[SciPy-Dev] Consensus on the future of integrate.ode
Mon Sep 9 02:37:52 CDT 2013
2013/9/8 firstname.lastname@example.org <email@example.com>
> Hello Juan Luis,
> Yes, I saw your pull request and this, in part, motivated me to start this
> discussion. Looks like you put a lot of work into your odeint modifications!
> I completely agree with you, that ode should be fixed first, then odeint
> should be a nice interface wrapped around it. integrate.ode becomes a
> package aimed at people who understand the complexities of solving ODE
> problems and integrate.odeint is for people who just want an answer.
> Also, thank you for doing a nice summary, that was really helpful.
> Remark 1: Backend.
> I don't think we need to reinvent the wheel, Benny's work looks excellent
> so I think it make sense to base a new integrate.ode off scikits.odes. It
> has a nice array of modern solvers, in both C and Fortran.
Thanks for the thumbs up.
However, odes is only one of 3 implementations, and then the one that
exposes least of the C solvers. Odes was based originally on the previous
pysundials which was no longer maintained and was a non-cython wrapper. The
other implementations are geared towards a specific problem domain though.
One is: https://github.com/casadi/casadi/wiki (LGPL tough)
The other: http://www.jmodelica.org/assimulo (annoying copyright transfer
contribution license though to a company,http://www.jmodelica.org/page/14)
The non sundials solvers in odes are also not as state of the art as some
that are added in above two interfaces.
The problem with above packages is their license and the fact that they are
packages with parsing language, ..., see eg:
Note that you can pass an array of times to sundials at which you want
output, and then all iteration is done inside sundials, so the point of
time step outside of sundials is not needed (though in many problems you'll
want to do stepping controlled in a python loop).
> Remark 2 Frontend.
> We can define a new integrate.ode interface that wraps scikits.odes. It
> seems that you already have some ideas in that area, mentioning the MATLAB
> style. I looked at the MATLAB docs just now and spend 20 minutes thinking
> how this might look if it were more pythonic. You can take a look here,
> fork your own version to make changes or add comments,
> Best wishes,
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev