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