[AstroPy] consistency of reference frames between SkyCoord and JPL Horizons

[Benjamin Weiner]

Hello Paolo,

I am not entirely sure what end result you wish to achieve, nor am I an
expert on SkyCoord.  However, I have a suggestion to understand further
these discrepancies (and thank you for including the notebook example). In
your first example:
(a) JPL's barycentric coords to build ICRS at specified time, then
transformed to GCRS at specified time.
(b) JPL's apparent coords to build GCRS at specified time.

The separation of 16 arcmin between (a) and (b) is due to the precession of
the Earth's axis from 2000 to 2020.  This can be seen if we substitute
   time = Time('2000-01-01T00:00:00', scale='utc')
in the line of your notebook that sets the time. At 2000-01-01, the
separation reduces to 8 arcseconds, which you have identified as coming
from the aberration of starlight.

I think that the discrepancy is in building the GCRS coordinates from the
apparent RA/Dec.  The JPL apparent coordinates are referenced to the
position of the Earth's axis at the specified time. But the axes of GCRS
are non-rotating with respect to the axes of BCRS and ICRS - that is, GCRS
is fixed to the Earth's center, but not to the Earth's axis, and does not
precess.  I believe that this is correct - USNO circular 179 has more gory
details on the definition of coordinate frames, see
https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf

Cheers,
Ben

On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org> wrote:

>
> Message: 1
> Date: Fri, 24 Apr 2020 15:00:22 +0200
> From: Paolo Tanga <Paolo.Tanga at oca.eu>
> To: AstroPy at python.org
> Subject: [AstroPy] consistency of reference frames between SkyCoord
>         and JPL Horizons
> Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi all
>
> I am trying to plug the results by JPL Horizons into the appropriate
> reference system of a SkyCoord object, but it looks very trick. (bewore
> long message, I hope the explanation is clear for the specialists of
> reference systems)
>
> The Horizons server returns two types of equatorial coordinates:
> "astrometric" (1) and (2) "apparent".
>
> Their description is the following:
>
> - (1): astrometric RA and Dec with respect to the observing site
> (coordinate origin) in the reference frame of
> the planetary ephemeris (ICRF). Compensated for down-leg light-time
> delay aberration.
>
> - (2): Airless apparent RA and Dec of the target with respect to an
> instantaneous reference frame defined by the Earth equator of-date
> (z-axis) and meridian containing the Earth equinox of-date (x-axis,
> IAU76/80). Compensated for down-leg light-time delay, gravitational
> deflection of light, stellar aberration, precession & nutation. Note:
> equinox (RA origin) is offset -53 mas from the of-date frame defined by
> the IAU06/00a P & N system.
>
> My guess is none of these two systems correspond to either ICRS or GCRS
> as defined in astropy. The simplest possibility for me, would have been
> to assimilate (1), computed for the Solar System barycenter, to ICRS.
> But definitely (2) is not GCRS and the test below easily proves that.
>
> Verification (see the attached notebook if you want to play with) :
>
> - I queried for Solar System barycentric coordinates (1) of an asteroid
> at one epoch. I inserted them in a SkyCoord object as ICRS and use the
> transform_to(GCRS) towards geocentric, at the given epoch.
>
> - I queried again JPL Horizons for the apparent coordinates (2) from the
> geocenter, directly.
>
> As expected, by comparing the results I get the patent confirmation that
> GCRS is not the frame of (2), with a discrepancy of 16 arcmin in my
> case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent coordinates
> (2) aside for the moment.
>
> Second possibility (see notebook again).
>
> I take coordinates (1), for the geocentric observer. I insert them as
> GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric observer)
> and compare the result to a query of (1) directly for the barycentric
> observer.
>
> Again this SHOULD NOT WORK accurately. In fact the definition of (1)
> does not contain annual aberration and light deflection that are part of
> GCRS. A difference of several arcsec (mostly due to annual aberration)
> SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>
> The conclusions if that using SkyCoord with the output of JPL Horizons
> is far from obvious to the end user...
>
> ----
>
> So, my final questions/remarks are:
>
> - How to get a fully accurate consistency between a SkyCoord frame and
> JPL Horizons output, in the case of a barycentric, geocentric or
> topocentric observer, for both "astrometric" and "apparent" coordinates
> as provided by JPL? Which reference SkyCoord should use and how?
>
> - Does astropy implement GCRS correctly in the case of Solar System
> objects, by taking into account aberration and light deflection in the
> relativistic form, for an object at finite distance (different than for
> the stars!) ?
>
> - ...or... Am I missing something fundamental in my interpretation?
>
> - Eventually, this query to Horizons turns our to be tricky to manage as
> SkyCoord for the final user. I think it would be useful to provide the
> correct recipe and/or directly a SkyCoord as output of the query...
>
> Best regards
>
> Paolo
>
>
-- 
Benjamin Weiner
Staff Scientist / Associate Astronomer, MMT / Steward Observatory
bjw at as.arizona.edu
http://mingus.mmto.arizona.edu/~bjw/ <http://mingus.as.arizona.edu/~bjw/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200425/9b68a11a/attachment.html>