Discovered potential edge case in Eclipse detection routine

I believe I have discovered an apparent edge case in the Eclipse detection routine (using Python wrapper). I have a standard mid-inclination orbit propagated for 180 days and am searching for umbra events as follows:

umbra_logger = EventsLogger()
orekit_ephemeris = Ephemeris(orekit_sc_states, 10) 
umbra_detector = EclipseDetector(sun, Constants.WGS84_EARTH_EQUATORIAL_RADIUS, earth).withUmbra().withHandler(RecordAndContinue())
orekit_ephemeris.addEventDetector(umbra_detector)
orekit_ephemeris.addEventDetector(umbra_logger.monitorDetector(umbra_detector))
result = orekit_ephemeris.propagate(orekit_ephemeris.getMaxDate())

but the routine fails on the last line with the following error:

JavaError: <super: <class 'JavaError'>, <JavaError object>>
    Java stacktrace:
org.orekit.errors.OrekitException: point is inside ellipsoid
	at org.orekit.bodies.Ellipsoid.pointOnLimb(Ellipsoid.java:251)
	at org.orekit.propagation.events.EclipseDetector.g(EclipseDetector.java:182)
	at org.orekit.propagation.events.EventState.g(EventState.java:153)
	at org.orekit.propagation.events.EventState.lambda$findRoot$0(EventState.java:314)
	at org.hipparchus.analysis.solvers.BaseAbstractUnivariateSolver.computeObjectiveValue(BaseAbstractUnivariateSolver.java:166)
	at org.hipparchus.analysis.solvers.BracketingNthOrderBrentSolver.doSolveInterval(BracketingNthOrderBrentSolver.java:297)
	at org.hipparchus.analysis.solvers.BracketingNthOrderBrentSolver.solveInterval(BracketingNthOrderBrentSolver.java:426)
	at org.hipparchus.analysis.solvers.BracketedUnivariateSolver.solveInterval(BracketedUnivariateSolver.java:126)
	at org.orekit.propagation.events.EventState.findRoot(EventState.java:320)
	at org.orekit.propagation.events.EventState.evaluateStep(EventState.java:218)
	at org.orekit.propagation.analytical.AbstractAnalyticalPropagator.acceptStep(AbstractAnalyticalPropagator.java:311)
	at org.orekit.propagation.analytical.AbstractAnalyticalPropagator.propagate(AbstractAnalyticalPropagator.java:168)
	at org.orekit.propagation.AbstractPropagator.propagate(AbstractPropagator.java:260)

Interestingly, if I change the Ephemeris interpolation point setting from 10 to 5 or 2, the run succeeds and no error is produced. I also tried a value of 30 but the same error manifested. I am unsure why the error production is dependent on the number of Ephemeris interpolation points nor what exactly the org.orekit.errors.OrekitException: point is inside ellipsoid error is suggesting. I unsuccessfully searched the documentation and code for answers so was hoping someone could point me in the right direction to determine what the root cause is or suggest what sort of edge case may be occurring here. Is a value of 10 too much for Ephemeris interpolation? Running many other mid inclination orbits or sun synchronous orbits with similar initial conditions work just fine…but for some reason this one ephemeris produces the above behavior and I am unsure where to look to understand this better.

This error means that the position of the satellite is withing the Earth ellipsoid (i.e. its altitude with respect to surface is negative). In this case, we cannot find where the horizon is, which is used for eclipse computation.

Does your ephemeris has a large or a small step size? Is the trajectory very close to Earth?

Using 10 points for ephemeris interpolation is quite large. Interpolation is based on polynomials, so it attempts to stick exactly on points (interpolation is not smoothing!), and when a large number of points are used it is sensitive to very small points displacements (numerical noise, truncation to too few significant numbers in files…) and you may experience Runge phenomenon with high oscillations between nodes.

Hi Luc,

This makes quite a lot of sense after thinking it through. The orbit has 180 second time steps and is a relatively Low Earth Orbit. With my previously large interpolation point setting, it would make sense that the Runge phenomenon could cause a point to be within the Earth ellipsoid. Reducing the number of points to 2-3 and observing successful runs with this setting essentially confirms this theory.

Would you have a recommended interpolation point setting for a 400-500 km orbit with 180 second time stamps? I’ll likely pick 2-3 as that seemed to work well.

Many thanks for the detailed response and explanation, much appreciated.

-Justin