arbor-sim / arbor

The Arbor multi-compartment neural network simulation library.
https://arbor-sim.org
BSD 3-Clause "New" or "Revised" License
108 stars 61 forks source link

Stricter checks on network construction / simulation parameters. #2264

Open thorstenhater opened 6 months ago

thorstenhater commented 6 months ago

We now check that

dt <= min_delay/2

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

bcumming commented 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:

thorstenhater commented 6 months ago

Hi @bcumming, currently I am looking at alternatives, but so far I haven't anything I can get behind:

  1. Implicitly changing all delays to at least dt. Altering user input without consent
  2. Allocating a minimum delay like EPSILON. Makes for really slow simulations.
  3. The variant above. Incorrect, as you noted.
  4. Your suggestion of throwing on zero delay. The model needs to know about execution parameters.

Out of those, 4. is probably the least worst option.

bcumming commented 6 months ago

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.

halfflat commented 6 months ago

My feelings about this: