[odeint] GSoC Summary and Feedback request
Hi, this is a summary of the progress of the odeint-library during this years GSoC. First of all I would like to thank Andrew for mentoring this project and also for the many fruitful comments and hints he gave during the past months. The aim of the project was to finalize odeint and prepare it for a boost review. This goal has been, more or less, achieved, I think. Although some work on docs and maybe some minor usability improvements are to be done we think we have reached a state of development ready for a review and we might try take this step in the near future. The puropose of odeint is to provide algorithms to numerically solve ordinary differential equations (ODEs) given as initial value problems: x'(t) = f(x,t) , x(0) = x0. It is written by Karsten Ahnert and myself. Please visit the docs to find out more about the features and abilities of odeint: http://headmyshoulder.github.com/odeint-v2/doc/index.html During the GSoC project, we switched from a svn branch in the boost sandbox to a new git project called odeint-v2: https://github.com/headmyshoulder/odeint-v2 In terms of code, I have made the following improvements to odeint: * Implementation and performance tests of a generic Runge-Kutta algorithm. * Implementation of several algorithms using the generic Runge-Kutta scheme (rk4, rk54ck, rk78) * Redesign of the construction/destruction of temporary states by use of a state_wrapper * Redesign of the resizing functionality by usage of boost::bind * Redesing of the algebra implementation to now use instances instead of static functions. * Creating mkl_operations to make use of Intel's MKL for optimal performance * major refactorings (e.g. renaming stepper classes) * Implementation of a Bulirsch-Stoer stepper with dense output * Improvement of integrate functions so they have consistent behavior * Adding integrate_times function to allow for observation at user defined time points * Adding unit tests for integrate functions Additionally, I worked on the documentation: * Created an overview over all implemented algorithms * Adding a resizing example to the tutorials section * Adding a description of the integrate functions * Adding a brief concept description of steppers, system and observer * Adding a brief overview on the Algebra/Operations and how they interact Besides his fruitful input and discussions related to my work presented above, Karsten also put quite some effort into odeint during the GSoC period, e.g. providing examples and tutorials in the docs section or adding multistep and implicit algorithms (adams-bashforth, rosenbrock4). We are very happy about any feedback on the work done within this GSoC or on odeint in general. If you have any further question please feel also invited to contact us. Finally, I want to thank the boost communtity for giving me the possibility to take part in this years GSoC as part of the boost organization. I have learned a lot during this time and I think odeint took a major step forward in terms of design and extent. Regards, Mario
On 08/22/11 13:01, Mario Mulansky wrote: [snip]
http://headmyshoulder.github.com/odeint-v2/doc/boost_sandbox_numeric_odeint/... the number 14 appears with no explanation of why 14 was chosen instead of say 20 or 50. Instead of 14, it would be better if there were some macro, like mpl's BOOST_MPL_LIMIT_VECTOR_SIZE: http://www.boost.org/doc/libs/1_47_0/libs/mpl/doc/refmanual/limit-vector-siz... There's also a typo on state_algebra_operations.html: Constrcuts a Scale object Also, couldn't: algebra.for_eachN( y, x1, x2, ... xN-1) be replaced by generating overloaded algebra.for_each's? Similarly, couldn't Operations::scale_sumN< Value1, Value2, ..., ValueN> done like the way fusion::vector is done? This might make it easier, in the future, to convert to variadic templates. OTOH, why not try variadic templates now? -regards, Larry
On 08/22/2011 10:05 PM, Larry Evans wrote:
We do not use the preprocessor library. Of course it is possible but we might spent a lot of time learning it. We are not sure if this amount of time is really useful, since in C++0x everything is much easier.
We want odeint to work with C++03 compilers. Nevertheless, we plan to create an own C++0x (or C++11) branch. Best regards, Karsten
On 8/22/2011 4:24 PM, Karsten Ahnert wrote:
Creating a macro as a compile-time constant which an end-user can manipulate to change library behavior is hardly "using the preprocessor library". You may have other reasons for not creating such a macro but familiarity with the Boost PP library can hardly be that reason in such a simple case.
On 08/22/2011 10:34 PM, Edward Diener wrote:
Yes, you are right. There is no need for larger numbers than 14, since such steppers do not exists at the moment. Furthermore, this approach does not work for all library we want to use. Take thrust as an example: Here you need to call thrust::for_each with a zip iterator which maximal number of entries is limited to 10. If you want to go for more entries you have to call thrust::for_each with a zip iterator of zip iterators.
On Mon, 22 Aug 2011 22:05:13 +0200, Larry Evans <cppljevans@suddenlink.net> wrote:
First, the description of the algebra/operations is very brief, lots of details are still missing there. The number 14 is induced by the maximum number of stages used in a stepper (here in the runge_kutta78 stepper). Also, I up to now never encountered an algorithm which requires more stages so I currently don't see a reason to increase the number. However, I generally agree that it might be better to implement the operations by using Macros. But opposing to the BOOST_MPL_LIMIT_VECTOR_SIZE there is absolutely no point in giving the user the possibility to change the, say, ODEINT_OPERATIONS_COUNT as it is strictly defined by the implemented algorithms. For this reason switching to a macro-ized version does not have priority for us at the moment as we currently don't see any benefit, except elegance maybe.
Will be corrected, thanks.
Switching to an overloaded for_each would be no problem at all. But I do actually like the for_eachN version because the compiler tells you if you accidentally forget an argument. A bug rather difficult to identify if just another overload kicks in. As said before, revisiting the Operations is something I want to look into at some point, but for now I don't think it's worth the effort. As Karsten said, odeint-v2 is and will stay C++03, we have an c++11 version in mind where operations and algebra will surely look more sophisticated. Thanks for your comments! Best, Mario
-regards, Larry
participants (4)
-
Edward Diener -
Karsten Ahnert -
Larry Evans -
Mario Mulansky