# Exception during findRoot in EventState

Hello,

We encounter a problem with the detection of visibility events for a station with an elevation mask.
An exception is raised saying that the selected interval has no root.
After investigation, it seems related to the numerical accuracy of the conversion between absolute dates and relative dates used by the BracketingNthOrderBrentSolver.

Extract of findRoot in EventState class:

``````                final AbsoluteDate fT0 = loopT;
final UnivariateFunction f = dt -> {
return g(interpolator.getInterpolatedState(fT0.shiftedBy(dt)));
};
// tb as a double for use in f
final double tbDouble = tb.durationFrom(fT0);
if (forward) {
try {
final Interval interval =
solver.solveInterval(maxIterationCount, f, 0, tbDouble);
beforeRootT = fT0.shiftedBy(interval.getLeftAbscissa());
beforeRootG = interval.getLeftValue();
afterRootT = fT0.shiftedBy(interval.getRightAbscissa());
afterRootG = interval.getRightValue();
// CHECKSTYLE: stop IllegalCatch check
} catch (RuntimeException e) {
// CHECKSTYLE: resume IllegalCatch check
throw new OrekitException(e, OrekitMessages.FIND_ROOT,
detector, loopT, loopG, tb, gb, lastT, lastG);
}

``````

If I compute g(interpolator.getInterpolatedState(tb)), I get something around 5e-14
But if I compute f(tbDouble) that should gives me the same value, I get something with an opposite sign (for example -2e-15).
So g(interpolator.getInterpolatedState(fT0)) and g(interpolator.getInterpolatedState(tb)) have opposite signs which is correct for the search of a root, but f(0) and f(tbDouble) have not and an exception is raised in Hipparchus

On the interval, the trajectory seems tangent to the mask of the antenna because we have something like: g(interpolator.getInterpolatedState(fT0)) = -1e-12
g(interpolator.getInterpolatedState(tb)) = 5e-14.

Is there a workaround or correction for this problem that can be used ? Configuration of the propagator or the detectors/handlers ?

Thanks!

This is a bug.
The fact the trajectory is tangent is not the cause of the problem. I was finally able to reproduce it (it was not easy) even with a basic date detector that has a `g` function with a clean and obvious zero.
I have created issue 921 and am looking at how to solve it.

Thanks for the report!

Issue has been fixed in the develop branch.

Hello Luc,

Thank you for the investigation and the correction!