You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2010/03/07 12:58:31 UTC
[math] seeking for an implementation advice
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 ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] seeking for an implementation advice
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz a écrit :
> 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.
OK. So I will stick with the current implementation.
> 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?
I think a simpler alternative would have imply an incompatible change in
user interfaces. The problem is that important methods (from a user
point of view), like FirstOrderIntegrator.integrate and the three
methods in EventHandler use t (the integration variable) and y (the
state vector) only. This extended problem implies providing also dy0/dp
to initialize the integration and it provides the additional results
dy(t)/dy0 and dy(t)/dp, which are the main thing we are interested in.
The two choices above are different ways to deal with this in an upward
compatible way. Current implementation simply create a new classes with
their own methods (integrate, eventOccurred ...) that have the
additional parameters. The public adaptors method provides intermediate
adaptors that pack/unpack (y, dy/dy0, dy/dp) to/from a single array.
A simpler implementation would probably mean getting rid of the y array
and setting up some StateVector class holding (t, y) and extending it to
add the jacobians in some StateVectorWithJacobians. It would also
probably force users to do some casts from StateVector to
StateVectorWithJacobians which would not be elegant either. This would
be a really huge change IMHO.
The examples above show a complete use case when you want the result at
integration end but also the intermediate results (in step handlers) and
have some discrete events to cope with. There are simpler use cases when
only the final state is useful, so only the integrate method is called.
> In any case, examples in the user
> guide and / or class javadoc would be helpful.
Of course! I only did not write them yet because I wanted the API to be
stable. If we go with the current one, I can start writing something.
Luc
>
> Phil
>
>
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] seeking for an implementation advice
Posted by Phil Steitz <ph...@gmail.com>.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org