search

headmyshoulder / odeint-v2

odeint - solving ordinary differential equations in c++ v2
http://headmyshoulder.github.com/odeint-v2/
Other
340 stars 101 forks source link

Python-odeint-v2 #155

Closed delta-pi-1701 closed 7 years ago

delta-pi-1701 commented 9 years ago

Is there a wrapper for Python-Odeint-v2 ?

mariomulansky commented 9 years ago

Hi, I'm not aware of any Python bindings for odeint. However, note that there are quiet sophisticated ODE solvers available in the scipy package. The main advantage of Boost.odeint is the generality, but this is very difficult to transfer in a python binding so I'm not very convinced Python bindings for odeint make much sense.

delta-pi-1701 commented 9 years ago

Well, I was looking for an easy to use GPU based ODE solver. My system includes 250 sets of Independent systems, where each system posses 350 ODEs. Hence, the need for GPU based ODE solver !

ddemidov commented 9 years ago

It should be easy to wrap the exact solver you need with the exact GPU backend you want into a python module with help of boost.python. Then you could transparently call it from python with numpy arrays as input/output.

delta-pi-1701 commented 9 years ago

Why it has to be an exact GPU backend? boost is a generalized one !

Well, I am not so expert with c++ and python either !

mariomulansky commented 9 years ago

Last time I checked Boost.Python did not support numpy particularly well, but that was quite some ago so maybe it improved. But I agree, the best would be to write a module in C that does the ODE solving and import in python. I've had good experience with Cython, where I managed to include Boost.odeint. But to get that running with GPU compilers is a different story I suppose.

delta-pi-1701 commented 9 years ago

Can you suggest some libraries (python based) which can solve ODEs on GPU?

ddemidov commented 9 years ago

Why it has to an exact GPU backend?

Because the solver and backend are selected at compile time, and once you create a python module, you can not change those. You could also compile several options in and let the user choose among them of course.

Last time I checked Boost.Python did not support numpy particularly well.

I used it successfully with help of this package: https://github.com/mdboom/numpy-boost. See example here: https://github.com/ddemidov/amgcl/tree/master/pyamgcl.

bjodah commented 9 years ago

Sorry if this isn't the appropriate place to post, but in case someone might be interested I wrote this Python wrapper for odeint:

https://github.com/bjodah/pyodeint

It will obviously be quite slow, but I find it useful for trying things out in Python (which is easier than in C++ in my humble opinion). Note that I just got this working so there might be some bugs not caught by the test suite. Any criticism is very welcome.

mariomulansky commented 9 years ago

Hi bjodah, I like your pyodint bindings, it's a nice example how access odeint from Python. Now I'm wondering how much more difficult the interface would become if you somehow allow the rhs function to be defined in Cython as well, because this would then give you a huge performance boost and thus a clear advantage over the exisiting scipy.integrate.odeint imlementation. On the other hand, that would mean the user would have to interact with cython all the time, which decreases usability I suspect...

bjodah commented 9 years ago

I actually use this with Cython myself, i.e. I have a rhs function in C++ which is wrapped using Cython. I can then use scipy or pyodeint to call the python callbacks in the Cython generated wrapper. The overhead is actually surprisingly small (given the rhs, and jac calculations involve a large number of operations). For some problems where a very large number of steps are taken (maybe on the order of 10^6) I might suspect a Cython wrapper passing a cdef function pointer to be significantly faster, but I guess some benchmarks would be needed to be sure..

jackhall commented 8 years ago

Maybe some of you would be interested in a python library I wrote a while ago and maintain occasionally. It's not a straightforward wrapper of odeint, but it does use the odeint solvers. I used boost.python for the language interface.

Pros:

Cons:

Let me know if you like it! Nothing like having users to spur development...