Closed mstimberg closed 5 years ago
I think my last commit fixes the issues you identified, would be grateful if you could have another look.
Now the question is - do we have any tests that cover some of the likely use cases? Do you have run-regularly tests in the Brian tests?
We do have a couple of tests, e.g. a basic test for NeuronGroup
:
G = NeuronGroup(1, 'v : 1')
G.run_regularly('v += 1', dt=2*defaultclock.dt)
M = StateMonitor(G, 'v', record=0, when='end')
run(10 * defaultclock.dt)
assert_allclose(G.v[:], 5)
assert_allclose(np.diff(M.v[0]), np.tile([0, 1], 5)[:-1])
and a similar one for Synapses
:
G = NeuronGroup(10, 'v : 1', threshold='False')
tau = 10*ms
S = Synapses(G, G, 'w : 1', on_pre='v += w')
S.connect(j='i')
S.run_regularly('w = i')
run(defaultclock.dt)
assert_allclose(S.w[:], np.arange(10))
I also specifically added a test that changes the order
argument of StateMonitor
and run_regularly
which is mostly relevant for brian2genn
(in standard Brian, you'd rather use scheduling via named slots which only has very basic support in brian2genn
). They all pass (ignore all the failing tests for the ..._stable
configurations, current brian2genn
from master
needs brian2
from master
...).
This PR still needs a bit more thorough testing, but it seems to work in principle.
run_regularly
operations are now always executed on the CPU, which comes with a number of advantages over the previous solution:TimedArray
#13).Synapses
can haverun_regularly
operations as well (Fixes #58)run_regulary
operation per object allowed (not sure how relevant this is in practice, though).If the user has a
run_regularly
operation that gets executed every time step, then the new approach will probably slow the simulation down a bit. For the more standard use case of a rarely executed operation, I don't think we'll see any difference.Fixes #96.