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

boyfarrell@gmai... boyfarrell@gmai...
Wed Sep 4 11:14:44 CDT 2013


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.

Best regard,

Dan


More information about the SciPy-Dev mailing list