From parejkoj at uw.edu  Fri Nov  4 20:04:25 2016
From: parejkoj at uw.edu (John K. Parejko)
Date: Fri, 4 Nov 2016 17:04:25 -0700
Subject: [AstroPy] Hour Angle from location and alt/az
Message-ID: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>

Hello astropythians,

I?m trying to work around a distinct lack of UT1 and LST in some telescope file headers, and was wondering if there?s a straight-forward astropy way to get a source?s Hour Angle from the alt/az, ra/dec, and telescope location. I can build an altaz SkyCoord, but I?m not sure what to do with it from there:

loc = coord.EarthLocation.from_geodetic(long, lat, elevation)
sky = coord.SkyCoord(az, alt, location=loc, frame='altaz', unit='deg?)

I can?t transform this to ICRS:

ipdb> sky.transform_to(coord.ICRS)
*** TypeError: unsupported operand type(s) for -: 'NoneType' and ?float?

and there?s not an ?hour_angle? method that I can see in either of those.

Per the internet[1], one should be able to get HA from alt/az and dec directly (modulo refraction corrections):

HA = asin(- sin(az)*cos(alt) / cos(dec))

I can do that, but I was hoping for a nice and tidy astropy method.

Thanks,
John

1: http://star-www.st-and.ac.uk/~fv/webnotes/chapter7.htm

--
*************************
John Parejko
parejkoj at uw.edu
http://staff.washington.edu/parejkoj/
Department of Physics and Astronomy
University of Washington
Seattle, WA
**************************













From jmwalawender at gmail.com  Sat Nov  5 00:37:46 2016
From: jmwalawender at gmail.com (Josh Walawender)
Date: Fri, 4 Nov 2016 18:37:46 -1000
Subject: [AstroPy] Hour Angle from location and alt/az
In-Reply-To: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
References: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
Message-ID: <E72087E3-F142-4B88-91D5-8CE749AEB3D8@gmail.com>

Hi John,


I solved a similar problem using the RA, DEC, and time from the header (and knowing the telescopes location) then just using the RA-LST method.  Here?s some (pseudo)code which calculates the HA for the mid point of the exposure (adjust as needed for start time if you like):


# Location of the observation
loc = EarthLocation(lat=cfg_loc['latitude?], lon=cfg_loc['longitude?], height=cfg_loc['elevation?])
# Read the start time and exposure time of the image from the header
starttime = Time(time.strptime(header['DATE-OBS?], '%Y-%m-%dT%H:%M:%S'), location=loc)
exptime = TimeDelta(float(header['EXPTIME']), format='sec')
# estimate the exposure mid time
midtime = starttime + exptime/2.0
# determine the sidereal time at the mid point of the exposure
sidereal = midtime.sidereal_time('apparent')
# read the position of the field from the header (assumes J2000)
header_pointing = SkyCoord(ra=float(header['RA'])*u.degree, dec=float(header['DEC'])*u.degree)
## To calculate HA, we need to precess to the current equinox
## otherwise the RA - LST method will be off.
FK5_Jnow = FK5(equinox=midtime)
HA = header_pointing.transform_to(FK5_Jnow).ra.to(u.hourangle) - sidereal

This was good enough for my purposes, but did seem a bit cumbersome.

-Josh




> On Nov 4, 2016, at 2:04 PM, John K. Parejko <parejkoj at uw.edu> wrote:
> 
> Hello astropythians,
> 
> I?m trying to work around a distinct lack of UT1 and LST in some telescope file headers, and was wondering if there?s a straight-forward astropy way to get a source?s Hour Angle from the alt/az, ra/dec, and telescope location. I can build an altaz SkyCoord, but I?m not sure what to do with it from there:
> 
> loc = coord.EarthLocation.from_geodetic(long, lat, elevation)
> sky = coord.SkyCoord(az, alt, location=loc, frame='altaz', unit='deg?)
> 
> I can?t transform this to ICRS:
> 
> ipdb> sky.transform_to(coord.ICRS)
> *** TypeError: unsupported operand type(s) for -: 'NoneType' and ?float?
> 
> and there?s not an ?hour_angle? method that I can see in either of those.
> 
> Per the internet[1], one should be able to get HA from alt/az and dec directly (modulo refraction corrections):
> 
> HA = asin(- sin(az)*cos(alt) / cos(dec))
> 
> I can do that, but I was hoping for a nice and tidy astropy method.
> 
> Thanks,
> John
> 
> 1: http://star-www.st-and.ac.uk/~fv/webnotes/chapter7.htm
> 
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20161104/8c19257a/attachment.html>

From thomas.robitaille at gmail.com  Sat Nov  5 05:16:44 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sat, 5 Nov 2016 09:16:44 +0000
Subject: [AstroPy] Hour Angle from location and alt/az
In-Reply-To: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
References: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
Message-ID: <CAGMHX_04YZHEk+AYVXf2ajh+yqMf=swqGOABanD_XwkfZ2D67g@mail.gmail.com>

Hi John,

It seems like this is something you may be able to do with astroplan:

http://astroplan.readthedocs.io/en/latest/api/astroplan.Observer.html?highlight=hour%20angle#astroplan.Observer.target_hour_angle

(this is the Astropy affiliated package for observation planning)

Cheers,
Tom


On 5 November 2016 at 00:04, John K. Parejko <parejkoj at uw.edu> wrote:
> Hello astropythians,
>
> I?m trying to work around a distinct lack of UT1 and LST in some telescope file headers, and was wondering if there?s a straight-forward astropy way to get a source?s Hour Angle from the alt/az, ra/dec, and telescope location. I can build an altaz SkyCoord, but I?m not sure what to do with it from there:
>
> loc = coord.EarthLocation.from_geodetic(long, lat, elevation)
> sky = coord.SkyCoord(az, alt, location=loc, frame='altaz', unit='deg?)
>
> I can?t transform this to ICRS:
>
> ipdb> sky.transform_to(coord.ICRS)
> *** TypeError: unsupported operand type(s) for -: 'NoneType' and ?float?
>
> and there?s not an ?hour_angle? method that I can see in either of those.
>
> Per the internet[1], one should be able to get HA from alt/az and dec directly (modulo refraction corrections):
>
> HA = asin(- sin(az)*cos(alt) / cos(dec))
>
> I can do that, but I was hoping for a nice and tidy astropy method.
>
> Thanks,
> John
>
> 1: http://star-www.st-and.ac.uk/~fv/webnotes/chapter7.htm
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From tim.jenness at gmail.com  Sat Nov  5 16:40:58 2016
From: tim.jenness at gmail.com (Tim Jenness)
Date: Sat, 5 Nov 2016 13:40:58 -0700
Subject: [AstroPy] Hour Angle from location and alt/az
In-Reply-To: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
References: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
Message-ID: <CA+G92RdDENySSqsE3gaKsMDPrZdkpz7BsXSEiGc0q-AK9yiPBQ@mail.gmail.com>

PAL (also palpy and SLALIB) has
https://github.com/Starlink/pal/blob/master/palDh2e.c but that routine
hasn't made it to SOFA/ERFA. I'm surprised astropy.coords does not support
azel to hadec.

-- 
Tim Jenness

On Fri, Nov 4, 2016 at 5:04 PM, John K. Parejko <parejkoj at uw.edu> wrote:

> Hello astropythians,
>
> I?m trying to work around a distinct lack of UT1 and LST in some telescope
> file headers, and was wondering if there?s a straight-forward astropy way
> to get a source?s Hour Angle from the alt/az, ra/dec, and telescope
> location. I can build an altaz SkyCoord, but I?m not sure what to do with
> it from there:
>
> loc = coord.EarthLocation.from_geodetic(long, lat, elevation)
> sky = coord.SkyCoord(az, alt, location=loc, frame='altaz', unit='deg?)
>
> I can?t transform this to ICRS:
>
> ipdb> sky.transform_to(coord.ICRS)
> *** TypeError: unsupported operand type(s) for -: 'NoneType' and ?float?
>
> and there?s not an ?hour_angle? method that I can see in either of those.
>
> Per the internet[1], one should be able to get HA from alt/az and dec
> directly (modulo refraction corrections):
>
> HA = asin(- sin(az)*cos(alt) / cos(dec))
>
> I can do that, but I was hoping for a nice and tidy astropy method.
>
> Thanks,
> John
>
> 1: http://star-www.st-and.ac.uk/~fv/webnotes/chapter7.htm
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20161105/79aeaa0d/attachment.html>

From p.schellart at princeton.edu  Mon Nov  7 07:23:07 2016
From: p.schellart at princeton.edu (Pim Schellart)
Date: Mon, 7 Nov 2016 12:23:07 +0000
Subject: [AstroPy] Hour Angle from location and alt/az
In-Reply-To: <CA+G92RdDENySSqsE3gaKsMDPrZdkpz7BsXSEiGc0q-AK9yiPBQ@mail.gmail.com>
References: <9733D0DA-57FC-4FC3-9711-5AEFE7A13A4C@uw.edu>
 <CA+G92RdDENySSqsE3gaKsMDPrZdkpz7BsXSEiGc0q-AK9yiPBQ@mail.gmail.com>
Message-ID: <112A9CB1-921C-4009-85BD-7C0F6604D8B1@princeton.edu>

Also see https://github.com/pschella/tmf. I?m not completely surprised, as this conversion is tricky ;)
> On 5 Nov 2016, at 21:40, Tim Jenness <tim.jenness at gmail.com> wrote:
> 
> PAL (also palpy and SLALIB) has https://github.com/Starlink/pal/blob/master/palDh2e.c but that routine hasn't made it to SOFA/ERFA. I'm surprised astropy.coords does not support azel to hadec.
> 
> -- 
> Tim Jenness
> 
> On Fri, Nov 4, 2016 at 5:04 PM, John K. Parejko <parejkoj at uw.edu> wrote:
> Hello astropythians,
> 
> I?m trying to work around a distinct lack of UT1 and LST in some telescope file headers, and was wondering if there?s a straight-forward astropy way to get a source?s Hour Angle from the alt/az, ra/dec, and telescope location. I can build an altaz SkyCoord, but I?m not sure what to do with it from there:
> 
> loc = coord.EarthLocation.from_geodetic(long, lat, elevation)
> sky = coord.SkyCoord(az, alt, location=loc, frame='altaz', unit='deg?)
> 
> I can?t transform this to ICRS:
> 
> ipdb> sky.transform_to(coord.ICRS)
> *** TypeError: unsupported operand type(s) for -: 'NoneType' and ?float?
> 
> and there?s not an ?hour_angle? method that I can see in either of those.
> 
> Per the internet[1], one should be able to get HA from alt/az and dec directly (modulo refraction corrections):
> 
> HA = asin(- sin(az)*cos(alt) / cos(dec))
> 
> I can do that, but I was hoping for a nice and tidy astropy method.
> 
> Thanks,
> John
> 
> 1: http://star-www.st-and.ac.uk/~fv/webnotes/chapter7.htm
> 
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From boada at physics.rutgers.edu  Mon Nov  7 14:22:56 2016
From: boada at physics.rutgers.edu (Steven Boada)
Date: Mon, 7 Nov 2016 14:22:56 -0500
Subject: [AstroPy] problems with astroplan
Message-ID: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>

Hi list,

I'm headed to KPNO and I'm trying out astroplan for the first time. But 
I'm getting some confusing output. Here's an example.

from astroplan import Observer, FixedTarget
from astropy.coordinates import SkyCoord

# make telescope location
kpno = Observer.at_site('KPNO')

# make target coordinates
coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')

# make all the targets
target = [FixedTarget(name='test', coord=coords)]

# make the observing time
start_time = Time('2016-11-11 01:54:00')
end_time = Time('2016-11-11 12:30:00')
time_delta = end_time - start_time
observable_time = start_time + time_delta * np.linspace(0,1,75)

print(kpno.target_is_up(start_time, target))
# should print True

# 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, targets[:1], 
times=Time('2016-11-11')))
# should print false.


Looking up the airmass etc. on the web, the target is certainly visible 
from KPNO. I'm obviously missing something, but I can't seem to figure 
out what it is.

Thanks for your help.


steven


-- 

Steven Boada

Postdoctoral Researcher
Rutgers University
boada at physics.rutgers.edu



From ejensen1 at swarthmore.edu  Mon Nov  7 14:36:50 2016
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Mon, 7 Nov 2016 14:36:50 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
Message-ID: <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>

Hi Steven,

Since you don?t specify a timezone on your start_time variable, I?m guessing that it is probably being interpreted as UTC, in which case your specified target isn?t up at KPNO.  

You don?t show an import statement that would define your call to ?Time? so I?m not 100% sure what routine it is and how it?s interpreting the specified time, but being sure about timezones is where I?d start troubleshooting this. 

Eric


> On Nov 7, 2016, at 2:22 PM, Steven Boada <boada at physics.rutgers.edu> wrote:
> 
> Hi list,
> 
> I'm headed to KPNO and I'm trying out astroplan for the first time. But I'm getting some confusing output. Here's an example.
> 
> from astroplan import Observer, FixedTarget
> from astropy.coordinates import SkyCoord
> 
> # make telescope location
> kpno = Observer.at_site('KPNO')
> 
> # make target coordinates
> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
> 
> # make all the targets
> target = [FixedTarget(name='test', coord=coords)]
> 
> # make the observing time
> start_time = Time('2016-11-11 01:54:00')
> end_time = Time('2016-11-11 12:30:00')
> time_delta = end_time - start_time
> observable_time = start_time + time_delta * np.linspace(0,1,75)
> 
> print(kpno.target_is_up(start_time, target))
> # should print True
> 
> # 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, targets[:1], times=Time('2016-11-11')))
> # should print false.
> 
> 
> Looking up the airmass etc. on the web, the target is certainly visible from KPNO. I'm obviously missing something, but I can't seem to figure out what it is.
> 
> Thanks for your help.
> 
> 
> steven
> 
> 
> -- 
> 
> Steven Boada
> 
> Postdoctoral Researcher
> Rutgers University
> boada at physics.rutgers.edu
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From boada at physics.rutgers.edu  Mon Nov  7 14:43:45 2016
From: boada at physics.rutgers.edu (Steven Boada)
Date: Mon, 7 Nov 2016 14:43:45 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
Message-ID: <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>

Hi Eric,

I apologize for my example not working. That is what I get for typing it 
out in the same console I had been testing things in. Here is a much 
more complete example.

I've specified the timezone, but it still prints True and then False.

import astroplan
from astroplan import Observer, FixedTarget
from astroplan.constraints import AtNightConstraint
from astropy.coordinates import SkyCoord
from astropy.time import Time

# make telescope location
kpno = Observer.at_site('KPNO', timezone='MST')

# make target coordinates
coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')

# make all the targets
target = [FixedTarget(name='test', coord=coords)]

# make the observing time
start_time = Time('2016-11-10 18:54:00')
end_time = Time('2016-11-11 5:27:00')
time_delta = end_time - start_time
observable_time = start_time + time_delta * np.linspace(0,1,75)

print(kpno.target_is_up(start_time, target))
# should print True

# 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], 
times=Time('2016-11-11')))
# should print false.

Thanks again.

On 11/07/2016 02:36 PM, Eric L. N. Jensen wrote:
> Hi Steven,
>
> Since you don?t specify a timezone on your start_time variable, I?m guessing that it is probably being interpreted as UTC, in which case your specified target isn?t up at KPNO.
>
> You don?t show an import statement that would define your call to ?Time? so I?m not 100% sure what routine it is and how it?s interpreting the specified time, but being sure about timezones is where I?d start troubleshooting this.
>
> Eric
>
>
>> On Nov 7, 2016, at 2:22 PM, Steven Boada <boada at physics.rutgers.edu> wrote:
>>
>> Hi list,
>>
>> I'm headed to KPNO and I'm trying out astroplan for the first time. But I'm getting some confusing output. Here's an example.
>>
>> from astroplan import Observer, FixedTarget
>> from astropy.coordinates import SkyCoord
>>
>> # make telescope location
>> kpno = Observer.at_site('KPNO')
>>
>> # make target coordinates
>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>
>> # make all the targets
>> target = [FixedTarget(name='test', coord=coords)]
>>
>> # make the observing time
>> start_time = Time('2016-11-11 01:54:00')
>> end_time = Time('2016-11-11 12:30:00')
>> time_delta = end_time - start_time
>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>
>> print(kpno.target_is_up(start_time, target))
>> # should print True
>>
>> # 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, targets[:1], times=Time('2016-11-11')))
>> # should print false.
>>
>>
>> Looking up the airmass etc. on the web, the target is certainly visible from KPNO. I'm obviously missing something, but I can't seem to figure out what it is.
>>
>> Thanks for your help.
>>
>>
>> steven
>>
>>
>> -- 
>>
>> Steven Boada
>>
>> Postdoctoral Researcher
>> Rutgers University
>> boada at physics.rutgers.edu
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

-- 

Steven Boada

Postdoctoral Researcher
Rutgers University
boada at physics.rutgers.edu



From gnarayan at noao.edu  Mon Nov  7 15:43:13 2016
From: gnarayan at noao.edu (Gautham Narayan)
Date: Mon, 7 Nov 2016 13:43:13 -0700
Subject: [AstroPy] problems with astroplan
In-Reply-To: <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
Message-ID: <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>

Hi Steven,

Maybe I'm missing something but you're example is supposed to print True 
and then False. That's what is in the comments even.


print(kpno.target_is_up(start_time, target))
# should print True

print(astroplan.is_observable(constraint, kpno, target[:1], 
times=Time('2016-11-11')))
# should print false.

Cheers,
-Gautham




On 11/07/2016 12:43 PM, Steven Boada wrote:
> Hi Eric,
>
> I apologize for my example not working. That is what I get for typing 
> it out in the same console I had been testing things in. Here is a 
> much more complete example.
>
> I've specified the timezone, but it still prints True and then False.
>
> import astroplan
> from astroplan import Observer, FixedTarget
> from astroplan.constraints import AtNightConstraint
> from astropy.coordinates import SkyCoord
> from astropy.time import Time
>
> # make telescope location
> kpno = Observer.at_site('KPNO', timezone='MST')
>
> # make target coordinates
> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>
> # make all the targets
> target = [FixedTarget(name='test', coord=coords)]
>
> # make the observing time
> start_time = Time('2016-11-10 18:54:00')
> end_time = Time('2016-11-11 5:27:00')
> time_delta = end_time - start_time
> observable_time = start_time + time_delta * np.linspace(0,1,75)
>
> print(kpno.target_is_up(start_time, target))
> # should print True
>
> # 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], 
> times=Time('2016-11-11')))
> # should print false.
>
> Thanks again.
>
> On 11/07/2016 02:36 PM, Eric L. N. Jensen wrote:
>> Hi Steven,
>>
>> Since you don?t specify a timezone on your start_time variable, I?m 
>> guessing that it is probably being interpreted as UTC, in which case 
>> your specified target isn?t up at KPNO.
>>
>> You don?t show an import statement that would define your call to 
>> ?Time? so I?m not 100% sure what routine it is and how it?s 
>> interpreting the specified time, but being sure about timezones is 
>> where I?d start troubleshooting this.
>>
>> Eric
>>
>>
>>> On Nov 7, 2016, at 2:22 PM, Steven Boada <boada at physics.rutgers.edu> 
>>> wrote:
>>>
>>> Hi list,
>>>
>>> I'm headed to KPNO and I'm trying out astroplan for the first time. 
>>> But I'm getting some confusing output. Here's an example.
>>>
>>> from astroplan import Observer, FixedTarget
>>> from astropy.coordinates import SkyCoord
>>>
>>> # make telescope location
>>> kpno = Observer.at_site('KPNO')
>>>
>>> # make target coordinates
>>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>>
>>> # make all the targets
>>> target = [FixedTarget(name='test', coord=coords)]
>>>
>>> # make the observing time
>>> start_time = Time('2016-11-11 01:54:00')
>>> end_time = Time('2016-11-11 12:30:00')
>>> time_delta = end_time - start_time
>>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>>
>>> print(kpno.target_is_up(start_time, target))
>>> # should print True
>>>
>>> # 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, targets[:1], 
>>> times=Time('2016-11-11')))
>>> # should print false.
>>>
>>>
>>> Looking up the airmass etc. on the web, the target is certainly 
>>> visible from KPNO. I'm obviously missing something, but I can't seem 
>>> to figure out what it is.
>>>
>>> Thanks for your help.
>>>
>>>
>>> steven
>>>
>>>
>>> -- 
>>>
>>> Steven Boada
>>>
>>> Postdoctoral Researcher
>>> Rutgers University
>>> boada at physics.rutgers.edu
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>


-- 
Dr. Gautham Narayan
NOAO/UA
950 N. Cherry Ave., Rm. 118
Tucson, AZ 85719
(309) 531-1810



From boada at physics.rutgers.edu  Mon Nov  7 15:48:18 2016
From: boada at physics.rutgers.edu (Steven Boada)
Date: Mon, 7 Nov 2016 15:48:18 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
Message-ID: <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>

I Gautham,

OK, maybe my example was a little misleading. I mentioned what the 
example should do, but it isn't what I expect it to do.

Basically, I am trying to figure out if my object is observable from 
KPNO, and then I am going to use all the fancy scheduling stuff in 
astroplan to figure out which objects I want to observe when. The 
problem is that the line that prints false is checking whether or not my 
object is observable. I know it *is* observable, so I don't understand 
why it is printing false instead of true.

As Eric mentioned, it is probably something to do with the observation 
times, but I can't seem to find what I am missing. I want the example to 
print True True instead of True False.

Thanks for your help.

steven

On 11/07/2016 03:43 PM, Gautham Narayan wrote:
> Hi Steven,
>
> Maybe I'm missing something but you're example is supposed to print 
> True and then False. That's what is in the comments even.
>
>
> print(kpno.target_is_up(start_time, target))
> # should print True
>
> print(astroplan.is_observable(constraint, kpno, target[:1], 
> times=Time('2016-11-11')))
> # should print false.
>
> Cheers,
> -Gautham
>
>
>
>
> On 11/07/2016 12:43 PM, Steven Boada wrote:
>> Hi Eric,
>>
>> I apologize for my example not working. That is what I get for typing 
>> it out in the same console I had been testing things in. Here is a 
>> much more complete example.
>>
>> I've specified the timezone, but it still prints True and then False.
>>
>> import astroplan
>> from astroplan import Observer, FixedTarget
>> from astroplan.constraints import AtNightConstraint
>> from astropy.coordinates import SkyCoord
>> from astropy.time import Time
>>
>> # make telescope location
>> kpno = Observer.at_site('KPNO', timezone='MST')
>>
>> # make target coordinates
>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>
>> # make all the targets
>> target = [FixedTarget(name='test', coord=coords)]
>>
>> # make the observing time
>> start_time = Time('2016-11-10 18:54:00')
>> end_time = Time('2016-11-11 5:27:00')
>> time_delta = end_time - start_time
>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>
>> print(kpno.target_is_up(start_time, target))
>> # should print True
>>
>> # 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], 
>> times=Time('2016-11-11')))
>> # should print false.
>>
>> Thanks again.
>>
>> On 11/07/2016 02:36 PM, Eric L. N. Jensen wrote:
>>> Hi Steven,
>>>
>>> Since you don?t specify a timezone on your start_time variable, I?m 
>>> guessing that it is probably being interpreted as UTC, in which case 
>>> your specified target isn?t up at KPNO.
>>>
>>> You don?t show an import statement that would define your call to 
>>> ?Time? so I?m not 100% sure what routine it is and how it?s 
>>> interpreting the specified time, but being sure about timezones is 
>>> where I?d start troubleshooting this.
>>>
>>> Eric
>>>
>>>
>>>> On Nov 7, 2016, at 2:22 PM, Steven Boada 
>>>> <boada at physics.rutgers.edu> wrote:
>>>>
>>>> Hi list,
>>>>
>>>> I'm headed to KPNO and I'm trying out astroplan for the first time. 
>>>> But I'm getting some confusing output. Here's an example.
>>>>
>>>> from astroplan import Observer, FixedTarget
>>>> from astropy.coordinates import SkyCoord
>>>>
>>>> # make telescope location
>>>> kpno = Observer.at_site('KPNO')
>>>>
>>>> # make target coordinates
>>>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>>>
>>>> # make all the targets
>>>> target = [FixedTarget(name='test', coord=coords)]
>>>>
>>>> # make the observing time
>>>> start_time = Time('2016-11-11 01:54:00')
>>>> end_time = Time('2016-11-11 12:30:00')
>>>> time_delta = end_time - start_time
>>>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>>>
>>>> print(kpno.target_is_up(start_time, target))
>>>> # should print True
>>>>
>>>> # 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, targets[:1], 
>>>> times=Time('2016-11-11')))
>>>> # should print false.
>>>>
>>>>
>>>> Looking up the airmass etc. on the web, the target is certainly 
>>>> visible from KPNO. I'm obviously missing something, but I can't 
>>>> seem to figure out what it is.
>>>>
>>>> Thanks for your help.
>>>>
>>>>
>>>> steven
>>>>
>>>>
>>>> -- 
>>>>
>>>> Steven Boada
>>>>
>>>> Postdoctoral Researcher
>>>> Rutgers University
>>>> boada at physics.rutgers.edu
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>

