I am testing out NumericalPropagator using the Orekit Tutorial Code. ( Orekit tutorial 11.3 → propagation package → Numerical Propagator).
The propagator doesn’t produce the same PV state when propagated backward and forward between two different dates.
For example,
final NumericalPropagator propagator = new NumericalPropagator(integrator);
propagator.setOrbitType(propagationType);
// removing all force models except central attraction
propagator.removeForceModels();
// Set up initial state in the propagator
propagator.setInitialState(initialState);
// Set up an end date
AbsoluteDate finalDate = initialDate.shiftedBy(24*3600.0);
System.out.println("Initial State = "+initialState.getPVCoordinates());
for(int s=0;s<3;s++) {
SpacecraftState finalState = propagator.propagate(finalDate);
System.out.println("Final State = "+finalState.getPVCoordinates());
SpacecraftState startState = propagator.propagate(initialDate);
System.out.println("Start State = "+startState.getPVCoordinates());
}
I assumed the satellite state would be the same at the same time stamp. I appreciate it if someone can explain why the propagator is behaving like this.
I would like to add that this does not happen with GEO satellite. I used a continuous scheduler with GEO. When propagated back and forth between two says, the state is the satellite was the same each iteration at the same time stamp.
This can come from the combination of integrator accuracy settings and in-step interpolators.
First, you can try to reduce the settings when calling NumericalPropagator.tolerances. In the tutorials, the settings are huge: 10m. We now recommend something much smaller, like 1mm or so. This should improve things a lot.
The settings above correspond to an threshold that is compared by the ODE integrator with an estimated error at the end of each step. The step is accepted if the error is below the threshold, and rejected if above. Then a new step size is computed, which will correspond to either next step if step was accepted, or a new attempt on current step if step was rejected. Once a step is accepted, the internal model used by the integrator is used to set up the step interpolator that will be provided to the caller (mainly for the sake of events detection and step handlers). It is important to note the the error is only estimated (if we could compute the exact error, we would compensate it and the output would be perfect), and it is on one step only, so it will build up over a complete propagation. With the current 10m settings, you can expect hundred of meters or kilometers errors after some time.
When we use integrators, the stop date may also differ from final step date, mainly when using stop events. In this case, another error can creep in : the state at event time is interpolated. One often overlooked part of step interpolators is that they are less accurate in the middle of the step than at end points. This is because the so called order conditions that are used to select integrators internal coefficients (the Butcher arrays in the case of Runge-Kutta like integrators) are set up so that error is minimal at the end of the step, by cancelling some terms. These conditions do not hold in the middle of the step, hence the integrator exhibits a bumpy behavior, with very accurate end points (say order 8 error for example) but less accurate intermediate points (say order 7 for example). So when a propagator is stopped by an event occurring in the middle of a step and then restarted (in the same direction or in the opposite direction), the second propagation will be slightly off. I guess this does not happen for propagation ending regularly at a specified target date (I think we truncate last step size before step is computed), but am not sure.
So in your case, just reducing the tolerance should be sufficient.
