rclewley at cam.cornell.edu
Tue Feb 7 14:01:02 CST 2006
Alan, to answer your questions:
1. I don't think there's any such destiny :) ... inasmuch as we haven't
presumed that our libraries would be considered either useful or
well-written enough to be brought into the SciPy fold. Our classes are
still effectively prototypes, and I would not like to get roasted for
trying to integrate them into SciPy without a lot more time (and probably
outside help) to get them up to scratch.
Now that we have shown proof-of-concept with some of our constructs, such
as a Pointset, and some of the symbolic expression stuff, I expect that
these could be broadly useful to scientific users in general. But I
personally don't have much time to be a coder any more. If someone wanted
to help me and/or give me feedback on what might be of use to SciPy users
then perhaps I'll be less hesitant.
2. In short, no. It was a quick fix when we were trying to get any
available integrator running with our core libraries, in order to test out
our ideas for wrapped integrators in our simulation environment.
Other Python developers here at Cornell (Chris Myers, Jim Sethna, Ryan
Gutenkunst, and others of the SloppyCell group) have used and adapted
SciPy's LSODE solver in their package, and we have discussed the relative
merits of trying to improve SciPy's support of dynamical systems through
our "fancier" ODE solver interfaces.
Apart from a lack of time on our part to invest in maintaining
publicly-releasable code, the other issue with PyDSTool is that users
would have to invest in our basic classes to work with our wrapped
integrators. Even though the UI permits very easy specification of ODE
right-hand sides and other options, I am nevertheless worried that
users may find the extra baggage of our Pointset, Generator, and
Trajectory classes too much to just solve small ODE systems with minimal
fuss. I guess I'd like to hear feedback about that stuff. We have lots of
working demos in the download for people to try out....
My collaborator, Erik Sherwood, writes the PyDSTool SWIG interfaces and
the C or Fortran wrappers to legacy ODE integrator codes. His ODE solver
classes are themselves wrapped inside those of PyDSTool, and as such his
python interface is more along the lines of the present SciPy ODE solvers
(input and output is with Numarray arrays, not my bells-and-whistles
Trajectory classes). Perhaps that would be the way to go in the short
term. Certainly, he has done great work in wrapping high-end solvers like
Hairer & Wanner's Dopri 853 and Radau 5 codes to work in Python, which
could be very useful for SciPy users. He has even added support for
user-defined events and non-constant mass-matrix support in Radau, among
other useful extensions. He is in the process of adding more H&W
integrators that use the same interface style. But you'd have to ask him
if he'd like to be responsible for maintaining SciPy-released code!
Of course, the neat thing I think about PyDSTool wrapping these legacy
integrators is that it doesn't require the user to write any actual _code_
in order to get super-fast ODE integration of C vector fields (Cf.
VODE which uses python function callbacks for the right-hand sides). We
use distutils to compile a DLL on the fly, which contains the v.f. and an
instance of the integrator. This is automatically generated and reloaded
Last, but far from least, we have not yet migrated to new SciPy, so that
would also be a sticking point. Our code uses a mixture of numarray and
old SciPy array functions and classes, and needs some work to port that
stuff to the new SciPy. Don't know when that will happen....
Sorry for the long post, but often the shortest questions require the
On Tue, 7 Feb 2006, Alan G Isaac wrote:
> 1. Is PyDSTool destined to be part of SciPy? This seems
> like a good idea ...
> 2. Was PyDSTool's scipy_ode.py forked from SciPy's ode.py
> for any reason other than lack of communication?
> Alan Isaac
> PS The note in scipy_ode.py reads::
> # This is a trivially-adapted version of the original
> SciPy integrate code.
> # Changes: (1) removed the annoying print statement whenever
> # the ODE code is 'found', which is unwanted screen output during
> # computations.
> # (2) Made ode a new-style class.
> # (3) Changed a lambda occurrence in one of the methods to use noneFn instead.
> SciPy-user mailing list
> SciPy-user at scipy.net
Department of Mathematics
and Center for Applied Mathematics
Ithaca, NY 14853
More information about the SciPy-user