Re: [Orekit Developers] Bug #239 Nearly Simultaneous Events

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Le 18/04/2016 15:20, Evan Ward a écrit :
> Hi,
> 
> When looking into bug #239 about nearly simultaneous events the issues
> appears to be subtler than I originally expected. Currently events are
> not linearizable, that is there is not always a "happens before"
> relationship between event detectors, or in other words some calls to
> eventOccured() cannot logically occur in the same time line. For
> example, suppose we have two nearly simultaneous event detectors D1 and
> D2 that reset the state to S1 and S2 respectively. If S0 is the state
> before either event detector is notified then I would expect the
> sequence of events to be either
> 
> D1.eventOccured(S0)
> D2.eventOccured(S1)
> 
> or
> 
> D2.eventOccured(S0)
> D1.eventOccured(S2)
> 
> since events can be re-ordered within their tolerance setting. But
> instead the current implementation produces
> 
> D1.eventOccured(S0)
> D2.eventOccured(S0)
> 
> which implies neither event occurs before the other. Since any event can
> reset the state having linearizable events implies a total order for
> events which implies that we need to process events one at a time.
> 
> Processing events one at a time can be a little tricky because of the
> tolerance setting so we don't know exactly where the root is. I'm going
> to try a scheme where the event occurs to the left of the root (so
> events won't be skipped) and then the search for more events starts to
> the right of the root (so events won't be repeated).
> 
> I would also like to hear your comments on these ideas or any ideas you
> have for fixing it.

One thing you should be aware is that we still need to have the events
detection function at least consistent, and rather continuous around
events. If this assumption is not fulfilled, event detection will not
be reliable.

In the documentation, we stated we need continuity around 0. In fact,
if continuity is not assured but g(state) function is consistent enough
that it changes sign correctly (like directly switching from -1 to +1),
then everything will work (but convergence will be slow).

If state reset from S0 to S1 from first detector is sufficient to
change the nature of the zero crossing for the second detector, I
don't think we can do anything. In this case, I would ask users to
specify their events another way or to handle discontinuities (or
rather inconsistencies) by themselves.

The implementation reason we relie on this consistency is that event
detectors are wrapped inside EventState classes that *do* keep a
memory of previous state. In your case, the second detector D2
will be wrapped within EventState(D2) and this will hold values
for g(S0). When resetting the state, I don't remember if the
preserved state will be recomputed using g(S1) or if we simply
assume at least the reset does not change the sign of g(S1) with
respect to g(S0). If this sign is changed, how could we interpret it?
It would be a sign change induce by an instantaneous state reset, but
does it mean a condition boundary was really crossed?

We did encounter such a case when dealing with attitude changes
triggered by events. Using a rough model, we had a spacecraft
tracking objects. When a new object entered a big field of view,
the attitude was instantaneously changed to track the new object.
However, in some cases as one object entered, the spacecraft
turned to it, and this rotation made another object enter, so the
event detection algorithm was lost because the g function switched
from a positive to a negative value, but in fact no zero crossing
could be detected. We had in fact a causality loop: attitude
depended on events, and events were triggered by attitude changes.
In this case, the solution was to have a better model and consider
the attitude changes were note instantaneous but took some time,
so attitude was continuous and the problem disappeared: the
state preservation within EventState was working correctly again
and sign changes became real sign changes again with the correct
semantics.

So back to your problem, are your state changes S0 -> S1 -> S2
or S0 -> S2 -> S1 preserving signs for the various g functions
so EventState assumptions are still valid or not? If they are
not, then either the state changes are not physically meaningful
(this was our case with the attitude changes) or the state
changes are valid but the g function should be written in such
a way they change sign properly even when these state changes occur.

If both the states changes are valid and the g functions semantics
are valid, of course we need to fix the behaviour.

From what you explained, I don't understand in which case we are
(or even if we are in another case I did not think about).

best regards,
Luc


> 
> Best Regards,
> Evan
> 
> https://www.orekit.org/forge/issues/239
>