adrunge not thread safe

NMODL and the Channel Builder.
Post Reply
wwlytton
Posts: 65
Joined: Wed May 18, 2005 10:37 pm
Contact:

adrunge not thread safe

Post by wwlytton » Tue Nov 05, 2019 6:34 pm

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?

ted
Site Admin
Posts: 5621
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: adrunge not thread safe

Post by ted » Tue Nov 05, 2019 8:41 pm

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.

hines
Site Admin
Posts: 1580
Joined: Wed May 18, 2005 3:32 pm

Re: adrunge not thread safe

Post by hines » Wed Nov 06, 2019 6:34 am

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.

Post Reply