I just now encountered what to me looks like a bug when extracting a state from a BoundedPropagator (resulting from an EphemerisGenerator). Basically, because of floating point errors in python (numpy) I accidentally generated a timestamp which is outside the ephemeris range (by ~3 ms). When I used this time vector to query the BoundedPropagator no error is thrown, but instead the final state is completely wrong (position in the order of 1e34).
There is a margin of 1s when querying an IntegratedEphemeris. See code snippet:
// compare using double precision instead of AbsoluteDate.compareTo(...)
// because time is expressed as a double when searching for events
if (date.compareTo(minDate.shiftedBy(-EXTRAPOLATION_TOLERANCE)) < 0) {
// date is outside of supported range
throw new OrekitException(OrekitMessages.OUT_OF_RANGE_EPHEMERIDES_DATE_BEFORE,
date, minDate, maxDate, minDate.durationFrom(date));
}
if (date.compareTo(maxDate.shiftedBy(EXTRAPOLATION_TOLERANCE)) > 0) {
// date is outside of supported range
throw new OrekitException(OrekitMessages.OUT_OF_RANGE_EPHEMERIDES_DATE_AFTER,
date, minDate, maxDate, date.durationFrom(maxDate));
}
return model.getInterpolatedState(date.durationFrom(startDate));
The comment by @evan.ward suggests that this is so that event detection doesn’t fail.
I don’t know if following @luc’s recent update on AbsoluteDate, this is still relevant?
If the event detector is used in a numerical propagator (and probably DSST too), then it is delegated to Hipparchus and still based on floating point numbers.
Yes, though a better solution would be to make sure event detection doesn’t ask for a date beyond the end of a step. Though that is hard because an AbsoluteDate might round to a double that is outside the bounds.
The comparison used to be based on double values to fix #283. Which should be good enough for the event detection. Later I changed it to a 1s tolerance in 631ddf62, but I don’t remember why. The comment still says the comparison is based on double even though it is not. (compare using double precision instead of AbsoluteDate.compareTo(...)) Might be worth revisiting if 631ddf62 can be reverted now that AbsoluteDate has be reimplemented. Or at least decreasing the extrapolation tolerance to a few ULPs instead of 1 s.
