[AstroPy] problems with astroplan
boada at physics.rutgers.edu
Tue Nov 8 10:16:16 EST 2016
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.
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
>> fax: (218) 477-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.
>>>> print(astroplan.is <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
boada at physics.rutgers.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the AstroPy