[SciPy-dev] dae solvers
Fri Aug 29 04:07:41 CDT 2008
I created a patch to scipy to add support for dae solvers:
The backend I included is the netlib ddaspk.f solver.
I chose for this as I need to solve large systems and I want to keep the
speed of fortran with a minimum of overhead in python.
It should be possible to add quickly the backend lsodi based on patch
http://www.scipy.org/scipy/scipy/ticket/615 . Adding a backend to the ida
solver in sundials should also be possible based on the pysundials package
(advantage over pysundials would only be a single api definition )
Extension to add support of Krylov within ddaspk should also be easy with
Well, I can improve this (extra backend, ...) if it is considered for
inclusion in scipy, otherwise it is just a way of sharing it in the hope the
next person doesn't have to reinvent it all again.
2008/8/25 Rob Clewley <email@example.com>
> On Sun, Aug 24, 2008 at 8:18 AM, Benny Malengier
> <firstname.lastname@example.org> wrote:
> > Guess I should have googled a bit longer.
> Well, maybe a bit longer still :) There have been a couple of other
> attempts, too. For instance, you might get some joy from the wrapped
> version of Radau, which has a lighter interface and is part of a more
> python-oriented environment.
> > As this pysundials is there, I do think it should be integrated somehow
> > scipy. What use of ode class and odepack in scipy which interface old
> > vode/lsode fortran progs when pysundials exists that interfaces sundials
> > like that the new cvode and ida solvers?
> > So perhaps ode.py should obtain a backend to that? Or should scipy just
> > longer offer ode solvers...
> There has been some discussion about ode solvers in scipy recently,
> but it didn't come to much. People are still busy arguing over how to
> represent matrices properly, let alone getting in to how dynamical
> systems should be supported. Someone tried starting a new interface to
> the existing ode solvers in scipy recently, but I don't know how
> that's getting along. I think it's called pyode and on google code.
> > Well, I'm not a scipy dev, just my 2 cents. It always amazes me how many
> > duplication is going on. I'll investigate my options furter and make up
> > mind next week on how to proceed.
> I mostly agree, but it's tricky to talk about duplication. Users in
> different fields want different things from their packages, and have
> different expectations about how many dependencies they're willing to
> tolerate, how much of a GUI is supported, what kinds of application or
> data formats are supported, etc. So there end up being some conscious
> attempts to do similar things somewhat differently. And so that's not
> necessarily a bad thing.
> Scipy-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev