Hello,
Please note that since the beginning of this thread, two important changes occurred in the current development version, which will be released soon as Orekit 11.0.
The first change is that we have removed the notion of propagation modes. See this discussion for details. The change mainly means that you can have any number of step handlers, including 0 set up in the propagator and in your setting you can mix at will step handlers with different step sizes and variable step size step handlers. No step handlers at all is equivalent to what was known as slave mode.
The second change is that the scheduling of step and event handlers has been fixed (it has bothered us for years) so now if an event occurs at the end of a step, the step handlers is called first and the event handler called afterwards.
Yes, this is the maxCheck setting in the EventDetector. As event detectors are generally implemented by extending the AbstractDetector class, the classical way to set up a custom max check is as follows:
SomeDetector detector = new SomeDetector(...).
withMaxCheck(maxCheck).
withThreshold(threshold).
withHandler(myHandler);
propagator.addEventDetector(detector);
Note that the withXxx methods rely on the fluent API, i.e. you must use the object returned by the withXxx() method and chain them as shown.
The principle of the maxCheck setting is that regardless of how the propagator runs, the g function that defines the event will be called at least once every maxCheck seconds. If the propagator is a numerical propagator that already has an internal step size, the g function may be called more often if this step size is small. If on the other hand the propagator is an analytical propagator without any notion of step size or if the propagator is a numerical propagator with a large step size, then this setting will trigger intermediate calls to the g function. If the function changes sign between two calls, then it means an event occurs in between and a root finding algorithm is run to locate it accurately, down to the precision set in the threshold setting.
The maxCheck value is chosen according to the separation between events in a pair. It is not perfect, of course, and no practical implementation can be perfect: if some specific event detector triggers a pair of events with a femtosecond separation, you will probably miss it (but it is probably not a serious problem since too close events generally cannot be used for anything practical). As an example, when you set up an ElevationDetector for computing the ground control schedule for telemetry and telecommand, you don’t care about cases when the satellite raises above ground and sets back below horizon less than 60 seconds later, you will not have time to do anything and signal will probably be poor, so you just use 60s for maxCheck and don’t care if you miss such close pairs of events.
There are default settings for maxCheck for most events, but they are only arbitrary defaults, you should use your own settings depending on your use of events. Using a very small maxCheck (say one second or below) is often a bad idea, it will just waste time.
Note also that maxCheck is unrelated to tolerance. The first one is used just to bracket roots and trigger root search whereas the second is used for the convergence check once the root search has been triggered. You can have a maxCheck set to 60s or even one hour (if you are only interested in widely separated events) but still have a tolerance set to 1µs if you want.