-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulator doesn't seem to work correctly when time step is changed #243
Comments
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. |
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. |
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 Therefore based on the current design of the event queue buffer, simulation time step 0.01ms is not allowed. |
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):
|
I want to postpone this to the future issue. Reasons:
|
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. |
What kind of issue is this?
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.
Other Comments
The text was updated successfully, but these errors were encountered: