[AstroPy] problems with astroplan
boada at physics.rutgers.edu
Tue Nov 8 11:25:26 EST 2016
Thanks for the explanation. I actually, just stumbled into what you have
described. The documentation isn't super clear I suppose.
I really appreciate your (and everyone's) help.
On 11/08/2016 11:20 AM, Brigitta Sipocz wrote:
> Hi Steven,
> # now we try to do all the fancy scheduling
> # set our only constraint to be at night
> constraint = [AtNightConstraint.twilight_civil(),
> print(astroplan.is_observable(constraint, kpno, target[:1],
> 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],
> I'll open a PR/issue to raise an exception for the case when the wrong
> parameter is used.
> Hope it helps
> On 8 November 2016 at 15:16, Steven Boada <boada at physics.rutgers.edu
> <mailto:boada at physics.rutgers.edu>> wrote:
> 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.
> 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
> 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. /
>> On 2016-11-08 03:09, Matthew Craig wrote:
>>> IIRC, astropy times do not support timezones in a very direct
>>> way . 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).
>>> : http://docs.astropy.org/en/latest/time/index.html#timezones
>>> Matt Craig
>>> schedule: http://physics.mnstate.edu/craig
>>> Department of Physics and Astronomy
>>> Minnesota State University Moorhead
>>> 1104 7th Ave S, Moorhead MN 56563
>>> office: Hagen 307F
>>> phone: (218) 477-2439 <tel:%28218%29%20477-2439>
>>> fax: (218) 477-2290 <tel:%28218%29%20477-2290>
>>>> On Nov 7, 2016, at 2:57 PM, Eric L. N. Jensen
>>>> <ejensen1 at swarthmore.edu <mailto: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.
>>>>> On Nov 7, 2016, at 3:53 PM, Gautham Narayan <gnarayan at noao.edu
>>>>> <mailto: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.
>>>>> <http://astroplan.is>_observable(constraint, kpno, target[:1],
>>>>> times=[Time('2016-11-11 12:15:00')]))
>>>>> # prints True
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> AstroPy mailing list
>>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> Best Regards
>> Dr Ravinder Banyal
>> Indian Institute of Astrophysics
>> Koramangala 2nd Block
>> Bangalore 560034
>> Phone: 08025530672
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> Steven Boada
> Postdoctoral Researcher
> Rutgers University
> boada at physics.rutgers.edu <mailto:boada at physics.rutgers.edu>
> _______________________________________________ AstroPy mailing
> list AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> AstroPy mailing list
> AstroPy at scipy.org
boada at physics.rutgers.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the AstroPy