【问题标题】:Why both tableau and explicit solver in DifferentialEquations.jl?为什么在 DifferentialEquations.jl 中同时使用表格和显式求解器?
【发布时间】:2017-05-02 06:54:52
【问题描述】:

我正在查看DifferentialEquations.jl 包。在 DiffEqDevTools/src/ode_tableaus.jl我可以看到画面 MidpointRK4

但我也可以在 OrdinaryDiffEq/src/integrators/fixed_timestep_integrators.jl.

我有点期待一些代码使用画面而不是那里 作为一个显式求解器。

我不确定如何检查画面是否正在使用。 我尝试删除 OrdinaryDiffEq.jl 但我的示例不会 运行。

这反而表明正在使用显式代码。但在 那这种情况为什么画面还存在呢?

【问题讨论】:

    标签: julia differential-equations differentialequations.jl


    【解决方案1】:

    是的,在大多数情况下不使用画面。实际上,只有在使用ExplicitRK(tableau=...) 方法时才会使用该表。您可以在 DiffEqDevTools' tests 中看到对每一个的收敛测试,但除此之外,它们通常不被使用。

    这是因为基于画面的实现往往效率不高。摆脱使用指向常量的指针引起的间接性对运行时有可衡量的影响。当然,在用户的f 非常昂贵的渐近限制中,实现细节并不重要,但大多数现实世界的案例都不在这个限制中,正如真实基准所证明的那样(在那个限制中,你应该使用多步方法总是)。因此,最有效的 Runge-Kutta 方法有硬编码版本,它们带有硬编码的高阶插值方案,因为这些是主力方法,应该获得最大的效率。

    那么为什么这些画面会存在呢?我认为重要的是要注意,DifferentialEquations.jl 不仅仅是一个使用微分方程的软件包,它还是一个用于开发和测试新方法的软件包。 the testing features in the devdocs 证明了这一点。对于有更高效实现的算法,表格仍然有开发用途,因为表格都有相同的实现,因此这提供了一种简单的科学方法来确定方法之间的真正效率。拥有表格不仅可以比较效率,而且您还可以使用绘图配方比较稳定性区域:

    plot(constructRK4())
    

    This large tableau library 用于梳理所有 RK 方法并创建现代化选择。 I posted some haphazard notes written about itdocumented some parts more extensively in a CompSci SO post。这些都是使用开发工具完成的实验。

    最后,DifferentialEquations.jl 确实是独一无二的,因为它不仅仅是对您之前所见内容的重新实现。与之前的一个明显变化是,选择的 4/5 阶 Runge-Kutta 方法不是像 MATLAB 或 SciPy 中那样的 Dormand-Prince 对 DP5(它只是一个 dopri5 包装器),而是一种现代算法: Tsit5() 方法。这是因为这种较新的方法理论上在计算成本均匀时实现了较低的误差,而开发工具证实了这一点。 DifferentialEquations.jl 中其他独特的东西是its adaptivity for stochastic differential equationshigh-order methods for delay differential equations 等,还有更多的研究即将到来(在私有存储库中发布直到发布)。由于相关的开发套件,其中大部分成为可能(或至少很容易做到)。

    所以我认为这清楚地表明,DifferentialEquations.jl 的哲学与其他语言/库中的微分方程套​​件不同。在其他套件中,例如 MATLAB 或 SciPy,大多数时候目标是为您提供一些通常有用的基本方法。效率不一定是目标(一个很好的例子是 Shampine 有意识地选择在 MATLAB 中没有高阶 RK 方法),包装“标准”实现通常就足够了(SciPy 只是包装器)。简单和标准对这些软件套件很有意义。

    但DifferentialEquations.jl 的重点是开发处理现代计算困难方程的新方法,并使用这些新方法解决以前不可行的问题。由于这种不同的关注点,有一些选择是不同的。例如,在这里拥有大量方法/实现是很好的,因为它允许用户和方法研究人员在算法之间进行比较,并找出如何不断改进它们和选择(我邀请用户针对他们的问题测试画面方法并查看如果一些晦涩的 RK 方法做得很好)。我关心的是确保最有效的研究工具可用,并通过向用户提供默认值和建议来处理复杂性。如果文档中的建议有任何不明确的部分,请打开一个问题,以便我们讨论如何改进文档。但我认为引导用户“正确”选择方法是一个文档问题,而不是应该限制设计、功能或效率的问题。

    我将在近期的一些博客文章中介绍微分方程.jl 的哲学,但这就是它的要点。我不认为这是一个很大的问题,因为这对我来说更像是一个个人问题,为什么我一直知道低效的方法(尽管不推荐!),我希望这能提供一个信息丰富的答案。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-11-08
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-11-05
      • 1970-01-01
      • 2012-03-01
      相关资源
      最近更新 更多