astroplan not ready for astropy-1.3 yet

@bsipocz

As discussed in astropy/astropy#5651 with @bsipocz and @ViviCoder (Debian maintainer of astroplan), astroplan still fails in a number of tests with astropy 1.3, even with some necessary patches added. This makes astroplan currently unsuitable for the upcoming Debian Stretch release, which will include astropy 1.3 (with bug fixes).
Is there any chance to get the astroplan failures fixed in the next days? Then we could release Debian Stretch including astroplan, which would be quite nice.

@bmorris3

There's some discussion under other the issues already, e.g. #263 or #278. Basically only one incompatibility is remained to be fixed (the broadcasting issue). I'm not sure whether @bmorris3 has the time to merge the current PRs and work on the remaining issue and do a release.

@bsipocz

Oops, I see that this mainly duplicates #263 -- this is, however since the caption of #263 is misleading. I thought (from the date the issue was opened) that "stable" means the previous astropy version (1.2), so I didn't check this out.
However, I can confirm that when I apply #274 and #281 (and use a patched version of astropy), the only remaining problem are broadcasting issues.
@bsipocz do you have a fix for that? We don't need a new version; a patch would be fine to keep astroplan in the next Debian release :-)

Sadly, I don't have a fix for it yet, I only had a quick debug session of it and couldn't see why it fails. I maybe some triviality though for someone knowing more about numpy tricks...

Is this a bug in astroplan or in astropy? I could imagine that it has the same cause as astropy/astropy#5650 ... but I am not familiar with the broadcasting stuff ...

@olebole

I tried to spend some time today looking at this. I applied #273 #274 and #281 after which there were still 6 outstanding errors. Applying the following reduces that to 3 errors, all in test_scheduling.py and all consistent with the error @olebole pointed out in astropy. Everything else I tried seemed to point to that error in astropy rather than in astroplan, but I could be wrong.

The first patch is just making the indexes use integers instead of floats and there's probably a better way to do it. The second patch is just a simplification based on the new vector support so bypasses the issue pointed out above. I can submit these as a separate pull-request if desired.

diff.txt

I can confirm this. The remaining failures are all similar, so here is the first one:

______________________________ test_transitioner _______________________________
self = <astropy.coordinates.baseframe.TimeFrameAttribute object at 0x7f80365e23c8>
instance = <[ValueError("attribute obstime should be scalar or have shape (2, 1), but is has shape (2,) and could not be broadcast.") raised in repr()] AltAz object at 0x7f8032fb2470>
frame_cls = <class 'astropy.coordinates.builtin_frames.altaz.AltAz'>

    def __get__(self, instance, frame_cls=None):
[...]
        if instance is not None:
            instance_shape = getattr(instance, 'shape', None)
            if instance_shape is not None and (getattr(out, 'size', 1) > 1 and
                                               out.shape != instance_shape):
                # If the shapes do not match, try broadcasting.
                try:
                    if isinstance(out, ShapedLikeNDArray):
                        out = out._apply(np_broadcast_to, shape=instance_shape,
>                                        subok=True)

/usr/lib/python3/dist-packages/astropy/coordinates/baseframe.py:227: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <Time object: scale='utc' format='iso' value=['2016-02-06 03:00:00.000' '2016-02-06 03:00:00.000']>
method = <function broadcast_to at 0x7f803ce8ce18>, args = ()
kwargs = {'shape': (2, 1), 'subok': True}, new_format = 'iso'
apply_method = <function Time._apply.<locals>.<lambda> at 0x7f803a69c730>
jd1 = array([ 2457424.5,  2457424.5]), jd2 = array([ 0.125,  0.125])

    def _apply(self, method, *args, **kwargs):
[...]
        if callable(method):
            apply_method = lambda array: method(array, *args, **kwargs)
        else:
            if method == 'replicate':
                apply_method = None
            else:
                apply_method = operator.methodcaller(method, *args, **kwargs)
    
        jd1, jd2 = self._time.jd1, self._time.jd2
        if apply_method:
>           jd1 = apply_method(jd1)

/usr/lib/python3/dist-packages/astropy/time/core.py:849: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

array = array([ 2457424.5,  2457424.5])

>   apply_method = lambda array: method(array, *args, **kwargs)

/usr/lib/python3/dist-packages/astropy/time/core.py:840: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

array = array([ 2457424.5,  2457424.5]), shape = (2, 1), subok = True

    def broadcast_to(array, shape, subok=False):
        """[...]"""
>       return _broadcast_to(array, shape, subok=subok, readonly=True)

/usr/lib/python3/dist-packages/numpy/lib/stride_tricks.py:174: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

array = array([ 2457424.5,  2457424.5]), shape = (2, 1), subok = True
readonly = True

    def _broadcast_to(array, shape, subok, readonly):
[...]
        broadcast = np.nditer(
            (array,), flags=['multi_index', 'refs_ok', 'zerosize_ok'] + extras,
>           op_flags=[op_flag], itershape=shape, order='C').itviews[0]
E       ValueError: operands could not be broadcast together with remapped shapes [original->remapped]: (2,) and requested shape (2,1)

/usr/lib/python3/dist-packages/numpy/lib/stride_tricks.py:129: ValueError

During handling of the above exception, another exception occurred:

    def test_transitioner():
        blocks = [ObservingBlock(t, 55 * u.minute, i) for i, t in enumerate(targets)]
        slew_rate = 1 * u.deg / u.second
        trans = Transitioner(slew_rate=slew_rate)
        start_time = Time('2016-02-06 03:00:00')
>       transition = trans(blocks[0], blocks[2], start_time, apo)

astroplan/tests/test_scheduling.py:112: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
astroplan/scheduling.py:842: in __call__
    sep = aaz[0].separation(aaz[1])[0]
/usr/lib/python3/dist-packages/astropy/utils/misc.py:941: in __getitem__
    return self._apply('__getitem__', item)
/usr/lib/python3/dist-packages/astropy/coordinates/sky_coordinate.py:279: in _apply
    self._sky_coord_frame = self_frame._apply(method, *args, **kwargs)
/usr/lib/python3/dist-packages/astropy/coordinates/baseframe.py:1181: in _apply
    value = getattr(self, attr)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <astropy.coordinates.baseframe.TimeFrameAttribute object at 0x7f80365e23c8>
instance = <[ValueError("attribute obstime should be scalar or have shape (2, 1), but is has shape (2,) and could not be broadcast.") raised in repr()] AltAz object at 0x7f8032fb2470>
frame_cls = <class 'astropy.coordinates.builtin_frames.altaz.AltAz'>

    def __get__(self, instance, frame_cls=None):
[...]
                try:
                    if isinstance(out, ShapedLikeNDArray):
                        out = out._apply(np_broadcast_to, shape=instance_shape,
                                         subok=True)
                    else:
                        out = np_broadcast_to(out, instance_shape, subok=True)
                except ValueError:
                    # raise more informative exception.
                    raise ValueError(
                        "attribute {0} should be scalar or have shape {1}, "
                        "but is has shape {2} and could not be broadcast."
>                       .format(self.name, instance_shape, out.shape))
E                   ValueError: attribute obstime should be scalar or have shape (2, 1), but is has shape (2,) and could not be broadcast.

/usr/lib/python3/dist-packages/astropy/coordinates/baseframe.py:235: ValueError

@bsipocz

@bsipocz @bmorris3 Could you estimate how fatal the remaining failures are?
The reason I ask is that in principle, we could upload (and thus ship with Debian Stretch) astroplan with the patches given so far and just mark these three failures as @pytest.mark.xfail(). But this would only make sense if astroplan is useful (with astropy-1.3) in this stage.
What is your opinion about astroplan in Debian Stretch?
My proposed set of patches is here -- it needs confirmation from @ViviCoder however. And, for reference, the Debian related bug is #851437.

It is ok for me if astroplan is mostly usable in spite of the remaining failures.

@wtgee

@wtgee - Yes please open the PR for #282 (comment). I think the more problem are fixed are the better.

Small fixes for astropy 1.3 as discussed in astropy#282

Merge pull request #283 from wtgee/issue-282-fixes

this can be closed now

Navigation Menu

Repository navigation

astroplan not ready for astropy-1.3 yet #282

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

astroplan not ready for astropy-1.3 yet #282

Description

Activity

bsipocz commented on Jan 21, 2017

olebole commented on Jan 23, 2017

bsipocz commented on Jan 23, 2017

olebole commented on Jan 24, 2017

wtgee commented on Jan 24, 2017

olebole commented on Jan 24, 2017

olebole commented on Jan 27, 2017

ViviCoder commented on Jan 29, 2017

bsipocz commented on Jan 31, 2017

bsipocz commented on Oct 4, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions