From ghang.naoc at gmail.com  Wed Jan  1 02:27:20 2014
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Wed, 1 Jan 2014 15:27:20 +0800
Subject: [AstroPy] how to read out the data in hst's psf files?
Message-ID: <CABb23mubbj28w6kqZMyZ6F3W+SFyYn6HpnNMc2sJqxJCx0KO7w@mail.gmail.com>

Hi guys ,
Anybody did that before?
I  mean the files like F450W.pc.psf  and F450W.wfc3.psf .

Happy new year.
hang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140101/f59cb119/attachment.html>

From d.berry at jach.hawaii.edu  Fri Jan  3 06:35:04 2014
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 3 Jan 2014 11:35:04 +0000
Subject: [AstroPy] Ecliptic coordinates in astropy.coordinates?
In-Reply-To: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu>
References: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu>
Message-ID: <CAALafn6gXXJQHoc9LY9tjr6MQQwuJe6=8L0r0-P_7C2n6kfkQA@mail.gmail.com>

pyast (http://dsberry.github.io/starlink/pyast.html) can do
conversions to and from ecliptic.

David

On 31 December 2013 20:58, Leo Singer <lsinger at caltech.edu> wrote:
> Hi,
>
> Is it possible to convert from ICRS to ecliptic coordinates in astropy?
>
> Thanks,
> Leo Singer
> Graduate Student @ LIGO-Caltech
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From aldcroft at head.cfa.harvard.edu  Fri Jan  3 08:39:41 2014
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Fri, 3 Jan 2014 08:39:41 -0500
Subject: [AstroPy] Ecliptic coordinates in astropy.coordinates?
In-Reply-To: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu>
References: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu>
Message-ID: <CAMtEP6yPaP9-A_A57K9c=qapPXHtdaMWLDaJ_znRAk=REFnx6w@mail.gmail.com>

Hi Leo,

Here is the relevant issue:  https://github.com/astropy/astropy/issues/1430.
 Since that topic was active there has been progress on some of the
blockers (arrayification of coordinates in particular), but I don't know if
there has been any direct progress on support for ecliptic.

- Tom


On Tue, Dec 31, 2013 at 3:58 PM, Leo Singer <lsinger at caltech.edu> wrote:

> Hi,
>
> Is it possible to convert from ICRS to ecliptic coordinates in astropy?
>
> Thanks,
> Leo Singer
> Graduate Student @ LIGO-Caltech
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140103/449cb3c1/attachment.html>

From erik.tollerud at gmail.com  Fri Jan  3 23:17:28 2014
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Fri, 3 Jan 2014 23:17:28 -0500
Subject: [AstroPy] Ecliptic coordinates in astropy.coordinates?
In-Reply-To: <CAMtEP6yPaP9-A_A57K9c=qapPXHtdaMWLDaJ_znRAk=REFnx6w@mail.gmail.com>
References: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu>
	<CAMtEP6yPaP9-A_A57K9c=qapPXHtdaMWLDaJ_znRAk=REFnx6w@mail.gmail.com>
Message-ID: <CAARXUwV40T0tFYs9Fi_BTJ=Dr+KSrDdfGjP4ri9CkG3Tnm+m-Q@mail.gmail.com>

To add a bit more: there is a soon-to-come proposal for a change in
coordinates (an APE + an API proposal) that will hopefully make
implementing new coordinate transforms quite a bit easier.

Once that goes through, the next step is to actually implement the
important missing coordinate systems, and ecliptic is certainly among
them.

In the meantime, if you want a pure-python solution, astropysics
(http://pythonhosted.org/Astropysics/) and Kapteyn
(http://www.astro.rug.nl/software/kapteyn/)

On Fri, Jan 3, 2014 at 8:39 AM, Aldcroft, Thomas
<aldcroft at head.cfa.harvard.edu> wrote:
> Hi Leo,
>
> Here is the relevant issue:  https://github.com/astropy/astropy/issues/1430.
> Since that topic was active there has been progress on some of the blockers
> (arrayification of coordinates in particular), but I don't know if there has
> been any direct progress on support for ecliptic.
>
> - Tom
>
>
> On Tue, Dec 31, 2013 at 3:58 PM, Leo Singer <lsinger at caltech.edu> wrote:
>>
>> Hi,
>>
>> Is it possible to convert from ICRS to ecliptic coordinates in astropy?
>>
>> Thanks,
>> Leo Singer
>> Graduate Student @ LIGO-Caltech
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Erik


From abhijithrajan at asu.edu  Mon Jan  6 13:54:39 2014
From: abhijithrajan at asu.edu (Abhijith Rajan)
Date: Mon, 6 Jan 2014 11:54:39 -0700
Subject: [AstroPy] correcting geometric distortion in HST data
Message-ID: <CAHfbfxFqjENbKV_PUrBbeNANEDMrXpD5z=Rm0MZwCUCME3v_RA@mail.gmail.com>

Hi,

Apologies if this question has been answered in the past.

I want to correct for the geometric distortion in some HST/WFC3 data
without using going through the process of using the drizzle software from
STScI. I have written my own code to to up-sample the data where I
interlace the different dither steps to create an image that has twice the
resolution of the original. The purpose was to get the PSF Nyquist (just)
sampled prior to running any other linear transformations. The distortion
coefficients in the header of the original FLT images are for the
undersampled data and I was wondering if I can use them without
modification?

Any help would be extremely valuable.

Thanks
Abhi

-------------------------------------------------------------------------------------------
Abhijith Rajan
PhD Candidate
Arizona State University
School of Earth & Space Exploration
Interdisciplinary Sci & Tech Bldg 4 Rm 542
Tempe, AZ 85287
Tel: (480) 727-2559
Fax: (480) 965-8102
www.abhijithrajan.com
-------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140106/c62e597a/attachment.html>

From rfinn at siena.edu  Thu Jan  9 11:57:49 2014
From: rfinn at siena.edu (Finn, Rose)
Date: Thu, 9 Jan 2014 11:57:49 -0500
Subject: [AstroPy] help with writing a boolean column with astropy.io.Table
Message-ID: <CAF=o2jH2Wuwx_SzRKT40Mn7=igfRUZKe0pQDpQ_4LR2ArJ7ALA@mail.gmail.com>

Hi,

I am trying to write a fits table with astropy.io.Table and am having
trouble with a boolean array.  Basically, all the values turn out to be
false, regardless of what the values are in the input array.  I have
included an example below - any help would be appreciated!  I am trying to
avoid writing the table with astropy.io.fits because it is cumbersome.
 Everything works fine with floating point arrays.

Thanks,
Rose


from astropy.io import Column

from astropy.table import Table

from astropy.table import Column

newcol=Column(data=np.ones(10),name='test',dtype='bool')

dt=Table()

dt.add_column(newcol)

dt.write('test.fits')

dat=dt.read('test.fits')

In [*48*]: dat['test']

Out[*48*]:

<Column name='test' unit=None format=None description=None>

array([False, False, False, False, False, False, False, False, False,
False], dtype=bool)


In [*45*]: newcol

Out[*45*]:

<Column name='test' unit=None format=None description=None>

array([ True,  True,  True,  True,  True,  True,  True,  True,  True,
True], dtype=bool)


-- 
Rose A. Finn
Department of Physics & Astronomy
Siena College
Loudonville, NY  12211
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140109/954096f6/attachment.html>

From aldcroft at head.cfa.harvard.edu  Thu Jan  9 12:44:41 2014
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Thu, 9 Jan 2014 12:44:41 -0500
Subject: [AstroPy] help with writing a boolean column with
	astropy.io.Table
In-Reply-To: <CAF=o2jH2Wuwx_SzRKT40Mn7=igfRUZKe0pQDpQ_4LR2ArJ7ALA@mail.gmail.com>
References: <CAF=o2jH2Wuwx_SzRKT40Mn7=igfRUZKe0pQDpQ_4LR2ArJ7ALA@mail.gmail.com>
Message-ID: <CAMtEP6y6ae1eHxNey3va+_mPjxV-A5dVYSX-5NG256j8k08_qQ@mail.gmail.com>

Hi Rose,

I'm able to reproduce this and I've confirmed that the test.fits file
output seems to be correct (by reading with an independent FITS reader).
 This would appear to be a bug in FITS reading, though it's just a little
surprising that something so basic as reading a FITS file with a boolean
column could have a bug like this.

I'm opening an astropy github issue on this now.

- Tom


On Thu, Jan 9, 2014 at 11:57 AM, Finn, Rose <rfinn at siena.edu> wrote:

> Hi,
>
> I am trying to write a fits table with astropy.io.Table and am having
> trouble with a boolean array.  Basically, all the values turn out to be
> false, regardless of what the values are in the input array.  I have
> included an example below - any help would be appreciated!  I am trying to
> avoid writing the table with astropy.io.fits because it is cumbersome.
>  Everything works fine with floating point arrays.
>
> Thanks,
> Rose
>
>
> from astropy.io import Column
>
> from astropy.table import Table
>
> from astropy.table import Column
>
> newcol=Column(data=np.ones(10),name='test',dtype='bool')
>
> dt=Table()
>
> dt.add_column(newcol)
>
> dt.write('test.fits')
>
> dat=dt.read('test.fits')
>
> In [*48*]: dat['test']
>
> Out[*48*]:
>
> <Column name='test' unit=None format=None description=None>
>
> array([False, False, False, False, False, False, False, False, False,
> False], dtype=bool)
>
>
> In [*45*]: newcol
>
> Out[*45*]:
>
> <Column name='test' unit=None format=None description=None>
>
> array([ True,  True,  True,  True,  True,  True,  True,  True,  True,
> True], dtype=bool)
>
>
> --
> Rose A. Finn
> Department of Physics & Astronomy
> Siena College
> Loudonville, NY  12211
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140109/c705fb50/attachment.html>

From rfinn at siena.edu  Thu Jan  9 13:01:21 2014
From: rfinn at siena.edu (Rose Finn)
Date: Thu, 9 Jan 2014 13:01:21 -0500
Subject: [AstroPy] help with writing a boolean column with
	astropy.io.Table
In-Reply-To: <CAMtEP6y6ae1eHxNey3va+_mPjxV-A5dVYSX-5NG256j8k08_qQ@mail.gmail.com>
References: <CAF=o2jH2Wuwx_SzRKT40Mn7=igfRUZKe0pQDpQ_4LR2ArJ7ALA@mail.gmail.com>
	<CAMtEP6y6ae1eHxNey3va+_mPjxV-A5dVYSX-5NG256j8k08_qQ@mail.gmail.com>
Message-ID: <CAL9NRkTW14oVBMESm6uiO=-nj4mLpSPg7QhJB_bjYvJxZT9dng@mail.gmail.com>

Thanks Tom, for your quick reply!  In case this is useful, when I open
test.fits in topcat (v3.9), the column data is not imported correctly -
there are no values under the test column, nor the typical buttons that
appear with other boolean columns.  Topcat does know it is a boolean column
with format code L.  So this seems to indicate that there is something
non-standard in how the column is written.

Take care,
Rose


On Thu, Jan 9, 2014 at 12:44 PM, Aldcroft, Thomas <
aldcroft at head.cfa.harvard.edu> wrote:

> Hi Rose,
>
> I'm able to reproduce this and I've confirmed that the test.fits file
> output seems to be correct (by reading with an independent FITS reader).
>  This would appear to be a bug in FITS reading, though it's just a little
> surprising that something so basic as reading a FITS file with a boolean
> column could have a bug like this.
>
> I'm opening an astropy github issue on this now.
>
> - Tom
>
>
> On Thu, Jan 9, 2014 at 11:57 AM, Finn, Rose <rfinn at siena.edu> wrote:
>
>> Hi,
>>
>> I am trying to write a fits table with astropy.io.Table and am having
>> trouble with a boolean array.  Basically, all the values turn out to be
>> false, regardless of what the values are in the input array.  I have
>> included an example below - any help would be appreciated!  I am trying to
>> avoid writing the table with astropy.io.fits because it is cumbersome.
>>  Everything works fine with floating point arrays.
>>
>> Thanks,
>> Rose
>>
>>
>> from astropy.io import Column
>>
>> from astropy.table import Table
>>
>> from astropy.table import Column
>>
>> newcol=Column(data=np.ones(10),name='test',dtype='bool')
>>
>> dt=Table()
>>
>> dt.add_column(newcol)
>>
>> dt.write('test.fits')
>>
>> dat=dt.read('test.fits')
>>
>> In [*48*]: dat['test']
>>
>> Out[*48*]:
>>
>> <Column name='test' unit=None format=None description=None>
>>
>> array([False, False, False, False, False, False, False, False, False,
>> False], dtype=bool)
>>
>>
>> In [*45*]: newcol
>>
>> Out[*45*]:
>>
>> <Column name='test' unit=None format=None description=None>
>>
>> array([ True,  True,  True,  True,  True,  True,  True,  True,  True,
>> True], dtype=bool)
>>
>>
>> --
>> Rose A. Finn
>> Department of Physics & Astronomy
>> Siena College
>> Loudonville, NY  12211
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Rose A. Finn, PhD
Department of Physics & Astronomy
Siena College
Loudonville, NY
(518) 782-6764
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140109/73084b5c/attachment.html>

From beaumont at hawaii.edu  Mon Jan 13 13:58:40 2014
From: beaumont at hawaii.edu (Chris Beaumont)
Date: Mon, 13 Jan 2014 13:58:40 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
Message-ID: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>

Hi,

Given a WCS object, I'd like to know which pixel and world axes are
independent of each other. For example:

 * X/Y are generally NOT orthogonal to RA or DEC in the tan projection (to
compute RA or DEC, you need both X and Y)
 * X is independent to DEC in cartesian projection, UNLESS something like
cd2_1 or crota are nonzero
* the velocity axis in a spectral data cube is usually orthogonal to the
spatial axes (you can translate between Z and V without knowledge of X and
Y).

I'm sure there are lots of corner cases here. Is there any way I can
introspect a WCS object to generally determine if a given world and pixel
axis are independent of each other?

Thanks,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140113/b95f075e/attachment.html>

From thomas.robitaille at gmail.com  Mon Jan 13 14:11:58 2014
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 13 Jan 2014 20:11:58 +0100
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
Message-ID: <CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>

I have the same question. Just brainstorming here since I don't know
the final answer, but I guess there are (as you said) two things going
on here - one being the fact that certain projections can couple
coordinates (such as RA/Dec) in some projections (e.g. TAN), and the
other being rotations of coordinate systems relative to the pixel
axes. For the latter, I *guess* one could look at the non-diagonal
elements of the PC matrix:

    >>> w = WCS(...)
    >>> w.wcs.get_pc()
    array([[ 1.,  0.,  0.],
           [ 0.,  1.,  0.],
           [ 0.,  0.,  1.]])

in the above case, there is no rotation. But for axes 1 and 2 the
projection is not -CAR:

    In [9]: w.wcs.ctype
    Out[9]: ['RA---SFL', 'DEC--SFL', 'VOPT']

so axes 1 and 2 are linked (but axis 3 is independent). Maybe the
solution to find if an axes is independent of the others is:

- check that the non-diagonal elements for that axis are zero
- check that the projection for that axis is not a spherical
projection, unless it's -CAR in which case it's also fine

What do others think? Is this robust? Or are there projections that
are not the usual spherical projections that might link axes? Does one
need to also check that there are no distortion coefficients in
addition to the above criteria?

Cheers,
Tom


On 13 January 2014 19:58, Chris Beaumont <beaumont at hawaii.edu> wrote:
> Hi,
>
> Given a WCS object, I'd like to know which pixel and world axes are
> independent of each other. For example:
>
>  * X/Y are generally NOT orthogonal to RA or DEC in the tan projection (to
> compute RA or DEC, you need both X and Y)
>  * X is independent to DEC in cartesian projection, UNLESS something like
> cd2_1 or crota are nonzero
> * the velocity axis in a spectral data cube is usually orthogonal to the
> spatial axes (you can translate between Z and V without knowledge of X and
> Y).
>
> I'm sure there are lots of corner cases here. Is there any way I can
> introspect a WCS object to generally determine if a given world and pixel
> axis are independent of each other?
>
> Thanks,
> Chris
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From hodge at stsci.edu  Mon Jan 13 14:18:56 2014
From: hodge at stsci.edu (Phil Hodge)
Date: Mon, 13 Jan 2014 14:18:56 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
Message-ID: <52D43C20.7060907@stsci.edu>

Consider the case of celestial coordinates with the center of the image 
close to either the north or south pole, but with the declination axis 
aligned with the image Y axis.  You will need both right ascension and 
declination to calculate an X coordinate in the image, or both X and Y 
to calculate either right ascension or declination.  So you can't just 
look at the off-diagonal elements of the PC matrix.

You could take pixel coordinates [1, 0, ...], [0, 1, ...], etc., and 
transform each of them to world coordinates.  If the world coordinates 
have non-zero elements in more than one world coordinate vector, the 
axes are not independent.

Phil

On 01/13/2014 02:11 PM, Thomas Robitaille wrote:
> I have the same question. Just brainstorming here since I don't know
> the final answer, but I guess there are (as you said) two things going
> on here - one being the fact that certain projections can couple
> coordinates (such as RA/Dec) in some projections (e.g. TAN), and the
> other being rotations of coordinate systems relative to the pixel
> axes. For the latter, I *guess* one could look at the non-diagonal
> elements of the PC matrix:
>
>      >>> w = WCS(...)
>      >>> w.wcs.get_pc()
>      array([[ 1.,  0.,  0.],
>             [ 0.,  1.,  0.],
>             [ 0.,  0.,  1.]])
>
> in the above case, there is no rotation. But for axes 1 and 2 the
> projection is not -CAR:
>
>      In [9]: w.wcs.ctype
>      Out[9]: ['RA---SFL', 'DEC--SFL', 'VOPT']
>
> so axes 1 and 2 are linked (but axis 3 is independent). Maybe the
> solution to find if an axes is independent of the others is:
>
> - check that the non-diagonal elements for that axis are zero
> - check that the projection for that axis is not a spherical
> projection, unless it's -CAR in which case it's also fine
>
> What do others think? Is this robust? Or are there projections that
> are not the usual spherical projections that might link axes? Does one
> need to also check that there are no distortion coefficients in
> addition to the above criteria?
>
> Cheers,
> Tom
>
>
> On 13 January 2014 19:58, Chris Beaumont <beaumont at hawaii.edu> wrote:
>> Hi,
>>
>> Given a WCS object, I'd like to know which pixel and world axes are
>> independent of each other. For example:
>>
>>   * X/Y are generally NOT orthogonal to RA or DEC in the tan projection (to
>> compute RA or DEC, you need both X and Y)
>>   * X is independent to DEC in cartesian projection, UNLESS something like
>> cd2_1 or crota are nonzero
>> * the velocity axis in a spectral data cube is usually orthogonal to the
>> spatial axes (you can translate between Z and V without knowledge of X and
>> Y).
>>
>> I'm sure there are lots of corner cases here. Is there any way I can
>> introspect a WCS object to generally determine if a given world and pixel
>> axis are independent of each other?
>>
>> Thanks,
>> Chris
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From stsci.perry at gmail.com  Mon Jan 13 14:24:10 2014
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 13 Jan 2014 14:24:10 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
Message-ID: <F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>


On Jan 13, 2014, at 2:11 PM, Thomas Robitaille wrote:

> I have the same question. Just brainstorming here since I don't know
> the final answer, but I guess there are (as you said) two things going
> on here - one being the fact that certain projections can couple
> coordinates (such as RA/Dec) in some projections (e.g. TAN), and the
> other being rotations of coordinate systems relative to the pixel
> axes. For the latter, I *guess* one could look at the non-diagonal
> elements of the PC matrix:
> 
>>>> w = WCS(...)
>>>> w.wcs.get_pc()
>    array([[ 1.,  0.,  0.],
>           [ 0.,  1.,  0.],
>           [ 0.,  0.,  1.]])
> 
> in the above case, there is no rotation. But for axes 1 and 2 the
> projection is not -CAR:
> 
>    In [9]: w.wcs.ctype
>    Out[9]: ['RA---SFL', 'DEC--SFL', 'VOPT']
> 
> so axes 1 and 2 are linked (but axis 3 is independent). Maybe the
> solution to find if an axes is independent of the others is:
> 
> - check that the non-diagonal elements for that axis are zero
> - check that the projection for that axis is not a spherical
> projection, unless it's -CAR in which case it's also fine
> 
> What do others think? Is this robust? Or are there projections that
> are not the usual spherical projections that might link axes? Does one
> need to also check that there are no distortion coefficients in
> addition to the above criteria?

No, it is not robust. Phil basically explains why. If the WCS involves expressions that use more than one axis, there presumably is coupling between more than one axis. Many of the intrinsic projections have intrinsic coupling (e.g. TAN).


Perry



From stsci.perry at gmail.com  Mon Jan 13 14:26:43 2014
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 13 Jan 2014 14:26:43 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <52D43C20.7060907@stsci.edu>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<52D43C20.7060907@stsci.edu>
Message-ID: <5FACA733-CD75-4303-82A5-B5B1EC2AA392@gmail.com>


On Jan 13, 2014, at 2:18 PM, Phil Hodge wrote:

> Consider the case of celestial coordinates with the center of the image 
> close to either the north or south pole, but with the declination axis 
> aligned with the image Y axis.  You will need both right ascension and 
> declination to calculate an X coordinate in the image, or both X and Y 
> to calculate either right ascension or declination.  So you can't just 
> look at the off-diagonal elements of the PC matrix.
> 
> You could take pixel coordinates [1, 0, ...], [0, 1, ...], etc., and 
> transform each of them to world coordinates.  If the world coordinates 
> have non-zero elements in more than one world coordinate vector, the 
> axes are not independent.
> 
> Phil
> 
But just because one set of pixels doesn't show this, doesn't mean that another won't either (e.g., if I change only the nth coordinate, does that only change one output coordinate), so I don't think this is sufficient to show independence (but I'm not sure I understand your example).

Perry



From hodge at stsci.edu  Mon Jan 13 14:37:08 2014
From: hodge at stsci.edu (Phil Hodge)
Date: Mon, 13 Jan 2014 14:37:08 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <5FACA733-CD75-4303-82A5-B5B1EC2AA392@gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<52D43C20.7060907@stsci.edu>
	<5FACA733-CD75-4303-82A5-B5B1EC2AA392@gmail.com>
Message-ID: <52D44064.3050102@stsci.edu>

On 01/13/2014 02:26 PM, Perry Greenfield wrote:
> But just because one set of pixels doesn't show this, doesn't mean that another won't either (e.g., if I change only the nth coordinate, does that only change one output coordinate), so I don't think this is sufficient to show independence (but I'm not sure I understand your example).

I didn't express it well.  I meant that you could take a one-pixel step 
along each axis in pixel space, and see if only the corresponding world 
coordinate changed.  For an N-dimensional pixel space, that would be N + 
1 transformations to world coordinates (some point in the image, plus 
one pixel adjacent to that point along each axis).  But as you said, 
this would have to be checked at multiple points in the image to have 
confidence that the axes were independent.

Phil


From thomas.robitaille at gmail.com  Mon Jan 13 14:46:24 2014
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 13 Jan 2014 20:46:24 +0100
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
Message-ID: <CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>

Hi Phil and Perry,

On 13 January 2014 20:24, Perry Greenfield <stsci.perry at gmail.com> wrote:
>
> On Jan 13, 2014, at 2:11 PM, Thomas Robitaille wrote:
>
>> I have the same question. Just brainstorming here since I don't know
>> the final answer, but I guess there are (as you said) two things going
>> on here - one being the fact that certain projections can couple
>> coordinates (such as RA/Dec) in some projections (e.g. TAN), and the
>> other being rotations of coordinate systems relative to the pixel
>> axes. For the latter, I *guess* one could look at the non-diagonal
>> elements of the PC matrix:
>>
>>>>> w = WCS(...)
>>>>> w.wcs.get_pc()
>>    array([[ 1.,  0.,  0.],
>>           [ 0.,  1.,  0.],
>>           [ 0.,  0.,  1.]])
>>
>> in the above case, there is no rotation. But for axes 1 and 2 the
>> projection is not -CAR:
>>
>>    In [9]: w.wcs.ctype
>>    Out[9]: ['RA---SFL', 'DEC--SFL', 'VOPT']
>>
>> so axes 1 and 2 are linked (but axis 3 is independent). Maybe the
>> solution to find if an axes is independent of the others is:
>>
>> - check that the non-diagonal elements for that axis are zero
>> - check that the projection for that axis is not a spherical
>> projection, unless it's -CAR in which case it's also fine
>>
>> What do others think? Is this robust? Or are there projections that
>> are not the usual spherical projections that might link axes? Does one
>> need to also check that there are no distortion coefficients in
>> addition to the above criteria?
>
> No, it is not robust. Phil basically explains why. If the WCS involves expressions that use more than one axis, there presumably is coupling between more than one axis. Many of the intrinsic projections have intrinsic coupling (e.g. TAN).

Just to clarify, I think we are agreeing here - I mentioned:

"- check that the projection for that axis is not a spherical
projection, unless it's -CAR in which case it's also fine"

In the example you and Phil gave, if the non-diagonal elements are
zero but the projection is TAN, this violates the rule above. My point
was that if any of the the diagonal elements are non-zero, or if the
projection is one of the projections of a sphere, i.e. any projections
from paper 2, (except CAR), then this means the axes are coupled, but
should one be ok if all non-diagonal elements are zero *and* the
projection is CAR or a projection that is not one of the spherical
projections (but could be e.g. a spectral projection convention). Is
this correct?

Cheers,
Tom

>
>
> Perry
>


From hodge at stsci.edu  Mon Jan 13 14:56:10 2014
From: hodge at stsci.edu (Phil Hodge)
Date: Mon, 13 Jan 2014 14:56:10 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
	<CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
Message-ID: <52D444DA.3020301@stsci.edu>

Tom,

On 01/13/2014 02:46 PM, Thomas Robitaille wrote:
> Just to clarify, I think we are agreeing here - I mentioned:
>
> "- check that the projection for that axis is not a spherical
> projection, unless it's -CAR in which case it's also fine"
>
> In the example you and Phil gave, if the non-diagonal elements are
> zero but the projection is TAN, this violates the rule above. My point
> was that if any of the the diagonal elements are non-zero, or if the
> projection is one of the projections of a sphere, i.e. any projections
> from paper 2, (except CAR), then this means the axes are coupled, but
> should one be ok if all non-diagonal elements are zero*and*  the
> projection is CAR or a projection that is not one of the spherical
> projections (but could be e.g. a spectral projection convention). Is
> this correct?

Well, the Mercator projection should be OK, as spherical projections go, 
and there are others.  But if there are distortions in addition to any 
projection, that would make it pretty hard to determine whether the axes 
were independent just by looking at the WCS attributes.

Phil


From stsci.perry at gmail.com  Mon Jan 13 15:04:16 2014
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 13 Jan 2014 15:04:16 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <52D444DA.3020301@stsci.edu>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
	<CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
	<52D444DA.3020301@stsci.edu>
Message-ID: <5A5321BE-92BF-496E-BA09-13FA791FB06F@gmail.com>


On Jan 13, 2014, at 2:56 PM, Phil Hodge wrote:

> Tom,
> 
> On 01/13/2014 02:46 PM, Thomas Robitaille wrote:
>> Just to clarify, I think we are agreeing here - I mentioned:
>> 
>> "- check that the projection for that axis is not a spherical
>> projection, unless it's -CAR in which case it's also fine"
>> 
>> In the example you and Phil gave, if the non-diagonal elements are
>> zero but the projection is TAN, this violates the rule above. My point
>> was that if any of the the diagonal elements are non-zero, or if the
>> projection is one of the projections of a sphere, i.e. any projections
>> from paper 2, (except CAR), then this means the axes are coupled, but
>> should one be ok if all non-diagonal elements are zero*and*  the
>> projection is CAR or a projection that is not one of the spherical
>> projections (but could be e.g. a spectral projection convention). Is
>> this correct?
> 
> Well, the Mercator projection should be OK, as spherical projections go, 
> and there are others.  But if there are distortions in addition to any 
> projection, that would make it pretty hard to determine whether the axes 
> were independent just by looking at the WCS attributes.
> 
> Phil

Right. But I think we all essentially agree. It's the details of the specific cases that takes all the work. For the most part, one could practically assume that spatial coordinate are coupled given the arbitrary orientation of the detectors and that we are mapping to the sky. The number of real uses of an aligned separable spatial system is so rare as to make it a waste of time to handle specially.

Perry




From beaumont at hawaii.edu  Mon Jan 13 15:20:30 2014
From: beaumont at hawaii.edu (Chris Beaumont)
Date: Mon, 13 Jan 2014 15:20:30 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <5A5321BE-92BF-496E-BA09-13FA791FB06F@gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
	<CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
	<52D444DA.3020301@stsci.edu>
	<5A5321BE-92BF-496E-BA09-13FA791FB06F@gmail.com>
Message-ID: <CAFP9tKraZWi9PkU7huo0uDAC+dNN+98ERoQAjvBWECHNeJog1A@mail.gmail.com>

I'd be willing to accept a method which returns either "definitely
independent" or "might be dependent". I have a much lower tolerance for
accidentally saying two axes are independent if they're not.

Tom: is there a definitive property (analogous to w.wcs.get_pc) that
indicates whether distortions are present, regardless of how they might be
encoded in a header?

Regarding Perry's last point: This is probably true for images right from a
detector, but less often true for images that have been mosaiced in some
way. Likewise, the spectral axis in spectral image cubes is often (but not
always) independent of the spatial axis.


On Mon, Jan 13, 2014 at 3:04 PM, Perry Greenfield <stsci.perry at gmail.com>wrote:

>
> On Jan 13, 2014, at 2:56 PM, Phil Hodge wrote:
>
> > Tom,
> >
> > On 01/13/2014 02:46 PM, Thomas Robitaille wrote:
> >> Just to clarify, I think we are agreeing here - I mentioned:
> >>
> >> "- check that the projection for that axis is not a spherical
> >> projection, unless it's -CAR in which case it's also fine"
> >>
> >> In the example you and Phil gave, if the non-diagonal elements are
> >> zero but the projection is TAN, this violates the rule above. My point
> >> was that if any of the the diagonal elements are non-zero, or if the
> >> projection is one of the projections of a sphere, i.e. any projections
> >> from paper 2, (except CAR), then this means the axes are coupled, but
> >> should one be ok if all non-diagonal elements are zero*and*  the
> >> projection is CAR or a projection that is not one of the spherical
> >> projections (but could be e.g. a spectral projection convention). Is
> >> this correct?
> >
> > Well, the Mercator projection should be OK, as spherical projections go,
> > and there are others.  But if there are distortions in addition to any
> > projection, that would make it pretty hard to determine whether the axes
> > were independent just by looking at the WCS attributes.
> >
> > Phil
>
> Right. But I think we all essentially agree. It's the details of the
> specific cases that takes all the work. For the most part, one could
> practically assume that spatial coordinate are coupled given the arbitrary
> orientation of the detectors and that we are mapping to the sky. The number
> of real uses of an aligned separable spatial system is so rare as to make
> it a waste of time to handle specially.
>
> Perry
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140113/15d0a11c/attachment.html>

From d.berry at jach.hawaii.edu  Tue Jan 14 02:47:27 2014
From: d.berry at jach.hawaii.edu (David Berry)
Date: Tue, 14 Jan 2014 07:47:27 +0000
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAFP9tKraZWi9PkU7huo0uDAC+dNN+98ERoQAjvBWECHNeJog1A@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
	<CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
	<52D444DA.3020301@stsci.edu>
	<5A5321BE-92BF-496E-BA09-13FA791FB06F@gmail.com>
	<CAFP9tKraZWi9PkU7huo0uDAC+dNN+98ERoQAjvBWECHNeJog1A@mail.gmail.com>
Message-ID: <CAALafn7zkTC4ThHEy2cS=X_dNZEDiVis9nNHRPEtQ8ovDNNOBw@mail.gmail.com>

Generalising a bit to an arbitrary mapping from an input N-dimensional
coordinate system to an output M-dimensional coordinate system, I
think the two issues here are:

1) Can the mapping be split into two or more mappings applied in
parallel. This would usually (although not necessarily always) be the
case for instance for a mapping from 3D pixel coordinates to a
(ra,dec,freq) cube - the mapping could be split into two mappings, a
2D mapping for the spatial axes and an independent 1D mapping for the
frequency axis.

2) If you move the input position a small distance along each input
axis in turn, are the corresponding increments in output position
parallel to the output axes?

>From experience with AST, having a method that will analyse a mapping
into independent parallel mappings (case 1) above)  is a very useful
tool. Issue 2) is less useful because it only tells you about the
properties of the mapping at the specific point at which you do the
test. There is no a priori reason why doing the test at a different
point may not give you different answers. But if you really want to do
this test, it's not hard to code up given a way of transforming
arbitrary points.

Regarding 1), which is much harder to code, AST has the astMapSplit
method - see http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node331.html

