astropy: Test failure in test_aa_high_precision()

Description

This is in regards to issue #11527 and PR #11564. At first, I didn’t worry too much about the failure as the difference appeared to be small enough to be ascribed to the change in the handling of polar motion introduced in pyerfa 1.7.2. I calculate that differences due to this change should be less than 1 uas and the difference shown in issue #11547 is 8.63433769e-11 degrees or 0.31 uas, but then along came PR #11564 which is evidently showing the following differences:

Azimuth 19.62 uas
Elevation 0.85  uas
Distance 38.87 mm

These seemed excessively large to me, so I downloaded the latest version of SOFA and reran my test program. The results for the time used in the test are:

       Time            Azimuth         Elevation       Distance (m)    DUT1      Xp       Yp
2017-04-06 00:00:00 15.032673509956 50.303110133923 376252883.247239 0.4634343 0.009587 0.384603

Here I am including the EOP values to make sure that we are still on the same page in that regard. The differences between this and the previous version of SOFA that I used are:

Azimuth 0.252 uas
Elevation -0.018 uas
Distance  0.000 mm

Considering the apparent discrepancy, I think it would be worthwhile to revisit the entire 24 hour test. If someone could please run the following script and post the output here, I can take a look at this.

astropy_topo_test.py.txt

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 24 (20 by maintainers)

Most upvoted comments

Re-pkg_resources: we replaced it with importlib.metadata (#11091)

saimn on May 5, 2021

No problem, having the separate issue helps track the change. I’ve resolved it; __version__ should appear with the next release.

brandon-rhodes on May 5, 2021

Okay, so here is what I see in the eopc04_IAU2000.62-now file, it is basically the file from main, as I did an editable install from source. If there is some API calls for extra checks, please let me know.

      Date      MJD      x          y        UT1-UTC       LOD         dX        dY        x Err     y Err   UT1-UTC Err  LOD Err     dX Err       dY Err  
                         "          "           s           s          "         "           "          "          s         s            "           "
     (0h UTC)
2017   4   6  57849   0.009587   0.384603   0.4634343   0.0014635  -0.000063   0.000300   0.000060   0.000046  0.0000179  0.0000132    0.000046    0.000041

And then, I run the following manually in a Python session:

>>> import astropy
>>> astropy.__version__
'4.3.dev1480+g0860b7006'
>>> from astropy import units as u
>>> from astropy.coordinates import AltAz, EarthLocation, solar_system_ephemeris
>>> from astropy.coordinates.solar_system import get_body
>>> from astropy.time import Time
>>> lat = -22.959748 * u.deg
>>> lon = -67.787260 * u.deg
>>> elev = 5186 * u.m
>>> loc = EarthLocation.from_geodetic(lon, lat, elev)
>>> t = Time('2017-04-06T00:00:00.0', location=loc)
>>> with solar_system_ephemeris.set('de430'):
...     moon = get_body('moon', t, loc)
...     moon_aa = moon.transform_to(AltAz(obstime=t, location=loc))
>>> TARGET_AZ = 15.032673509886 * u.deg

With jplephem 2.14

>>> moon_aa.az
<Longitude 15.03267352 deg>
>>> moon_aa.az - TARGET_AZ
<Angle 5.44987699e-09 deg>
>>> (moon_aa.az - TARGET_AZ).to(u.uas)
<Angle 19.61955718 uas>

With jplephem 2.15

>>> moon_aa.az
<Longitude 15.03267351 deg>
>>> moon_aa.az - TARGET_AZ
<Angle 8.63433769e-11 deg>
>>> (moon_aa.az - TARGET_AZ).to(u.uas)
<Angle 0.31083616 uas>

There is currently no pin on the jplephem minversion:

https://github.com/astropy/astropy/blob/0860b70066656682f852c6683a19b6d0b6b82164/setup.cfg#L77

pllim on May 3, 2021

Perhaps, your EOP file is different. Please take a look at astropy.utils.iers.data.eopc04_IAU2000.62-now and check x, y, and UT1-UTC for April 6th, 2017 to see if they are the same as my Xp, Yp, and DUT1.

mkbrewer on May 3, 2021