Adaptable max check interval or predicate for event detectors

Orekit usage
1

Hi there :slightly_smiling_face:

I first just wanted to say that Orekit is a fantastic and powerful set of tools and I am very thankful for all of the continual support it receives!

The problem I am trying to solve is to find a performant way of searching for events which can last as little as 1 second and will only happen (at most) once per orbit. Obviously it is very time-consuming to set the max check of the detector to 1s, when I only really need this level of precision close to a potential event. I could very easily write a function or predicate that can determine when this smaller max check interval should be used, and when a larger interval can be used.

I tried using the EventEnablingPredicateFilter to reduce the search time, but if I understand correctly, the predicate only reduces the number of calls to the underlying g-function by not bothering to find the exact increasing/decreasing events?

What would be great is to be able to wrap an EventDetector with some predicate that is checked with a separate max check interval, and only look for events/call the underlying g-function (with the smaller max check interval) whilst the predicate is true. I can see there was a similar issue that was closed a while back, #87, without much explanation.

Maybe I am missing something from the existing architecture that would solve this problem? Or some workaround? Otherwise maybe I have to implement something custom for this behaviour.

Thanks in advance :slightly_smiling_face:

2

Hi @JakeRandellOC welcome

Thank you for the kind words, it is really appreciated.

I agree such a feature would be interesting, and we postponed it for a while without good reasons.
It is indeed the right time to ask for it, because we are working on major releases of both Orekit and Hipparchus, so we can break API and introduce new features now.

What would you think about replacing the current no-argument getMaxCheckInterval() method in event detectors with a method that would take the current state as an argument getMaxCheckInterval(state). A default implementation would simply always return the same value, but users could register a custom method using something like:

  EventDetector detector = new SomeDetector().
                           withThreshold(aTinyThreshold).
                           withMaxCheck(state -> closeToEventPredicate(state) ? 1.0 : 100.0);

where closeToEventPredicate would be a user-provided predicate.

1 Like
3

Hi @luc, thanks for the prompt reply.

Your proposal sounds like it would perfectly solve my problem. And the idea seems very flexible - I can foresee using something like this to dynamically set the max check depending on how close we are to the event i.e. the max check value decreases as we approach a potential event, and increases as we move away from a potential event.

4

Hey there,

Quick comment: if you don’t need to detect events live (I mean if it’s acceptable to find them post propagation), you can use the BoundedPropagator, it’d be faster as it will interpolate states.

Cheers,
Romain

5

Fine, could you open two issues then? One in the Orekit forge and one in the Hipparchus forge?

6

@luc of course, I will create the issues shortly, thanks for your help :slightly_smiling_face:

@Serrof thank you for the suggestion - I have not used the BoundedPropagator interface or any of the classes that implement it before, so I just had a quick read of the docs. I largely use the TLEPropagator as I am working with the latest available TLE’s for missions.

Are you suggesting that I run the TLE propagator for a time window I am searching for events within, whilst collecting SpacecraftState samples at some defined interval/sampling. Then providing these samples to something like the Ephemeris class, and attaching my EventDetector to it and then do the propagation?

7

Ah never mind, if your propagator is analytical rather than numerical there is no benefit in using the ephemeris generator

Romain.

8

No worries, useful to be aware of nonetheless :slightly_smiling_face:

9

I think this will be a useful feature. I left some comment on Luc’s prototype in Adaptable max checking interval for event detection · Issue #270 · Hipparchus-Math/hipparchus · GitHub

10

The feature has been implemented in both Hipparchus and Orekit.
Please note that the dependency of Orekit on Hipparchus requires the two libraries to be updated simulaneously for this to work.