DSST Propagation - Error in mean element computation

Orekit usage
1

While using DSST orbit propagation using 12.1.2 version, the following error message is observed “unable to compute eccentric longitude argument from the mean one after 50 iterations”, for propagating a typical GTO orbit, (a=27,773 km, e=0.72). If 12.0 version is used, this issue is not observed. I understand that, this could be due to introduction of “EquinoctialLongitudeArgumentUtility.java” in 12.1.2. I am not sure on whether increasing the number of iteration will help or any other “fix” is required.

2

Hi @Rajesh

Could you provide an example allowing to reproduce the problem?

Thank you and best regards,
Bryan

3

Hi there,

In 12.1 was introduced a check after the iterations when converting an argument of longitude. If they have reached the maximum allowed there is an exception (whilst before the code kept going as if the conversion was successful). If you get that error, I suspect there is a problem beforehand. Like out of bounds values for some orbital elements or something. As Bryan said, we’d need test data to investigate further.

Cheers,
Romain.

4

DSSTTest.java.txt (22.0 KB)
Hi @bcazabonne and @Serrof

Code is attached. It is basically a modified version of DSST propagation tutorial code with AltitudeDetector. It works well with 12.0 version, but not in 12.1.2 version. Hope you could reproduce the error message “unable to compute eccentric longitude argument from the mean one after 50 iterations”. I guess it has to do something with updates between 12.0 to 12.1.2 version, probably with EquinoctialLongitudeArgumentUtility.java.

5

Hi there, any update on this topic?

6

Hello @Rajesh,

Thank you for the provided example, i can reproduce your error.

I’ll try to find some time to look into it.

Cheers,
Vincent

7

After investigating the issue with @MaximeJ , we realized that an oscillation occurs while the difference is only slightly above the constant tolerance of 1e-12 applied. So even though the algorithm has almost converged, it cannot get out of the loop.

We were able to fix this by normalizing the input mean longitude with MathUtils.normalizeAngle(LM, 0)

Test code to reproduce the error

The error can be reproduced using the following code :

import org.hipparchus.util.MathUtils;
import org.orekit.orbits.EquinoctialLongitudeArgumentUtility;

public class TestEquinoctial {

    public static void main(String[] args) {
        final double ex = 0.44940492906694396;
        final double ey = 0.56419162961687;
        final double lM = 4995.963018579126;
        //        final double lM = MathUtils.normalizeAngle(4995.963018579126, 0);

        EquinoctialLongitudeArgumentUtility.meanToEccentric(ex, ey, lM);
    }

}

Explaination (?)

Given the observed numerical values, we believe that the order of magnitude of the input LM (1e3) combined with defined tolerance (1e-12) leads to a loss of precision under 1e-15 (minimal precision for double value) which itself leads to an oscillation during the convergence process.

We shall implement a fix for this

Cheers,
Vincent

8

Hi guys,

Thanks Vincent for looking at this.
I guess the convergence check in all Kepler equation solver (not just the equinoctial one) could take the best of an absolute and a relative error evaluation?

Cheers,
Romain.

9

@Rajesh in the meantime, a workaround is to sometimes reset your argument of longitude in [0, 2\pi]

10

Hi @Serrof @Vincent @bcazabonne,

Good that the issue is identified and the reason is understood.
If the fix is implemented in upcoming version, it is all well and good.
For my purpose, version 12.0, is fine and working.
Thanks guys for your support and effort.

11

Hi all,

I don’t know if an issue has been opened yet but, if not, @Rajesh, could you please open one on the issue tracker?

Cheers,
Maxime

12

Hi @MaximeJ ,

As you suggested an issue is opened, Issue link

regards,
Rajesh

2 Likes