Skip to content

get_moon does not support non-scalar times for non-geocentric observer #5216

Closed

Description

@bmorris3

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).

cc @StuartLittlefair @eteq @mhvk

Activity

  1. StuartLittlefair commented on Aug 4, 2016

    @StuartLittlefair
    Contributor

    Thanks for raising this @bmorris3.
    There's a PR already submitted which should fix this issue.

  2. StuartLittlefair commented on Nov 17, 2016

    @StuartLittlefair
    Contributor

    @bmorris3 this has been addressed now by #5253. Perhaps you can close?

  3. lpsinger commented on Nov 17, 2016

    @lpsinger
    Contributor

    Thanks for fixing this! When can we expect to see it in a release?

  4. pllim commented on Nov 17, 2016

    @pllim
    Member

    @lpsinger , that fix is tagged for 1.3, so hopefully late December 2016 or early January 2017.

  5. bsipocz commented on Nov 17, 2016

    @bsipocz
    Member

    @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

  6. StuartLittlefair commented on Nov 17, 2016

    @StuartLittlefair
    Contributor

    @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.

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