2013/9/23 boyfarrell@gmail.com <boyfarrell@gmail.com>
Dear list,
There was some discussion on how to improve integrate recently mostly focused around the ode solvers, http://comments.gmane.org/gmane.comp.python.scientific.devel/18150
I'll summarise the changes we want to make here,
1) Improve the interface to integrate.ode. - see the suggestion here, https://gist.github.com/danieljfarrell/6482713
2) Make integrate.odeint a functional wrapper around integrate.ode. - For the functional version we can use the MATLAB concept of 'events' to specify time points at which the solution can be exported.
3) Update the integrate.ode solvers (from Sundials via scikits.odes) - replace VODE with CVODE (a version written in C with many improvements) - add CVODES (CVODE + simultaneous corrector methods) - add IDA (similar to MATLAB's ode15s, also has the option for solving DAEs)
Points 1 and 2 are fairly standard, however point 3 generated lots of discussion i.e. do we use sundials, scikits.odes, petsc4py... as the basis of the new module? petsc4py would allow solving ODEs in parallel and has a huge array of solvers. But I think in the end it was decided that scikits.odes would be a better starting point because of the lower complexity. Plus it already wraps the Sundials suite and is actively maintained.
I don't know the events concept. Is there something like that already in scipy? Some doc? Sundials and hence scikits.odes also have event monitoring, in essence, checking when a condition is fullfilled, eg when a ball hits a wall, and return the solver at that point (as the physics and the equations will change). I think that was meant with 'events' in an earlier discussion on sundials. In sundials it is the RootFn functions. I could set-up a clone of scipy and integrate scikits.ode as best as possible. I'm leaning though to renaming scikit.odes.ode into deq, and rewriting scipy ode and odeint as wrappers around deq. Or would you break ode api fully? Seems like a world of hurt for the users of ode. The main programmer of scikit.odes (so not me, but Pavol) very much likes to circumvent the ode wrapper and instead use directly the sundials wrapped methods. To each it's own, but that does raise the question, do we consider that part of the API (so the methods ode or deq use to set up sundials problems)? Personally, I don't see problems with it, on the other hand, documentation might become confusing. Note that for all parallel solvers, the problem seems to be more the user who has to write the correct functions to drive the solver, and not so much the solver. Once we have sundials, people can contribute to use the parallel version. I'm sure some would be interested and contribute that. Note that once you integrate sundials, you obtain kinsol for free, which should be in the linalg package or accessible from the generic solve? If you ask ida to compute the initial condition, ida in essence calls kinsol, so you can solve nonlinear algebraic equations. It would be good to expose this in the correct scipy subpackage if it complements existing methods. As a final note, scikits.odes is maintained, but I have no fixed position, so as always, that can change quickly. Benny
Best wishes,
Dan _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev