Noise MOD creating strange voltage discontinuities

[Bill Connelly]

So I have been using a mod file for creating membrane noise based on a very simple Ornstein–Uhlenbeck process of current. However, the other day, I noted that if I increase the current then the membrane potential behaves very very strangely.

Here is an image of the noise behaving normally in a simple compartment model containing ONLY the default passive conductance


I set the random seed to be the same, and then increase the amplitude by a factor of 10. The current dutifully scales by 10, and I would expect the voltage deflections to essentially scale by a factor of 10 also, but as you can see, that does not happen



The mod code is:

Code: Select all

INDEPENDENT {t FROM 0 TO 1 WITH 1 (ms)}

NEURON {
	POINT_PROCESS Inoise2
	RANGE tau, amp
	RANGE new_seed
	NONSPECIFIC_CURRENT i
}

UNITS {
	(nA) = (nanoamp) 
}

PARAMETER {
	dt		(ms)
	amp = .01 (nA)
	tau = 30 (ms)
}

ASSIGNED {
	i 	(nA)		: fluctuating current
}

INITIAL {
	i = 0
}

BREAKPOINT {
  i= i - ( dt * i ) / tau + amp * normrand(0,1) 
}


PROCEDURE new_seed(seed) {		: procedure to set the seed
	set_seed(seed)
}

Anyone have any thoughts on what is happening and what I can do about it?

Thanks

[ted]

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.

[Bill Connelly]

Okay, that makes a lot of sense. I thought it was going to be something vaguely along those lines.

And thank you, that fixes the problem.

But can I ask, WHY does it fix the problem? i.e. if BREAKPOINT is called twice? I would have thought by packing the RNG off to another function, and then calling that function in BREAKPOINT, we end up with the same situation.

[ted]

Good question.
SOLVE foo
and
SOLVE foo METHOD bar
causes only one execution of fhe code in foo per time step.