Adding Boost Odeint dependency

Contributor & Development Discussion scipy
1

Hello Everyone,

I’ve been working on adding symplectic integration methods to scipy ( ENH: integrate: The case for Symplectic Solvers in ODE Solver · Issue #12690 · scipy/scipy · GitHub ). I have a fairly straightforward cython wrapper which allows users to call symplectic integration methods defined in boost odeint.

I’ve added my code to a scipy fork but am having trouble compiling it using spin build. The issue I’m running into is that there are an unknown number of dependencies for boost odeint. I’ve been adding header files that need to be included but I’m not sure if that’s the best approach.

I thought I would ask if this is a worthwhile endeavor or if this is adding too much bloat (via dependencies) to scipy for little reward. Any insight would be greatly appreciated.

Best,

Jacob

2

Hi @JacobHass8, do you have a summary of what you think is needed? I saw your boost.math PR, and had a look at odeint/CMakeLists.txt at develop · boostorg/odeint · GitHub. Adding only boost.odeint as a git submodule would probably be fine, however unlike for boost.math there’s no “standalone” build option, so it looks like even for the NO_ADAPTERS odeint build option it’d need adding 16 or so git submodules - that isn’t going to work.

If you have a WIP branch, I’d be happy to have a look.

3

I didn’t get too far on the branch because I quickly realized that there were too many header files to include. I tried running g++ -H on a minimal script which only included the 2 header files I needed. This totaled to including more than 1200+ files. It looks like odeint relies on multiple other sub-modules in boost.

I already have nice results in the boost PR so I think that I’ll press forward with that. The cython code to use the C++ function in python is actually quite small (maybe 50 lines). I think porting this to scipy should be straightforward. The main hurdle will be documentation and any additional wrapping to get the inputs/outputs into a nicer form.

4

Thanks for the context. That’s a lot of files - it probably won’t be possible to come up with a reasonable vendoring strategy for that. If it’s only a small bit of Cython code, a separate package is likely the better route to go.