[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] [Orekit Users] Planetary Ephemeris
Le 23/10/2015 12:52, MAISONOBE Luc a écrit :
> Hi,
Hi all,
>
> [note that I have added the dev list here, if we continue
> this thread it should probably be done on the dev lists
> rather than the users list]
>
> Evan Ward <evan.ward@nrl.navy.mil> a écrit :
>
>> Hi Hank,
>>
>> My guess is a reference frame mismatch since the errors increase the
>> further you get from Earth. Have you tried getting the positions in the
>> GCRF frame in Orekit? I think Orekit assumes that the JPL ECI frame is
>> GCRF. I think the slight bias between GCRF and J2000 as implemented in
>> Orekit would be about the same order of magnitude for the errors you're
>> seeing.
>
> I agree this may be a problem. Take a look for example at slide 12
> in the JPL NAIF tutorial about frames here:
>
> <http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/17_frames_and_coordinate_systems.pdf>
>
>
> This slides reads:
>
> ------------------
> The realization of ICRF was made to coincide almost
> exactly with the J2000 frame.
>
> – The difference is very small–a rotation of less than 0.1 arc second
> – These two frames are considered the same in SPICE
> » In reality, any SPICE data said to be referenced to the J2000
> frame are actually referenced to the ICRF frame
> » For historical and backwards compatibility reasons, only the
> name “J2000” is recognized by SPICE software as a frame
> name–not “ICRF”
>
> • No transformation is required to convert SPICE state
> vectors orientation data from the J2000 frame to
> the ICRF.
> ------------------
After some investigation, this was a red-herring. The frame used within
ephemerides s really ICRF and compliant with IAU definitions. The (now
old) document for DE414
(<http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/a_old_versions/de414iom.pdf>)
states that
ICRF is the reference frame for DE414. The more recent document for
DE 430 and DE 431
<http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de430_and_de431.pdf>
confirms this and adds that
" The orbits of the inner planets are aligned with ICRF2 with an
accuracy of 0′′.0002 through use of VLBI observations of
spacecraft in orbit about Mars. "
So Orekit assumption to use frames aligned with ICRF and taking into
account the rotation bias between ICRF and EME2000 is correct.
>
> In Orekit, however, we do take into account this bias. As up to now
> we thought JPL published everything in "ICRF aligned" frames centered
> at various points and it appears it may really be in "EME2000 eligned"
> frames at various points, we may need to change JPLEphemerisLoader.
>
> There is however another issue we identified only yesterday, while
> working on the IAU pole models. Up to now, Orekit did consider that
> the reference dates of these models may be in some specific time scale
> (most of the time TDB), the durations from these reference dates was
> always computed in an Eart-based scale (i.e. with a time flow rate
> equal to that of TT, TAI or UTC). This was wrong. For solar system
> related models, the flow rate of time should be something less
> Earth-centric,
> it is really defined in TDB. On the long term, there is no drift as
> TDB is a small harmonic variation with respect to TT (due to Earth
> velocity I guess and relativity I guess).
>
> This was fixed yesterday for IAU pole (see commit 2fa02be). It should
> also be fixed in JPL ephemeris. I have set up a first patch (not complete
> because I also have to update unit tests, 13 of which now failing due
> to the change). This path is attached. Could you try it and tell me if
> this improves things? It will probably not fix everything as the
> EME2000/ICRF bias issue is till there.
The issue was confirmed to be present in both IAU pole models and
JPL/Inpop ephemerides. It has been fixed now and the fix has been pushed
to the git repository.
>
> We are currently working on some new tests with reference data computed
> using NAIF libraries, so I think we will eventually be able to fix
> this completely.
We have completed the tests and included them in the Junit set of tests.
We have also added a test with respect to the Horizon system, using
data extracted from a telnet sessions.
The fact there was about one hundred kilometers difference in the
Jupiter position is due to the fact the DE-430 ephemeris contains the
position of the barycenter of the Jovian system rather thant the
center of Jupiter body. In the Horizon (or NAIF) systems, selecting one
or the other is done by selecting target 5 (Jupiter Barycenter) or
target 599 (Jupiter). When we compare Orekit output using DE-430 to
Horizon results with Jupiter barycenter, we get a position difference
of 0.4mm (see testHorizon in CelestialBodyFactoryTest. When we compare
Orekit output using DE-430 to NAIF library results for several planets
we get position differences of a few meters (max error 15m for Mercury,
Jupiter error about 1m).
best regards,
Luc
>
> best regards,
> Luc
>
>>
>> Best Regards,
>> Evan
>>
>> On 10/18/2014 03:26 PM, Hank Grabowski wrote:
>>> I'm querying for planetary ephemeris and to make sure I am getting
>>> expected values I'm comparing my results against the JPL HORIZONS
>>> website. Unfortunately I'm not seeing the accuracies that I was
>>> expecting. I'm querying for January 1st at midnight for the year
>>> 2000 and 2015. I'm doing this for the Sun, Moon and Jupiter. The Sun
>>> position is around 5100 meters off, the moon position is about 40
>>> meters off and Jupiter's position is between 137 km and 179 km off.
>>>
>>> I downloaded and have Orekit using the 421 ephemerides at this point.
>>> These get me closest. I've tried 406, 423 and 430. The 430
>>> ephemerides didn't even load (I believe they changed the format
>>> slightly) and 406 was worse by at least 20%. My settings on the
>>> website are:
>>>
>>> Ephemeris Type: Vectors
>>> Target Body: Jupiter [599], Sun [10] or Moon [301]
>>> Coordinate Origin: Geocentric [500] (which is Earth[399] BODY CENTER)
>>> Reference plane: Earth mean equator and equinox of reference
>>> Reference System: ICRF/J2000
>>> Type: Geometric states (no aberration; instantaneous dynamic states)
>>>
>>> Times entered for vector format is always in Coordinate Time, which
>>> matches Orekit's TDB timescale. I'm generating my "actual" values
>>> using code like this:
>>>
>>> PVCoordinatesProvider pvSun = CelestialBodyFactory.getSun();
>>> Frame j2000 = FramesFactory.getEME2000();
>>>
>>> AbsoluteDate epoch = new AbsoluteDate(2000, 1, 1, 0, 0, 0,
>>>
>>> TimeScalesFactory.getTDB());
>>>
>>> Vector3D actualPosition = pvSun.getPVCoordinates(epoch, j2000)
>>> .getPosition();
>>>
>>>
>>> It's not clear to me what I am doing wrong. I've tried messing around
>>> with the coordinate frame, timescale and changing the type generated
>>> by HORIZONS to include light time delay and stellar aberration. The
>>> closest I've gotten to matching HORIZONS is with the above
>>> configuration of the HORIZONS site and this code.
>>>
>>> If anything jumps out at someone, let me know.
>>>
>>> Thanks!
>>>
>>> Hank
>
>