[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Users] Problem with the EarthMoonBarycenter
- To: orekit-users@orekit.org
- Subject: Re: [Orekit Users] Problem with the EarthMoonBarycenter
- From: MAISONOBE Luc <luc.maisonobe@c-s.fr>
- Date: Fri, 07 Mar 2014 14:45:11 +0100
- In-reply-to: <CAGbXLWjK_KRr_=q+5GUE3v4gN3cFagPSqUyzGEn0YZkpR=J-UA@mail.gmail.com>
- References: <CAGbXLWjK_KRr_=q+5GUE3v4gN3cFagPSqUyzGEn0YZkpR=J-UA@mail.gmail.com>
- User-agent: Internet Messaging Program (IMP) H3 (4.3.9)
Quentin Nénon <q.nenon@gmail.com> a écrit :
Hi,
Hi Quentin,
I am using the EarthMoonBarycenter body from the CelestialBodyFactory and I
have a problem : the position of the body in the ICRF frame seems to be
wrong as well as the position in the Sun-centered inertially oriented
frame. The distances between the Sun and the EarthMoonBarycenter are
therefore different depending on the frame used for the computation of the
positions of the Sun and the EarthMoonBarycenter.
You are right, this is a bug.
I have registered it in the issue tracker here:
<https://www.orekit.org/forge/issues/165>.
The problem is due to the way JPLCelestialBody is implemented.
JPL ephemerides provides the position of Earth-Moon barycenter with
respect to the Solar system barycenter, and the position of Moon with
respect to Earth.
In order to connect everything, some scaling factors are applied. A
-1.0 scaling factor is applied to Earth-Moon barycenter coordinates to
compute Solar system barycenter with respect to Earth-Moon barycenter.
A 1/(1+η) scaling factor is applied to geocentric Moon
coordinates to compute Earth-Moon barycenter with respect to Earth,
where η is the mass ratio between Earth and Moon.
This scaling factor is not applied correctly when retrieving
PVCoordinates in a frame that is not the defining frame. The
translation is applied first and the translated coordinates are
scaled, which is wrong!
I have fixed the issue in the development version. If you prefer to
simply patch your current version, the important part of the patch is
here:
<https://www.orekit.org/forge/projects/orekit/repository/revisions/202ca0f9e09a8673653ed5fa7b85789110677b70/diff/src/main/java/org/orekit/bodies/JPLCelestialBody.java>
The velocity of the EarthMoonBarycenter around the Sun is also strange.
The fact the velocity is different depending on the frames is normal.
When using transformPVCoordinates to transform velocity, you don't
simply project a velocity, you change its reference. The obvious
consequence is that if you transform the velocity of a moving
celestial body in its own inertial frame, you get 0 as a result since
the body does not move with respect to itself. If you need to
"project" a velocity defined in frame 1 into frame 2 without changing
its definition (i.e. it will still represent a velocity with respect
to frame 1, but its direction cosines will be agains frame 2 axes),
then instead of using the transformPVCoordinates method in Transform
class, you must use the transformVector method in the same class.
The enclosed main class points out these problems and is using :
-Orekit 6.1 and commons math 3.2 as dependances
-the "orekit-data" physical dataset available on the Orekit website
I would like to know if anyone see something I am doing wrong or if I am
not considering the EarthMoonBarycenter instance in a good way. Then, if my
test highlights an issue with Orekit, I would be happy to participate in
the effort of finding the source of the problem. I am surprised by this one
as the EarthMoonBarycenter positions and speeds are directly interpolated
from the JPL ephemerides, not like the Earth ones for instance.
Thank you,
Thank you for the report
Luc
Quentin
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.