Luc Maisonobe wrote: > Hello, > > 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 ?
I agree with the current implementation choice among the two described. My only question - which I do not have an answer to as this is way out of my domain of practical experience - is is there an even simpler setup possible? In any case, examples in the user guide and / or class javadoc would be helpful. Phil > Luc > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
