commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject [math] seeking for an implementation advice
Date Sun, 07 Mar 2010 11:58:31 GMT

As you may have seen, I have implemented a new feature in [math] last
few days. It is an extended integrator for ODE that in addition to state
y() also provides its jacobians with respect to initial state dy(t)/dy0
and with respect to some ODE parameters dy(t)/dp.

The underlying algorithm is simply to extend the ODE problem with a few
variational equations, so if you start with an y(t) state that has
dimension 6 for example, and you have 3 parameters you will end up with
a compound state that has dimension 6 + (6 * 6) + (6 * 3) = 60. One the
state has been extended and the additional equations have been set up,
the problem is a classical Initial Value Problem whci can be handled by
all the existing integrators we have. So this feature consists mainly in
a bunch of adaptor classes to perform the state versus compound state
mapping. There are adaptors for the ODE problem, the step handlers, the
step interpolators and the events handlers.

For now, the implementation is based on a top level class:
FirstOrderIntegratorWithJacobians and five interfaces:
StepHandlerWithJacobians, StepInterpolatorWithJacobians,
EventHandlerWithJacobians, ParameterizedODE and ODEWithJacobians. The
user typically has to implement StepHandlerWithJacobians if he want to
monitor the integration process at each step, EventHandlerWithJacobians
if he needs to introduce some discrete event in the otherwise continuous
integration process and either ParameterizedODE or ODEWithJacobians to
describe the problem he wants to integrate. The
FirstOrderIntegratorWithJacobians performs all wrapping by itself and
mimics many of the original FirstOrderIntegrator interface.

Another choice would be to remove the FirstOrderIntegratorWithJacobians
class and change the adaptors classes to be user visible
(StepHandlerAdaptor, EventHandlerAdaptor, ODEAdaptor). In this case, the
user would need to wrap his implementations of the jacobians enabled
interface into the adaptors and pass them to a classical integrator. On
the one hand, this choice would remove duplication of the integrator
methods in a separate class, and would allow better management of
handlers by users. Users may also not use adaptors for step handlers or
event handlers if they don't explicitly need the jacobians, using only
the irst elements of the compound state without any data copyin. On the
other hand it will force the user to add the adaptors Here are examples
of user code in both cases:

Current implementation:

  FirstOrderIntegrator rawIntegrator = new XyzIntegrator(...);
  ODEWithJacobians ode = new MyProblem(...);
  FirstOrderIntegratorWithJacobians integrator =
    new FirstOrderIntegratorWithJacobians(rawIntegrator, myProblem);
  integrator.addEventHandler(new MyEventHandler(...),
                             max, epsilon, count);
  integrator.addStepHandler(new MyStepHandler(...));
  integrator.integrate(t0, y0, dy0dp, t, y, dydy0, dydp);

Implementation with public adaptors:

  FirstOrderIntegrator integrator = new XyzIntegrator(...);
  ODEWithJacobians ode = new MyProblem(...);
  integrator.addEventHandler(new EventAdaptor(new MyEventHandler(...)),
                             max, epsilon, count);
  integrator.addStepHandler(new StepAdaptor(new MyStepHandler(...)));
  StateAdaptor sa = new StateAdaptor(y0, dy0dp);
  double[] y = sa.getCompoundStateReference();
  integrator.integrate(ode, t0, y t, y);
  dydy0 = sa.getDyDy0();
  dydp  = sa.getDyDp();

My current preference is to have visible adaptors. It seems cleaner from
a design perspective, and not too cumbersome for users.

What do you think ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message