commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Hendriks (Commented) (JIRA)" <>
Subject [jira] [Commented] (MATH-705) DormandPrince853 integrator leads to revisiting of state events
Date Thu, 10 Nov 2011 14:31:52 GMT


Dennis Hendriks commented on MATH-705:

> Should we let this problem alone and consider we are in the grey zone of expected numerical
inaccuracy due to integration/interpolation orders or should we attempt the two half-models

I consider it important that events are properly detected, and are detected exactly once (if
they occur exactly once). Therefore, in general, I think the half-models trick would be a
good idea, as it is more important (to me) to have higher accuracy at the end points than
in the middle. For me, the DormandPrince853Integrator is now practically useless.

> DormandPrince853 integrator leads to revisiting of state events
> ---------------------------------------------------------------
>                 Key: MATH-705
>                 URL:
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.0
>         Environment: Commons Math trunk, Java 6, Linux
>            Reporter: Dennis Hendriks
>         Attachments:, ReappearingEventTest.out
> See the attached It has two unit tests, which use either the
DormandPrince853 or the GraggBulirschStoer integrator, on the same ODE problem. It is a problem
starting at time 6.0, with 7 variables, and 1 state event. The state event was previously
detected at time 6.0, which is why I start there now. I provide and end time of 10.0. Since
I start at the state event, I expect to integrate all the way to the end (10.0). For the GraggBulirschStoer
this is what happens (see attached ReappearingEventTest.out). For the DormandPrince853Integerator,
it detects a state event and stops integration at 6.000000000000002.
> I think the problem becomes clear by looking at the output in ReappearingEventTest.out,
in particular these lines:
> {noformat}
> computeDerivatives: t=6.0                  y=[2.0                 , 2.0             
   , 2.0                 , 4.0                 , 2.0                 , 7.0               
 , 15.0                ]
> (...)
> g                 : t=6.0                  y=[1.9999999999999996  , 1.9999999999999996
 , 1.9999999999999996  , 4.0                 , 1.9999999999999996  , 7.0                 ,
14.999999999999998  ]
> (...)
> final result      : t=6.000000000000002    y=[2.0000000000000013  , 2.0000000000000013
 , 2.0000000000000013  , 4.000000000000002   , 2.0000000000000013  , 7.000000000000002   ,
15.0                ]
> {noformat}
> The initial value of the last variable in y, the one that the state event refers to,
is 15.0. However, the first time it is given to the g function, the value is 14.999999999999998.
This value is less than 15, and more importantly, it is a value from the past (as all functions
are increasing), *before* the state event. This makes that the state event re-appears immediately,
and integration stops at 6.000000000000002 because of the detected state event.
> I find it puzzling that for the DormandPrince853Integerator the y array that is given
to the first evaluation of the g function, has different values than the y array that is the
input to the problem. For GraggBulirschStoer is can be seen that the y arrays have identical

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message