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

Re: [Orekit Users] Problem when doing propagation from different point of views


do you think that the numerical precision of the "double" which is about 15 digits could lead to this kind of errors for long term integration?
Because position/velocity of the probe in the sun frame are not given with the same accuracy as in EME2000 frame and maybe, after a long integration, we could have this error?

Just an idea...

Le 6 avr. 2014 09:26, "MAISONOBE Luc" <luc.maisonobe@c-s.fr> a écrit :
MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :

Quentin Nénon <q.nenon@gmail.com> a écrit :


Hi Quentin,

I would like to add some comments in order to make the discussion progress.

You will find enclosed another main class using the previously posted ones
and it is basically doing the same thing as before but it uses the Venus
point of view (and adds the perturbation due to Venus to avoid to use a GM
constant of 0., that throws an exception). You can therefore see that the
problem is not only due to the definition of the Sun inertially oriented
frame. The problem still can be in the definition of all the inertially
oriented frames.

Another interesting aspect is when you change the force models you add to
the propagators. If for instance you remove the moon or sun perturbation,
you have errors on the position and velocity that change. This makes me
think that the problem might be in the definition of the perturbative
forces ?

If any of the users have an idea of what might be the problem, I would be
very happy to discuss it here,

I finally found some time to look at your problem. I'm sorry for the delay.

It seems to me the problem is due to an oversimplified model. In your code, you propagate a trajectory using Keplerian attraction and third body perturbations only in all cases, using Sun, Earth and Moon in various combinations. The combinations are logical, i.e. when you consider the Sun as the center, Earth and Moon are perturbing bodies, and when you consider Earth as the center, Sun and Moon are the perturbing bodies. Then you compare the two trajectories and notice a large position error (more than 2000 kilometers. This error happens after 100 days in an escape trajectory, where the position of the probe starts at about 14000 km from Earth center and reaches about 7.2 million kilometers 100 days later.

Assuming the two trajectories should be equals is similar to assuming the Earth trajectory with respect to Sun is also only dependent on Sun and Moon, which is not true. I think that what you observe is partly due to the non-Keplerian part of the Earth trajectory which is included in the JPL ephemeris used to compute the various frames, and which is not included in your simplified force model.

In order to check this, I have tried to compare a trajectory that would in fact always remain at the center of the Earth. The first part of the trajectory (as seen from Earth) is simple to compute with perfect accuracy: the position is always exactly at the center of the EME2000 frame ;-) The second part (as seen for Sun) is computed using your simplified model, i.e. using only Sun as the main attraction body and Moon as a perturbing body. This second trajectory, once converted to EME2000 fram does not stay at the origin, it moves approximately in the same motion as the error you see between your two trajectories. It does not really represent the error you observe, but goes in the same direction, the curves have the same shape, and when you compute the ration between your error and this trajectory for all coordinates x, y, z, the ratio remains roughly between 1.0 and 1.8. As the accelerations I compute in this case are computed from the center of Earth, which is always muche closer to Moon than your probe which escapes from the system, it is not surprising that I don't rebuilt the exact same error you see. However, since the dynamics of the curves are similar and the order of magnitude is similar, I guess this could be an explanation.

As a summary, Earth motion *is* a complex motion, which is fully taken into account in the JPL ephemerides, and which cannot be accurately represented with only Sun and Moon gravity fields. If you need to do computation far from Earth, you would probably have to take other planets into account (I would say at least Venus and Jupiter, perhaps Mars too).

After some checks, this is not sufficient (adding Venus, Mars, Jupiter and Saturn still produces more than 2000 km error).

I'm still looking for something else.


Also note that even if the two trajectories are not equal, they are very close and your propagation duration is long. Don't forget your probe is 7 millions kilometers away from Earth after 100 days. Given the simplistic assumption you do on Earth motion, I would say between 2000 and 3000 kilometers is not that bad. Earth has moved about 250 millions kilometers during this duration.

Do you agree with this argument?

best regards, and sorry again for the delay

Thank you,


2014-03-20 9:57 GMT+01:00 Luc Maisonobe <Luc.Maisonobe@c-s.fr>:

Le 20/03/2014 09:53, Quentin Nénon a écrit :

