www.neuron.yale.edu

I recently ran some tests with variable time step simulations and have a few questions. First, I was told that I could force output to have a fixed time step. But the documentation states:

following two not yet implemented
x = cvode.active(1, dt)

and I see that the dt argument does indeed seem to be ignored; recording time into a vector shows the variable time steps. Does any other version allow this, or is there anything else I can do to make this work?

Second: With cvode active it seems that the solution around current pulse (Iclamp) transitions is not very reproducible. I guess Iclamp doesn't inform cvode of these transition times, correct? How can I get around this?

Third: I was able to use SEClamp to voltage clamp with a recorded action potential waveform with cvode active. However, the voltage clamp simulation was very slow compared to the initial current clamp simulation or even the fixed time step simulation. Why is that?

Thank you!

Good questions.

TWA wrote:I recently ran some tests with variable time step simulations and have a few questions. First, I was told that I could force output to have a fixed time step.

Use Vector class's record() method with 2nd argument equal to desired sampling interval. Read about it in Programmer's Reference.

With cvode active it seems that the solution around current pulse (Iclamp) transitions is not very reproducible.

That would be news. Supposed to be 100% reproducible. Can you send me
ted dot carnevale at yale dot edu
a simple example that demonstrates such irreproducibility? Please follow the recommendations in
What to include in a zip file, and what to leave out viewtopic.php?f=28&t=560
and
No rar, doc, or winmail.dat files, please! viewtopic.php?f=28&t=1048

I was able to use SEClamp to voltage clamp with a recorded action potential waveform with cvode active. However, the voltage clamp simulation was very slow compared to the initial current clamp simulation or even the fixed time step simulation. Why is that?

Very good question.

First, an important general comment:

Adaptive integration is not necessarily faster than fixed time step integration. In many cases, it is slower, sometimes much slower. A single fadvance() is about 3 x slower with adaptive integration than with fixed time step. You only get shortened runtimes if the system trajectory is such that the adaptive integrator can make enough big increments in time to compensate for all of the short, costly steps it takes for the sake of guaranteed local accuracy.

Next, some important specific comments:

The devil is in the details, and certainly that is so with regard to the use of Vector play during adaptive integration. If you specified Vector play with the usual syntax, you are actually forcing v to follow a step function (let me direct you to http://www.neuron.yale.edu/neuron/stati ... cvode.html, and in particular the following excerpt:
" . . . if one records an action potential (with either fixed or variable time steps) and plays it back into a voltage clamp; the clamp potential is not a discrete function but an exact step function."). Each of those steps is an abrupt jump of v that produces a rapidly decaying capacitive transient in the clamp current, and the integrator is forced to advance the solution in many tiny time steps. Performance goes down the toilet, and the clamp's current record is full of capacitive artifacts.

Instead, specify Vector play with the "continuous" argument, e.g.
vsrc.play(&SEClamp.amp1, tvec, 1)
and the forcing function willl be treated as a piecewise linear function, with consequent improved speed of execution and a much cleaner looking clamp current. Please read the documentation on Vector play http://www.neuron.yale.edu/neuron/stati ... .html#play, especially the paragraph that begins
"When continuous is 1 then linear interpolation is used to define the values between time points. However, events at each Dt or tvec are still used and that has beneficial performance implications for variable step methods since vsrc is equivalent to a piecewise linear function . . . "