[SciPy-user] question about ODE output and time steps

[Travis Oliphant]

Rob Clewley wrote:
> Hi,
>
> I don't foresee having time to add (probably only some of) PyDSTool to
> SciPy or unless someone would graciously give me a hand. Part of that
> would involve some very specific feedback on the basic classes we've
> implemented and an evaluation of whether they are suitable for general
> usage: in particular, our Interval, Pointset, Variable, and Trajectory
> classes. 
> To bring on board PyDSTool's ODE solvers in their current
> form is also to commit to the use of these basic classes, as there's
> not a trivial way to factor out the solvers without losing some of the
> fancy functionality (e.g., having autonomous external inputs to a RHS
> interpolated from arrays). In my biased opinion, I think that these
> basic classes could add value to SciPy in general, but I'm not going
> to push it until I get a sense of sufficient support from you guys.
>   

Most of the main contributors to SciPy have been cautious 
object-oriented people.  We've got only a few limited classes but there 
is no central objection to adding classes other than my experience is 
that it is very hard to get classes that are really central enough to be 
useful in more than one domain.  

But, that doesn't preclude us from providing package-specific classes 
(which we've already done).  So, if adding these classes makes it easier 
/ faster to solve dynamical systems, then I don't think there is going 
to be any real resistance to putting them in the ODE tool chain. 

In fact, there has been lots of discussion suggesting pulling out ODE's 
from their current home in the integrate package (where they only 
loosely fit) and making say a "dynamic" module that houses several 
solution approaches to ordinary differential equations:  from simple 
wrappers around ODEPACK to full-featured class-based approaches like 
PyDSTool provides.

> Some technically-minded folks might want to help me improve our
>   
> implementations too.
>   
I could help with implementations in terms of Python-compiled language 
wrappings if that's what you mean. 
> Also, the lsodar routine already wrapped nicely in SloppyCell could
> much more easily be incorporated into SciPy with minimal baggage
> included.
>   
It sounds like this is something that we should do already.   There are 
several low-level routines with compiled code already available in the 
SciPy compiled code without a Python wrapper.  I'd like to fix this.  I 
welcome anyone who wants to do more fancy things on top.  If you want or 
need SVN access to SciPy to contribute the work just ask.  Usually, the 
changes take place in the sandbox, but we need to move lots of things 
over from the sandbox. 

I'm planning some major work on SciPy this summer (as soon as I get this 
Python buffer interface thing done for Python 3.0)
> Anyway, we haven't yet got around our ugly method for generating
> C-based right-hand-sides in a platform-independent way, which is to
> (mis-)use distutils! We hope to use auto-generated makefiles instead,
> and we have some chance of coding that up over the summer. I would
> think that would be a deal-breaker for having our integrators in
> SciPy, no?
>   
There is general interest in adapting weave so that pieces of it which 
would be helpful for this kind of work are easier to access.
> In the meantime, I would encourage anyone who writes for SciPy, has
> played with PyDSTool, and is curious about incorporating our solvers
> into SciPy, to please continue this discussion with a critical
> evaluation of our base classes (recent improvements are in our SVN
> repository). You can read more about their design and implementation
> at our wiki.
>   

Thanks for continuing the discussion. 


-Travis