Open thorstenhater opened 6 months ago
In this case, dt > min_delay/2
will lead to invalid output because spikes won't be delivered on time. I see that the desire is to "simulate" a zero-delay connection by picking a very small connection delay, so why not just require that they user selects delay = dt/2
?
According to Arbor's model, shouldn't dt > min_delay/2
be a hard error, because the following should always be true:
dt <= min_delay/2
dt > 0
min_delay > 0
Hi @bcumming, currently I am looking at alternatives, but so far I haven't anything I can get behind:
dt
. Altering user input without consentOut of those, 4. is probably the least worst option.
Do you need the model to know about execution parameters?
Instead, the simulation
object could throw during model initialisation, or when simulation::run
is called, based on all runtime information. This reflects that while the model might be "correctly" specified, the runtime configuration is not correct.
My feelings about this:
simulation::run
should be regarded as firstly a maximum dt and secondly as being up to cell group implementations to interpret in their context of finding a solution (including being ignored).
We now check that
before running a simulation and connections can no longer be constructed with zero delay.
In addition,
simulation::run
checks that forward progress of at least a single step $\Delta t$ is made. If that is not the case, we assume oversight on part of the user instead of silently doing nothing.Addresses #2263