I was just wondering if what I am observing with the Propagator is a normal behaviour. The following are the steps I am currently performing
Create an initial state without attitude and any additional states (calling this as initial_state)
Set initial_state as the initial state to a propagator
Adding some AttitudeProvider and AdditionalStateProvider to the propagator
Propagate to the same time instant as initial_state (initial_state.getDate()), basically a zero duration propagation.
Then when I retrieve the state at the end (it never really started!) of the propagation, this is same as initial_state but I was expecting to have proper attitude and additional states too.
I just wanted to confirm if it is a normal behaviour or it would make sense for us to recompute the (initial) state with new providers added to the propagator.
What propagator do you use?
(I ask the question to reproduce the problem)
What is the behavior if you perform?
propagator.propagate(initial_state.getDate(). shiftedBy(-1.0e-6), initial_state.getDate());
I know that event detectors for which the event occurs at the epoch of the initial state of the propagation are not taken into account. The workaround is to shift a little bit the initial epoch of the propagation.
I am currently using NumericalPropagator but I guess the results would be similar with DSSTPropagator as well.
This propagator.propagate(initial_state.getDate(). shiftedBy(-1.0e-6), initial_state.getDate()); is producing the results as expected, as there is a small finite amount of duration to propagate.
I have also noticed the following, when I generate the ephemeris (for some finite time) using getGeneratedEphemeris, the BoundedPropagator I get seems to be having proper initial_state though. Is this an inconsistency?
Yes, it will be the same for all integrated orbit propagators (i.e., DSST and/or numerical). This behavior is normal and expected according to the Orekit source code (see (src/main/java/org/orekit/propagation/integration/AbstractIntegratedPropagator.java · develop · Orekit / Orekit · GitLab) [AbstractIntegratedPropagator.java]. Because you want to propagate at the epoch correspong to the initial propagator state, it is expected for computational efficiency to directly return the initial spacecrat state of the propagator, without any additional computation or numerical integration. The workaround is to shift a little bit the initial propagation epoch using the example I provided in my previous comment. For analytical orbit propagation, the story is different. Because analytical orbit propagators use a specific input data to be initialized (e.g., a TLE for SGP4 or SDP4, and an almanac for GNSS), performing an orbit propagation at the data epoch has an impact on calculated spacecraft state. Building a SpacecraftState using the values contained in the input data is prone to error, for both TLE or GNSS almanac. The propagation model must be called, even at input data epoch.
No I don’t think. Because the ephemeris propator is an analytical orbit propagator, even the initial state is recomputed when generating the ephemeris.
It seems a bit inconsistent to me that the user gets different behavior with different implementations of Propagator. Would the propagate(...) work correctly if that if statement was removed? Just reading that method it is clear there are many other side effects to calling propagate() besides just returning the computed state. Most of the propagations I do I don’t use the returned state because the whole effect is side effects through step handler and event handlers.