DSSTTesseralForce null pointer exception

Orekit usage
1

Dear Orekit Users,
I am using DSSTPropagator to propagate object for a distant time in a future.
The DSSTTesseral force model is crashing with null pointer exception. It is setup as in Orekit’s DSSTTesseralTest class.

The problem seems to be that hansenObjects[rows][columns] is not intialized. When HansenObjects.computeHansenObjectsInitValues(*) method is called, the array return null value.
Why the array is not initialized?
The resonant orders are defining the size and initialization for an hansenObjects array. These orders are computed in DSSTTesseralContext. In its constructor, the ratio of object’s Keplerian period and central body rotation period is used to find resonance in tesseral harmonic field.
When they are not found, the list of orders is empty, then the array is not initialized, and null pointer exception occurs. Also even when some are found (I have tried to increase order of harmonics provider) still some elements of hansenObjects are not initialized and NullException occurs, but later during propagation.

To reproduce, please use following files that I am attaching.
DSSTForcesFactory.java (10.9 KB) DSSTPropTest.java (4.4 KB)

The error:

java.lang.NullPointerException
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral$HansenObjects.computeHansenObjectsInitValues(DSSTTesseral.java:2769)
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral$UAnddU.(DSSTTesseral.java:2349)
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral.getMeanElementRate(DSSTTesseral.java:409)
at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$Main.elementRates(DSSTPropagator.java:933)
at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$Main.computeDerivatives(DSSTPropagator.java:912)
at org.orekit.propagation.integration.AbstractIntegratedPropagator$ConvertedMainStateEquations.computeDerivatives(AbstractIntegratedPropagator.java:675)
at org.hipparchus.ode.ExpandableODE.computeDerivatives(ExpandableODE.java:134)
at org.hipparchus.ode.AbstractIntegrator.computeDerivatives(AbstractIntegrator.java:265)
at org.hipparchus.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:257)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:466)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:414)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:397)
at utils.DSSTPropTest.test(DSSTPropTest.java:113)

Thanks for any tips in advance.
Regards,

2

Hi @AstroUser,

There are two things that fix the issue:

  1. Reduce a a little bit the eccentricity: If you use 0.736462 instead of 0.739462 your test is OK.
  2. Remove the drag force model.

These two ideas are link because the error occurs because your perigee altitude is low (around 100 km). In that respect, you have important dynamic effects due to the atmosphere and the drag. DSST orbit propagator is not adapted in the case where the dynamic effects are too important. One of the example is the fact that the resonance terms are not computed correctly for the Tesseral effects in your application.

In order to have a better modeling of these effects without changing your initialization (eccentricity and force models), you can just reduce the max step used for the integrator. In your application you use a max step equals to 2 days. If you use 1 day the test works correctly without altering the computation time.

    AbstractIntegrator integr = new DormandPrince853Integrator(360,
                                                               1 * 24
                                                                    * 3600,
                                                               tolerances[0],
                                                               tolerances[1]);

I hope this will help you.

Kind regards,
Bryan

3

Hello,
Thanks for your reply.
When I change max step size to 1 day, the problem sill exists. Maybe the difference is in gravity potential files that we are using ?
I am using EIGEN-5C.gfc http://op.gfz-potsdam.de/grace/results/grav/g007_eigen-05c.html
Which file is loaded by you ?
Regards,

4

In my case I use EIGEN-6S file. It is available on the last version of the orekit-data file here.

I downloaded again your test and just change the value of the max step to 1 * 24 *3600 instead of 2 * 24 * 3600. The conclusion is the same, the test works correctly with this small change. Try to update your orekit-data. Using a more recent gravity potential file could be the solution of your issue because the perigee of your orbit is very low.

Kind regards,
Bryan