[
https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147712#comment-13147712
]
Dennis Hendriks edited comment on MATH-705 at 11/10/11 2:31 PM:
----------------------------------------------------------------
bq. 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 trick?
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.
was (Author: dhendriks):
> 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 trick?
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: https://issues.apache.org/jira/browse/MATH-705
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: Commons Math trunk, Java 6, Linux
> Reporter: Dennis Hendriks
> Attachments: ReappearingEventTest.java, ReappearingEventTest.out
>
>
> See the attached ReappearingEventTest.java. 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 values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
