[
https://issues.apache.org/jira/browse/MATH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056360#comment-13056360
]
Dennis Hendriks commented on MATH-605:
--------------------------------------
bq. there is a BracketedSolution interface (by the way, I think this name is
not appropriate, a solver is not a solution)
I agree. Maybe BracketedSolutionSolver? Or if you want to be really precise,
then BracketedSolutionUnivariateRealSolver, but in my opinion that is way too
long.
bq. I would suggest we adjust our hierarchy slightly and force user to use a
solver from the bracketing part of the hierarchy only.
Good idea.
bq. Second, we should let the integrator (or better the internal event state
handler) select the side by itself. It should select the right side for forward
integration, but it should select the left side for backward integration.
I anticipated this, which is the reason I added the left side choice, even
though I didn't personally need this (I don't use backward integration).
bq. Looking at your example, I'm a little puzzled by the switching function.
This issue was part of a larger application. I extracted that what was needed
to show the issue. Some of the things may not make sense in the simplified
context. I agree that the switching function is less than ideal, but it should
nonetheless work. It can be evaluated at each point, and a bracketed solution
can be maintained. Even though convergence is not optimal, I think the
Secant-based algorithms should be able to handle this. Note that the function
has one root only, not more, which may be essential in this case.
bq. I have tried to simply suppress the small ignore zone at the start of the
integration, but it wasn't sufficient. I think we'll have to dig deeper in the
code.
I tried this as well, and failed. I guess I don't have enough knowledge of the
code involved to change this.
bq. So as a partial conclusion, [...]
I agree.
bq. We should make sure that it works for all existing unit tests [...]
An other interesting case would be 2 events at the same time, that actually are
detected at the same time. Changing the derivative of the second function to 1,
to be equal to the first one, may do that.
bq. Thanks a lot for this report and the solution, it is really the way to go!
Thank you for your useful comments.
> 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
