Some Context: The project I am currently working on involves using an unscented Kalman filter to track estimation errors for orbits of objects in the LEO/VLEO regime. This involves sampling the covariance ellipsoid for an orbit estimate, propagating all of those samples forward, then using the resulting point cloud to reconstruct the ellipsoid at a later date. The problem: points within the ellipsoid can go to some very nonphysical places while the mean orbit itself remains physical.
In particular, I have a VLEO test case where one of the points is intersecting the Earth’s surface. Since this intersection makes nearly every force model in Orekit unhappy (via the Brillouin sphere exception), I have been attempting to find simpler force models to switch to during the low altitude swings (via an altitude detector propagator swap) so that I can get some estimate for these challenge points. At present, I am only using Newtonian gravity and an exponential isotropic atmospheric drag model, and I am seeing some weird results from the numerical propagator:
The black circle is the center of the Earth, the Blue circle/lines are the propagated orbit, and the vectors are instantaneous velocity. The point of interest is in the lower left of the figure where the orbit drastically changes direction.
To clarify, the above is not using multiple propagators, but rather only the single simplified one. However, when it intersects the Earth’s surface, it goes on its merry way in an entirely nonphysical direction and no longer appears to be gravitationally attracted to the earth.
Any insights as to what might be causing this? Is it a bug or intended behavior? I am currently pursuing an alternate solution to my original problem, but this is driving me crazy!
To be clear, the code is set up to restart the propagator after the altitude detector triggers (with the intent of using a different force model). For the above test case though, it is restarting a duplicate of the original propagator object (with new ICs) for debugging purposes. I would expect the same motion to continue if this were working properly.
Additionally, if it were to stop propagating completely, wouldn’t that just stop generating new points? Why would it start drifting in a nonphysical direction?
Can you show us how your reinitialise the propagator?
Also, do you remove the AltitudeDetector afterwards? Otherwise it might just stay where it stopped. Have you checked the dates for your points?
Unfortunately, I can’t paste the code here (I apologize, I know that is the quickest way to resolve this but my hands are tied).
To answer your question though, we tried a number of approaches for reinitialization with all having identical results to the above.
Overview: At startup, we initialized two propagators using the same setup method and inputs (i.e. perfect duplicates), each with the altitude detector set to trigger on either increasing or decreasing (note this only ever triggered once in practice). After the detector triggered, we would restart the other propagator from the returned state / time.
Within the detector, we tried both Action.Stop (switching propagator objects) and Action.ResetDerivatives (trying to continue with the same propagator object)
In the outer loop, we tried both the resetInitialState and resetState methods to re-initialize the second propagator to continue from the last returned state.
Regarding your second point, why would the detector halt the propagation (while allowing time to continue increasing) after it already crossed the threshold? I assume the recursion used to determine the crossing time would ensure to return a time after the event crossing to avoid getting locked up on such scenarios?
Finally, I have not internally verified the dates for the points, but they are enforced by an interpolator. Things would need to be very broken indeed for those to be wrong.
