Stricter checks on network construction / simulation parameters. #2264

thorstenhater · 2024-04-02T13:21:21Z

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 · 2024-04-03T04:56:38Z

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

thorstenhater · 2024-04-03T08:07:58Z

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

Implicitly changing all delays to at least dt. Altering user input without consent
Allocating a minimum delay like EPSILON. Makes for really slow simulations.
The variant above. Incorrect, as you noted.
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 · 2024-04-03T08:53:05Z

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 · 2024-04-03T09:26:29Z

My feelings about this:

The dt provided to 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).
Maximum dt should be greater than zero (we can throw if not a positive number).
Because of the above, a cell group should be free to internally set its dt in integration to less than the epoch duration.

halfflat · 2024-04-03T09:40:54Z

arbor/include/arbor/recipe.hpp

-        if (std::isnan(weight)) throw std::out_of_range("Connection weight must be finite.");
-        if (std::isnan(delay) || delay < 0)  throw std::out_of_range("Connection delay must be non-negative and infinite in units of [ms].");
+        if (std::isnan(weight)) throw std::domain_error("Connection weight must be finite.");
+        if (std::isnan(delay) || delay <= 0)  throw std::domain_error("Connection delay must be positive, finite, and given in units of [ms].");
    }


We have quite specific exceptions such as arb::bad_connection_source_gid defined in <arbexcept.hpp>; it would be consistent to define some exceptions to throw here that derive from arb::arbor_exception.

