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

[Juan Luis Cano]

On 09/04/2013 06:14 PM, boyfarrell at gmail.com wrote:
> Dear list,
>
> I think it would be interesting to start a discussion regarding the direction of integrate.ode. Reading the list, there seems to be many people interested seeing improvements. Is there a roadmap for development? If not can we come to a consensus about how best to contribute to this part of scipy? I think it is fair to say that other projects have overtaken scipy in terms integrating new solvers and general development in this area. Which is a shame.
>
> Personally, speaking as a user, I would like to see the use of more modern solvers. For example the code could be updated to use CVODE. This has many improvements/fixes over the Fortran VODE solver that is currently used. This would be a nice place to start, clearly that is still a nontrivial task.
>
> Also, is there a way that developers could be encourage to contribute additional solvers? For example by making an elegant low level API that makes this easier. Moreover, say that in order for a developer to connect a new solver to scipy all that had to be done was implement a particular, well defined, interface for their wrapper. Once implemented the new solver could be called with the exciting integrate.ode interface. Has anybody got experience is such design? Surely something like this has been attempted? The GNU Scientific Library interface springs to mind as a good example, http://www.gnu.org/software/gsl/manual/html_node/Ordinary-Differential-Equations.html
>
> Finally, I have read some discussion here regarding changing the API and or unifying the odeint and ode. I don't want to get too distracted with this as my main point is outlined above. Personally the current API doesn't bother me too much, I find both easy to use. But if this is being considered for an update I think the crucial thing is to have the interface have no reliance on any particular solver. Abstraction is key.
>
> Happy to know your thoughts and if we can make a push together for some improvements in this area then all the better.

Regarding the last part, I created a PR last week with some changes to 
the odeint function, but I didn't aim to unify odeint and ode or do a 
big rework of the API. I introduced a couple of convenience changes: 
odeint objetive function has different signature than ode (one is (y, t) 
and the other is (t, y)) and some minor (but backwards incompatible) 
changes, done to solve some annoying issues that odeint has had. The 
thing is that even this little changes require a proper deprecation 
cycle to not break everyone's code too soon, so this major uplifting in 
ode/odeint must be taken very carefully.

The good thing about odeint is that it's a simple function to 
GetThingsDone™ when you just want to quickly integrate some equation. 
You just need a lambda, an initial condition and a vector of time 
values. Having to configure a solver with its options is not very 
straightforward, specially for interactive work, as Gaël Varoquaux had 
already described in a previous discussion some years ago:

http://osdir.com/ml/python-scientific-devel/2009-02/msg00042.html

(this is true for everything else IMHO, also for building splines and 
stuff like that).

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.

Juan Luis Cano