Repository navigation
Failing frame comparison test with astropy 3.1 #382
Description
It's not yet clear whether it's an astroplan issue or upstream, please investigate.
cc @eteq
================================================= test session starts ==================================================
platform darwin -- Python 3.7.0, pytest-3.6.4, py-1.6.0, pluggy-0.7.1
Running tests with astroplan version 0.5.dev1135.
Running tests in astroplan docs.
Date: 2018-11-15T17:15:12
Platform: Darwin-17.7.0-x86_64-i386-64bit
Executable: /usr/local/opt/python/bin/python3.7
Full Python Version:
3.7.0 (default, Sep 18 2018, 18:47:22)
[Clang 9.1.0 (clang-902.0.39.2)]
encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15
Numpy: 1.15.4
Scipy: 1.1.0
Matplotlib: 3.0.0
Pandas: 0.23.4
Astropy: 3.1rc1
pytz: 2018.5
pyephem: not available
matplotlib: 3.0.0
pytest-mpl: not available
astropy_helpers: 3.1rc1
Using Astropy options: remote_data: any.
rootdir: /private/var/folders/dc/hsm7tqpx2d57n7vb3k1l81xw0000gq/T/astroplan-test-q1faxskt/lib/python3.7/site-packages, inifile: setup.cfg
plugins: remotedata-0.3.0, openfiles-0.3.0, doctestplus-0.1.3, cov-2.6.0, arraydiff-0.2
collected 116 items
astroplan/constraints.py ..... [ 4%]
astroplan/observer.py ................. [ 18%]
astroplan/target.py . [ 19%]
astroplan/plots/tests/test_sky.py . [ 20%]
astroplan/tests/test_constraints.py ....................... [ 40%]
astroplan/tests/test_moon.py . [ 41%]
astroplan/tests/test_observer.py ........................... [ 64%]
astroplan/tests/test_periodic.py ..... [ 68%]
astroplan/tests/test_scheduling.py ............. [ 80%]
astroplan/tests/test_target.py ..F [ 82%]
astroplan/tests/test_utils.py .... [ 86%]
docs/api.rst . [ 87%]
docs/changelog.rst . [ 87%]
docs/getting_started.rst . [ 88%]
docs/index.rst . [ 89%]
docs/installation.rst . [ 90%]
docs/faq/contribute.rst . [ 91%]
docs/faq/iers.rst . [ 92%]
docs/faq/index.rst . [ 93%]
docs/faq/precision.rst . [ 93%]
docs/faq/terminology.rst . [ 94%]
docs/tutorials/constraints.rst . [ 95%]
docs/tutorials/index.rst . [ 96%]
docs/tutorials/periodic.rst . [ 97%]
docs/tutorials/plots.rst . [ 98%]
docs/tutorials/scheduling.rst . [ 99%]
docs/tutorials/summer_triangle.rst . [100%]
======================================================= FAILURES =======================================================
__________________________________________________ test_get_skycoord ___________________________________________________
def test_get_skycoord():
m31 = SkyCoord(10.6847083*u.deg, 41.26875*u.deg)
m31_with_distance = SkyCoord(10.6847083*u.deg, 41.26875*u.deg, 780*u.kpc)
subaru = Observer.at_site('subaru')
time = Time("2016-01-22 12:00")
pos, vel = subaru.location.get_gcrs_posvel(time)
gcrs_frame = GCRS(obstime=Time("2016-01-22 12:00"), obsgeoloc=pos, obsgeovel=vel)
m31_gcrs = m31.transform_to(gcrs_frame)
m31_gcrs_with_distance = m31_with_distance.transform_to(gcrs_frame)
coo = get_skycoord(m31)
assert coo.is_equivalent_frame(ICRS())
with pytest.raises(TypeError) as exc_info:
len(coo)
coo = get_skycoord([m31])
assert coo.is_equivalent_frame(ICRS())
assert len(coo) == 1
coo = get_skycoord([m31, m31_gcrs])
assert coo.is_equivalent_frame(ICRS())
assert len(coo) == 2
coo = get_skycoord([m31_with_distance, m31_gcrs_with_distance])
assert coo.is_equivalent_frame(ICRS())
assert len(coo) == 2
coo = get_skycoord([m31, m31_gcrs, m31_gcrs_with_distance, m31_with_distance])
assert coo.is_equivalent_frame(ICRS())
assert len(coo) == 4
coo = get_skycoord([m31_gcrs, m31_gcrs_with_distance])
> assert coo.is_equivalent_frame(m31_gcrs.frame)
E assert False
E + where False = <bound method SkyCoord.is_equivalent_frame of <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, kpc)\n [(10.6847083, 41.26875, 100.), (10.6847083, 41.26875, 780.)]>>(<GCRS Coordinate (obstime=2016-01-22 12:00:00.000, obsgeoloc=(-4952566.74044721, 3393196.50332016, 2158839.2227695) m, obsgeovel=(-247.44326373, -361.39190633, 0.3680486) m / s): (ra, dec) in deg\n (10.68224059, 41.27142713)>)
E + where <bound method SkyCoord.is_equivalent_frame of <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, kpc)\n [(10.6847083, 41.26875, 100.), (10.6847083, 41.26875, 780.)]>> = <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, kpc)\n [(10.6847083, 41.26875, 100.), (10.6847083, 41.26875, 780.)]>.is_equivalent_frame
E + and <GCRS Coordinate (obstime=2016-01-22 12:00:00.000, obsgeoloc=(-4952566.74044721, 3393196.50332016, 2158839.2227695) m, obsgeovel=(-247.44326373, -361.39190633, 0.3680486) m / s): (ra, dec) in deg\n (10.68224059, 41.27142713)> = <SkyCoord (GCRS: obstime=2016-01-22 12:00:00.000, obsgeoloc=(-4952566.74044721, 3393196.50332016, 2158839.2227695) m, obsgeovel=(-247.44326373, -361.39190633, 0.3680486) m / s): (ra, dec) in deg\n (10.68224059, 41.27142713)>.frame
astroplan/tests/test_target.py:81: AssertionError
Activity
eteq commentedon Nov 16, 2018
Hmm, it is not obvious to me if this is something astroplan is doing that's not quite right or if it's a bug in astropy, but either way it's probably a subtle behavior change in
astropy.coordinatesin 3.1. So will add an issue an astropy for this...adrn commentedon Nov 27, 2018
Yea, I'm wondering if the issue is in astroplan's
get_skycoord()?It looks like this function is basically concatenating the input coordinates (or targets). But the
SkyCoordinitializer or theconcatenate()function can do that automatically. Maybeget_skycoord()can be simplified to first parse out the coordinate objects, then pass the list in toSkyCoord?eteq commentedon Dec 3, 2018
I agree this should probably more efficiently use the
SkyCoordorconcatenate... And that should be the subject of this issue.But as it turns out there's a real behavior change in astropy 3.1 here (see astropy/astropy#8138 for more)
eteq commentedon Dec 5, 2018
Also, to confirm here: astropy/astropy#8218 should fix this, so if that's merged this can be closed.
pllim commentedon Aug 20, 2019
Close this?