commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-605) Missing state events due to events between t0 and t0+e being ignored
Date Sun, 10 Jul 2011 16:39:59 GMT

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

Luc Maisonobe commented on MATH-605:
------------------------------------

Dennis, I have committed a few changes in the EventState class, following the previous comments.
Now we make sure the event time is located at or after the exact root (i.e. never before),
according to the current integration time. This is done by either asking the user-provided
solver to select the proper side if it is a bracketing solver, or by using the new forceSide
method as a post-processing step if the solver is non-bracketing.
This has allowed me to remove at least one special case handling, and only slightly changing
another one.
It does work on all unit cases of the library, and it has also been tested on my own user
code.

Could you check if this works for you too ? If it works, I'll resolve this issue.

> 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

       

Mime
View raw message