I am using one of the tutorials uploaded to Orekit’s GitLab (DSSTPropagation) to propagate some initial conditions for a relatively short time (5 years). However, the DSSTTesseral force model crashes with a null pointer exception. When HansenObjects.computeHansenObjectsInitValues(*) method is called, the array returns a null value seeming that hansenObjects[rows][columns] is not initialized.
A similar case with possible explanations about the error can be found in a previous post: DSSTTesseralForce null pointer exception. In that post, it was suggested that the error could be avoided by either reducing initial eccentricity or removing drag effect. In that case, the perigee altitude was very low and the orbit propagator was not adapted in the case where the dynamic effects were too important.
In my case, the orbit is almost circular and the drag effect is not considered. Besides, several propagations are executed in a row with the same configuration and only for particular initial conditions.
To reproduce the test, I leave below the files I am using, the main and the input file from which I extract the initial conditions. Everything is set up as the original configuration of Orekit 10.1 and run with the most recent Orekit data available.
The error:
Exception in thread “main” java.lang.NullPointerException
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral$HansenObjects.computeHansenObjectsInitValues(DSSTTesseral.java:2798)
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral$UAnddU.(DSSTTesseral.java:2401)
at org.orekit.propagation.semianalytical.dsst.forces.DSSTTesseral.getMeanElementRate(DSSTTesseral.java:438)
at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$Main.elementRates(DSSTPropagator.java:994)
at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$Main.computeDerivatives(DSSTPropagator.java:973)
at org.orekit.propagation.integration.AbstractIntegratedPropagator$ConvertedMainStateEquations.computeDerivatives(AbstractIntegratedPropagator.java:677)
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:468)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:414)
at org.orekit.tutorials.propagation.DSSTPropagation.run(DSSTPropagation.java:379)
at org.orekit.tutorials.propagation.DSSTPropagation.main(DSSTPropagation.java:135)
First, it is important to know that the DSST has changed a lot in Orekit 10.0 version. Indeed, during this version, we introduced orbit determination feature using DSST.
Therefore, I tried your configuration using Orekit 9.3 (i.e. before the changes) and everything work. After that, I tried using Orekit 10.0 and the problem occur. As a result, it seems that a regression was introduced in Orekit 10.0. Could you open an issue on the Orekit issue tracker?
You have two possibilities to run your program correctly:
Use Orekit 9.3 instead of Orekit 10.1. There are three important changes between the two versions for DSST initialization. You can use that old version of the tutorial to help you.
First, you have to remove the mu parameter in DSST force models initialization. It has been introduced in Orekit 10.0 in order to estimate that parameter during DSST orbit determination. It is not used for Orekit before 10.0 in DSST force model constructors.
Furthermore, DataContext cannot be used. You have to initialize the orekit-data by usingDataProvidersManager manager = DataProvidersManager.getInstance(); instead of DataProvidersManager manager = DataContext.getDefault().getDataProvidersManager();
Finally, you cannot use PropagationType object. Before Orekit 10.0 boolean values were used. Considering your example, the boolean values to use are:
final DSSTPropagator dsstProp = new DSSTPropagator(integrator, true);
dsstProp.setInitialState(new SpacecraftState(orbit, mass), false);
I tried to reduce a little bit your initial eccentricity. Using 0.017522 instead of 0.017822 allows your program running correctly with all Orekit versions. Before and after Orekit 10.0. This is just a workaround, bug must be fixed.
I have exactly the same problem on a classical GEO orbit.
I tried to see if the bug was inserted in Orekit issue tracker as requested but I was unable to find one. Is a problem report has been opened to cover this issue ? And can we hope to have a correction soon (or a workaround on 10.2) ?
The issue has not been opened on the Orekit issue tracker. Therefore, you can open it. I don’t know when the issue will be fixed. Probably after 10.3 release. In the meantime, I noticed that reducing a little bit the eccentricity of the orbit allowed to get around this problem. Maybe you can try it.
Thanks for the answer.
I will open the issue with the data from @farribax to trace it.
My eccentricity is already really small (around 1e-5) and the initial orbit comes from an external computation (I can’t modify it). Sometimes, depending on the case, everything runs fine and sometimes I have the problem so the proposed workaround is not really applicable but thanks for the proposal!
Hi @bcazabonne I’m using 10.3.1 Orekit Version. I’m having this problem as well.
Is there a more recent version where this problem is solved?
If so, after which version is it solved?
Current Orekit version is 11.3. There is no API change between 11.0 and 11.3. Therefore, I recommend you to use 11.3 instead of 11.0 to benefit the DSST bug fix and the latest Orekit features
Yes I’m having conflicts on the packages version when trying to upgrade to orekit 11.3.
I think it’s mainly related to the python version that I currently have (python==3.8.11=h12debd9_0_cpython)
Which python version should I use to be compatible with orekit 11.3?
