Hello, First of all, I think that odeint is a nice and useful library and should be accepted into Boost. It well belongs to Boost's Math and Numerics section.

- What is your evaluation of the design?

Odeint provides intuitive and logical interface, and is easily extended to use custom state types and operations. Many usual state types (such as scalar values, std::vector<> or boost::array<>) and operations on them are supported out of the box. The adaptation to user-defined data types is straightforward.

- What is your evaluation of the implementation?

I only had a quick glance at the implementation, but the code looks decent, clean and well formatted. Implementation of some algebras and operations could probably benefit from usage of C++11 variadic templates, but this would have to wait for wider adoption of the new standard.

- What is your evaluation of the documentation?

Documentation is good. Examples in tutorial cover most use cases and common state types and operations. There is an overview of avalable steppers, but more detailed description of each stepper (typical use cases, stability requirements, advantages and disadvantages w.r.t. other methods) would probably be beneficial.

- What is your evaluation of the potential usefulness of the library?

The library has admittedly limited scope, but it should be very useful for the domain it aims for. I believe its design is general enough to be included into Boost.

- Did you try to use the library? With what compiler? Did you have any problems?

I used odeint with gcc v4.6 and v4.7. I did not have any problems with those compiler versions.

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

I used odeint as a basis for comparison of several CUDA and OpenCL libraries (Thrust [1], ViennaCL [2], VexCL [3]). This was done in collaboration with Karsten Ahnert, coauthor of odeint. We solved several large systems of ODEs to look at both performance and ease of use of the GPGPU libraries (the work is not yet published). This task is easily performed with odeint due to its general design. I spent a couple of weeks working with odeint. Most of the time was devoted to writing system functions that would work with CUDA and OpenCL libraries and to performance tuning of custom odeint operations for the libraries.

- Are you knowledgeable about the problem domain?

I mostly deal with partial differential equations in my line of work, but I am familiar with solution of ordinary differential equations as well. [1] https://github.com/thrust/thrust [2] http://viennacl.sourceforge.net [3] https://github.com/ddemidov/vexcl -- Dr Denis Demidov Supercomputer Center of Russian Academy of Sciences Lobachevsky st. 2/31, Kazan 420008, Russia

Hi All, This is more a message from a (satisfied) user of odeint, than a proper review of the code, but still perhaps somehow helpful... On 19/09/12 17:46, Steven Watanabe wrote:

Please always state in your review, whether you think the library should be accepted as a Boost library!

I think it should be accepted. Both the library itself and the documentation proved to be functional for me and both seem quite mature. Odeint is well integrated with Boost by making use of other Boost components in its implementation, and allowing to use Boost.[Units, uBLAS, Array, Range, Fusion] objects as data containers. odeint would nicely complement the current catalogue of Boost libraries applicable in research. In fact, it would be great to have similar libraries for some particular types of PDEs, interpolation, fitting, etc. In particular, the odeint's interoperability with multiple data-container libraries (including those from Boost and others) would be great. I'm not sure if having a range of scientific libraries in Boost fits its aims, but if so, odeint would give a good example in my opinion.

- What is your evaluation of the design?

Not sure if that's a results of tutorial-based docs or the library design, but in my opinion the authors managed to avoid a steep learning curve. From a user's perspective the API is quite concise and clear. The separation of integration-related numerics from adaptivity-related numerics, and from the underlying data representation seems successful, what makes the design flexible (good example being the simultaneous compatibility with CUDA, OpenMP, OpenCL, GSL, and the several Boost containers mentioned above... not for all algorithms, though).

- What is your evaluation of the implementation?

I'm not feeling competent enough to evaluate the internals, but from a user's perspective the implementation simply works well. In particular, I confirm that the support for Thrust (both using GPU and OpenMP) and for Boost.units works out of the box.

- What is your evaluation of the documentation?

