I realize I did not explain the role of `maxCheck`

.

As explained in my previous post, the propagator/ODE integrator checks the registered `g`

functions (by the way they are sometime called switching functions) to see if they change sign during the possible next step.The check is performed by evaluating the `g`

function value and compare it to the value we got from previous check and see if sign changed between the two checks. If the sign changed, then we know that there is at least one zero crossing in between, and then we run a root finding algorithm to locate this crossing accurately (i.e. down to the `tolerance`

setting). We will *not* run the root finding if the sign is the same as the sign of the previous check.

Checking the `g`

function only once during each step would miss some zero crossings if the next step is too long (in fact if an even number of roots occur during the step, we would miss them). This is important in numerical propagation if the numerical propagator uses an adaptive step size integrator with a large `maxStep`

, and it is even more critical in analytical propagators which depending on the configuration may use only one step from start to end.

So in order to work around this problem, the `maxCheck`

parameter is used. It means that the propagator/ODE integrator must check the `g`

function value *at least once* every `maxCheck`

seconds (and also at least once every step, even if steps are shorter than `maxCheck`

). The `g`

function of `ElevationDetector`

is the elevation angle minus the current min elevation, so it is positive when spacecraft is above horizon, negative when spacecraft is below horizon, and zero at raising/setting time). If this detector uses a 60s `maxCheck`

and the propagator has a current step size of 300s, it implies the propagator will check the `g`

function value (i.e. the spacecraft elevation above current horizon) at least 5 times during the step. So as long as raising/setting events are separated by at least 60 seconds, we will not miss them as we will notice the sign change of the associated `g`

function, start the root finding and locate the horizon crossing to millisecond accuracy if `tolerance`

was set to 10⁻³ s). If the spacecraft trajectory is such that it raises barely above horizon and immediately sets back below it in less than one minute, we will probably miss the event pair (we may find it if the check date luckily occurs during the short above horizon period, but it is not likely).

For `ElevationDetector`

, this default 60 seconds `maxCheck`

corresponds to classical operational constraints: you generally don’t care about too short visibility intervals. They are too short to do anything useful and too close to the limits so are expected to have a noisy radio link. Not bothering about missing too close events pairs is therefore fine there. For other detectors, we may be concerned about missing a pair of events, so we have to set up a shorter `maxCheck`

, but the price is high: we will evaluate the `g`

function many times, even when it is in a stable domain far from roots.

There is no way we can guarantee for any continuous function that we will always find all crossings and never miss a pair. In fact, it is simple to design a `g`

function that has arbitrarily close pairs of roots just to demonstrate that we are doomed. Setting `maxCheck`

properly is a compromise.

It is important to understand the difference between `maxCheck`

and `tolerance`

. `maxCheck`

is an often quite large value (order of magnitude of minutes or hours in space flight dynamics) that is used to bracket roots and start a root finding algorithm. `tolerance`

is an often quite small value (order of magnitude of milliseconds or microseconds) that is used as a convergence criterion for the root finding algorithm.