Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 25 Oct 2011 19:28:32 +0000 (UTC)
From: "Luc Maisonobe (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <2107141532.14813.1319570912416.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1710934765.14171.1319561552306.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (MATH-695) Incomplete
 reinitialization with some events handling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Luc Maisonobe edited comment on MATH-695 at 10/25/11 7:28 PM:
--------------------------------------------------------------

As I work with Pascal (we share the same office at work), I have seen how the bug occurs and am trying to set up a simplified test case that reproduces it. It seems that there is a combination of conditions that is not handled properly. We have seen the bug occurring when both following conditions are true:

* there are several events occurring in the same integration step
* when one of the earliest events occurrence is triggered, it returns RESET_DERIVATIVES

In this case, the acceptStep method in AbstractIntegrator returns early from inside the while loop and the remaining events that where expected to occur later on are left in an inconsistent state with respect to the integrator. The t0 and g0 fields in the corresponding EventState instance still contain values from the beginning of the step, they do not reflect the fact the event has been triggered. This implies that when next step is started with the updated derivatives, evaluateStep tries to catch up from t0 to current t and calls the g function at times that do not belong to the current step.

Up to now, I have not been able to set up a simplified test case that exhibits this, but I'm working on it.
                
      was (Author: luc):
    As I work with Pascal (we share the same office at work), I have seen how the bug occur and am trying to set up a simplified test case that reproduces it. It seems that there is a combination of conditions that is not handled properly. We have seen the bu occurring when both following conditions are true:

* there are several events occurring in the same integration step
* when one of the earliest events occurrence is triggered, it returns RESET_DERIVATIVES

In this case, the acceptStep method in AbstractIntegrator returns early from inside the while loop and the remaining events that where expected to occur later on are left in an inconsistent state with respect to the integrator. The t0 and g0 fields in the corresponding EventState still contains values from the beginning of the step, they do not reflect the fact the event has been triggered. This implies that when next step is started with the updated derivatives, since the t0 for the second event is still lagging behind current time, evaluateStep tries to catch up from t0 to current t and calls the g function at times that do not belong to the current step.

Up to now, I have not been able to set up a simplified test case that exhibits this, but I'm working on it.
                  
> Incomplete reinitialization with some events handling
> -----------------------------------------------------
>
>                 Key: MATH-695
>                 URL: https://issues.apache.org/jira/browse/MATH-695
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.0
>            Reporter: Pascal Parraud
>         Attachments: events.patch
>
>
> I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way.
> I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests.

--
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