Performance issue with JPL ephemerides

Orekit usage
1

Hi all,

I’m running into a severe performance drop when numerical propagation time exceeds the 150 days mark or so, if the dynamics uses JPL ephemerides.
Here is a code snippet to reproduce.

    @Test
    void test() {
        Utils.setDataRoot("regular-data");
        final Orbit initialOrbit = new EquinoctialOrbit(42000e3, 0., 0., 0., 0., 0., PositionAngleType.ECCENTRIC, FramesFactory.getGCRF(),
                AbsoluteDate.ARBITRARY_EPOCH, Constants.EGM96_EARTH_MU);
        final SpacecraftState initialState = new SpacecraftState(initialOrbit);
        final DormandPrince54IntegratorBuilder integratorBuilder = new DormandPrince54IntegratorBuilder(1e-3, 1e3, 1e-3);
        final OrbitType orbitType = initialOrbit.getType();
        final AbstractIntegrator integrator = integratorBuilder.buildIntegrator(initialOrbit, orbitType);
        final NumericalPropagator propagator = new NumericalPropagator(integrator);
        propagator.setOrbitType(orbitType);
        propagator.setInitialState(initialState);
        propagator.addForceModel(new ThirdBodyAttraction(CelestialBodyFactory.getSun()));
        propagator.propagate(initialOrbit.getDate().shiftedBy(Constants.JULIAN_DAY * 150));
    }

With 100 days, execution time on my computer is less than one second. Make it 150 days, and it jumps to about 15 seconds. Profiling shows that circa 60% is spent in the feed method of the DIrectoryCrawler in that latter case.
So I guess the problem comes from the cache system? And it does look similar to this.

Cheers,
Romain.

2

I think you are right, we should open a bug report for this (I didn’t check if there was already one open).

3

Hi Luc,

Issue created just now.

Cheers,
Romain.

4

Hello @luc, @Serrof,

I couldn’t reproduce your bug Romain. I’m still about 3.4s for a 1000 days propagation with your code.
The only difference is that I didn’t use the data from the test suite but the classical “orekit-data” as input.
Could you try the same configuration on your side and tell us if you’re still observing the performance drop?

Cheers,
Maxime

5

Hi Maxime,

The issue does seem to disappear if the data is not loaded like in the tests. I still would like to understand why this happens though :sweat_smile:

Cheers,
Romain.

6

Hi @Serrof,

I do agree with you we need to understand what’s happening :slight_smile:
There are multiple JPL ephemerides files in “regular-data” test folder, with the dates you’re using your code should only use regular-data/de431-ephemerides/lnxp0000.431 (from 1999-11-22T00:00:00.000 (TDB) to 2000-06-01T00:00:00.000 (TDB), according to the readme file in the same folder)
There’s something fishy with the data though, if you shift the initial date by 100 days and propagate on 50 days then it takes 23s.
It looks like the problem comes from the dates used in the propagation, after 2000-05-15 it gets very slow…