The caller specifies the indicies of one or more input axes and
astMapSplit attempt to find a mapping from the selected inputs to a
subset of the available outputs, where each output depends only on the
selected inputs. If the selected inputs do not form an independent
subset, then astMapSplit  returns a null mapping.

Each subclass of mapping provides its own implementation of this
method. So for instance the MatrixMap class knows how and when a
matrix can be split into two independent matrices, and the WcsMap (a
class of spherical projections)   knows that no spherical projection
can be split. Crucially, the CmpMap class (a compound mapping that
joins other mappings together in series or parallel) provides an
implementation of astMapSplit that knows how to apply astMapSplit to
its component mappings and combine the results.

David

On 13 January 2014 20:20, Chris Beaumont <beaumont at hawaii.edu> wrote:
> I'd be willing to accept a method which returns either "definitely
> independent" or "might be dependent". I have a much lower tolerance for
> accidentally saying two axes are independent if they're not.
>
> Tom: is there a definitive property (analogous to w.wcs.get_pc) that
> indicates whether distortions are present, regardless of how they might be
> encoded in a header?
>
> Regarding Perry's last point: This is probably true for images right from a
> detector, but less often true for images that have been mosaiced in some
> way. Likewise, the spectral axis in spectral image cubes is often (but not
> always) independent of the spatial axis.
>
>
> On Mon, Jan 13, 2014 at 3:04 PM, Perry Greenfield <stsci.perry at gmail.com>
> wrote:
>>
>>
>> On Jan 13, 2014, at 2:56 PM, Phil Hodge wrote:
>>
>> > Tom,
>> >
>> > On 01/13/2014 02:46 PM, Thomas Robitaille wrote:
>> >> Just to clarify, I think we are agreeing here - I mentioned:
>> >>
>> >> "- check that the projection for that axis is not a spherical
>> >> projection, unless it's -CAR in which case it's also fine"
>> >>
>> >> In the example you and Phil gave, if the non-diagonal elements are
>> >> zero but the projection is TAN, this violates the rule above. My point
>> >> was that if any of the the diagonal elements are non-zero, or if the
>> >> projection is one of the projections of a sphere, i.e. any projections
>> >> from paper 2, (except CAR), then this means the axes are coupled, but
>> >> should one be ok if all non-diagonal elements are zero*and*  the
>> >> projection is CAR or a projection that is not one of the spherical
>> >> projections (but could be e.g. a spectral projection convention). Is
>> >> this correct?
>> >
>> > Well, the Mercator projection should be OK, as spherical projections go,
>> > and there are others.  But if there are distortions in addition to any
>> > projection, that would make it pretty hard to determine whether the axes
>> > were independent just by looking at the WCS attributes.
>> >
>> > Phil
>>
>> Right. But I think we all essentially agree. It's the details of the
>> specific cases that takes all the work. For the most part, one could
>> practically assume that spatial coordinate are coupled given the arbitrary
>> orientation of the detectors and that we are mapping to the sky. The number
>> of real uses of an aligned separable spatial system is so rare as to make it
>> a waste of time to handle specially.
>>
>> Perry
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From beaumont at hawaii.edu  Tue Jan 14 08:43:59 2014
From: beaumont at hawaii.edu (Chris Beaumont)
Date: Tue, 14 Jan 2014 08:43:59 -0500
Subject: [AstroPy] Determining when world and pixel axes are independent
In-Reply-To: <CAALafn7zkTC4ThHEy2cS=X_dNZEDiVis9nNHRPEtQ8ovDNNOBw@mail.gmail.com>
References: <CAFP9tKoZp0VtQbrxY5dAPPobEjnx=dcy_UJFeFdkODyRWPdfbA@mail.gmail.com>
	<CAGMHX_3QCNxtqi3ANWOV_5MgpmaKWnhZbNZzNaE2h7vnx3Wkyg@mail.gmail.com>
	<F60B5718-0429-41EA-9FB2-35DBC62C115B@gmail.com>
	<CAGMHX_2Pnh7fcTdeyd_Y0ahBii+M8A_nQDWdU5oEdDddxnOC=A@mail.gmail.com>
	<52D444DA.3020301@stsci.edu>
	<5A5321BE-92BF-496E-BA09-13FA791FB06F@gmail.com>
	<CAFP9tKraZWi9PkU7huo0uDAC+dNN+98ERoQAjvBWECHNeJog1A@mail.gmail.com>
	<CAALafn7zkTC4ThHEy2cS=X_dNZEDiVis9nNHRPEtQ8ovDNNOBw@mail.gmail.com>
