[SciPy-Dev] Consensus on the future of integrate.ode

[Mario Mulansky]

> Please, please don't implement anything in the SciPy ODE solvers with Boost.
> odeint unless it's a separate interface that requires extreme generality.
> 
> Boost.odeint uses Boost.uBLAS for its linear algebra (see
> http://headmyshoulder.github.io/odeint-v2/doc/boost_numeric_odeint/concepts/
> implicit_system.html), and Boost.uBLAS is slow because it tries to be
> general (everything is templated), and it has debugging features added by
> default.
> 
> A lot of users (myself included) don't need that generality, and would
> prefer the extra performance that you'd get from a code that can use a
> faster dense linear algebra library (like an optimized LAPACK, Eigen,
> Elemental, maybe MTL4).

I agree with the concerns but I would like to note that the current 
implementation of implicit routines in Boost.odeint is preliminary. We are 
currently working on a generalization of these routines to allow the usage of 
arbitrary backends that should be done by the end of the year. However, 
Boost.odeint misses some more of the functionality of CVODE, e.g. automatic 
detection of stiffness or numerical Jacobi approximation. But I think that 
using Boost.odeint could be benefitial for scipy.odeint (e.g. parallelization) 
and we would be happy to assist scipy developers, e.g. by providing missing 
functionality, if you want to use Boost.odeint.

Best regards,

Mario