Le mardi 14 août 2012 à 21:21 +0200, Ralf Gommers a écrit :

On Sun, Aug 12, 2012, Fabrice Silva silva@lma.cnrs-mrs.fr wrote: I made a pull request [1] to integrate the LSODA solver that is used in odeint into the modular scipy.integrate.ode generic class. In a similar way as for vode, it just wraps the already present lsoda.f file (see .pyf file) and exposes it within an IntegratorBase subclass adjusting the coefficients before calling lsoda.

Does that mean that odeint can be made a wrapper around lsoda and that the odepack static extension can be completely removed?

Hi Ralf, The pull request allows to run the integration using the object-oriented interface ode, with the same solver than the odeint interface uses, i.e. lsoda, extending the integrators available for the object-oriented interface.

As I understand the scipy.integrate architecture, we are by now building: * the odepack library, which has all the fortran sources required by lsoda and vode at least. * the _odepack extension, which defines the _odepack module needed by odeint.

This latter would be removable, and odeint a wrapper around the lsoda pyf'ed function. I suppose you are talking about the _odepack extension, am I wrong?

Le mercredi 15 août 2012 à 20:54 +0200, Ralf Gommers a écrit :

I was mixing it up a bit, but yes: the _odepack extension and the C source for it. Not necessary to do that at once I guess, but wrapping the same function twice is once too many.

And forgot in my first email: nice PR, looks good to me.

OK then, you can found two commits :

the first one removes the _odepack extension (and the relative multipack.h, __odepack.h and _odepackmodule.c), replacing it by Python counterparts in the odeint function itself. https://github.com/FabricioS/scipy/commit/02e8a4856f29f4ad438fef2c86a41b266d...

the second one suggests reverting callback arguments convention: ydot = f(y,t,..) to ode's one: ydot = f(t,y,..) This ones would raise backward compatibility issues but align ordering to the convention defined in the LLNL when designing the ODEPACK. https://github.com/FabricioS/scipy/commit/f867f2b8133d3f6ea47d449bd760a77a7c...

Le lundi 20 août 2012 à 22:04 +0200, Ralf Gommers a écrit :

https://github.com/FabricioS/scipy/commit/f867f2b8133d3f6ea47d449bd760a77a7c...

This is probably not worth the cost for existing users imho. It is a backwards compatibility break that doesn't really add anything except for some consistency (right?).

Hi Ralf, Ok concerning this point.

In addition, I have been looking to suggest additional solvers, essentially simpler scheme, that would thus allow to easily switch between "complex" (lsode, vode, cvode) and basic schemes (Euler, Nicholson, etc...)

I came across some code on the Montana Univ.'s Computer Science dpt: http://wiki.cs.umt.edu/classes/cs477/index.php/Creating_ODE_Solver_Objects and asked Jesse Johnson (the responsible for that class) what is the license for that code. Here is his answer :

Any thing that you find on those pages, you may use. However, I'm not sure how to go about officially giving the code a particular license. Can I add a license to the wiki, stating that it applies to all the code therein?

PS It is fantastic you're doing this. I've often thought that scipy.ode could use some improvements.

He is cc'ed of this mail, could anyone concerned about scipy license requirements and more generally in code licensing answer him ?

Regards