Message-ID: <CAFP9tKoyUWq78noa197ekvh2OGMytrK7O03yNbSZvSne1vvMkg@mail.gmail.com>

Hi David,

Thanks, your first point is precisely the use case I'm interested in. I
will take a look at how AST accomplishes this (alas, I need an
implementation that uses astropy WCS objects)

Cheers,
Chris


On Tue, Jan 14, 2014 at 2:47 AM, David Berry <d.berry at jach.hawaii.edu>wrote:

> Generalising a bit to an arbitrary mapping from an input N-dimensional
> coordinate system to an output M-dimensional coordinate system, I
> think the two issues here are:
>
> 1) Can the mapping be split into two or more mappings applied in
> parallel. This would usually (although not necessarily always) be the
> case for instance for a mapping from 3D pixel coordinates to a
> (ra,dec,freq) cube - the mapping could be split into two mappings, a
> 2D mapping for the spatial axes and an independent 1D mapping for the
> frequency axis.
>
> 2) If you move the input position a small distance along each input
> axis in turn, are the corresponding increments in output position
> parallel to the output axes?
>
> From experience with AST, having a method that will analyse a mapping
> into independent parallel mappings (case 1) above)  is a very useful
> tool. Issue 2) is less useful because it only tells you about the
> properties of the mapping at the specific point at which you do the
> test. There is no a priori reason why doing the test at a different
> point may not give you different answers. But if you really want to do
> this test, it's not hard to code up given a way of transforming
> arbitrary points.
>
> Regarding 1), which is much harder to code, AST has the astMapSplit
> method - see
> http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node331.html
>
> The caller specifies the indicies of one or more input axes and
> astMapSplit attempt to find a mapping from the selected inputs to a
> subset of the available outputs, where each output depends only on the
> selected inputs. If the selected inputs do not form an independent
> subset, then astMapSplit  returns a null mapping.
>
> Each subclass of mapping provides its own implementation of this
> method. So for instance the MatrixMap class knows how and when a
> matrix can be split into two independent matrices, and the WcsMap (a
> class of spherical projections)   knows that no spherical projection
> can be split. Crucially, the CmpMap class (a compound mapping that
> joins other mappings together in series or parallel) provides an
> implementation of astMapSplit that knows how to apply astMapSplit to
> its component mappings and combine the results.
>
> David
>
> On 13 January 2014 20:20, Chris Beaumont <beaumont at hawaii.edu> wrote:
> > I'd be willing to accept a method which returns either "definitely
> > independent" or "might be dependent". I have a much lower tolerance for
> > accidentally saying two axes are independent if they're not.
> >
> > Tom: is there a definitive property (analogous to w.wcs.get_pc) that
> > indicates whether distortions are present, regardless of how they might
> be
> > encoded in a header?
> >
> > Regarding Perry's last point: This is probably true for images right
> from a
> > detector, but less often true for images that have been mosaiced in some
> > way. Likewise, the spectral axis in spectral image cubes is often (but
> not
> > always) independent of the spatial axis.
> >
> >
> > On Mon, Jan 13, 2014 at 3:04 PM, Perry Greenfield <stsci.perry at gmail.com
> >
> > wrote:
> >>
> >>
> >> On Jan 13, 2014, at 2:56 PM, Phil Hodge wrote:
> >>
> >> > Tom,
> >> >
> >> > On 01/13/2014 02:46 PM, Thomas Robitaille wrote:
> >> >> Just to clarify, I think we are agreeing here - I mentioned:
> >> >>
> >> >> "- check that the projection for that axis is not a spherical
> >> >> projection, unless it's -CAR in which case it's also fine"
> >> >>
> >> >> In the example you and Phil gave, if the non-diagonal elements are
> >> >> zero but the projection is TAN, this violates the rule above. My
> point
> >> >> was that if any of the the diagonal elements are non-zero, or if the
> >> >> projection is one of the projections of a sphere, i.e. any
> projections
> >> >> from paper 2, (except CAR), then this means the axes are coupled, but
> >> >> should one be ok if all non-diagonal elements are zero*and*  the
> >> >> projection is CAR or a projection that is not one of the spherical
> >> >> projections (but could be e.g. a spectral projection convention). Is
> >> >> this correct?
> >> >
> >> > Well, the Mercator projection should be OK, as spherical projections
> go,
> >> > and there are others.  But if there are distortions in addition to any
> >> > projection, that would make it pretty hard to determine whether the
> axes
> >> > were independent just by looking at the WCS attributes.
> >> >
> >> > Phil
> >>
> >> Right. But I think we all essentially agree. It's the details of the
> >> specific cases that takes all the work. For the most part, one could
> >> practically assume that spatial coordinate are coupled given the
> arbitrary
> >> orientation of the detectors and that we are mapping to the sky. The
> number
> >> of real uses of an aligned separable spatial system is so rare as to
> make it
> >> a waste of time to handle specially.
> >>
> >> Perry
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > --
> > ************************************
> > Chris Beaumont
> > Graduate Student
> > Institute for Astronomy
> > University of Hawaii at Manoa
> > 2680 Woodlawn Drive
> > Honolulu, HI 96822
> > www.ifa.hawaii.edu/~beaumont
> > ************************************
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>



