为什么在DifferentialEquations.jl中同时使用tableau和显式求解器?

ido*_*uch 3 differential-equations julia differentialequations.jl

我正在查看DifferentialEquations.jl包裹.在 DiffEqDevTools/src/ode_tableaus.jl我所看到的舞台造型 MidpointRK4.

但我也可以看到这些方案的明确代码 OrdinaryDiffEq/src/integrators/fixed_timestep_integrators.jl.

我有点期望一些代码使用tableaux而不是有一个明确的解算器.

我不知道如何检查是否正在使用画面.我尝试删除,OrdinaryDiffEq.jl但后来我的例子不会运行.

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

Chr*_*kas 9

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

这样做的原因是因为基于tableau的实现往往不那么有效.通过使用指向常量的指针消除间接性会对运行时产生可测量的影响.当然,在用户f极其昂贵的渐近极限中,实现细节并不重要,但是大多数现实世界的情况都没有达到那个限制,正如实际基准所证明的那样(在这个限制中,你应该使用多步骤方法) ).因此,存在具有硬编码高阶插值方案的最有效Runge-Kutta方法的硬编码版本,因为这些是主力方法并且应该获得最大效率.

那么为什么这些表格存在呢?我认为值得注意的是,DifferentialEquations.jl不仅仅是使用微分方程的软件包,而且它也是用于开发和测试新方法的软件包.这可以通过devdocs中的测试功能得到证明.对于具有更高效实现的算法,该表格仍然具有开发用途,因为该表格都具有相同的实现,因此这提供了一种简单的科学方法来确定方法之间的真实效率.使用表格不仅可以比较效率,还可以使用绘图配方比较稳定性区域:

plot(constructRK4())
Run Code Online (Sandbox Code Playgroud)

RK4稳定性

这个大型的画面库用于梳理所有RK方法并创建现代化的选择.我发布了一些关于它的随意笔记,并在CompSci SO帖子中更广泛地记录了一些部分.这些都是使用开发工具完成的所有实验.

最后,DifferentialEquations.jl非常独特,因为它不仅仅是您之前看到的重新实现.之前的一个明显变化是4/5 Runge-Kutta选择的方法不是DP5像MATLAB或SciPy那样的Dormand-Prince对(它只是一个dopri5包装器),而是一种现代算法:Tsit5()方法.这是因为当计算成本均匀时,这种更新的方法理论上可以实现更低的误差,并且devtools证实了这一点.在DifferentialEquations.jl其他东西是独特的是其随机微分方程适应性,高阶方法时滞微分方程等,还有其它更多的研究来(东西私有仓库,直到出版).由于相关的开发套件,大多数情况都成为可能(或至少容易做到).

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

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

我将在不久的将来的博客文章中介绍DifferentialEquations.jl的理念,但这就是它的要点.我不认为这是一个很大的问题,因为对我来说,为什么我一直都知道效率低下的方法(尽管不推荐!),这更像是个人问题,我希望这给出了一个信息丰富的答案.