brian-team/brian2 — pull request #318 by mstimberg (2014-08-27 10:18:21+00:00)
Title: Scheduling time and reinit

This is not ready to merge yet, I'd just like to discuss an important fundamental decision.

As discussed in #183, I changed the interface so that the user never deals with `Clock` objects, instead they can specify a `dt` for the `NeuronGroup` etc. (and for more precise control, `when` and `order`). At the run preparation stage, one clock is created for each dt and assigned to the respective objects.

I'm not very satisfied with this, since we keep `Clock` objects around but not in a very useful way. The main two problems I'm seeing are:
1. We still have to use `AttributeVariable` objects to get `t` and `dt` from the `Clock` object -- it would be quite nice if we could get rid of them
2. In the code, we always have to take care not to assume that an object already has a clock, it might not if it hasn't been run yet.

A more straightforward system seems to me to store the clock information directly in each object, i.e. have an integer timestep and a dt and a `t` that is calculated from `timestep * dt`. `Clock` objects would completely disappear.

There's only one problem with this approach, we could not nicely support a change in dt between runs. If each object has a dt after its creation (if none was specified, the default dt) there's no easy way to change the dt for all objects, you'd have to change dt for each object individually.

In the master branch, changing dt is relatively straightforward: each object has a clock, either `defaultclock` or an explicitly specified one. So you could change the clock's dt after object creation and the reference semantics made it clear that this changes the dt for all the objects using that clock. But then again, clocks also store the `t`, leading to the problems we discussed in #183 and we need `AttributeVariable` objects, etc.

Any good ideas...? @romainbrette, what do you think?