random variables and simulation speed

[porio]

Hi,

I've been playing around with random number generators, both within mod files and hoc files (in the latter case, I introduced a noisy current with the play command of the Random class).
I every case, I'm obtaining weird behaviours that I will try to explain:

- When using fixed timestep (cvode.active(0)) the simulation gets slower and slower as it runs. To give you an idea, the first 1000 ms are calculated in ~2.2 seconds; the second 1000 ms, in ~2.8 s; then in ~3.5 s. My simulations are 80 seconds long, so you can imagine how slow the simulation turns when reaching the end.

- If I set cvode.active(1), I can not see any randomness in the simulation, it's as if there were no random current at all.

I have seen more or less the same behaviour regardless of wether the 'randomness' lies within a .mod mechanism or at the hoc level.

IMPORTANT UPDATE: I am seeing the slow down of the simulation even without the random current (when cvode.active is 0), so it seems that this is my principal problem. Why does it happen?

Thanks.

[porio]

Doing further search, I have partly answered myself:

Under MSWin, screen updates slow down considerably after more than a few thousand
points have been plotted in a graph. There might be an undocumented system call that
avoids this problem (undocumented system calls were used successfully by MicroSoft in
the early 1990s to enhance the performance of Word and Excel vs. competitors WordStar,
WordPerfect, Lotus 123 etc.).

But whether you're using MSWin, Linux, or OS X, the best strategy for dealing with long
simulations is to use the Vector class's record() method to capture the variables of interest,
then save or plot them after the end of the simulation.

Now I can add two more specific questions:

- Why it doesn't happen when using cvode.active(1)?
- There are still some situations when I don't want to wait till the end of the simulation to see what's going on. Should I move to Linux?

Regards.

[hines]

- Why it doesn't happen when using cvode.active(1)?

CVode may be plotting fewer points. At the end of the run do a pick vector on one of the trajectories and type

Code: Select all

hoc_obj_.size

There are still some situations when I don't want to wait till the end of the simulation to see what's going on. Should I move to Linux?

In the RunControl, change "Scrn update invl (s)" to 5 and see if that improves matters.

- If I set cvode.active(1), I can not see any randomness in the simulation, it's as if there were no random current at all.

To use cvode, noise must be defined to make sense independent of the value of dt. Normally this means it has to be defined in terms of negexp and events. Cvode requires that a system be continuous up to the derivative order it is trying to use, often 3 or 4. So if a noise event occurs on the order of a fixed step dt, use the fixed step method. However, noise generally causes cvode to keep reducing dt til it gets so close to 0 it refuses to continue. Since you say the result is as if there is no noise at all, there must be something else wrong or else the noise is so small that it still satisfies cvode's absolute state tolerance criterion in terms of its effect
on states.

[ted]

porio wrote:

Thanks mike!
I don't know what may be going wrong with the noise and cvode, sometimes it behaves as you say and sometimes it doesn't. Some day I will take a closer look at it.
Now I have another noise related question/problem.

The remainder of porio's message starts a new thread called
Random play()--see https://www.neuron.yale.edu/phpBB2/viewtopic.php?p=2582