The problem typically arises in models that generate noisy currents (synapses, ion channels, or "background noise") in which the a random number generator is called in the BREAKPOINT block and the returned result is used to simulate noise. It happens because the code in the BREAKPOINT block is executed twice at every time step in order to estimate the mechanism's conductance di/dv from the currents it generates at v and at v+0.001. The di/dv value is added to the corresponding element in the main diagonal of the Jacobian matrix that NEURON uses to advance the solution to the new time.
If the BREAKPOINT block contains a call to a random number generator, and the value returned by that generator is used to calculate i, then the slope conductance estimates will be completely incorrect. Occasionally the results will be so grossly wrong that the user may even notice it, as you did.
In broad outline, the fix is to move the call to the random number generator into a PROCEDURE, and include a corresponding
SOLVE procedurename
statement in the BREAKPOINT block. Here's how I fixed your particular code:
Change the BREAKPOINT block to
Code: Select all
COMMENT
BREAKPOINT {
i= i - ( dt * i ) / tau + amp * normrand(0,1)
}
ENDCOMMENT
BREAKPOINT {
SOLVE noise
}
PROCEDURE noise() {
i = i - ( dt * i ) / tau + amp * normrand(0,1)
}
Insert this at the top of the file
Code: Select all
: NTC revised 20160309
: to prevent corruption of the estimate of di/dt.
: This was done by removing normrand() call from BREAKPOINT block
: so it isn't called twice per advance.
Fixing the problem has two consequences. First, it eliminates all those giant jumps of v. Second, it completely changes the nature of the current that is generated: it is much smoother (all those little sawtooth-like jumps in v will go away--they're all excrement), and you'll have to reduce the value of the amp parameter by a factor of at least 50. Since the unfixed code generates garbage output, and the fix completely changes the amplitude and statistical properties of the delivered current, you may need to repeat whatever simulations you have already done.
To try to prevent future occurrences of this, we're checking ModelDB for code that makes a similar mistake.