Skip to content

Ecliptic coordinate transformation precision #6461

Closed

Description

@astrofrog

At the moment, the tests for the ecliptic frame only check that things are accurate to 1 arcminute:

https://github.com/astropy/astropy/blob/master/astropy/coordinates/tests/accuracy/test_ecliptic.py#L29

The coordinates-benchmark summary page also shows that Astropy's ecliptic implementation seems to disagree with all others by 10 arcseconds or more. This issue is a reminder that we should fix this.

There is a related issue to use ERFA for the Ecliptic transformation: #4873

I'm labelling this as a bug since I think we want to backport any fix to the 2.0 LTS series. I'm also labelling this as being high priority since I think these kinds of accuracy issues should not be present in a 'core' library.

Activity

  1. astrojuanlu commented on Sep 1, 2017

    @astrojuanlu
    Member

    I started using the Ecliptic reference frames from Astropy when loading asteroid data from the JPL Small-Body Database Browser and found some discrepancies. By suggestion of @mhvk I copy my conclusions here:

    Although it was stated in the wiki that the results from Horizons and the Small Object Browser are not exactly the same, in fact all the differences stay within the declared uncertainties (1 sigma), so we can consider them equal in some sense 🙂

    And on the other hand, this is the information Horizons gives about the reference frame:

    Coordinate system description:

    Ecliptic and Mean Equinox of Reference Epoch

    Reference epoch: J2000.0
    XY-plane: plane of the Earth's orbit at the reference epoch
              Note: obliquity of 84381.448 arcseconds wrt ICRF equator (IAU76)
    X-axis  : out along ascending node of instantaneous plane of the Earth's
              orbit and the Earth's mean equator at the reference epoch
    Z-axis  : perpendicular to the xy-plane in the directional (+ or -) sense
              of Earth's north pole at the reference epoch.
    

    With respect to the obliquity, this is the result of using Astropy functions:

    
    In [8]: from astropy.time import Time
    
    In [9]: equinox = Time("J2000")
    
    In [11]: from astropy.coordinates.builtin_frames.utils import get_jd12
    
    In [12]: jd1, jd2 = get_jd12(equinox, 'tt')
    
    In [13]: from astropy import units as u
    
    In [14]: obl = erfa.obl06(jd1, jd2)*u.radian
    
    In [15]: obl
    Out[15]: <Quantity 0.40909260059596453 rad>
    
    In [20]: obl.to(u.arcsec)
    Out[20]: <Quantity 84381.4059990474 arcsec>```
    

    which is slightly different from the announced value of 84381.448 arcseconds. This is because Horizons uses the ICRF equator of IAU76!

    
    In [24]: obl80
    Out[24]: <Quantity 0.40909280421771277 rad>
    
    In [25]: obl80.to(u.arcsecond)
    Out[25]: <Quantity 84381.44799904784 arcsec>```
    

    So we need a mean ecliptic of IAU76, which is not present in Astropy.

  2. added a commit that references this issue on Sep 3, 2017
    fb8efaa
  3. added a commit that references this issue on Nov 28, 2017
    3219570
  4. added a commit that references this issue on Dec 6, 2017
    728dedf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions