Look into CellML 2.0 reset rules

[MichaelClerx]

1. Should we support them in the cellml parsing step? UPDATE: yes
2. In the sympy step? UPDATE: No
3. In the model code generating step? UPDATE: Yes
4. See if CellML reset rules can be used to implement pacing, and see if this can speed up pre-pacing in particular (or just be intelligent about when to reset CVODE, and when max dt can be large)

[MichaelClerx]

If we do them the way I want to they can be very useful! Will get back to working on the draft...

[mirams]

For 4) I don't see how the reset rules for pacing can speed things up? Presumably they work with some sort of root finding, resulting in some sort of iterative scheme to find the root (time to apply the stimulus, and time to un-apply)?

Granted, if it is a Newton-Raphson root finding algorithm it should be very fast/almost exact with a linearly increasing time... But I can't see how it can be as computationally efficient or clean as just solving straight to exactly the right place, stopping and starting again (like you've been using in myokit?), which we can do easily with a normal CellML file by just looking at the stimulus oxmeta metadata annotations.

Root finding is maybe effectively what CVODE does anyway when it is set to a maxDt (oversteps, sees a big sudden I_stim and goes back to work out where it was applied), in this case perhaps a reset rule could speed it up. But that would need benchamarking.

These rules also put a big extra requirement on software for using cardiac models and you couldn't just use a generated a right-hand side any more. There are a non-negligible number of cardiac solvers getting CellML in by hook or by crook. Certainly I think us using the resets in cardiac models should be forbidden until PMR / the CellML API generates Python, C, Matlab, that can actually run simulations for models that have resets!!

[MichaelClerx]

You're right! It would be an extra requirement - but it would get rid of the max step size of 0.1 ms that we use a lot of the time now, which is informed by our knowledge of common pacing protocols rather than anything we can read from the models. So there's that

For speeding things up... We had 2 (and only 2!) common use cases for a reset rule. One was cell division where you do indeed use root finding to trigger a system parameter change. The trigger in this case is some calculated cell size variable. The second case was occasional block pulses (like you use to trigger APs). In this case the reset rule is on the free variable / variable of integration. This could speed things up because you could get rid of the max step size, since you know a priori where the discontinuities are going to be.

https://docs.google.com/document/d/1o4cOC9KOXC0b0M4Z4n1ScXBLUacNW0MhzydDyGKBOUw/edit is the latest version of the reset rule doc, I'll need to get back into this to finalise it or comment, there were a few tricky bits

That was our thinking at Harmony anyway. Happy to discuss further!

[MichaelClerx]

which we can do easily with a normal CellML file by just looking at the stimulus oxmeta metadata annotations.

This bit is particularly important. The reset rules as I'm visualising them now would make a clear distinction between "stuff that flows in the direction of the derivatives" and "stuff that we force to act funnily" e.g. the stimulus. So you don't need user annotations or spurious model inspection to tell them apart. They are separated from the outset. You get a model of the physical system, and some reset rules that show how occasionally that system is forcefully perturbed

[MichaelClerx]

Current reset rule draft allows it to be used for pacing. Remains to be seen if people want to use it that way. Closing this as out-of-scope, or possibly part of (1) implementing CellML 2.0 (see cellmlmanip) and (2) speeding things up #52