-- 

Steven Boada

Postdoctoral Researcher
Rutgers University
boada at physics.rutgers.edu



From gnarayan at noao.edu  Mon Nov  7 15:53:00 2016
From: gnarayan at noao.edu (Gautham Narayan)
Date: Mon, 7 Nov 2016 13:53:00 -0700
Subject: [AstroPy] problems with astroplan
In-Reply-To: <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
Message-ID: <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>

Hi Steven,

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

Cheers,
-Gautham




On 11/07/2016 01:48 PM, Steven Boada wrote:
> I Gautham,
>
> OK, maybe my example was a little misleading. I mentioned what the 
> example should do, but it isn't what I expect it to do.
>
> Basically, I am trying to figure out if my object is observable from 
> KPNO, and then I am going to use all the fancy scheduling stuff in 
> astroplan to figure out which objects I want to observe when. The 
> problem is that the line that prints false is checking whether or not 
> my object is observable. I know it *is* observable, so I don't 
> understand why it is printing false instead of true.
>
> As Eric mentioned, it is probably something to do with the observation 
> times, but I can't seem to find what I am missing. I want the example 
> to print True True instead of True False.
>
> Thanks for your help.
>
> steven
>
> On 11/07/2016 03:43 PM, Gautham Narayan wrote:
>> Hi Steven,
>>
>> Maybe I'm missing something but you're example is supposed to print 
>> True and then False. That's what is in the comments even.
>>
>>
>> print(kpno.target_is_up(start_time, target))
>> # should print True
>>
>> print(astroplan.is_observable(constraint, kpno, target[:1], 
>> times=Time('2016-11-11')))
>> # should print false.
>>
>> Cheers,
>> -Gautham
>>
>>
>>
>>
>> On 11/07/2016 12:43 PM, Steven Boada wrote:
>>> Hi Eric,
>>>
>>> I apologize for my example not working. That is what I get for 
>>> typing it out in the same console I had been testing things in. Here 
>>> is a much more complete example.
>>>
>>> I've specified the timezone, but it still prints True and then False.
>>>
>>> import astroplan
>>> from astroplan import Observer, FixedTarget
>>> from astroplan.constraints import AtNightConstraint
>>> from astropy.coordinates import SkyCoord
>>> from astropy.time import Time
>>>
>>> # make telescope location
>>> kpno = Observer.at_site('KPNO', timezone='MST')
>>>
>>> # make target coordinates
>>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>>
>>> # make all the targets
>>> target = [FixedTarget(name='test', coord=coords)]
>>>
>>> # make the observing time
>>> start_time = Time('2016-11-10 18:54:00')
>>> end_time = Time('2016-11-11 5:27:00')
>>> time_delta = end_time - start_time
>>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>>
>>> print(kpno.target_is_up(start_time, target))
>>> # should print True
>>>
>>> # 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], 
>>> times=Time('2016-11-11')))
>>> # should print false.
>>>
>>> Thanks again.
>>>
>>> On 11/07/2016 02:36 PM, Eric L. N. Jensen wrote:
>>>> Hi Steven,
>>>>
>>>> Since you don?t specify a timezone on your start_time variable, I?m 
>>>> guessing that it is probably being interpreted as UTC, in which 
>>>> case your specified target isn?t up at KPNO.
>>>>
>>>> You don?t show an import statement that would define your call to 
>>>> ?Time? so I?m not 100% sure what routine it is and how it?s 
>>>> interpreting the specified time, but being sure about timezones is 
>>>> where I?d start troubleshooting this.
>>>>
>>>> Eric
>>>>
>>>>
>>>>> On Nov 7, 2016, at 2:22 PM, Steven Boada 
>>>>> <boada at physics.rutgers.edu> wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>> I'm headed to KPNO and I'm trying out astroplan for the first 
>>>>> time. But I'm getting some confusing output. Here's an example.
>>>>>
>>>>> from astroplan import Observer, FixedTarget
>>>>> from astropy.coordinates import SkyCoord
>>>>>
>>>>> # make telescope location
>>>>> kpno = Observer.at_site('KPNO')
>>>>>
>>>>> # make target coordinates
>>>>> coords = SkyCoord(131.1331774, 62.41165761, unit='deg', frame='icrs')
>>>>>
>>>>> # make all the targets
>>>>> target = [FixedTarget(name='test', coord=coords)]
>>>>>
>>>>> # make the observing time
>>>>> start_time = Time('2016-11-11 01:54:00')
>>>>> end_time = Time('2016-11-11 12:30:00')
>>>>> time_delta = end_time - start_time
>>>>> observable_time = start_time + time_delta * np.linspace(0,1,75)
>>>>>
>>>>> print(kpno.target_is_up(start_time, target))
>>>>> # should print True
>>>>>
>>>>> # 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, targets[:1], 
>>>>> times=Time('2016-11-11')))
>>>>> # should print false.
>>>>>
>>>>>
>>>>> Looking up the airmass etc. on the web, the target is certainly 
>>>>> visible from KPNO. I'm obviously missing something, but I can't 
>>>>> seem to figure out what it is.
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>>
>>>>> steven
>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> Steven Boada
>>>>>
>>>>> Postdoctoral Researcher
>>>>> Rutgers University
>>>>> boada at physics.rutgers.edu
>>>>>
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at scipy.org
>>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>


-- 
Dr. Gautham Narayan
NOAO/UA
950 N. Cherry Ave., Rm. 118
Tucson, AZ 85719
(309) 531-1810



From ejensen1 at swarthmore.edu  Mon Nov  7 15:57:39 2016
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Mon, 7 Nov 2016 15:57:39 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
Message-ID: <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>

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
> 



From mcraig at mnstate.edu  Mon Nov  7 16:39:25 2016
From: mcraig at mnstate.edu (Matthew Craig)
Date: Mon, 7 Nov 2016 21:39:25 +0000
Subject: [AstroPy] problems with astroplan
In-Reply-To: <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
 <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
Message-ID: <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>

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

