[SciPy-Dev] Consensus on the future of integrate.ode
Juan Luis Cano
juanlu001@gmail....
Sat Sep 7 09:05:42 CDT 2013
On 09/07/2013 09:40 AM, boyfarrell@gmail.com wrote:
> Hello all,
>
>> Perhaps the most important thing is that someone with interest in this
>> patiently iterates with this idea, searches consensus in the mailing
>> list, write a proposal somewhere if needed, thinks about the proper
>> deprecation process with the maintainers, writes the code and, well,
>> takes responsibility of this until the very end. I guess it can take
>> some months.
> I was hoping that we have enough people that we could avoid the Rambo developer phenomenon. Besides this seems to be exactly what we have right now. What I would like to do is find is a group of people that are interested in seeing improvements and working together to fix things.
>
> Remark 1. Maybe we should set a few simple goals? For example, would people be interested in replacing vode with the cvode solver from sundials? This would be a nice improvement. What would you like to see?
>
> Remark 2. I don't understand the problem well enough to design an general new interface that solvers can be connected to. I'm not even sure is this will help. I think someone with more experience writing numerical code could architect something like this.
(I am sorry: long email ahead)
I have not been in this list for long, but as far as I can tell, the
problem is: there are two *unrelated* interfaces to integrate
differential equations. The simple one is `odeint`, which uses a
manually C-wrapped version of lsoda.f and does the iteration on the C
side, and the complex one (also in the mathematical sense) is the `ode`
class, which uses f2py generated interfaces to vode and other packages
and does the iteration in the Python side. These two have several
incompatibilities, the most silly one being the different signature of
the objective function: `odeint` expects `func(y, t)` and `ode` expects
`func(t, y)`.
So let's say we want to solve the problem of the interfaces being
unrelated. Then you would make `odeint` a simplified wrapper to the
`ode` class, providing some nice defaults to rapidly integrate an ode in
a one-liner.
Then we step on the `ode` territory: the routines it wraps are outdated
and other packages, and they probably don't see bug fixes anymore. So it
is desirable to replace these with newly developed codes, like the
mentioned sundials. Benny Malengier already created the odes scikit,
which if I understand correctly wraps sundials.
Plus, related to this replacement, it's been suggested also that we
should make the `ode` class more solver-agnostic, providing an more
unified interface for options and a MATLAB-style way of setting extra
parameters, because as Benny already pointed out in the previously
linked comment, "the scipy ode class is also too much linked to the old
vode solver". In that comment he also points out which he considers are
the main pieces for a full DE solution.
I think this is a decent summary of what we are discussing (others
please correct my mistakes and omissions).
Now my opinion is: from an API point of view, I think all these are good
things, both making odeint a wrapper to ode and simplifying and
reworking the parameters handling in the ode class.
From an implementation point of view, my only concern is: now `odeint`
iterates in a compiled language (C in current SciPy, Fortran 90 in my
pull request), whereas `ode` iterates on Python. There are C/Fortran <->
Python callbacks anyway, but while working on my `odeint` rewrite I
noticed that the Fortran iteration was ~30 % faster. If after rewriting
`ode` we keep iterating on Python and make `odeint` a wrapper around it,
we might see performance losses.
Other than that, I am not really familiarized with the state-of-the-art
differential equations solving and such low-level numerical code (just
reading lsoda.f was an enormous pain).
The reason I called for a Rambo developer here is that, at the end of
the day, both `odeint` and `ode` work decently, people use them and
probably most really don't care about this "problems". That's why we
need enough motivated people to carry the change. I ain't be that Rambo,
but definitely will help.
I hope this clarified something, apart from cluttering everybody's inbox :)
Regards
Juan Luis Cano
More information about the SciPy-Dev
mailing list