Propagation with Keplerian Elements but Different Results

Hello everyone,

I was trying to use the numerical propagator (with DormandPrince853Integrator) and noticed something which I think is odd. I were hoping to get ideas here if not answers. So basically what I did was running the same numerical propagation with same Keplerian elements. The only variable here was the way that I acquired those Keplerian elements:

  • In the first way, I used the following bit:
initialOrbit = CartesianOrbit(TLE_pv, ECI, initialDate, Mu_earth)
initialState = SpacecraftState(initialOrbit, satellite_mass)            
keplerElements = OrbitType.KEPLERIAN.convertType(initialState.getOrbit())
  • In the second way, however, I have utilized same position and velocity vectors with the algorithm (the one for obtaining orbital elements from state vectors) provided by Howard D. Curtis.

These options give nearly identical orbital elements, except for perigee argument, RAAN and true anomaly. For example, if I recieve RAAN = 170 degrees in the second method, it appears to be -190 degrees in the first way; which are clockwise/counter-clock wise pairs.

Anyway, getting the propagated PV vectors at the final time differs slightly when comparing these two methods. When comparing the results of both ways the with SGP4 propagator result, RMS is around 5000 with first way, while the second way gives and RMS around 5000.

Any idea why this happens? Thank you in advance for the discussion.
Baris

Hi @Echulion, welcome

This is expected behaviour as -190 = 170 - 360, so it is really the same angle. See this post for a throrough explanation.

What error do you get for perigee argument and anomaly? If your orbit is very close to circular, then the perigee location is singular and you may end up with perigee argument increased by some random angle (say 10°, but can really be anything) when the anomaly is decreased by the exact same amount. What is stable, though is the sum ω+v. In other words if one propagator gives ω=100° and v=32° and the other propagator gives ω=110° and v=22° for a circular orbit, it is just because the perigee is not defined for this orbit, but both results are consistent. In this case, one should use other representations like CircularOrbit or EquinoctialOrbit (or stay with CartesianOrbit).

This is correct behaviour. The SGP4 propagator is not a Keplerian propagator it includes some approximations of mean evolution of a few forces. This implies that instantaneous position given by a TLE propagator cannot be used as an initial orbit for another propagator, regardless of the model you use. If you attempt to compare it to a Keplerian propagator, you will miss the perturbations SGP4 uses internally. If you attempt to compare it to a numerical propagator, SGP4 will miss the accurate definition of forces. In addition in both cases, you will be comparing osculating parameters when SGP4 provides mean parameters. The order of magnitude of the short periodic terms between these two models are of the order of magnitude of several kilometers, this is what you observe.

If you want to go from TLE to anything else, rather than just use one point you should use a full model conversion over several orbits (typically one day). There is a tutorial about that.

1 Like

Hello @luc,

Thank you for the thorough explanation. For this instance my eccentricity is 0.0003134 and the error of perigee argument is 0.16678708365 degrees.

The second argument you made is also what I would expect from SGP4, Keplerian or Numerical propagators. But this brought up another fundamental question in my mind. So TLE data should only be used with TLE propagator (SGP4), okay. But many sources such as CelesTrack and Space-track provide satellite state with TLE.

I did not really understand what you mean by full model conversion over several orbits. Searched quickly through tutorials as well but couldn’t match your comment with any of those.

Yes, the availability of data is the only reason why TLE is in widespread use. The only other large public orbital data repository you can find is CDDIS, and it is accurate at a few centimeters levels. However it has only navigation satellites data.

For conversion, you should look at PropagatorConversion.java

1 Like