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$ – J. M.'s torpor Jan 20 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 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$ – J. M.'s torpor Jan 20 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 at 11:00
  • 1
    $\begingroup$ @yarchik Did you read this paper arxiv.org/pdf/1505.02290.pdf ? $\endgroup$ – Alex Trounev Jan 21 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.