Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 11 Jul 2011 08:50:00 +0000 (UTC)
From: "Dennis Hendriks (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <658887453.2264.1310374200524.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <461981483.43311.1309171967574.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (MATH-605) Missing state events due to events
 between t0 and t0+e being ignored
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

Dennis Hendriks updated MATH-605:
---------------------------------

    Attachment: overlapping-events-tests.patch

Nice work Luc! I tested it on my application, and I no longer need the hack=
 that I previously used.

I added a new patch (overlapping-events-tests.patch) that provides a few te=
st cases to test this new functionality. It is a modified unit test from th=
e original file I attached to this issue, when I reported this issue, etc.

Also, I checked all your commits. The patch fixes some comments here and th=
ere.

Finally, I fixed the verifyBracketing/isBracketing methods in the Univariat=
eRealSolverUtils class, to also except intervals that have a zero function =
value at one of the end points.

Thanks for you efforts.

> Missing state events due to events between t0 and t0+e being ignored
> --------------------------------------------------------------------
>
>                 Key: MATH-605
>                 URL: https://issues.apache.org/jira/browse/MATH-605
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: Dennis Hendriks
>         Attachments: OverlappingEventsTest.java, overlapping-events-tests=
.patch
>
>
> The Commons Math page on ODEs (http://commons.apache.org/math/userguide/o=
de.html) states in section 13.3 (Discrete Events Handling), that: "Note tha=
t g function signs changes at the very beginning of the integration (from t=
0  to t0 + =CE=B5 where =CE=B5 is the events detection convergence threshol=
d) are explicitely ignored. This prevents having the integration stuck at i=
ts initial point when a new integration is restarted just at the same point=
 a previous one had been stopped by an event."
> However, due the following issues:
>  - MATH-586: Allow using a custom root-finding algorithm to detect state =
events
>  - MATH-599: Re-implementation of Secant-based root finding algorithms
> we can now use for instance the PegasusSolver to detect state events. Usi=
ng the AllowedSolutions.RIGHT_SIDE we can guarantee that we have passed the=
 event. As such, skipping (future) events between t0 and t0+e is not desire=
d.
> I attached a Java class to show this issue. It has 2 continuous variables=
, each starts at 0.0. The first has derivative 1.0, the second 2.0. Wheneve=
r they become larger than 1.0, they are reset. We thus expect resets for ev=
ent 1 at 1.0, 2.0, 3.0, etc. We expect resets for event 2 at 0.5, 1.0, 1.5,=
 etc. The events overlap (at 1.0, 2.0, etc). Due to numerical differences, =
the events however are not detected at the exact same times. After we proce=
ssed the first, the 'skip everything between t0 and t0+e' may result in ski=
pping events, as can be observed from the failing unit test. The second tes=
t has a hack to get around this problem: it is manually checked whether the=
 guard changes, by evaluating t0 and t0+e. If an event is detected, a step =
of e is done, and integration is restarted from t0+e. This solves the issue=
, and the unit tests succeeds (we get the events at the expected times, and=
 we don't miss any events).
> From what I understand, event detection is complicated, as discussed in M=
ATH-484. I propose to make the skipping of events betweeen t0 and t0+e opti=
onal, as that is no longer needed in the cases I described above, and in fa=
ct causes severe problems that can only be solved by hacks. For other (non-=
bracketed solution) algorithms, it may still be necessary to skip such root=
s. Maybe an option could be introduced to control this behavior?
> So, if an event is detected at time t, integration may continue from t0=
=3Dt, and if there is a sign change for t0 and t0+e, then the step handler =
should be called for t0+e, and the step handler should be called for t0+e a=
s well, with isLast=3Dtrue. I'm not sure what the value of e should be. It =
could be the absolute accuracy of the root-finding algorithm. if there are =
multiple ones, maybe the maximum of all of them. Maybe even the minimal int=
egration step should be taken into account, taking the maximum of that an d=
all the absolute accuracies of the root-finding algorithms?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira