Thank you @evan.ward for the investigation and @dl00718 for the test and information,
Evan, your solution would indeed fix the problem !
I’ve played around a bit with dl00718 code and found the following info that can help.
I added a step handler
dsstProp.getMultiplexer().add(new OrekitStepHandler() {
int nStep = 0;
@Override
public void handleStep(OrekitStepInterpolator interpolator) {
SpacecraftState s = interpolator.getCurrentState();
double stepSize = s.getDate().durationFrom(interpolator.getPreviousState().getDate());
System.out.format(Locale.US, "Step %d - dt: %10.3f days / step: %10.3f s / Alt: %10.3f km\n",
nStep++, s.getDate().durationFrom(initDate) / Constants.JULIAN_DAY, stepSize,
(s.getPVCoordinates().getPosition().getNorm() - Constants.WGS84_EARTH_EQUATORIAL_RADIUS) / 1000.);
}
});
Then I’ve tried some (minStep / position tolerance) configurations for the integrator:
minStep = 3600.
dP = 10.
→ (default config) Crashes with HarrisPriester minimum altitude exception
minStep = 3600.
dP = 0.1
→ Crashes with Hipparchus ODE message: MINIMAL_STEPSIZE_REACHED_DURING_INTEGRATION. The integrator tries to reduce the step to fulfill the constraint of 0.1m on the position tolerance but cannot because the minStep is too big.
minStep = 60.
dP = 0.001
→ Working combo: After around 1540 days, the altitude detector kicks in with no crash. Last step is around 60s and truncated at ~41s by the detector.
So, ultimately, it is a configuration issue of the integrator.
Reducing minStep and dP does not impair DSST performances because the maximum step size of 2 days is used until altitude gets below ~270km (after 1513 days of propagation) and the integrator starts reducing the steps.
As a user, I would like the integrator to reduce the step duration until the minimum step size is reached and throw an exception like in the second case above.
That way I would know what to do to improve the configuration, which I found is not explicit with the first case (altitude is too low).
To me, this looks like the multiple questions we had on the forum with an exception thrown due to a negative eccentricity (see this thread for example, though it is related to initial time step only and can be fixed differently).
So I was wondering if, on top of Evan’s proposition, we couldn’t implement a mechanism that would invalidate an integrator step given some exceptions (altitude too low, negative eccentricity etc.).
That way the integrator would try to reduce the step until the minimum is reached instead of blindly throwing the exception and leaving the user in the dark.
That would require implementing a specific exception type extending OrekitException and catching it at integrator level.
I haven’t checked if it is doable with current Hipparchus or Orekit APIs though.
Do you think that it makes sense ?