[AstroPy] problems with astroplan

Tue Nov 8 11:20:24 EST 2016

Hi Steven,

```
# now we try to do all the fancy scheduling
# set our only constraint to be at night
constraint = [AtNightConstraint.twilight_civil(), AirmassConstraint(max=5)]
print(astroplan.is_observable(constraint, kpno, target[:1],
time_range=observable_time_utc))
```

Your target is always up, so the checking you do with kpno.target_is_up()
is not helping much to spot the problem. Setting the airmass constraint to
insanely large (as your target is rather low at the beginning of the night)
returns the True value, but still masks the bug.

The issue is that the argument ``time_range`` only expects to get the two
time limits and it populates the interval with the time step specified in
``time_resolution``. Instead if you already have your time grid, you should
use the argument ``times``:
  astroplan.is_observable(constraint, kpno, target[:1],
times=observable_time_utc))

I'll open a PR/issue to raise an exception for the case when the wrong
parameter is used.

Hope it helps
 Brigitta

On 8 November 2016 at 15:16, Steven Boada <boada at physics.rutgers.edu> wrote:

> List,
>
> Thanks for all the feedback. I'm still struggling to understand what I am
> missing. I get that I am doing *something* wrong with the times, but I feel
> like I have checked and rechecked.
>
> I made a gist of my example, so I don't have to paste the whole thing
> here.
>
> https://gist.github.com/boada/12584fa0b7046aedf27aebb0616892a5
>
> I created some functions to make sure I am converting to/from UTC, and
> labeled all of my variables to help me keep track of everything. I still
> don't understand why the is_observable function returns False.
>
> Plotting the airmass for the same time span
>
> astroplan.plots.plot_airmass(target[:1], kpno, observable_time_utc)
>
> clearly shows the object is rising, and should satisfy my constraints. I'm
> not sure what I am missing.
>
> thanks again
>
> steven
>
> On 11/07/2016 11:05 PM, banyal wrote:
>
> Would be great to have the 'object visibility' in local time.  This issue
> was also flagged  by someone in the discussion group on astroplan*. *I
> hope they  fix it soon.
>
> Regards,
>
> Ravinder
>
> On 2016-11-08 03:09, Matthew Craig wrote:
>
> Hi,
>
> IIRC, astropy times do not support timezones in a very direct way [1].
> Both start_time and end_time from the example will be interpreted as times
> in UTC, and the time arguments to functions in astroplan are in UTC, not
> local time, even if you specify the time zone when you create the Observer
> object. The documentation for target_is_up say that the time is passed
> directly to the astropy Time class which, in the cases in the sample code,
> will assume UTC.
>
> It looks like if you want to get local times you could use the
> astropy_time_to_datetime method of Observer.
>
> I'm using astropy in an undergraduate observing class this semester and
> have been reminding them (repeatedly) that they need to do local to UTC
> conversions themselves and then feed the UTC times into astropy/astroplan.
> That is a little inconvenient, but seemed less error-prone than explaining
> how to use pytz or create a TimezoneInfo object (their python background is
> typically limited).
>
> [1]: http://docs.astropy.org/en/latest/time/index.html#timezones
>
> Matt Craig
>
> schedule:  http://physics.mnstate.edu/craig
> ——
> Professor
> Department of Physics and Astronomy
> Minnesota State University Moorhead
> 1104 7th Ave S, Moorhead MN 56563
>
> office: Hagen 307F
> phone: (218) 477-2439
> fax: (218) 477-2290
>
> On Nov 7, 2016, at 2:57 PM, Eric L. N. Jensen <ejensen1 at swarthmore.edu>
> wrote:
>
> Good catch, Gautham.
>
> And more generally to that point, Steven, I'd suggest getting in the habit
> of *always* specifying the timezone for any times you use in your code
> (e.g. in any call to 'Time'), even if you're using UTC, just to be more
> clear to yourself and to anyone reading your code what timezone you're
> working with.  In the example you gave, when you're specifying the start
> and end times it would still be good to explicitly specify the timezone
> there as well.
>
> Eric
>
>
> On Nov 7, 2016, at 3:53 PM, Gautham Narayan <gnarayan at noao.edu> wrote:
>
>
> Specify the time as well as the date. 2016-11-11 is being parsed at
> 2016-11-11 00:00:00 UTC, at which point it's only 5pm here in AZ, so it's
> not yet civil twilight at Kitt Peak.
>
> print(astroplan.is_observable(constraint, kpno, target[:1],
> times=[Time('2016-11-11 12:15:00')]))
> # prints True
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Best Regards
> Dr Ravinder Banyal
> Indian Institute of Astrophysics
> Koramangala 2nd Block
> Bangalore 560034
> Phone: 08025530672
>
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
> --
>
> Steven Boada
>
> Postdoctoral Researcher
> Rutgers Universityboada at physics.rutgers.edu
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161108/75de4007/attachment.html>