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

[Geoff Oxberry]

There's also petsc4py (https://code.google.com/p/petsc4py/), which is a set
of Python bindings for the scientific library PETSc. PETSc implements a lot
of solvers, including an interface to CVODE in SUNDIALS. However, it
generally does things using sparse linear algebra, so if you want to solve
a system of ODEs using a direct linear solver, you essentially have to use
LU decomposition as a preconditioner, and pass the inverted linear system
to CVODE (which will then solve it trivially in one iteration of GMRES,
TFQMR, or BiCGStab).

There's no interface for IDA, although PETSc has a number of DAE solvers
implemented itself.

The license is BSD, and is well-maintained. I'd say the main drawbacks of
the petsc4py library are that:

- the library itself is not well-documented, but PETSc is, and the library
generally follows the PETSc interface, plus has a number of Python examples
- PETSc's a huge library, and it takes a while to get a handle on the API

PETSc and scipy are trying to do different, but related things. PETSc and
petsc4py are trying to provide a software platform for developing
computational science applications that can run on anything from desktops
with a single processor to a Blue Gene/Q with tens or hundreds of thousands
of processors.

SciPy is more geared towards rapid prototyping and computational
exploration on a single processor, so it helps to have a more intuitive
API, preferably something like MATLAB since that's so prevalent in
education, and a lot of people who use SciPy come from a MATLAB background.
Even though the licenses are compatible, I'm not sure you'd want to
incorporate elements of petsc4py into SciPy (although it would be
incredibly cool to be able to use any of their extremely long list of ODE
or DAE solvers).

Assimulo does not require you to write your ODE system in a parsing
language, though in the Python implementation of JModelica, you could
certainly do that. I used it for my thesis without too much difficulty, and
sent the authors a few feature requests. Assimulo makes assumptions about
the arguments being passed to CVODE, so you can't pass arbitrary data to
CVODE via the Assimulo interface without some kludging; they assume you're
going to pass an array of doubles, essentially. (Or at least, this was the
case 15 months ago; I have no idea if they've changed the interface.)


On Mon, Sep 9, 2013 at 3:37 AM, Benny Malengier
<benny.malengier at gmail.com>wrote:

>
>
>
> 2013/9/8 boyfarrell at gmail.com <boyfarrell at gmail.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:
> https://github.com/casadi/casadi/blob/master/examples/python/dae_single_shooting_in_30_lines.py.
>
> 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).
>
> Benny
>
>
>> 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,
>>
>> https://gist.github.com/danieljfarrell/6482713
>>
>> Best wishes,
>>
>> Dan
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Geoffrey Oxberry, Ph.D., E.I.T.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130909/95998e36/attachment.html>