Error with DSST

Orekit usage
1

Hello,

I have encountered this error with the DSST propagator (used with the underlying ephemeris generator):

java.lang.ArrayIndexOutOfBoundsException: 4
	at org.orekit.propagation.semianalytical.dsst.forces.DSSTThirdBody$GeneratingFunctionCoefficients.getdSdgammaCj(DSSTThirdBody.java:2692)
	at org.orekit.propagation.semianalytical.dsst.forces.DSSTThirdBody.updateShortPeriodTerms(DSSTThirdBody.java:368)
	at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$ShortPeriodicsHandler.handleStep(DSSTPropagator.java:1272)
	at org.hipparchus.ode.AbstractIntegrator.acceptStep(AbstractIntegrator.java:439)
	at org.hipparchus.ode.nonstiff.RungeKuttaIntegrator.integrate(RungeKuttaIntegrator.java:170)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.integrateDynamics(AbstractIntegratedPropagator.java:477)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:425)
	at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:385)

My force model is a 5x5 geopotential with Sun & Moon gravity.
The problem is clearly related to third bodies.
Has anyone seen something like that? Couldn’t find it on the forum or Gitlab.
Although it looks a bit like issue #672
I haven’t dug into yet, but I guess I could extract the initial conditions.

Romain.

2

Hi Romain,

Do you have a sample of code (even in Python) showing how do you initialize the DSST propagator? (including the force models)

Bryan

3

Hi Bryan,

initialization is similar to this with obviously now some third bodies e.g.:
DSSTThirdBody(CelestialBodyFactory.getMoon(), mu)
Integrator is RK4 with a step of 10000 seconds.
Out of tens of thousands of initial conditions, I am only having this error for a few.

Best,
Romain.

4

Hi @Serrof

I’m unfortunately unable to reproduce the problem. I can reproduce the known issue for 3x3 geopotential terms, but I can’t reproduce your issue with 5x5.

What value of mu did you used to initialize the DSSTThirdBody? Because it must be Earth’s value.
But, I will need some code examples in order to reproduce your issue… If it’s possible for you.

On my side, I’m using the Orekit tutorial DSSTPropagation in version 11.2. I updated it to use 5x5 geopotential terms, luni-solar attractions and a RK4 integrator with 10000s step size. I tries using three different Orekit version: 11.0, 11.1, and 11.2.

Best regards,
Bryan

5

Hello Bryan,

I dug into one case and it turns out to be a very high altitude orbit.
Here are the initial conditions:
Epoch: 2022-09-24 08:17:50.661600+00:00 (UTC)
Position-velocity vector in m and m/s (EME2000):
P = -32849463.65183451, -57543170.63012171, 57807703.331736915
V = 1846.1379875561317, -1436.0116917287667, -368.30380562637004
Moreover, I’m using DE440 ephemerides and EGM08 geopotential coefficients.

Cheers,
Romain.

6

Hey there,

I’ve got these initial conditions too if that helps:
2022-10-08 09:42:06.732
3.22524097e+06, 5.92887672e+06, 2.67866165e+06
2.44105965e+03, 1.59844000e+03, -6.76785436e+03
Propagating over more or less 3 days should cause the error.

Edit: btw disabling the moon as a third body seems to remove the issue

Cheers,
Romain.

7

Thank you Romain for the new test case. I unfortunately didn’t check the problem. Time issues …
But I am constantly aware of this issue

Bryan

8

Don’t worry Bryan, I don’t want to pressure you in any way, I’m just populating this thread for reference.
I actually encountered another error with DSST, this time within an OD process (so more difficult for me to extract the initial conditions from Python, and also it might just be that the least squares are diverging and causing non physical trajectories). But here it is anyway:


java.lang.ArrayIndexOutOfBoundsException: 6
	at org.hipparchus.analysis.differentiation.Gradient.subtract(Gradient.java:242)
	at org.hipparchus.analysis.differentiation.Gradient.subtract(Gradient.java:57)
	at org.orekit.time.FieldAbsoluteDate.durationFrom(FieldAbsoluteDate.java:1117)
	at org.orekit.propagation.semianalytical.dsst.utilities.FieldShortPeriodicsInterpolatedCoefficient.value(FieldShortPeriodicsInterpolatedCoefficient.java:79)
	at org.orekit.propagation.semianalytical.dsst.forces.AbstractGaussianContribution$FieldGaussianShortPeriodicCoefficients.value(AbstractGaussianContribution.java:2242)
	at org.orekit.propagation.semianalytical.dsst.DSSTHarvester.setReferenceState(DSSTHarvester.java:294)
	at org.orekit.estimation.leastsquares.DSSTBatchLSModel.configureOrbits(DSSTBatchLSModel.java:113)
	at org.orekit.estimation.leastsquares.AbstractBatchLSModel.value(AbstractBatchLSModel.java:302)
	at org.hipparchus.optim.nonlinear.vector.leastsquares.LeastSquaresFactory$LocalLeastSquaresProblem.evaluate(LeastSquaresFactory.java:440)
	at org.orekit.estimation.leastsquares.BatchLSEstimator$TappedLSProblem.evaluate(BatchLSEstimator.java:615)
	at org.hipparchus.optim.nonlinear.vector.leastsquares.LevenbergMarquardtOptimizer.optimize(LevenbergMarquardtOptimizer.java:333)
	at org.orekit.estimation.leastsquares.BatchLSEstimator.estimate(BatchLSEstimator.java:435)
9

I have an idea for this one! Do you estimate additional parameters like force model parameters (e.g. drag coefficient, reflection coefficient) or measurement parameters (e.g. bias)?
If yes, it’s indeed a bug. Shame on me because it’s a bug I know since a long time and I never opened an issue…

Bryan

10

Hi Bryan,

It’s very well possible I was estimating the drag coefficient yes, but I can’t quite remember.
Anyway if there is an issue known to you only please share it on gitlab :joy:

Cheers,
Romain

11

Issue opened: DSST orbit estimation cannot estimate propagation and/or measurement parameters (#986) · Issues · Orekit / Orekit · GitLab :sweat_smile: