### Integration methods for SOLVE statements

Posted:

**Thu Sep 14, 2006 11:11 am**Use

Use

u' = a*(b*v - u)

the mechanism requires derivimplicit.

derivimplicit has first order accuracy in time and is stable regardless of the stiffness or nonlinearity of the system equations.

For kinetic schemes use

SOLVE foo METHOD euler

and they may seem to work, but euler is prone to instability when system equations are stiff--and most mechanistic models of neurons have stiff system equations. Also, euler cannot be used in multithreaded simulations. Just because it's in ModelDB doesn't mean that it's the right thing to do. Doesn't matter who it was who wrote it. No new code should be written that uses euler, and old code that uses it should be revised to use something else.

**cnexp**for mechanisms described by linear ODEs (including HH-style channel models). This is an implicit integration method that is stable even for stiff systems (models in which there is a wide range of time constants). cnexp can produce solutions that have second order precision in time.Use

**derivimplicit**for general equations--that is, nonlinear ODEs and ODEs that include coupled state equations--and for simple ion accumulation mechanisms (like cacum.mod in examples). Also, remember that v is indeed a state variable, so if the DERIVATIVE block includes an ODE like thisu' = a*(b*v - u)

the mechanism requires derivimplicit.

derivimplicit has first order accuracy in time and is stable regardless of the stiffness or nonlinearity of the system equations.

For kinetic schemes use

**sparse**. NMODL code that involves a KINETIC block is translated into equations that require use of the sparse solver, which produces results with first order precision in time.**NEVER use euler.**You may find legacy code with BREAKPOINT blocks that assertSOLVE foo METHOD euler

and they may seem to work, but euler is prone to instability when system equations are stiff--and most mechanistic models of neurons have stiff system equations. Also, euler cannot be used in multithreaded simulations. Just because it's in ModelDB doesn't mean that it's the right thing to do. Doesn't matter who it was who wrote it. No new code should be written that uses euler, and old code that uses it should be revised to use something else.