commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-705) DormandPrince853 integrator leads to revisiting of state events
Date Sun, 20 Nov 2011 21:45:51 GMT

    [ https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153884#comment-13153884
] 

Luc Maisonobe commented on MATH-705:
------------------------------------

This issue should be fixed in subversion repository as of r1204270.

Could you check it works for you ? If so, I will use the same trick for other Runge-Kutta
type step interpolators.
                
> 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

        

Mime
View raw message