[
https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Hendriks updated MATH-605:
---------------------------------
Affects Version/s: 3.0
Updated affected version to 3.0 from 'unset'.
> 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
>
>
> The Commons Math page on ODEs
> (http://commons.apache.org/math/userguide/ode.html) states in section 13.3
> (Discrete Events Handling), that: "Note that g function signs changes at the
> very beginning of the integration (from t0 to t0 + ε where ε is the events
> detection convergence threshold) are explicitely ignored. This prevents
> having the integration stuck at its 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. Using
> 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 desired.
> 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. Whenever
> they become larger than 1.0, they are reset. We thus expect resets for event
> 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 processed
> the first, the 'skip everything between t0 and t0+e' may result in skipping
> events, as can be observed from the failing unit test. The second test 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
> MATH-484. I propose to make the skipping of events betweeen t0 and t0+e
> optional, as that is no longer needed in the cases I described above, and in
> fact causes severe problems that can only be solved by hacks. For other
> (non-bracketed solution) algorithms, it may still be necessary to skip such
> roots. Maybe an option could be introduced to control this behavior?
> So, if an event is detected at time t, integration may continue from t0=t,
> 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 as well,
> with isLast=true. 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 integration step
> should be taken into account, taking the maximum of that an dall 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
