Repository navigation
Closed
Labels
Description
If you call get_moon with a non-scalar time and specify an observer location with the location keyword argument, the function fails. Here's an example:
In [1]: from astropy.coordinates import EarthLocation, get_moon
In [2]: from astropy.time import Time
In [3]: get_moon(Time(['2014-01-01', '2014-01-02']))
Out[3]:
<SkyCoord (GCRS: obstime=['2014-01-01 00:00:00.000' '2014-01-02 00:00:00.000'], obsgeoloc=[ 0. 0. 0.] m, obsgeovel=[ 0. 0. 0.] m / s): (ra, dec, distance) in (deg, deg, AU)
[(273.79665999, -19.09558029, 0.00239101),
(289.77426273, -17.30906137, 0.00238599)]>
In [4]: location = EarthLocation.of_site('apo')
In [5]: get_moon(Time(['2014-01-01', '2014-01-02']), location=location)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-5-782877431d86> in <module>()
----> 1 get_moon(Time(['2014-01-01', '2014-01-02']), location=location)
/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/solar_system.py in get_moon(time, location, ephemeris)
378 """
379
--> 380 return get_body('moon', time, location=location, ephemeris=ephemeris)
381
382 get_moon.__doc__ += indent(_EPHEMERIS_NOTE)[4:]
/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/solar_system.py in get_body(body, time, location, ephemeris)
344 gcrs = icrs.transform_to(GCRS(obstime=time,
345 obsgeoloc=obsgeoloc,
--> 346 obsgeovel=obsgeovel))
347 else:
348 gcrs = icrs.transform_to(GCRS(obstime=time))
/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in __init__(self, *args, **kwargs)
540
541 # Validate input by getting the attribute here.
--> 542 getattr(self, fnm)
543
544 args = list(args) # need to be able to pop them
/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in __get__(self, instance, frame_cls)
210 out = self.default
211
--> 212 out, converted = self.convert_input(out)
213 if instance is not None and converted:
214 setattr(instance, '_' + self.name, out)
/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in convert_input(self, value)
333 raise ValueError('The provided value has shape "{0}", but '
334 'should have shape "{1}"'.format(value.shape,
--> 335 self.shape))
336 if (oldvalue.unit == value.unit and hasattr(oldvalue, 'value') and
337 np.all(oldvalue.value == value.value)):
ValueError: The provided value has shape "(3, 2)", but should have shape "(3,)"This is using astropy v1.2. This is related to the old closed issue #5069. This is coming up because we are using get_moon in astroplan and have to loop over each time to avoid this bug, which is a pretty slow solution (astropy/astroplan#211).
Activity
StuartLittlefair commentedon Aug 4, 2016
Thanks for raising this @bmorris3.
There's a PR already submitted which should fix this issue.
StuartLittlefair commentedon Nov 17, 2016
@bmorris3 this has been addressed now by #5253. Perhaps you can close?
lpsinger commentedon Nov 17, 2016
Thanks for fixing this! When can we expect to see it in a release?
pllim commentedon Nov 17, 2016
@lpsinger , that fix is tagged for 1.3, so hopefully late December 2016 or early January 2017.
bsipocz commentedon Nov 17, 2016
@StuartLittlefair - Actually I still see similar failures in astroplan when testing against astropy dev, but don't have time at the moment to investigate further. It can either be an astroplan bug, or upstream in astropy, (or a legit API change in astropy that I haven't noticed).
See e.g.: https://travis-ci.org/astropy/astroplan/jobs/176492884#L790 and below
StuartLittlefair commentedon Nov 17, 2016
@bsipocz Those errors look like they are related to changes made in #5254, which made frames and their attributes (I.e obstimes) handle shapes correctly.
IIRC there are a number of places in astroplan where these attributes are assumed to be 1D lists which is probably causing the errors you see.
We should probably discuss this further on the astroplan repo but IMO the decision to use lists of FixedTargets in that code rather than non scalar
SkyCoords had led to a lot of pain and poor performance, as well as the bugs you're seeing. It may be wise to consider a code refactoring.