Discrepancies between DSST propagator (mean propagation type) and STK for J2 Perturbation

Hi, I am currently trying to use DSSTPropagator to simulate an orbit with J2 perturbations. I compared the results with STK J2 perturbations, but there are discrepancies. The discrepancy can be around 1.5km after 5 days. Did anyone also run into this issue? How could I generate the same results as STK?
Thanks so much in advance!


I believe this could be related to this issue.
It is resolved in the development branch and will be part of the next major release of Orekit. If you’re using the python wrapper I’m afraid you’re gonna have to wait for the latter, except if you’re brave enough to compile it yourself :sweat_smile:


Hi Serrof,
Thank you for your quick reply!
Actually, I do not need the J2 squared term or a numerical integrator. I am just using DSSTPropagator to simulate a simple analytical propagator for only secular drifts of the orbital elements. Please see my current code below.

initialOrbit = KeplerianOrbit(a, e, i, omega, raan, lv, PositionAngle.TRUE, inertialFrame, initialDate, 398600441500000.0)
integrator = ClassicalRungeKuttaIntegrator(43200.0)
dsstProp = DSSTPropagator(integrator, PropagationType.MEAN)
dsstProp.setInitialState(SpacecraftState(initialOrbit), PropagationType.MEAN)
provider = GravityFieldFactory.getUnnormalizedProvider(6378137.0, 398600441500000.0, TideSystem.UNKNOWN, [[0.0], [0.0], [-earthJ2]], [[0.0], [0.0], [0.0]])
dsstProp.propagate(initialDate, initialDate.shiftedBy(float(step)))

Do you think I missed anything in my code?
Thank you!

I don’t see anything obvious. Your stepsize might be a bit large if you’re in LEO, what is your orbit?
Anyhow, I’m no semi analytical theory specialist, but I don’t know if it makes much sense to convert mean elements into Cartesian coordinates. How big is the difference when you compare the mean elements directly?


@Serrof is right about the differences between Orekit DSST and STK J2 perturbations.

Please note that you can use a variable step integrator for LEO satellites. The value of 43200 seconds is usually used for GEO or MEO satellites. For LEO, I recommend you to use a variable step size with a min step of 1 orbital period and a max step of 10 orbital periods.


Thank you both @Serrof and @bcazabonne !

My orbit is LEO. For the mean elements, a, e, and i remain the same values. Mean anomaly is the same as STK! However, omega and raan are not the same as STK, although the differences are small (about 0.02 degrees for omega and 0.005 degrees for raan after 5 days)

I tried a variable step integrator as below:
tol = DSSTPropagator.tolerances(1.0, initialOrbit)
integrator = DormandPrince853Integrator(minStep, maxStep, tol[0], tol[1])
However, the results are almost the same as the fixed step size (the differences are very tiny and can be negligible).
Actually, does it really matter about the step size of the integrator? I am simulating an analytical propagator with mean elements and not using those short periodic terms so maybe the numerical integrator does not really matter? (My question may be silly since I am a new guy in this field.)

Thank you!

Hi again,

The steps do matter with semi analytical models such as DSST. They propagate the mean dynamics which translates into much slower variables and the size can be fairly larger than for full numerical, but it’s still numerical integration. Converting to osculating elements is not part of the process per se, it’s an extra operation than can be done if that’s what you’re interested in.

I know that may sound silly, but have you checked that you’re not swapping angles at some point? In Orekit the argument of periapsis usually comes before the RAAN in constructors, which you correctly used in your code. I’ve made that mistake myself before, as I was not used to that convention.

Besides, I’m not sure how DSST compares with secular J2 motion propagated analytically.


Thank you for your reply Romain!
I tried different step sizes and variable step sizes, but the results are not very different. I do not need osculating elements because I know STK uses mean elements.
I have checked that there is no error in the input angles. I tried KeplerianPropagator as well, and the results are the same as TwoBody propagator in STK, so I think there is no mistakes about how I use Orekit. But no idea why the results for J2 are different…
Thanks for your help!

Hi @xl6358,

Welcome to the forum !

Do you know what’s under the hood of these J2-mean elements in STK ?
Mean elements usually depend on the underlying theory. In Orekit there are different ways to compute mean elements. DSST, as you already found out, but also Brouwer-Lyddanne or Eckstein-Hechler theories (these last two are analytical while DSST is semi-analytical).

Hi, I do not know about the details of the J2-mean elements used in STK. I have already tried Brouwer-Lyddanne and Eckstein-Hechler in Orekit, but their results are much more different from STK. This is because they use osculating elements although they are analytical. I tried to find a way to use mean elements in Brouwer-Lyddanne and Eckstein-Hechler, but I did not manage to do that.

@xl6358 what Orekit version do you use?

I think that adding a DSSTJ2SquaredClosedForm could improve the consistency. But this class is currently available only in the development version of Orekit…

For osculating to mean conversion for a single state, you can use the computeMeanOrbit() method. It is implemented for each model.

For orbit propagation, the two models return osculating parameters. Having the possibility to choose between MEAN or OSCULATING propagation (like DSST do) for Brouwer-Lyddane and Eckstein-Hechler is something very interesting that we should have in Orekit. I think it is something easy to implement since these two models well separate the mean and oscillating terms.


Agreed, we should definitely open an issue for this

Well, talking about API improvement to models, I was thinking that for the DSST it’d be nice to be able to propagate a given set of perturbations (so for the mean elements), but give the possibility to use a different set for the osculating outputs. A typical application would be to retrieve them only with J2 (as it is the dominant one usually over a couple of revolutions) in order to save some computational time. What do you think?



Could the difference between DSST and STK J2 be due to long-periodic variations?
If Orekit’s DSST has single-averaged zonal harmonics (averaged over mean anomaly only) then long-periodic variations (e.g. due to changing argument of perigee) are still present in addition to secular variations. The analytical zonal propagator I assume only considers secular variations.


Good point @dgondelach

Btw I found this on the internet about the STK analytical models.

@bcazabonne The version I use is 11.3.1. From the name of DSSTJ2SquaredClosedForm, J2 squared will be used? If so, then I do not think I need this since J2 perturbation only include J2 term (no J2 squared term).

I tried this method, but the resulting mean elements are not stable, and so the position results are still not the same as STK. For example, a, i, and e should remain the same all the time, but the values from this method are oscillating around the assigned values.

@dgondelach Based on my knowledge, long-periodic variations should be from J3 term, right? Since I only include J2 term, I think it should not have long-periodic variations.


The effect of J2 depends on the location of the perigee. As the argument of perigee precesses, the J2 effect changes slowly over time. This variation is periodic with the argument of perigee. Since the argument of perigee precesses slowly, it is called long-periodic. See for example the discussion on the first three pages of this paper by Kozai (https://articles.adsabs.harvard.edu/pdf/1959AJ.....64..367K).
I do not know the Orekit DSST implementation, but maybe it considers this long periodic variation. What you could do is check if the differences between DSST and STK J2 show a periodic behaviour with a period equal to one revolution of the argument of perigee.
Maybe it is not this that you are seeing, but it is a possibility.