My feeling is that it is on par (or even more complete) than several other Boost documentations I have used, and it is rich in examples. In principle, it does allow to use the library without digging into the code or contacting the authors. However, it seems as it has grown quite a bit since the initial structuring into chapters and sections, and perhaps it deserves at least some reordering. In particular, I'd suggest promoting all subsections of the "Special topics" section to separate sections of the Tutorial chapter. Some other minor comments: * Tables 1.1, 1.2 and 1.7 as well as tables 1.3/1.4 and 1.8/1.9 seem to be identical? * The table 1.1 in the "Overview" includes headers naming non-previously mentioned subjects such as Concepts, System Concept. A paragraph briefly explaining these and referring to subsections of the "odeint in detail" chapter would be appropriate just before the table. * Tables in the "Concepts" chapter are not numbered * The fusion_algebra is missing from the table listing all algebras in doc/concepts/state_algebra_operations.qbk * Most of the tables in the "Concepts" chapter have their first column named "Name" while "Synopsis" or "Purpose" would probably reflect better the contents. * There is a catalogue of references in the Tutorial, but it does not list all the references (e.g. the Ott's book referenced in the chapter on Lyapunov exponents). There is no unified way of referring to (and hyperlinkig) the references in the text. Why not a separate chapter "References" for the whole documentation? * The README and the CHANGELOG files seem forgotten, but perhaps they are simply not needed if accepted into Boost * The "Caution" "Using Boost.Units works nicely but compilation can be very time and memory consuming. For example the unit test for Boost.Units take up to 4 GB of memory at compilation." would probably need some more specific information on the compiler used... or less specific statement on the amount of memory. Trying with gcc 4.7 and clang 3.1 I've recorded 1.8G and 1.1G, respectively (default Boost compiler options). * in some parts the documentation addresses the reader per "You", and in others using "one may ..." constructs * Some other Boost libraries contain "Reference" sections in the docs listing (e.g. http://www.boost.org/doc/libs/1_51_0/doc/html/boost_units/Reference.html). It would be useful for odeint as well in my opinion. * I think that the "Concepts" chapter requires an opening section (Overview?) explaining the concept of concepts. * I've placed some other suggestions/typo fixes for the documentation in a github pull request: https://github.com/slayoo/odeint-v2/commit/5eec7bf86321af185b4547a4825c0751e...

- What is your evaluation of the potential usefulness of the library?

I find it potentially very useful. Primarily in scientific/engineering context, but perhaps also in other domains - game design, GUI design. In comparison with other ODE solvers, the library seems quite versatile - it supports both implicit and explicit methods, both adaptive and non-adaptive solutions, algorithms for stiff and non-stiff systems, and as mentioned above, numerous "backends" ranging from GPU-stored POD arrays to resizable vectors of objects.

- Did you try to use the library? With what compiler? Did you have any problems?

I'm using the library for more than half year in my PhD project (IIRC, I've found it by googling "GPU ODE solver"). There we use odeint for two purposes: - solutions of simple 1-dimensional equations employing Boost.units (latent heat production during cloud droplet condensation/evaporation) - aerosol/cloud/drizzle/rain particle tracking within a fluid flow model (parallel solutions of ~milions of equations of motion, condensation, chemical reactions, etc) using Thrust (OpenMP only up to now). We've used clang 3.1 and several newer versions of gcc. Here's an example animation from a (quite naive) simulation of precipitation formation in a stratocumulus cloud: http://www.igf.fuw.edu.pl/~slayoo/temp/todo_sdm_E10.gif

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

Not counting the previous work with odeint, I've had a quick reading of the docs and a glance at the code. I've run all the tests and examples using "bjam" with clang and gcc toolsets.

- Are you knowledgeable about the problem domain?

I'm a PhD student studying atmospheric physics. ODEs show up frequently in my work, and I've been using some other solvers besides ODEINT as well (SUNDIALS in particular). I don't consider myself experienced enough to comment on the correctness of the mathematical/numerical part of ODEINT, though. In fact the key advantage of ODEINT for me is that the maths/numerics are nicely hidden from the user. HTH, regards, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/