I added a StateCovarianceMatrixProvider to a numerical propagator, and I’m trying to build an ephemeris upon this propagator through its EphemerisGenerator.
When I try to propagate with the ephemeris, though, I end up with the following NullPointerException:
java.lang.NullPointerException: Cannot invoke “org.orekit.propagation.SpacecraftState.getOrbit()” because “initialState” is null
prop1.setupMatricesComputation(STM_NAME, null, null);
stateCovProvider = new StateCovarianceMatrixProvider(COV_PROV_NAME, STM_NAME, harvester,
EphemerisGenerator generator = prop1.getEphemerisGenerator();
Propagator ephemeris = generator.getGeneratedEphemeris();
The problem seems to arise in the calls before propagating, upon initializing the additional states of the ephemeris. The method AbstractPropagator.initializeAdditionalStates calls provider.init(initialstate, target) with the class parameter initialstate being null !
Unfortunately, I did not find a way to give a value to initialState, as the method IntegratedEphemeris.resetInitialState leads to an exception with OrekitMessages.NON_RESETABLE_STATE.
What am I missing here ?
This is unfortunately an issue I also encountered a while ago (check issue 949) but as of today, I did not find a simple fix.
My only idea was to use the super.resetInitialState method to avoid the OrekitMessages.NON_RESETABLE_STATE error but that was not enough to address all affected classes.
I’ll put this issue in the 12.0 milestone as we may need to rethink the architecture.
Thanks Vincent, and Sorry I did not find issue 949 when I searched through the issues history.
In the case of integratedEphemeris, if I’m not mistaken one possibility could be to automatically fill the initial state and date with the start state and date available. As for other classes, I’m not sure…
By the way, as a workaround, is there an easy and reliable way to clone a propagator while removing the additionalStatesProviders ?
Indeed but I was, and still am, afraid that such a specific fix may be ultimately modified when trying to fix this issue for all affected propagators so i was looking for a more global fix. I’d have to take a look at it again to figure out something, since I’m much more familiar with Orekit than before.
Regarding your workaround, I first thought that we could clear the
AdditionalStateProvider but that doesn’t seem to be the case. Unfortunatly, the only solution i can come up with right now is to build the same propagator twice, with and without the desired
AdditionalStateProvider and then use the one without
AdditionalStateProvider to build an
I think you can open an issue about adding a clearAdditionalStateProvider() or a removeAdditionalStateProvider() method in the
I’ll try to see what I can do about the issue #949 but it is currently not a priority for this week (i’m working on issue 970).
Hi @bruno ,
I wanted to keep you informed that this issue has now been fixed in this merge request.