I am a bit torn here, std::domain_error fits the basic checks for isnan etc well and has the advantage that it plays nice with pybind11 (it'll automatically convert to ValueError).

halfflat · 2024-04-03T09:41:35Z

arbor/include/arbor/recipe.hpp

@@ -54,8 +54,8 @@ struct cell_connection_base {

    cell_connection_base(L src, cell_local_label_type dst, float w, const U::quantity& d):
        source(std::move(src)), target(std::move(dst)), weight(w), delay(d.value_as(U::ms)) {
-        if (std::isnan(weight)) throw std::out_of_range("Connection weight must be finite.");
-        if (std::isnan(delay) || delay < 0)  throw std::out_of_range("Connection delay must be non-negative and infinite in units of [ms].");
+        if (std::isnan(weight)) throw std::domain_error("Connection weight must be finite.");


Message doesn't match test: should this test be !std::isfinite(weight)?

That's better, yes.

halfflat · 2024-04-03T09:56:56Z

arbor/include/arbor/recipe.hpp

-        if (std::isnan(weight)) throw std::out_of_range("Connection weight must be finite.");
-        if (std::isnan(delay) || delay < 0)  throw std::out_of_range("Connection delay must be non-negative and infinite in units of [ms].");
+        if (std::isnan(weight)) throw std::domain_error("Connection weight must be finite.");
+        if (std::isnan(delay) || delay <= 0)  throw std::domain_error("Connection delay must be positive, finite, and given in units of [ms].");


Inasmuch as we're presuming NaNs work as expected, we could just have the test !(delay > 0) instead of std::isnan(delay) || delay <= 0.

Do we really need to enforce that delay is finite? If so, then the test should include that.

Also, not being familiar (yet) with how LLNL units works, why do we need to specify that the quantity is in milliseconds? Can't we just convert as required or else assert in the type?

Well, the two issues go hand in hand: (42 * U.ms).value_as(U.mV) == NaN. So, receiving a nan can mean either we got nan * U.ms or an erroneous unit. This is why the message allows for both.

halfflat · 2024-04-03T09:57:31Z

arbor/include/arbor/recipe.hpp

@@ -69,7 +69,7 @@ struct gap_junction_connection {

    gap_junction_connection(cell_global_label_type peer, cell_local_label_type local, double g):
        peer(std::move(peer)), local(std::move(local)), weight(g) {
-        if (std::isnan(weight)) throw std::out_of_range("Gap junction weight must be finite.");
+        if (std::isnan(weight)) throw std::domain_error("Gap junction weight must be finite.");


Similar comments as above: testing finite or testing Nan? We should use an arbor exception.

halfflat · 2024-04-03T10:11:28Z

arbor/simulation.cpp

+    if (!std::isfinite(dt) || dt < eps) throw std::domain_error("simulation: dt must be finite, positive, and in [ms]");
+    if (dt - t_interval_ > eps) throw std::domain_error(util::pprintf("simulation: dt={}ms is larger than epoch length by {}, chose at most half the minimal connection delay {}ms.", dt, dt - t_interval_, t_interval_));
+    if (!std::isfinite(tfinal) || tfinal < eps) throw std::domain_error("simulation: tfinal must be finite, positive, and in [ms]");
+    if (tfinal - epoch_.t1 < dt) throw std::domain_error(util::pprintf("simulation: tfinal={}ms doesn't make progress of least one dt; current time of simulation is {}ms and dt {}ms", tfinal, epoch_.t1, dt));


This seems all a bit fiddly; as mentioned in the general comments, I think we should just leave dt interpretation up to the integrators and they can make a sensible choice, e.g. clip it by epoch duration or interpret very small dt values as being larger, based on whatever they have to do. Having eps here is untidy because it splits the responsibility for sane dt interpretation between the main loop and the integrators.

Also, if someone wants to run arbor for ever, do we really need to stop them? We already have a check for tfinal being less than the end time of the preceding epoch, where we return the correct 'simulated up to' time, so we don't really need tests for it being zero, or negative; in fact a tfinal of zero should be a valid no-op in my opinion.

In short, a isnan test for tfinal remains sufficient, I believe.

In endeffect you are suggesting that instead of throwing an error, the cell groups' individual advance methods should decide. Do enable that, we'd have to pass all possible options, currently min_delay and dt, down the stack. I'd rather make the choice uniformly, especially since #2053.

No we don't have to pass it down the stack: we know epochs are at most min_delay/2 long. The epoch already has all the info they need, and if there is more info it will be in the cell kind global data, which they also have.

#2053 is just cable cells, and I still want to partially revert it so that we can use flexible time steps with a different cable cell integrator, even if it's just to make them line up correctly with epoch intervals.

As an example, if we have the last epoch (ending on tfinal) having duration 3.1 dt, wouldn't it be best to set the fixed dt for that epoch to be e.g. the duration/4 and then we would know that all cell states across cell groups were actually at the same integration time?

Also, if someone wants to run arbor for ever, do we really need to stop them? We already have a check for tfinal being less than the end time of the preceding epoch, where we return the correct 'simulated up to' time, so we don't really need tests for it being zero, or negative; in fact a tfinal of zero should be a valid no-op in my opinion.

Technically I agree. Practically I know that I'd spent way too much time looking for the reason why my simulation did nothing in that situation. Especially since our time_type doesn't distinguish time points from durations, so run(5 *ms) really could mean run until t=5ms or run for 5ms. Thus I think it's friendlier towards the user to tell them 'this is a no-op and you likely didn't mean that'. Especially, as I cannot currently imagine situations where this is a semantically meaningful request.

As a general principle, I think we should keep things general unless there is a good reason not to. I mean, the parameter is literally called tfinal, and we return the simulation state time - it's a simple interface with simple semantics (from the outside) and there's nothing stopping us adding checks on the outside of that if we want to provide more hand holds in the Python interface (though I don't think we should there either).

We can always change the name to run_to.

The semantics of running a simulation from t = 0 for 0 seconds should be that the state reflects the initial conditions. It's not what we'd expect someone to do in normal circumstances, but it's the consistent result, and may arise in circumstances where the simulator is being driven by another process or co-simulation.

Damn you and your arguments :D

Tiny fix for |epoch| < dt.

6a5bdc4

Tighten the checks on simulation::run.

4fb5476

Stricter checks, adjust tests.

12261a2

thorstenhater changed the title ~~Tiny fix for |epoch| < dt.~~ Stricter checks on network construction / simulation parameters. Apr 3, 2024

halfflat reviewed Apr 3, 2024

View reviewed changes

thorstenhater added 5 commits April 3, 2024 13:31

Loosen checks a tiny bit, ensure min_delay is >0.

2739392

Merge, relax check on t_final, and use isfinite.

0893669

Fix tests.

4797b9f

Merge remote-tracking branch 'origin/master' into bug/epoch-lt-dt

b85e8e6

Format.

73acec6

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stricter checks on network construction / simulation parameters. #2264

Stricter checks on network construction / simulation parameters. #2264

thorstenhater commented Apr 2, 2024 •

edited

Loading

bcumming commented Apr 3, 2024 •

edited

Loading

thorstenhater commented Apr 3, 2024 •

edited

Loading

bcumming commented Apr 3, 2024 •

edited

Loading

halfflat commented Apr 3, 2024

halfflat Apr 3, 2024

thorstenhater Apr 3, 2024

halfflat Apr 3, 2024

thorstenhater Apr 3, 2024

halfflat Apr 3, 2024

thorstenhater Apr 3, 2024

halfflat Apr 3, 2024

halfflat Apr 3, 2024

halfflat Apr 3, 2024

thorstenhater Apr 3, 2024

halfflat Apr 3, 2024

halfflat Apr 3, 2024

halfflat Apr 3, 2024

thorstenhater Apr 3, 2024

halfflat Apr 3, 2024 •

edited

Loading

thorstenhater Apr 3, 2024

Stricter checks on network construction / simulation parameters. #2264

Are you sure you want to change the base?

Stricter checks on network construction / simulation parameters. #2264

Conversation

thorstenhater commented Apr 2, 2024 • edited Loading

bcumming commented Apr 3, 2024 • edited Loading

thorstenhater commented Apr 3, 2024 • edited Loading

bcumming commented Apr 3, 2024 • edited Loading

halfflat commented Apr 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

halfflat Apr 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thorstenhater commented Apr 2, 2024 •

edited

Loading

bcumming commented Apr 3, 2024 •

edited

Loading

thorstenhater commented Apr 3, 2024 •

edited

Loading

bcumming commented Apr 3, 2024 •

edited

Loading

halfflat Apr 3, 2024 •

edited

Loading