Eric


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>
https://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161107/82f14ec2/attachment.html>

From teuben at astro.umd.edu  Mon Nov  7 17:21:23 2016
From: teuben at astro.umd.edu (Peter Teuben)
Date: Mon, 7 Nov 2016 17:21:23 -0500
Subject: [AstroPy] astropy vs. casa coordinate transformations?
Message-ID: <9643d83f-4bcf-dd1e-553e-47914593c427@astro.umd.edu>


The astropy coordinate transformations look very nice, but CASA also has a very impressive collection of these. Has anybody done a detailed comparison on how well they compare, as I was about to embark on a spot check.


- peter



From banyal at iiap.res.in  Mon Nov  7 23:05:37 2016
From: banyal at iiap.res.in (banyal)
Date: Tue, 08 Nov 2016 09:35:37 +0530
Subject: [AstroPy] problems with astroplan
In-Reply-To: <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
 <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
 <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>
Message-ID: <7d90f568589a2838afed82ca4fbb55a6@iiap.res.in>

 

 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 [1] 
> 
> Matt Craig 
> 
> schedule: http://physics.mnstate.edu/craig [2]
> ---- 
> 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 [3]_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 list
AstroPy at scipy.org
https://mail.scipy.org/mailman/listinfo/astropy [4]

-- 
Best Regards
Dr Ravinder Banyal
Indian Institute of Astrophysics
Koramangala 2nd Block
Bangalore 560034
Phone: 08025530672
 

Links:
------
[1] http://docs.astropy.org/en/latest/time/index.html#timezones
[2] http://physics.mnstate.edu/craig
[3] http://astroplan.is
[4] https://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161108/d4be6248/attachment.html>

From minzastro at gmail.com  Tue Nov  8 08:49:32 2016
From: minzastro at gmail.com (Alexey Mints)
Date: Tue, 8 Nov 2016 14:49:32 +0100
Subject: [AstroPy] Writing metadata to votable
Message-ID: <d0e5f9ad-f31a-7f65-b761-05789ba5e928@gmail.com>

Hi
Is there a consistent way to write metadata (or params) into VO table 
using astropy.table.Table? meta works fine for fits, but not for votable.
I want to have a single entity (table) so that for writing i have only 
to provide a format, so falling back to astropy.io.votable is not an option.
Cheers,
Alexey


From boada at physics.rutgers.edu  Tue Nov  8 10:16:16 2016
From: boada at physics.rutgers.edu (Steven Boada)
Date: Tue, 8 Nov 2016 10:16:16 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <7d90f568589a2838afed82ca4fbb55a6@iiap.res.in>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
 <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
 <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>
 <7d90f568589a2838afed82ca4fbb55a6@iiap.res.in>
Message-ID: <0700a67b-83b0-6a39-cb6d-415a640e4e5c@physics.rutgers.edu>

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 <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.
>>>
>>> Eric
>>>
>>>
>>>> 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>
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> https://mail.scipy.org/mailman/listinfo/astropy
>
> -- 
> Best Regards
> Dr Ravinder Banyal
> Indian Institute of Astrophysics
> Koramangala 2nd Block
> Bangalore 560034
> Phone: 08025530672
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

-- 

Steven Boada

Postdoctoral Researcher
Rutgers University
boada at physics.rutgers.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161108/9df472e6/attachment.html>

From sic at elte.hu  Tue Nov  8 11:20:24 2016
From: sic at elte.hu (Brigitta Sipocz)
Date: Tue, 8 Nov 2016 16:20:24 +0000
Subject: [AstroPy] problems with astroplan
In-Reply-To: <0700a67b-83b0-6a39-cb6d-415a640e4e5c@physics.rutgers.edu>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
 <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
 <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>
 <7d90f568589a2838afed82ca4fbb55a6@iiap.res.in>
 <0700a67b-83b0-6a39-cb6d-415a640e4e5c@physics.rutgers.edu>
Message-ID: <CAEjJ3fhW6i9PBAYJ8Y_KSJUuu25Xtb868PFQ5OCUvBb8OSU_xg@mail.gmail.com>

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>

From boada at physics.rutgers.edu  Tue Nov  8 11:25:26 2016
From: boada at physics.rutgers.edu (Steven Boada)
Date: Tue, 8 Nov 2016 11:25:26 -0500
Subject: [AstroPy] problems with astroplan
In-Reply-To: <CAEjJ3fhW6i9PBAYJ8Y_KSJUuu25Xtb868PFQ5OCUvBb8OSU_xg@mail.gmail.com>
References: <6b47265e-6750-b681-2cc6-134e86529bea@physics.rutgers.edu>
 <46E9F0D5-9E75-49F4-8181-95AC5AF778B6@swarthmore.edu>
 <f923320c-f106-ef14-3021-8f1e930d34dc@physics.rutgers.edu>
 <fc52c0ef-1526-f173-2970-713c61a2aff0@noao.edu>
 <9226fafb-7446-1579-b348-4faebea8d94c@physics.rutgers.edu>
 <ccbe662a-1f4c-409a-59c5-105d8af7e07b@noao.edu>
 <1CE616C6-E194-48A4-9A69-63F5ADB7677C@swarthmore.edu>
 <29122301-901E-45A8-8EA5-01C7BE6E6139@mnstate.edu>
 <7d90f568589a2838afed82ca4fbb55a6@iiap.res.in>
 <0700a67b-83b0-6a39-cb6d-415a640e4e5c@physics.rutgers.edu>
 <CAEjJ3fhW6i9PBAYJ8Y_KSJUuu25Xtb868PFQ5OCUvBb8OSU_xg@mail.gmail.com>
Message-ID: <0809352d-6037-fddd-ce5a-b1d45d6c28f0@physics.rutgers.edu>

Brigitta,

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.

steven

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(), 
> 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 
> <mailto: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
>     <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
>>>     <http://docs.astropy.org/en/latest/time/index.html#timezones>
>>>
>>>     Matt Craig
>>>
>>>     schedule: http://physics.mnstate.edu/craig
>>>     <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 <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.
>>>>
>>>>     Eric
>>>>
>>>>
>>>>>     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>
>>>>     https://mail.scipy.org/mailman/listinfo/astropy
>>>>     <https://mail.scipy.org/mailman/listinfo/astropy>
>>>
>>>     _______________________________________________
>>>     AstroPy mailing list
>>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>     https://mail.scipy.org/mailman/listinfo/astropy
>>>     <https://mail.scipy.org/mailman/listinfo/astropy>
>>
>>     -- 
>>     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>
>>     https://mail.scipy.org/mailman/listinfo/astropy
>>     <https://mail.scipy.org/mailman/listinfo/astropy>
>
>     -- 
>
>     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>
>     https://mail.scipy.org/mailman/listinfo/astropy
>     <https://mail.scipy.org/mailman/listinfo/astropy> 
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
-- 

Steven Boada

Postdoctoral Researcher
Rutgers University
boada at physics.rutgers.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161108/cf9d79fc/attachment.html>

From baweaver at lbl.gov  Thu Nov 10 12:59:31 2016
From: baweaver at lbl.gov (Benjamin Alan Weaver)
Date: Thu, 10 Nov 2016 10:59:31 -0700
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <CAMCHcTrhC6_AdTtpZay5F4jg68QUbzn5mc3+wxvXX835SG0sHQ@mail.gmail.com>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
 <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
 <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>
 <CAMCHcTrhC6_AdTtpZay5F4jg68QUbzn5mc3+wxvXX835SG0sHQ@mail.gmail.com>
Message-ID: <0085d583-3462-4d45-d7aa-a199b7de8fd8@lbl.gov>

Hello y'all,

I just wanted to follow up on this.  Did the problem that Stephen
reported with Python 3 get added to any existing bug reports, or a new
bug report?

Kia ora koutou,
Benjamin Alan Weaver

