OceanTides in Orekit not aligned with STK

We are trying to align Orekit propagator with respect to STK HPOP and we are having a hard time in matching the ocean tides.

We are running a 10 days propagation including only the ocean tides as a perturbation force in order to specifically see their effect. We ensure that we are using the same reference file to model the ocean tides. We use FES2014 model and we check that the coefficients in the fes2014-Cnm-Snm.dat file that we are using match exactly the ones that STK takes into consideration. We aligned the reference data as well (as in Earth Orientation Parameters, etc.). Also, we made sure to use the same degree and order (16x16) in both software.

We ran different tests for different orbital regimes. Clearly, according to the orbital regime, we obtain a more or less significant impact from the Ocean tides.

These are the deviations we are getting:

  1. LEO – Orekit propagation vs STK

  1. MEO – Orekit propagation vs STK

  1. HEO – Orekit propagation vs STK

We are very surprised by the difference we are getting on the HEO test case, in which we reach a maximum deviation in the order of 130m.

We read a warning comment in Orekit code dated 2013 stating that the Orekit implementation of the Ocean tides should be considered experimental. But 10 years have passed since, so we do not know if that is still applicable.

Also, focusing on the HEO case and comparing the propagation against a simple Keplerian one, we saw that the Orekit implementation drives the satellite in the opposite direction compared to STK.

  1. Keplerian vs Orekit propagation:

  1. Keplerian vs STK propagation:

This is the code snipped we use to instantiate the OceanTides force model:

ReferenceEllipsoid referenceEllipsoid = ReferenceEllipsoid.getIers2010(dataContext.getFrames().getITRF(IERSConventions.IERS_2010, true)); 
new OceanTides( 
    referenceEllipsoid.getBodyFrame(), 
    referenceEllipsoid.getEquatorialRadius(), 
    referenceEllipsoid.getGM(), 
    true, 
    OceanTides.DEFAULT_STEP, 
    OceanTides.DEFAULT_POINTS, 
    16, 
    16, 
    iersConventions, 
    ut1, 
    dataContext.getGravityFields());

How can we align the model with STK?

This comment is not applicable anymore. It was partly due to a sign difference that was unexplained at some time. It is now considered that this sign is correct in Orekit with respect to the reference equations from IERS, and anyway this dubious sign was on a very small parameter, orders of magnitude lower than what you see. Evan did validate tides implementation and published a paper about this: Do Open Source tools rival heritage systems? A comparison of tide models in OCEAN and Orekit

Hi @LordRaptor,

Could you maybe share both configurations, Orekit and STK? (although I don’t know much about STK).
And also the STK ephemeris that you compare with Orekit?

Have you tried starting with a lower degree/order of the tides?

There’s a lot of configuration involved in the computation of the ocean tides. You seem to have taken care of matching the configurations but still, I’m thinking of:

  • The ITRF version that may be different,
  • The astronomical amplitudes file used,
  • Usage of pole tides, points and step for interpolation when building the OceanTides object…

I’m not sure these parameters would have such an effect though

Thanks a lot @luc for your reply and for clarifying that that warning statement is no longer applicable. We will have a look at the paper you linked here and try to see if that might help us in finding out the origin of our issue.

Thanks @luc and @MaximeJ .

As @Hobbites has said, we’ll be looking into the paper. He will also provide you the ephemerides (he’s the orbit specialist, I’m the developer)

In regards of the configuration used:

  • Degree & Order: We’re using 16x16 in both STK and Orekit
  • ITRF Version: We’re using ITRF2010 for both
  • Pole Tides, points and steps for interpolation: I’ve played arround with changing those parameters, but it did not have much of an effect.
  • Astronomical amplitudes. We’re using the fes2014_Cnm-Snm.dat reference file, which does not use astronomical amplitudes (As can be seen in org.orekit.forces.gravity.potential.LazyLoadedGravityFields#addDefaultOceanTidesReaders). We have also exported the reference data files used in STK and compared them, aside from being arranged differently, they are the same. Though they do included wave amplitudes, and we don’t know how STK is using them, but we know it is also using fes2014_Cnm-Snm

@Hobbites will provide you with more details, including the STK ephemerides and reference files

Hi @MaximeJ and thanks a lot for your suggestions.

@LordRaptor mentioned already most of the configurations.
Unfortunately STK does not expose everything. They do provide a sort of explanation at the beginning of the file containing all the coefficients, though. I included that part of the file here, so you can have a look at it.
STK explanation.txt (5.7 KB)
They do mention there that pole tides are included in this way: “AGI’s model of the ocean pole tide discussed in section 6.5 is modeled using only the C21-S21 coefs, using the equations in section 6.5 of the IERS document.”

In STK, when including the Ocean tides you are simply asked to indicate the maximum degree and order and a minimum amplitude that you want to consider. We set those respectively to 16x16 and to 0).

