[Boost-users] Review of ODEInt

Subject: [Boost-users] Review of ODEInt
From: Rhys Ulerich (rhys.ulerich_at_[hidden])
Date: 2012-09-28 09:59:23

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/dense_output_stepper.html
 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/dense_output_stepper.html

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_in_detail/steppers.html
are static_casts preferred to using constructors a la Value(2) /
Value(3)?