Is the CVode class implemented so that it scales well with many nodes?

General issues of interest both for network and
individual cell parallelization.

Moderator: hines

Post Reply
itaru
Posts: 7
Joined: Wed Jan 29, 2020 10:15 pm
Contact:

Is the CVode class implemented so that it scales well with many nodes?

Post by itaru » Tue Feb 25, 2020 8:17 pm

I ask this because I will be using the class. Thanks!

ted
Site Admin
Posts: 5704
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Is the CVode class implemented so that it scales well with many nodes?

Post by ted » Tue Feb 25, 2020 10:35 pm

Try it.

ramcdougal
Posts: 196
Joined: Fri Nov 28, 2008 3:38 pm
Location: Yale School of Public Health

Re: Is the CVode class implemented so that it scales well with many nodes?

Post by ramcdougal » Wed Feb 26, 2020 3:50 pm

CVode is an adaptive algorithm that chooses time steps to give results within a specified error tolerance.

Thus it will use small timesteps when things are changing rapidly (e.g. synaptic input, during an action potential) and larger timesteps where they are not. To get the same accuracy out of fixed step, you'd have to use the small timesteps for the entire simulation. For single cell simulations, this is a double win, because you get a bound on error and potentially faster simuation by advancing quickly over the relatively calm parts.

There's a potential practical problem though. Remember that to ensure accuracy, CVode must use small time steps near action potentials and synaptic input. If you have a large network (I'm assuming you do, since this is the "Parallel NEURON" board), there's likely to be lots of these, and therefore you'll need to use small time steps for a signficant fraction of your simulation. (i.e. there are no calm time periods). NEURON does support locally variable timesteps (see e.g. https://dx.doi.org/10.1162%2F0899766053429453) but if there is a lot of input coming into every specific cell, then the same issues remain.

CVode will have no problem computing appropriately small time steps to get the accuracy right, but guaranteeing that accuracy might require smaller time steps on average than you'd prefer to use for e.g. a fixed step simulation. The only way to know for sure if the accuracy constraint will affect runtime negatively is to try it.

The good news is, if the accuracy forces slower timesteps than you'd like, you can switch back without modifying any of your code except the single line that says something like

Code: Select all

h.CVode().active(True)
to instead say

Code: Select all

h.CVode().active(False)
Fixed step integration does risk introducing more synchrony than is truly present in your model (since any spikes coming in during a time step are treated as coming in simultaneously) and doesn't directly allow constraining accuracy -- you'd have to experiment to see if these are a problem in your model -- but many modelers find these tradeoffs are ok for their specific model.

Post Reply