Concerning the propagator configuration themselves, we have on Orekit side:

  • minstep 0.001
  • maxstep 86400
  • positiontolerance 1e-6
  • initialstep 1

In STK the integrator is a RKF 7(8) and we are using

  • error tolerance 1e-13 (relative error)
  • minstep and maxstep as in Orekit

We are propagating for 10 days with a time step of 600s in both software.

Here you can find the STK ephemeris for the HEO case we reported in the thread.
HEO eph.oem (241.2 KB)

To answer to your question, no, we did not try to use different values for the ocean tides degree and order. We might give that a try as well. Thanks for the suggestion.

Let us know if there is something else that might help you out and we will try our best to provide you with all the info.

Thanks a lot!

Thank you guys for the details.
That’s a lot of info, I cannot promise that I will be able to look into it soon, nor that I will manage to answer your question :sweat_smile:

Thanks for sharing your procedure and some of your intermediate results. I’d be interested in seeing your final results.

Looks like you have different integrators with different tolerance. That will lead to them selecting different steps, once that happens the two trajectories will diverge. So from the procedure it’s not clear whether the observed difference is due to differences in the tides model, or to a different sample of integration error. Perhaps try finding an fixed step integrator that both STK and Orekit support and configure it to use the same step size in both. That should eliminate the integrator as a possible source of the observed differences.

Hi @evan.ward, thanks a lot for your feedback and sorry for my late response.

Your suggestion is definitely valuable. Indeed, having mismatched integrators cause the two trajectories to diverge. We now used a 4th order Runge Kutta integrator (ClassicalRungeKuttaIntegrator) which uses a fixed integration step and is available in both software.

We could indeed notice that by having different steps the two trajectories deviated much more than what we reported in the thread (values in the order of km to thousands of km).
By using the same step though we got results pretty much aligned with what we posted here already.

As reference, this is what we got using a fixed step of 600s:

And here with a fixed step of 60s:

The results are different based on the step used, but with a fixed step of 60s, we are basically getting the same results that we were obtaining using our original integrators.

I am begging to wonder if we’re using the correct fes2014_Cnm-Snm.dat reference file. We’re using https://api.sedoo.fr/formater-catalogue-prod/grace/direct/fes2014b.v1.Cnm-Snm_Om1+Om2C20_with_S1_wave.POT_format.txt

Maybe this file does not contain the data in a way orekit requires/expects?

It seems to have the format expected by Orekit if we compare it to the FES 2004 model available in orekit-data. The 2014 version is much larger, though, and amplitudes are split into finer degrees.

Could you try to use FES 2004 on both programs?

Hi @luc, once again thanks for your suggestions.
Unfortunately, this is not very easy to do as in STK it is not straightforward to switch from FES2014 to FES2004. We need to prepare the reference file for that and we cannot simply input the same one used in Orekit. We might give it a try though.

On the other hand, we noticed that by changing to FES2004 in Orekit, we obtained slightly better results with respect to STK. The improvement is minimal though (in the HEO case, we pass from an RMS on the position norm residual of 29.9m to 29.1m).

What we find surprising though is that STK is actually using the amplitude of the waves (Hf values) on top of the Cnm-Snm coefficients. So basically, STK is using an extra input compared to Orekit. Indeed, when we remove the Hf values reported in STK reference data, the ocean tides are not used anymore (the propagation gives as output the same as the Keplerian one). Similarly, by manually changing the Hf values from the reference file, we get different results.

Could you try orekit+fes 04 versus orekit + fes 14 ?

Sure.
This is the result I get when running FES2004 vs 2014. They are pretty much the same. With a difference of about 4m maximum in the in-track direction after about 10 days.

Hi @Hobbites,

That may be the source of the difference you observe.
Orekit can also use the astronomical amplitudes if you ask him to (see an example here in OceanTidesTest). Did you place the astronomical amplitudes file in your orekit-data folder?

Maxime

Hi @MaximeJ,
I agree with you and we debated this a lot internally. In the end, though, we arrived to the conclusion that Orekit can deal with the Ocean tides in two ways:

  1. With the amplitude and the chat reference files (as in the example you provided)
  2. With the Cnm_Snm reference file (what we are using)
    @LordRaptor also found a test in Orekit that was making sure that the output is the same if you use either of the two options.

Please correct us if our understanding is incorrect.

What surprises us, though, is that it clearly seems that STK on the other hand is using the Cnm_Snm file plus the amplitudes.

To fully answer your question though, we have no amplitude reference file in our folder.