Hi, I proposed a library for solving ordinary differential equations some months ago. Since this time, we have worked a lot on this topic and we would like to start a discussion about the needs and the design of the library. The library odeint ("odeint" comes from integration of ordinary differential equations ) can be found in the sandbox and some preliminary documentation is also available: http://svn.boost.org/svn/boost/sandbox/odeint/ http://svn.boost.org/svn/boost/sandbox/odeint/libs/numeric/odeint/doc/html/i... One of our main aims is the independence on a specific container or array type, such that the library can work with ODEs defined on arbitrary topologies, like networks, lattices , grids, etc. So, any comments on this library are highly welcome, as well as contributions (of any kind). Best regards, Karsten
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Karsten Ahnert Sent: Monday, July 05, 2010 4:04 PM To: boost@lists.boost.org Subject: [boost] library proposal : odeint
I proposed a library for solving ordinary differential equations some months ago. Since this time, we have worked a lot on this topic and we would like to start a discussion about the needs and the design of the library.
The library odeint ("odeint" comes from integration of ordinary differential equations ) can be found in the sandbox and some preliminary documentation is also available:
http://svn.boost.org/svn/boost/sandbox/odeint/ http://svn.boost.org/svn/boost/sandbox/odeint/libs/numeric/odeint/doc/html/i...
One of our main aims is the independence on a specific container or array type, such that the library can work with ODEs defined on arbitrary topologies, like networks, lattices , grids, etc.
So, any comments on this library are highly welcome.
For those interested in integration of ordinary differential equations this looks most promising, and the docs also look in good shape (with only a few typos, but some missing links to code snippets?). But any differential equations are a niche market and I suspect that few Boosters currently tracking the list are expert in this field (not me ;-). Do not let the absence of immediate enthusiasm put you off, but building a group of users who find it useful (and have some expertise in this field) would be good. Putting this in the sandbox is a good start signalling some maturity. I have one question - have you considered if your library will 'play nicely' with the Boost.Units library? If it will, the units error detection and convenience of output with units, would seem to make it much more attractive. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
just a hint for developers think about the so called "dense output" methods e.g. you want to get solution on a grid of 100 points but in fact a stepper does not always need to do 100 steps to produce the desired figures a frequent case may be that a stepper makes say 42 steps to reach the end point maintaining given accuracy and produces the solution on the grid points by some special means (a variant of interpolation) there is an item on this topic in the book "numerical recipes 3rd ed." 17.2.2 Dense Output (p.915) good luck -- Pavel
On 07/09/2010 05:35 PM, DE wrote:
just a hint for developers think about the so called "dense output" methods e.g. you want to get solution on a grid of 100 points but in fact a stepper does not always need to do 100 steps to produce the desired figures a frequent case may be that a stepper makes say 42 steps to reach the end point maintaining given accuracy and produces the solution on the grid points by some special means (a variant of interpolation) there is an item on this topic in the book "numerical recipes 3rd ed." 17.2.2 Dense Output (p.915)
Thanks for this hint. I think just that you mentioned this we will include some steppers with dense output, they are in fact very nice. We have tought in an earlier stage of this library about including them. But we droped that idea, because there exist only a few steppers which provide a output function and this concept can not be applied to all steppers in general. Karsten
Hi Paul, thanks for your comments and hints:
For those interested in integration of ordinary differential equations this looks most promising, and the docs also look in good shape (with only a few typos, but some missing links to code snippets?).
The docs are still preliminary and some of work has surely to be done (especially the reference is still missing).
But any differential equations are a niche market and I suspect that few Boosters currently tracking the list are expert in this field (not me ;-).
I think that ODEs are quite basic objects in physics, mathematics, etc with huge ranges of applications.
I have one question - have you considered if your library will 'play nicely' with the Boost.Units library? If it will, the units error detection and convenience of output with units, would seem to make it much more attractive.
At the moment it is not possible to use Boost.Units. We are redesigning the library and it might be possible to enable Boost.Units at some point. But I suspect, that Boost.Units will not work in general with odeint. I can go in details if you like. Karsten
On 9 Jul 2010, at 15:46, Karsten Ahnert wrote:
I have one question - have you considered if your library will 'play nicely' with the Boost.Units library? If it will, the units error detection and convenience of output with units, would seem to make it much more attractive.
At the moment it is not possible to use Boost.Units. We are redesigning the library and it might be possible to enable Boost.Units at some point. But I suspect, that Boost.Units will not work in general with odeint. I can go in details if you like.
I would be very interested in why it would not work with Boost.Units since I might be interested in using such a library with my own datatypes instead of double or std::complex<double> Matthias
I would be very interested in why it would not work with Boost.Units since I might be interested in using such a library with my own datatypes instead of double or std::complex<double>
If you want to use Boost.Units the system function has to work on different types, for example: harmonic_oscillator( StateType , DerivType , TimeType ) The units have to obey [DerivType] = [StateType] / [TimeType]. This condition is not a problem for the explicit Runge-Kutta solvers. But if you want to use some implicit methods you are usually faced with some matrix inversion routines. In this case the state type has the restrictions to work with appropriate LA functions. I doubt that it will be possible to get this working with Boost.Units. Another problem might be that every entry in the state vector could have a different dimension, although this might be solved by using fusion vectors or something similar. If there is a strong interest in Boost.Units we could try to include them for some specific steppers in the next version. But in my opinion this is not that important. If you want to use your own datatypes you can try to specialize the container_traits. At the moment we are working on a small redesign of the library allowing for an stronger independence of the underlying types. One goal is for example to get the library working with thrust to enable CUDA support (http://code.google.com/p/thrust/). What kind of datatypes do you have in mind? Maybe we can try to get this library working with your types, too. Best regards, Karsten
On Sunday 11 July 2010 06:26:22 Matthias Troyer wrote:
On 9 Jul 2010, at 15:46, Karsten Ahnert wrote:
I have one question - have you considered if your library will 'play nicely' with the Boost.Units library? If it will, the units error detection and convenience of output with units, would seem to make it much more attractive.
At the moment it is not possible to use Boost.Units. We are redesigning the library and it might be possible to enable Boost.Units at some point. But I suspect, that Boost.Units will not work in general with odeint. I can go in details if you like.
I would be very interested in why it would not work with Boost.Units since I might be interested in using such a library with my own datatypes instead of double or std::complex<double>
Using your own integral types, e.g. vector< my_double >, should be possible, as long as standard operators ( + , * , += , *= ... ) are defined for my_double. For steppers with error control, also max, abs and pow functions are required for your data type. If you encounter a problem please let us know. For using Boost.Units, the types for state vector and derivative vector are different, as Karsten also pointed out. This is not supported currently, but might be possible. Things get more complicated when one thinks about using different units for different entries of the state vector - as Karsten said. My very personal opinion is that the effort to support Boost.Units exceeds the outcome. Before addressing an ODE numerically, one should always transform to dimensionless equations anyways so I see only little benefits from Boost.Units here. However, using own data types is exactly what this library is designed for so we appreciate any feedback on this. Best regards, Mario
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Troyer Sent: Sunday, July 11, 2010 5:26 AM To: boost@lists.boost.org Subject: Re: [boost] library proposal : odeint
On 9 Jul 2010, at 15:46, Karsten Ahnert wrote:
I have one question - have you considered if your library will 'play nicely' with the Boost.Units library? If it
will,
the units error detection and convenience of output with units, would seem to make it much more attractive.
At the moment it is not possible to use Boost.Units. We are redesigning the library and it might be possible to enable Boost.Units at some point. But I suspect, that Boost.Units will not work in general with odeint. I can go in details if you like.
I would be very interested in why it would not work with Boost.Units since I might be interested in using such a library with my own datatypes instead of double or std::complex<double>
I have also have some interest in using a user defined 'uncertain type' - one that includes not just a value but also an uncertainty - a sort of 'plus or minus' (and calculation operators propagate the uncertainties). Can you see any reason why it would not work with a user-defined type like that? (Leaving aside downsides like much longer compute time). But perhaps there are other better ways of estimating uncertainties of the final result? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
I have also have some interest in using a user defined 'uncertain type' - one that includes not just a value but also an uncertainty - a sort of 'plus or minus' (and calculation operators propagate the uncertainties).
Can you see any reason why it would not work with a user-defined type like that?
(Leaving aside downsides like much longer compute time).
As long as the (+,+=,...) are defined everything should work. You can have a look at the solar system example where a point type is defined.
But perhaps there are other better ways of estimating uncertainties of the final result?
Hmm, what people usually do it to integrate the linear perturbations of the systems. In this way one gets a huge amount of informations about the dynamics, i.e. is it chaotic, regular, dissipative... ( have a look for Lyapunov exponents for example). Any perturbation will converge quickly to the most unstable direction. If you like I can give you an example how to integrate the linear perturbations. Best regards, Karsten
So, any comments on this library are highly welcome, as well as contributions (of any kind).
Best regards,
Karsten
Hello Karsten, I have a comment: I think that it would be very beneficial to discuss specific, modern applications of your odeint library on the documentation pages, preferably the applications for which you originally wrote the library. I feel as Paul does that differential equations are a tool for very specific problems, and probably few Boosters have the opportunity to work on applications that use ODEs. Consequently, I think that the lack of immediate feedback is more due to a lack of experience with ODE solving rather than a feeling that ODEs are unimportant (they're not!). I am very interested to see where this goes because you never know when that perfect use for a high-quality, generic ODE integration library will come along. Please keep the list informed. Daniel
I have a comment: I think that it would be very beneficial to discuss specific, modern applications of your odeint library on the documentation pages, preferably the applications for which you originally wrote the library.
Yes, this is a good idea. I could imagine for example a network of oscillators where some kind of a phase transition can be observed, or some discretizations of partial differential equations.
I feel as Paul does that differential equations are a tool for very specific problems, and probably few Boosters have the opportunity to work on applications that use ODEs. Consequently, I think that the lack of immediate feedback is more due to a lack of experience with ODE solving rather than a feeling that ODEs are unimportant (they're not!).
I think you both are right. But I also believe that there is a market for this library. Best regards, Karsten
Hello. My name is Zachary Vance. I am a very young boost member -- I've never worked on anything. Is there something useful for me to work on?
AMDG Zachary Vance wrote:
Hello. My name is Zachary Vance. I am a very young boost member -- I've never worked on anything. Is there something useful for me to work on?
Take a look at the open tickets in trac (http://svn.boost.org/). In Christ, Steven Watanabe P.S. Please don't reply to an unrelated thread.
participants (8)
-
Daniel Trebbien -
DE -
Karsten Ahnert -
Mario Mulansky -
Matthias Troyer -
Paul A. Bristow -
Steven Watanabe -
Zachary Vance