-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140114/232b57f2/attachment.html>

From jo.bovy at gmail.com  Tue Jan 14 16:22:54 2014
From: jo.bovy at gmail.com (Jo Bovy)
Date: Tue, 14 Jan 2014 16:22:54 -0500
Subject: [AstroPy] Fwd: ANN: galpy v0.1 released
In-Reply-To: <CALeWRE4j5z-hb1g7yUbPQ48wBw2wJc2VWbuiYyS4VhiFnQH1gQ@mail.gmail.com>
References: <CALeWRE4j5z-hb1g7yUbPQ48wBw2wJc2VWbuiYyS4VhiFnQH1gQ@mail.gmail.com>
Message-ID: <CALeWRE7nUGOwRU2PxGoOWvUMxyvUT3LxNTbGi2Qosw0AKjdnqA@mail.gmail.com>

Dear colleagues,

I am happy to announce the first public release of galpy, a python package
for galactic and MW dynamics. You are receiving this email because I
believe this may be of interest to you; if not, I apologize for the mass
mailing.

galpy supports orbit integration in a variety of potentials, evaluating and
sampling various disk distribution functions, and the calculation of
action-angle coordinates for all static potentials. The basic functionality
is written in pure python, but various parts of the code are accelerated
using C (orbit integration and action-angle calculations in particular);
see the installation instructions on how to get the full functionality.

galpy is available on pypi:

http://pypi.python.org/pypi/galpy/0.1

and github

http://github.com/jobovy/galpy

and can be installed from there or using pip. Documentation (including more
detailed installation instructions) can be found here:

http://galpy.readthedocs.org/en/latest/

Please report issues by reporting them on github (the preferred method)

http://github.com/jobovy/galpy/issues

or by emailing me (bovy at ias.edu). Please let me know if you are using the
code so I can keep you informed of any major updates.

Thanks,

Jo

-- 
Jo Bovy, School of Natural Sciences, IAS, http://sns.ias.edu/~bovy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140114/8a6c20fe/attachment.html>

From hack at stsci.edu  Wed Jan 15 17:16:02 2014
From: hack at stsci.edu (Warren J. Hack)
Date: Wed, 15 Jan 2014 17:16:02 -0500
Subject: [AstroPy] New Version of DrizzlePac Available
Message-ID: <52D708A2.9000301@stsci.edu>

     ********************************************************

     DrizzlePac v1.1.15 NOW AVAILABLE

     ********************************************************


The Science Software Branch of the Space Telescope Science Institute
wishes to announce the availability of DrizzlePac Version 1.1.15, an
update to the package previously released as part of STScI_Python 2.14.

-----------
DrizzlePac
-----------
The DrizzlePac package, a component of the STScI_Python environment,
implements the distortion correction and image combination algorithm for
HST data.  This release updates the software to work with the new
distortion calibrations implemented in standard HST processing for WFC3 
data,
which also required changes to ACS D2IM distortion files.  The updated
distortion calibrations resulted in changes to the calibrated HST data
provided by the HST archive that were incompatible with the previous
version of DrizzlePac (as released in May 2013).

This release also fixes a number of additional problems, including (but not
limited to):

   * supporting processing of STIS data
   * keeping the value of the NEXTEND consistent when updating files
   * restoring the recording of cosmic-rays in calibrated (FLT) files
   * allowing tweakreg to be run non-interactively
   * removing all OPUS-generated input image WCS keywords from drizzle 
product headers

A full set of release notes can be found online at the DrizzlePac home 
page at:

     http://drizzlepac.stsci.edu


INSTALLATION
============
The STScI_Python software had been re-packaged in the May 2013 release to
install each package separately using standard Python installation
tools such as pip and easy_install.  This also allows each package
to be updated separately rather than having to update all at once.
The entire suite of software can still be installed in one command
that retrieves the software from the Python Package Index (PyPI)
directly.  A full description of this change and how to get and
install this software can be found on our web page at:

http://www.stsci.edu/institute/software_hardware/pyraf/stsci_python/installation

Installation of this new version of DrizzlePac can be performed
using the single command:

   pip install --upgrade drizzlepac

Alternatively, if you would like to pick up all changes to all
packages in the STScI_Python installation since the May 2013 release,
you can use:

   pip install --upgrade stscipython

These commands should be run under whatever environment you
initialize to run the STScI_Python code, including the new
Ureka installations. Full details on Ureka can be found at:

   http://ssb.stsci.edu/ureka/

------------
STScI_Python
------------
This update requires that STScI_Python Version 2.14 already be installed 
either
on its own as released in May 2013 or as part of Ureka Version 1.0. More
details on STScI_Python installations can be found at:

http://www.stsci.edu/institute/software_hardware/pyraf/stsci_python/installation


Please contact us through e-mail (help at stsci.edu), by telephone at
(410) 338-1082.


From sergio.pasra at gmail.com  Sat Jan 18 17:51:39 2014
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Sat, 18 Jan 2014 23:51:39 +0100
Subject: [AstroPy] Astropy in Fedora
Message-ID: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>

Hello,

I'm very happy to inform you that astropy has been included in Fedora.

It exists for Fedora 20 only. There are python-astropy for Python 2.7 and
python3-astropy for Python 3.3
The documentation is splited in a subpackage python(3)-astropy-doc

During the next week approximately , the packages will be in the
'updates-testing' repository. To install from this repository users will
need to do:

$ sudo yum install python-astropy --enablerepo=updates-testing

Once the package is pushed to the updates repository, its enough to do

$ sudo yum install python-astropy

Please install, test and enjoy!

Best regards, Sergio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140118/292d3248/attachment.html>

From embray at stsci.edu  Sat Jan 18 18:35:31 2014
From: embray at stsci.edu (Erik Bray)
Date: Sat, 18 Jan 2014 18:35:31 -0500
Subject: [AstroPy] Astropy in Fedora
In-Reply-To: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
References: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
Message-ID: <52DB0FC3.10909@stsci.edu>

On 01/18/2014 05:51 PM, Sergio Pascual wrote:
> Hello,
>
> I'm very happy to inform you that astropy has been included in Fedora.
>
> It exists for Fedora 20 only. There are python-astropy for Python 2.7 and
> python3-astropy for Python 3.3
> The documentation is splited in a subpackage python(3)-astropy-doc
>
> During the next week approximately , the packages will be in the
> 'updates-testing' repository. To install from this repository users will need to do:
>
> $ sudo yum install python-astropy --enablerepo=updates-testing
>
> Once the package is pushed to the updates repository, its enough to do
>
> $ sudo yum install python-astropy
>
> Please install, test and enjoy!
>
> Best regards, Sergio

Thanks for doing the packaging for Fedora!

Erik B.



From mdroe at stsci.edu  Wed Jan 22 11:02:27 2014
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 22 Jan 2014 11:02:27 -0500
Subject: [AstroPy] Astropy in Fedora
In-Reply-To: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
References: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
Message-ID: <52DFEB93.2060403@stsci.edu>

Thanks for doing this. This is fantastic.

I'm getting one absolutely non-critical test failure with the package, 
however.

|_______________ test_skip_hidden __________________

     def test_skip_hidden():
         path = data._find_pkg_data_path('data')
         for root, dirs, files in os.walk(path):
>           assert '.hidden_file.txt' in files
E           assert u'.hidden_file.txt' in [u'local.dat.bz2', u'invalid.dat.gz', u'unicode.txt', u'local.dat', u'invalid.dat.bz2', u'local.dat.gz']

