[SciPy-Dev] Adding new wrappers (dassl, daspk version 2, cvode version 2.7.0) to scipy.integrate?

Johan Åkesson johan.akesson@modelon....
Thu Jun 21 17:09:16 CDT 2012


Geoff Oxberry <goxberry <at> gmail.com> writes:

> 
> I posted a feature request ticket (#1678,
http://projects.scipy.org/scipy/ticket/1678) about this on
> the SciPy Dev Wiki, and Ralf Gommers suggested that I follow up on the
scipy-dev mailing list.
> 
> To recap the gist of my ticket, there are problems for which DVODE (currently
wrapped in
> scipy.integrate.ode) are inadequate, such as in computational combustion. It
would be helpful to
> researchers in combustion to wrap updated numerical integration libraries
(such as DASSL, DASPK, and
> CVODE); DAE solver wrappers would also be very helpful (technically, DASSL and
DASPK are DAE solvers, but
> one thing at a time here).
> 
> Since some of these wrappers already exist in scikits.odes, would it be
possible to merge them into
> scipy.integrate.ode? If so, in the process, could the Sundials wrappers also
be updated to operate with
> Sundials version 2.5.0 instead of Sundials version 2.4.0? The newest version
of Sundials contains only
> minor changes to the API (a few integer arguments are changed to long integers
to accommodate larger
> problem sizes), and several bugs are fixed.
> 
> There have been many e-mails on the Sundials-users mailing list requesting a
good, well-maintained and
> supported Python interface to Sundials with a reputable institution behind it.
It looks like
> scikits.odes is the best-maintained Python interface out there, since
pysundials and python-sundials
> are no longer maintained, and the Assimulo documentation uses some
nomenclature that is nonstandard in
> numerical analysis (which makes me doubt the software). Furthermore, I know
that users in the combustion
> community, frustrated with this situation, have implemented their own wrappers
to such solvers (see for
> instance, https://github.com/jwallen/PyDAS, written by a colleague of mine).
> 
> I am willing to help with this effort after I graduate (I am in the process of
finishing my PhD) in a few months.
> 
> Geoff
> 

Hi Geoff,

I'm involved in the Assimulo development, and since Assimulo is mentioned in the
post, I'd like to contribute some comments to the discussion. I think that
Assimulo matches well the requirements mentioned in Geoff's post. The project is
backed by an environment where departments at Lund University, Sweden, (notably
the Center for Mathematical Sciences (www.maths.lth.se) and the Lund Center for
Control of Complex Systems (www.lccc.lth.se)) collaborates with Modelon, a
Lund-based company in the simulation and optimization industry. The project
benefits from a mix contributions from academic research, ensuring sound
numerics, and industrial applications, ensuring scalability to real world
problems. The institutions involved in the development are committed to long
term development and maintenance, which is one of the key differentiators to
ensure quality in OSS projects.

>From early on, the goal of the Assimulo project has been to provide an easy to
use and well documented front-end to a variety of integration algorithms – in
addition to the Sundials solvers, we recently added interfaces to Hairer's
Dopri5 and Radau codes, ODASSL and the Glimda solver. Additional solvers are
planned for inclusion in the future. There was a publication recently that talks
about Assimulo at the 2nd Joint International Conference on Multibody System
Dynamics: http://www.control.lth.se/Publication/and_etal2012imsd.html.

Through the Python-package PyFMI (www.pyfmi.org), Assimulo is conveniently
connected to a wide range of state of the art tools for physical modeling,
including AMESim, Dymola, JModelica.org, OpenModelica and SimulationX. The PyFMI
package is based on the Functional Mock-up Interface Standard
(www.fmi-standard.org), which is supported by a wide range of simulation tools.

All input on how to improve Assimulo is very welcome!

Best regards
/Johan





More information about the SciPy-Dev mailing list