[SciPy-Dev] Scipy 1.0 roadmap - integrate

Benny Malengier benny.malengier@gmail....
Mon Sep 23 08:17:55 CDT 2013

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.


> Best wishes,
> Dan
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20130923/c07b6d3d/attachment.html 

More information about the SciPy-Dev mailing list