/usr/lib64/python2.7/site-packages/astropy/utils/tests/test_misc.py:118: AssertionError
==== 1 failed, 4802 passed, 89 skipped, 11 xfailed in 178.17 seconds ====|

The purpose of this test is to ensure that the regular Python |os.walk| 
includes hidden files, but that our own 
|astropy.utils.misc.walk_skip_hidden| does not. To test this, a hidden 
file is included in the test data folder, but it looks like that file is 
not being installed in the package:

|~ > ls -a /usr/lib64/python2.7/site-packages/astropy/utils/tests/data/
.  ..  invalid.dat.bz2  invalid.dat.gz  local.dat  local.dat.bz2  local.dat.gz  test_package  unicode.txt|

If hidden files can't be included in the package for policy reasons, 
it's probably reasonable to either disable this test in the package, or 
create the file programmatically in a temporary directory and then run 
these tests there. I can probably help code up the latter if that would 
be helpful.

Let me know if this is sufficient or I should file a bugzilla entry etc.

Mike

On 01/18/2014 05:51 PM, Sergio Pascual wrote:

> Hello,
>
> I'm very happy to inform you that astropy has been included in Fedora.
>
> It exists for Fedora 20 only. There are python-astropy for Python 2.7 
> and python3-astropy for Python 3.3
> The documentation is splited in a subpackage python(3)-astropy-doc
>
> During the next week approximately , the packages will be in the 
> 'updates-testing' repository. To install from this repository users 
> will need to do:
>
> $ sudo yum install python-astropy --enablerepo=updates-testing
>
> Once the package is pushed to the updates repository, its enough to do
>
> $ sudo yum install python-astropy
>
> Please install, test and enjoy!
>
> Best regards, Sergio
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

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

From ejensen1 at swarthmore.edu  Wed Jan 22 11:14:41 2014
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Wed, 22 Jan 2014 11:14:41 -0500
Subject: [AstroPy] Type changing (float to int) of header fields in
	astropy.wcs.to_header ?
Message-ID: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>

Hi all,

In working today with reading, modifying, and writing WCS values from FITS headers, I ran into an unexpected feature - seems to be a bug, but I thought I'd check to be sure.

