Are Orekit results repeatable?

Hello,

I’m using Orekit estimation module, doing Kalman Filtering. I’ve seen that the outputs can be slightly different from one run to another.

Is it normal? Is there a way to fix this behaviour? I can try to provide a code snippet if you need so. Maybe it’s not Orekit’s fault, I’m not a Java expert.

Thank you!

The Orekit results are often repeatable, the numerous (more that 8300) non-regression tests demonstrate that.
The two main discrepancy causes are non-deterministic nature of multi-thread programs and pseudo-random numbers generation.
One example that come to mind for multi-thread programs is frame transforms, as many of them cache intermediate results. If adding a new sample in cache is done by thread A instead of thread B, then the sample may be very slightly distorted. The differences should be really really small as the interpolation schemes used are tuned so interpolation errors are far below models accuracy (perhaps at micrometer level on Earth surface).
Concerning pseudo-random generation, one needs to set up properly the random seed in the generator. If using both random generation and multi-threading, then each thread should have its separate generator so they do not interfere with each other. The classical trick to do that is to use a single random seed for the program, to build a unique SplittableRandom from this, and then to call its nextLong method to create (always in deterministic order!) the seeds for the individual threads. After that, the generators for all thread should produce repeatable results.

Could you elaborate on the way you use Kalman filtering? Do you use synthetic measurements you generate from Orekit with multi-threading and pseudo-random number generation or do you use a constant set of measurements? How large are the differences you observe on the output?

Hi,

the first thing to do for users to make their results repeatable is to use the same Orekit DataContext with the same underlying files. If you don’t have that, the same code can produce different output.

In my experience, the interpolation of Earth Orientation Parameter can cause non negligible differences, especially for long propagations, even in single threading.
Basically even with the same data, results can be different if before running your propagation, you called a transform at some date. Depending on where this date is w.r.t. your initial and final epochs, the EOP will have been interpolated differently and because they intervene a lot in the geopotential, the discrepancy can build up quite significantly.
One way of getting rid of this is to not use the interpolation (I’m not sure at what level that option is) but then frame transforms will be slower, so it becomes a tradeoff.

Cheers,
Romain.

Hello,
Thank you for the answer.
I don’t do multithreading, I don’t use random generation number neither. I use a constant set of measurements (rinex observations) and use the extended kalman filter.

For the differences, I will try to make a code snippet.

Hi,
Yes I use the same orekit-data.
You say “you called a transform at some date”, do you mean an actual date ? Running the code at 15h00 vs running the code at 15h01 won’t produce the same results ?

Because concretely, I was running compiled Java code, without using multithreading or rng, with the same input data, and the results were slightly different.

My code is quite big so I can’t provide a code snippet that easily but I’ll try my best.

Yes, this can induce differences. As frames transforms involve huge computation (several thousands of terms in Poisson series for nutation), they are not computed for each and every date, but rather computed fully from time to time (once per hour for precession-nutation using the IERS Non-Rotating Origin paradigm) and interpolated in between.
If the first call is at 15.00, the points fully computed will be at 15:00, 16:00, 17:00… If the first call is at 15:01, the points fully computed will be at 15:01, 16:01, 17:01… At some point, I considered making this more deterministic by forcing the dates to be at round hours regardless of the date of the first call, but it seems we never included this feature. Also as I wrote before, the difference will be very small. As precession-nutation is very smooth (despite it involves thousands of terms), interpolating one point per hour is largely sufficient. The interpolation errors are very small (almost at numerical noise level for angles if I remember well), so changing from sampling at 15:00, 16.00 to sampling at 15:01, 16:01 induces differences, but they should be really acceptable and well below models accuracy.