On 10/24/2016 09:38 PM, Stephen Bailey wrote:
> Thanks for the suggestions.  The original problem also applies to python
> 3.5 though ? this isn't just a python 2.7 thing.  If LANG isn't set, the
> ascii table readers can break even with python 3.5 and even if the
> non-ascii character is in a comment field.  e.g. the following table
> can't be read with format='ascii.basic' unless $LANG is set or one of
> locale tricks from Thomas or Derek is used:
> 
> # Some comment
> # ? or not?
> # Another comment
> x y
> 1 2
> 3 4
> 5 6
> 
> Also, for the record: apparently Mac OSX needs 'en_US.UTF-8' and not
> 'en_US.utf8'; flavors of Linux will accept either.
> 
> Stephen
> 
> In [*9*]: !cat blat.csv
> 
> # Some comment
> 
> # ? or not?
> 
> # Another comment
> 
> x y
> 
> 1 2
> 
> 3 4
> 
> 5 6
> 
> 
> In [*10*]: sys.version
> 
> Out[*10*]: '3.5.2 |Continuum Analytics, Inc.| (default, Jul  2 2016,
> 17:52:12) \n[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)]'
> 
> 
> In [*11*]: print(os.getenv('LANG'))
> 
> None
> 
> 
> In [*12*]: t = Table.read('blat.csv', format='ascii.basic')
> 
> ---------------------------------------------------------------------------
> 
> UnicodeDecodeError                        Traceback (most recent call last)
> 
> <ipython-input-12-4c7389d51f8f>in <module>()
> 
> ----> 1t =Table.read('blat.csv',format='ascii.basic')
> 
> 
> /Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/table/table.pyin
> read(cls, *args, **kwargs)
> 
> *   2330*        passed through to the underlying data reader
> (e.g.`~astropy.io.ascii.read`).
> 
> *   2331*        """
> 
> -> 2332        returnio_registry.read(cls,*args,**kwargs)
> 
> *   2333* 
> 
> *   2334*    defwrite(self,*args,**kwargs):
> 
> 
> /Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/registry.pyin
> read(cls, *args, **kwargs)
> 
> *    349* 
> 
> *    350*        reader =get_reader(format,cls)
> 
> --> 351        data =reader(*args,**kwargs)
> 
> *    352* 
> 
> *    353*        ifnotisinstance(data,cls):
> 
> 
> /Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/ascii/connect.pyin
> io_read(format, filename, **kwargs)
> 
> *     35*    from.ui importread
> 
> *     36*    format =re.sub(r'^ascii\.','',format)
> 
> ---> 37    returnread(filename,format=format,**kwargs)
> 
> *     38* 
> 
> *     39* 
> 
> 
> /Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/ascii/ui.pyin
> read(table, guess, **kwargs)
> 
> *    287*            try:
> 
> *    288*                withget_readable_fileobj(table)asfileobj:
> 
> --> 289                    table =fileobj.read()
> 
> *    290*            exceptValueError:  # unreadable or invalid binary file
> 
> *    291*                raise
> 
> 
> /Users/sbailey/anaconda/envs/desi/lib/python3.5/encodings/ascii.pyin
> decode(self, input, final)
> 
> *     24*classIncrementalDecoder(codecs.IncrementalDecoder):
> 
> *     25*    defdecode(self,input,final=False):
> 
> ---> 26        returncodecs.ascii_decode(input,self.errors)[0]
> 
> *     27* 
> 
> *     28*classStreamWriter(Codec,codecs.StreamWriter):
> 
> 
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 17:
> ordinal not in range(128)
> 
> 
> In [*13*]: *with*set_locale('en_US.UTF-8'):
> 
>     ...:     t = Table.read('blat.csv', format='ascii.basic')
> 
> 
> In [*14*]: t
> 
> Out[*14*]: 
> 
> <Table length=3>
> 
>   x     y  
> 
> int64 int64
> 
> ----- -----
> 
>     1     2
> 
>     3     4
> 
>     5     6
> 
> 
> 
> On Mon, Oct 24, 2016 at 6:53 PM, Aldcroft, Thomas
> <aldcroft at head.cfa.harvard.edu <mailto:aldcroft at head.cfa.harvard.edu>>
> wrote:
> 
> 
> 
>     On Mon, Oct 24, 2016 at 6:11 PM, Derek Homeier
>     <derek at astro.physik.uni-goettingen.de
>     <mailto:derek at astro.physik.uni-goettingen.de>> wrote:
> 
>         On 25 Oct 2016, at 12:01 am, Nathan Goldbaum
>         <nathan12343 at gmail.com <mailto:nathan12343 at gmail.com>> wrote:
>         >
>         > I believe this is issue 2923:
>         >
>         > https://github.com/astropy/astropy/issues/2923
>         <https://github.com/astropy/astropy/issues/2923>
>         >
>         > On Mon, Oct 24, 2016 at 4:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov <mailto:baweaver at lbl.gov>> wrote:
>         > Hello y'all,
>         >
>         > We are trying to read "ASCII" tables containing atomic line data
>         > provided by NIST.  When you request the line wavelength data in
>         > angstroms, NIST very helpfully labels the columns with the angstrom
>         > symbol (?), which is not strictly part of the ASCII character set.
>         >
>         > We can read these tables with Table.read() *and* the environment
>         > variable LANG=en_US.utf-8 set.  However, if LANG is not set,
>         > Table.read() fails to decode these files.
>         >
>         > As far as I can tell the underlying read() function in astropy.io.ascii
>         > does not accept keywords related to the file encoding.
>         >
>         > So two questions:
>         >
>         > 1. Is the lack of an encoding keyword a bug that should be reported?
>         >
>         > 2. Is there a workaround that does not rely on LANG being set?
> 
>         A workaround that would at least get you away without
>         manipulating the
>         environment outside Python would be
> 
>         import locale
>         locale.setlocale(locale.LC_ALL, str(?en_US.utf8?))
> 
> 
>     You can make this a little cleaner using the set_locale context
>     manager in astropy:
> 
>     from astropy.utils.misc import set_locale
>     with set_locale('en_US.utf8'):
>         dat = Table.read(...)
> 
>     As to the original question of whether this should be reported as a
>     bug, it has already been discussed in:
> 
>      https://github.com/astropy/astropy/issues/3826
>     <https://github.com/astropy/astropy/issues/3826>
> 
>     That discussion ended without any really clear consensus except that
>     using Python 3 is a good thing if that is an option.  I have never
>     seriously evaluated how difficult it would be to implement support
>     for unicode inputs for Python 2.  A basic recipe is shown in the
>     stdlib csv package documentation, but I don't know how messy a fully
>     working implementation would get.
> 
>     Cheers,
>     Tom A
>      
> 
> 
>         Cheers,
>                                                 Derek
> 
>         _______________________________________________
>         AstroPy mailing list
>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>         https://mail.scipy.org/mailman/listinfo/astropy
>         <https://mail.scipy.org/mailman/listinfo/astropy>
> 
> 
> 
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
>     <https://mail.scipy.org/mailman/listinfo/astropy>
> 
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 

-- 
Nothing brightens up my morning.  Coffee simply provides a shade of gray
just above the pitch-black of the infinite depths of the abyss.
  --Sid Dabster, userfriendly.org


From derek at astro.physik.uni-goettingen.de  Thu Nov 10 13:42:15 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Thu, 10 Nov 2016 19:42:15 +0100
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <0085d583-3462-4d45-d7aa-a199b7de8fd8@lbl.gov>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
 <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
 <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>
 <CAMCHcTrhC6_AdTtpZay5F4jg68QUbzn5mc3+wxvXX835SG0sHQ@mail.gmail.com>
 <0085d583-3462-4d45-d7aa-a199b7de8fd8@lbl.gov>
Message-ID: <73E9D44A-34E4-4C2D-8CC6-0A9B9252C139@astro.physik.uni-goettingen.de>

On 10 Nov 2016, at 6:59 pm, Benjamin Alan Weaver <baweaver at lbl.gov> wrote:
> 
> I just wanted to follow up on this.  Did the problem that Stephen
> reported with Python 3 get added to any existing bug reports, or a new
> bug report?

If I read right, this is being addressed at least for Python 3 in PR 5448.

https://github.com/astropy/astropy/pull/5448

Cheers,
					Derek



From baweaver at lbl.gov  Thu Nov 10 13:43:47 2016
From: baweaver at lbl.gov (Benjamin Alan Weaver)
Date: Thu, 10 Nov 2016 11:43:47 -0700
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <73E9D44A-34E4-4C2D-8CC6-0A9B9252C139@astro.physik.uni-goettingen.de>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
 <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
 <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>
 <CAMCHcTrhC6_AdTtpZay5F4jg68QUbzn5mc3+wxvXX835SG0sHQ@mail.gmail.com>
 <0085d583-3462-4d45-d7aa-a199b7de8fd8@lbl.gov>
 <73E9D44A-34E4-4C2D-8CC6-0A9B9252C139@astro.physik.uni-goettingen.de>
Message-ID: <af028a0b-0b11-d3a5-06ae-0148f49bc0aa@lbl.gov>

Hello Derek,

OK, thanx.

Kia ora koe,
Benjamin Alan Weaver

On 11/10/2016 11:42 AM, Derek Homeier wrote:
> On 10 Nov 2016, at 6:59 pm, Benjamin Alan Weaver <baweaver at lbl.gov> wrote:
>>
>> I just wanted to follow up on this.  Did the problem that Stephen
>> reported with Python 3 get added to any existing bug reports, or a new
>> bug report?
> 
> If I read right, this is being addressed at least for Python 3 in PR 5448.
> 
> https://github.com/astropy/astropy/pull/5448
> 
> Cheers,
> 					Derek
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 

-- 
He wiped the Earth -- clean as a plate
What does it take to make a Ruskie break?
  --The Clash


From gabrielperren at gmail.com  Mon Nov 14 20:47:11 2016
From: gabrielperren at gmail.com (Gabriel Perren)
Date: Tue, 15 Nov 2016 01:47:11 +0000
Subject: [AstroPy] Example using ZScaleInterval?
Message-ID: <CALBDAwCT8E9PLmPGU=wJ-WySJpi0xxz0EV7R6kTKZ-UAeESgFQ@mail.gmail.com>

Hi,

I'd like to use the ZScaleInterval class (
http://docs.astropy.org/en/stable/api/astropy.visualization.ZScaleInterval.html)
to calculate the (zmin,zmax) values to display a .fits file. I couldn't
find any example anywhere.

Cheers,
Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161115/c492e4d6/attachment.html>

From jmwalawender at gmail.com  Mon Nov 14 21:07:18 2016
From: jmwalawender at gmail.com (Josh Walawender)
Date: Mon, 14 Nov 2016 16:07:18 -1000
Subject: [AstroPy] IRAF geomap and geotran equivalent in AstroPy?
In-Reply-To: <D41C057B.1FF78%mihail.cara@gmail.com>
References: <D41C057B.1FF78%mihail.cara@gmail.com>
Message-ID: <30C0C462-9420-4812-BA03-41B39435FFBD@gmail.com>

Hi all,

I?ve come back to this question of fitting a WCS if given a set of associated coordinates (e.g. x, y, RA, Dec) similar to IRAF?s geomap functionality.  I see several items in astropy.models that look like they might be useful (astropy.models.SIP, astropy.models.InverseSIP, astropy.models.Pix2Sky_*).  What is the status of that code?  There?s not much documentation there and no examples of use.  If there were fittable models for SIP for example then this would be fairly easy.

-Josh




> On Oct 6, 2016, at 7:54 AM, Mihai Cara <mihail.cara at gmail.com> wrote:
> 
> It has been a long time since I've used either geomap or geotran and so I
> cannot guarantee that my suggestions will 100% match your needs.
> DrizzlePac from STScI (https://github.com/spacetelescope/drizzlepac)
> contains methods that replicate (somewhat) geomap except they can do the
> fitting only using linear transformations (no support for higher order
> polynomials):
> 
> import drizzlepac
> drizzlepac.linearfit.fit_all(xy, uv, method='rscale')
> 
> NOTE: method='general' allows fitting for skews as well (that is, it
> produces two rotation angles, two scales, and two shifts).
> 
> Another low-level package https://github.com/spacetelescope/drizzle can be
> used to resample your images. However, you will need to provide your own
> coordinate mappings computed from the transformations found in the fitting
> step.
> 
> Mihai
> 
> 
>> Today's Topics:
>> 
>>  1. Re: IRAF geomap and geotran equivalent in AstroPy?
>>     (Steve Crawford)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 4 Oct 2016 21:45:39 +0200
>> From: Steve Crawford <crawfordsm at gmail.com>
>> To: Astronomical Python mailing list <astropy at scipy.org>
>> Subject: Re: [AstroPy] IRAF geomap and geotran equivalent in AstroPy?
>> Message-ID:
>> 	<CAE+obB_9g9C3MMcgRvr+hBX4ZM2bbr0sT9E+1hboR+Ki4RwDQg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Hi Russell,
>> 
>> Neither has a direct transformation into python as far as I know.
>> However, here are the status of some related things:
>> 
>> There are a lot of things in python that let's you transform your
>> image (scikit image for example).   In ccdproc, we have wrapped the
>> reproject package to provide a transform_image task:
>> http://ccdproc.readthedocs.io/en/latest/api/ccdproc.transform_image.html#c
>> cdproc.transform_image
>> 
>> This will provide similar functionality to geotran but the user has to
>> provide what the transformation they want to provide.
>> 
>> Also, I've started on a little bit of a work in progress of a
>> geomap/ccmap replacement as it does seem like a high priority item.
>> However I have not made much progress at the moment, but if anyone
>> wants to coordinate, please let me know.
>> 
>> On the other hand, there are other packages (astrometry.net, swarp for
>> example) that do similar things as well that might be just as good or
>> better.
>> 
>> Cheers
>> Steve
>> 
>> On Wed, Sep 28, 2016 at 5:29 AM, Russell Kackley <rkackley at naoj.org>
>> wrote:
>>> I have some code that uses the IRAF geomap and geotran tasks via the
>>> pyraf
>>> interface. I would like to replace those IRAF tasks with something from
>>> AstroPy, if possible. I searched the AstroPy mailing
>>> list archives to see if anyone had a suggestion for an AstroPy
>>> replacement
>>> for those two tasks. Back in June 2010, Juan Catalan asked if AstroPy
>>> had
>>> something equivalent to geomap and geotran.
>>> 
>>> https://mail.scipy.org/pipermail/astropy/2010-June/000971.html
>>> 
>>> However, I didn't see a reply that suggested an AstroPy equivalent for
>>> the
>>> IRAF tasks. Does anyone on the list have a suggestion for an AstroPy
>>> replacement of geomap and/or geotran? Thanks.
>>> 
>>> --
>>> Russell Kackley
>>> Subaru Telescope
>>> Hilo, Hawaii
>>> 
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> 
>> 
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
>> ------------------------------
>> 
>> End of AstroPy Digest, Vol 121, Issue 1
>> ***************************************
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From simon at sconseil.fr  Tue Nov 15 05:22:21 2016
From: simon at sconseil.fr (Simon Conseil)
Date: Tue, 15 Nov 2016 11:22:21 +0100
Subject: [AstroPy] Example using ZScaleInterval?
In-Reply-To: <CALBDAwCT8E9PLmPGU=wJ-WySJpi0xxz0EV7R6kTKZ-UAeESgFQ@mail.gmail.com>
References: <CALBDAwCT8E9PLmPGU=wJ-WySJpi0xxz0EV7R6kTKZ-UAeESgFQ@mail.gmail.com>
Message-ID: <fa715478-14cc-f407-4090-e96fd8f3a597@sconseil.fr>

Hi,

You can find an example in 
http://docs.astropy.org/en/stable/visualization/normalization.html#intervals-and-normalization 
with MinMaxInterval, and the same apply to ZScaleInterval and other 
Interval classes:

from astropy.visualization import ZScaleInterval
a = np.random.rand(100,100)
interval = ZScaleInterval()
interval.get_limits(a)

Cheers,

Simon


Le 15/11/2016 ? 02:47, Gabriel Perren a ?crit :
> Hi,
>
> I'd like to use the ZScaleInterval class 
> (http://docs.astropy.org/en/stable/api/astropy.visualization.ZScaleInterval.html) 
> to calculate the (zmin,zmax) values to display a .fits file. I 
> couldn't find any example anywhere.
>
> Cheers,
> Gabriel
>
>
> _______________________________________________
> 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/20161115/6d20af2e/attachment.html>

From gabrielperren at gmail.com  Tue Nov 15 06:59:40 2016
From: gabrielperren at gmail.com (Gabriel Perren)
Date: Tue, 15 Nov 2016 11:59:40 +0000
Subject: [AstroPy] Example using ZScaleInterval?
In-Reply-To: <fa715478-14cc-f407-4090-e96fd8f3a597@sconseil.fr>
References: <CALBDAwCT8E9PLmPGU=wJ-WySJpi0xxz0EV7R6kTKZ-UAeESgFQ@mail.gmail.com>
 <fa715478-14cc-f407-4090-e96fd8f3a597@sconseil.fr>
Message-ID: <CALBDAwCLDCaiwdhf3rnOv1u0RrE3FD5q25VCFs8ypsD9ubkSzA@mail.gmail.com>

Thank you!

El mar., 15 de nov. de 2016 a la(s) 07:22, Simon Conseil <simon at sconseil.fr>
escribi?:

> Hi,
>
> You can find an example in
> http://docs.astropy.org/en/stable/visualization/normalization.html#intervals-and-normalization
> with MinMaxInterval, and the same apply to ZScaleInterval and other
> Interval classes:
>
> from astropy.visualization import ZScaleInterval
> a = np.random.rand(100,100)
> interval = ZScaleInterval()
> interval.get_limits(a)
>
> Cheers,
>
> Simon
>
> Le 15/11/2016 ? 02:47, Gabriel Perren a ?crit :
>
> Hi,
>
> I'd like to use the ZScaleInterval class (
> http://docs.astropy.org/en/stable/api/astropy.visualization.ZScaleInterval.html)
> to calculate the (zmin,zmax) values to display a .fits file. I couldn't
> find any example anywhere.
>
> Cheers,
> Gabriel
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> 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/20161115/257c55cd/attachment.html>

From marcio.melendez at gmail.com  Tue Nov 15 09:26:21 2016
From: marcio.melendez at gmail.com (Marcio Melendez)
Date: Tue, 15 Nov 2016 09:26:21 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with updated
	astrometry
Message-ID: <CAJ0xgiQfx9Ddd7JEF8V6F9oDOiFiDzyMUA_M6ENh+0Dm76L8FA@mail.gmail.com>

Hi all,
Is there a similar function to IDL's  HROT in python, e.g., a function to
rotate an image and create a new FITS header with updated astrometry.

Thanks!

-- 
Marcio B. Melendez, Ph.D
JWST ISIM Optics Support Scientist
KBRwyle Science, Technology and Engineering Group
NASA Goddard Space Flight Center  Greenbelt, MD  20771
Bldg. 29 Rm. T29-10, phone: 301-286-8517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161115/70c62759/attachment.html>

From teuben at astro.umd.edu  Tue Nov 15 10:32:55 2016
From: teuben at astro.umd.edu (Peter Teuben)
Date: Tue, 15 Nov 2016 10:32:55 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
 updated astrometry
In-Reply-To: <CAJ0xgiQfx9Ddd7JEF8V6F9oDOiFiDzyMUA_M6ENh+0Dm76L8FA@mail.gmail.com>
References: <CAJ0xgiQfx9Ddd7JEF8V6F9oDOiFiDzyMUA_M6ENh+0Dm76L8FA@mail.gmail.com>
Message-ID: <0381c927-1026-2610-64d9-54e5611e5c2b@astro.umd.edu>

the best is to use the python interface to montage. it's a contributed package for astropy.

On 11/15/2016 09:26 AM, Marcio Melendez wrote:
> Hi all, 
> Is there a similar function to IDL's  HROT in python, e.g., a function to rotate an image and create a new FITS header with updated astrometry. 
>
> Thanks!
>
> -- 
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771  
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
>
> _______________________________________________
> 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/20161115/490ca202/attachment.html>

From marcio.melendez at gmail.com  Tue Nov 15 10:55:37 2016
From: marcio.melendez at gmail.com (Marcio Melendez)
Date: Tue, 15 Nov 2016 10:55:37 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
	updated astrometry
Message-ID: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>

Hi Peter,
I use Montage mainly for display purpose, to get the correct sky
orientation, but I have never used it to perform any operation. I see that
there is a rotation utility, mRotate, but from the description "This module
is meant for quick-look only; it is *not flux conserving*." which is not
useful for what I need. Are there any other options?

Thanks!

On Tue, Nov 15, 2016 at 10:32 AM, Peter Teuben <teuben at astro.umd.edu> wrote:

> the best is to use the python interface to montage. it's a contributed
> package for astropy.
>
>
> On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>
> Hi all,
> Is there a similar function to IDL's  HROT in python, e.g., a function to
> rotate an image and create a new FITS header with updated astrometry.
>
> Thanks!
>
> --
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Marcio B. Melendez, Ph.D
JWST ISIM Optics Support Scientist
KBRwyle Science, Technology and Engineering Group
NASA Goddard Space Flight Center  Greenbelt, MD  20771
Bldg. 29 Rm. T29-10, phone: 301-286-8517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161115/f74ca53d/attachment.html>

From teuben at astro.umd.edu  Tue Nov 15 11:02:39 2016
From: teuben at astro.umd.edu (Peter Teuben)
Date: Tue, 15 Nov 2016 11:02:39 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
 updated astrometry
In-Reply-To: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>
References: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>
Message-ID: <c3123e19-61b3-f881-7d48-dba36726604b@astro.umd.edu>

Marcio
  I didn't know they didn't flux conserve. You should file a bug report.  They love those.

 I know the equivalent routine in miriad (regrid) does conserve flux, but it's normally used on radio data with a well described beam. Not that your data doesn't have those, but in a bind that's another way.

Alternatively you could use mRotate, and measure the flux in some large area, and rescale manually if need be.

peter

On 11/15/2016 10:55 AM, Marcio Melendez wrote:
> Hi Peter, 
> I use Montage mainly for display purpose, to get the correct sky orientation, but I have never used it to perform any operation. I see that there is a rotation utility, mRotate, but from the description "This module is meant for quick-look only; it is *not flux conserving*." which is not useful for what I need. Are there any other options? 
>
> Thanks! 
>
> On Tue, Nov 15, 2016 at 10:32 AM, Peter Teuben <teuben at astro.umd.edu <mailto:teuben at astro.umd.edu>> wrote:
>
>     the best is to use the python interface to montage. it's a contributed package for astropy.
>
>
>     On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>>     Hi all, 
>>     Is there a similar function to IDL's  HROT in python, e.g., a function to rotate an image and create a new FITS header with updated astrometry. 
>>
>>     Thanks!
>>
>>     -- 
>>     Marcio B. Melendez, Ph.D
>>     JWST ISIM Optics Support Scientist
>>     KBRwyle Science, Technology and Engineering Group
>>     NASA Goddard Space Flight Center  Greenbelt, MD  20771  
>>     Bldg. 29 Rm. T29-10, phone: 301-286-8517 <tel:301-286-8517>
>>
>>
>>     _______________________________________________
>>     AstroPy mailing list
>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>     https://mail.scipy.org/mailman/listinfo/astropy <https://mail.scipy.org/mailman/listinfo/astropy>
>
>     _______________________________________________ AstroPy mailing list AstroPy at scipy.org <mailto:AstroPy at scipy.org> https://mail.scipy.org/mailman/listinfo/astropy <https://mail.scipy.org/mailman/listinfo/astropy> 
>
> -- 
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771  
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
> _______________________________________________
> 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/20161115/89202763/attachment.html>

From demitri.muna at gmail.com  Tue Nov 15 11:13:54 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Tue, 15 Nov 2016 11:13:54 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
 updated astrometry
In-Reply-To: <c3123e19-61b3-f881-7d48-dba36726604b@astro.umd.edu>
References: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>
 <c3123e19-61b3-f881-7d48-dba36726604b@astro.umd.edu>
Message-ID: <285C5325-E0D1-4E24-890E-CC19C70E658D@gmail.com>

Hi,

I'm actually quite interested in this question too.

On Nov 15, 2016, at 11:02 AM, Peter Teuben <teuben at astro.umd.edu> wrote:

>   I didn't know they didn't flux conserve. You should file a bug report.  They love those.

It's a question of algorithm; not a bug. While a bug report won't hurt, I wouldn't expect a "fix" in the short term.

>  I know the equivalent routine in miriad (regrid) does conserve flux, but it's normally used on radio data with a well described beam. Not that your data doesn't have those, but in a bind that's another way.


miriad is the tool I'm most familiar with for doing this. Surely there are other tools?

Cheers,
Demitri

__________
Demitri Muna
Center for Cosmology and AstroParticle Physics
& Department of Astronomy
Ohio State University

http://muna.com <http://muna.com/>
muna at astronomy.ohio-state.edu <mailto:muna at astronomy.ohio-state.edu>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161115/d79b40b3/attachment.html>

From erik.tollerud at gmail.com  Tue Nov 15 11:18:27 2016
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Tue, 15 Nov 2016 11:18:27 -0500
Subject: [AstroPy] astropy vs. casa coordinate transformations?
In-Reply-To: <9643d83f-4bcf-dd1e-553e-47914593c427@astro.umd.edu>
References: <9643d83f-4bcf-dd1e-553e-47914593c427@astro.umd.edu>
Message-ID: <CAARXUwWesy6UedcR8rPbUsvzgV5LexK6ZqewdY0ic8YUec7e4Q@mail.gmail.com>

There's a *place* for this in the form of this repo:
https://github.com/astropy/coordinates-benchmark

Although it doesn't have any of the CASA coordinate systems. It looks like
all of the CASA coordinate systems are already in Astropy. (assuming
https://casa.nrao.edu/docs/cookbook/casa_cookbook014.html#sec587 is the
complete list?) So you can probably do a complete comparison.  The one
catch is that the CASA systems don't quite map completely onto the concept
astropy has for a coordinate "Frame" (
http://docs.astropy.org/en/stable/coordinates/definitions.html).  But it
looks to me like all of the things CASA lists have a direct analog...?


---
Erik T

On Mon, Nov 7, 2016 at 5:21 PM, Peter Teuben <teuben at astro.umd.edu> wrote:

>
> The astropy coordinate transformations look very nice, but CASA also has a
> very impressive collection of these. Has anybody done a detailed comparison
> on how well they compare, as I was about to embark on a spot check.
>
>
> - peter
>
> _______________________________________________
> 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/20161115/b947fa04/attachment.html>

From mihail.cara at gmail.com  Tue Nov 15 11:21:24 2016
From: mihail.cara at gmail.com (Mihai Cara)
Date: Tue, 15 Nov 2016 11:21:24 -0500
Subject: [AstroPy] AstroPy Digest, Vol 122, Issue 11
In-Reply-To: <mailman.102616.1479225765.2321.astropy@scipy.org>
References: <mailman.102616.1479225765.2321.astropy@scipy.org>
Message-ID: <D4509EAD.21519%mihail.cara@gmail.com>

Flux conservation for a rotation resampling should not be of concern since
the |Jacobian| of an orthogonal rotation transformation is 1. If you are
also rescaling by the same scaling factor (let's say, "s") for each axis,
you can simply rescale the intensity of the rescaled image by 1/s^2.

Mihai Cara

On 11/15/16, 11:02 AM, "astropy-bounces at scipy.org on behalf of
astropy-request at scipy.org" <astropy-bounces at scipy.org on behalf of
astropy-request at scipy.org> wrote:

>Send AstroPy mailing list submissions to
>	astropy at scipy.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://mail.scipy.org/mailman/listinfo/astropy
>or, via email, send a message with subject or body 'help' to
>	astropy-request at scipy.org
>
>You can reach the person managing the list at
>	astropy-owner at scipy.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of AstroPy digest..."
>
>
>Today's Topics:
>
>   1. Rotate an image and create new FITS header with updated
>      astrometry (Marcio Melendez)
>   2. Re: Rotate an image and create new FITS header with updated
>      astrometry (Peter Teuben)
>   3. Re: Rotate an image and create new FITS header with	updated
>      astrometry (Marcio Melendez)
>   4. Re: Rotate an image and create new FITS header with updated
>      astrometry (Peter Teuben)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 15 Nov 2016 09:26:21 -0500
>From: Marcio Melendez <marcio.melendez at gmail.com>
>To: Astronomical Python mailing list <astropy at scipy.org>
>Subject: [AstroPy] Rotate an image and create new FITS header with
>	updated	astrometry
>Message-ID:
>	<CAJ0xgiQfx9Ddd7JEF8V6F9oDOiFiDzyMUA_M6ENh+0Dm76L8FA at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi all,
>Is there a similar function to IDL's  HROT in python, e.g., a function to
>rotate an image and create a new FITS header with updated astrometry.
>
>Thanks!
>
>-- 
>Marcio B. Melendez, Ph.D
>JWST ISIM Optics Support Scientist
>KBRwyle Science, Technology and Engineering Group
>NASA Goddard Space Flight Center  Greenbelt, MD  20771
>Bldg. 29 Rm. T29-10, phone: 301-286-8517
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mail.scipy.org/pipermail/astropy/attachments/20161115/70c62759/at
>tachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Tue, 15 Nov 2016 10:32:55 -0500
>From: Peter Teuben <teuben at astro.umd.edu>
>To: astropy at scipy.org
>Subject: Re: [AstroPy] Rotate an image and create new FITS header with
>	updated astrometry
>Message-ID: <0381c927-1026-2610-64d9-54e5611e5c2b at astro.umd.edu>
>Content-Type: text/plain; charset="windows-1252"
>
>the best is to use the python interface to montage. it's a contributed
>package for astropy.
>
>On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>> Hi all, 
>> Is there a similar function to IDL's  HROT in python, e.g., a function
>>to rotate an image and create a new FITS header with updated astrometry.
>>
>> Thanks!
>>
>> -- 
>> Marcio B. Melendez, Ph.D
>> JWST ISIM Optics Support Scientist
>> KBRwyle Science, Technology and Engineering Group
>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mail.scipy.org/pipermail/astropy/attachments/20161115/490ca202/at
>tachment-0001.html>
>
>------------------------------
>
>Message: 3
>Date: Tue, 15 Nov 2016 10:55:37 -0500
>From: Marcio Melendez <marcio.melendez at gmail.com>
>To: Astronomical Python mailing list <astropy at scipy.org>
>Subject: Re: [AstroPy] Rotate an image and create new FITS header with
>	updated astrometry
>Message-ID:
>	<CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi Peter,
>I use Montage mainly for display purpose, to get the correct sky
>orientation, but I have never used it to perform any operation. I see that
>there is a rotation utility, mRotate, but from the description "This
>module
>is meant for quick-look only; it is *not flux conserving*." which is not
>useful for what I need. Are there any other options?
>
>Thanks!
>
>On Tue, Nov 15, 2016 at 10:32 AM, Peter Teuben <teuben at astro.umd.edu>
>wrote:
>
>> the best is to use the python interface to montage. it's a contributed
>> package for astropy.
>>
>>
>> On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>>
>> Hi all,
>> Is there a similar function to IDL's  HROT in python, e.g., a function
>>to
>> rotate an image and create a new FITS header with updated astrometry.
>>
>> Thanks!
>>
>> --
>> Marcio B. Melendez, Ph.D
>> JWST ISIM Optics Support Scientist
>> KBRwyle Science, Technology and Engineering Group
>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>
>>
>> _______________________________________________
>> AstroPy mailing 
>>listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
>-- 
>Marcio B. Melendez, Ph.D
>JWST ISIM Optics Support Scientist
>KBRwyle Science, Technology and Engineering Group
>NASA Goddard Space Flight Center  Greenbelt, MD  20771
>Bldg. 29 Rm. T29-10, phone: 301-286-8517
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mail.scipy.org/pipermail/astropy/attachments/20161115/f74ca53d/at
>tachment-0001.html>
>
>------------------------------
>
>Message: 4
>Date: Tue, 15 Nov 2016 11:02:39 -0500
>From: Peter Teuben <teuben at astro.umd.edu>
>To: astropy at scipy.org
>Subject: Re: [AstroPy] Rotate an image and create new FITS header with
>	updated astrometry
>Message-ID: <c3123e19-61b3-f881-7d48-dba36726604b at astro.umd.edu>
>Content-Type: text/plain; charset="windows-1252"
>
>Marcio
>  I didn't know they didn't flux conserve. You should file a bug report.
>They love those.
>
> I know the equivalent routine in miriad (regrid) does conserve flux, but
>it's normally used on radio data with a well described beam. Not that
>your data doesn't have those, but in a bind that's another way.
>
>Alternatively you could use mRotate, and measure the flux in some large
>area, and rescale manually if need be.
>
>peter
>
>On 11/15/2016 10:55 AM, Marcio Melendez wrote:
>> Hi Peter, 
>> I use Montage mainly for display purpose, to get the correct sky
>>orientation, but I have never used it to perform any operation. I see
>>that there is a rotation utility, mRotate, but from the description
>>"This module is meant for quick-look only; it is *not flux conserving*."
>>which is not useful for what I need. Are there any other options?
>>
>> Thanks! 
>>
>> On Tue, Nov 15, 2016 at 10:32 AM, Peter Teuben <teuben at astro.umd.edu
>><mailto:teuben at astro.umd.edu>> wrote:
>>
>>     the best is to use the python interface to montage. it's a
>>contributed package for astropy.
>>
>>
>>     On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>>>     Hi all, 
>>>     Is there a similar function to IDL's  HROT in python, e.g., a
>>>function to rotate an image and create a new FITS header with updated
>>>astrometry. 
>>>
>>>     Thanks!
>>>
>>>     -- 
>>>     Marcio B. Melendez, Ph.D
>>>     JWST ISIM Optics Support Scientist
>>>     KBRwyle Science, Technology and Engineering Group
>>>     NASA Goddard Space Flight Center  Greenbelt, MD  20771
>>>     Bldg. 29 Rm. T29-10, phone: 301-286-8517 <tel:301-286-8517>
>>>
>>>
>>>     _______________________________________________
>>>     AstroPy mailing list
>>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>     https://mail.scipy.org/mailman/listinfo/astropy
>>><https://mail.scipy.org/mailman/listinfo/astropy>
>>
>>     _______________________________________________ AstroPy mailing
>>list AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>https://mail.scipy.org/mailman/listinfo/astropy
>><https://mail.scipy.org/mailman/listinfo/astropy>
>>
>> -- 
>> Marcio B. Melendez, Ph.D
>> JWST ISIM Optics Support Scientist
>> KBRwyle Science, Technology and Engineering Group
>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mail.scipy.org/pipermail/astropy/attachments/20161115/89202763/at
>tachment.html>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>AstroPy mailing list
>AstroPy at scipy.org
>https://mail.scipy.org/mailman/listinfo/astropy
>
>
>------------------------------
>
>End of AstroPy Digest, Vol 122, Issue 11
>****************************************




From erik.tollerud at gmail.com  Tue Nov 15 11:21:33 2016
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Tue, 15 Nov 2016 11:21:33 -0500
Subject: [AstroPy] Where is the cache file de430.bsp in local machine?
In-Reply-To: <CACVX7WRg-ZcupAcY8a-8Lv+vwtHNNLjizGb+hKasRdcNq4akhA@mail.gmail.com>
References: <CACVX7WRg-ZcupAcY8a-8Lv+vwtHNNLjizGb+hKasRdcNq4akhA@mail.gmail.com>
Message-ID: <CAARXUwXK=29hJNDeEy0=9iE+Go8hXABTTwsvQYc-9H9gg5xizA@mail.gmail.com>

I know this is pretty old... But because it's easy and I just noticed
it I'll answer:  the file does *not* get downloaded under the name
de430.bsp .  It gets put in the astropy download cache under a hash.
http://docs.astropy.org/en/stable/utils/#id15 describes the functions
for manipulating that - you can use "is_url_in_cache" to check if
something is actually in the cache, or "clear_download_cache" to clear
it.
---
Erik T


On Wed, Aug 17, 2016 at 11:02 PM, Yang Hon-Jang <hjyanghj at gmail.com> wrote:
> First time I execute the script get_body('sun', t,  ephemeris='jpl'),
> I see following message?
> Downloading
> http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de430.bsp
> [Done]
>
> But I can't locate the file de430.bsp in my local computer.
> Where is it?
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From bsipocz at gmail.com  Wed Nov 16 07:46:56 2016
From: bsipocz at gmail.com (Brigitta Sipocz)
Date: Wed, 16 Nov 2016 12:46:56 +0000
Subject: [AstroPy] Rotate an image and create new FITS header with
	updated astrometry
Message-ID: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>

Hi Marcio,

While it doesn't do exactly what you ask for, you may want to check out the
affiliated package reproject (http://reproject.readthedocs.io/en/stable/).
It does flux conserving image reprojection:

http://reproject.readthedocs.io/en/stable/

Cheers,
 Brigitta

On 15 November 2016 at 14:26, Marcio Melendez <marcio.melendez at gmail.com>
wrote:

> Hi all,
> Is there a similar function to IDL's  HROT in python, e.g., a function to
> rotate an image and create a new FITS header with updated astrometry.
>
> Thanks!
>
> --
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
> _______________________________________________
> 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/20161116/9b3a4c6c/attachment.html>

From thomas.robitaille at gmail.com  Wed Nov 16 07:52:26 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 16 Nov 2016 12:52:26 +0000
Subject: [AstroPy] Rotate an image and create new FITS header with
	updated astrometry
In-Reply-To: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>
References: <CAJ0xgiRUSbZm=mc1EX8j2odG4JzVc1hCrgsmtpNO_dJb9f8EWg@mail.gmail.com>
Message-ID: <CAGMHX_2n5qfmfLjDh064DYCWxq_LmOgKT-Sd=d9m5tqdq2qg9A@mail.gmail.com>

On 15 November 2016 at 15:55, Marcio Melendez <marcio.melendez at gmail.com> wrote:
> Hi Peter,
> I use Montage mainly for display purpose, to get the correct sky
> orientation, but I have never used it to perform any operation. I see that
> there is a rotation utility, mRotate, but from the description "This module
> is meant for quick-look only; it is not flux conserving." which is not
> useful for what I need. Are there any other options?

You can still do this with Montage - the easy way is to first run
mRotate, then run mGetHdr to get the header from the rotated image,
and mProject your original image to the new header to get your final
image - since mProject is flux-conserving.

Cheers,
Tom



>
> Thanks!
>
> On Tue, Nov 15, 2016 at 10:32 AM, Peter Teuben <teuben at astro.umd.edu> wrote:
>>
>> the best is to use the python interface to montage. it's a contributed
>> package for astropy.
>>
>>
>> On 11/15/2016 09:26 AM, Marcio Melendez wrote:
>>
>> Hi all,
>> Is there a similar function to IDL's  HROT in python, e.g., a function to
>> rotate an image and create a new FITS header with updated astrometry.
>>
>> Thanks!
>>
>> --
>> Marcio B. Melendez, Ph.D
>> JWST ISIM Optics Support Scientist
>> KBRwyle Science, Technology and Engineering Group
>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From simon at sconseil.fr  Wed Nov 16 09:13:32 2016
From: simon at sconseil.fr (Simon Conseil)
Date: Wed, 16 Nov 2016 15:13:32 +0100
Subject: [AstroPy] Rotate an image and create new FITS header with
 updated astrometry
In-Reply-To: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>
References: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>
Message-ID: <b280111b-a4be-d0b0-41ee-81a272f342af@sconseil.fr>

Hi all,

We have some code to rotate an image with a given angle:

http://mpdaf.readthedocs.io/en/latest/image.html#image-geometrical-manipulation

http://mpdaf.readthedocs.io/en/latest/api/mpdaf.obj.Image.html#mpdaf.obj.Image.rotate

It uses scipy.ndimage.affine_transform, and should give the same result 
as reproject, which uses scipy.ndimage.map_coordinates (both rely on 
ndimage.geometric_transform). It would be interesting to compare !

Cheers,

Simon



Le 16/11/2016 ? 13:46, Brigitta Sipocz a ?crit :
>
> Hi Marcio,
>
> While it doesn't do exactly what you ask for, you may want to check 
> out the affiliated package reproject 
> (http://reproject.readthedocs.io/en/stable/ 
> <http://reproject.readthedocs.io/en/stable/>). It does flux conserving 
> image reprojection:
>
> http://reproject.readthedocs.io/en/stable/ 
> <http://reproject.readthedocs.io/en/stable/>
>
> Cheers,
>  Brigitta
>
> On 15 November 2016 at 14:26, Marcio Melendez 
> <marcio.melendez at gmail.com <mailto:marcio.melendez at gmail.com>> wrote:
>
>     Hi all,
>     Is there a similar function to IDL's  HROT in python, e.g., a
>     function to rotate an image and create a new FITS header with
>     updated astrometry.
>
>     Thanks!
>
>     -- 
>     Marcio B. Melendez, Ph.D
>     JWST ISIM Optics Support Scientist
>     KBRwyle Science, Technology and Engineering Group
>     NASA Goddard Space Flight Center  Greenbelt, MD  20771
>     Bldg. 29 Rm. T29-10, phone: 301-286-8517 <tel:301-286-8517>
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
>     <https://mail.scipy.org/mailman/listinfo/astropy>
>
>
>
>
>
>
> _______________________________________________
> 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/20161116/d3ade743/attachment.html>

From marcio.melendez at gmail.com  Wed Nov 16 10:55:23 2016
From: marcio.melendez at gmail.com (Marcio Melendez)
Date: Wed, 16 Nov 2016 10:55:23 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
	updated astrometry
In-Reply-To: <b280111b-a4be-d0b0-41ee-81a272f342af@sconseil.fr>
References: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>
 <b280111b-a4be-d0b0-41ee-81a272f342af@sconseil.fr>
Message-ID: <CAJ0xgiQKeSOG0_BLoxxop83cxQQmoJTSZ=jkZ1kYhBAEJSvsvA@mail.gmail.com>

Hi Simon,
It looks like a very nice software, thanks for sharing. I started to play
around with it but  a simple read an image and then rotate, got me an error
(see below). I need to open a ticket for this issue in the MPDAF webpage,
however it seems very inconvenient as you need to create an account with
CRAL first.

  File "<stdin>", line 1, in <module>

  File
"/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py",
line 1272, in rotate

    cutoff=cutoff)

  File
"/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py",
line 1161, in _rotate

    self.wcs.set_cd(newcd)

  File
"/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/coords.py",
line 1303, in set_cd

    self.wcs.wcs.crota = image_angle_from_cd(cd, u.deg)

ValueError: object of too small depth for desired array



On Wed, Nov 16, 2016 at 9:13 AM, Simon Conseil <simon at sconseil.fr> wrote:

> Hi all,
>
> We have some code to rotate an image with a given angle:
>
> http://mpdaf.readthedocs.io/en/latest/image.html#image-
> geometrical-manipulation
>
> http://mpdaf.readthedocs.io/en/latest/api/mpdaf.obj.Image.
> html#mpdaf.obj.Image.rotate
>
> It uses scipy.ndimage.affine_transform, and should give the same result
> as reproject, which uses scipy.ndimage.map_coordinates (both rely on
> ndimage.geometric_transform). It would be interesting to compare !
>
> Cheers,
>
> Simon
>
>
>
> Le 16/11/2016 ? 13:46, Brigitta Sipocz a ?crit :
>
>
> Hi Marcio,
>
> While it doesn't do exactly what you ask for, you may want to check out
> the affiliated package reproject (http://reproject.readthedocs.
> io/en/stable/). It does flux conserving image reprojection:
>
> http://reproject.readthedocs.io/en/stable/
>
> Cheers,
>  Brigitta
>
> On 15 November 2016 at 14:26, Marcio Melendez <marcio.melendez at gmail.com>
> wrote:
>
>> Hi all,
>> Is there a similar function to IDL's  HROT in python, e.g., a function to
>> rotate an image and create a new FITS header with updated astrometry.
>>
>> Thanks!
>>
>> --
>> Marcio B. Melendez, Ph.D
>> JWST ISIM Optics Support Scientist
>> KBRwyle Science, Technology and Engineering Group
>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Marcio B. Melendez, Ph.D
JWST ISIM Optics Support Scientist
KBRwyle Science, Technology and Engineering Group
NASA Goddard Space Flight Center  Greenbelt, MD  20771
Bldg. 29 Rm. T29-10, phone: 301-286-8517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161116/9e4cce40/attachment.html>

From simon at sconseil.fr  Wed Nov 16 11:16:12 2016
From: simon at sconseil.fr (Simon Conseil)
Date: Wed, 16 Nov 2016 17:16:12 +0100
Subject: [AstroPy] Rotate an image and create new FITS header with
 updated astrometry
In-Reply-To: <CAJ0xgiQKeSOG0_BLoxxop83cxQQmoJTSZ=jkZ1kYhBAEJSvsvA@mail.gmail.com>
References: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>
 <b280111b-a4be-d0b0-41ee-81a272f342af@sconseil.fr>
 <CAJ0xgiQKeSOG0_BLoxxop83cxQQmoJTSZ=jkZ1kYhBAEJSvsvA@mail.gmail.com>
Message-ID: <7c9ffa1b-3a9c-9ccf-8430-90d91396c571@sconseil.fr>



Le 16/11/2016 ? 16:55, Marcio Melendez a ?crit :
> Hi Simon,
> It looks like a very nice software, thanks for sharing. I started to 
> play around with it but  a simple read an image and then rotate, got 
> me an error (see below). I need to open a ticket for this issue in the 
> MPDAF webpage, however it seems very inconvenient as you need to 
> create an account with CRAL first.

Yes, sorry about that ..
But we also have a mailing list, I can transfer you email there to avoid 
spamming Astropy's list, and try to find the bug (we use mostly MUSE and 
HST data so it is possible that some wcs stuff is not well handled for 
your data).

Simon



>   File "<stdin>", line 1, in <module>
>
>   File 
> "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py", 
> line 1272, in rotate
>
>     cutoff=cutoff)
>
>   File 
> "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py", 
> line 1161, in _rotate
>
> self.wcs.set_cd(newcd)
>
>   File 
> "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/coords.py", 
> line 1303, in set_cd
>
> self.wcs.wcs.crota = image_angle_from_cd(cd, u.deg)
>
> ValueError: object of too small depth for desired array
>
>
>
>
> On Wed, Nov 16, 2016 at 9:13 AM, Simon Conseil <simon at sconseil.fr 
> <mailto:simon at sconseil.fr>> wrote:
>
>     Hi all,
>
>     We have some code to rotate an image with a given angle:
>
>     http://mpdaf.readthedocs.io/en/latest/image.html#image-geometrical-manipulation
>     <http://mpdaf.readthedocs.io/en/latest/image.html#image-geometrical-manipulation>
>
>     http://mpdaf.readthedocs.io/en/latest/api/mpdaf.obj.Image.html#mpdaf.obj.Image.rotate
>     <http://mpdaf.readthedocs.io/en/latest/api/mpdaf.obj.Image.html#mpdaf.obj.Image.rotate>
>
>     It uses scipy.ndimage.affine_transform, and should give the same
>     result as reproject, which uses scipy.ndimage.map_coordinates
>     (both rely on ndimage.geometric_transform). It would be
>     interesting to compare !
>
>     Cheers,
>
>     Simon
>
>
>
>     Le 16/11/2016 ? 13:46, Brigitta Sipocz a ?crit :
>>
>>     Hi Marcio,
>>
>>     While it doesn't do exactly what you ask for, you may want to
>>     check out the affiliated package reproject
>>     (http://reproject.readthedocs.io/en/stable/
>>     <http://reproject.readthedocs.io/en/stable/>). It does flux
>>     conserving image reprojection:
>>
>>     http://reproject.readthedocs.io/en/stable/
>>     <http://reproject.readthedocs.io/en/stable/>
>>
>>     Cheers,
>>      Brigitta
>>
>>     On 15 November 2016 at 14:26, Marcio Melendez
>>     <marcio.melendez at gmail.com <mailto:marcio.melendez at gmail.com>> wrote:
>>
>>         Hi all,
>>         Is there a similar function to IDL's  HROT in python, e.g., a
>>         function to rotate an image and create a new FITS header with
>>         updated astrometry.
>>
>>         Thanks!
>>
>>         -- 
>>         Marcio B. Melendez, Ph.D
>>         JWST ISIM Optics Support Scientist
>>         KBRwyle Science, Technology and Engineering Group
>>         NASA Goddard Space Flight Center  Greenbelt, MD  20771
>>         Bldg. 29 Rm. T29-10, phone: 301-286-8517 <tel:301-286-8517>
>>
>>         _______________________________________________
>>         AstroPy mailing list
>>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>         https://mail.scipy.org/mailman/listinfo/astropy
>>         <https://mail.scipy.org/mailman/listinfo/astropy>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     AstroPy mailing list
>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>     https://mail.scipy.org/mailman/listinfo/astropy
>>     <https://mail.scipy.org/mailman/listinfo/astropy>
>     _______________________________________________ AstroPy mailing
>     list AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
>     <https://mail.scipy.org/mailman/listinfo/astropy> 
>
> -- 
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
> _______________________________________________
> 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/20161116/da4130e3/attachment.html>

From marcio.melendez at gmail.com  Wed Nov 16 11:28:43 2016
From: marcio.melendez at gmail.com (Marcio Melendez)
Date: Wed, 16 Nov 2016 11:28:43 -0500
Subject: [AstroPy] Rotate an image and create new FITS header with
	updated astrometry
In-Reply-To: <7c9ffa1b-3a9c-9ccf-8430-90d91396c571@sconseil.fr>
References: <CAEjJ3fisNY5-TD+6siRCsh100E1PAS2Nvw-Eu2BeNwSu8RRpVQ@mail.gmail.com>
 <b280111b-a4be-d0b0-41ee-81a272f342af@sconseil.fr>
 <CAJ0xgiQKeSOG0_BLoxxop83cxQQmoJTSZ=jkZ1kYhBAEJSvsvA@mail.gmail.com>
 <7c9ffa1b-3a9c-9ccf-8430-90d91396c571@sconseil.fr>
Message-ID: <CAJ0xgiQMmgv=XkYyT-1tLDVOqB4mrmnTkYdCkjs5fL5D3qMOmA@mail.gmail.com>

Yes, that would be great. Once there is a solution to the problem, I can
post an update with the solution so other Astropy users can benefit.

On Wed, Nov 16, 2016 at 11:16 AM, Simon Conseil <simon at sconseil.fr> wrote:

>
>
> Le 16/11/2016 ? 16:55, Marcio Melendez a ?crit :
>
> Hi Simon,
> It looks like a very nice software, thanks for sharing. I started to play
> around with it but  a simple read an image and then rotate, got me an error
> (see below). I need to open a ticket for this issue in the MPDAF webpage,
> however it seems very inconvenient as you need to create an account with
> CRAL first.
>
>
> Yes, sorry about that ..
> But we also have a mailing list, I can transfer you email there to avoid
> spamming Astropy's list, and try to find the bug (we use mostly MUSE and
> HST data so it is possible that some wcs stuff is not well handled for your
> data).
>
> Simon
>
>
>
>
>   File "<stdin>", line 1, in <module>
>
>   File "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py",
> line 1272, in rotate
>
>     cutoff=cutoff)
>
>   File "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/image.py",
> line 1161, in _rotate
>
>     self.wcs.set_cd(newcd)
>
>   File "/Users/<username>/anaconda/lib/python3.4/site-packages/mpdaf/obj/coords.py",
> line 1303, in set_cd
>
>     self.wcs.wcs.crota = image_angle_from_cd(cd, u.deg)
>
> ValueError: object of too small depth for desired array
>
>
>
> On Wed, Nov 16, 2016 at 9:13 AM, Simon Conseil <simon at sconseil.fr> wrote:
>
>> Hi all,
>>
>> We have some code to rotate an image with a given angle:
>>
>> http://mpdaf.readthedocs.io/en/latest/image.html#image-geome
>> trical-manipulation
>>
>> http://mpdaf.readthedocs.io/en/latest/api/mpdaf.obj.Image.ht
>> ml#mpdaf.obj.Image.rotate
>>
>> It uses scipy.ndimage.affine_transform, and should give the same result
>> as reproject, which uses scipy.ndimage.map_coordinates (both rely on
>> ndimage.geometric_transform). It would be interesting to compare !
>>
>> Cheers,
>>
>> Simon
>>
>>
>>
>> Le 16/11/2016 ? 13:46, Brigitta Sipocz a ?crit :
>>
>>
>> Hi Marcio,
>>
>> While it doesn't do exactly what you ask for, you may want to check out
>> the affiliated package reproject (http://reproject.readthedocs.
>> io/en/stable/). It does flux conserving image reprojection:
>>
>> http://reproject.readthedocs.io/en/stable/
>>
>> Cheers,
>>  Brigitta
>>
>> On 15 November 2016 at 14:26, Marcio Melendez <marcio.melendez at gmail.com>
>> wrote:
>>
>>> Hi all,
>>> Is there a similar function to IDL's  HROT in python, e.g., a function
>>> to rotate an image and create a new FITS header with updated astrometry.
>>>
>>> Thanks!
>>>
>>> --
>>> Marcio B. Melendez, Ph.D
>>> JWST ISIM Optics Support Scientist
>>> KBRwyle Science, Technology and Engineering Group
>>> NASA Goddard Space Flight Center  Greenbelt, MD  20771
>>> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________ AstroPy mailing list
>> AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy
>
> --
> Marcio B. Melendez, Ph.D
> JWST ISIM Optics Support Scientist
> KBRwyle Science, Technology and Engineering Group
> NASA Goddard Space Flight Center  Greenbelt, MD  20771
> Bldg. 29 Rm. T29-10, phone: 301-286-8517
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Marcio B. Melendez, Ph.D
JWST ISIM Optics Support Scientist
KBRwyle Science, Technology and Engineering Group
NASA Goddard Space Flight Center  Greenbelt, MD  20771
Bldg. 29 Rm. T29-10, phone: 301-286-8517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161116/fbfeaf1e/attachment.html>

From stuart at cadair.com  Sat Nov 19 05:32:08 2016
From: stuart at cadair.com (Stuart Mumford)
Date: Sat, 19 Nov 2016 10:32:08 +0000
Subject: [AstroPy] Reminder: Python in Astronomy 2017 Deadline
Message-ID: <a886bf4d-b013-b526-dc6d-93f99b84343b@cadair.com>

Hello all,


Applications for the Python in Astronomy 2017 conference
(http://openastronomy.org/pyastro/2017/) are open until *December 9th*,
2016. The conference will be held on 8th - 12th May 2017 at the Lorentz
Center in Leiden, the Netherlands. Please fill out this form
<https://docs.google.com/forms/d/e/1FAIpQLSfFvzolQvW5PJRbgIoPs73t4LgMIDNX2lX3RThzfmES3MtHdg/viewform?c=0&w=1>to
apply.


The Python in Astronomy conferences aim to bring together a wide variety
of people who currently use, develop or teach people about Python
packages in the context of all forms of Astronomy. Participant selection
will be made with the goal of growingthe Python in Astronomy community
and we particularly encourage requests to attend from junior astronomers
and people who are new to contributing to open source software. This
conference is neither intended to be an introduction to Python bootcamp
nor only for expert-level Python developers, but we do expect all
participants to have at least a basic familiarity with Python.


Please fill out the application and indicate the level of financial
support you will likely require in order to attend. Once the
participants have been selected, we?ll get back in touch with everyone
about their specific financial support requirements.


Stuart Mumford, SOC Chair

Matt Craig

Kelle Cruz

Daniela Huppenkothen

Abigail Stevens

Erik Tollerud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161119/135bc95e/attachment.html>

From teuben at astro.umd.edu  Sun Nov 20 16:10:40 2016
From: teuben at astro.umd.edu (Peter Teuben)
Date: Sun, 20 Nov 2016 16:10:40 -0500
Subject: [AstroPy] descriptive package descriptions?
Message-ID: <8358ebfa-5449-0e83-0416-897a1ebac810@astro.umd.edu>

the one line packages descriptions, as for example seen on anaconda's

    https://anaconda.org/astropy/repo

could use some cleanup/normalization. How are these generated? The astropy group could make them more coherent between them. I'm thinking of the unix man page description under the NAME field.  A few are still labeled "No Summary", and my eye also caught an author's colorful opinion.

The entry for "emcee" is labeled "kick ass blablabla".  Perhaps cute in 2015. But I really object to putting an opinion in a searchable line like that. We should stick to facts. I'm not even sure how to measure kick-ass anyways.  And how is one  to trump that one, if one ever write one that actually runs in reasonable time   There will be no end in sight in the language we'll have to use to describe codes. 

peter



From mcraig at mnstate.edu  Sun Nov 20 20:29:21 2016
From: mcraig at mnstate.edu (Matthew Craig)
Date: Mon, 21 Nov 2016 01:29:21 +0000
Subject: [AstroPy] descriptive package descriptions?
In-Reply-To: <8358ebfa-5449-0e83-0416-897a1ebac810@astro.umd.edu>
References: <8358ebfa-5449-0e83-0416-897a1ebac810@astro.umd.edu>
Message-ID: <22DD937E-BBE7-4D7B-968D-B997B899A016@mnstate.edu>

Hi Peter,

I believe the one line descriptions are generated from the description argument in setup.py, though it is possible to override that manually. Not sure why some have ?No summary.?

I can update the ?No summary? ones over thanksgiving (I?m one of the maintainers of the conda channel) and am happy to update any other summaries package owners want to change?.when the  build mechanism is working well I never see the summaries and would be reluctant to edit on the fly in any event.

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 20, 2016, at 3:10 PM, Peter Teuben <teuben at astro.umd.edu<mailto:teuben at astro.umd.edu>> wrote:

the one line packages descriptions, as for example seen on anaconda's

   https://anaconda.org/astropy/repo

could use some cleanup/normalization. How are these generated? The astropy group could make them more coherent between them. I'm thinking of the unix man page description under the NAME field.  A few are still labeled "No Summary", and my eye also caught an author's colorful opinion.

The entry for "emcee" is labeled "kick ass blablabla".  Perhaps cute in 2015. But I really object to putting an opinion in a searchable line like that. We should stick to facts. I'm not even sure how to measure kick-ass anyways.  And how is one  to trump that one, if one ever write one that actually runs in reasonable time   There will be no end in sight in the language we'll have to use to describe codes.

peter

_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto: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/20161121/cf63c596/attachment.html>

From astropy at liska.ath.cx  Mon Nov 21 02:32:32 2016
From: astropy at liska.ath.cx (Ole Streicher)
Date: Mon, 21 Nov 2016 08:32:32 +0100
Subject: [AstroPy] descriptive package descriptions?
References: <8358ebfa-5449-0e83-0416-897a1ebac810@astro.umd.edu>
 <22DD937E-BBE7-4D7B-968D-B997B899A016@mnstate.edu>
Message-ID: <87k2bx70fj.fsf@liska.ath.cx>

Hi Matthew,

Matthew Craig <mcraig at mnstate.edu> writes:
> I can update the ?No summary? ones over thanksgiving (I?m one of the
> maintainers of the conda channel) and am happy to update any other
> summaries package owners want to change?.when the build mechanism is
> working well I never see the summaries and would be reluctant to edit
> on the fly in any event.

To make this more straightforward, you may use the short descriptions
from Debian Astro:

https://blends.debian.org/astro/tasks/python3

If you find one or the other not useful, this would in turn help me to
improve :-)

Cheers

Ole


From npkuin at gmail.com  Thu Nov 24 18:55:22 2016
From: npkuin at gmail.com (Paul Kuin)
Date: Thu, 24 Nov 2016 23:55:22 +0000
Subject: [AstroPy] Need some advise about inputting a old coordinate
Message-ID: <CANoQ6N2Sf5EFZdMksE6hhqhqZQdo-mHeaO5mnCYP4X9ZcjJ_8A@mail.gmail.com>

I have a coordinate ra, dec in (1900) which I assume is
the B1900 equinox. If I put that in the SkyCoord call it does
seem to default to ICRS. Its not FK4 or FK5, so how do I enter
that coordinate?  Can someone help me, please?

What I did so far - things that work is when the frame is ICRS or FK4:

pos = coordinates.SkyCoord(FK4(ra=Angle("5h11.5m"), dec=Angle("-71d46m")),)
and
p2000=pos.transform_to("icrs")
with
pos
<SkyCoord (FK4: equinox=B1950.000, obstime=B1950.000): (ra, dec) in deg
    (77.875, -71.76666667)>
and
p2000
<SkyCoord (ICRS): (ra, dec) in deg
    (77.69083577, -71.70770648)>

That all works but it is not a B1950 frame, unfortunately, but B1900.

p1900 = coordinates.SkyCoord(ra=Angle("5h11.5m"),
dec=Angle("-71d46m"),equinox=astropy.time.Time(2415020.3135,format="jd"))
 p1900
<SkyCoord (ICRS): (ra, dec) in deg
 (77.875, -71.76666667)>

I hope I'm not too confusing, but it seems not possible. Any help is
being appreciated!

Cheers,
   Paul


-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204111 (work)
mobile +44(0)7908715953  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.


From stuart at cadair.com  Fri Nov 25 05:04:42 2016
From: stuart at cadair.com (Stuart Mumford)
Date: Fri, 25 Nov 2016 10:04:42 +0000
Subject: [AstroPy] Interested in Hosting Python in Astronomy 2018?
Message-ID: <9f5f7181-547b-4c7a-c0ce-9c17bfb5e118@cadair.com>

Hello all,


I am chair of the SOC for Python in Astronomy 2017, which is scheduled
for May 8-12 at the Lorentz Center in Leiden, the Netherlands
http://openastronomy.org/pyastro/2017).


I am getting in touch because we would like to start the process of
choosing the 2018 venue as soon as possible and, ideally, announce the
2018 location at the upcoming 2017 conference.


If you are interested in hosting the 2018 Python in Astronomy conference
and have not already filled out our venue information form, please do
so: https://goo.gl/forms/hWkoDPX8KWEwZGUQ2(Note: if you already filled
in this form with 2017 in mind, you will be considered for 2018)


The SOC for 2017 will shortlist some venues and be in touch. We also
plan to talk to you or a representative of your venue at the 2017
conference and then announce the 2018 venue at the conference dinner.


Thanks,

Stuart Mumford, on behalf of the Python in Astronomy 2017 SOC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161125/256b2b22/attachment.html>

From varunb at iucaa.in  Sun Nov 27 06:58:23 2016
From: varunb at iucaa.in (Varun Bhalerao)
Date: Sun, 27 Nov 2016 17:28:23 +0530
Subject: [AstroPy] Wrong earth mass in astropy.constants
Message-ID: <82B8473F-1012-4E87-881E-B32B8C552DDA@iucaa.in>

Astropy.constants has the following value for earth mass:

In [70]: const.M_earth
Out[70]: <Constant name=u'Earth mass' value=5.9742e+24 uncertainty=5e+19 unit='kg' reference=u"Allen's Astrophysical Quantities 4th Ed.">

Looking into Allen's, the reference is a 1992 book (Lerch, F.J. et al. 1992). This does not agree with the current value: 5.9722e24 +- 6e20

That value seems to come from a 2011 IAU publication:
http://asa.usno.navy.mil/static/files/2016/Astronomical_Constants_2016.pdf
(or even https://en.wikipedia.org/wiki/Earth_mass)

The website of the IAU working group seems to be http://maia.usno.navy.mil/NSFA/NSFA_cbe.html - and there are even small differences in G, R_earth etc!

Can the values be updated?

Regards,
-- Varun
____________________
-  Varun Bhalerao  -
Office: A 214, IUCAA
Ph: +91 20 2560 4214
www.iucaa.in/~varunb

This email is encrypted and signed with OpenPGP.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/astropy/attachments/20161127/6fd09543/attachment.sig>

From p3y1i4n at gmail.com  Sun Nov 27 09:50:07 2016
From: p3y1i4n at gmail.com (Pey Lian Lim)
Date: Sun, 27 Nov 2016 09:50:07 -0500
Subject: [AstroPy]  Wrong earth mass in astropy.constants
Message-ID: <CAJt49iR+F-9SNTJLBcxfgBWTVhH81oB8e1TYDhgVwhTvrPAMTA@mail.gmail.com>

Astropy is still undecided on exactly what is the best way to version
control constants. Please see https://github.com/astropy/astropy/issues/4958
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161127/b0540f3c/attachment.html>

From varunb at iucaa.in  Mon Nov 28 07:09:06 2016
From: varunb at iucaa.in (Varun Bhalerao)
Date: Mon, 28 Nov 2016 17:39:06 +0530
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <mailman.3.1480334402.15839.astropy@scipy.org>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
Message-ID: <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>

Thanks!

But shouldn't the current version reflect latest value of constants, while versioning is being applied? It seems "current value is different from previous version" is lesser of a problem than "current value is different from current best accepted value"

-- Varun
____________________
-  Varun Bhalerao  -
Office: A 214, IUCAA
Ph: +91 20 2560 4214
www.iucaa.in/~varunb

This email is encrypted and signed with OpenPGP.

> On 28-Nov-2016, at 5:30 pm, astropy-request at scipy.org wrote:
> 
> Message: 1
> Date: Sun, 27 Nov 2016 09:50:07 -0500
> From: Pey Lian Lim <p3y1i4n at gmail.com>
> To: astropy at scipy.org
> Subject: [AstroPy]  Wrong earth mass in astropy.constants
> Message-ID:
> 	<CAJt49iR+F-9SNTJLBcxfgBWTVhH81oB8e1TYDhgVwhTvrPAMTA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Astropy is still undecided on exactly what is the best way to version
> control constants. Please see https://github.com/astropy/astropy/issues/4958
> .
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mail.scipy.org/pipermail/astropy/attachments/20161127/b0540f3c/attachment-0001.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/astropy/attachments/20161128/235b68a6/attachment.sig>

From ewinter at stsci.edu  Mon Nov 28 10:11:16 2016
From: ewinter at stsci.edu (Eric Winter)
Date: Mon, 28 Nov 2016 15:11:16 +0000
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
Message-ID: <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>

Therein lies the problem ? who decides on the ?best accepted value?? My initial thought would be to use values of constants defined by appropriate authorities, such as NASA, AAS, or IAU. But those values will always (and with good reason) lag behind the ?latest value?. I think (this is just IMHO, of course) that official, vetted and reviewed values from trusted authorities should be used for AstroPy ? and only such values. If a given user needs a more recent value, they can simply override it in their own code (and document said change, of course).

FWIW
Eric Winter

On 11/28/16, 7:09 AM, "AstroPy on behalf of Varun Bhalerao" <astropy-bounces at scipy.org on behalf of varunb at iucaa.in> wrote:

    Thanks!
    
    But shouldn't the current version reflect latest value of constants, while versioning is being applied? It seems "current value is different from previous version" is lesser of a problem than "current value is different from current best accepted value"
    
    -- Varun
    ____________________
    -  Varun Bhalerao  -
    Office: A 214, IUCAA
    Ph: +91 20 2560 4214
    www.iucaa.in/~varunb
    
    This email is encrypted and signed with OpenPGP.
    
    > On 28-Nov-2016, at 5:30 pm, astropy-request at scipy.org wrote:
    > 
    > Message: 1
    > Date: Sun, 27 Nov 2016 09:50:07 -0500
    > From: Pey Lian Lim <p3y1i4n at gmail.com>
    > To: astropy at scipy.org
    > Subject: [AstroPy]  Wrong earth mass in astropy.constants
    > Message-ID:
    > 	<CAJt49iR+F-9SNTJLBcxfgBWTVhH81oB8e1TYDhgVwhTvrPAMTA at mail.gmail.com>
    > Content-Type: text/plain; charset="utf-8"
    > 
    > Astropy is still undecided on exactly what is the best way to version
    > control constants. Please see https://github.com/astropy/astropy/issues/4958
    > .
    > -------------- next part --------------
    > An HTML attachment was scrubbed...
    > URL: <https://mail.scipy.org/pipermail/astropy/attachments/20161127/b0540f3c/attachment-0001.html>
    
    


From ejensen1 at swarthmore.edu  Mon Nov 28 10:20:53 2016
From: ejensen1 at swarthmore.edu (Eric Jensen)
Date: Mon, 28 Nov 2016 10:20:53 -0500
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
Message-ID: <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>

The IAU passed a resolution relatively recently addressing exactly this problem, and recommending standard values, while acknowledging that best estimates might continue to diverge slightly from these.  So it seems like these IAU standard values would be a good option to consider for use in astropy: 

https://arxiv.org/abs/1510.07674

Resolution B3 here:

https://www.iau.org/static/resolutions/IAU2015_English.pdf

Eric

> On Nov 28, 2016, at 10:11 AM, Eric Winter <ewinter at stsci.edu> wrote:
> 
> Therein lies the problem ? who decides on the ?best accepted value?? My initial thought would be to use values of constants defined by appropriate authorities, such as NASA, AAS, or IAU. But those values will always (and with good reason) lag behind the ?latest value?. I think (this is just IMHO, of course) that official, vetted and reviewed values from trusted authorities should be used for AstroPy ? and only such values. If a given user needs a more recent value, they can simply override it in their own code (and document said change, of course).
> 
> FWIW
> Eric Winter



From thomas.robitaille at gmail.com  Mon Nov 28 10:44:36 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 28 Nov 2016 15:44:36 +0000
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
 <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
Message-ID: <CAGMHX_0AoiTa-0=V0hfE6hTnhycsbcuhvoHVshzXwReObXwC8w@mail.gmail.com>

The main problem we are facing in Astropy is that if we update constants
from one release to the next, results might then change, which might not be
acceptable for some users. Therefore, we need to make sure we have a
mechanism for users to import a 'fixed/frozen' version of constants that
will not change in future releases of Astropy, and this is why there are
delays currently in updating some of the constants.

Cheers,
Tom



On 28 November 2016 at 15:20, Eric Jensen <ejensen1 at swarthmore.edu> wrote:

> The IAU passed a resolution relatively recently addressing exactly this
> problem, and recommending standard values, while acknowledging that best
> estimates might continue to diverge slightly from these.  So it seems like
> these IAU standard values would be a good option to consider for use in
> astropy:
>
> https://arxiv.org/abs/1510.07674
>
> Resolution B3 here:
>
> https://www.iau.org/static/resolutions/IAU2015_English.pdf
>
> Eric
>
> > On Nov 28, 2016, at 10:11 AM, Eric Winter <ewinter at stsci.edu> wrote:
> >
> > Therein lies the problem ? who decides on the ?best accepted value?? My
> initial thought would be to use values of constants defined by appropriate
> authorities, such as NASA, AAS, or IAU. But those values will always (and
> with good reason) lag behind the ?latest value?. I think (this is just
> IMHO, of course) that official, vetted and reviewed values from trusted
> authorities should be used for AstroPy ? and only such values. If a given
> user needs a more recent value, they can simply override it in their own
> code (and document said change, of course).
> >
> > FWIW
> > Eric Winter
>
> _______________________________________________
> 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/20161128/6fca45d9/attachment.html>

From demitri.muna at gmail.com  Mon Nov 28 10:56:20 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Mon, 28 Nov 2016 10:56:20 -0500
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <CAGMHX_0AoiTa-0=V0hfE6hTnhycsbcuhvoHVshzXwReObXwC8w@mail.gmail.com>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
 <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
 <CAGMHX_0AoiTa-0=V0hfE6hTnhycsbcuhvoHVshzXwReObXwC8w@mail.gmail.com>
Message-ID: <A284225C-060A-4D50-AAFE-7A06E53F68AF@gmail.com>

Hi,

On Nov 28, 2016, at 10:44 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:

> The main problem we are facing in Astropy is that if we update constants from one release to the next, results might then change, which might not be acceptable for some users. Therefore, we need to make sure we have a mechanism for users to import a 'fixed/frozen' version of constants that will not change in future releases of Astropy, and this is why there are delays currently in updating some of the constants.

Taking the devil's advocate position-

1) Those that are worried about things like the Earth?s mass to the precision of the edge of current research (or similar constants) probably are putting in their own value and not relying on a library. That seems like the right thing to do in that case.

2) While a tiny of change of a constant at the most precise level would change a person's calculation from one release to another, they should be checking equivalence to a certain precision, not an exact value when using constants like these.

I would argue for always adopting the most current "trusted" value (where "trusted" can be defined as JPL, IAU, etc.). Changes in a user's output because of changes in constants like these is a reflection of a bad software test, not the library.

Cheers,
Demitri

_________________________________________
Demitri Muna
http://muna.com

Center for Cosmology and AstroParticle Physics
& Department of Astronomy
Le Ohio State University

My Projects:
http://nightlightapp.io
http://trillianverse.org
http://scicoder.org





From ewinter at stsci.edu  Mon Nov 28 11:00:58 2016
From: ewinter at stsci.edu (Eric Winter)
Date: Mon, 28 Nov 2016 16:00:58 +0000
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <A284225C-060A-4D50-AAFE-7A06E53F68AF@gmail.com>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
 <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
 <CAGMHX_0AoiTa-0=V0hfE6hTnhycsbcuhvoHVshzXwReObXwC8w@mail.gmail.com>
 <A284225C-060A-4D50-AAFE-7A06E53F68AF@gmail.com>
Message-ID: <922D6005-163C-4E4B-B275-BFADBCAFDEA9@stsci.edu>

I think the consideration of versioning the constants (not the same as versioning the code) is the right approach. Someone else suggested creating subsections of the package based on the source and year of the constants. I think that?s a good approach. The ?latest? version would be the default, and alternative versions could be made available with the appropriate import statements.

Eic

On 11/28/16, 10:56 AM, "AstroPy on behalf of Demitri Muna" <astropy-bounces at scipy.org on behalf of demitri.muna at gmail.com> wrote:

    Hi,
    
    On Nov 28, 2016, at 10:44 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
    
    > The main problem we are facing in Astropy is that if we update constants from one release to the next, results might then change, which might not be acceptable for some users. Therefore, we need to make sure we have a mechanism for users to import a 'fixed/frozen' version of constants that will not change in future releases of Astropy, and this is why there are delays currently in updating some of the constants.
    
    Taking the devil's advocate position-
    
    1) Those that are worried about things like the Earth?s mass to the precision of the edge of current research (or similar constants) probably are putting in their own value and not relying on a library. That seems like the right thing to do in that case.
    
    2) While a tiny of change of a constant at the most precise level would change a person's calculation from one release to another, they should be checking equivalence to a certain precision, not an exact value when using constants like these.
    
    I would argue for always adopting the most current "trusted" value (where "trusted" can be defined as JPL, IAU, etc.). Changes in a user's output because of changes in constants like these is a reflection of a bad software test, not the library.
    
    Cheers,
    Demitri
    
    _________________________________________
    Demitri Muna
    http://muna.com
    
    Center for Cosmology and AstroParticle Physics
    & Department of Astronomy
    Le Ohio State University
    
    My Projects:
    http://nightlightapp.io
    http://trillianverse.org
    http://scicoder.org
    
    
    
    _______________________________________________
    AstroPy mailing list
    AstroPy at scipy.org
    https://mail.scipy.org/mailman/listinfo/astropy
    


From demitri.muna at gmail.com  Mon Nov 28 11:08:05 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Mon, 28 Nov 2016 11:08:05 -0500
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <922D6005-163C-4E4B-B275-BFADBCAFDEA9@stsci.edu>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
 <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
 <CAGMHX_0AoiTa-0=V0hfE6hTnhycsbcuhvoHVshzXwReObXwC8w@mail.gmail.com>
 <A284225C-060A-4D50-AAFE-7A06E53F68AF@gmail.com>
 <922D6005-163C-4E4B-B275-BFADBCAFDEA9@stsci.edu>
Message-ID: <53F5140B-5F97-4C2D-AC62-E09A6526B1E4@gmail.com>


On Nov 28, 2016, at 11:00 AM, Eric Winter <ewinter at stsci.edu> wrote:

> I think the consideration of versioning the constants (not the same as versioning the code) is the right approach. Someone else suggested creating subsections of the package based on the source and year of the constants. I think that?s a good approach. The ?latest? version would be the default, and alternative versions could be made available with the appropriate import statements.

That sounds like a good solution.

_________________________________________
Demitri Muna
http://muna.com

Center for Cosmology and AstroParticle Physics
& Department of Astronomy
Le Ohio State University

My Projects:
http://nightlightapp.io
http://trillianverse.org
http://scicoder.org





From astropy at liska.ath.cx  Tue Nov 29 03:39:03 2016
From: astropy at liska.ath.cx (Ole Streicher)
Date: Tue, 29 Nov 2016 09:39:03 +0100
Subject: [AstroPy] numpy.arange and quantities
Message-ID: <ytzpolelly0.fsf@news.ole.ath.cx>

Hi,

how can I create a sequence of quantities, when start, end, and step are
given?

The simplest approach doesn't work (astropy 1.2.1):

>>> import numpy
>>> import astropy.units as u
>>> z0 = 0
>>> z1 = 9 * u.km
>>> dz = 100 * u.m
>>> r = numpy.arange(z0, z1, dz)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: setting an array element with a sequence.

Best regards

Ole


From burtscher at strw.leidenuniv.nl  Tue Nov 29 04:07:16 2016
From: burtscher at strw.leidenuniv.nl (Leonard Burtscher)
Date: Tue, 29 Nov 2016 10:07:16 +0100
Subject: [AstroPy] numpy.arange and quantities
In-Reply-To: <ytzpolelly0.fsf@news.ole.ath.cx>
References: <ytzpolelly0.fsf@news.ole.ath.cx>
Message-ID: <FA1DBE96-C381-41EA-BB76-CFA8B20AF5C6@strw.leidenuniv.nl>

Hi Ole,

r=np.arange(0,9,0.1)*u.km

works.

Best,
Leo

> Am 29.11.2016 um 09:39 schrieb Ole Streicher <astropy at liska.ath.cx>:
> 
> Hi,
> 
> how can I create a sequence of quantities, when start, end, and step are
> given?
> 
> The simplest approach doesn't work (astropy 1.2.1):
> 
>>>> import numpy
>>>> import astropy.units as u
>>>> z0 = 0
>>>> z1 = 9 * u.km
>>>> dz = 100 * u.m
>>>> r = numpy.arange(z0, z1, dz)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> ValueError: setting an array element with a sequence.
> 
> Best regards
> 
> Ole
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

--
http://strw.leidenuniv.nl/~burtscher





From astropy at liska.ath.cx  Tue Nov 29 04:16:03 2016
From: astropy at liska.ath.cx (Ole Streicher)
Date: Tue, 29 Nov 2016 10:16:03 +0100
Subject: [AstroPy] numpy.arange and quantities
References: <ytzpolelly0.fsf@news.ole.ath.cx>
 <FA1DBE96-C381-41EA-BB76-CFA8B20AF5C6@strw.leidenuniv.nl>
Message-ID: <ytzlgw2lk8c.fsf@news.ole.ath.cx>

Leonard Burtscher <burtscher at strw.leidenuniv.nl> writes:
> r=np.arange(0,9,0.1)*u.km
>
> works.

Sure. But the quantities are already given. I could convert them to
numbers first (with a random unit), like

np.arange(z0/u.m, z1/u.m, dz/u.m) * u.m

But this looks really ugly.

Cheers

Ole


From burtscher at strw.leidenuniv.nl  Tue Nov 29 04:19:23 2016
From: burtscher at strw.leidenuniv.nl (Leonard Burtscher)
Date: Tue, 29 Nov 2016 10:19:23 +0100
Subject: [AstroPy] numpy.arange and quantities
In-Reply-To: <ytzlgw2lk8c.fsf@news.ole.ath.cx>
References: <ytzpolelly0.fsf@news.ole.ath.cx>
 <FA1DBE96-C381-41EA-BB76-CFA8B20AF5C6@strw.leidenuniv.nl>
 <ytzlgw2lk8c.fsf@news.ole.ath.cx>
Message-ID: <6FA51318-08DC-423F-A7E4-6519EBFF867A@strw.leidenuniv.nl>

OK, I see. Have you seen the discussion here?
https://github.com/astropy/astropy/wiki/Quantity-Arrays

Seems to be a known problem, but I'm don't know if it has been solved.


> Am 29.11.2016 um 10:16 schrieb Ole Streicher <astropy at liska.ath.cx>:
> 
> Leonard Burtscher <burtscher at strw.leidenuniv.nl> writes:
>> r=np.arange(0,9,0.1)*u.km
>> 
>> works.
> 
> Sure. But the quantities are already given. I could convert them to
> numbers first (with a random unit), like
> 
> np.arange(z0/u.m, z1/u.m, dz/u.m) * u.m
> 
> But this looks really ugly.
> 
> Cheers
> 
> Ole
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

--
http://strw.leidenuniv.nl/~burtscher





From deil.christoph at googlemail.com  Tue Nov 29 04:26:01 2016
From: deil.christoph at googlemail.com (Christoph Deil)
Date: Tue, 29 Nov 2016 10:26:01 +0100
Subject: [AstroPy] numpy.arange and quantities
In-Reply-To: <6FA51318-08DC-423F-A7E4-6519EBFF867A@strw.leidenuniv.nl>
References: <ytzpolelly0.fsf@news.ole.ath.cx>
 <FA1DBE96-C381-41EA-BB76-CFA8B20AF5C6@strw.leidenuniv.nl>
 <ytzlgw2lk8c.fsf@news.ole.ath.cx>
 <6FA51318-08DC-423F-A7E4-6519EBFF867A@strw.leidenuniv.nl>
Message-ID: <AB5B4B69-B459-479F-81F8-D52CC6D7C217@googlemail.com>

Hi Ole, Leo,

There?s also a mention of known issues with some numpy functions with Quantity objects here:
http://astropy.readthedocs.io/en/latest/known_issues.html#quantity-issues <http://astropy.readthedocs.io/en/latest/known_issues.html#quantity-issues>
(arange isn?t mentioned specifically).

The workaround is just to do something like this, i.e. call the function with the value array and after put the unit back on:

q_in = <some quantity>
unit = <some fixed unit>
a_out  = np.somefunction(a_in.to(unit).value)
q_out = Quantity(a_out, unit)

I don?t know if the Numpy / Quantity situation will get better over the years, or if it will mostly stay as-is due do backward-compatibility constraints in Numpy.

Christoph

> On 29 Nov 2016, at 10:19, Leonard Burtscher <burtscher at strw.leidenuniv.nl> wrote:
> 
> OK, I see. Have you seen the discussion here?
> https://github.com/astropy/astropy/wiki/Quantity-Arrays
> 
> Seems to be a known problem, but I'm don't know if it has been solved.
> 
> 
>> Am 29.11.2016 um 10:16 schrieb Ole Streicher <astropy at liska.ath.cx>:
>> 
>> Leonard Burtscher <burtscher at strw.leidenuniv.nl> writes:
>>> r=np.arange(0,9,0.1)*u.km
>>> 
>>> works.
>> 
>> Sure. But the quantities are already given. I could convert them to
>> numbers first (with a random unit), like
>> 
>> np.arange(z0/u.m, z1/u.m, dz/u.m) * u.m
>> 
>> But this looks really ugly.
>> 
>> Cheers
>> 
>> Ole
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> --
> http://strw.leidenuniv.nl/~burtscher
> 
> 
> 
> _______________________________________________
> 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/20161129/3211da3d/attachment.html>

From andrej.prsa at guest.arnes.si  Tue Nov 29 07:34:37 2016
From: andrej.prsa at guest.arnes.si (Andrej Prsa)
Date: Tue, 29 Nov 2016 07:34:37 -0500
Subject: [AstroPy] Wrong earth mass in astropy.constants
In-Reply-To: <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
References: <mailman.3.1480334402.15839.astropy@scipy.org>
 <2F8FCD2B-CB2C-47BC-932A-0892144885E8@iucaa.in>
 <2BA33772-98C1-4C0D-AD48-77D9D3D6A6E1@stsci.edu>
 <CA0D5E1F-3DC4-4295-B4BB-D234D58F1273@swarthmore.edu>
Message-ID: <20161129073437.6d379ca8@altair>

> The IAU passed a resolution relatively recently addressing exactly
> this problem, and recommending standard values, while acknowledging
> that best estimates might continue to diverge slightly from these.
> So it seems like these IAU standard values would be a good option to
> consider for use in astropy: 
> 
> https://arxiv.org/abs/1510.07674
> 
> Resolution B3 here:
> 
> https://www.iau.org/static/resolutions/IAU2015_English.pdf

Note that these are /nominal/ values rather than current best
estimates. They are by definition exact and are used as rulers, not as
CBEs. See this for an extended discussion:

	http://adsabs.harvard.edu/abs/2016AJ....152...41P

We override the constants from astropy in phoebe to conform to nominal
units (which is arguably the only suitable set for our work as per the
reference above). Thus, package subsectioning sounds like a good
solution for these issues.

My 2c worth,
Andrej