I would like to complete my answer of yesterday. What I called
"differential accelerations" is just taking into the relative
acceleration of the two frames.

You will find enclosed a new main class, step handler and a "MyChart"
class for the plots. I modified a little the step handler and the main
and you now have the plots of the difference of position and speed
between the two propagators over the time.

Hi Quentin,

I will only be able to look at this in a few days, I am very busy with
some urgent matters right now.

Sorry for the delay

I am using the jfreechart-1.0.17 and jcommon-1.0.21 libraries for the
plots. You will find enclosed the jar files that should be linked to the
project to have the plots.

Hope this can help.

Thanks again,


2014-03-19 16:10 GMT+01:00 Quentin Nénon <q.nenon@gmail.com

    Thanks again for the fast answer.

    You will find enclosed a MyStepHandler class and a new main class
    that is using this step handler to keep the positions with an output
    step of 1000 secondes (you can modify it in the main class if you
    want). I then write the results in a txt file that I am then used to
    visualize using Excel. I can create charts if you want.

    I already tried to verify that the problem was not due to the fact
    the the Earth EME2000 Frame is not inertial. It seems to already be
    taken into account by using differential accelerations for the
    ThirdBodyAttraction rather than the actual acceleration created by
    the perturbative body. It means that the acceleration due to the Sun
    perturbation in the Earth Frame is equal to the acceleration of the
    satellite due to the Sun in the Sun frame MINUS the acceleration of
    the Earth due to the Sun in the Sun Frame. If the Earth Frame was
    inertial, the acceleration of the Earth in the Sun Frame due to the
    Sun would be 0. and the acceleration of the satellite would be the
    same in the Earth and Sun Frame.

    Moreover, if the Earth motion around the Sun was not taken into
    account, much bigger errors would be expected and all the
    propagations in the EME2000 would be (I think very) wrong.

    Thank you,


    2014-03-19 15:35 GMT+01:00 MAISONOBE Luc <luc.maisonobe@c-s.fr

        Hi Quentin,

        Quentin Nénon <q.nenon@gmail.com <mailto:q.nenon@gmail.com>> a
        écrit :

            Hi Orekit users,

            First, let me thank Luc very much for the very fast and
            effective answer he
            gave to my last topic. It is very nice and enjoyable to have
            support and
            suggestions from the Orekit developer team and users.

        Thanks a lot.

            I have another issue I would like to submit to the Orekit
            users. I am
            trying to use Orekit to propagate  an interplanetary
            trajectory and in
            order to have the best possible precision, I am creating a
            manager of
            sphere of influence. The goal is therefore to be able to
            propagate the
            motion of the spacecraft in different frames (first, in
            inertial frames).

            You will find enclosed a main class that is doing the
            propagation of the
            same motion but from two different point of views :

            -The first one is to consider that the spacecraft is turning
            around the
            Earth central body and has newtonian perturbations coming
            from the Sun and
            from the Moon
            -The second one is to consider that the spacecraft is
            turning around the
            Sun central body and has newtonian perturbations coming from
            the Earth and
            from the Moon.

            I am using the Orekit physical data available on the Orekit
            website. I have
            Orekit 6.1 and commons math 3.2 as dependances.

            At the end of the two propagations, I have a difference in
            the position of
            about 2800 kilometers, that is not very good ... I verified
            with my own
            patch that it is not a problem due to the distances between
            the celestial
            bodies (see the EarthMoonBarycenter topic).

            Does anyone has an idea of why I have this result ? Am I
            doing a mistake
            when I am adding the force models to the propagators ?

        I just skimmed over the code and did not see any obvious error.
        Could you store not only the final position but a few hundreds
        intermediate points at fixed date (you can use an
        OrekitFixedStepHandler for that) and create a plot showing the
        error evolution throughout the propagation?

        I wonder if the problem could not be related to the fact Earth
        frame is not really inertial (due to motion around Sun) and in
        this case it shows up.

        best regards,

            Thanks again,


        This message was sent using IMP, the Internet Messaging Program.

This message was sent using IMP, the Internet Messaging Program.

This message was sent using IMP, the Internet Messaging Program.