EventShifter behavior when the duration of the event is less than the shift

1

Hello,

I think the behavior of the EventShifter is not correct if the duration of underlying raw event is smaller than the shift requested on the event (maybe it’s indicated in the documentation but I didn’t see it).
For example, if I request to shift an entry in eclipse umbra of 5 minutes and the eclipse umbra lasts only 3 minutes, I have multiple detections of the entry (the g function oscillates around 0).

How can it be possible to handle this kind of specific cases where the underlying event lasts less than the shift ?

Thank you.

Christophe

2

Hi @Christophe,

I don’t have an answer to your question yet…
But it seems to be a bug to me, or at least if this is an expected behavior it should be documented.

Could you send us a test case that will help us reproduce the bug please ?

Maxime

3

Hello,

here is an example that reproduces the behavior.
It’s an eclipse not far from perigee on a GTO orbit (eclipse duration ~23 min) and with a shift -15min before and +15min after.

After execution, I get something like this:

Shifted eclipse - 2020-01-17T04:57:31.241 : Entry
Nominal eclipse - 2020-01-17T05:12:31.241 : Entry
Shifted eclipse - 2020-01-17T05:20:58.378 : Exit
Shifted eclipse - 2020-01-17T05:27:31.241 : Entry
Nominal eclipse - 2020-01-17T05:35:58.378 : Exit
Shifted eclipse - 2020-01-17T05:50:58.378 : Exit

The example is based on Orekit 9.3.1 (that is the version that we currently use but I think the problem is still present in v10. Maybe a small adaptation of my example for the detectors is needed with the new version).

Thank you!

Christophe

OrekitEventShifter.java (2.9 KB)

4

Hello again @Christophe,

Thank you for the sample code.
It helped me understand what happens.

As you said the problem arises when the event duration is lower than the sum of increasingTimeShift - decreasingTimeShift.
In your example let’s call increasingTimeShift = t_{+}, decreasingTimeShift = t_{-} and event duration = Δt

In short, here is what happens.

  1. Working case: your example with t_{-}= -11min before and t_{+} = +11min after eclipse.
    Since the eclipse duration is 23min we have t_{+} - t_{-} <= \Delta t
    The figure below is the value of the g function around the eclipse (abscissa = seconds since 2020-01-17T04:50.000).
    The shifter computes the red g_{shifted} function as the minimum of the base blue g function with g_{shifted}(t) = min(g(t - t_{-}), g(t - t_{+}))
    EclipseDetector - Unbuggy
    That case works as we want it to work.

  2. Bugged case: your example with t_{-}= -15min before and t_{+} = +15min after eclipse. So t_{+} - t_{-} > \Delta t
    The g function now looks like this. We see the two unwanted detected entry (@t_{entry} - t_{+}) and exit (@t_{exit} - t_{-}) from your test case.
    EclipseDetector - Buggy

I’ll open an issue on the forge for this bug.

I don’t have a clean fix for it right now.

But I’ve found an (ugly) work around using two detectors and EventSlopeFilters.

You need to:

  1. Create a shifted eclipse entry detector: Set up a shifted detector with (-t_{-}, t_{-}) as inputs and filter it for decreasing events only;
  2. Create a shifted eclipse exit detector: Set up a shifted detector with (t_{+}, -t_{+}) as inputs and filter it for increasing events only;
  3. Add the two detectors to your propagator.

That way the g functions look like this:
EclipseDetector - Filtered

And the output is:

Shifted Eclipse fixed - 2020-01-17T04:57:31.241 : Entry
Nominal Eclipse - 2020-01-17T05:12:31.241 : Entry
Nominal Eclipse - 2020-01-17T05:35:58.378 : Exit
Shifted Eclipse fixed - 2020-01-17T05:50:58.378 : Exit

Here is a modified version of your code that implements the fix: OrekitEventShifter.java (8.5 KB).
It is in Orekit 10 (not much to change though).

Maxime

5

Hello Maxime,

By looking at your last plot, a g function that will be the multiplication of the two filtered g functions seems to do the job (but I don’t know if this will handle all the possible cases).

And thank you for all the explanations and a possible workaround.

Christophe

6

Hello Christophe,

You are very welcome.

It does indeed work in this case you are right. I didn’t think of this, thank you.
See the plot and output below, with your proposed implementation in “new shifter”.

It could be a nice fix.
I agree that we’ll have to do some proper testing to see if it will handle all possible cases.
EclipseDetector - With New Shifter

New shifter - 2020-01-17T04:57:31.241 : Entry
Shifted Entry filtered - 2020-01-17T04:57:31.241 : Entry
Nominal Eclipse - 2020-01-17T05:12:31.241 : Entry
Nominal Eclipse - 2020-01-17T05:35:58.378 : Exit
Shifted exit filtered - 2020-01-17T05:50:58.378 : Exit
New shifter - 2020-01-17T05:50:58.378 : Exit

Here is the code of the event shifter I used, just in case you want to do some tests:
EventShifter2.java (8.9 KB)
I had to add two filtered event detectors as attributes of the class.
It’s a bit heavy.
There must be a more elegant way to do it.

Maxime