dense output support

[berceanu]

I would like to know if dense output, in particular for ode45, is in the works or not.
If not, I could give it a try, however

1. i do not know if the current codebase will not change completely due to the GPL licensing (what are the plans?)
2. i do not know if dense output can be integrated nicely into the existing routines, or a rewrite is anyhow in order

[ivarne]

What do you mean by dense output?

If you want a matrix of the solution vectors you can use hcat(sol...)

[acroy]

@berceanu : AFAIK no one is working on dense output, but it would be a nice feature. It might be that we will replace the current oderkf by something evolving from #33, but I would think that a dense output routine should be very similar for both cases. Eventually, we probably want to have a separate DOPRI5 routine (which might find its way into Base and for which dense output is very efficient) and a routine like the current oderkf, which can handle different RK-triples.

@ivarne : Dense output refers to interpolation methods which give the solution between two integration steps. For example, within DOPRI5 this can be done without additional evaluations of the RHS.

[berceanu]

So are you suggesting to implement a stand-along dense output routine, which could then be called by the current oderkf and the future DOPRI5? Or will it be part of the DOPRI5 (like in the Hairer code)?

[acroy]

For DOPRI5 it might make sense to integrate the dense output into the routine, but since we don't have a dedicated DOPRI5 solver now, I would start with something that can be used with oderkf. (If DOPRI5 makes it into Base we would anyways need separate implementations.)

[tomasaschan]

(Isn't there a long-time goal to get all the functionality in this package into Base, once the API is stable and the code is well-tested?)

[ivarne]

It should at least have a fair chance of being included in the standard distribution as a default package.

[berceanu]

@acroy I guess that by "something that can be used with oderkf" you mean changing oderkf itself, since the dense output would need partial results from the runge kutta integration at each time step.

[acroy]

Yes, I guess you will have to modify oderkf. Maybe one can nevertheless put
most of the code into a separate function? And it should ideally work for
different RK-triples.

On Friday, June 20, 2014, berceanu notifications@github.com wrote:

@acroy https://github.com/acroy I guess that by "something that can be
used with oderkf" you mean changing oderkf itself, since the dense output
would need partial results from the runge kutta integration at each time
step.

—
Reply to this email directly or view it on GitHub
#40 (comment).

[berceanu]

I wrote some notes on implementing dense output here: http://nbviewer.ipython.org/github/berceanu/notebooks/blob/master/julia/dense_output.ipynb
Unfortunately as there is no support for MathJax in Github (at least as far as I know), I could not do a PR on the wiki. Anyway, looking forward for your feedback.

[berceanu]

For the API details on dense output, see #44

[tomasaschan]

Having read your notebook again, I'm beginning to get the feeling that a solver with dense output is something a user would want when the workflow is to first solve the ODE problem, and then find the solution at some specific points, which are not necessarily known at the time of solving. In other words, the output from a solver with dense output support, whatever type of object(s) we return, somehow needs to support a posteriori evaluation anywhere on the timeline.

Since this is extra work which we don't want to do if the user doesn't explicitly ask for it, I think we should probably do it entirely separate from the current oderkf implementation. (We want the dense output to be calculated "along the way", and the solution returned as a "dense type", which will break type stability).

Since dopri5 does intrinsically support this, maybe we could start by adding an implementation of that, with some smart output format? Then we could generalize from there, e.g. to other RK methods and/or cases that need extra rhs evaluations.

[berceanu]

dopri5 is nothing but our beloved oderkf using the Dormand-Prince set of coefficients, and with dense output integrated. i see no convincing reason to port it at this point.

about the usage cases, dense output can for instance be useful in case of an event function. imagine one want to integrate until one has g(t, x(t)) = 0 for some user-defined g. an example could be, when solving an periodic astrophysics problem, stopping after one complete period.
for me personally, its useful because i would like to do an FFT of the returned x(t) values, so they have to be on an evenly spaced grid in time. also, i do not want to store all the xout values, for each step, since they will be complex matrices of dimension 2x1024x1024.

about breaking type stability, im not sure i get why that would be. for theta = 1 (using the notation in my notebook) one recoveres the original time-steps taken by the solver. for theta between 0 and 1 one gets more output, in between those original points, but the return type would always be the same as the type of x0. am i missing something?

[tomasaschan]

I might have misunderstood how dense output usually works, but my impression of how it is as useful as possible, is if it is possible to do something like this:

tout, yout = odedense(F, x0, tspan)

and then evaluate the solution in any point (t,y) simply by evaluating yout[t], for any t between extrema(tspan), and not just for any t in tout (or, as it is today, an index). For example, this means that I can first solve the problem, then examine some part of the solution, and then decide to evaluate the solution at some other place, which was impossible to determine before the call to the solver.

If this functionality is to go in oderkf, one of two things must happen: either we always calculate the interpolation for dense output, and return a type that supports it (meaning extra work and lost performance for most use cases) or we calculate dense output only when the user has explicitly requested it, but then we have to sacrifice type stability, since regular arrays can never support dense output as I've outlined it above.

If, on the other hand, the API is to be more or less the same as for some step-limiting dense output-like feature, requiring the user to specify all the points for dense output up front when calling the solver, then this won't be a problem. But I imagine dense output is much less useful that way...