Consensus on the future of integrate.ode
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
participants (1)
-
Mario Mulansky