It appears that some header keywords are changing from float to integer when being converted by the wcs.to_header function.  Below is an example (code first, then output).  Note that the value of CRVAL3 is still correct, but by writing it out as an integer, some FITS readers (I'm looking at you, CASA) choke on it because they try to read it as an int and I get 'integer overflow' errors.  And the Pence et al. 2010 FITS paper does say that the CRVAL keywords should be type float. 

For what it's worth, I run into the same problem with the 'RESTFRQ' keyword in this file, which also should be a float 345795989900.0 but gets written as an int 345795989900.  It seems to happen for values that don't have a non-integer part, but which should remain as floats nonetheless. 

I looked at the github source for 'to_header' but I have to confess that I don't understand what's going on there, so I can't propose a fix.  

It seems to be a bug, but in the meantime, any suggested workarounds?  Just assigning
header['CRVAL3'] = float(header['CRVAL3'])

doesn't work.  In the short term I've resorted to multiplying the keyword value by 1 + epsilon, where I fine-tune epsilon to be small enough not to matter for my calculations downstream, but that's far from ideal. 

Thanks as always for your help,

Eric


Test case:

import astropy.io.fits as fits
import astropy.wcs as wcs
import numpy as np

fitsfile = 'test.fits'
hdulist = fits.open(fitsfile)

w = wcs.WCS(hdulist[0].header)

# Check types of header fields in wcs object:

print "From WCS object:\n"
for i in (0,1,2):
    print "CRVAL%d is type %s with value:" % (i+1,
                                              type(w.wcs.crval[i]))
    print w.wcs.crval[i]
    
# Now do the same thing after converting to header:
header = w.to_header()

print "\nAfter to_header conversion:\n"
for i in (0,1,2):
    keyname = "CRVAL%d" % (i+1)
    print "CRVAL%d is type %s with value:" % (i+1,
                                              type(header[keyname]))
    print header[keyname]

import pkg_resources
print "\nAstropy version " + pkg_resources.get_distribution("astropy").version


Output:

From WCS object:

CRVAL1 is type <type 'numpy.float64'> with value:
67.960692
CRVAL2 is type <type 'numpy.float64'> with value:
24.405019
CRVAL3 is type <type 'numpy.float64'> with value:
345797143190.0

After to_header conversion:

CRVAL1 is type <type 'float'> with value:
67.960692
CRVAL2 is type <type 'float'> with value:
24.405019
CRVAL3 is type <type 'int'> with value:
345797143190

Astropy version 0.3




From sergio.pasra at gmail.com  Wed Jan 22 11:22:56 2014
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Wed, 22 Jan 2014 17:22:56 +0100
Subject: [AstroPy] Astropy in Fedora
In-Reply-To: <52DFEB93.2060403@stsci.edu>
References: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
	<52DFEB93.2060403@stsci.edu>
Message-ID: <CACta-KY42G1miL4jpYwzg4TnswoMEkfXEMYi=7xLKTWRkiOGtg@mail.gmail.com>

Hi Mike,

2014/1/22 Michael Droettboom <mdroe at stsci.edu>

>  Thanks for doing this. This is fantastic.
>
> I?m getting one absolutely non-critical test failure with the package,
> however.
>
I'm aware of the failure. it's a mistake in my RPM specfile. I have an
updated package that includes the hidden file, but I haven't pushed as a
new update to avoid further delays.
Each package has to stay ~ 7 days in updates-testing before being pushed to
the stable updates repository. If I submit the update now, the day count
resets.

As soon as this version (python-astropy-0.3-5.fc20) is moved to stable
updates I will submit the fixed package (python-astropy-0.3-6.fc20)

Best, Sergio

> On 01/18/2014 05:51 PM, Sergio Pascual wrote:
>
>    Hello,
>
>  I'm very happy to inform you that astropy has been included in Fedora.
>
>  It exists for Fedora 20 only. There are python-astropy for Python 2.7
> and python3-astropy for Python 3.3
>  The documentation is splited in a subpackage python(3)-astropy-doc
>
>  During the next week approximately , the packages will be in the
> 'updates-testing' repository. To install from this repository users will
> need to do:
>
>  $ sudo yum install python-astropy --enablerepo=updates-testing
>
>  Once the package is pushed to the updates repository, its enough to do
>
> $ sudo yum install python-astropy
>
>  Please install, test and enjoy!
>
>  Best regards, Sergio
>
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttp://mail.scipy.org/mailman/listinfo/astropy
>
>    --
>                    _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> http://www.droettboom.com
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140122/966c3fc2/attachment.html>

From mdroe at stsci.edu  Wed Jan 22 11:43:41 2014
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 22 Jan 2014 11:43:41 -0500
Subject: [AstroPy] Astropy in Fedora
In-Reply-To: <CACta-KY42G1miL4jpYwzg4TnswoMEkfXEMYi=7xLKTWRkiOGtg@mail.gmail.com>
References: <CACta-Kbi8LWgW2j1cXijjE3z-MOHNKNW_G-=zMCsWJC11WxLcA@mail.gmail.com>
	<52DFEB93.2060403@stsci.edu>
	<CACta-KY42G1miL4jpYwzg4TnswoMEkfXEMYi=7xLKTWRkiOGtg@mail.gmail.com>
Message-ID: <52DFF53D.6020704@stsci.edu>

Great!  As I said, this is a completely non-critical failure and 
shouldn't impact anyone just using astropy...

Thanks,
Mike

On 01/22/2014 11:22 AM, Sergio Pascual wrote:
> Hi Mike,
>
> 2014/1/22 Michael Droettboom <mdroe at stsci.edu <mailto:mdroe at stsci.edu>>
>
>     Thanks for doing this. This is fantastic.
>
>     I?m getting one absolutely non-critical test failure with the
>     package, however.
>
> I'm aware of the failure. it's a mistake in my RPM specfile. I have an 
> updated package that includes the hidden file, but I haven't pushed as 
> a new update to avoid further delays.
> Each package has to stay ~ 7 days in updates-testing before being 
> pushed to the stable updates repository. If I submit the update now, 
> the day count resets.
>
> As soon as this version (python-astropy-0.3-5.fc20) is moved to stable 
> updates I will submit the fixed package (python-astropy-0.3-6.fc20)
>
> Best, Sergio
>
>     On 01/18/2014 05:51 PM, Sergio Pascual wrote:
>
>>     Hello,
>>
>>     I'm very happy to inform you that astropy has been included in
>>     Fedora.
>>
>>     It exists for Fedora 20 only. There are python-astropy for Python
>>     2.7 and python3-astropy for Python 3.3
>>     The documentation is splited in a subpackage python(3)-astropy-doc
>>
>>     During the next week approximately , the packages will be in the
>>     'updates-testing' repository. To install from this repository
>>     users will need to do:
>>
>>     $ sudo yum install python-astropy --enablerepo=updates-testing
>>
>>     Once the package is pushed to the updates repository, its enough
>>     to do
>>
>>     $ sudo yum install python-astropy
>>
>>     Please install, test and enjoy!
>>
>>     Best regards, Sergio
>>
>>
>>
>>     _______________________________________________
>>     AstroPy mailing list
>>     AstroPy at scipy.org  <mailto:AstroPy at scipy.org>
>>     http://mail.scipy.org/mailman/listinfo/astropy
>
>     -- 
>                         _
>     |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
>     |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
>     http://www.droettboom.com
>
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

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

From mdroe at stsci.edu  Wed Jan 22 11:58:32 2014
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 22 Jan 2014 11:58:32 -0500
Subject: [AstroPy] Type changing (float to int) of header fields in
 astropy.wcs.to_header ?
In-Reply-To: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>
References: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>
Message-ID: <52DFF8B8.2060107@stsci.edu>

On 01/22/2014 11:14 AM, Eric L.N.Jensen wrote:
> Hi all,
>
> In working today with reading, modifying, and writing WCS values from FITS headers, I ran into an unexpected feature - seems to be a bug, but I thought I'd check to be sure.
>
> It appears that some header keywords are changing from float to integer when being converted by the wcs.to_header function.  Below is an example (code first, then output).  Note that the value of CRVAL3 is still correct, but by writing it out as an integer, some FITS readers (I'm looking at you, CASA) choke on it because they try to read it as an int and I get 'integer overflow' errors.  And the Pence et al. 2010 FITS paper does say that the CRVAL keywords should be type float.
>
> For what it's worth, I run into the same problem with the 'RESTFRQ' keyword in this file, which also should be a float 345795989900.0 but gets written as an int 345795989900.  It seems to happen for values that don't have a non-integer part, but which should remain as floats nonetheless.

This is what the FITS standard has to say about floating-point numbers:

```
A floating-point number is represented by a decimal number
followed by an optional exponent, with no embedded spaces.
A decimal number shall consist of a '+' (decimal 43 or hexadecimal
2B) or '--' (decimal 45 or hexadecimal 2D) sign, followed
by a sequence of ASCII digits containing a single decimal
point ('.'), representing an integer part and a fractional part of
the floating-point number. The leading '+' sign is optional. At
least one of the integer part or fractional part must be present.
If the fractional part is present, the decimal point must also be
present. If only the integer part is present, the decimal point may
be omitted, in which case the floating-point number is indistinguishable
from an integer.
```

So by that standard, astropy.wcs is doing the right thing here. "45" is 
a floating-point number (as far as FITS is concerned) but it is also an 
integer.

>
> I looked at the github source for 'to_header' but I have to confess that I don't understand what's going on there, so I can't propose a fix.

`astropy.wcs` uses `wcslib` to generate the header keywords from its 
internal data structures.  It all happens in a C function called 
`wcshdo`.  Here [1], for example, is the code where the `CRVAL` is 
generated.

[1] 
https://github.com/astropy/astropy/blob/master/cextern/wcslib/C/wcshdr.c#L637

```
wcsutil_double2str(keyvalue,"%20.12G",wcs->crval[i]);
```

As you can see, it's using the C "%G" operator to convert the value to a 
string, whose manpage says:

```
Trailing zeros are removed from the fractional part of the result; a
decimal point appears only if it is followed by at least one digit.
```

We could change the `G` to `E`, I suppose, but then we'd always get an 
exponent.  C doesn't provide any good options here, which I suspect is 
why the FITS standard is the way it is.
>
> It seems to be a bug, but in the meantime, any suggested workarounds?  Just assigning
> header['CRVAL3'] = float(header['CRVAL3'])
>
> doesn't work.  In the short term I've resorted to multiplying the keyword value by 1 + epsilon, where I fine-tune epsilon to be small enough not to matter for my calculations downstream, but that's far from ideal.

Honestly, and I don't mean to sound unhelpful, this sounds like a bug in 
CASA.  It should cast to a float before performing floating-point 
operations.

Mike

>
> Thanks as always for your help,
>
> Eric
>
>
> Test case:
>
> import astropy.io.fits as fits
> import astropy.wcs as wcs
> import numpy as np
>
> fitsfile = 'test.fits'
> hdulist = fits.open(fitsfile)
>
> w = wcs.WCS(hdulist[0].header)
>
> # Check types of header fields in wcs object:
>
> print "From WCS object:\n"
> for i in (0,1,2):
>      print "CRVAL%d is type %s with value:" % (i+1,
>                                                type(w.wcs.crval[i]))
>      print w.wcs.crval[i]
>      
> # Now do the same thing after converting to header:
> header = w.to_header()
>
> print "\nAfter to_header conversion:\n"
> for i in (0,1,2):
>      keyname = "CRVAL%d" % (i+1)
>      print "CRVAL%d is type %s with value:" % (i+1,
>                                                type(header[keyname]))
>      print header[keyname]
>
> import pkg_resources
> print "\nAstropy version " + pkg_resources.get_distribution("astropy").version
>
>
> Output:
>
> >From WCS object:
>
> CRVAL1 is type <type 'numpy.float64'> with value:
> 67.960692
> CRVAL2 is type <type 'numpy.float64'> with value:
> 24.405019
> CRVAL3 is type <type 'numpy.float64'> with value:
> 345797143190.0
>
> After to_header conversion:
>
> CRVAL1 is type <type 'float'> with value:
> 67.960692
> CRVAL2 is type <type 'float'> with value:
> 24.405019
> CRVAL3 is type <type 'int'> with value:
> 345797143190
>
> Astropy version 0.3
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

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

From ejensen1 at swarthmore.edu  Wed Jan 22 14:42:38 2014
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Wed, 22 Jan 2014 14:42:38 -0500
Subject: [AstroPy] Type changing (float to int) of header fields in
	astropy.wcs.to_header ?
In-Reply-To: <52DFF8B8.2060107@stsci.edu>
References: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>
	<52DFF8B8.2060107@stsci.edu>
Message-ID: <5688B829-FF07-4480-8A2D-445816D456FB@swarthmore.edu>

Hi Mike,

Thanks for your quick and helpful response - I really appreciate it. 

First, let me say that I completely agree with this:

> Honestly, and I don't mean to sound unhelpful, this sounds like a bug in CASA.  It should cast to a float before performing floating-point operations.


I wasn't sure if that was the case before because I hadn't found the part of the FITS standard you reference (thanks!) about the decimal point being optional for floats in FITS.   And for what it's worth, I'm not sure if it's an issue with floating-point operations, or just with interpreting the field as an int and trying to store it as such.  (In fact the value in my particular case, ~3.45E9, is too long to store even as a long int in C.  So I guess the key issue is whether the FITS reader knows which fields to interpret as floats even if they have no non-integer part.)

Still, there's something unsatisfying to me about this happening within astropy:

>> From WCS object:
>> 
>> CRVAL3 is type <type 'numpy.float64'> with value:
>> 345797143190.0
>> 
>> After to_header conversion:
>> 
>> CRVAL3 is type <type 'int'> with value:
>> 345797143190

All that is within Python, i.e. the stated datatype *in Python* changes after the call to 'to_header'.   Could this be a problem if, e.g., a user decides to divide by that value (reasoning that it should be a float, since the input was float) and gets the result of integer division rather than floating-point division?  (I admit that this is a contrived example, since it would require that the numerator be an integer as well, but I'm still a little puzzled by the type change.) 

I guess I still don't see how this conversion happens.  I see in the code where you pointed out that wcslib will drop the decimal in making the number into a string, but to_header doesn't return a string-representation FITS header; it returns a FITS header object (which seems dictionary-like) that definitely doesn't have only string values.  Do these fields get converted to strings and then back to numbers during the to_header call?

At some level this won't matter for my particular problem if the final output file is written with that wcsutil_double2str 
function, but I am curious on your thoughts about the above, i.e. what is happening within Python itself. 

Thanks again,

Eric

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

From mdroe at stsci.edu  Wed Jan 22 17:12:11 2014
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 22 Jan 2014 17:12:11 -0500
Subject: [AstroPy] Type changing (float to int) of header fields in
 astropy.wcs.to_header ?
In-Reply-To: <5688B829-FF07-4480-8A2D-445816D456FB@swarthmore.edu>
References: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>	<52DFF8B8.2060107@stsci.edu>
	<5688B829-FF07-4480-8A2D-445816D456FB@swarthmore.edu>
Message-ID: <52E0423B.9020206@stsci.edu>

On 01/22/2014 02:42 PM, Eric L. N. Jensen wrote:
> Hi Mike,
>
> Thanks for your quick and helpful response - I really appreciate it.
>
> First, let me say that I completely agree with this:
>
>> Honestly, and I don't mean to sound unhelpful, this sounds like a bug 
>> in CASA.  It should cast to a float before performing floating-point 
>> operations.
>
> I wasn't sure if that was the case before because I hadn't found the 
> part of the FITS standard you reference (thanks!) about the decimal 
> point being optional for floats in FITS.   And for what it's worth, 
> I'm not sure if it's an issue with floating-point operations, or just 
> with interpreting the field as an int and trying to store it as such. 
>  (In fact the value in my particular case, ~3.45E9, is too long to 
> store even as a long int in C.  So I guess the key issue is whether 
> the FITS reader knows which fields to interpret as floats even if they 
> have no non-integer part.)
It isn't the responsibility of the FITS reader to interpret the values 
-- it's the responsibility of the code that needs to use the value.  In 
effect, CASA should be saying "give me CRVAL3 as a float, because I know 
that's what a CRVAL should be."  It's not ideal, but that's the best one 
can do with the FITS standard such as it is.

The issue with the maximum size of C ints is one of the reasons CFITSIO 
has the caller say what type they want the value returned in.  My 
sidestep this a little in PyFITS by using Python's arbitrary-precision 
integers, so it doesn't matter if the value is read first as an int (by 
astropy.fits) and later recast as a float (by the tool using astropy.fits).

I'm sorry if I seemed abrupt -- others at my office have wondered why we 
can't just add a decimal place to these values in wcslib and be done 
with it.  We certainly can, but it doesn't change the fact that any tool 
*reading* a WCS structure still needs to be fixed in order to read 
anything that may be thrown at it (which may well include a floating 
point value that looks like an integer).  And I'd just rather fix the 
problem at its source than accrue even more workarounds (there's way too 
many of those in the FITS/WCS world already).

>
> Still, there's something unsatisfying to me about this happening 
> within astropy:
>
>>>  From WCS object:
>>>
>>> CRVAL3 is type <type 'numpy.float64'> with value:
>>> 345797143190.0
>>>
>>> After to_header conversion:
>>>
>>> CRVAL3 is type <type 'int'> with value:
>>> 345797143190
>
> All that is within Python, i.e. the stated datatype *in Python* 
> changes after the call to 'to_header'.   Could this be a problem if, 
> e.g., a user decides to divide by that value (reasoning that it should 
> be a float, since the input was float) and gets the result of integer 
> division rather than floating-point division?  (I admit that this is a 
> contrived example, since it would require that the numerator be an 
> integer as well, but I'm still a little puzzled by the type change.)

Even in this contrived example, if the user wants to do floating point 
division, they should cast the value to a floating point value first.

>
> I guess I still don't see how this conversion happens.  I see in the 
> code where you pointed out that wcslib will drop the decimal in 
> making the number into a string, but to_header doesn't return a 
> string-representation FITS header; it returns a FITS header object 
> (which seems dictionary-like) that definitely doesn't have only string 
> values.

wcslib converts its internal data structures back into a string 
representation of a FITS header, which we parse back into an 
`astropy.fits.Header` object.  This is because wcslib does not provide 
an API to get a list of key/value pairs, only to get a parsed and 
cleaned up header back as a string.  The mapping from the internal data 
structure to key/value pairs is non-trivial.

>  Do these fields get converted to strings and then back to numbers 
> during the to_header call?

Yes.  It's all just a peculiarity from the decision to use wcslib, which 
has many years of effort in implementing the WCS standard and not 
wanting to reimplement it.

>
> At some level this won't matter for my particular problem if the final 
> output file is written with that wcsutil_double2str
> function, but I am curious on your thoughts about the above, i.e. what 
> is happening within Python itself.
>

Hope it's clearer.

The flow is basically:

astropy.io.fits.Header ->
FITS Header string ->
[all kinds of normalization and fixups for different changing and 
obsolete conventions] ->
WCS data structure (normalized and optimized for performing the 
transformations) ->
FITS header string ->
astropy.io.fits.Header

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

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

From wkerzendorf at gmail.com  Thu Jan 23 11:53:23 2014
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Thu, 23 Jan 2014 11:53:23 -0500
Subject: [AstroPy] ANN: TARDIS v0.9 - A spectral synthesis code for rapid
	modelling of supernovae
Message-ID: <49084DB2-EBB3-4156-8A26-F3B720654B2B@gmail.com>

Hey guys,

I?m happy to announce the release of TARDIS  - a new 1D montecarlo spectral synthesis code for supernovae.  Documentation and example files are available at http://tardis.readthedocs.org (an accompanying paper can be found on today?s astro-ph: http://arxiv.org/abs/1401.5469). Currently, we focus on SN Ia but are in the process of implementing the necessary microphysics for Type II supernovae. 

The code is built in a modular fashion and it should be easily possible to introduce new physics for the code. 

The code also uses astropy extensively (mainly for the setup procedures and units/quantity) and has also adopted its philosophy of being fully open: https://github.com/tardis-sn/tardis

Please do not hesitate to let us know if you encounter any problems with the code!

Happy synthesizing,
    Wolfgang (on behalf of the TARDIS team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140123/af45065a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/astropy/attachments/20140123/af45065a/attachment.sig>

From jzuhone at gmail.com  Thu Jan 23 13:12:58 2014
From: jzuhone at gmail.com (John ZuHone)
Date: Thu, 23 Jan 2014 13:12:58 -0500
Subject: [AstroPy] Release of pywwt 0.1.0,
	a Python interface to the World Wide Telescope Windows Client
Message-ID: <1304F272-D306-4DD7-9872-38628E385DE9@gmail.com>

Hi all,

Apologies for the spam, but I thought maybe the astropy list would be good place to find some interest in this new library I wrote, pywwt:

http://www.jzuhone.com/pywwt

pywwt is a Python interface for the Microsoft World Wide Telescope (WWT, http://www.worldwidetelescope.org) Windows client, using the Layer Control API (LCAPI). The LCAPI provides an interface to WWT?s Layer Manager by sending data and information in the form of strings over HTTP. pywwt provides a straightforward Python interface to make these calls, enabling the control of WWT from scripts or an IPython notebook. Most importantly, it enables the passing of data created within a Python environment to WWT. 

The upshot of this is that particle and event data that can be loaded into memory in Python can be passed off to a World Wide Telescope client running on a Windows machine, either the same host or a host on the same network. 

To see an example IPython notebook (complete with an example video!), visit: http://www.jzuhone.com/pywwt/pywwt_example.html

pywwt requires the following packages:

	? NumPy
	? Matplotlib
	? AstroPy
	? Beautiful Soup 4
	? Requests
	? Dateutil

pywwt can be installed from pip:

pip install pywwt

or download the source from http://github.com/jzuhone/pywwt and install:

python setup.py install

My use cases are limited, and I'd be interested in what others could do with it, so if you are interested please fork the code and help develop!

Best,

John ZuHone


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

From embray at stsci.edu  Thu Jan 23 15:35:33 2014
From: embray at stsci.edu (Erik Bray)
Date: Thu, 23 Jan 2014 15:35:33 -0500
Subject: [AstroPy] Type changing (float to int) of header fields in
 astropy.wcs.to_header ?
In-Reply-To: <52E0423B.9020206@stsci.edu>
References: <04EF53EA-3870-4B4D-9552-89D124E64B08@swarthmore.edu>	<52DFF8B8.2060107@stsci.edu>	<5688B829-FF07-4480-8A2D-445816D456FB@swarthmore.edu>
	<52E0423B.9020206@stsci.edu>
Message-ID: <52E17D15.7080001@stsci.edu>

On 01/22/2014 05:12 PM, Michael Droettboom wrote:
> On 01/22/2014 02:42 PM, Eric L. N. Jensen wrote:

>> Still, there's something unsatisfying to me about this happening within astropy:
>>
>>>>  From WCS object:
>>>>
>>>> CRVAL3 is type <type 'numpy.float64'> with value:
>>>> 345797143190.0
>>>>
>>>> After to_header conversion:
>>>>
>>>> CRVAL3 is type <type 'int'> with value:
>>>> 345797143190

Incidentally this was just brought up here: 
https://github.com/spacetelescope/PyFITS/issues/49

I don't know whether or not that was in response to this thread, as I don't see 
Julian on it anywhere, but it's the same issue nonetheless.

I agree with Mike that if you need the value to be *strictly* treated as a 
float, in particular for the purposes of division, that it's a bug in the 
software to not ensure that it's doing floating point division.  It's also true 
that "1" is a perfectly good "floating point" value as far as FITS is concerned, 
and is also just as much an integer.

There are other keywords in the FITS standard that must be *strictly* treated as 
integers, so it makes sense to return something like "1" as an integer and not a 
float.  That said, I think that if you have

CRVAL3 = 345797143190

and you enter in PyFITS:

header['CRVAL3'] = 345797143190.0

then that should upcast the value to a float, with ".0" IMO.  This should be 
easy to fix.

As an aside: I'm working on (and am nearly ready with a prototype of) a new FITS 
keyword schema definition interface for PyFITS.  This will enable providing 
PyFITS with more semantic information about known keywords (both keywords 
specified in the FITS standard, or keywords in a user-specified convention). 
For example, the header will "know" that it is adhering to the FITS WCS 
convention, and that by that convetion CRVAL3 should be treated as a float, so 
that even entering:

header['CRVAL3'] = 345797143190

would make sure that it is upcast to a float, as well as returned as a float.

The first prototype of the schema definition interface is nearly complete, but 
there's still a little ways to go on full integration with the PyFITS Header 
interface.

Erik B.



From dshaw.noao at gmail.com  Mon Jan 27 12:22:12 2014
From: dshaw.noao at gmail.com (Richard Shaw)
Date: Mon, 27 Jan 2014 10:22:12 -0700
Subject: [AstroPy] AstroPy Digest, Vol 88, Issue 14
In-Reply-To: <mailman.1.1390586401.25587.astropy@scipy.org>
References: <mailman.1.1390586401.25587.astropy@scipy.org>
Message-ID: <CAE=Hp-JMxbMO+Xg7qgQq57z2L7+N-P=fsSywhZ+87Rbb5pH=ig@mail.gmail.com>

Bravo! Particularly:

>It's also true that "1" is a perfectly good "floating point" value as far
as FITS is concerned, and is also just as much an integer.

I would add that "1." is also a perfectly good floating point value as far
as FITS is concerned. IMHO software should _insulate_ users from the
peculiarities of FITS, to the extent feasible, rather than torture them
with it.

-Dick Shaw


On Fri, Jan 24, 2014 at 11:00 AM, <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
>         http://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. Release of pywwt 0.1.0,   a Python interface to the World Wide
>       Telescope Windows Client (John ZuHone)
>    2. Re: Type changing (float to int) of header fields in
>       astropy.wcs.to_header ? (Erik Bray)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Jan 2014 13:12:58 -0500
> From: John ZuHone <jzuhone at gmail.com>
> Subject: [AstroPy] Release of pywwt 0.1.0,      a Python interface to the
>         World Wide Telescope Windows Client
> To: astropy <astropy at scipy.org>
> Message-ID: <1304F272-D306-4DD7-9872-38628E385DE9 at gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi all,
>
> Apologies for the spam, but I thought maybe the astropy list would be good
> place to find some interest in this new library I wrote, pywwt:
>
> http://www.jzuhone.com/pywwt
>
> pywwt is a Python interface for the Microsoft World Wide Telescope (WWT,
> http://www.worldwidetelescope.org) Windows client, using the Layer
> Control API (LCAPI). The LCAPI provides an interface to WWT?s Layer Manager
> by sending data and information in the form of strings over HTTP. pywwt
> provides a straightforward Python interface to make these calls, enabling
> the control of WWT from scripts or an IPython notebook. Most importantly,
> it enables the passing of data created within a Python environment to WWT.
>
> The upshot of this is that particle and event data that can be loaded into
> memory in Python can be passed off to a World Wide Telescope client running
> on a Windows machine, either the same host or a host on the same network.
>
> To see an example IPython notebook (complete with an example video!),
> visit: http://www.jzuhone.com/pywwt/pywwt_example.html
>
> pywwt requires the following packages:
>
>         ? NumPy
>         ? Matplotlib
>         ? AstroPy
>         ? Beautiful Soup 4
>         ? Requests
>         ? Dateutil
>
> pywwt can be installed from pip:
>
> pip install pywwt
>
> or download the source from http://github.com/jzuhone/pywwt and install:
>
> python setup.py install
>
> My use cases are limited, and I'd be interested in what others could do
> with it, so if you are interested please fork the code and help develop!
>
> Best,
>
> John ZuHone
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20140123/454831be/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 Jan 2014 15:35:33 -0500
> From: Erik Bray <embray at stsci.edu>
> Subject: Re: [AstroPy] Type changing (float to int) of header fields
>         in astropy.wcs.to_header ?
> To: <astropy at scipy.org>
> Message-ID: <52E17D15.7080001 at stsci.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 01/22/2014 05:12 PM, Michael Droettboom wrote:
> > On 01/22/2014 02:42 PM, Eric L. N. Jensen wrote:
>
> >> Still, there's something unsatisfying to me about this happening within
> astropy:
> >>
> >>>>  From WCS object:
> >>>>
> >>>> CRVAL3 is type <type 'numpy.float64'> with value:
> >>>> 345797143190.0
> >>>>
> >>>> After to_header conversion:
> >>>>
> >>>> CRVAL3 is type <type 'int'> with value:
> >>>> 345797143190
>
> Incidentally this was just brought up here:
> https://github.com/spacetelescope/PyFITS/issues/49
>
> I don't know whether or not that was in response to this thread, as I
> don't see
> Julian on it anywhere, but it's the same issue nonetheless.
>
> I agree with Mike that if you need the value to be *strictly* treated as a
> float, in particular for the purposes of division, that it's a bug in the
> software to not ensure that it's doing floating point division.  It's also
> true
> that "1" is a perfectly good "floating point" value as far as FITS is
> concerned,
> and is also just as much an integer.
>
> There are other keywords in the FITS standard that must be *strictly*
> treated as
> integers, so it makes sense to return something like "1" as an integer and
> not a
> float.  That said, I think that if you have
>
> CRVAL3 = 345797143190
>
> and you enter in PyFITS:
>
> header['CRVAL3'] = 345797143190.0
>
> then that should upcast the value to a float, with ".0" IMO.  This should
> be
> easy to fix.
>
> As an aside: I'm working on (and am nearly ready with a prototype of) a
> new FITS
> keyword schema definition interface for PyFITS.  This will enable providing
> PyFITS with more semantic information about known keywords (both keywords
> specified in the FITS standard, or keywords in a user-specified
> convention).
> For example, the header will "know" that it is adhering to the FITS WCS
> convention, and that by that convetion CRVAL3 should be treated as a
> float, so
> that even entering:
>
> header['CRVAL3'] = 345797143190
>
> would make sure that it is upcast to a float, as well as returned as a
> float.
>
> The first prototype of the schema definition interface is nearly complete,
> but
> there's still a little ways to go on full integration with the PyFITS
> Header
> interface.
>
> Erik B.
>
>
>
> ------------------------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
> End of AstroPy Digest, Vol 88, Issue 14
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140127/7c5a87c4/attachment.html>

From harrold at astro.as.utexas.edu  Mon Jan 27 15:51:07 2014
From: harrold at astro.as.utexas.edu (Samuel Harrold)
Date: Mon, 27 Jan 2014 14:51:07 -0600
Subject: [AstroPy] astroquery.vizier.Vizier.get_catalogs doesn't fetch more
	than 50 rows
Message-ID: <CAAhYzvDnzARSdPMKGR1=e=FxP6aeuaYXTQpbFDDVWsBERkxpjQ@mail.gmail.com>

Hello,

I'm having trouble downloading all rows from a VizieR table using
astroquery: I have a table with more than 50 rows with the "-out.max"
keyword set to greater than 50, but astroquery returns only 50 rows. I've
included terminal output below. (Also, astroquery warns that I'm using an
old version of astropy, but both are up-to-date.)

Am I using the function correctly? Is there a workaround?

Thanks for any help!
Sam
**********
Samuel Harrold
PhD student
Astronomy Department
University of Texas at Austin

Terminal Output
********************
$ pip install --upgrade astropy
Requirement already up-to-date: astropy in
/Users/harrold/anaconda/lib/python2.7/site-packages
Cleaning up...
$ pip install --upgrade astroquery
Requirement already up-to-date: astroquery in
/Users/harrold/anaconda/lib/python2.7/site-packages
Requirement already up-to-date: astropy in
/Users/harrold/anaconda/lib/python2.7/site-packages (from astroquery)
Cleaning up...
$ python
Python 2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Jan 10 2014, 11:23:15)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import astropy
>>> astropy.version.version
'0.3'
>>> import astroquery
/Users/harrold/anaconda/lib/python2.7/site-packages/astroquery/__init__.py:132:
UserWarning: You are using an 'old' version of astropy prior to the change
that made all units singular.  astropy is being monkeypatched such that
degrees and degree are both allow and hours and hour are both allowed.
 This is NOT normal astropy behavior.
  warn("You are using an 'old' version of astropy prior to the change "
>>> astroquery.version.version
'0.1'
>>> from astroquery.vizier import Vizier
>>> Vizier.get_catalogs('2013ApJS..204....5K', {"-out.max":1000000})
TableList with 1 tables:
'0:J/ApJS/204/5/table2' with 20 column(s) and 50 row(s)

# However, the table actually has ~20,000 rows:
#
http://vizier.u-strasbg.fr/viz-bin/asu-txt?-source=2013ApJS..204....5K&-out.max=1000000

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

From adam.g.ginsburg at gmail.com  Mon Jan 27 17:06:40 2014
From: adam.g.ginsburg at gmail.com (Adam Ginsburg)
Date: Mon, 27 Jan 2014 18:06:40 -0400
Subject: [AstroPy] astroquery.vizier.Vizier.get_catalogs doesn't fetch
 more than 50 rows
In-Reply-To: <CAAhYzvDnzARSdPMKGR1=e=FxP6aeuaYXTQpbFDDVWsBERkxpjQ@mail.gmail.com>
References: <CAAhYzvDnzARSdPMKGR1=e=FxP6aeuaYXTQpbFDDVWsBERkxpjQ@mail.gmail.com>
Message-ID: <CAEBNSwbBuyevj57Ki5EjX6TTP-taHhbW+C2EirBF2Sy-yt1p6Q@mail.gmail.com>

Sam & I communicated off the mailing list; he determined that
Vizier.ROW_LIMIT supercedes the '-out.max' keyword.

The other issue is likely a problem with the pip version of
astroquery, which means we need to make a new release.

On Mon, Jan 27, 2014 at 4:51 PM, Samuel Harrold
<harrold at astro.as.utexas.edu> wrote:
> Hello,
>
> I'm having trouble downloading all rows from a VizieR table using
> astroquery: I have a table with more than 50 rows with the "-out.max"
> keyword set to greater than 50, but astroquery returns only 50 rows. I've
> included terminal output below. (Also, astroquery warns that I'm using an
> old version of astropy, but both are up-to-date.)
>
> Am I using the function correctly? Is there a workaround?
>
> Thanks for any help!
> Sam
> **********
> Samuel Harrold
> PhD student
> Astronomy Department
> University of Texas at Austin
>
> Terminal Output
> ********************
> $ pip install --upgrade astropy
> Requirement already up-to-date: astropy in
> /Users/harrold/anaconda/lib/python2.7/site-packages
> Cleaning up...
> $ pip install --upgrade astroquery
> Requirement already up-to-date: astroquery in
> /Users/harrold/anaconda/lib/python2.7/site-packages
> Requirement already up-to-date: astropy in
> /Users/harrold/anaconda/lib/python2.7/site-packages (from astroquery)
> Cleaning up...
> $ python
> Python 2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Jan 10 2014, 11:23:15)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import astropy
>>>> astropy.version.version
> '0.3'
>>>> import astroquery
> /Users/harrold/anaconda/lib/python2.7/site-packages/astroquery/__init__.py:132:
> UserWarning: You are using an 'old' version of astropy prior to the change
> that made all units singular.  astropy is being monkeypatched such that
> degrees and degree are both allow and hours and hour are both allowed.  This
> is NOT normal astropy behavior.
>   warn("You are using an 'old' version of astropy prior to the change "
>>>> astroquery.version.version
> '0.1'
>>>> from astroquery.vizier import Vizier
>>>> Vizier.get_catalogs('2013ApJS..204....5K', {"-out.max":1000000})
> TableList with 1 tables:
> '0:J/ApJS/204/5/table2' with 20 column(s) and 50 row(s)
>
> # However, the table actually has ~20,000 rows:
> #
> http://vizier.u-strasbg.fr/viz-bin/asu-txt?-source=2013ApJS..204....5K&-out.max=1000000
>
> ********************
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Adam Ginsburg
Fellow, European Southern Observatory
http://www.adamgginsburg.com/


From asishrocks95 at gmail.com  Tue Jan 28 12:43:44 2014
From: asishrocks95 at gmail.com (Asish Panda)
Date: Tue, 28 Jan 2014 23:13:44 +0530
Subject: [AstroPy] GSOC 2014
Message-ID: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>

Hey!
My first question is whether astropy is going to take part in gsoc 2014? If
it is, is the project list in github still good for 2014?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140128/f02f5cd1/attachment.html>

From thomas.robitaille at gmail.com  Tue Jan 28 12:56:07 2014
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 28 Jan 2014 18:56:07 +0100
Subject: [AstroPy] GSOC 2014
In-Reply-To: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>
References: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>
Message-ID: <CAGMHX_1yTqPkabB8c+=jJFEsX3di=2mEk2BTfnpBG+Ur7+iJ7w@mail.gmail.com>

Hi Asish,

Astropy is going to apply to participate in GSoC 2014. The project
list is going to be updated but some of the projects from last year
will still be there. If you are interested in participating, then try
familiarizing yourself with the developer workflow for Astropy:

 http://docs.astropy.org/en/latest/development/workflow/index.html

and try and submit a pull request for one of the available open issues:

  https://github.com/astropy/astropy/issues?direction=desc&sort=created&state=open

You can filter these with an 'Easy' tag to see ones that don't require
too much understanding of the whole Astropy infrastructure:

  https://github.com/astropy/astropy/issues?direction=desc&labels=easy&page=1&sort=created&state=open

Cheers,
Tom


On 28 January 2014 18:43, Asish Panda <asishrocks95 at gmail.com> wrote:
> Hey!
> My first question is whether astropy is going to take part in gsoc 2014? If
> it is, is the project list in github still good for 2014?
> Thanks!
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From asishrocks95 at gmail.com  Tue Jan 28 14:32:39 2014
From: asishrocks95 at gmail.com (Asish Panda)
Date: Wed, 29 Jan 2014 01:02:39 +0530
Subject: [AstroPy] GSOC 2014
In-Reply-To: <CAGMHX_1yTqPkabB8c+=jJFEsX3di=2mEk2BTfnpBG+Ur7+iJ7w@mail.gmail.com>
References: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>
	<CAGMHX_1yTqPkabB8c+=jJFEsX3di=2mEk2BTfnpBG+Ur7+iJ7w@mail.gmail.com>
Message-ID: <CAMTAJMGO3sgne7uns3GWew6BT1VSeN9trNrB=K88E_HCLZm64Q@mail.gmail.com>

Alright! Thanks for the fast reply!
Does document pull request count as well?


On Tue, Jan 28, 2014 at 11:26 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Asish,
>
> Astropy is going to apply to participate in GSoC 2014. The project
> list is going to be updated but some of the projects from last year
> will still be there. If you are interested in participating, then try
> familiarizing yourself with the developer workflow for Astropy:
>
>  http://docs.astropy.org/en/latest/development/workflow/index.html
>
> and try and submit a pull request for one of the available open issues:
>
>
> https://github.com/astropy/astropy/issues?direction=desc&sort=created&state=open
>
> You can filter these with an 'Easy' tag to see ones that don't require
> too much understanding of the whole Astropy infrastructure:
>
>
> https://github.com/astropy/astropy/issues?direction=desc&labels=easy&page=1&sort=created&state=open
>
> Cheers,
> Tom
>
>
> On 28 January 2014 18:43, Asish Panda <asishrocks95 at gmail.com> wrote:
> > Hey!
> > My first question is whether astropy is going to take part in gsoc 2014?
> If
> > it is, is the project list in github still good for 2014?
> > Thanks!
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140129/01ded845/attachment.html>

From thomas.robitaille at gmail.com  Tue Jan 28 17:05:29 2014
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 28 Jan 2014 23:05:29 +0100
Subject: [AstroPy] GSOC 2014
In-Reply-To: <CAMTAJMGO3sgne7uns3GWew6BT1VSeN9trNrB=K88E_HCLZm64Q@mail.gmail.com>
References: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>
	<CAGMHX_1yTqPkabB8c+=jJFEsX3di=2mEk2BTfnpBG+Ur7+iJ7w@mail.gmail.com>
	<CAMTAJMGO3sgne7uns3GWew6BT1VSeN9trNrB=K88E_HCLZm64Q@mail.gmail.com>
Message-ID: <CAGMHX_1agSc2SLjApmAeEQfFWc+k3bNukpsGCdEmZ=qKXF8RCg@mail.gmail.com>

On 28 January 2014 20:32, Asish Panda <asishrocks95 at gmail.com> wrote:
> Alright! Thanks for the fast reply!
> Does document pull request count as well?

Documentation pull requests count too - since they still require you
to understand the fork - clone - branch - pull request workflow. If
you can though, you should also try one of the coding issues since it
will show that you understand the Python code. You should feel free to
submit more than one pull request if you wish.

Cheers,
Tom

>
>
> On Tue, Jan 28, 2014 at 11:26 PM, Thomas Robitaille
> <thomas.robitaille at gmail.com> wrote:
>>
>> Hi Asish,
>>
>> Astropy is going to apply to participate in GSoC 2014. The project
>> list is going to be updated but some of the projects from last year
>> will still be there. If you are interested in participating, then try
>> familiarizing yourself with the developer workflow for Astropy:
>>
>>  http://docs.astropy.org/en/latest/development/workflow/index.html
>>
>> and try and submit a pull request for one of the available open issues:
>>
>>
>> https://github.com/astropy/astropy/issues?direction=desc&sort=created&state=open
>>
>> You can filter these with an 'Easy' tag to see ones that don't require
>> too much understanding of the whole Astropy infrastructure:
>>
>>
>> https://github.com/astropy/astropy/issues?direction=desc&labels=easy&page=1&sort=created&state=open
>>
>> Cheers,
>> Tom
>>
>>
>> On 28 January 2014 18:43, Asish Panda <asishrocks95 at gmail.com> wrote:
>> > Hey!
>> > My first question is whether astropy is going to take part in gsoc 2014?
>> > If
>> > it is, is the project list in github still good for 2014?
>> > Thanks!
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/astropy
>> >
>
>


From asishrocks95 at gmail.com  Tue Jan 28 23:34:35 2014
From: asishrocks95 at gmail.com (Asish Panda)
Date: Wed, 29 Jan 2014 10:04:35 +0530
Subject: [AstroPy] GSOC 2014
In-Reply-To: <CAGMHX_1agSc2SLjApmAeEQfFWc+k3bNukpsGCdEmZ=qKXF8RCg@mail.gmail.com>
References: <CAMTAJMHp5Dajk3o-gsuT2dpBft575HPnjaa3wfdDYndbEb6YuA@mail.gmail.com>
	<CAGMHX_1yTqPkabB8c+=jJFEsX3di=2mEk2BTfnpBG+Ur7+iJ7w@mail.gmail.com>
	<CAMTAJMGO3sgne7uns3GWew6BT1VSeN9trNrB=K88E_HCLZm64Q@mail.gmail.com>
	<CAGMHX_1agSc2SLjApmAeEQfFWc+k3bNukpsGCdEmZ=qKXF8RCg@mail.gmail.com>
Message-ID: <CAMTAJMHJ-mH4LA-cH6m4nxNNgnKLj0NUtALJqHtWvnvSR0Kamw@mail.gmail.com>

Alright.
And sorry for asking my initial question, that was already answered in the
google group.
Thank you again! :)


On Wed, Jan 29, 2014 at 3:35 AM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> On 28 January 2014 20:32, Asish Panda <asishrocks95 at gmail.com> wrote:
> > Alright! Thanks for the fast reply!
> > Does document pull request count as well?
>
> Documentation pull requests count too - since they still require you
> to understand the fork - clone - branch - pull request workflow. If
> you can though, you should also try one of the coding issues since it
> will show that you understand the Python code. You should feel free to
> submit more than one pull request if you wish.
>
> Cheers,
> Tom
>
> >
> >
> > On Tue, Jan 28, 2014 at 11:26 PM, Thomas Robitaille
> > <thomas.robitaille at gmail.com> wrote:
> >>
> >> Hi Asish,
> >>
> >> Astropy is going to apply to participate in GSoC 2014. The project
> >> list is going to be updated but some of the projects from last year
> >> will still be there. If you are interested in participating, then try
> >> familiarizing yourself with the developer workflow for Astropy:
> >>
> >>  http://docs.astropy.org/en/latest/development/workflow/index.html
> >>
> >> and try and submit a pull request for one of the available open issues:
> >>
> >>
> >>
> https://github.com/astropy/astropy/issues?direction=desc&sort=created&state=open
> >>
> >> You can filter these with an 'Easy' tag to see ones that don't require
> >> too much understanding of the whole Astropy infrastructure:
> >>
> >>
> >>
> https://github.com/astropy/astropy/issues?direction=desc&labels=easy&page=1&sort=created&state=open
> >>
> >> Cheers,
> >> Tom
> >>
> >>
> >> On 28 January 2014 18:43, Asish Panda <asishrocks95 at gmail.com> wrote:
> >> > Hey!
> >> > My first question is whether astropy is going to take part in gsoc
> 2014?
> >> > If
> >> > it is, is the project list in github still good for 2014?
> >> > Thanks!
> >> >
> >> > _______________________________________________
> >> > AstroPy mailing list
> >> > AstroPy at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/astropy
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140129/abf2c616/attachment.html>

From gb.gabrielebrambilla at gmail.com  Fri Jan 31 13:48:36 2014
From: gb.gabrielebrambilla at gmail.com (Gabriele Brambilla)
Date: Fri, 31 Jan 2014 13:48:36 -0500
Subject: [AstroPy] Fwd: Gaussian filter
In-Reply-To: <CABmgkid_7J546CHyq_fTnUL9oo-AyAXtd-aoJSihDOQ0YV4DZg@mail.gmail.com>
References: <CABmgkid_7J546CHyq_fTnUL9oo-AyAXtd-aoJSihDOQ0YV4DZg@mail.gmail.com>
Message-ID: <CABmgkifz5HybprGWKyYxVW8AYWJQ543s9cHd-yeBfH+WJHMA7Q@mail.gmail.com>

Hi,
I'm an italian guy that studies astrophysics.
I'm using Scipy's gaussian filter to smooth some images...
Could you tell me the meaning the unity of measure of the parameter sigma?

thanks

Gabriele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140131/498855c3/attachment.html>

From thomas.robitaille at gmail.com  Fri Jan 31 13:53:00 2014
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 31 Jan 2014 19:53:00 +0100
Subject: [AstroPy] Fwd: Gaussian filter
In-Reply-To: <CABmgkifz5HybprGWKyYxVW8AYWJQ543s9cHd-yeBfH+WJHMA7Q@mail.gmail.com>
References: <CABmgkid_7J546CHyq_fTnUL9oo-AyAXtd-aoJSihDOQ0YV4DZg@mail.gmail.com>
	<CABmgkifz5HybprGWKyYxVW8AYWJQ543s9cHd-yeBfH+WJHMA7Q@mail.gmail.com>
Message-ID: <CAGMHX_1ZnNXNyayLTkjn+7wZu-Kv386+tUR+9c_G3nJOyyHATQ@mail.gmail.com>

Hi Gabriele,

In Scipy's gaussian_filter, sigma is the standard deviation of the
Gaussian function in pixel units.

It is 'c' in the equation given here:
http://en.wikipedia.org/wiki/Gaussian_function

Cheers,
Tom

On 31 January 2014 19:48, Gabriele Brambilla
<gb.gabrielebrambilla at gmail.com> wrote:
> Hi,
> I'm an italian guy that studies astrophysics.
> I'm using Scipy's gaussian filter to smooth some images...
> Could you tell me the meaning the unity of measure of the parameter sigma?
>
> thanks
>
> Gabriele
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>