[SciPy-user] PyDSTool and SciPy (general)
Thu Apr 17 00:23:29 CDT 2008
We would like to begin a discussion that should help us set the stage
for maintaining effective utilities for ODE and difference equation
models through scipy, in both the short and long term. This is the
first of two emails we are posting to the scipy list on this topic;
the second one will focus more specifically on integrating ODEs.
As some of you know, we put together the PyDSTool package a couple of
years ago while at Cornell University; our intent was to develop a
flexible platform for dynamical systems analysis and simulation,
replacing and greatly improving upon the dstool (C/TclTk-based) and
ODETools (Matlab-based) programs that had been developed under the
direction of John Guckenheimer at Cornell. As it stands now, PyDSTool
is a fully usable, reliable dynamical systems package, and we have
used it extensively in our scientific work. In terms of what we had
originally envisioned for PyDSTool when we began program design and
initial coding, our current product is a proof of concept of various
ideas about supporting dynamical systems analysis and simulation using
We are actively seeking your help in planning out and executing the
integration of some of our code base into scipy. We believe we have
several exciting features to offer the scipy community in general, and
we think that the effort of others in helping us to improve, maintain
and document our code over the longer term will be the best way to
move our project forward and benefit the most people.
Features that we believe are of interest for potential relocation as
add-ons to scipy include:
* Fast C- and Fortran-based ODE integrators for stiff and non-stiff
systems that we have interfaced in a more powerful fashion that the
existing lsoda and vode integrators in scipy (utilizing C-based vector
field callback functions rather than slower Python callback
* Event detection, autonomous external input features at the C level
for these integrators.
* Index-free trajectory classes for manipulating multi-dimensional
time series in a mathematically natural way.
* Support for "hybrid" discrete and smooth dynamics, e.g. as used in
control theory applications.
* Bifurcation analysis tools (PyCont, and its interface to AUTO).
* Model manipulation classes built over symbolic expression
processing, which is particularly useful for model inference
algorithms or building large, structured models from smaller
* Prototype classes associated with numerical phase-plane analysis
(fixed points, nullclines, periodic orbits, manifolds, etc.).
* Some data analysis algorithms (esp. our pointwise dimension
estimation code recently published in IEEE TBME).
(More details about PyDSTool's features can be found on our wiki
We also have noticed recent developments in the scientific python
community of relevance to our project goals, including advances in CAS
symbolic processing with SymPy, optimization with OpenOpt and other
potentially interesting tools like Spyke for python-to-C
compilation. While some of PyDSTool's design and its high level
classes are focused specifically towards facilitating data-driven
modeling for dynamical systems, and symbolic manipulations, it seems
worthwhile to explore moving our support for the underlying machinery
to these other projects.
We have reached a stage in both our code development and our
professional situations where we need to make decisions regarding
PyDSTool's future carefully. PyDSTool is (uniquely) useful to us on a
daily basis, and it has a small base of active users, but it would
require substantial refactoring and redesign to reach its potential as
a dynamical systems package that is also broadly accessible and useful to
a wider audience. At the same time, having moved onto faculty/post-doc
positions, we have less time and energy available for coding work on
the core parts of PyDSTool. We do have increasing opportunities for
supporting such work through grant funding, and have already obtained
some funding to help pay for small technical developments for PyDSTool
by third parties.
We recognize that we will need to put in effort ourselves in order to
advocate, educate, and refactor our designs and code for use in
scipy. In the past, we have heard people's interest in some of our
ideas, and would like to hear from those people again. We'd like the
community's suggestions as to how we might proceed with choosing
features to cross into a scikit (for instance), and whether anyone
might be interested in helping us do that (we have not yet studied
existing scikits or followed debate on the mailing lists about setting
We are inspired by the apparent success of taking the early sketches
that were SymPy (a year or more ago) to the masses and turning it into
a very promising and strongly featured package. We would like to use
our time, energy and (perhaps) money wisely over the coming year or
two to make the most of what we've already achieved with PyDSTool.
Robert H. Clewley, Ph. D.
Department of Mathematics and Statistics
Georgia State University
720 COE, 30 Pryor St
Atlanta, GA 30303, USA
tel: 404-413-6420 fax: 404-651-2246
More information about the SciPy-user