I didn't specify runge-kutta or anything else for DERIVATIVE block and get this warning: "adrunge not thread safe"
Error goes away if I explicitly choose SOLVE states METHOD derivimplicit or cnexp
Seems funny that the default METHOD is one that is not threadable? -- I had generally tried to avoid defining a particular METHOD in nmodl so that the file could keep up with whatever method is best. What is current practice?
adrunge not thread safe
-
ted
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: adrunge not thread safe
Good that warning turned up. Always specify an appropriate method. runge, adrunge, adams etc. are not appropriate. See
Integration methods for SOLVE statements viewtopic.php?f=28&t=592
in the Forum's Hot tips area. Those recommendations are current.
Integration methods for SOLVE statements viewtopic.php?f=28&t=592
in the Forum's Hot tips area. Those recommendations are current.
Re: adrunge not thread safe
I had forgotten about that. It was the default for SCoP. The fix on our part will be to replace the existing adrunge implementation with a thread
safe version. Nevertheless, adrunge generally makes little sense in a NEURON context since the extra accuracy does not translate into a more
accurate simulation since the tree cable numerics are first or second order correct. The higher order accuracy gotten from cvode is independent
of the METHOD chosen in the SOLVE block.
safe version. Nevertheless, adrunge generally makes little sense in a NEURON context since the extra accuracy does not translate into a more
accurate simulation since the tree cable numerics are first or second order correct. The higher order accuracy gotten from cvode is independent
of the METHOD chosen in the SOLVE block.