Simulator doesn't seem to work correctly when time step is changed #243
Description
What kind of issue is this?
- Bug report
- Feature request
- Question not answered in documentation
- Cleanup needed
Attempt to change time step from 0.1ms to 0.05ms or 0.1ms produces results that are completely different than original.
What is affected by this?
Simulator
How do we replicate the issue/how would it work?
Change only time step; keep all other parameters the same.
Expected behavior (i.e. solution or outline of what it would look like)
Should produce qualitatively the same results. Since we deliver random numbers at each time step, changing the time step size will produce different noise realizations, even with identical seeds. But, this should not make a large qualitative difference in results, after analysis. So, for example, if done with Izikevich, the raster plot should look basically the same and neuron spike rates and ISI distributions should be the same.
Activity
fumik commentedon Nov 2, 2018
Run 1s simulation with 1x1 LIF neuron (no input, no active neuron) changing time step 0.1ms and 0.01ms.
Results:
membrane potential of 0.1ms time step simulation
membrane potential of 0.01ms time step simulation
As we can see the results, fluctuation of membrane potential of 0.01ms time step simulation is smaller. If this neuron is an active neuron which threshold is around 13.6e-3V, the neuron never fire.
Reason:
According to the formula below, the fluctuation of membrane potential is proportional to C2⋅Inoise. Therefore as the simulation time step becomes smaller, C2 also gets smaller, and eventually the the fluctuation of membrane potential becomes smaller.
Vm(t+Δt)=C1⋅Vm(t)+C2⋅(Isyn(t)+Iinject+Inoise+Vresting/Rm)
C2=Rm⋅(1−e(−Δt/τm)) .
stiber commentedon Nov 2, 2018
EDITED
The most obvious cause is that C2 is scaling the noise amplitude by a factor of 10 as the time step is reduced by a factor of 10. The simplest approach, a bit of a hack, would be to multiply Inoise by the ratio of Δt and 0.1ms.
It also might be due to the noise's spectrum being shifted to higher frequencies, which are then low pass filtered by the LIF neuron. One approach to addressing this would be to choose a "standard" noise (say at 0.1ms time step), double-buffer noise generation, and then wrap the RNG with a noise generator that interpolates so that, regardless of the time step, the neuron gets (approximately) the same waveform.
fumik commentedon Nov 5, 2018
To make the noise generator more general, we should introduce a parameter, the noise frequency, in addition to the noise scale factor. For the current implementation, the noise frequency is equal to (1/(simulation time step)). The noise frequency is (1/(interval between noise)), and it must be (the noise frequency <= 1/(simulation time step)). If (the noise frequency < 1/(simulation time step)), we will interpolate noises.
fumik commentedon Nov 6, 2018
Another restriction regarding to the simulation step is caused by the length of event queue buffer, and it must be satisfied by the following formula.
(maximum + minimum synapse transmission delay) / simulation step + 1 < length of event queue buffer.
where: maximum synapse transmission delay = 1.5e-3
minimum synapse transmission delay = 0.8e-3
length of event queue buffer = 64
Therefore based on the current design of the event queue buffer, simulation time step 0.01ms is not allowed.
stiber commentedon Nov 7, 2018
OK, the decision about noise makes sense to me. We should probably avoid the term "frequency" for this, as it could be confused with the frequency content of the noise, i.e., that it's not white noise. Maybe "noise time step"? Or "noise update interval"?
In thinking about the two alternatives (increase the noise current amplitude vs. keep the noise time step constant and interpolate) it strikes me that we're presenting the individual doing the simulation with a choice (and that is good, because they can make the decision):
fumik commentedon Nov 9, 2018
I want to postpone this to the future issue.
Reasons:
stiber commentedon Nov 11, 2018
Agreed. While we can hack this, it's not entirely clear that we can make all of these things independent of time step changes so that we can be confident that we aren't introducing artifacts. I'll reference issue #182 that notes that we should likely separate the integration method from the models. Typically, this is done by having the model-specific code take in state information and return derivatives, which the integrator then uses. But this is a major change — as big as thinking of noise in terms of synthesizing a waveform rather than merely generating random numbers.