[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Users] DSSTPropagator isOsculating


MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :


MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :


Elisabet <elisabet.cid-borobia@thalesaleniaspace.com> a écrit :


Hello Luc,

In my case the earthDegree=36 and the earthOrder=4. It seems it throws the
exception each time the earthDegree is different from the earthOrder. The
DSSTPropagator, using mean parameters, can be used with these Earth’s degree 
and order. However, it throws the thread when using osculating parameters.


I finally managed to reproduce the error!
I first tried simply having different values for degree and order, but
still got a result.

Using (36, 4), I finally got the same exception as you!

I will look at this issue, stay tuned.


OK, the problem was quite straightforward to analyze.

It appears as soon as degree > 31 and order > 1. So a (36, 0) setting
does not trigger any error, but a (32, 1) does.

The reason is a overflow while computing Newcomb operators for high
degrees (i.e. 32 or more) in tesseral contribution (which are computed
when order > 1).

I don't know if it is possible to find quickly a different implementation
for computing the high degree polynomials involved that does not overflow.
The polynomials are degree 67 here.
The issue is fixed. I have registered it as number 237 <https://www.orekit.org/forge/issues/237> and fixed it in the git repository. It will be published with the next release. 

You can get it directly by using the development version of Orekit or by
patching your version using this: <https://www.orekit.org/forge/projects/orekit/repository/revisions/a72c8c585121a7cab8bb9e97a74954e6a8eee633/diff/src/main/java/org/orekit/propagation/semianalytical/dsst/utilities/NewcombOperators.java>. 

The fix simply uses double numbers instead of integers to store the large
binomial coefficients that arise while building some recurrence relations.
This avoids overflows.

Thanks for reporting the issue.

best regards,
Luc



In the mean time, I suggest you restrict yourself to gravity fields of
degree 31 at most.

The degree that does trigger the error is the one embedded in the "provider"
argument from DSSTCentralBody, which is used for the mean elements computation. The other degree/order settings also correspond to gravity field, and are used when you want to limit the short periodic terms to something smaller than what 
you use for mean elements.

This fine tuning feature was introduced in 7.1, for expert use and validation
purposes. In most cases, users would want the same settings for mean elements
and short periods, so your configuration was indeed correct. Note that in the
upcoming version (probably next week), we will even add more fine tuning settings, 
typically concerning the max power for eccentricity expansions. As an attempt
to reduce the complexity of the constructor parameters, this change will be
performed by deprecating the DSSTCentralBody class and replacing it with
two separate classes DSSTZonal and DSSTTesseral, which themselves will have
already complex enough constructors.

best regards,
Luc



best regards,
Luc



The thread:
Exception in thread "main"
org.apache.commons.math3.exception.MathArithmeticException: erreur
arithmétique
	at
org.apache.commons.math3.util.ArithmeticUtils.mulAndCheck(ArithmeticUtils.java:582)
	at
org.apache.commons.math3.util.ArithmeticUtils.mulAndCheck(ArithmeticUtils.java:552)
	at
org.apache.commons.math3.util.CombinatoricsUtils.binomialCoefficient(CombinatoricsUtils.java:126)
	at
org.apache.commons.math3.analysis.polynomials.PolynomialsUtils.shift(PolynomialsUtils.java:329)
	at
org.orekit.propagation.semianalytical.dsst.utilities.NewcombOperators
$PolynomialsGenerator.shiftList(NewcombOperators.java:326)
	at
org.orekit.propagation.semianalytical.dsst.utilities.NewcombOperators
$PolynomialsGenerator.computeFor(NewcombOperators.java:216)
	at
org.orekit.propagation.semianalytical.dsst.utilities.NewcombOperators
$PolynomialsGenerator.getPolynomials(NewcombOperators.java:175)
	at
org.orekit.propagation.semianalytical.dsst.utilities.NewcombOperators
$PolynomialsGenerator.access$000(NewcombOperators.java:104)
	at
org.orekit.propagation.semianalytical.dsst.utilities.NewcombOperators.getValue(NewcombOperators.java:86)
	at
org.orekit.propagation.semianalytical.dsst.utilities.hansen.HansenTesseralLinear
$HansenCoefficientsBySeries.generatePolynomial(HansenTesseralLinear.java:516)
	at
org.orekit.propagation.semianalytical.dsst.utilities.hansen.HansenTesseralLinear
$HansenCoefficientsBySeries.<init>(HansenTesseralLinear.java:472)
	at
org.orekit.propagation.semianalytical.dsst.utilities.hansen.HansenTesseralLinear.<init>(HansenTesseralLinear.java:100)
	at
org.orekit.propagation.semianalytical.dsst.forces.TesseralContribution.createHansenObjects(TesseralContribution.java:398)
	at
org.orekit.propagation.semianalytical.dsst.forces.TesseralContribution.initialize(TesseralContribution.java:334)
	at
org.orekit.propagation.semianalytical.dsst.forces.DSSTCentralBody.initialize(DSSTCentralBody.java:134)
	at
org.orekit.propagation.semianalytical.dsst.DSSTPropagator.computeOsculatingState(DSSTPropagator.java:338)

Best regards,

Elisabet