In solving a large system of ODEs I found that Method->ExplicitRungeKutta (also Automatic as a matter of fact) is fast, but often unstable. I tried the option Method->ImplicitRungeKutta, but for the given number of ODEs (3924) the memory used by the kernel grows above 50GB. Eventually I have to stop the calculation. What options of NDSolve can be tried to improve the stability and remain with reasonable memory consumption?

  • 2
    $\begingroup$ Generally, implicit methods require a lot more work (and storage) per step, but if a problem is stiff (cf. this answer), an implicit method will take fewer steps than an explicit method. Then, you have methods that are able to switch between using an explicit and implicit method (e.g. "StiffnessSwitching"), depending on the ODE's behavior. Without seeing what your ODEs look like, it's hard to say more. $\endgroup$ Jan 20, 2021 at 9:29
  • $\begingroup$ @J.M. right, but as far as I understand, the "StiffnessSwitching" switches from explicit to implicit, but never goes back to explicit. $\endgroup$
    – yarchik
    Jan 20, 2021 at 9:47
  • $\begingroup$ Actually it does; that's why it supports a "NonstiffTest" as well as a "StiffnessTest" option. See the discussion in Stiffness Detection. $\endgroup$ Jan 20, 2021 at 10:22
  • 4
    $\begingroup$ What do you mean by unstable? My personal experience is the default setting of NDSolve is quite robust for IVP of ODE(s). (There exist rare cases that one needs to adjust MaxStepSize though. ) But who knows… As @J.M. said, it's hard to advise without a concrete example. $\endgroup$
    – xzczd
    Jan 20, 2021 at 11:00
  • 1
    $\begingroup$ @yarchik Did you read this paper arxiv.org/pdf/1505.02290.pdf ? $\endgroup$ Jan 21, 2021 at 21:04


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.