Execution time issues with frame cache

1

Hi,

I have experienced some issues, I believe, with the cache used by Orekit in Frame transform.

Here is a snapshot of a code where I see this issue:

FactoryManagedFrame itrf = FramesFactory.getITRF(IERSConventions.IERS_2010, false);
FactoryManagedFrame tod = FramesFactory.getTOD(true);
double step = 3600.0;
AbsoluteDate initialDate = new AbsoluteDate(2020, 1, 1, 0, 0, 0.0, TimeScalesFactory.getUTC());
AbsoluteDate maxDate = new AbsoluteDate(2022, 1, 1, 0, 0, 0.0, TimeScalesFactory.getUTC());
long timeBefore = System.currentTimeMillis();
for (AbsoluteDate currentDate = initialDate; currentDate.isBefore(maxDate); currentDate = currentDate.shiftedBy(step)) {
            Transform transformationAtInitial = itrf.getTransformTo(tod, initialDate);
            Transform transformationAtCurrent = itrf.getTransformTo(tod, currentDate);
}
long timeAfter = System.currentTimeMillis();
System.out.println("Number of elapsed seconds are:" + (timeAfter - timeBefore) * 1e-3);

When my maxDate is 2021/01/01, the excecution time of this code is about 1sec, and when my maxDate is in 2022/01/01, it is about 60s

I think the way cache is orchestrated in Orekit may be responsible for this large difference in execution time. From what I understood, Frame transforms are stored in cache with a max length of 1 year.

The code above is close from a real context when I have to request transform successively at times before and after the stored cache. When the difference between the two times is lower than 1 year, everything works perfectly. However, once the difference is larger than one year, the code spends a lot of time rebuilding cache successively before and after. Therefore, the number of requests to frame transform increases a lot.

I do not know if I was clear, I can provide some drawings if necessary.

What do you think? Did I understand this issue correctly? Do think you could have a solution?

Thank you for your time,

Dorian

2

Hi @dorian

Looks like a bug. We shall investigate the size of Orekit cache. Could you open an issue?

Thank you,
Bryan

1 Like
3

Thanks for your answer. Issue created here: https://gitlab.orekit.org/orekit/orekit/-/issues/1243

Dorian

4

I see you created ITRF with simpleEop=false. I thought this disabled most, if not all, caching in Orekit’s frames. Do you see the same performance discrepancy when using simpleEop=true.

5

Take a look at AbstractFrames.getCIRF(...). Interpolation and shift is still used with simpleEop=false. Each cache is one year long and new caches are created for dates 30 days apart, so you’re probably seeing some cache thrashing when your dates are more they 1 year apart and less than 1 year 30 days apart. Does it help if, before your main loop, you get one transform for each year? That should cause it to create a separate cache for each year.

6

Hi Evan,

Thanks for the answer, I tried to use simpleEop=true, and there is no real change on the performances. I still have an execution of 1s for one year, and 60s for 2 years

7

Yes I fully agree with your analysis, and as you suggested, I have some numbers to confort it:

  • when my maxDate is in 2021/01/01, the execution time is about 1s
  • when my maxDate is in 2021/02/03, the execution time is about 60s
  • when my maxDate is in 2022/01/01, the execution time is still about 60s

which means the performance issue occurs during january, precisely before when the new caches are created.

When I start with computing a transform each year, the execution time when my maxDate is in 2022/01/01 drops to about 2 seconds, which also conforts your analysis

Dorian