Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 9 Nov 2011 13:31:52 +0000 (UTC)
From: "Dennis Hendriks (Updated) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <493020881.14288.1320845512231.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1840959452.14276.1320845391919.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (MATH-705) DormandPrince853 integrator leads to
 revisiting of state events
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Hendriks updated MATH-705:
---------------------------------

    Attachment: ReappearingEventTest.out
                ReappearingEventTest.java

The Java unit tests that show the problem, and the console output they give, as described in the issue description.
                
> 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