As co-author of scikits.odes, let me mention some things. Sundials has been wrapped a lot in 2011. Not only by my group, but also others. The main ones are:<br><br>1. <a href="https://openmodelica.org/">https://openmodelica.org/</a> The author of python-sundials <a href="%28http://code.google.com/p/python-sundials/">(http://code.google.com/p/python-sundials/</a>) uses that now, so this last probably will not be further developed<br>
<br>2. <a href="http://www.jmodelica.org/assimulo" target="_top" rel="nofollow">http://www.jmodelica.org/assimulo</a> Very extensive and good bindings. It is however more high-level.<br><br>These two are targeted for use with modelica compiler, but work outside too using their api.<br>
<br>3. <a href="http://pysundials.sourceforge.net" target="_top" rel="nofollow">http://pysundials.sourceforge.net</a>  Not developed at the moment. I contributed some patches there, but they are happy with the current code, and concentrate on what they model. No time/funds to keep working on it.<br>
<br>4. our own scikit.odes. Very low level 1-1 mapping of sundials, combined with a higher level API to quickly start solving a problem. It was nice to work on that, now we use it is our models. Also for us, funding and time are uncertain in the near future. Our use case is solving PDE using method of lines (ODE), which is why we are not 100% happy with the approaches that come from other fields.<br>
<br>5. CasADi, <a href="http://sourceforge.net/apps/trac/casadi/">http://sourceforge.net/apps/trac/casadi/</a><br><br>6. DAE Tools, <a href="http://daetools.sourceforge.net/w/index.php/Main_Page">http://daetools.sourceforge.net/w/index.php/Main_Page</a> by using pyDAE<br>
<br>My main problem is that using some of these gives a full simulation environment, which is for many people much more than what you want. As a consequence, they are daunting for a master thesis student or somebody else less into modelling to use for his problem. <br>
<br>Integration of sundials in scipy in some way with a basic interface would solve that.<br><br>Benny<br><br><div class="gmail_quote">2012/6/20 Geoff Oxberry <span dir="ltr">&lt;<a href="mailto:goxberry@gmail.com" target="_blank">goxberry@gmail.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Claus,<br>
<br>
What made me skittish about the API documentation of Assimulo is when you describe the CVODE in the &quot;Documentation contents&quot; page of your documentation (<a href="http://www.jmodelica.org/assimulo" target="_blank">http://www.jmodelica.org/assimulo</a>) as an &quot;explicit solver&quot;. That, to me, seemed &quot;non-standard&quot;.<br>

<br>
After an initial moment of confusion, I realized that you were instead talking about explicit ordinary differential equations, not explicit methods for integrating ODEs. (I believe my comments on the Trac Ticket reflect this.) As someone who&#39;s seen enough software thrown out there by people who either don&#39;t maintain it, or don&#39;t document it, I get very skeptical when I see something that looks out of place in documentation. Anyone who jumps to the Assimulo home page will immediately realize the distinction you&#39;re making; I just happened to type in &quot;assimulo documentation&quot; because I had already been recommended the package by a user on Computational Science Stack Exchange (of which I am a moderator).<br>

<br>
When I downloaded your project to compile the Trac ticket report, I did notice that your project is among the more actively maintained wrappers of Sundials out there, and receiving an e-mail from you is a pleasant surprise. I also appreciate that your project has documentation. Of the six wrappers to Sundials or DASSL that I know of out there, Assimulo looks like it&#39;s the best documented.<br>

<br>
Recently, I attempted to integrate a stiff system of ODEs derived from the GRI-Mech 3.0 combustion chemistry model with DVODE, varying the absolute tolerances from 1e-9 to 1e-20 and the relative tolerances from 1e-6 to 1e-15. For whatever reason, I don&#39;t obtain the expected solution behavior, but I do obtain the expected solution behavior with the MATLAB wrapper to CVODE, and I also obtain this behavior with a modified version of DASSL (that simulation was programmed in Fortran 90). Perhaps I should give Assimulo&#39;s wrapper a try, especially since I&#39;ve found that IDA tends to work well on my problems also.<br>

<br>
That said, I still believe that DVODE in scipy.integrate should be supplemented (or even replaced) by CVODE. DVODE has had a long history of successful use in combustion chemistry, but CVODE, DASSL, DASPK, and IDA seem to have superior stepping heuristics for these sorts of problems, based on my 5 or so years of experience working on them.<br>

<br>
Thank you for your response,<br>
<br>
Geoff<br>
_______________________________________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@scipy.org">SciPy-Dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/scipy-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/scipy-dev</a><br>
</blockquote></div><br>