[SciPy-Dev] Consensus on the future of integrate.ode

[Juan Luis Cano]

On 09/07/2013 09:40 AM, boyfarrell at 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