[SciPy-dev] dae solvers
Fri Aug 29 04:14:11 CDT 2008
On Fri, 29 Aug 2008 11:07:41 +0200
"Benny Malengier" <firstname.lastname@example.org> wrote:
> I created a patch to scipy to add support for dae
> The backend I included is the netlib ddaspk.f solver.
You might be interested in
> 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
> (advantage over pysundials would only be a single api
> Extension to add support of Krylov within ddaspk should
>also be easy with
> some overloading.
> Well, I can improve this (extra backend, ...) if it is
> 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
>> 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
>> > scipy. What use of ode class and odepack in scipy
>>which interface old
>> > vode/lsode fortran progs when pysundials exists that
>> > 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
>> but it didn't come to much. People are still busy
>>arguing over how to
>> represent matrices properly, let alone getting in to how
>> systems should be supported. Someone tried starting a
>>new interface to
>> the existing ode solvers in scipy recently, but I don't
>> that's getting along. I think it's called pyode and on
>> > 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
>> data formats are supported, etc. So there end up being
>> attempts to do similar things somewhat differently. And
>>so that's not
>> necessarily a bad thing.
>> Scipy-dev mailing list
More information about the Scipy-dev