DSST osculating propagation and AbstractGaussianContribution with low-thrust maneuver?


I have questions and problems while trying to use the AbstractGaussianContribution class for the DSST propagation.

First, it’s not easy to call the “init” method of the underlying force model because the “initialize” method of AbstractGaussianContribution, called at the beginning of a DSST propagation, does not provide a spacecraftState at start and/or a time. So what is the correct way to initialize a ForceModel from an AbstractGaussianContribution ?

Then, while I tried to implement a long low-thrust maneuver in DSST with the AbstractGaussianContribution class, I encountered a problem when trying to propagate with a propagation type = Osculating.
I want to set a maneuver that thrusts between two mean equinoctial longitudes, with the start and stop triggered by event detectors. But when I run it, an exception is raised.

Exception in thread "main" org.orekit.errors.OrekitException: échantillon d'interpolation vide
	at org.orekit.errors.OrekitException.unwrap(OrekitException.java:154)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:494)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:414)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:397)
	at DsstPropagatorBehavior.propagate(DsstPropagatorBehavior.java:64)
	at DsstPropagatorBehavior.main(DsstPropagatorBehavior.java:91)
Caused by: org.hipparchus.exception.MathIllegalArgumentException: échantillon d'interpolation vide
	at org.hipparchus.analysis.interpolation.HermiteInterpolator.checkInterpolation(HermiteInterpolator.java:277)
	at org.hipparchus.analysis.interpolation.HermiteInterpolator.value(HermiteInterpolator.java:176)
	at org.orekit.propagation.semianalytical.dsst.utilities.ShortPeriodicsInterpolatedCoefficient.value(ShortPeriodicsInterpolatedCoefficient.java:76)
	at org.orekit.propagation.semianalytical.dsst.forces.DSSTZonal$ZonalShortPeriodicCoefficients.value(DSSTZonal.java:1506)
	at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$MeanPlusShortPeriodicMapper.mapArrayToState(DSSTPropagator.java:841)
	at org.orekit.propagation.integration.StateMapper.mapArrayToState(StateMapper.java:167)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.getCompleteState(AbstractIntegratedPropagator.java:595)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.access$600(AbstractIntegratedPropagator.java:63)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator$AdaptedEventDetector.init(AbstractIntegratedPropagator.java:774)
	at org.hipparchus.ode.AbstractIntegrator.initIntegration(AbstractIntegrator.java:225)
	at org.hipparchus.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:196)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:468)
	... 4 more

What is stranged id that the exception is raised in DSSTZonal…
This exception is raised only when the propagation type is OSCULATING (when adding the short terms). In MEAN propagation, the problem is not raised and the propagation runs fine (at least, the propagation finishes without errors but I didn’t check the correctness of the propagation…).
It seems linked to the use of the event detectors. If I remove the detectors and force the underlying force model to thrust all the time (but with the LLimit set correctly), I do not have this error (but a different result…).
What is the correct way to handle detectors that would enable/disable the thrust for example ?

I made a small piece of code to reproduce the behavior I encountered.
If someone has already done something similar with DSST and could explain me how to handle it correctly, that would be great!
ConstantManeuver.java (8.8 KB) DsstPropagatorBehavior.java (4.5 KB) DsstThrustManeuver.java (2.8 KB)


Hi @Christophe

I don’t think I understood that question. Do you want to implement your own custom force model who inherits AbstractGaussianContribution ? If yes, you have just to extend AbstractGaussianContribution class. Please not that you are dealing with DSSTForceModel and not ForceModel (which is an interface for the numerical propagator force models).

You have encountered a known problem with Orekit. But luckily it has recently been fixed (see #613). Currently, you can take advantage of the fix on our development branch. The fix will be “officially” released at Orekit 10.2.



thanks for the answers, I will try with the development branch.

For the initialization, my question was related to the call of the “init” method of a numerical ForceModel.
When you instantiate a class which is a subclass of AbstractGaussianContribution, you must provide an underlying numerical ForceModel (that will execute the computation of the acceleration) -> cf constructor of AbstractGaussianContribution. If this ForceModel has an “init” method that needs to be called at start of propagation for a correct behavior of this force model, how can we call it properly from the the “initialize” method of the DSSTForceModel at the beginning of each propagation ?
Do I need to understand that different implementations of a disturbing force may be needed for the AbstractGaussianContribution (DSST propagator) and for a numerical propagator, even if they share the same ForceModel interface ?


I think you found an issue. The init method of ForceModel interface is never called either by AbstractGaussianContribution class or by the DSSTPropagator. Therefore, if a ForceModel implements the init method, the ForceModel will never be initialized by a DSSTForceModel that extend AbstractGaussianContribution class. Can you open an issue in our Gitlab repository ?

I attached a small test showing the issue. What you can do, temporarily, is to call the method init of the ForceModel object before the DSST propagation as it is done in the failing test, just below the FIXME annotation (i.e. force.init(state, target)).


AbstractGaussianContributionTest.java (7.4 KB)


I proposed two solutions for fixing the issue #670.

I am waiting for feedback on the best solution to use.