Event functions

[tomasaschan]

For some problems, it is interesting to run the solver until something happens - specified by (part of) the solution at that point. In those cases, it can be hard to know on beforehand exactly when this happens, so it's difficult to give an upper limit to the solution domain.

For example, think about a program modelling a bouncing ball: it's just solving F = ma for a free-falling object, except every time the ball hits the floor, we want to change sign of the y-component of its velocity. Without event functions, one has to solve for one parabola at a time, obtain the final components of the velocity, change the sign and use as initial values for the next - with them, one can let the solver do the work.

It could also be nice to be able to stop the simulation when some condition is met, rather than after a final time - for a system that you expect to stabilize but you don't know how long it's going to take, you can then stop when the rate of change in the solution is small enough.

Basically, the solvers should support some way of saying every time X happens, do Y where Y can be anything from changing some part of the problem to stopping the solver. As noted in #7 it could also be interesting to support only emitting solution points when some condition is met, which could also be specified by an event function.

What is a good way of implementing this in the current solvers? What should the user interface look like?

[stevengj]

Changing the problem as a function of the solution can already be accomplished in the ODE callback function, unless I am misunderstanding you.

To halt the solver, maybe the ODE callback could throw some special exception?

[tomasaschan]

Yeah - you're probably right. Changing the problem along the way can be accomplished without this.

Throwing an exception to halt the solver seems like a code smell to me - it's not really an error as such. I'd rather have the ODE callback return some special symbol, but that would be harmful for performance since it's return type wouldn't be fixed... It also wouldn't work if we want the event function to specify when to output solution points, but not halt the solver - that depends on the ODE callback returning as usual, but something else gets evaluated too.

Maybe we could have a keyword argument event that takes a function g(t, y) which returns either :halt, :out (to output solution, but probably with a better name) or :donothing (also with a better name), that gets evaluated once at the end of each iteration?

[stevengj]

Premature termination seems like an exception to me...

I'd prefer not to have to write two callback functions when one will do, especially since the termination criteria may depend on internal state of the dx/dt callback.

[tomasaschan]

"Premature" is probably a bad term for what I'm trying to get at - I'm rather looking for cases when it is not possible to state the end time in advance.

[acroy]

I would also say that exceptions provide a clean way to terminate the solver. However, I am not sure that triggering events in the dx/dt callback is a good idea. Firstly, because one only gets local information (x and dx/dt at the current time) and secondly, because one does not know in which context the function was called. For instance, one cannot know whether the time-step will actually be accepted or not and why the solver actually called the function. The locality might be a problem if one wants to check if a given function of x and/or dx/dt is passing through zero during the integration step (this is basically how events work in MATLAB).

[ivarne]

Maybe not directly on topic, but I have sometimes wanted to have some means of telling the solver to reduce the step size if some of the integrated properties is out of bounds. If i know that all values in the x vector will be positive it would be nice if I could throw an exception (ReduceStepSizeException?) if the algorithm overshoots and tries with a negative value.

[sglyon]

Any update on this? Does anyone have a working example of using callbacks to emulate the events functionality of Matlab?

[mauro3]

I don't think so. The new RK solvers have dense output (although only 3rd order polynomials). This could then be used to detect events.

[sglyon]

I needed this, so I implemented a routine that uses any integrator in ODE.jl. The routine is in this gist

I'm quite positive this is one of the most inefficient ways of doing it, but it works for my needs right now and I thought I'd share.

[acroy]

Since it just came up in #33: At some point I suggested a simple way to have a progress callback for Sundials, which might in principle also work for our purposes?