Here is my review of the proposed ODEInt library... I'm abstaining on the yes/no library acceptance vote.
- What is your evaluation of the design?
As a user, I can find my way around. Several particular nits appear in my miscellaneous comments section. I'm not convinced that the interfaces, which differ from many other ODE integration packages, are a marked improvement from those other packages (e.g. GSL, PETSc, Trilinos, SUNDIALS, etc). I think that adding more than classical use cases could be difficult, in particular IMEX schemes. In particular, my personal research code (a turbulence DNS platform requiring semi-implicit time advance for a hyperbolic PDE system) could not be retrofit into this framework.
- What is your evaluation of the implementation?
I've not read through the implementation.
- What is your evaluation of the documentation?
Fairly good on the whole. I wish the math more clearly appeared using display-style equations rather than inline text. One table appears repeatedly and many links are missing. The applications section is quite nice.
- What is your evaluation of the potential usefulness of the library?
I think the collection of features are useful, but I'd not adopt this library over the GSL, PETSc's time steppers, or Trilino's Rythmos when working in C or C++. GSL's APIs are quite easy and have no learning curve. PETSc's steppers are very powerful and support many new, exotic schemes. Rythmos build atop clean C++ vector space abstractions from the rest of Trilinos. odeint-v2 doesn't seem to beat any of these three alternatives at their game nor does it feel like enough of a winning compromise to make it compelling to me.
- Did you try to use the library? With what compiler? Did you have any problems?
No.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
45 minutes of reading.
- Are you knowledgeable about the problem domain?
Somewhat. In conclusion, I'm thrilled to see someone put forward an ODE integration library for Boost but I feel the design doesn't address current application needs and best practices in many portions of the numerical PDE communities. That said, I applaud the authors' effort and I'm sure odeint-v2 will be useful for other folks. - Rhys P.S.: Miscellaneous, jumbled comments: Within the documentation, Table 1.1's stepper algorithm classes should link to the class. Ditto for lists of models within, e.g., http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concepts... Table 1.2 appears to duplicate Table 1.1 and should simply be linked. Ditto for Table 1.7. Stray < and > appear within the generated documentation, e.g. at http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concepts... sys.first(...) and sys.second(...) don't describe what's happening within the ImplicitSystem interface. sys.calculate_dxdt(...) and sys.calculate_dfdx(...) describe the operations involved. That they're called in some sequence shouldn't determine the names. Moreover, sometimes big gains can be made by simultaneously computing the Jacobian and the function evaluation in a single call. ImplicitSystem should be a System, but it's not. System should use a calculate_dxdt(...) method rather than operator(...) so that one has a hierarchy of system concepts. Similar naming concerns apply to the symplectic system concepts. In- versus out-of-place do_step(...) method signatures should differ by more than the method signatures. In my own codes I've used terminology like 'apply' and 'accumulate' and modeled the signatures off Level 1 and Level 2 BLAS calls. WRT ImplicitSystem, either providing or recommending some mechanism for finite differenced or complex-stepped Jacobians would be useful. Naming inconsistencies in the dense output schemes: bulirsch_stoer_dense_out vs rosenbrock4_dense_output Unclear if the design permits low storage Runge Kutta schemes, singly diagonally implicit.schemes, and other fun implicit-explicit things. E.g., there are IMEX schemes with different formal orders of accuracy for the implicit vs explicit portions of the scheme. Unclear if the design permits CFL-related maximum stable step sizes within f(u). The System interface would need to be adapted to have each method return maximum stable eigenvalue magnitudes for first and second order differential operators.` Rather than limiting implicit systems to folks using uBLAS matrices, it may be better to define the abstract operations a class would need to support to plug into the ImplicitSystem infrastructure. Especially because getting a uBLAS "wrapper" around an existing chunk of memory is quite a PITA and relies upon non-standard parts of the uBLAS (See, e.g., http://agentzlerich.blogspot.com/2009/10/boostublasshallowarrayadaptor.html). Why in http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_i... are static_casts preferred to using constructors a la Value(2) / Value(3)?