 Discrepancies in results of propagation for different start anomaly

Hello,

While checking the results of the propagation for the same orbit but with a different mean-anomaly at the orbit epoch, I have noticed strange results.

If you look at the attached file, it looks like at 90° the orbit track is much different than the 0° one which I cannot explain. I have done the tests using different propagators only adding the J2 effect and only the DSST considering a mean-orbit looks consistent between 0 and 90.
The Eikstein-Hechler one is also giving a discrepancy.

Would you know what the issue is? In my mind the orbit tracks for both should be the same but slightly shifted (just like the DSST Mean). Is the propagator the issue, or maybe the transform method that transforms the inertial coordinates?

Thank you very much for any insight you may have!

(The DSST Mean was a longer duration simulation compared to the other ones)

Hi Aaron,

I have no immediate answer. Is it possible to send us your code, or at least the part of your code where propagators are initialized and used ? So we can understand the whole context of the propagations and the way you transform the inertial coordinates.

My guess is that you are observing the effects of short period variations in the orbital parameters. For example a=7000km @ θ=0 and a=7000km @ θ=90 have the same osculating semi-major axis but will have different mean semi-major axes. From the plots it looks like your’re trying to model a repeat ground track orbit so small differences in the mean semi-major axis will cause the ground track to drift over time.

Hi you will find below the code I use but it is the same code that initializes the orbit that is then passed onto the propagator. The only thing I have changed is the anomaly of the orbit epoch for the figures from the left to the right.

Another person I know has noticed the same behavior. I am basically initializing a SSO orbit with:
a = 6928137m, i = 97.594, again only difference between the 2 plots is the anomaly which should not make the ground track all that difference from my understanding.
I can’t understand why the results from the Eicklein-Hechler would be different from the DSST Mean either.

Maybe the coordinate transformation is doing something funny but then I can’t understand why it would look fine for 0° and different for 90°.
Code involved:

Orbit initialization (I have also tried initializing with an Equinoctial orbit resulting to the same behavior):

``````this.initialOrbit = new KeplerianOrbit(a, e, Math.toRadians(i),
this.inertialFrame, startDate, Constants.EGM96_EARTH_MU);
``````

propagator initialization:

``````if (propagatorParameters.type == PropagatorKind.NUMERICAL) {
NumericalPropagator numericalPropagator = new NumericalPropagator(integrator);
this.setForces(propagatorParameters.forces, earthFrame, numericalPropagator);
numericalPropagator.setInitialState(new SpacecraftState(this.initialOrbit, mass));
this.propagator = numericalPropagator;
} else if (propagatorParameters.type == PropagatorKind.DSST) {
DSSTPropagator dsstPropagator = new DSSTPropagator(integrator, !propagatorParameters.considerOsculatingOrbit);
dsstPropagator.setInterpolationGridToFixedNumberOfPoints(3);
this.setForces(propagatorParameters.forces, earthFrame, dsstPropagator);
dsstPropagator.setInitialState(new SpacecraftState(this.initialOrbit, mass), propagatorParameters.considerOsculatingOrbit);
this.propagator = dsstPropagator;
}

this.propagator.setAttitudeProvider(attitudeProvider);
``````

Coordinates transformation in the StepHandler using a master-mode propagation:

``````public void handleStep(SpacecraftState s, boolean isLast) {
AbsoluteDate date = s.getDate();
PVCoordinates coord = s.getPVCoordinates();
Vector3D pos = coord.getPosition();

GeodeticPoint latlong = this.earth.transform(pos, this.eme2000, date);
Vector3D itrfpos = this.eme2000.getTransformTo(this.earth.getBodyFrame(), date).transformPVCoordinates(coord).getPosition();

// These coordinates are then just printed out
}
``````

I have also tried to print out the ITRF cartesian coordinates in 3D and we can see the same discrepancy.

I do expect the orbit to drift with the J2 effect. But I do expect them to drift the same way (as shown in the DSST propagator considering mean elements)

STK with a J2 propagator drifts the same way for both 0° and 90° of anomaly. This is consistent with DSST mean orbit, but not Eickstein-Hechler.

As Evan said, the problem probably comes from the conversion between mean and osculating SMA. The different propagators consider the input orbit as osculating elements, but the DSST Mean propagator does not compute short period terms, so there is no difference between osculating and mean elements. It is probably the case for the J2 propagator you use in STK too, I can’t say.

In your case, if you draw the osculating SMA for your 2 orbits, you will see a difference of ~20km in the mean SMA of the 2 orbits, which can fully explain the drift rate difference :

In red the osculating SMA of the “0°” orbit, in green the osculating SMA of the “90°” orbit

Ok I understand but when I set the forces for the numerical and DSST Osculating I only set the force coefficients provider for (2, 0). Would that still compute short period terms?

Also does it mean that the Eikstein-Hechler set for J2 only compute these?

Thanks for your answer. It is not linked to the force model, but to the elements computated by the propagator. Since you consider the J2 in the forces model, you will find short period terms in the propagation.
The difference is that the DSST “mean” propagator does not compute these short period terms and only computes the long time drift of the mean elements. This is probably the case for the STK propagator you used.

The other propagators will compute these osculating short period terms if J2 is in the forces model, no matter if they are analytical or numerical.

What you should keep in mind is that the initial orbit must be in osculating elements, except for explicit cases like DSST mean propagator.

1 Like

Ok I understand, so basically to have the same mean semi-major axis of A, I would have to compute the actual sma associated to the anomaly before giving it to the propagator since as you have shown neither of them have a mean sma of the value that was passed.

I see a osculating to mean parameter converter built-in in Orekit but does the other way exist?

Again, thank you a lot for the explanation.

Hi Aaron,

Maybe DSSTPropagator.computeOsculatingState method is what you are looking for ?

Hope this helps.
Maxime

1 Like

I have implemented on the side a first-order mapping to get these elements but I will haev a look at that method as well.

Thanks a lot 