From mdroe at stsci.edu  Fri Nov  1 07:56:39 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Fri, 1 Nov 2013 07:56:39 -0400
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
Message-ID: <527396F7.9080503@stsci.edu>

On 10/31/2013 08:08 PM, Jacob Vanderplas wrote:
> Hello,
> I'm working on a problem that requires the inversion of SIP
> corrections: that is, I have points in world coordinates that I want
> to project onto an image plane.
>
> My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> forward transformation, as well as the (AP_p_q, BP_p_q) required for
> the backward transformation, according to the Shupe et al 2005
> reference.
>
> The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> which appeared to be what I needed, but these don't seem to actually
> invert each other. That is:
>
>>>> from astropy.wcs import WCS
>>>> wcs = WCS(header)
>>>> Xpix = [[1, 1]]
>>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
>>>> print wcs.sip_foc2pix(Xfoc, 0)
> [[ 1.2522118   1.74039233]]
>
> I would have expected this to recover the input pixels, but it's
> clearly not the case.  Is there any functionality in astropy that will
> utilize the available AP/BP coefficients in my header to perform the
> inverse SIP distortion?  Is there anything I'm doing wrong or missing
> here?
I would have expected the above to work.  Are we sure the AP* and BP* 
coeffs are a true inverse of the A* and B* ones?  You can send me the 
FITS file directly (off-list) and I'd be happy to have a look.

Mike


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

http://www.droettboom.com



From d.berry at jach.hawaii.edu  Fri Nov  1 13:40:13 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 1 Nov 2013 17:40:13 +0000
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <527396F7.9080503@stsci.edu>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
	<527396F7.9080503@stsci.edu>
Message-ID: <CAALafn5BWUxCeeqxkQgsg-RbbfG=z2OZ5HZ5rmf1WkXCNRd7yg@mail.gmail.com>

I've seen several SIP headers where the inverse transformation given by the
AP* BP* headers is a poor inverse of the forward transformation given by
the A* B* headers. In fact this issue was discussed recently on the astropy
list (subject "Running wcs_pix2world for all image pixels") in the context
of a header presented by Maik Riechert, which showed a similar problem.
>From that case I came to the conclusion that astropy ignroes the AP/BP
headers and creates its own inverse transformation based on the forward
transformation - maybe I was wrong.

For what it's worth, pyast does in fact do this - so it should always
provide a good inverse for a SIP header.

David


On 1 November 2013 11:56, Michael Droettboom <mdroe at stsci.edu> wrote:

> On 10/31/2013 08:08 PM, Jacob Vanderplas wrote:
> > Hello,
> > I'm working on a problem that requires the inversion of SIP
> > corrections: that is, I have points in world coordinates that I want
> > to project onto an image plane.
> >
> > My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> > forward transformation, as well as the (AP_p_q, BP_p_q) required for
> > the backward transformation, according to the Shupe et al 2005
> > reference.
> >
> > The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> > which appeared to be what I needed, but these don't seem to actually
> > invert each other. That is:
> >
> >>>> from astropy.wcs import WCS
> >>>> wcs = WCS(header)
> >>>> Xpix = [[1, 1]]
> >>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
> >>>> print wcs.sip_foc2pix(Xfoc, 0)
> > [[ 1.2522118   1.74039233]]
> >
> > I would have expected this to recover the input pixels, but it's
> > clearly not the case.  Is there any functionality in astropy that will
> > utilize the available AP/BP coefficients in my header to perform the
> > inverse SIP distortion?  Is there anything I'm doing wrong or missing
> > here?
> I would have expected the above to work.  Are we sure the AP* and BP*
> coeffs are a true inverse of the A* and B* ones?  You can send me the
> FITS file directly (off-list) and I'd be happy to have a look.
>
> Mike
>
>
> --
>                     _
> |\/|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/20131101/7b587765/attachment.html>

From stsci.perry at gmail.com  Fri Nov  1 13:43:30 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Fri, 1 Nov 2013 13:43:30 -0400
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <CAALafn5BWUxCeeqxkQgsg-RbbfG=z2OZ5HZ5rmf1WkXCNRd7yg@mail.gmail.com>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
	<527396F7.9080503@stsci.edu>
	<CAALafn5BWUxCeeqxkQgsg-RbbfG=z2OZ5HZ5rmf1WkXCNRd7yg@mail.gmail.com>
Message-ID: <9A2E88C3-4C00-42AB-9E90-D9C507C2B519@gmail.com>

At the very least, there should be a easy-to-use test of the supplied inverse to see how accurately it round trips, and a means of specifically using an iterative inverse based on the forward transform, even if an inverse has been provided.

Perry

On Nov 1, 2013, at 1:40 PM, David Berry wrote:

> I've seen several SIP headers where the inverse transformation given by the AP* BP* headers is a poor inverse of the forward transformation given by the A* B* headers. In fact this issue was discussed recently on the astropy list (subject "Running wcs_pix2world for all image pixels") in the context of a header presented by Maik Riechert, which showed a similar problem. From that case I came to the conclusion that astropy ignroes the AP/BP headers and creates its own inverse transformation based on the forward transformation - maybe I was wrong. 
> 
> For what it's worth, pyast does in fact do this - so it should always provide a good inverse for a SIP header.
> 
> David
> 
> 
> On 1 November 2013 11:56, Michael Droettboom <mdroe at stsci.edu> wrote:
> On 10/31/2013 08:08 PM, Jacob Vanderplas wrote:
> > Hello,
> > I'm working on a problem that requires the inversion of SIP
> > corrections: that is, I have points in world coordinates that I want
> > to project onto an image plane.
> >
> > My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> > forward transformation, as well as the (AP_p_q, BP_p_q) required for
> > the backward transformation, according to the Shupe et al 2005
> > reference.
> >
> > The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> > which appeared to be what I needed, but these don't seem to actually
> > invert each other. That is:
> >
> >>>> from astropy.wcs import WCS
> >>>> wcs = WCS(header)
> >>>> Xpix = [[1, 1]]
> >>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
> >>>> print wcs.sip_foc2pix(Xfoc, 0)
> > [[ 1.2522118   1.74039233]]
> >
> > I would have expected this to recover the input pixels, but it's
> > clearly not the case.  Is there any functionality in astropy that will
> > utilize the available AP/BP coefficients in my header to perform the
> > inverse SIP distortion?  Is there anything I'm doing wrong or missing
> > here?
> I would have expected the above to work.  Are we sure the AP* and BP*
> coeffs are a true inverse of the A* and B* ones?  You can send me the
> FITS file directly (off-list) and I'd be happy to have a look.
> 
> Mike
> 
> 
> --
>                     _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> 
> http://www.droettboom.com
> 
> _______________________________________________
> 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 npkuin at gmail.com  Fri Nov  1 14:25:26 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Fri, 1 Nov 2013 18:25:26 +0000
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <9A2E88C3-4C00-42AB-9E90-D9C507C2B519@gmail.com>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
	<527396F7.9080503@stsci.edu>
	<CAALafn5BWUxCeeqxkQgsg-RbbfG=z2OZ5HZ5rmf1WkXCNRd7yg@mail.gmail.com>
	<9A2E88C3-4C00-42AB-9E90-D9C507C2B519@gmail.com>
Message-ID: <CANoQ6N3fTFoyq2hvkNVXxbg_C9Je7XYeyLzbP3Uyeb3qfqZpEA@mail.gmail.com>

I think this should be part of the fits verification, not any thing else.
This should be easy to do as an additional check.

I'll send a note to the fitsio people as well.

Paul


On Fri, Nov 1, 2013 at 5:43 PM, Perry Greenfield <stsci.perry at gmail.com>wrote:

> At the very least, there should be a easy-to-use test of the supplied
> inverse to see how accurately it round trips, and a means of specifically
> using an iterative inverse based on the forward transform, even if an
> inverse has been provided.
>
> Perry
>
> On Nov 1, 2013, at 1:40 PM, David Berry wrote:
>
> > I've seen several SIP headers where the inverse transformation given by
> the AP* BP* headers is a poor inverse of the forward transformation given
> by the A* B* headers. In fact this issue was discussed recently on the
> astropy list (subject "Running wcs_pix2world for all image pixels") in the
> context of a header presented by Maik Riechert, which showed a similar
> problem. From that case I came to the conclusion that astropy ignroes the
> AP/BP headers and creates its own inverse transformation based on the
> forward transformation - maybe I was wrong.
> >
> > For what it's worth, pyast does in fact do this - so it should always
> provide a good inverse for a SIP header.
> >
> > David
> >
> >
> > On 1 November 2013 11:56, Michael Droettboom <mdroe at stsci.edu> wrote:
> > On 10/31/2013 08:08 PM, Jacob Vanderplas wrote:
> > > Hello,
> > > I'm working on a problem that requires the inversion of SIP
> > > corrections: that is, I have points in world coordinates that I want
> > > to project onto an image plane.
> > >
> > > My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> > > forward transformation, as well as the (AP_p_q, BP_p_q) required for
> > > the backward transformation, according to the Shupe et al 2005
> > > reference.
> > >
> > > The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> > > which appeared to be what I needed, but these don't seem to actually
> > > invert each other. That is:
> > >
> > >>>> from astropy.wcs import WCS
> > >>>> wcs = WCS(header)
> > >>>> Xpix = [[1, 1]]
> > >>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
> > >>>> print wcs.sip_foc2pix(Xfoc, 0)
> > > [[ 1.2522118   1.74039233]]
> > >
> > > I would have expected this to recover the input pixels, but it's
> > > clearly not the case.  Is there any functionality in astropy that will
> > > utilize the available AP/BP coefficients in my header to perform the
> > > inverse SIP distortion?  Is there anything I'm doing wrong or missing
> > > here?
> > I would have expected the above to work.  Are we sure the AP* and BP*
> > coeffs are a true inverse of the A* and B* ones?  You can send me the
> > FITS file directly (off-list) and I'd be happy to have a look.
> >
> > Mike
> >
> >
> > --
> >                     _
> > |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> > |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> >
> > http://www.droettboom.com
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131101/0cd7c784/attachment.html>

From lsinger at caltech.edu  Fri Nov  1 19:06:25 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Fri, 1 Nov 2013 19:06:25 -0400
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <mailman.0.1383325201.3328.astropy@scipy.org>
References: <mailman.0.1383325201.3328.astropy@scipy.org>
Message-ID: <E0D58F7C-502C-46ED-8B16-4048F5BF5B40@caltech.edu>

On Nov 1, 2013, at 1:00 PM, astropy-request at scipy.org wrote:

> Hello,
> I'm working on a problem that requires the inversion of SIP
> corrections: that is, I have points in world coordinates that I want
> to project onto an image plane.
> 
> My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> forward transformation, as well as the (AP_p_q, BP_p_q) required for
> the backward transformation, according to the Shupe et al 2005
> reference.
> 
> The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> which appeared to be what I needed, but these don't seem to actually
> invert each other. That is:
> 
>>>> from astropy.wcs import WCS
>>>> wcs = WCS(header)
>>>> Xpix = [[1, 1]]
>>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
>>>> print wcs.sip_foc2pix(Xfoc, 0)
> [[ 1.2522118   1.74039233]]
> 
> I would have expected this to recover the input pixels, but it's
> clearly not the case.  Is there any functionality in astropy that will
> utilize the available AP/BP coefficients in my header to perform the
> inverse SIP distortion?  Is there anything I'm doing wrong or missing
> here?
> Thanks,
>   Jake

Hi Jake,

One other option to be aware of: the development version of Astropy (what will be version 0.3) contains a new method WCS.all_world2pix that converts world to pixel coordinates. It uses an iterative scheme, so it's not exact but you can set the tolerance to be as accurate as you like.

See the documentation:
http://docs.astropy.org/en/latest/api/astropy.wcs.wcs.WCS.html#astropy.wcs.wcs.WCS.all_world2pix

See also the merged pull request:
https://github.com/astropy/astropy/pull/1281

Best,
Leo Singer
Graduate Student @ LIGO-Caltech


From stsci.perry at gmail.com  Mon Nov  4 11:12:35 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 4 Nov 2013 11:12:35 -0500
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
Message-ID: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>

Jonathan Eisenhamer suggested that astropy have a wikipedia entry. At this stage it seems like a good idea. On the other hand, wikipedia generally prefers such pages be created by more neutral individuals (that pretty much excludes the coordinators, and perhaps heavy committers to astropy). 

Is someone out there willing to take up the task of creating a wikipedia entry for astropy? We can help with details or supporting material if needed.

Thanks, Perry



From rays at blue-cove.com  Mon Nov  4 12:02:54 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 09:02:54 -0800
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
Message-ID: <201311041702.rA4H2uou011674@blue-cove.com>

Importantly, where should it be linked from in the Python wiki tree
https://en.wikipedia.org/wiki/List_of_Python_software
I'd presume Scientific Packages 
https://en.wikipedia.org/w/index.php?title=List_of_Python_software&action=edit&section=8
Is it "The Astropy Project" or "Astropy"? There at least needs to be 
a redirect.
I can create a stub following the numpy model easily.

Ray

At 08:12 AM 11/4/2013, Perry Greenfield wrote:
>Jonathan Eisenhamer suggested that astropy have a wikipedia entry. 
>At this stage it seems like a good idea. On the other hand, 
>wikipedia generally prefers such pages be created by more neutral 
>individuals (that pretty much excludes the coordinators, and perhaps 
>heavy committers to astropy).
>
>Is someone out there willing to take up the task of creating a 
>wikipedia entry for astropy? We can help with details or supporting 
>material if needed.
>
>Thanks, Perry
>
>_______________________________________________
>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/20131104/2350a042/attachment.html>

From rays at blue-cove.com  Mon Nov  4 12:46:26 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 09:46:26 -0800
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
Message-ID: <201311041746.rA4HkSEi027061@blue-cove.com>

At 08:12 AM 11/4/2013, Perry Greenfield wrote:
>Is someone out there willing to take up the task 
>of creating a wikipedia entry for astropy?

Stub:
http://en.wikipedia.org/wiki/Astropy
You really don't need to worry about editing as a 
main contributor; it is only the content (and 
importantly, supporting links and references) 
that matter. Further discussion of the entry 
could mainly be on the Talk Page 
https://en.wikipedia.org/w/index.php?title=Talk:Astropy&action=edit&redlink=1

 From https://en.wikipedia.org/wiki/Wikipedia:Introduction
"Don't be afraid to edit ? anyone can edit almost 
every page, and we are encouraged to 
<https://en.wikipedia.org/wiki/Wikipedia:Be_bold>be 
bold! Find something that can be improved and 
make it better?for example, spelling, grammar, 
rewriting for readability, adding content, or 
removing non-constructive edits. If you wish to 
add new facts, please try to provide 
<https://en.wikipedia.org/wiki/Help:Introduction_to_referencing/1>references 
so they may be 
<https://en.wikipedia.org/wiki/Wikipedia:Verifiability>verified, 
or suggest them on the article's 
<https://en.wikipedia.org/wiki/Help:Introduction_to_talk_pages>discussion 
page. Changes to controversial topics and 
Wikipedia's main pages should usually be discussed first.

Remember ? you can't break Wikipedia; all edits 
can be reversed, fixed or improved later. 
Wikipedia is 
<https://en.wikipedia.org/wiki/Wikipedia:Editing_policy>allowed 
to be imperfect. So go ahead, edit an article and 
help make Wikipedia the best information source on the Internet!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131104/20419ee2/attachment.html>

From pbarmby at uwo.ca  Mon Nov  4 13:25:55 2013
From: pbarmby at uwo.ca (Pauline Barmby)
Date: Mon, 04 Nov 2013 13:25:55 -0500
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <mailman.1.1383588001.21006.astropy@scipy.org>
References: <mailman.1.1383588001.21006.astropy@scipy.org>
Message-ID: <BA9B1D96-8FDA-443D-B8B7-BF8229506086@uwo.ca>

I'd be willing to write the initial version, although can't commit
to maintaining it.

Pauline Barmby
Department of Physics & Astronomy,  Western University
1151 Richmond St., London, ON N6A 3K7, Canada
pbarmby at uwo.ca







From Paul.A.Ries at jpl.nasa.gov  Mon Nov  4 13:47:42 2013
From: Paul.A.Ries at jpl.nasa.gov (Ries, Paul A (3265-Affiliate))
Date: Mon, 4 Nov 2013 18:47:42 +0000
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <201311041746.rA4HkSEi027061@blue-cove.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
Message-ID: <2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>

And unfortunately, after a mere 12 minutes of existence, the astropy wikipedia article has been nominated for deletion by a new page patroller:
https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy



For better or for worse, the key to a page surviving its first few days on wikipedia is establishing notability.  So the key to getting the page kept is adding references that establish notability.

The "official" guideline for notability:
https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline

An essay (i.e. less official, but still useful) regarding notability for software:
https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)

I think that pretty much the best way to achieve inclusion on wiki would be to establish that it's widely used in the astronomical community.  The best way I can think of is if there exist course pages from universities about using the software for astronomical purposes.  Those should be added as references.  Without those, though or something like them, it's likely the article will be deleted.... basically, the sources have to be independent of the astropy project pages and major contributors.  If you can find such sources, they can be added to the article using <ref>[http://www.university.edu/the/page.html]</ref>....

Source: experienced wiki editor with votes in over 80 deletion discussions

----Paul

On Nov 4, 2013, at 9:46 AM, RayS wrote:

At 08:12 AM 11/4/2013, Perry Greenfield wrote:
Is someone out there willing to take up the task of creating a wikipedia entry for astropy?

Stub:
http://en.wikipedia.org/wiki/Astropy
You really don't need to worry about editing as a main contributor; it is only the content (and importantly, supporting links and references) that matter. Further discussion of the entry could mainly be on the Talk Page https://en.wikipedia.org/w/index.php?title=Talk:Astropy&action=edit&redlink=1

>From https://en.wikipedia.org/wiki/Wikipedia:Introduction
"Don't be afraid to edit ? anyone can edit almost every page, and we are encouraged to be bold<https://en.wikipedia.org/wiki/Wikipedia:Be_bold>! Find something that can be improved and make it better?for example, spelling, grammar, rewriting for readability, adding content, or removing non-constructive edits. If you wish to add new facts, please try to provide references<https://en.wikipedia.org/wiki/Help:Introduction_to_referencing/1> so they may be verified<https://en.wikipedia.org/wiki/Wikipedia:Verifiability>, or suggest them on the article's discussion page<https://en.wikipedia.org/wiki/Help:Introduction_to_talk_pages>. Changes to controversial topics and Wikipedia's main pages should usually be discussed first.

Remember ? you can't break Wikipedia; all edits can be reversed, fixed or improved later. Wikipedia is allowed to be imperfect<https://en.wikipedia.org/wiki/Wikipedia:Editing_policy>. So go ahead, edit an article and help make Wikipedia the best information source on the Internet!"
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto: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/20131104/09d566c3/attachment.html>

From stsci.perry at gmail.com  Mon Nov  4 14:22:45 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 4 Nov 2013 14:22:45 -0500
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
Message-ID: <2CA78478-A55A-404D-9EC8-53D26045C249@gmail.com>


On Nov 4, 2013, at 1:47 PM, Ries, Paul A (3265-Affiliate) wrote:

> And unfortunately, after a mere 12 minutes of existence, the astropy wikipedia article has been nominated for deletion by a new page patroller:
> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy
> 
> 
> 
> For better or for worse, the key to a page surviving its first few days on wikipedia is establishing notability.  So the key to getting the page kept is adding references that establish notability.  
> 
> The "official" guideline for notability:
> https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline
> 
> An essay (i.e. less official, but still useful) regarding notability for software:
> https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)
> 
> I think that pretty much the best way to achieve inclusion on wiki would be to establish that it's widely used in the astronomical community.  The best way I can think of is if there exist course pages from universities about using the software for astronomical purposes.  Those should be added as references.  Without those, though or something like them, it's likely the article will be deleted.... basically, the sources have to be independent of the astropy project pages and major contributors.  If you can find such sources, they can be added to the article using <ref>[http://www.university.edu/the/page.html]</ref>....  
> 
> Source: experienced wiki editor with votes in over 80 deletion discussions
> 
> ----Paul

I can think of the following things that could be added:

- reference to the A&A paper
- a couple blog references (astrobetter, astrocompute, though I don't know how much these count)
- references to pyfits (since it is now in astropy), many of these could be obtained, but they are probably not direct references to astropy.io.fits, though we should have this added to the FITS listing of modules as the recommended reference.
- that it is part of some linux distributions

Or is your sense that it is premature at this point until more sites reference astropy?

While IRAF obviously has much wider use, it's wikipedia page is lacks much in the way of references (and as far as links go, the only one is to STScI as it turns out.)

Perry




From jturner at gemini.edu  Mon Nov  4 14:28:39 2013
From: jturner at gemini.edu (James Turner)
Date: Mon, 4 Nov 2013 16:28:39 -0300
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
Message-ID: <5277F567.70600@gemini.edu>

> The "official" guideline for notability:
> https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline

There's a lot of wiki-nerd jargon there, but digging a little bit,
I'd think github stats ought to help establish notability? Eg.:

   https://github.com/astropy/astropy/graphs/contributors

For example, NumPy cites this page, which is also a non-static
status reference:

   http://buildbot.pypy.org/numpy-status/latest.html

Also, whoever is an editor ought to be able to argue that
acceptance of such an article by A&A is notable in its own
right. The NumPy page also links to some conference presentations,
for which we have these:

   http://conference.scipy.org/scipy2013/presentation_detail.php?id=212
   http://adass2013.cfht.hawaii.edu/presenterdetails.php?id=221

I could add those myself but it would be anonymous (plus I'm
currently still the domain owner so don't look independent).

The guidelines say that non-commercial organizations are usually
notable if "the scope of their activities is national or
international in scale" and "information about the organization
and its activities can be verified by multiple,[1] third-party,
independent, reliable sources". Failing the above, I'd have
thought having a few prominent institutions link to the upcoming
3.0 announcement ought to do the trick?

Cheers,

James.



From jakevdp at cs.washington.edu  Mon Nov  4 14:27:24 2013
From: jakevdp at cs.washington.edu (Jacob Vanderplas)
Date: Mon, 4 Nov 2013 11:27:24 -0800
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <2CA78478-A55A-404D-9EC8-53D26045C249@gmail.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
	<2CA78478-A55A-404D-9EC8-53D26045C249@gmail.com>
Message-ID: <CACpqBg1+FLD_ctSkMUYZEK5pKmuZm=CQUoOniw+t9VpLQO7YPA@mail.gmail.com>

On Mon, Nov 4, 2013 at 11:22 AM, Perry Greenfield <stsci.perry at gmail.com> wrote:
> [clip]
>
> I can think of the following things that could be added:
>
> - reference to the A&A paper
> - a couple blog references (astrobetter, astrocompute, though I don't know how much these count)
> - references to pyfits (since it is now in astropy), many of these could be obtained, but they are probably not direct references to astropy.io.fits, though we should have this added to the FITS listing of modules as the recommended reference.
> - that it is part of some linux distributions

We might also mention that astropy is included (by default, I believe)
in the Anaconda installation, which means there are thousands who have
it installed, whether they use it or not!
   Jake

>
> Or is your sense that it is premature at this point until more sites reference astropy?
>
> While IRAF obviously has much wider use, it's wikipedia page is lacks much in the way of references (and as far as links go, the only one is to STScI as it turns out.)
>
> Perry
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From demitri.muna at gmail.com  Mon Nov  4 14:34:24 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Mon, 4 Nov 2013 14:34:24 -0500
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
Message-ID: <6DCEB57A-F387-44FF-907A-74041CBE6B90@gmail.com>


On Nov 4, 2013, at 1:47 PM, Ries, Paul A (3265-Affiliate) <Paul.A.Ries at jpl.nasa.gov> wrote:

> And unfortunately, after a mere 12 minutes of existence, the astropy wikipedia article has been nominated for deletion by a new page patroller:
> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy

Yeah, but the username of that page patroller is "IDL4Eva", so I'm somewhat suspicious.

_________________________________________
Demitri Muna

Department of Astronomy
An Ohio State University

http://scicoder.org/



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

From wkerzendorf at gmail.com  Mon Nov  4 14:58:38 2013
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Mon, 4 Nov 2013 14:58:38 -0500
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <6DCEB57A-F387-44FF-907A-74041CBE6B90@gmail.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
	<6DCEB57A-F387-44FF-907A-74041CBE6B90@gmail.com>
Message-ID: <2DFA27C7-6F4C-4EA4-BBF2-2D93A9E94567@gmail.com>

Sounds like a troll to me - I think there are enough keep?s already on wikipedia that it won?t disappear. 

Cheers,
   W
On Nov 4, 2013, at 2:34 PM, Demitri Muna <demitri.muna at gmail.com> wrote:

> 
> On Nov 4, 2013, at 1:47 PM, Ries, Paul A (3265-Affiliate) <Paul.A.Ries at jpl.nasa.gov> wrote:
> 
>> And unfortunately, after a mere 12 minutes of existence, the astropy wikipedia article has been nominated for deletion by a new page patroller:
>> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy
> 
> Yeah, but the username of that page patroller is "IDL4Eva", so I'm somewhat suspicious.
> 
> _________________________________________
> Demitri Muna
> 
> Department of Astronomy
> An Ohio State University
> 
> http://scicoder.org/
> 
> 
> 
> _______________________________________________
> 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/20131104/70ff545b/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/20131104/70ff545b/attachment.sig>

From rays at blue-cove.com  Mon Nov  4 15:07:12 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 12:07:12 -0800
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
In-Reply-To: <2CA78478-A55A-404D-9EC8-53D26045C249@gmail.com>
References: <27141511-E865-43A5-A3BF-647F43C960E1@gmail.com>
	<201311041746.rA4HkSEi027061@blue-cove.com>
	<2BDFE8C9-1D51-4EBD-936B-4422BFDF4134@jpl.nasa.gov>
	<2CA78478-A55A-404D-9EC8-53D26045C249@gmail.com>
Message-ID: <201311042007.rA4K7EuM004394@blue-cove.com>

At 11:22 AM 11/4/2013, Perry Greenfield wrote:
>I can think of the following things that could be added:
>
>- reference to the A&A paper

Which is in

References

, but the link to it could be moved

>- references to pyfits (since it is now in astropy), many of these 
>could be obtained, but they are probably not direct references to 
>astropy.io.fits, though we should have this added to the FITS 
>listing of modules as the recommended reference.
>- that it is part of some linux distributions
>
>Or is your sense that it is premature at this point until more sites 
>reference astropy?

Remember that it is only other Wikipedia pages which reference 
Astropy that count, unlike Google; proper references to the Astropy 
entry should be added to the other appropriate Categories and 
Python-related wiki pages, which anyone can do.

- Ray S 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131104/dc99f27d/attachment.html>

From rays at blue-cove.com  Mon Nov  4 15:08:16 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 12:08:16 -0800
Subject: [AstroPy] volunteers sought for  astropy wikipedia entry
Message-ID: <201311042008.rA4K8IoS006942@blue-cove.com>

And from his talk page, the reviewer appears to have an itchy finger.
I added the "under construction" which should prevent him from actual deletion.
I agree that notability is important for software 
listings. I think a list of notable important users would be next.
Would the list of 30 colloborators in The Astropy 
Collaboration  in 
http://www.aanda.org/articles/aa/abs/2013/10/aa22068-13/aa22068-13.html
be appropriate? They are certainly users, and themselves notable in the field.

- Ray S


At 10:47 AM 11/4/2013, Ries, Paul A (3265-Affiliate) wrote:
>And unfortunately, after a mere 12 minutes of 
>existence, the astropy wikipedia article has 
>been nominated for deletion by a new page patroller:
><https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy>https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy
>
>
>
>For better or for worse, the key to a page 
>surviving its first few days on wikipedia is 
>establishing notability.  So the key to getting 
>the page kept is adding references that establish notability.
>
>The "official" guideline for notability:
><https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline>https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline
>
>An essay (i.e. less official, but still useful) 
>regarding notability for software:
><https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)>https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)
>
>I think that pretty much the best way to achieve 
>inclusion on wiki would be to establish that 
>it's widely used in the astronomical 
>community.  The best way I can think of is if 
>there exist course pages from universities about 
>using the software for astronomical 
>purposes.  Those should be added as 
>references.  Without those, though or something 
>like them, it's likely the article will be 
>deleted.... basically, the sources have to be 
>independent of the astropy project pages and 
>major contributors.  If you can find such 
>sources, they can be added to the article using 
><ref>[http://www.university.edu/the/page.html]</ref>....
>
>Source: experienced wiki editor with votes in over 80 deletion discussions
>
>----Paul
>
>On Nov 4, 2013, at 9:46 AM, RayS wrote:
>
>>At 08:12 AM 11/4/2013, Perry Greenfield wrote:
>>>Is someone out there willing to take up the 
>>>task of creating a wikipedia entry for astropy?
>>
>>Stub:
>>http://en.wikipedia.org/wiki/Astropy
>>You really don't need to worry about editing as 
>>a main contributor; it is only the content (and 
>>importantly, supporting links and references) 
>>that matter. Further discussion of the entry 
>>could mainly be on the Talk Page 
>>https://en.wikipedia.org/w/index.php?title=Talk:Astropy&action=edit&redlink=1
>>
>> >From https://en.wikipedia.org/wiki/Wikipedia:Introduction
>>"Don't be afraid to edit ? anyone can edit 
>>almost every page, and we are encouraged to 
>><https://en.wikipedia.org/wiki/Wikipedia:Be_bold>be 
>>bold! Find something that can be improved and 
>>make it better?for example, spelling, grammar, 
>>rewriting for readability, adding content, or 
>>removing non-constructive edits. If you wish to 
>>add new facts, please try to provide 
>><https://en.wikipedia.org/wiki/Help:Introduction_to_referencing/1>references 
>>so they may be 
>><https://en.wikipedia.org/wiki/Wikipedia:Verifiability>verified, 
>>or suggest them on the article's 
>><https://en.wikipedia.org/wiki/Help:Introduction_to_talk_pages>discussion 
>>page. Changes to controversial topics and 
>>Wikipedia's main pages should usually be discussed first.
>>
>>Remember ? you can't break Wikipedia; all edits 
>>can be reversed, fixed or improved later. 
>>Wikipedia is 
>><https://en.wikipedia.org/wiki/Wikipedia:Editing_policy>allowed 
>>to be imperfect. So go ahead, edit an article 
>>and help make Wikipedia the best information source on the Internet!"
>>_______________________________________________
>>AstroPy mailing list
>><mailto:AstroPy at scipy.org>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131104/547011a2/attachment.html>

From rays at blue-cove.com  Mon Nov  4 17:14:20 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 14:14:20 -0800
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.g
	mail.com>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
Message-ID: <201311042214.rA4MEMTC011240@blue-cove.com>

At 12:29 PM 11/4/2013, Thomas Robitaille wrote:
>- links to the affiliated packages

more need to be added

>- 54 international developers have contributed so far, including
>developers at notable institutions such the Space Telescope Science
>Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
>Planck Society, etc. (and you can link to their wikipedia pages)

~28 institutions are added from http://dx.doi.org/10.1051/0004-6361/201322068

>- you could add a logo? (attached)

the logo should have a clear copyright statement associated, 
Wikipedia is very picky, understandably
https://en.wikipedia.org/wiki/File:Logo_of_the_Astropy_Project.png
As the logo of an organization, they want a Fair Use description, "To 
the uploader: Please add a detailed 
<https://en.wikipedia.org/wiki/Wikipedia:Non-free_use_rationale_guideline>fair 
use rationale for each use, as well as the source of the work and 
copyright information. "

>Thanks for your work on this! In any case, make sure that you save the
>content you do write so that we can try again in future.

If others made occasional edits, the entry should be safe from the 
deletion fanatics.

Glad to be of help to the Python community, but back to work for now 
;)  Maybe someday I'll polish up my LX200 module...

- Ray S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131104/a722516b/attachment.html>

From derek at astro.physik.uni-goettingen.de  Mon Nov  4 18:33:03 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Tue, 5 Nov 2013 00:33:03 +0100
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <201311042214.rA4MEMTC011240@blue-cove.com>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
Message-ID: <1052E81D-A6FE-494F-8B4A-1BE438E30192@astro.physik.uni-goettingen.de>

On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:

>> - 54 international developers have contributed so far, including
>> developers at notable institutions such the Space Telescope Science
>> Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
>> Planck Society, etc. (and you can link to their wikipedia pages)
> 
> ~28 institutions are added from http://dx.doi.org/10.1051/0004-6361/201322068
> 
Actually as it is the list almost appears a bit overwhelming (at least it quite dominates
the present page), but this will probably balance out as content to the main sections
is added...
> 
>> Thanks for your work on this! In any case, make sure that you save the
>> content you do write so that we can try again in future.
> 
> If others made occasional edits, the entry should be safe from the deletion fanatics.

I've added references to some Linux and OS X packages (Debian, MacPorts and Fink
being the only ones I was aware of right away - perhaps somewhere on the main
astropy page there could also be a list of packages and maintainers?).
And I back-referenced the page from the FITS page, hope this helps a bit.

Thanks for your efforts as well!

						Derek



From derek at astro.physik.uni-goettingen.de  Mon Nov  4 18:54:21 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Tue, 5 Nov 2013 00:54:21 +0100
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <201311042214.rA4MEMTC011240@blue-cove.com>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
Message-ID: <F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>

On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:

>> 
>> Thanks for your work on this! In any case, make sure that you save the
>> content you do write so that we can try again in future.
> 
> If others made occasional edits, the entry should be safe from the deletion fanatics.

Anyone has the number of subscribers to this list at hand? Another wannabe neighbourhood
watchman is now threatening a Sockpuppet investigation (i.e., I think, they are suspecting a
single person operating under multiple user names editing the page)!

						Derek



From stsci.perry at gmail.com  Mon Nov  4 19:02:10 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 4 Nov 2013 19:02:10 -0500
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
	<F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>
Message-ID: <FDA6A406-8FE1-4927-B6BB-F8B8B2296197@gmail.com>

currently 608

On Nov 4, 2013, at 6:54 PM, Derek Homeier wrote:

> On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
> 
>>> 
>>> Thanks for your work on this! In any case, make sure that you save the
>>> content you do write so that we can try again in future.
>> 
>> If others made occasional edits, the entry should be safe from the deletion fanatics.
> 
> Anyone has the number of subscribers to this list at hand? Another wannabe neighbourhood
> watchman is now threatening a Sockpuppet investigation (i.e., I think, they are suspecting a
> single person operating under multiple user names editing the page)!
> 
> 						Derek
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From rays at blue-cove.com  Mon Nov  4 19:02:24 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 16:02:24 -0800
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <1052E81D-A6FE-494F-8B4A-1BE438E30192@astro.physik.uni-goet
	tingen.de>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
	<1052E81D-A6FE-494F-8B4A-1BE438E30192@astro.physik.uni-goettingen.de>
Message-ID: <201311050002.rA502RoP026704@blue-cove.com>

At 03:33 PM 11/4/2013, Derek Homeier wrote:
>On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
>
> >> - 54 international developers have contributed so far, including
> >> developers at notable institutions such the Space Telescope Science
> >> Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
> >> Planck Society, etc. (and you can link to their wikipedia pages)
> >
> > ~28 institutions are added from 
> http://dx.doi.org/10.1051/0004-6361/201322068
> >
>Actually as it is the list almost appears a bit overwhelming (at 
>least it quite dominates
>the present page), but this will probably balance out as content to 
>the main sections
>is added...

Ultimately, most of that list should be pushed down into the 
References (which are automagically generated from <ref></ref>), as 
those users' publications are linked from the text body above. The 
Python main page
https://en.wikipedia.org/wiki/Python_%28programming_language%29
is a good example.
Look at the sections it incorporates, and think of where published 
items could be added to Astropy - I think ==Use== and ==Impact== 
would be good to include, and professionals' entries included therein 
with <ref> tags.

Python Contents
1 History
2 Features and philosophy
3 Syntax and semantics
3.1 Indentation
3.2 Statements and control flow
3.3 Expressions
3.4 Methods
3.5 Typing
3.6 Mathematics
4 Libraries
5 Development environments
6 Implementations
7 Development
8 Naming
9 Use
10 Impact
11 See also
12 References
13 Further reading
14 External links


- Ray S




From derek at astro.physik.uni-goettingen.de  Mon Nov  4 19:31:09 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Tue, 5 Nov 2013 01:31:09 +0100
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <CAKxLWdid9Ea3KVcYzFAGg0_23-m0JpXE0rVrWFW_8by2pgMFvA@mail.gmail.com>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
	<F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>
	<CAKxLWdid9Ea3KVcYzFAGg0_23-m0JpXE0rVrWFW_8by2pgMFvA@mail.gmail.com>
Message-ID: <875374A7-4616-45FD-AA6C-96D776A6967D@astro.physik.uni-goettingen.de>

Hi Philip,

On 05.11.2013, at 1:02AM, Philip Tait <philip at naoj.org> wrote:

> Would it help to have links to major projects using Astropy, e.g.: http://www.naoj.org/Projects/HSC/
> 
> Let me know if I can help.

thanks for the link; yes, it seems external links and cross-references to/from other
Wikipedia pages are the main support to show this is not just some sort of inbred
project! It would probably be even better if there is an online reference to the use
of astropy on that page. But I'd say this fits perfectly into the ==Use== section proposed
by Ray:

> The Python main page
> https://en.wikipedia.org/wiki/Python_%28programming_language%29
> is a good example.
> Look at the sections it incorporates, and think of where published 
> items could be added to Astropy - I think ==Use== and ==Impact== 
> would be good to include, and professionals' entries included therein 
> with <ref> tags.

Since Ray has taken care of the page and its overall architecture, I'd leave it up to him
how to include this best.

Cheers,
						Derek



From willettk at colorado.edu  Mon Nov  4 20:03:30 2013
From: willettk at colorado.edu (Kyle Willett)
Date: Mon, 4 Nov 2013 19:03:30 -0600
Subject: [AstroPy] AstroPy Digest, Vol 86, Issue 5
In-Reply-To: <mailman.3543.1383609415.1002.astropy@scipy.org>
References: <mailman.3543.1383609415.1002.astropy@scipy.org>
Message-ID: <CAKgCMQiX=9DHjWUnvLOXnOG_S6su6SpH_9+0+q_=2FTnYjoRLA@mail.gmail.com>

Sockpuppet investigation is something we badly want to avoid - they're
usually loud accusations of finger pointing on both sides, but with little
proof, suspicion never seems to go away.

If you're making an edit to the page, make sure that you're logged into
your Wikipedia account so that they can see multiple users are editing the
site. Particularly, if you vote on the deletion status of the article (
https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy),
sign your comment with four tildes (~~~~) at the end of your vote. That
will create an automatic user ID and timestamp; this will help demonstrate
that we are in fact many independent users working and supporting the
article, not just sockpuppet accounts.

- Kyle


On 4 November 2013 17:56, <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. Re: volunteers sought for  astropy wikipedia entry (RayS)
>    2. Re: volunteers sought for  astropy wikipedia entry (RayS)
>    3. Re: volunteers sought for astropy wikipedia entry (RayS)
>    4. Re: volunteers sought for astropy wikipedia entry (Derek Homeier)
>    5. Re: volunteers sought for astropy wikipedia entry (Derek Homeier)
>    6. Re: volunteers sought for astropy wikipedia entry
>       (Perry Greenfield)
>    7. Re: volunteers sought for astropy wikipedia entry (RayS)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 Nov 2013 12:07:12 -0800
> From: RayS <rays at blue-cove.com>
> Subject: Re: [AstroPy] volunteers sought for  astropy wikipedia entry
> To: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <201311042007.rA4K7EuM004394 at blue-cove.com>
> Content-Type: text/plain; charset="us-ascii"
>
> At 11:22 AM 11/4/2013, Perry Greenfield wrote:
> >I can think of the following things that could be added:
> >
> >- reference to the A&A paper
>
> Which is in
>
> References
>
> , but the link to it could be moved
>
> >- references to pyfits (since it is now in astropy), many of these
> >could be obtained, but they are probably not direct references to
> >astropy.io.fits, though we should have this added to the FITS
> >listing of modules as the recommended reference.
> >- that it is part of some linux distributions
> >
> >Or is your sense that it is premature at this point until more sites
> >reference astropy?
>
> Remember that it is only other Wikipedia pages which reference
> Astropy that count, unlike Google; proper references to the Astropy
> entry should be added to the other appropriate Categories and
> Python-related wiki pages, which anyone can do.
>
> - Ray S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131104/dc99f27d/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 04 Nov 2013 12:08:16 -0800
> From: RayS <rays at blue-cove.com>
> Subject: Re: [AstroPy] volunteers sought for  astropy wikipedia entry
> To: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <201311042008.rA4K8IoS006942 at blue-cove.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> And from his talk page, the reviewer appears to have an itchy finger.
> I added the "under construction" which should prevent him from actual
> deletion.
> I agree that notability is important for software
> listings. I think a list of notable important users would be next.
> Would the list of 30 colloborators in The Astropy
> Collaboration  in
> http://www.aanda.org/articles/aa/abs/2013/10/aa22068-13/aa22068-13.html
> be appropriate? They are certainly users, and themselves notable in the
> field.
>
> - Ray S
>
>
> At 10:47 AM 11/4/2013, Ries, Paul A (3265-Affiliate) wrote:
> >And unfortunately, after a mere 12 minutes of
> >existence, the astropy wikipedia article has
> >been nominated for deletion by a new page patroller:
> ><https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy>
> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Astropy
> >
> >
> >
> >For better or for worse, the key to a page
> >surviving its first few days on wikipedia is
> >establishing notability.  So the key to getting
> >the page kept is adding references that establish notability.
> >
> >The "official" guideline for notability:
> ><https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline
> >https://en.wikipedia.org/wiki/Wikipedia:GNG#General_notability_guideline
> >
> >An essay (i.e. less official, but still useful)
> >regarding notability for software:
> ><https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)>
> https://en.wikipedia.org/wiki/Wikipedia:Notability_(software)
> >
> >I think that pretty much the best way to achieve
> >inclusion on wiki would be to establish that
> >it's widely used in the astronomical
> >community.  The best way I can think of is if
> >there exist course pages from universities about
> >using the software for astronomical
> >purposes.  Those should be added as
> >references.  Without those, though or something
> >like them, it's likely the article will be
> >deleted.... basically, the sources have to be
> >independent of the astropy project pages and
> >major contributors.  If you can find such
> >sources, they can be added to the article using
> ><ref>[http://www.university.edu/the/page.html]</ref>....
> >
> >Source: experienced wiki editor with votes in over 80 deletion discussions
> >
> >----Paul
> >
> >On Nov 4, 2013, at 9:46 AM, RayS wrote:
> >
> >>At 08:12 AM 11/4/2013, Perry Greenfield wrote:
> >>>Is someone out there willing to take up the
> >>>task of creating a wikipedia entry for astropy?
> >>
> >>Stub:
> >>http://en.wikipedia.org/wiki/Astropy
> >>You really don't need to worry about editing as
> >>a main contributor; it is only the content (and
> >>importantly, supporting links and references)
> >>that matter. Further discussion of the entry
> >>could mainly be on the Talk Page
> >>
> https://en.wikipedia.org/w/index.php?title=Talk:Astropy&action=edit&redlink=1
> >>
> >> >From https://en.wikipedia.org/wiki/Wikipedia:Introduction
> >>"Don't be afraid to edit ? anyone can edit
> >>almost every page, and we are encouraged to
> >><https://en.wikipedia.org/wiki/Wikipedia:Be_bold>be
> >>bold! Find something that can be improved and
> >>make it better?for example, spelling, grammar,
> >>rewriting for readability, adding content, or
> >>removing non-constructive edits. If you wish to
> >>add new facts, please try to provide
> >><https://en.wikipedia.org/wiki/Help:Introduction_to_referencing/1
> >references
> >>so they may be
> >><https://en.wikipedia.org/wiki/Wikipedia:Verifiability>verified,
> >>or suggest them on the article's
> >><https://en.wikipedia.org/wiki/Help:Introduction_to_talk_pages
> >discussion
> >>page. Changes to controversial topics and
> >>Wikipedia's main pages should usually be discussed first.
> >>
> >>Remember ? you can't break Wikipedia; all edits
> >>can be reversed, fixed or improved later.
> >>Wikipedia is
> >><https://en.wikipedia.org/wiki/Wikipedia:Editing_policy>allowed
> >>to be imperfect. So go ahead, edit an article
> >>and help make Wikipedia the best information source on the Internet!"
> >>_______________________________________________
> >>AstroPy mailing list
> >><mailto:AstroPy at scipy.org>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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131104/547011a2/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 04 Nov 2013 14:14:20 -0800
> From: RayS <rays at blue-cove.com>
> Subject: Re: [AstroPy] volunteers sought for astropy wikipedia entry
> To: Thomas Robitaille <thomas.robitaille at gmail.com>,
>         "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <201311042214.rA4MEMTC011240 at blue-cove.com>
> Content-Type: text/plain; charset="us-ascii"
>
> At 12:29 PM 11/4/2013, Thomas Robitaille wrote:
> >- links to the affiliated packages
>
> more need to be added
>
> >- 54 international developers have contributed so far, including
> >developers at notable institutions such the Space Telescope Science
> >Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
> >Planck Society, etc. (and you can link to their wikipedia pages)
>
> ~28 institutions are added from
> http://dx.doi.org/10.1051/0004-6361/201322068
>
> >- you could add a logo? (attached)
>
> the logo should have a clear copyright statement associated,
> Wikipedia is very picky, understandably
> https://en.wikipedia.org/wiki/File:Logo_of_the_Astropy_Project.png
> As the logo of an organization, they want a Fair Use description, "To
> the uploader: Please add a detailed
> <https://en.wikipedia.org/wiki/Wikipedia:Non-free_use_rationale_guideline
> >fair
> use rationale for each use, as well as the source of the work and
> copyright information. "
>
> >Thanks for your work on this! In any case, make sure that you save the
> >content you do write so that we can try again in future.
>
> If others made occasional edits, the entry should be safe from the
> deletion fanatics.
>
> Glad to be of help to the Python community, but back to work for now
> ;)  Maybe someday I'll polish up my LX200 module...
>
> - Ray S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131104/a722516b/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Nov 2013 00:33:03 +0100
> From: Derek Homeier <derek at astro.physik.uni-goettingen.de>
> Subject: Re: [AstroPy] volunteers sought for astropy wikipedia entry
> To: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID:
>         <
> 1052E81D-A6FE-494F-8B4A-1BE438E30192 at astro.physik.uni-goettingen.de>
> Content-Type: text/plain; charset=us-ascii
>
> On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
>
> >> - 54 international developers have contributed so far, including
> >> developers at notable institutions such the Space Telescope Science
> >> Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
> >> Planck Society, etc. (and you can link to their wikipedia pages)
> >
> > ~28 institutions are added from
> http://dx.doi.org/10.1051/0004-6361/201322068
> >
> Actually as it is the list almost appears a bit overwhelming (at least it
> quite dominates
> the present page), but this will probably balance out as content to the
> main sections
> is added...
> >
> >> Thanks for your work on this! In any case, make sure that you save the
> >> content you do write so that we can try again in future.
> >
> > If others made occasional edits, the entry should be safe from the
> deletion fanatics.
>
> I've added references to some Linux and OS X packages (Debian, MacPorts
> and Fink
> being the only ones I was aware of right away - perhaps somewhere on the
> main
> astropy page there could also be a list of packages and maintainers?).
> And I back-referenced the page from the FITS page, hope this helps a bit.
>
> Thanks for your efforts as well!
>
>                                                 Derek
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Nov 2013 00:54:21 +0100
> From: Derek Homeier <derek at astro.physik.uni-goettingen.de>
> Subject: Re: [AstroPy] volunteers sought for astropy wikipedia entry
> To: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID:
>         <
> F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0 at astro.physik.uni-goettingen.de>
> Content-Type: text/plain; charset=us-ascii
>
> On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
>
> >>
> >> Thanks for your work on this! In any case, make sure that you save the
> >> content you do write so that we can try again in future.
> >
> > If others made occasional edits, the entry should be safe from the
> deletion fanatics.
>
> Anyone has the number of subscribers to this list at hand? Another wannabe
> neighbourhood
> watchman is now threatening a Sockpuppet investigation (i.e., I think,
> they are suspecting a
> single person operating under multiple user names editing the page)!
>
>                                                 Derek
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 4 Nov 2013 19:02:10 -0500
> From: Perry Greenfield <stsci.perry at gmail.com>
> Subject: Re: [AstroPy] volunteers sought for astropy wikipedia entry
> To: Derek Homeier <derek at astro.physik.uni-goettingen.de>
> Cc: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <FDA6A406-8FE1-4927-B6BB-F8B8B2296197 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> currently 608
>
> On Nov 4, 2013, at 6:54 PM, Derek Homeier wrote:
>
> > On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
> >
> >>>
> >>> Thanks for your work on this! In any case, make sure that you save the
> >>> content you do write so that we can try again in future.
> >>
> >> If others made occasional edits, the entry should be safe from the
> deletion fanatics.
> >
> > Anyone has the number of subscribers to this list at hand? Another
> wannabe neighbourhood
> > watchman is now threatening a Sockpuppet investigation (i.e., I think,
> they are suspecting a
> > single person operating under multiple user names editing the page)!
> >
> >                                               Derek
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 04 Nov 2013 16:02:24 -0800
> From: RayS <rays at blue-cove.com>
> Subject: Re: [AstroPy] volunteers sought for astropy wikipedia entry
> To: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <201311050002.rA502RoP026704 at blue-cove.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 03:33 PM 11/4/2013, Derek Homeier wrote:
> >On 04.11.2013, at 11:14PM, RayS <rays at blue-cove.com> wrote:
> >
> > >> - 54 international developers have contributed so far, including
> > >> developers at notable institutions such the Space Telescope Science
> > >> Institute, the Harvard-Smithsonian Center for Astrophysics, the Max
> > >> Planck Society, etc. (and you can link to their wikipedia pages)
> > >
> > > ~28 institutions are added from
> > http://dx.doi.org/10.1051/0004-6361/201322068
> > >
> >Actually as it is the list almost appears a bit overwhelming (at
> >least it quite dominates
> >the present page), but this will probably balance out as content to
> >the main sections
> >is added...
>
> Ultimately, most of that list should be pushed down into the
> References (which are automagically generated from <ref></ref>), as
> those users' publications are linked from the text body above. The
> Python main page
> https://en.wikipedia.org/wiki/Python_%28programming_language%29
> is a good example.
> Look at the sections it incorporates, and think of where published
> items could be added to Astropy - I think ==Use== and ==Impact==
> would be good to include, and professionals' entries included therein
> with <ref> tags.
>
> Python Contents
> 1 History
> 2 Features and philosophy
> 3 Syntax and semantics
> 3.1 Indentation
> 3.2 Statements and control flow
> 3.3 Expressions
> 3.4 Methods
> 3.5 Typing
> 3.6 Mathematics
> 4 Libraries
> 5 Development environments
> 6 Implementations
> 7 Development
> 8 Naming
> 9 Use
> 10 Impact
> 11 See also
> 12 References
> 13 Further reading
> 14 External links
>
>
> - Ray S
>
>
>
>
> ------------------------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
> End of AstroPy Digest, Vol 86, Issue 5
> **************************************
>



-- 
Kyle Willett
Center for Astrophysics and Space Astronomy
University of Colorado
willettk [at] colorado.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131104/86ed48cc/attachment.html>

From rays at blue-cove.com  Mon Nov  4 20:40:48 2013
From: rays at blue-cove.com (RayS)
Date: Mon, 04 Nov 2013 17:40:48 -0800
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <875374A7-4616-45FD-AA6C-96D776A6967D@astro.physik.uni-goet
	tingen.de>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
	<F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>
	<CAKxLWdid9Ea3KVcYzFAGg0_23-m0JpXE0rVrWFW_8by2pgMFvA@mail.gmail.com>
	<875374A7-4616-45FD-AA6C-96D776A6967D@astro.physik.uni-goettingen.de>
Message-ID: <201311050140.rA51eqfQ004022@blue-cove.com>

At 04:31 PM 11/4/2013, Derek Homeier wrote:
><snip>
>thanks for the link; yes, it seems external links and 
>cross-references to/from other
>Wikipedia pages are the main support to show this is not just some 
>sort of inbred
>project! It would probably be even better if there is an online 
>reference to the use
>of astropy on that page. But I'd say this fits perfectly into the 
>==Use== section proposed

I added the use section, and added a few starters; the methodology 
was to use Google Scholar to search for references:
http://scholar.google.com/scholar?start=10&q=astropy&hl=en&as_sdt=0,5
then use <ref>{{cite  ...  }}</ref> template to insert the references 
https://en.wikipedia.org/wiki/Wikipedia:Citation_templates
Ex:
<ref>{{cite journal
| url=http://arxiv.org/pdf/1307.5851v4
| title=Discovery and redshift of an optical afterglow in 71 square 
degrees: iPTF13bxl and GRB 130702A
}}</ref>

There are of course a lot more...

  -Ray S




From erwin at mpe.mpg.de  Tue Nov  5 04:18:30 2013
From: erwin at mpe.mpg.de (Peter Erwin)
Date: Tue, 5 Nov 2013 10:18:30 +0100
Subject: [AstroPy] volunteers sought for astropy wikipedia entry
In-Reply-To: <201311050140.rA51eqfQ004022@blue-cove.com>
References: <201311042008.rA4K8IoS006942@blue-cove.com>
	<CAGMHX_1Q5x9UoRFbSWAq_NdeEZ2wpxbTykQGp1LXaMmoq7q7SA@mail.gmail.com>
	<201311042214.rA4MEMTC011240@blue-cove.com>
	<F71B3DFA-6CE2-4E98-95A1-9F341FAF83E0@astro.physik.uni-goettingen.de>
	<CAKxLWdid9Ea3KVcYzFAGg0_23-m0JpXE0rVrWFW_8by2pgMFvA@mail.gmail.com>
	<875374A7-4616-45FD-AA6C-96D776A6967D@astro.physik.uni-goettingen.de>
	<201311050140.rA51eqfQ004022@blue-cove.com>
Message-ID: <56A810CA-9906-4245-9BD9-054C21201C62@mpe.mpg.de>


On Nov 5, 2013, at 2:40 AM, RayS <rays at blue-cove.com> wrote:

> At 04:31 PM 11/4/2013, Derek Homeier wrote:
>> <snip>
>> thanks for the link; yes, it seems external links and 
>> cross-references to/from other
>> Wikipedia pages are the main support to show this is not just some 
>> sort of inbred
>> project! It would probably be even better if there is an online 
>> reference to the use
>> of astropy on that page. But I'd say this fits perfectly into the 
>> ==Use== section proposed
> 
> I added the use section, and added a few starters; the methodology 
> was to use Google Scholar to search for references:
> http://scholar.google.com/scholar?start=10&q=astropy&hl=en&as_sdt=0,5
> then use <ref>{{cite  ...  }}</ref> template to insert the references 
> https://en.wikipedia.org/wiki/Wikipedia:Citation_templates
> Ex:
> <ref>{{cite journal
> | url=http://arxiv.org/pdf/1307.5851v4
> | title=Discovery and redshift of an optical afterglow in 71 square 
> degrees: iPTF13bxl and GRB 130702A
> }}</ref>
> 
> There are of course a lot more...

Using the full-text search option at ADS turns up a total of 12 (including the already-mentioned
ones):
http://labs.adsabs.harvard.edu/adsabs/search/?q=+full%3A%22AstroPy%22&db_f=astronomy&year_f=[2011%20TO%202013]

(I'll let someone more familiar with Wikipedia's quirks decide which would be best to include.)

cheers,

Peter

=============================================================
Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
erwin at mpe.mpg.de              Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713     85748 Garching, Germany
fax  +49 (0)89 30000 3495     http://www.mpe.mpg.de/~erwin





From yannick.roehlly at lam.fr  Thu Nov  7 16:20:37 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Thu, 7 Nov 2013 22:20:37 +0100
Subject: [AstroPy] FITS files and column descriptions
Message-ID: <20131107222037.24a5ab74@lam.fr>

Hi all,

I have some remarks / questions concerning the column descriptions in
FITS table files (and VO).

1. Long column description

The FITS format requires that a column description must be 68
characters or less. Some tools like topcat / stills allows longer
descriptions because they use a kind of VO-table metada section in the
FITS header. If you open such file with astropy.io.fits and save it
again, you loose the long description. In fact, it's not an astropy
problem as these description as not in the "real FITS" column
descriptions in the header (TCOMxx), it is just because astropy does
not save the "VO-table" part of the topcat file.
Maybe it's worth raising a warning when opening such files, like "Hey,
you may loose metadata!" because one may be surprise not to have all
its column description.

2. astropy.table and column descriptions in FITS files

When opening a FITS file with astropy.tables(with last git checkout)
one does not have access to column descriptions. When saving an
astropy.io.table to FITS, the column description are lost. But when
opening a FITS file with description and saving it again to FITS, the
column descriptions are still here. I suppose that it's because
astropy.io.fits is under the hood. 

Is this because column description handling is not implemented or do I
miss something?

3. Column descriptions in VO-Table

When saving a table to VO-Table, astropy prettily indent the xml, e.g.

    <DESCRIPTION>
     IAU Name
    </DESCRIPTION>

But when reading these tables with topcat, this one add the spaces to
the description ("     IAU Name"). Maybe astropy should write the
description on one line.

Regards,

Yannick

-- 
Mystics always hope that science will some day overtake them.
		-- Booth Tarkington


From npkuin at gmail.com  Thu Nov  7 16:59:46 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Thu, 7 Nov 2013 21:59:46 +0000
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <20131107222037.24a5ab74@lam.fr>
References: <20131107222037.24a5ab74@lam.fr>
Message-ID: <CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>

Some years ago, I was leading the NASA Astronomical Data Center, now gone.
I worked with CDS to have a way to present a readable table along with the
ability to automatically generate a FITS file.  That lead to the "ReadMe"
files that accompany the catalogs from CDS, which is storing the metadata.

I think it is important to make sure no metadata are lost in the conversion
process. Sure, the FITS standard says so-and-so, but in practice, one has
to make amends so the standard can evolve.

I have only used the astropy saving to tables a little bit because I got
annoyed that there was loss of (meta) data.

The reason I write is, that there needs to be some serious thought about
this issue. as flagged by Yannick. My (biased) feeling  is that you cannot
go around having a second metadata file when going to ascii. Doing
otherwise will lead to a plethora of ways to save the data file. Better to
keep the data file clean, and put the jumk in a meta data file.

Cheers,

   Paul


On Thu, Nov 7, 2013 at 9:20 PM, Yannick Roehlly <yannick.roehlly at lam.fr>wrote:

> Hi all,
>
> I have some remarks / questions concerning the column descriptions in
> FITS table files (and VO).
>
> 1. Long column description
>
> The FITS format requires that a column description must be 68
> characters or less. Some tools like topcat / stills allows longer
> descriptions because they use a kind of VO-table metada section in the
> FITS header. If you open such file with astropy.io.fits and save it
> again, you loose the long description. In fact, it's not an astropy
> problem as these description as not in the "real FITS" column
> descriptions in the header (TCOMxx), it is just because astropy does
> not save the "VO-table" part of the topcat file.
> Maybe it's worth raising a warning when opening such files, like "Hey,
> you may loose metadata!" because one may be surprise not to have all
> its column description.
>
> 2. astropy.table and column descriptions in FITS files
>
> When opening a FITS file with astropy.tables(with last git checkout)
> one does not have access to column descriptions. When saving an
> astropy.io.table to FITS, the column description are lost. But when
> opening a FITS file with description and saving it again to FITS, the
> column descriptions are still here. I suppose that it's because
> astropy.io.fits is under the hood.
>
> Is this because column description handling is not implemented or do I
> miss something?
>
> 3. Column descriptions in VO-Table
>
> When saving a table to VO-Table, astropy prettily indent the xml, e.g.
>
>     <DESCRIPTION>
>      IAU Name
>     </DESCRIPTION>
>
> But when reading these tables with topcat, this one add the spaces to
> the description ("     IAU Name"). Maybe astropy should write the
> description on one line.
>
> Regards,
>
> Yannick
>
> --
> Mystics always hope that science will some day overtake them.
>                 -- Booth Tarkington
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131107/56dbeb91/attachment.html>

From yannick.roehlly at lam.fr  Fri Nov  8 07:32:43 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Fri, 8 Nov 2013 13:32:43 +0100
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
Message-ID: <20131108133243.6f2f29ee@lam.fr>

Le Thu, 7 Nov 2013 21:59:46 +0000,
Paul Kuin <npkuin at gmail.com> a ?crit :

> My (biased) feeling  is that you cannot
> go around having a second metadata file when going to ascii.


Hi Paul,

You are right, having all the metadata on a separate README file is
really important; I know people not even putting the column names in
the data files to be sure users read the README.
But I also think having the metadata inside the data file is useful as
a reminder when working with the data.

Concerning the column descriptions in FITS files, pyfits /
astropy.io.fits does not handle them, but it is always possible to add
the TCOMM keywords manually to the HDU headers.

Regards,

Yannick

-- 
What is mind?  No matter.  What is matter?  Never mind.
		-- Thomas Hewitt Key, 1799-1875


From stsci.perry at gmail.com  Mon Nov 11 08:51:05 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 11 Nov 2013 08:51:05 -0500
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
Message-ID: <CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>

What TOPCAT is doing is in no way part of the FITS standard. As far as I can tell, it isn't even listed as a registered convention. It's exactly this sort of thing that drives us nuts regarding FITS. Somehow people expect us to read and support anything anyone happens to stuff into a FITS file and handle its semantics correctly.

Sorry, it's not going to happen within the FITS module itself. If you want to use it, you need to layer something over FITS to handle it.

Perry

On Nov 7, 2013, at 4:59 PM, Paul Kuin wrote:

> Some years ago, I was leading the NASA Astronomical Data Center, now gone. I worked with CDS to have a way to present a readable table along with the ability to automatically generate a FITS file.  That lead to the "ReadMe" files that accompany the catalogs from CDS, which is storing the metadata. 
> 
> I think it is important to make sure no metadata are lost in the conversion process. Sure, the FITS standard says so-and-so, but in practice, one has to make amends so the standard can evolve. 
> 
> I have only used the astropy saving to tables a little bit because I got annoyed that there was loss of (meta) data.  
> 
> The reason I write is, that there needs to be some serious thought about this issue. as flagged by Yannick. My (biased) feeling  is that you cannot go around having a second metadata file when going to ascii. Doing otherwise will lead to a plethora of ways to save the data file. Better to keep the data file clean, and put the jumk in a meta data file.
> 
> Cheers, 
> 
>    Paul
> 
> 
> On Thu, Nov 7, 2013 at 9:20 PM, Yannick Roehlly <yannick.roehlly at lam.fr> wrote:
> Hi all,
> 
> I have some remarks / questions concerning the column descriptions in
> FITS table files (and VO).
> 
> 1. Long column description
> 
> The FITS format requires that a column description must be 68
> characters or less. Some tools like topcat / stills allows longer
> descriptions because they use a kind of VO-table metada section in the
> FITS header. If you open such file with astropy.io.fits and save it
> again, you loose the long description. In fact, it's not an astropy
> problem as these description as not in the "real FITS" column
> descriptions in the header (TCOMxx), it is just because astropy does
> not save the "VO-table" part of the topcat file.
> Maybe it's worth raising a warning when opening such files, like "Hey,
> you may loose metadata!" because one may be surprise not to have all
> its column description.



From mdroe at stsci.edu  Mon Nov 11 10:54:44 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Mon, 11 Nov 2013 10:54:44 -0500
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <20131107222037.24a5ab74@lam.fr>
References: <20131107222037.24a5ab74@lam.fr>
Message-ID: <5280FDC4.6090300@stsci.edu>

On 11/07/2013 04:20 PM, Yannick Roehlly wrote:
> 3. Column descriptions in VO-Table
>
> When saving a table to VO-Table, astropy prettily indent the xml, e.g.
>
>      <DESCRIPTION>
>       IAU Name
>      </DESCRIPTION>
>
> But when reading these tables with topcat, this one add the spaces to
> the description ("     IAU Name"). Maybe astropy should write the
> description on one line.
>

I'll just address this part and leave the others to those more heavily 
involved with the FITS side of things.

XML basically punts on whitespace handling, by saying that each 
"application of XML" (in this case, VOTable) should define how 
whitespace should be handled.  Unfortunately, the VOTable spec is silent 
on this issue, so in effect, "we're both right".  HTML, as an 
application of XML, would ignore the leading whitespace.

http://www.w3.org/TR/REC-xml/#sec-white-space

We should probably get some clarification from the VOTable committee on 
this point.  I'll write an e-mail to votable at ivoa.net

Mike

-- 

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

http://www.droettboom.com

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

From aldcroft at head.cfa.harvard.edu  Mon Nov 11 12:31:21 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Mon, 11 Nov 2013 12:31:21 -0500
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <20131107222037.24a5ab74@lam.fr>
References: <20131107222037.24a5ab74@lam.fr>
Message-ID: <CAMtEP6yE=JnJcGZcr=bE9ifqE=3cedz2cVd4ep_dUUtZ4ExEYw@mail.gmail.com>

On Thu, Nov 7, 2013 at 4:20 PM, Yannick Roehlly <yannick.roehlly at lam.fr>wrote:

> Hi all,
>
> I have some remarks / questions concerning the column descriptions in
> FITS table files (and VO).
>
> 1. Long column description
>
> The FITS format requires that a column description must be 68
> characters or less. Some tools like topcat / stills allows longer
> descriptions because they use a kind of VO-table metada section in the
> FITS header. If you open such file with astropy.io.fits and save it
> again, you loose the long description. In fact, it's not an astropy
> problem as these description as not in the "real FITS" column
> descriptions in the header (TCOMxx), it is just because astropy does
> not save the "VO-table" part of the topcat file.
> Maybe it's worth raising a warning when opening such files, like "Hey,
> you may loose metadata!" because one may be surprise not to have all
> its column description.
>
> 2. astropy.table and column descriptions in FITS files
>
> When opening a FITS file with astropy.tables(with last git checkout)
> one does not have access to column descriptions. When saving an
> astropy.io.table to FITS, the column description are lost. But when
> opening a FITS file with description and saving it again to FITS, the
> column descriptions are still here. I suppose that it's because
> astropy.io.fits is under the hood.
>
> Is this because column description handling is not implemented or do I
> miss something?
>

I believe this is not implemented but should be.  I opened an issue
https://github.com/astropy/astropy/issues/1768.


>
> 3. Column descriptions in VO-Table
>
> When saving a table to VO-Table, astropy prettily indent the xml, e.g.
>
>     <DESCRIPTION>
>      IAU Name
>     </DESCRIPTION>
>
> But when reading these tables with topcat, this one add the spaces to
> the description ("     IAU Name"). Maybe astropy should write the
> description on one line.
>
> Regards,
>
> Yannick
>
> --
> Mystics always hope that science will some day overtake them.
>                 -- Booth Tarkington
> _______________________________________________
> 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/20131111/baf2b49d/attachment.html>

From aldcroft at head.cfa.harvard.edu  Mon Nov 11 12:45:35 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Mon, 11 Nov 2013 12:45:35 -0500
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <20131108133243.6f2f29ee@lam.fr>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
	<20131108133243.6f2f29ee@lam.fr>
Message-ID: <CAMtEP6zBunfuZ2bN1KqFERD5LPFECYxTwHE-UPYqq5WqGMsn=g@mail.gmail.com>

On Fri, Nov 8, 2013 at 7:32 AM, Yannick Roehlly <yannick.roehlly at lam.fr>wrote:

> Le Thu, 7 Nov 2013 21:59:46 +0000,
> Paul Kuin <npkuin at gmail.com> a ?crit :
>
> > My (biased) feeling  is that you cannot
> > go around having a second metadata file when going to ascii.
>
>
> Hi Paul,
>
> You are right, having all the metadata on a separate README file is
> really important; I know people not even putting the column names in
> the data files to be sure users read the README.
> But I also think having the metadata inside the data file is useful as
> a reminder when working with the data.
>

There is no technical reason you cannot store all reasonable metadata in a
commented header that precedes the data in an ASCII table.  The vast
majority of table readers support a "comment" character to separate data
from other information.  Obviously this depends on having some standards
for interpreting the commented header, but this is the same whether or not
it resides in a separate file.

Personally I think it is far preferable to have header metadata and the
data in a single file, otherwise you have to maintain / distribute twice as
many files and have a mechanism for establishing a correspondence between
the meta (ReadMe) and the data file.  This then makes it harder to rename
table files since you need to update the contents of the ReadMe as well.
 Obviously there are some advantages, like being able to create a
collection of data files (ala CDS) with a single ReadMe, but overall it
seems simpler to have a single data table (with meta) per file.

BTW, slightly OT but I did spend some time thinking about supporting
arbitrary metadata in an ASCII format. The result is this pull request:
   https://github.com/astropy/astropy/pull/683
It's basically just an exploratory idea that saves everything as JSON.
 This got stalled out and it may not be the best way to go (do we need yet
another format?), but it's there if anyone is interested.

- Tom


>
> Concerning the column descriptions in FITS files, pyfits /
> astropy.io.fits does not handle them, but it is always possible to add
> the TCOMM keywords manually to the HDU headers.
>
> Regards,
>
> Yannick
>
> --
> What is mind?  No matter.  What is matter?  Never mind.
>                 -- Thomas Hewitt Key, 1799-1875
> _______________________________________________
> 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/20131111/da1e03bc/attachment.html>

From yannick.roehlly at lam.fr  Mon Nov 11 12:56:05 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Mon, 11 Nov 2013 18:56:05 +0100
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
	<CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
Message-ID: <20131111185605.31916464@lam.fr>

Le Mon, 11 Nov 2013 08:51:05 -0500,
Perry Greenfield <stsci.perry at gmail.com> a ?crit :

> What TOPCAT is doing is in no way part of the FITS standard.

Hi Perry,

I agree with you concerning the "VO metadata" embedded in the FITS
headers. But we should definitively add the column descriptions (in the
TCOMM keywords) when saving a table to FITS, maybe raising an
exception / a warning when a description is longer than 68 characters.

Regards,

Yannick

-- 
It has just been discovered that research causes cancer in rats.


From yannick.roehlly at lam.fr  Mon Nov 11 13:31:13 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Mon, 11 Nov 2013 19:31:13 +0100
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
	<CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
Message-ID: <20131111193113.163981ec@lam.fr>

Le Mon, 11 Nov 2013 08:51:05 -0500,
Perry Greenfield <stsci.perry at gmail.com> a ?crit :

> What TOPCAT is doing is in no way part of the FITS standard.

Hi Perry,

As far as I understand, even the TCOMM keyword is not part of the FITS
standard and they're is nothing in it to store column descriptions.
Right?

Yannick

-- 
If A = B and B = C, then A = C, except where void or prohibited by law.
		-- Roy Santoro


From stsci.perry at gmail.com  Mon Nov 11 13:36:52 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 11 Nov 2013 13:36:52 -0500
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <20131111193113.163981ec@lam.fr>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
	<CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
	<20131111193113.163981ec@lam.fr>
Message-ID: <8B24CF79-093A-49D3-A43A-CA20EECB91A2@gmail.com>


On Nov 11, 2013, at 1:31 PM, Yannick Roehlly wrote:

> Le Mon, 11 Nov 2013 08:51:05 -0500,
> Perry Greenfield <stsci.perry at gmail.com> a ?crit :
> 
>> What TOPCAT is doing is in no way part of the FITS standard.
> 
> Hi Perry,
> 
> As far as I understand, even the TCOMM keyword is not part of the FITS
> standard and they're is nothing in it to store column descriptions.
> Right?

Yes, I believe so. That is to say, nothing prevents you from using such keywords, but the standard doesn't give them any special meaning with regard to columns that anyone else is forced to recognize.

At least as keywords, they are more easily accessible from standard FITS readers (that don't need to do anything special to access them, unlike the meta data that is put into the primary HDU.

Also, I understand the reason they did that. It's there for those willing to go to the trouble to extract it. We are doing similar things for HST and JWST WCS information. But we don't assume that all other FITS readers must be able to access it. It's mainly for our software to use.

Perry



From sebas0 at gmail.com  Mon Nov 11 14:52:04 2013
From: sebas0 at gmail.com (Sebastian)
Date: Mon, 11 Nov 2013 17:52:04 -0200
Subject: [AstroPy] AstroPy Digest, Vol 86, Issue 9
Message-ID: <CAPx0h+nHzuywAA0b=nLqho3+pt5G+oy7rsejVpOmiU99=MR31A@mail.gmail.com>

Just wondering, will RICE compressed FITS files also be supported?



On Mon, Nov 11, 2013 at 2:50 PM, <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. Re: FITS files and column descriptions (Perry Greenfield)
>    2. Re: FITS files and column descriptions (Michael Droettboom)
>    3. Re: FITS files and column descriptions (Aldcroft, Thomas)
>    4. Re: FITS files and column descriptions (Aldcroft, Thomas)
>    5. Re: FITS files and column descriptions (Yannick Roehlly)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Nov 2013 08:51:05 -0500
> From: Perry Greenfield <stsci.perry at gmail.com>
> Subject: Re: [AstroPy] FITS files and column descriptions
> To: Paul Kuin <npkuin at gmail.com>
> Cc: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID: <CCD766AE-2AF4-4EDE-B74C-5D46C347018B at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> What TOPCAT is doing is in no way part of the FITS standard. As far as I
> can tell, it isn't even listed as a registered convention. It's exactly
> this sort of thing that drives us nuts regarding FITS. Somehow people
> expect us to read and support anything anyone happens to stuff into a FITS
> file and handle its semantics correctly.
>
> Sorry, it's not going to happen within the FITS module itself. If you want
> to use it, you need to layer something over FITS to handle it.
>
> Perry
>
> On Nov 7, 2013, at 4:59 PM, Paul Kuin wrote:
>
> > Some years ago, I was leading the NASA Astronomical Data Center, now
> gone. I worked with CDS to have a way to present a readable table along
> with the ability to automatically generate a FITS file.  That lead to the
> "ReadMe" files that accompany the catalogs from CDS, which is storing the
> metadata.
> >
> > I think it is important to make sure no metadata are lost in the
> conversion process. Sure, the FITS standard says so-and-so, but in
> practice, one has to make amends so the standard can evolve.
> >
> > I have only used the astropy saving to tables a little bit because I got
> annoyed that there was loss of (meta) data.
> >
> > The reason I write is, that there needs to be some serious thought about
> this issue. as flagged by Yannick. My (biased) feeling  is that you cannot
> go around having a second metadata file when going to ascii. Doing
> otherwise will lead to a plethora of ways to save the data file. Better to
> keep the data file clean, and put the jumk in a meta data file.
> >
> > Cheers,
> >
> >    Paul
> >
> >
> > On Thu, Nov 7, 2013 at 9:20 PM, Yannick Roehlly <yannick.roehlly at lam.fr>
> wrote:
> > Hi all,
> >
> > I have some remarks / questions concerning the column descriptions in
> > FITS table files (and VO).
> >
> > 1. Long column description
> >
> > The FITS format requires that a column description must be 68
> > characters or less. Some tools like topcat / stills allows longer
> > descriptions because they use a kind of VO-table metada section in the
> > FITS header. If you open such file with astropy.io.fits and save it
> > again, you loose the long description. In fact, it's not an astropy
> > problem as these description as not in the "real FITS" column
> > descriptions in the header (TCOMxx), it is just because astropy does
> > not save the "VO-table" part of the topcat file.
> > Maybe it's worth raising a warning when opening such files, like "Hey,
> > you may loose metadata!" because one may be surprise not to have all
> > its column description.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Nov 2013 10:54:44 -0500
> From: Michael Droettboom <mdroe at stsci.edu>
> Subject: Re: [AstroPy] FITS files and column descriptions
> To: <astropy at scipy.org>
> Message-ID: <5280FDC4.6090300 at stsci.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 11/07/2013 04:20 PM, Yannick Roehlly wrote:
> > 3. Column descriptions in VO-Table
> >
> > When saving a table to VO-Table, astropy prettily indent the xml, e.g.
> >
> >      <DESCRIPTION>
> >       IAU Name
> >      </DESCRIPTION>
> >
> > But when reading these tables with topcat, this one add the spaces to
> > the description ("     IAU Name"). Maybe astropy should write the
> > description on one line.
> >
>
> I'll just address this part and leave the others to those more heavily
> involved with the FITS side of things.
>
> XML basically punts on whitespace handling, by saying that each
> "application of XML" (in this case, VOTable) should define how
> whitespace should be handled.  Unfortunately, the VOTable spec is silent
> on this issue, so in effect, "we're both right".  HTML, as an
> application of XML, would ignore the leading whitespace.
>
> http://www.w3.org/TR/REC-xml/#sec-white-space
>
> We should probably get some clarification from the VOTable committee on
> this point.  I'll write an e-mail to votable at ivoa.net
>
> Mike
>
> --
>
>                     _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131111/b86c7c56/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Nov 2013 12:31:21 -0500
> From: "Aldcroft, Thomas" <aldcroft at head.cfa.harvard.edu>
> Subject: Re: [AstroPy] FITS files and column descriptions
> To: Yannick Roehlly <yannick.roehlly at lam.fr>
> Cc: "AstroPy at scipy.org" <astropy at scipy.org>
> Message-ID:
>         <CAMtEP6yE=JnJcGZcr=bE9ifqE=
> 3cedz2cVd4ep_dUUtZ4ExEYw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Nov 7, 2013 at 4:20 PM, Yannick Roehlly <yannick.roehlly at lam.fr
> >wrote:
>
> > Hi all,
> >
> > I have some remarks / questions concerning the column descriptions in
> > FITS table files (and VO).
> >
> > 1. Long column description
> >
> > The FITS format requires that a column description must be 68
> > characters or less. Some tools like topcat / stills allows longer
> > descriptions because they use a kind of VO-table metada section in the
> > FITS header. If you open such file with astropy.io.fits and save it
> > again, you loose the long description. In fact, it's not an astropy
> > problem as these description as not in the "real FITS" column
> > descriptions in the header (TCOMxx), it is just because astropy does
> > not save the "VO-table" part of the topcat file.
> > Maybe it's worth raising a warning when opening such files, like "Hey,
> > you may loose metadata!" because one may be surprise not to have all
> > its column description.
> >
> > 2. astropy.table and column descriptions in FITS files
> >
> > When opening a FITS file with astropy.tables(with last git checkout)
> > one does not have access to column descriptions. When saving an
> > astropy.io.table to FITS, the column description are lost. But when
> > opening a FITS file with description and saving it again to FITS, the
> > column descriptions are still here. I suppose that it's because
> > astropy.io.fits is under the hood.
> >
> > Is this because column description handling is not implemented or do I
> > miss something?
> >
>
> I believe this is not implemented but should be.  I opened an issue
> https://github.com/astropy/astropy/issues/1768.
>
>
> >
> > 3. Column descriptions in VO-Table
> >
> > When saving a table to VO-Table, astropy prettily indent the xml, e.g.
> >
> >     <DESCRIPTION>
> >      IAU Name
> >     </DESCRIPTION>
> >
> > But when reading these tables with topcat, this one add the spaces to
> > the description ("     IAU Name"). Maybe astropy should write the
> > description on one line.
> >
> > Regards,
> >
> > Yannick
> >
> > --
> > Mystics always hope that science will some day overtake them.
> >                 -- Booth Tarkington
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131111/baf2b49d/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Mon, 11 Nov 2013 12:45:35 -0500
> From: "Aldcroft, Thomas" <aldcroft at head.cfa.harvard.edu>
> Subject: Re: [AstroPy] FITS files and column descriptions
> To: Yannick Roehlly <yannick.roehlly at lam.fr>
> Cc: astropy <astropy at scipy.org>
> Message-ID:
>         <CAMtEP6zBunfuZ2bN1KqFERD5LPFECYxTwHE-UPYqq5WqGMsn=
> g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Nov 8, 2013 at 7:32 AM, Yannick Roehlly <yannick.roehlly at lam.fr
> >wrote:
>
> > Le Thu, 7 Nov 2013 21:59:46 +0000,
> > Paul Kuin <npkuin at gmail.com> a ?crit :
> >
> > > My (biased) feeling  is that you cannot
> > > go around having a second metadata file when going to ascii.
> >
> >
> > Hi Paul,
> >
> > You are right, having all the metadata on a separate README file is
> > really important; I know people not even putting the column names in
> > the data files to be sure users read the README.
> > But I also think having the metadata inside the data file is useful as
> > a reminder when working with the data.
> >
>
> There is no technical reason you cannot store all reasonable metadata in a
> commented header that precedes the data in an ASCII table.  The vast
> majority of table readers support a "comment" character to separate data
> from other information.  Obviously this depends on having some standards
> for interpreting the commented header, but this is the same whether or not
> it resides in a separate file.
>
> Personally I think it is far preferable to have header metadata and the
> data in a single file, otherwise you have to maintain / distribute twice as
> many files and have a mechanism for establishing a correspondence between
> the meta (ReadMe) and the data file.  This then makes it harder to rename
> table files since you need to update the contents of the ReadMe as well.
>  Obviously there are some advantages, like being able to create a
> collection of data files (ala CDS) with a single ReadMe, but overall it
> seems simpler to have a single data table (with meta) per file.
>
> BTW, slightly OT but I did spend some time thinking about supporting
> arbitrary metadata in an ASCII format. The result is this pull request:
>    https://github.com/astropy/astropy/pull/683
> It's basically just an exploratory idea that saves everything as JSON.
>  This got stalled out and it may not be the best way to go (do we need yet
> another format?), but it's there if anyone is interested.
>
> - Tom
>
>
> >
> > Concerning the column descriptions in FITS files, pyfits /
> > astropy.io.fits does not handle them, but it is always possible to add
> > the TCOMM keywords manually to the HDU headers.
> >
> > Regards,
> >
> > Yannick
> >
> > --
> > What is mind?  No matter.  What is matter?  Never mind.
> >                 -- Thomas Hewitt Key, 1799-1875
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20131111/da1e03bc/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Mon, 11 Nov 2013 18:56:05 +0100
> From: Yannick Roehlly <yannick.roehlly at lam.fr>
> Subject: Re: [AstroPy] FITS files and column descriptions
> To: astropy at scipy.org
> Message-ID: <20131111185605.31916464 at lam.fr>
> Content-Type: text/plain; charset=UTF-8
>
> Le Mon, 11 Nov 2013 08:51:05 -0500,
> Perry Greenfield <stsci.perry at gmail.com> a ?crit :
>
> > What TOPCAT is doing is in no way part of the FITS standard.
>
> Hi Perry,
>
> I agree with you concerning the "VO metadata" embedded in the FITS
> headers. But we should definitively add the column descriptions (in the
> TCOMM keywords) when saving a table to FITS, maybe raising an
> exception / a warning when a description is longer than 68 characters.
>
> Regards,
>
> Yannick
>
> --
> It has just been discovered that research causes cancer in rats.
>
>
> ------------------------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
> End of AstroPy Digest, Vol 86, Issue 9
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131111/c8248dc8/attachment.html>

From sebas0 at gmail.com  Mon Nov 11 16:49:16 2013
From: sebas0 at gmail.com (Sebastian)
Date: Mon, 11 Nov 2013 19:49:16 -0200
Subject: [AstroPy] colour RGB images and plotting
Message-ID: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>

Hoping for some advice.. We are using Montage and the montage_wrapper in
python to build stacked RGB colour images from individual *.fits images in
three different astronomical bands of the same field. With the mJPEG
command, Montage produces the RGB *.jpg image using three previously
generated reprojected images. This *.jpg image file includes a header with
WCS and other meta data.

Anyone had any success in making matplotlib plots of Montage jpg images
accessing on the JPEG header info? We wish to make plots of sections of the
jpg image, overlay small boxes around source positions, plot coords grids,
etc.

- any previous experience? Best wishes!
Sebastian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131111/ffb664bf/attachment.html>

From embray at stsci.edu  Mon Nov 11 17:47:28 2013
From: embray at stsci.edu (Erik Bray)
Date: Mon, 11 Nov 2013 17:47:28 -0500
Subject: [AstroPy] RICE support in PyFITS (was:  AstroPy Digest, Vol 86,
 Issue 9)
In-Reply-To: <CAPx0h+nHzuywAA0b=nLqho3+pt5G+oy7rsejVpOmiU99=MR31A@mail.gmail.com>
References: <CAPx0h+nHzuywAA0b=nLqho3+pt5G+oy7rsejVpOmiU99=MR31A@mail.gmail.com>
Message-ID: <52815E80.90907@stsci.edu>

On 11/11/2013 02:52 PM, Sebastian wrote:
> Just wondering, will RICE compressed FITS files also be supported?

Hi Sebastian,

I'm not exactly sure how this related to the messages in the digest you 
responded to, but I'm assuming you're asking about support for RICE compressed 
FITS images in PyFITS and/or Astropy.

RICE-compressed images (and images compressed with other algorithms support by 
the FITS Tiled Image Compression Convention [1]) have been supported by PyFITS 
(and by extension Astropy) for some time now.

If there was some file you had trouble reading, possibly created with more 
recent versions of fpack, it's possible that it was using some newer extensions 
to the convention that were not previously supported.  Though soon we will be 
releasing PyFITS v3.2 and Astropy v0.3, both of which support the latest version 
of this convention (2.3, released in July 2013).  So if you *are* having 
problems with this it's likely that will solve them.

Erik

P.S. Support for the beta features in fpack for compressing binary tables is not 
yet implemented, but hopefully that's not what you're referring to.

[1] http://fits.gsfc.nasa.gov/registry/tilecompression.html



From npkuin at gmail.com  Mon Nov 11 17:55:15 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 11 Nov 2013 22:55:15 +0000
Subject: [AstroPy] FITS files and column descriptions
In-Reply-To: <8B24CF79-093A-49D3-A43A-CA20EECB91A2@gmail.com>
References: <20131107222037.24a5ab74@lam.fr>
	<CANoQ6N3AzvtDNYMg8MjnG0tUC9L25_+=xooR2C6JkKrVpwzt0g@mail.gmail.com>
	<CCD766AE-2AF4-4EDE-B74C-5D46C347018B@gmail.com>
	<20131111193113.163981ec@lam.fr>
	<8B24CF79-093A-49D3-A43A-CA20EECB91A2@gmail.com>
Message-ID: <CANoQ6N2ohLx7au0r23Q=qSsX-4Gomg48YTAiLzh=VSRsz6bYhA@mail.gmail.com>

Dear Yannick,

You seem disappointed by the FITS stuff.

The FITS standard is a compromise. It has in it what is required to make it
work as an exchange format.  In the early 1990-ies there was some attempt
to go further and standardize other keywords, like units. This was
unsuccessful, but organisations like HEASARC defined their own unit
convention, and keywords they require, likewise, CDS did, and I suppose
NRAO.  That led to some keywords being registered, so their interpretation
would not get diluted by different conventions using the same term. I'm a
bit unclear in my memory what happened to that registry and what it is
called.

I think a description of a column is nice-to-have, not a requirement per
s?. However, it could be one of the reserved keywords, I suppose.  But
you're not the first one to preach for the global adoption of some FITS
keywords. Unfortunately, you must get everyone to agree.

I think FITS has been quite a success so far and has not run out of
momentum. It may eventually be overshadowed by HDF where you can put in
metadata and also links, which is kind of nice.  But for now we have to
make do.

Anyone can add stuff to the FITS headers, so those column descriptions
could be added by you. I'm not sure if you easily can with Astropy.ascii

But I hope this helps you understand why things are the way they are.

Paul







On Mon, Nov 11, 2013 at 6:36 PM, Perry Greenfield <stsci.perry at gmail.com>wrote:

>
> On Nov 11, 2013, at 1:31 PM, Yannick Roehlly wrote:
>
> > Le Mon, 11 Nov 2013 08:51:05 -0500,
> > Perry Greenfield <stsci.perry at gmail.com> a ?crit :
> >
> >> What TOPCAT is doing is in no way part of the FITS standard.
> >
> > Hi Perry,
> >
> > As far as I understand, even the TCOMM keyword is not part of the FITS
> > standard and they're is nothing in it to store column descriptions.
> > Right?
>
> Yes, I believe so. That is to say, nothing prevents you from using such
> keywords, but the standard doesn't give them any special meaning with
> regard to columns that anyone else is forced to recognize.
>
> At least as keywords, they are more easily accessible from standard FITS
> readers (that don't need to do anything special to access them, unlike the
> meta data that is put into the primary HDU.
>
> Also, I understand the reason they did that. It's there for those willing
> to go to the trouble to extract it. We are doing similar things for HST and
> JWST WCS information. But we don't assume that all other FITS readers must
> be able to access it. It's mainly for our software to use.
>
> Perry
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131111/ec57e266/attachment.html>

From yannick.roehlly at lam.fr  Mon Nov 11 18:39:51 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Tue, 12 Nov 2013 00:39:51 +0100
Subject: [AstroPy] colour RGB images and plotting
In-Reply-To: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>
References: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>
Message-ID: <20131112003951.31e6badc@lam.fr>

Le Mon, 11 Nov 2013 19:49:16 -0200,
Sebastian <sebas0 at gmail.com> a ?crit :

> Anyone had any success in making matplotlib plots of Montage jpg
> images accessing on the JPEG header info?

Hi Sebastian,

I've never tried with RGB maps produced directly by Montage, but I
suppose it uses AVM to embed the WCS information, so you should be able
to use them wit APLpy (http://aplpy.github.io/).

Regards,

Yannick

-- 
Solutions are obvious if one only has the optical power to observe them
over the horizon.
		-- K. A. Arsdall


From august.fly at gmail.com  Mon Nov 11 20:16:13 2013
From: august.fly at gmail.com (August (Gus) Muench)
Date: Mon, 11 Nov 2013 20:16:13 -0500
Subject: [AstroPy] colour RGB images and plotting
In-Reply-To: <20131112003951.31e6badc@lam.fr>
References: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>
	<20131112003951.31e6badc@lam.fr>
Message-ID: <CAMER+Ot3h0vvf9hu+E6rNqFzObB-X37gc1xwKR2guwYGWYju5w@mail.gmail.com>

I would bet it isn't AVM because that would require them to add XMP writing
abilities (wcs keys do not map to any JPEG/EXIF fields)

Rather I think the resulting FITS header is dumped into the JPEG.comment
(or maybe EXIF.comment) field. For example, Aladin looks for WCS there
(instead of AVM exclusively).


 - gus


On Mon, Nov 11, 2013 at 6:39 PM, Yannick Roehlly <yannick.roehlly at lam.fr>wrote:

> Le Mon, 11 Nov 2013 19:49:16 -0200,
> Sebastian <sebas0 at gmail.com> a ?crit :
>
> > Anyone had any success in making matplotlib plots of Montage jpg
> > images accessing on the JPEG header info?
>
> Hi Sebastian,
>
> I've never tried with RGB maps produced directly by Montage, but I
> suppose it uses AVM to embed the WCS information, so you should be able
> to use them wit APLpy (http://aplpy.github.io/).
>
> Regards,
>
> Yannick
>
> --
> Solutions are obvious if one only has the optical power to observe them
> over the horizon.
>                 -- K. A. Arsdall
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
August (Gus) Muench
august.fly at gmail.com
@augustmuench
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131111/70cd1b50/attachment.html>

From thomas.robitaille at gmail.com  Tue Nov 12 02:49:53 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 12 Nov 2013 08:49:53 +0100
Subject: [AstroPy] colour RGB images and plotting
In-Reply-To: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>
References: <CAPx0h+n952-sSgykiTdKojwRVaGiNNgL7G3LBgACSxYXDWB56A@mail.gmail.com>
Message-ID: <CAGMHX_0R40U5-jWz28_n3KrYziCd7HcS8PExZ2YFeui_E5f=8A@mail.gmail.com>

Hi Sebastian,

You can use APLpy to make the RGB images and embed AVM meta-data:

http://aplpy.readthedocs.org/en/v0.9.9/howto_rgb.html

http://aplpy.readthedocs.org/en/v0.9.9/howto_avm.html

Also requires PyAVM to be installed: http://astrofrog.github.io/pyavm/

If you can't get the AVM part to work, then once you've made the RGB
image, you can first call APLpy's FITSFigure with the FITS file that
has the same projection as the RGB image, then you can do ``show_rgb``
with the RGB image and it will use the header from the FITS file.
Ideally though, the AVM stuff should work. Let me know if not.

Cheers,
Tom

On 11 November 2013 22:49, Sebastian <sebas0 at gmail.com> wrote:
> Hoping for some advice.. We are using Montage and the montage_wrapper in
> python to build stacked RGB colour images from individual *.fits images in
> three different astronomical bands of the same field. With the mJPEG
> command, Montage produces the RGB *.jpg image using three previously
> generated reprojected images. This *.jpg image file includes a header with
> WCS and other meta data.
>
> Anyone had any success in making matplotlib plots of Montage jpg images
> accessing on the JPEG header info? We wish to make plots of sections of the
> jpg image, overlay small boxes around source positions, plot coords grids,
> etc.
>
> - any previous experience? Best wishes!
> Sebastian.
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From yannick.roehlly at lam.fr  Thu Nov 14 10:19:20 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Thu, 14 Nov 2013 16:19:20 +0100
Subject: [AstroPy] Question about WCS and coordinate system
Message-ID: <20131114161920.597ca59a@lam.fr>

Hi all,

I'm struggling with making an all sky plot using the
lambda_mollweide_sfd_ebv.fits reddening map available there
http://lambda.gsfc.nasa.gov/product/foreground/fg_sfd_get.cfm

When using aplpy, the coordinates are reversed so I'm trying to
understand what's going wrong using only astropy.

import numpy as np
from matplotlib import pyplot as plt
from astropy.wcs import wcs
from astropy.io import fits
hdulist = fits.open("lambda_mollweide_sfd_ebv.fits")
imshow(np.log(hdulist[1].data), cmap="cubehelix")

I'm trying to find the position of the Large Magelanic Cloud which
should be around the pixel 2862, 562 (figure attached).

wcs1 = wcs.WCS(hdulist[1].header)
print(wcs1.wcs_pix2world([[2862, 562]], 1))

-> [[ 80.13878056  33.70194417]]

But the LMC should be around 280, -32

Do I do something wrong?

A secondary question would be: when using WCS pix2world and world2pix,
what is the coordinate system used? The one declared in the fits header?

Cheers,

Yannick

-- 
How many weeks are there in a light year?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: figure.jpg
Type: image/jpeg
Size: 58825 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20131114/a0a5169c/attachment.jpg>

From jslavin at cfa.harvard.edu  Thu Nov 14 10:50:12 2013
From: jslavin at cfa.harvard.edu (Slavin, Jonathan)
Date: Thu, 14 Nov 2013 10:50:12 -0500
Subject: [AstroPy] Question about WCS and coordinate system
Message-ID: <CACcRS=dkPP3wqZ88gDyL0dEOyAmpAiniMVYx5__V7invQOhEmw@mail.gmail.com>

Yannick,

Judging from the E(B-V) image at
http://lambda.gsfc.nasa.gov/product/foreground/fg_images/med_ebv_image.png
I'd say your image is upside down.  Try imshow with origin='lower' as an
argument.

Jon


On Thu, Nov 14, 2013 at 10:13 AM, <astropy-request at scipy.org> wrote:
>
> Message: 1
> Date: Thu, 14 Nov 2013 16:19:20 +0100
> From: Yannick Roehlly <yannick.roehlly at lam.fr>
> Subject: [AstroPy] Question about WCS and coordinate system
> To: astropy mailing list <astropy at scipy.org>
> Message-ID: <20131114161920.597ca59a at lam.fr>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> I'm struggling with making an all sky plot using the
> lambda_mollweide_sfd_ebv.fits reddening map available there
> http://lambda.gsfc.nasa.gov/product/foreground/fg_sfd_get.cfm
>
> When using aplpy, the coordinates are reversed so I'm trying to
> understand what's going wrong using only astropy.
>
> import numpy as np
> from matplotlib import pyplot as plt
> from astropy.wcs import wcs
> from astropy.io import fits
> hdulist = fits.open("lambda_mollweide_sfd_ebv.fits")
> imshow(np.log(hdulist[1].data), cmap="cubehelix")
>
> I'm trying to find the position of the Large Magelanic Cloud which
> should be around the pixel 2862, 562 (figure attached).
>
> wcs1 = wcs.WCS(hdulist[1].header)
> print(wcs1.wcs_pix2world([[2862, 562]], 1))
>
> -> [[ 80.13878056  33.70194417]]
>
> But the LMC should be around 280, -32
>
> Do I do something wrong?
>
> A secondary question would be: when using WCS pix2world and world2pix,
> what is the coordinate system used? The one declared in the fits header?
>
> Cheers,
>
> Yannick
>
> --
> How many weeks are there in a light year?
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: figure.jpg
> Type: image/jpeg
> Size: 58825 bytes
> Desc: not available
> Url :
> http://mail.scipy.org/pipermail/astropy/attachments/20131114/a0a5169c/attachment.jpg
>
> ------------------------------
>
-- 
________________________________________________________
Jonathan D. Slavin                 Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu       60 Garden Street, MS 83
phone: (617) 496-7981       Cambridge, MA 02138-1516
fax: (617) 496-7577            USA
________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131114/8e527628/attachment.html>

From yannick.roehlly at lam.fr  Thu Nov 14 11:24:20 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Thu, 14 Nov 2013 17:24:20 +0100
Subject: [AstroPy] Question about WCS and coordinate system
In-Reply-To: <CACcRS=dkPP3wqZ88gDyL0dEOyAmpAiniMVYx5__V7invQOhEmw@mail.gmail.com>
References: <CACcRS=dkPP3wqZ88gDyL0dEOyAmpAiniMVYx5__V7invQOhEmw@mail.gmail.com>
Message-ID: <20131114172420.7e6b3f8b@lam.fr>

Le Thu, 14 Nov 2013 10:50:12 -0500,
"Slavin, Jonathan" <jslavin at cfa.harvard.edu> a ?crit :

> Judging from the E(B-V) image at
> http://lambda.gsfc.nasa.gov/product/foreground/fg_images/med_ebv_image.png
> I'd say your image is upside down.  Try imshow with origin='lower' as
> an argument.

Hi Jon,

Yes, but shouldn't the pix2world work on the actual pixel position?

Yannick

-- 
The Universe is populated by stable things.
		-- Richard Dawkins


From jslavin at cfa.harvard.edu  Thu Nov 14 13:16:30 2013
From: jslavin at cfa.harvard.edu (Slavin, Jonathan)
Date: Thu, 14 Nov 2013 13:16:30 -0500
Subject: [AstroPy] Question about WCS and coordinate system
Message-ID: <CACcRS=f3CYaPUYH22SUkTXeJLG=ysNn1i5iAmcFz-HxEonaLGA@mail.gmail.com>

I think that it does work on the pixel position, but how one plots the
pixels is controlled by matplotlib.  By default the (0,0) pixel is plotted
at the upper left.

Jon

On Thu, Nov 14, 2013 at 1:00 PM, <astropy-request at scipy.org> wrote:

> Date: Thu, 14 Nov 2013 17:24:20 +0100
> From: Yannick Roehlly <yannick.roehlly at lam.fr>
> Subject: Re: [AstroPy] Question about WCS and coordinate system
> To: astropy at scipy.org
> Message-ID: <20131114172420.7e6b3f8b at lam.fr>
> Content-Type: text/plain; charset=UTF-8
>
> Le Thu, 14 Nov 2013 10:50:12 -0500,
> "Slavin, Jonathan" <jslavin at cfa.harvard.edu> a ?crit :
>
> > Judging from the E(B-V) image at
> >
> http://lambda.gsfc.nasa.gov/product/foreground/fg_images/med_ebv_image.png
> > I'd say your image is upside down.  Try imshow with origin='lower' as
> > an argument.
>
> Hi Jon,
>
> Yes, but shouldn't the pix2world work on the actual pixel position?
>
> Yannick
>




-- 
________________________________________________________
Jonathan D. Slavin                 Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu       60 Garden Street, MS 83
phone: (617) 496-7981       Cambridge, MA 02138-1516
fax: (617) 496-7577            USA
________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131114/9d828247/attachment.html>

From erik.tollerud at gmail.com  Fri Nov 15 12:09:09 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Fri, 15 Nov 2013 12:09:09 -0500
Subject: [AstroPy] ANN: ERFA 1.0 released
Message-ID: <CAARXUwXBsOwvyj0e9CQGEoxhc1Z=9h5kmuZwxwz+44CSwiJ22Q@mail.gmail.com>

Hello all,

I write this to announce the first public release of the ERFA
(Essential Routines for Fundamental Astronomy) library.  ERFA is a C
library containing key algorithms for astronomy, as a primarily
drop-in replacement for the IAU's SOFA library, but re-licensed (with
the SOFA board's explicit permission) to be compatible with typical
Free/Open Source Software licenses, and with a faster bugfix cycle.

ERFA is available now on macports, and has been submitted to Fedora and Debian.

The release can be downloaded from:
https://github.com/liberfa/erfa/releases/download/v1.0.1/erfa-1.0.1.tar.gz

The project page is: https://github.com/liberfa/erfa

And the issue tracker is at: https://github.com/liberfa/erfa/issues


Thanks to all who helped make this happen!


-- 
Erik


From rays at blue-cove.com  Fri Nov 15 13:06:15 2013
From: rays at blue-cove.com (RayS)
Date: Fri, 15 Nov 2013 10:06:15 -0800
Subject: [AstroPy] Astropy logo copyright
Message-ID: <201311151806.rAFI6FPg002112@blue-cove.com>

Well, the AFD hubbub is finally over.

The Talk page still lists a small deficiency regarding the logo use:
https://en.wikipedia.org/wiki/Talk:Astropy
in that the logo's page
https://en.wikipedia.org/wiki/File:Logo_of_the_Astropy_Project.png#filelinks
does not have a specific copyright (or left) declaration
https://github.com/astropy/astropy-logo
only credits and license...
https://en.wikipedia.org/wiki/Wikipedia:Copyrights#Guidelines_for_images_and_other_media_files

- Ray  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131115/068a0366/attachment.html>

From thomas.robitaille at gmail.com  Fri Nov 15 13:46:13 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 15 Nov 2013 19:46:13 +0100
Subject: [AstroPy] Astropy logo copyright
In-Reply-To: <201311151806.rAFI6FPg002112@blue-cove.com>
References: <201311151806.rAFI6FPg002112@blue-cove.com>
Message-ID: <CAGMHX_3ab1ec+0aby3mnHRvx+bCEkeKZFRVROk2+2cSHNtCiSQ@mail.gmail.com>

Hi Ray,

A few days ago we added the copyright and license information here:

https://github.com/astropy/astropy-logo

in the LICENSE file.

Cheers,
Tom


On 15 November 2013 19:06, RayS <rays at blue-cove.com> wrote:
> Well, the AFD hubbub is finally over.
>
> The Talk page still lists a small deficiency regarding the logo use:
> https://en.wikipedia.org/wiki/Talk:Astropy
> in that the logo's page
> https://en.wikipedia.org/wiki/File:Logo_of_the_Astropy_Project.png#filelinks
> does not have a specific copyright (or left) declaration
> https://github.com/astropy/astropy-logo
> only credits and license...
> https://en.wikipedia.org/wiki/Wikipedia:Copyrights#Guidelines_for_images_and_other_media_files
>
> - Ray
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From marquett at iap.fr  Mon Nov 18 09:20:59 2013
From: marquett at iap.fr (Jean-Baptiste Marquette)
Date: Mon, 18 Nov 2013 15:20:59 +0100
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
	under Mac OS Mavericks and python under Homebrew
Message-ID: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>

Hi Astropy gurus,

I got this:

astropy/utils/src/compiler.c(124): error: expected a ")"

    PyModule_AddStringConstant(m, "compiler", COMPILER);

                                              ^



compilation aborted for astropy/utils/src/compiler.c (code 2)

error: command 'icc' failed with exit status 2


My compiler is:

icc -v
icc version 14.0.1 (gcc version 4.2.1 compatibility)

More on request if needed.

Cheers,
JB



From thomas.robitaille at gmail.com  Mon Nov 18 09:34:10 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 18 Nov 2013 15:34:10 +0100
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
 under Mac OS Mavericks and python under Homebrew
In-Reply-To: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>
References: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>
Message-ID: <CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>

Hi Jean-Baptiste,

Is this the default compiler, or have you deliberately changed it to
the intel c compiler? (icc)

If the latter, then we should open a general issue to support the
intel C compiler (I think no one had requested it so far, hence why it
went unnoticed). Try setting your compiler to clang instead to see if
it helps.

Cheers,
Tom


On 18 November 2013 15:20, Jean-Baptiste Marquette <marquett at iap.fr> wrote:
> Hi Astropy gurus,
>
> I got this:
>
> astropy/utils/src/compiler.c(124): error: expected a ")"
>
>     PyModule_AddStringConstant(m, "compiler", COMPILER);
>
>                                               ^
>
>
>
> compilation aborted for astropy/utils/src/compiler.c (code 2)
>
> error: command 'icc' failed with exit status 2
>
>
> My compiler is:
>
> icc -v
> icc version 14.0.1 (gcc version 4.2.1 compatibility)
>
> More on request if needed.
>
> Cheers,
> JB
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From marquett at iap.fr  Mon Nov 18 09:38:09 2013
From: marquett at iap.fr (Jean-Baptiste Marquette)
Date: Mon, 18 Nov 2013 15:38:09 +0100
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
	under Mac OS Mavericks and python under Homebrew
In-Reply-To: <CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
References: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>
	<CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
Message-ID: <0A02F93C-C6B8-43F5-8910-08A801EE9561@iap.fr>

Hi Tom,

> Is this the default compiler, or have you deliberately changed it to
> the intel c compiler? (icc)

I changed it, I have an alias command to do so in a given terminal.

> 
> If the latter, then we should open a general issue to support the
> intel C compiler (I think no one had requested it so far, hence why it
> went unnoticed). Try setting your compiler to clang instead to see if
> it helps.

OK, stay tuned.

Cheers,
JB

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

From marquett at iap.fr  Mon Nov 18 09:46:35 2013
From: marquett at iap.fr (Jean-Baptiste Marquette)
Date: Mon, 18 Nov 2013 15:46:35 +0100
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
	under Mac OS Mavericks and python under Homebrew
In-Reply-To: <CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
References: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>
	<CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
Message-ID: <44E61C16-E146-4D21-ADDA-0696B04FF0C8@iap.fr>


Hi again,

> If the latter, then we should open a general issue to support the
> intel C compiler (I think no one had requested it so far, hence why it
> went unnoticed). Try setting your compiler to clang instead to see if
> it helps.

clang successful, thus we are facing an icc compiler issue. Supporting it would be great. Emmanuel Bertin told me it is much more efficient in some situations, for example with sine or cosine functions.

Cheers,
JB

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

From mdroe at stsci.edu  Tue Nov 19 08:50:12 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Tue, 19 Nov 2013 08:50:12 -0500
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
 under Mac OS Mavericks and python under Homebrew
In-Reply-To: <44E61C16-E146-4D21-ADDA-0696B04FF0C8@iap.fr>
References: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>	<CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
	<44E61C16-E146-4D21-ADDA-0696B04FF0C8@iap.fr>
Message-ID: <528B6C94.7000804@stsci.edu>

On 11/18/2013 09:46 AM, Jean-Baptiste Marquette wrote:
>
> Hi again,
>
>> If the latter, then we should open a general issue to support the
>> intel C compiler (I think no one had requested it so far, hence why it
>> went unnoticed). Try setting your compiler to clang instead to see if
>> it helps.
>
> clang successful, thus we are facing an icc compiler issue. Supporting 
> it would be great. Emmanuel Bertin told me it is much more efficient 
> in some situations, for example with sine or cosine functions.

We'll need some way to provide the financial support for this, of 
course.  ICC is far from free.  It doesn't appear on paper that STScI 
would be eligible for academic pricing or non-commercial pricing by 
Intel's definition [1] [2], so it's $699/box or $2,499 for 2-concurrent 
floating site license.  It might be worth experimenting with the 30-day 
evaluation license to see what the performance benefits are before 
committing to long-term support of that compiler.  That kind of money 
actually goes a real long way toward hosted testing solutions etc. which 
would benefit a lot more users than supporting a commercial compiler.  
All that said, we can always accept small patches to support ICC even if 
none of the core developers have a copy.

[1] " For faculty or staff at degree-granting institutions of higher 
learning"
[2] " Non-commercial software development means you are not paid and/or 
compensated in any form, by anyone, for software development using the 
Intel? Software Development Products under the terms of the 
non-commercial license."

Mike

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

http://www.droettboom.com

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

From rhewett at mit.edu  Wed Nov 20 16:11:19 2013
From: rhewett at mit.edu (Russell Hewett)
Date: Wed, 20 Nov 2013 16:11:19 -0500
Subject: [AstroPy] docs building issue
Message-ID: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>

Hi All,

I can't seem to get the docs to build, ever since I installed graphviz.  It
worked beforehand, with the older version of sphinx that comes with
anaconda.  Any ideas?

C:\Users\rhewett\research\software-projects\astropy\docs>make html
Running Sphinx v1.2b2

Sphinx version error:
This project needs at least Sphinx v1.2b2 and therefore cannot be built
with this version.

(Also doesn't work with 1.2b3)

C:\Users\rhewett\research\software-projects\astropy\docs>ipython
Python 2.7.5 |Anaconda 1.7.0 (64-bit)| (default, Jul  1 2013, 12:37:52)
[MSC v.1500 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.

IPython 1.1.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import sphinx

In [2]: sphinx.__version__
Out[2]: '1.2b2'


-Russ

-- 
Russell J. Hewett
Postdoctoral Associate
Imaging and Computing Group
Department of Mathematics
Massachusetts Institute of Technology
www.russellhewett.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131120/f8bd5430/attachment.html>

From miguel.deval at gmail.com  Wed Nov 20 18:04:54 2013
From: miguel.deval at gmail.com (Miguel de Val-Borro)
Date: Wed, 20 Nov 2013 18:04:54 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
Message-ID: <20131120230454.GQ4013@cfhs5>

Hi Russell,

Can you check the setting of the "needs_sphinx" variable in the
astropy/docs/conf.py configuration file? If the file has not been
modified locally this line should be commented out. I have just tried to
build the HTML documentation from the current master branch and it
worked fine with Sphinx 1.1.3 on a Linux system.

Miguel

On Wed, Nov 20, 2013 at 04:11:19PM -0500, Russell Hewett wrote:
> Hi All,
> 
> I can't seem to get the docs to build, ever since I installed graphviz.  It
> worked beforehand, with the older version of sphinx that comes with
> anaconda.  Any ideas?
> 
> C:\Users\rhewett\research\software-projects\astropy\docs>make html
> Running Sphinx v1.2b2
> 
> Sphinx version error:
> This project needs at least Sphinx v1.2b2 and therefore cannot be built
> with this version.
> 
> (Also doesn't work with 1.2b3)
> 
> C:\Users\rhewett\research\software-projects\astropy\docs>ipython
> Python 2.7.5 |Anaconda 1.7.0 (64-bit)| (default, Jul  1 2013, 12:37:52)
> [MSC v.1500 64 bit (AMD64)]
> Type "copyright", "credits" or "license" for more information.
> 
> IPython 1.1.0 -- An enhanced Interactive Python.
> ?         -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help      -> Python's own help system.
> object?   -> Details about 'object', use 'object??' for extra details.
> 
> In [1]: import sphinx
> 
> In [2]: sphinx.__version__
> Out[2]: '1.2b2'
> 
> 
> -Russ
> 
> -- 
> Russell J. Hewett
> Postdoctoral Associate
> Imaging and Computing Group
> Department of Mathematics
> Massachusetts Institute of Technology
> www.russellhewett.com

> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From russell.j.hewett at gmail.com  Wed Nov 20 18:20:19 2013
From: russell.j.hewett at gmail.com (Russell Hewett)
Date: Wed, 20 Nov 2013 18:20:19 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <20131120230454.GQ4013@cfhs5>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
Message-ID: <CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>

Hi Miguel,

It is commented out.  With sphinx 1.1.3 it works fine, but with graphviz
installed, this code (from astropy/astropy/sphinx/conf.py) indicates that a
newer sphinx is needed (which I have installed).

def get_graphviz_version():
    try:
        output = subprocess.check_output(
            ['dot', '-V'], stdin=subprocess.PIPE,
            stderr=subprocess.STDOUT,
            shell=True)
    except subprocess.CalledProcessError:
        return '0'
    tokens = output.split()
    for token in tokens:
        if re.match(b'[0-9.]*', token):
            return token.decode('ascii')
    return '0'

graphviz_found = LooseVersion(get_graphviz_version())
graphviz_broken = LooseVersion('0.30')

if graphviz_found >= graphviz_broken:
    needs_sphinx = '1.2b2'
else:
    needs_sphinx = '1.1'




On Wed, Nov 20, 2013 at 6:04 PM, Miguel de Val-Borro <miguel.deval at gmail.com
> wrote:

> Hi Russell,
>
> Can you check the setting of the "needs_sphinx" variable in the
> astropy/docs/conf.py configuration file? If the file has not been
> modified locally this line should be commented out. I have just tried to
> build the HTML documentation from the current master branch and it
> worked fine with Sphinx 1.1.3 on a Linux system.
>
> Miguel
>
> On Wed, Nov 20, 2013 at 04:11:19PM -0500, Russell Hewett wrote:
> > Hi All,
> >
> > I can't seem to get the docs to build, ever since I installed graphviz.
>  It
> > worked beforehand, with the older version of sphinx that comes with
> > anaconda.  Any ideas?
> >
> > C:\Users\rhewett\research\software-projects\astropy\docs>make html
> > Running Sphinx v1.2b2
> >
> > Sphinx version error:
> > This project needs at least Sphinx v1.2b2 and therefore cannot be built
> > with this version.
> >
> > (Also doesn't work with 1.2b3)
> >
> > C:\Users\rhewett\research\software-projects\astropy\docs>ipython
> > Python 2.7.5 |Anaconda 1.7.0 (64-bit)| (default, Jul  1 2013, 12:37:52)
> > [MSC v.1500 64 bit (AMD64)]
> > Type "copyright", "credits" or "license" for more information.
> >
> > IPython 1.1.0 -- An enhanced Interactive Python.
> > ?         -> Introduction and overview of IPython's features.
> > %quickref -> Quick reference.
> > help      -> Python's own help system.
> > object?   -> Details about 'object', use 'object??' for extra details.
> >
> > In [1]: import sphinx
> >
> > In [2]: sphinx.__version__
> > Out[2]: '1.2b2'
> >
> >
> > -Russ
> >
> > --
> > Russell J. Hewett
> > Postdoctoral Associate
> > Imaging and Computing Group
> > Department of Mathematics
> > Massachusetts Institute of Technology
> > www.russellhewett.com
>
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131120/552cb87d/attachment.html>

From miguel.deval at gmail.com  Wed Nov 20 19:24:09 2013
From: miguel.deval at gmail.com (Miguel de Val-Borro)
Date: Wed, 20 Nov 2013 19:24:09 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
	<CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
Message-ID: <20131121002409.GS4013@cfhs5>

On Wed, Nov 20, 2013 at 06:20:19PM -0500, Russell Hewett wrote:
> def get_graphviz_version():
>     try:
>         output = subprocess.check_output(
>             ['dot', '-V'], stdin=subprocess.PIPE,
>             stderr=subprocess.STDOUT,
>             shell=True)
>     except subprocess.CalledProcessError:
>         return '0'
>     tokens = output.split()
>     for token in tokens:
>         if re.match(b'[0-9.]*', token):
>             return token.decode('ascii')
>     return '0'
> 
> graphviz_found = LooseVersion(get_graphviz_version())
> graphviz_broken = LooseVersion('0.30')
> 
> if graphviz_found >= graphviz_broken:
>     needs_sphinx = '1.2b2'
> else:
>     needs_sphinx = '1.1'

It looks like the version comparison in Sphinx is done with the
major.minor numbers in the version string. Could you try to replace in
that file:

needs_sphinx = '1.2b2'
by
needs_sphinx = '1.2'

I'm not sure that it will help but maybe the comparison is failing
because of that.


From russell.j.hewett at gmail.com  Wed Nov 20 20:32:29 2013
From: russell.j.hewett at gmail.com (Russell Hewett)
Date: Wed, 20 Nov 2013 20:32:29 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <20131121002409.GS4013@cfhs5>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
	<CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
	<20131121002409.GS4013@cfhs5>
Message-ID: <CAJ7zNxsmsSmxuwxf46jwpCFM2CwKGEB5xyP6SCabbr3c5mFimw@mail.gmail.com>

Still no dice.


On Wed, Nov 20, 2013 at 7:24 PM, Miguel de Val-Borro <miguel.deval at gmail.com
> wrote:

> On Wed, Nov 20, 2013 at 06:20:19PM -0500, Russell Hewett wrote:
> > def get_graphviz_version():
> >     try:
> >         output = subprocess.check_output(
> >             ['dot', '-V'], stdin=subprocess.PIPE,
> >             stderr=subprocess.STDOUT,
> >             shell=True)
> >     except subprocess.CalledProcessError:
> >         return '0'
> >     tokens = output.split()
> >     for token in tokens:
> >         if re.match(b'[0-9.]*', token):
> >             return token.decode('ascii')
> >     return '0'
> >
> > graphviz_found = LooseVersion(get_graphviz_version())
> > graphviz_broken = LooseVersion('0.30')
> >
> > if graphviz_found >= graphviz_broken:
> >     needs_sphinx = '1.2b2'
> > else:
> >     needs_sphinx = '1.1'
>
> It looks like the version comparison in Sphinx is done with the
> major.minor numbers in the version string. Could you try to replace in
> that file:
>
> needs_sphinx = '1.2b2'
> by
> needs_sphinx = '1.2'
>
> I'm not sure that it will help but maybe the comparison is failing
> because of that.
> _______________________________________________
> 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/20131120/1fd15f23/attachment.html>

From erik.tollerud at gmail.com  Wed Nov 20 20:35:11 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 20 Nov 2013 20:35:11 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <20131121002409.GS4013@cfhs5>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
	<CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
	<20131121002409.GS4013@cfhs5>
Message-ID: <CAARXUwVBfpEtz91LhDgXGzRYYAuhSb6E7=aWS6gaxFryXpHuMg@mail.gmail.com>

To clarify why this is necessary: it turns out that sphinx used
something in the graphviz API that was either private or deprecated,
and it changed between graphviz 0.28 and 0.30.  Sphinx fixed this in
version 1.2 beta something or other, but that means if you have Sphinx
1.1.3 (the current release version) and a graphviz newer than 0.28,
any graphviz graphs (including the class inheritance diagrams) cause
sphinx to fail.

The really odd thing is that it says you *have* Sphinx v1.2b2.  Is
there any chance you have two different sphinx versions installed on
top of each other?  It's *possible* that would make it think it's
version 1.2, when the actual code getting called is 1.1.3 ... one way
to check this might be to edit astropy/astropy/sphinx/conf.py to add a
``print sphinx.__version__`` directly under the `need_sphinx`
definitions.  Then you'd know for sure which version it was actually
using there.

On Wed, Nov 20, 2013 at 7:24 PM, Miguel de Val-Borro
<miguel.deval at gmail.com> wrote:
> On Wed, Nov 20, 2013 at 06:20:19PM -0500, Russell Hewett wrote:
>> def get_graphviz_version():
>>     try:
>>         output = subprocess.check_output(
>>             ['dot', '-V'], stdin=subprocess.PIPE,
>>             stderr=subprocess.STDOUT,
>>             shell=True)
>>     except subprocess.CalledProcessError:
>>         return '0'
>>     tokens = output.split()
>>     for token in tokens:
>>         if re.match(b'[0-9.]*', token):
>>             return token.decode('ascii')
>>     return '0'
>>
>> graphviz_found = LooseVersion(get_graphviz_version())
>> graphviz_broken = LooseVersion('0.30')
>>
>> if graphviz_found >= graphviz_broken:
>>     needs_sphinx = '1.2b2'
>> else:
>>     needs_sphinx = '1.1'
>
> It looks like the version comparison in Sphinx is done with the
> major.minor numbers in the version string. Could you try to replace in
> that file:
>
> needs_sphinx = '1.2b2'
> by
> needs_sphinx = '1.2'
>
> I'm not sure that it will help but maybe the comparison is failing
> because of that.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Erik


From rhewett at mit.edu  Wed Nov 20 20:46:14 2013
From: rhewett at mit.edu (Russell Hewett)
Date: Wed, 20 Nov 2013 20:46:14 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <CAARXUwVBfpEtz91LhDgXGzRYYAuhSb6E7=aWS6gaxFryXpHuMg@mail.gmail.com>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
	<CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
	<20131121002409.GS4013@cfhs5>
	<CAARXUwVBfpEtz91LhDgXGzRYYAuhSb6E7=aWS6gaxFryXpHuMg@mail.gmail.com>
Message-ID: <CAJ7zNxs39CAFb_-ca2RxCYyso_k3ZArdgO6wkikc0qyON0b_1w@mail.gmail.com>

OK, I take that back.  Changing '1.2b2'  to '1.2' worked.  I had forgotten
that that particular conf file was burried in the package and I was not in
develop mode, so live updates were meaningless.  Had to reinstall for the
change to take effect.

That said, following Erik's advice, I did check, and the conf is indeed
getting sphinx 1.2b2.  (And we can thus conclude that conda uninstall works
correctly.)



On Wed, Nov 20, 2013 at 8:35 PM, Erik Tollerud <erik.tollerud at gmail.com>wrote:

> To clarify why this is necessary: it turns out that sphinx used
> something in the graphviz API that was either private or deprecated,
> and it changed between graphviz 0.28 and 0.30.  Sphinx fixed this in
> version 1.2 beta something or other, but that means if you have Sphinx
> 1.1.3 (the current release version) and a graphviz newer than 0.28,
> any graphviz graphs (including the class inheritance diagrams) cause
> sphinx to fail.
>
> The really odd thing is that it says you *have* Sphinx v1.2b2.  Is
> there any chance you have two different sphinx versions installed on
> top of each other?  It's *possible* that would make it think it's
> version 1.2, when the actual code getting called is 1.1.3 ... one way
> to check this might be to edit astropy/astropy/sphinx/conf.py to add a
> ``print sphinx.__version__`` directly under the `need_sphinx`
> definitions.  Then you'd know for sure which version it was actually
> using there.
>
> On Wed, Nov 20, 2013 at 7:24 PM, Miguel de Val-Borro
> <miguel.deval at gmail.com> wrote:
> > On Wed, Nov 20, 2013 at 06:20:19PM -0500, Russell Hewett wrote:
> >> def get_graphviz_version():
> >>     try:
> >>         output = subprocess.check_output(
> >>             ['dot', '-V'], stdin=subprocess.PIPE,
> >>             stderr=subprocess.STDOUT,
> >>             shell=True)
> >>     except subprocess.CalledProcessError:
> >>         return '0'
> >>     tokens = output.split()
> >>     for token in tokens:
> >>         if re.match(b'[0-9.]*', token):
> >>             return token.decode('ascii')
> >>     return '0'
> >>
> >> graphviz_found = LooseVersion(get_graphviz_version())
> >> graphviz_broken = LooseVersion('0.30')
> >>
> >> if graphviz_found >= graphviz_broken:
> >>     needs_sphinx = '1.2b2'
> >> else:
> >>     needs_sphinx = '1.1'
> >
> > It looks like the version comparison in Sphinx is done with the
> > major.minor numbers in the version string. Could you try to replace in
> > that file:
> >
> > needs_sphinx = '1.2b2'
> > by
> > needs_sphinx = '1.2'
> >
> > I'm not sure that it will help but maybe the comparison is failing
> > because of that.
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Erik
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Russell J. Hewett
Postdoctoral Associate
Imaging and Computing Group
Department of Mathematics
Massachusetts Institute of Technology
www.russellhewett.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131120/84f61ffc/attachment.html>

From miguel.deval at gmail.com  Wed Nov 20 21:09:05 2013
From: miguel.deval at gmail.com (Miguel de Val-Borro)
Date: Wed, 20 Nov 2013 21:09:05 -0500
Subject: [AstroPy] docs building issue
In-Reply-To: <CAJ7zNxs39CAFb_-ca2RxCYyso_k3ZArdgO6wkikc0qyON0b_1w@mail.gmail.com>
References: <CAJ7zNxtLhT5j-uZPeTbhJMCzFu7_qpccvy=xB-kasvtswwMeiw@mail.gmail.com>
	<20131120230454.GQ4013@cfhs5>
	<CAJ7zNxuaRKqMOY3gknj6TkpgJ_JBCK+g9NaKwWjoS=B9kRuBhA@mail.gmail.com>
	<20131121002409.GS4013@cfhs5>
	<CAARXUwVBfpEtz91LhDgXGzRYYAuhSb6E7=aWS6gaxFryXpHuMg@mail.gmail.com>
	<CAJ7zNxs39CAFb_-ca2RxCYyso_k3ZArdgO6wkikc0qyON0b_1w@mail.gmail.com>
Message-ID: <20131121020905.GT4013@cfhs5>

On Wed, Nov 20, 2013 at 08:46:14PM -0500, Russell Hewett wrote:
> OK, I take that back.  Changing '1.2b2'  to '1.2' worked.  I had forgotten
> that that particular conf file was burried in the package and I was not in
> develop mode, so live updates were meaningless.  Had to reinstall for the
> change to take effect.
> 
> That said, following Erik's advice, I did check, and the conf is indeed
> getting sphinx 1.2b2.  (And we can thus conclude that conda uninstall works
> correctly.)

Great that it works now. I just checked that sphinx is doing 
this comparison to raise the version error:
self.config.needs_sphinx > sphinx.__version__[:3]

So needs_sphinx = '1.2b2' will always raise the version requirement
error but using the '1.2' string should produce the expected result if
you are using versions 1.2b2 or 1.2b3.

I have opened a pull request to fix this bug:
https://github.com/astropy/astropy/pull/1812

Miguel

> On Wed, Nov 20, 2013 at 8:35 PM, Erik Tollerud <erik.tollerud at gmail.com>wrote:
> 
> > To clarify why this is necessary: it turns out that sphinx used
> > something in the graphviz API that was either private or deprecated,
> > and it changed between graphviz 0.28 and 0.30.  Sphinx fixed this in
> > version 1.2 beta something or other, but that means if you have Sphinx
> > 1.1.3 (the current release version) and a graphviz newer than 0.28,
> > any graphviz graphs (including the class inheritance diagrams) cause
> > sphinx to fail.
> >
> > The really odd thing is that it says you *have* Sphinx v1.2b2.  Is
> > there any chance you have two different sphinx versions installed on
> > top of each other?  It's *possible* that would make it think it's
> > version 1.2, when the actual code getting called is 1.1.3 ... one way
> > to check this might be to edit astropy/astropy/sphinx/conf.py to add a
> > ``print sphinx.__version__`` directly under the `need_sphinx`
> > definitions.  Then you'd know for sure which version it was actually
> > using there.
> >
> > On Wed, Nov 20, 2013 at 7:24 PM, Miguel de Val-Borro
> > <miguel.deval at gmail.com> wrote:
> > > On Wed, Nov 20, 2013 at 06:20:19PM -0500, Russell Hewett wrote:
> > >> def get_graphviz_version():
> > >>     try:
> > >>         output = subprocess.check_output(
> > >>             ['dot', '-V'], stdin=subprocess.PIPE,
> > >>             stderr=subprocess.STDOUT,
> > >>             shell=True)
> > >>     except subprocess.CalledProcessError:
> > >>         return '0'
> > >>     tokens = output.split()
> > >>     for token in tokens:
> > >>         if re.match(b'[0-9.]*', token):
> > >>             return token.decode('ascii')
> > >>     return '0'
> > >>
> > >> graphviz_found = LooseVersion(get_graphviz_version())
> > >> graphviz_broken = LooseVersion('0.30')
> > >>
> > >> if graphviz_found >= graphviz_broken:
> > >>     needs_sphinx = '1.2b2'
> > >> else:
> > >>     needs_sphinx = '1.1'
> > >
> > > It looks like the version comparison in Sphinx is done with the
> > > major.minor numbers in the version string. Could you try to replace in
> > > that file:
> > >
> > > needs_sphinx = '1.2b2'
> > > by
> > > needs_sphinx = '1.2'
> > >
> > > I'm not sure that it will help but maybe the comparison is failing
> > > because of that.
> > > _______________________________________________
> > > AstroPy mailing list
> > > AstroPy at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> > --
> > Erik
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
> 
> 
> 
> -- 
> Russell J. Hewett
> Postdoctoral Associate
> Imaging and Computing Group
> Department of Mathematics
> Massachusetts Institute of Technology
> www.russellhewett.com

> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Thu Nov 21 09:49:11 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 21 Nov 2013 14:49:11 +0000
Subject: [AstroPy] Job Ad: Scientific (Python) Software Developer in a Max
 Planck Research Group
Message-ID: <CAGMHX_1pMe54cni=bOd0Eazn141d_sy2ZPkL_CrYX=FNHx49uQ@mail.gmail.com>

Dear colleagues,

I am hiring someone to work on Scientific Python software development
in my research group at the Max Planck Institute for Astronomy in
Heidelberg:

http://www.mpia.de/Public/MPIA/jobs/13-16en.pdf

This is a fixed-term position, and you do not need to have a formal
computer science education to apply - the position would therefore be
ideal for example for people in Astronomy who would like to transition
to a software development job and perfect their coding skills, or
people with a computer science background who want to learn more about
Astronomy.

If you have any questions about the position, please do not hesitate
to contact me at robitaille-mprg-applications at mpia.de

Please forward this message to anyone that you think might be interested!

Best regards,
Thomas Robitaille


From jzuhone at gmail.com  Sat Nov 23 15:53:13 2013
From: jzuhone at gmail.com (John ZuHone)
Date: Sat, 23 Nov 2013 15:53:13 -0500
Subject: [AstroPy] Announcing yt 2.6
Message-ID: <BB3237E4-9585-4668-8A6C-A7F5F8EA46A5@gmail.com>

I'm forwarding this release announcement on behalf of our release manager, Kacper Kowalik.  Please forward to other interested parties.

---------- Forwarded message ----------
From: Kacper Kowalik<xarthisius.kk at gmail.com>
Date: Sat, Nov 23, 2013 at 12:19 AM
Subject: [yt-dev] Announcing: yt 2.6
To: Discussion of the yt analysis package <yt-users at lists.spacepope.org>, "yt-dev at lists.spacepope.org" <yt-dev at lists.spacepope.org>


Hi all,

We are pleased to announce the release of yt 2.6.  This is a major
release that includes new features and major updates along with all the
bugs identified and fixed since the release of 2.5.5 on August 28.  We
currently plan for this to be the final major release of the yt 2.X
release series, although bug fix releases will continue for the
foreseeable future.

Please forward this email to other interested parties.

Most notable changes include:

 * Relicensing whole project to BSD 3-clause
 * Automated absorption line fitting module developed by Hilary Egan
 * Significant improvement in documentation in a joint effort of the dev
team led by Cameron Hummels
 * Documentation now includes inlined IPython notebooks, thanks to
Nathan Goldbaum
 * RAMSES, ART, Tiger, Maestro and Castro frontends removal as their
counterparts in 3.0 branch exceeded them both performance and capability
wise.  All users of the aforementioned codes are strongly advised to
migrate to yt-3.0
 * Python stack update, which now features: ipython-1.1.0, hg-2.8,
python-2.7.6 numpy-1.7.1
 * New ProfilePlot and PhasePlot classes thanks to Britton Smith, Nathan
Goldbaum and Matt Turk. Previous mechanisms (i.e. profiles using
PlotCollection) are deprecated and will be removed in future versions.
 * Projections of the Sunyaev-Zeldovich effect using SZpack implemented
by John ZuHone
 * Generating Mock X-ray Photons now possible thanks to John ZuHone
 * Introduction of Transfer Function Helper by Sam Skillman
 * Initial support for installing yt with the package management system
Conda.
 * The addition of a frontend for the Pluto code by Andrew Myers
 * The addition of an OBJ exporter to enable transparent and
multi-surface exports of surfaces to Blender and Sketchfab by Jiill Naiman
 * yt can now export to RADMC3D thanks to Andrew Myers
 * Considerably (10x+) faster kD-tree building for volume rendering
thanks to Sam Skillman
 * Full integration and demonstration of all available colormaps
included in documentation thanks to Cameron Hummels

There have also been a number of minor bugs fixed in this release.  Some
highlights:

 * Center of the plot in off_axis_projection plots is now calculated
correctly, thanks to William Gray
 * Several enhancements to PlotWindow made by Nathan Goldbaum:
   - Save accepts paths to directories
   - Better handling of highly rectangular domains
   - Axes and colorbars are now toggleable
   - Nicer output in ipython notebook
   - eps_writer is now compatible with PlotWindow, thanks to John Wise
 * yt command line enhancements thanks to Devin Silvia and Matt Turk
 * Several enhancements to Athena frontend by John ZuHone
 * Improvements for OSX support (up to Mavericks)
 * Updates to halo finding routines by Britton Smith

We?d also like to recognize the new contributors to the yt 2.x source
code and documentation during the yt 2.5 development cycle:

 * Hilary Egan
 * John Forbes
 * William Gray
 * Stuart Mumford
 * Jill Naiman
 * Doug Rudd
 * Noel Scudder
 * Elizabeth Tasker

If you are using the stable branch of yt from an installation script,
you can upgrade using "yt update" or "yt update --all" to upgrade your
full dependency stack.  If you are using the development branch, you
may already have these fixes.  A tarball of this release has been
uploaded to the Python Package Index (PyPI).

Documentation for this release is available at:

http://yt-project.org/docs/2.6/

Previous announcements from the 2.5 release cycle can be found at:

2.5.5:
http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-August/003929.html
2.5.4:
http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-July/003716.html
2.5.3:
http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-June/003669.html
2.5.2:
http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-May/003595.html
2.5.1:
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2013-March/002988.html

Thank you very much,

Kacper, on behalf of the yt development team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131123/2c6dc050/attachment.html>

From yannick.roehlly at lam.fr  Sun Nov 24 18:50:23 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Mon, 25 Nov 2013 00:50:23 +0100
Subject: [AstroPy] Problem with astropy 03 and quantities
Message-ID: <20131125005023.5ba10e11@lam.fr>

Dear all,

I've encountered a problem with astropy 0.3 and I wonder how to solve
it and if it's an astropy issue or not.

I've got some code (a SED fitting code) that used to work with astropy
0.2.5 and no longer works with version 0.3, failing with a "ValueError:
setting an array element with a sequence." when trying to copy an array
with numpy.copy.

I managed to trace the problem. At some point, I'm using the cosmology
module to compute a luminosity distance while building an array of
fluxes. With astropy 0.3, the luminosity_distance functions returns
quantities. So I have a "quantified" array that can not be copied with
numpy.copy.

So, I wonder if there is a way to disable this behaviour and make
astropy not use quantities.

Also, I wonder if this is not an astropy issue as it breaks working
code (at least, there should be a warning in the changelog).

Yannick

PS: Does the use of quantities slows down the computation or their
effect is negligible?

-- 
Wernher von Braun settled for a V-2 when he coulda had a V-8.


From kyle at anl.gov  Sun Nov 24 19:16:53 2013
From: kyle at anl.gov (Kyle Barbary)
Date: Sun, 24 Nov 2013 18:16:53 -0600
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <20131125005023.5ba10e11@lam.fr>
References: <20131125005023.5ba10e11@lam.fr>
Message-ID: <CANO7-x-Z5CmBpDK-yja1gOjkTRPZhYN61ym6-fK7DTY+C0R9fw@mail.gmail.com>

Hi Yannick,

I'll let others answer your main question, but to answer the PS, there is a
discussion of the performance hit to astropy.cosmology due to using
Quantity here:
https://github.com/astropy/astropy/issues/406
Note however that Quantity has seen some optimization since this
discussion, so the timings there probably aren't applicable any more.

- Kyle


On Sun, Nov 24, 2013 at 5:50 PM, Yannick Roehlly <yannick.roehlly at lam.fr>wrote:

> Dear all,
>
> I've encountered a problem with astropy 0.3 and I wonder how to solve
> it and if it's an astropy issue or not.
>
> I've got some code (a SED fitting code) that used to work with astropy
> 0.2.5 and no longer works with version 0.3, failing with a "ValueError:
> setting an array element with a sequence." when trying to copy an array
> with numpy.copy.
>
> I managed to trace the problem. At some point, I'm using the cosmology
> module to compute a luminosity distance while building an array of
> fluxes. With astropy 0.3, the luminosity_distance functions returns
> quantities. So I have a "quantified" array that can not be copied with
> numpy.copy.
>
> So, I wonder if there is a way to disable this behaviour and make
> astropy not use quantities.
>
> Also, I wonder if this is not an astropy issue as it breaks working
> code (at least, there should be a warning in the changelog).
>
> Yannick
>
> PS: Does the use of quantities slows down the computation or their
> effect is negligible?
>
> --
> Wernher von Braun settled for a V-2 when he coulda had a V-8.
> _______________________________________________
> 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/20131124/14c9032a/attachment.html>

From thomas.robitaille at gmail.com  Mon Nov 25 04:47:37 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 25 Nov 2013 10:47:37 +0100
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <20131125005023.5ba10e11@lam.fr>
References: <20131125005023.5ba10e11@lam.fr>
Message-ID: <CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>

Hi Yannick,

First, regarding the ``copy`` issue, could you provide some code to
replicate this? ``copy`` should work with Quantites:

    In [5]: np.copy(np.array([1,2,3]) * u.m)
    Out[5]: array([1, 2, 3])

To adapt your code, you simply need to add ``.value`` to the quantity
to get the underlying Numpy array if you want to drop the units.

There is a performance penalty in using Quantity in 0.3, but already
in 0.3.1 there will be significant optimizations, and given that
``Quantity`` is widely used in Astropy, you can expect more work on
optimizations in future.

By the way, there *is* an entry in the changelog:

http://docs.astropy.org/en/stable/changelog.html#api-changes

under ``astropy.cosmology``.

Cheers,
Tom

On 25 November 2013 00:50, Yannick Roehlly <yannick.roehlly at lam.fr> wrote:
> Dear all,
>
> I've encountered a problem with astropy 0.3 and I wonder how to solve
> it and if it's an astropy issue or not.
>
> I've got some code (a SED fitting code) that used to work with astropy
> 0.2.5 and no longer works with version 0.3, failing with a "ValueError:
> setting an array element with a sequence." when trying to copy an array
> with numpy.copy.
>
> I managed to trace the problem. At some point, I'm using the cosmology
> module to compute a luminosity distance while building an array of
> fluxes. With astropy 0.3, the luminosity_distance functions returns
> quantities. So I have a "quantified" array that can not be copied with
> numpy.copy.
>
> So, I wonder if there is a way to disable this behaviour and make
> astropy not use quantities.
>
> Also, I wonder if this is not an astropy issue as it breaks working
> code (at least, there should be a warning in the changelog).
>
> Yannick
>
> PS: Does the use of quantities slows down the computation or their
> effect is negligible?
>
> --
> Wernher von Braun settled for a V-2 when he coulda had a V-8.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From yannick.roehlly at lam.fr  Mon Nov 25 05:14:53 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Mon, 25 Nov 2013 11:14:53 +0100
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>
References: <20131125005023.5ba10e11@lam.fr>
	<CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>
Message-ID: <20131125111453.4cf1eb4e@lam.fr>

Hi Thomas,

Thanks for the answer.

Le Mon, 25 Nov 2013 10:47:37 +0100,
Thomas Robitaille <thomas.robitaille at gmail.com> a ?crit :

> First, regarding the ``copy`` issue, could you provide some code to
> replicate this? ``copy`` should work with Quantites:
> 
>     In [5]: np.copy(np.array([1,2,3]) * u.m)
>     Out[5]: array([1, 2, 3])

np.copy should accept an array-like but here it fails if it's an array
of quantities.

 In [16]: np.copy([x * u.m for x in xrange(10)])
 ERROR:astropy:ValueError: setting an array element with a sequence.
 ERROR: ValueError: setting an array element with a sequence.
 [numpy.lib.function_base]
 ---------------------------------------------------------------------------
 ValueError                                Traceback (most recent call
 last) <ipython-input-16-dd73be22bb28> in <module>() ----> 1 np.copy([x
 * u.m for x in xrange(10)])
 
 /usr/lib/pymodules/python2.7/numpy/lib/function_base.pyc in copy(a,
 order) 828 
     829     """
 --> 830     return array(a, order=order, copy=True)
     831 
     832 # Basic operations
 
 ValueError: setting an array element with a sequence.

I understand that this is not a bug as everything works as expected and
as numpy can't manage a Quantity datatype.

> To adapt your code, you simply need to add ``.value`` to the quantity
> to get the underlying Numpy array if you want to drop the units.

Yes, but that means the code will not work with prior version of
astropy. I'd better change it to have a numpy.array instead of a list
at the point the copy fails.

> There is a performance penalty in using Quantity in 0.3, but already
> in 0.3.1 there will be significant optimizations, and given that
> ``Quantity`` is widely used in Astropy, you can expect more work on
> optimizations in future.

My question was not for the astropy internals but for the computation
on arrays. Thanks to the pointer Kyle gave me, I've seen that some
optimizations made by Alex consist in splitting the value from the
quantity, making the computations and joining them back.

> By the way, there *is* an entry in the changelog:

I've read it ;-) but I meant a warning, as it can break some code. But
I admit I'm in a specific case.

Cheers,

Yannick

-- 
One can't proceed from the informal to the formal by formal means.


From neilcrighton at gmail.com  Mon Nov 25 05:42:42 2013
From: neilcrighton at gmail.com (Neil Crighton)
Date: Mon, 25 Nov 2013 21:42:42 +1100
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <20131125111453.4cf1eb4e@lam.fr>
References: <20131125005023.5ba10e11@lam.fr>
	<CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>
	<20131125111453.4cf1eb4e@lam.fr>
Message-ID: <CAFDPQ57SVP8kfZk1R_HaMrFEc8m9X=VLPGbOgimCH3wBq-w7gQ@mail.gmail.com>

Hi Yannick,

We're also aware of the inconvenience and annoyance that
backwards-incompatible changes can cause. We try to avoid them if at all
possible. As we get closer to version 1.0 we expect that fewer such changes
will be necessary. I would hope that no further backwards-incompatible
changes are needed for cosmology after 0.3, but we can't make any promises
until version 1.0.

Neil
On 25/11/2013 9:15 PM, "Yannick Roehlly" <yannick.roehlly at lam.fr> wrote:

> Hi Thomas,
>
> Thanks for the answer.
>
> Le Mon, 25 Nov 2013 10:47:37 +0100,
> Thomas Robitaille <thomas.robitaille at gmail.com> a ?crit :
>
> > First, regarding the ``copy`` issue, could you provide some code to
> > replicate this? ``copy`` should work with Quantites:
> >
> >     In [5]: np.copy(np.array([1,2,3]) * u.m)
> >     Out[5]: array([1, 2, 3])
>
> np.copy should accept an array-like but here it fails if it's an array
> of quantities.
>
>  In [16]: np.copy([x * u.m for x in xrange(10)])
>  ERROR:astropy:ValueError: setting an array element with a sequence.
>  ERROR: ValueError: setting an array element with a sequence.
>  [numpy.lib.function_base]
>
>  ---------------------------------------------------------------------------
>  ValueError                                Traceback (most recent call
>  last) <ipython-input-16-dd73be22bb28> in <module>() ----> 1 np.copy([x
>  * u.m for x in xrange(10)])
>
>  /usr/lib/pymodules/python2.7/numpy/lib/function_base.pyc in copy(a,
>  order) 828
>      829     """
>  --> 830     return array(a, order=order, copy=True)
>      831
>      832 # Basic operations
>
>  ValueError: setting an array element with a sequence.
>
> I understand that this is not a bug as everything works as expected and
> as numpy can't manage a Quantity datatype.
>
> > To adapt your code, you simply need to add ``.value`` to the quantity
> > to get the underlying Numpy array if you want to drop the units.
>
> Yes, but that means the code will not work with prior version of
> astropy. I'd better change it to have a numpy.array instead of a list
> at the point the copy fails.
>
> > There is a performance penalty in using Quantity in 0.3, but already
> > in 0.3.1 there will be significant optimizations, and given that
> > ``Quantity`` is widely used in Astropy, you can expect more work on
> > optimizations in future.
>
> My question was not for the astropy internals but for the computation
> on arrays. Thanks to the pointer Kyle gave me, I've seen that some
> optimizations made by Alex consist in splitting the value from the
> quantity, making the computations and joining them back.
>
> > By the way, there *is* an entry in the changelog:
>
> I've read it ;-) but I meant a warning, as it can break some code. But
> I admit I'm in a specific case.
>
> Cheers,
>
> Yannick
>
> --
> One can't proceed from the informal to the formal by formal means.
> _______________________________________________
> 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/20131125/8c091cda/attachment.html>

From thomas.robitaille at gmail.com  Mon Nov 25 06:43:02 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 25 Nov 2013 12:43:02 +0100
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <20131125111453.4cf1eb4e@lam.fr>
References: <20131125005023.5ba10e11@lam.fr>
	<CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>
	<20131125111453.4cf1eb4e@lam.fr>
Message-ID: <CAGMHX_1mvYQkgcr1Hb9DuhJ4xdcGTzExqfT2M7u+bPqK_VAMzA@mail.gmail.com>

Hi Yannick,

On 25 November 2013 11:14, Yannick Roehlly <yannick.roehlly at lam.fr> wrote:
> Hi Thomas,
>
> Thanks for the answer.
>
> Le Mon, 25 Nov 2013 10:47:37 +0100,
> Thomas Robitaille <thomas.robitaille at gmail.com> a ?crit :
>
>> First, regarding the ``copy`` issue, could you provide some code to
>> replicate this? ``copy`` should work with Quantites:
>>
>>     In [5]: np.copy(np.array([1,2,3]) * u.m)
>>     Out[5]: array([1, 2, 3])
>
> np.copy should accept an array-like but here it fails if it's an array
> of quantities.
>
>  In [16]: np.copy([x * u.m for x in xrange(10)])
>  ERROR:astropy:ValueError: setting an array element with a sequence.
>  ERROR: ValueError: setting an array element with a sequence.
>  [numpy.lib.function_base]
>  ---------------------------------------------------------------------------
>  ValueError                                Traceback (most recent call
>  last) <ipython-input-16-dd73be22bb28> in <module>() ----> 1 np.copy([x
>  * u.m for x in xrange(10)])
>
>  /usr/lib/pymodules/python2.7/numpy/lib/function_base.pyc in copy(a,
>  order) 828
>      829     """
>  --> 830     return array(a, order=order, copy=True)
>      831
>      832 # Basic operations
>
>  ValueError: setting an array element with a sequence.

Ah - in this case, are you the one making the array of quantity
objects, or is that coming from astropy.cosmology? We should
definitely never return an array of quantities, but rather a quantity
array.

> I understand that this is not a bug as everything works as expected and
> as numpy can't manage a Quantity datatype.
>
>> To adapt your code, you simply need to add ``.value`` to the quantity
>> to get the underlying Numpy array if you want to drop the units.
>
> Yes, but that means the code will not work with prior version of
> astropy. I'd better change it to have a numpy.array instead of a list
> at the point the copy fails.

I would suggest using a try...except in your code for this case, so
that you can maintain backward-compatibility.

>> There is a performance penalty in using Quantity in 0.3, but already
>> in 0.3.1 there will be significant optimizations, and given that
>> ``Quantity`` is widely used in Astropy, you can expect more work on
>> optimizations in future.
>
> My question was not for the astropy internals but for the computation
> on arrays. Thanks to the pointer Kyle gave me, I've seen that some
> optimizations made by Alex consist in splitting the value from the
> quantity, making the computations and joining them back.
>
>> By the way, there *is* an entry in the changelog:
>
> I've read it ;-) but I meant a warning, as it can break some code. But
> I admit I'm in a specific case.

To some extent, all of the things in the API changes section might
break code - for 0.3 the list is unfortunately quite long, but as Neil
pointed out, we want to make sure we minimize this in future.

Cheers,
Tom

>
> Cheers,
>
> Yannick
>
> --
> One can't proceed from the informal to the formal by formal means.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From yannick.roehlly at lam.fr  Mon Nov 25 07:19:59 2013
From: yannick.roehlly at lam.fr (Yannick Roehlly)
Date: Mon, 25 Nov 2013 13:19:59 +0100
Subject: [AstroPy] Problem with astropy 03 and quantities
In-Reply-To: <CAGMHX_1mvYQkgcr1Hb9DuhJ4xdcGTzExqfT2M7u+bPqK_VAMzA@mail.gmail.com>
References: <20131125005023.5ba10e11@lam.fr>
	<CAGMHX_1LKRs=90ioysJLOmeCmKaXVv0jPQjAYFC4XgBLGks7Ww@mail.gmail.com>
	<20131125111453.4cf1eb4e@lam.fr>
	<CAGMHX_1mvYQkgcr1Hb9DuhJ4xdcGTzExqfT2M7u+bPqK_VAMzA@mail.gmail.com>
Message-ID: <20131125131959.024a4731@lam.fr>

Le Mon, 25 Nov 2013 12:43:02 +0100,
Thomas Robitaille <thomas.robitaille at gmail.com> a ?crit :

> Ah - in this case, are you the one making the array of quantity
> objects, or is that coming from astropy.cosmology? We should
> definitely never return an array of quantities, but rather a quantity
> array.

Don't worry, I was making the array.

Cheers,

Yannick

-- 
An authority is a person who can tell you more about something than you
really care to know.


From erik.tollerud at gmail.com  Mon Nov 25 17:09:41 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Mon, 25 Nov 2013 17:09:41 -0500
Subject: [AstroPy] ANN: Astropy v0.3 released
Message-ID: <CAARXUwW2LoXCUNfoK+Ma_S9ncv1+Co6Wm_ffCaDLT5stbp04LA@mail.gmail.com>

Dear colleagues,

We are very happy to announce the second major public release (v0.3)
of the Astropy package, a core Python package for Astronomy:

   http://www.astropy.org

Astropy is a community-driven package intended to contain much of the
core functionality and common tools needed for performing astronomy
and astrophysics with Python.


New and improved functionality in this release includes:

* A new modeling package which provides a framework for fitting models to data
* Quantity has been re-implemented as a numpy array subclass,
enhancing performance and usability
* Unit conversion and Quantities are better integrated with other
parts of Astropy, simplifying many APIs and user code.
* New Table functionality for joining and aggregating tables
* Support for arrays of celestial coordinates
* A new virtual observatory cone search package
* A dedicated convolution sub-package with many predefined kernels

A full list of improvements, including examples, is provided at:

   http://docs.astropy.org/en/latest/whatsnew/0.3.html


Instructions for installing Astropy are provided at the
http://www.astropy.org website, and extensive documentation can be
found at:

   http://docs.astropy.org

Please report any issues, or request new features via our GitHub repository:

   https://github.com/astropy/astropy/issues

Over 50 developers have contributed code to Astropy so far, and you
can find out more about the team behind Astropy here:

   http://www.astropy.org/team.html


If you use Astropy directly - or as a dependency to another package -
for your work, please remember to include the following acknowledgment
at the end of paperst:

"This research made use of Astropy, a community-developed core Python
package for Astronomy (Astropy Collaboration, 2013)."

where ?(Astropy Collaboration, 2013)? is the Astropy paper which was
published this year:

 http://adsabs.harvard.edu/abs/2013A%26A...558A..33A


Please feel free to forward this announcement to anyone you think
might be interested in this release.


We hope that you enjoy using Astropy as much as we enjoyed developing it!

Erik Tollerud, Thomas Robitaille, and Perry Greenfield
on behalf of The Astropy Collaboration


From derek at astro.physik.uni-goettingen.de  Mon Nov 25 20:55:45 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Tue, 26 Nov 2013 02:55:45 +0100
Subject: [AstroPy] Astropy 0.2.5 compilation error using Intel compilers
	under Mac OS Mavericks and python under Homebrew
In-Reply-To: <528B6C94.7000804@stsci.edu>
References: <88FCD4D6-6CF8-4211-9E5B-298A4A2E0F92@iap.fr>	<CAGMHX_3+Sczye1_wD_6FVbMn5HsH31Q5D5uNQ=XjQeXxf8YHtA@mail.gmail.com>
	<44E61C16-E146-4D21-ADDA-0696B04FF0C8@iap.fr>
	<528B6C94.7000804@stsci.edu>
Message-ID: <7487BC36-4CEE-477D-B1D6-1E189CEBEE03@astro.physik.uni-goettingen.de>

Hi Mike,

On 19.11.2013, at 2:50PM, Michael Droettboom <mdroe at stsci.edu> wrote:

> On 11/18/2013 09:46 AM, Jean-Baptiste Marquette wrote:
>> 
>> Hi again,
>> 
>>> If the latter, then we should open a general issue to support the
>>> intel C compiler (I think no one had requested it so far, hence why it
>>> went unnoticed). Try setting your compiler to clang instead to see if
>>> it helps.
>> 
>> clang successful, thus we are facing an icc compiler issue. Supporting it would be great. Emmanuel Bertin told me it is much more efficient in some situations, for example with sine or cosine functions.
> 
> We'll need some way to provide the financial support for this, of course.  ICC is far from free.  It doesn't appear on paper that STScI would be eligible for academic pricing or non-commercial pricing by Intel's definition [1] [2], so it's $699/box or $2,499 for 2-concurrent floating site license.  It might be worth experimenting with the 30-day evaluation license to see what the performance benefits are before committing to long-term support of that compiler.  That kind of money actually goes a real long way toward hosted testing solutions etc. which would benefit a lot more users than supporting a commercial compiler.  All that said, we can always accept small patches to support ICC even if none of the core developers have a copy.
> 
> [1] " For faculty or staff at degree-granting institutions of higher learning"
> [2] " Non-commercial software development means you are not paid and/or compensated in any form, by anyone, for software development using the Intel? Software Development Products under the terms of the non-commercial license."

for the record, on Linux I was able to build astropy-0.3 with the Intel 13.1 compiler suite by simply
stealing numpy's compiler setup. After configuring and building numpy and scipy as described at
http://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl

I changed astropy/setup_helpers.py to

from distutils import log, sysconfig
from numpy.distutils import ccompiler

and 
> python setup.py build --help-compiler                       
List of available compilers:
  --compiler=bcpp     Borland C++ Compiler
  --compiler=cygwin   Cygwin port of GNU C Compiler for Win32
  --compiler=emx      EMX port of GNU C Compiler for OS/2
  --compiler=intel    Intel C Compiler for 32-bit applications
  --compiler=intele   Intel C Itanium Compiler for Itanium-based applications
  --compiler=intelem  Intel C Compiler for 64-bit applications
  --compiler=mingw32  Mingw32 port of GNU C Compiler for Win32
  --compiler=msvc     Microsoft Visual C++
  --compiler=pathcc   PathScale Compiler for SiCortex-based applications
  --compiler=unix     standard UNIX-style compiler

> python setup.py build --compiler=intelem --fcompiler=intelem

did the job on our cluster!
The same trick did not work so neatly for building some other prerequisites like cython and h5py, 
but I managed to force those with

LDSHARED='icc -shared [myoptions]' CC='icc [myoptions]' python setup.py build

I could certainly offer to test on our system for the regular releases.

The current release returns the same xFails that I get with the gcc-compiled version under OS X;
with the latest git master (0.4.dev6652) I got 4 additional Failures + 1 Error.

HTH,
					Derek


platform linux2 -- Python 2.7.5 -- pytest-2.4.0

Running tests with Astropy version 0.3.
Running tests in /usr/users/dhomeie/lib/python2.7/site-packages/astropy-0.3-py2.7-linux-x86_64.egg/astropy.

Platform: Linux-2.6.32-358.14.1.el6.x86_64-x86_64-with-redhat-6.4-Carbon

Executable: /home/product/applsw/python-2.7.5/bin/python2.7

Full Python Version: 
2.7.5 (default, Sep 23 2013, 14:39:38) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]

encodings: sys: ascii, locale: ANSI_X3.4-1968, filesystem: ANSI_X3.4-1968, unicode bits: 15
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.8.0
Scipy: 0.13.1
Matplotlib: not available
h5py: 2.2.0

collected 4898 items / 5 skipped 
astropy/table/tests/test_table.py ..................................................................................................................................................................................x..............
astropy/time/tests/test_precision.py ...?.x.
astropy/time/tests/test_quantity_interaction.py ..........x.
astropy/units/tests/test_quantity_array_methods.py .......x..............x..........x.x..........
astropy/units/tests/test_quantity_non_ufuncs.py xx
astropy/vo/client/tests/test_vo.py sssssssssss?x
astropy/wcs/tests/test_wcsprm.py ...........................................................................................x
===
4803 passed, 89 skipped, 11 xfailed in 182.16 seconds


 



From thomas.robitaille at gmail.com  Tue Nov 26 04:29:45 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 26 Nov 2013 10:29:45 +0100
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.3 released
In-Reply-To: <CAARXUwW2LoXCUNfoK+Ma_S9ncv1+Co6Wm_ffCaDLT5stbp04LA@mail.gmail.com>
References: <CAARXUwW2LoXCUNfoK+Ma_S9ncv1+Co6Wm_ffCaDLT5stbp04LA@mail.gmail.com>
Message-ID: <CAGMHX_2qRjLfbJsbCzg9SY8p3Yg26WBWgj5EDFnonmOsCOR9vQ@mail.gmail.com>

Just a quick note: for anyone using the Anaconda Python Distribution,
you can now update to the latest version of Astropy with:

  conda update astropy

MacPorts users can also update to the latest version using:

  sudo port selfupdate
  sudo port upgrade py27-astropy

(for other Python versions, replace 27 by e.g. 33 for Python 3.3)

Astropy is in the process of being updated in Linux Package managers,
but there will be a delay before the latest version is available.

Cheers,
Tom


On 25 November 2013 23:09, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> Dear colleagues,
>
> We are very happy to announce the second major public release (v0.3)
> of the Astropy package, a core Python package for Astronomy:
>
>    http://www.astropy.org
>
> Astropy is a community-driven package intended to contain much of the
> core functionality and common tools needed for performing astronomy
> and astrophysics with Python.
>
>
> New and improved functionality in this release includes:
>
> * A new modeling package which provides a framework for fitting models to data
> * Quantity has been re-implemented as a numpy array subclass,
> enhancing performance and usability
> * Unit conversion and Quantities are better integrated with other
> parts of Astropy, simplifying many APIs and user code.
> * New Table functionality for joining and aggregating tables
> * Support for arrays of celestial coordinates
> * A new virtual observatory cone search package
> * A dedicated convolution sub-package with many predefined kernels
>
> A full list of improvements, including examples, is provided at:
>
>    http://docs.astropy.org/en/latest/whatsnew/0.3.html
>
>
> Instructions for installing Astropy are provided at the
> http://www.astropy.org website, and extensive documentation can be
> found at:
>
>    http://docs.astropy.org
>
> Please report any issues, or request new features via our GitHub repository:
>
>    https://github.com/astropy/astropy/issues
>
> Over 50 developers have contributed code to Astropy so far, and you
> can find out more about the team behind Astropy here:
>
>    http://www.astropy.org/team.html
>
>
> If you use Astropy directly - or as a dependency to another package -
> for your work, please remember to include the following acknowledgment
> at the end of paperst:
>
> "This research made use of Astropy, a community-developed core Python
> package for Astronomy (Astropy Collaboration, 2013)."
>
> where ?(Astropy Collaboration, 2013)? is the Astropy paper which was
> published this year:
>
>  http://adsabs.harvard.edu/abs/2013A%26A...558A..33A
>
>
> Please feel free to forward this announcement to anyone you think
> might be interested in this release.
>
>
> We hope that you enjoy using Astropy as much as we enjoyed developing it!
>
> Erik Tollerud, Thomas Robitaille, and Perry Greenfield
> on behalf of The Astropy Collaboration
>
> --
> You received this message because you are subscribed to the Google Groups "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


From marquett at iap.fr  Tue Nov 26 12:54:55 2013
From: marquett at iap.fr (Jean-Baptiste Marquette)
Date: Tue, 26 Nov 2013 18:54:55 +0100
Subject: [AstroPy] Astropy 0.3 and TPV projection
Message-ID: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr>

Hi Astropy gurus,

I'm just testing this new and impressive release with images from the SSO SkyMapper telescope, and got trouble with the TPV projection, since these images were calibrated using Emmanuel Bertin's SCAMP package. The message is:

WARNING: FITSFixedWarning: 'celfix' made the change 'Unrecognized projection code (TPV in CTYPE1)'. [astropy.wcs.wcs]

I previously seamlessly used the astLib package, and both ds9 and Gaia/Starlink image browsers recognize the TPV projection. Integration in Astropy's wcs module would be greatly appreciated as well.

Thanks for your help,
Cheers,
JB

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

From tim.jenness at gmail.com  Tue Nov 26 13:00:54 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Tue, 26 Nov 2013 11:00:54 -0700
Subject: [AstroPy] Astropy 0.3 and TPV projection
In-Reply-To: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr>
References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr>
Message-ID: <CA+G92RcUx+LWnLrif8iXdVD2=v2Sqo6j2TffK4JDwW6TMm7GMg@mail.gmail.com>

You can use pyast for the moment.


On Tue, Nov 26, 2013 at 10:54 AM, Jean-Baptiste Marquette
<marquett at iap.fr>wrote:

> Hi Astropy gurus,
>
> I'm just testing this new and impressive release with images from the SSO
> SkyMapper telescope, and got trouble with the TPV projection, since these
> images were calibrated using Emmanuel Bertin's SCAMP package. The message
> is:
>
> WARNING: FITSFixedWarning: 'celfix' made the change 'Unrecognized
> projection code (TPV in CTYPE1)'. [astropy.wcs.wcs]
>
> I previously seamlessly used the astLib package, and both ds9 and
> Gaia/Starlink image browsers recognize the TPV projection. Integration in
> Astropy's wcs module would be greatly appreciated as well.
>
> Thanks for your help,
> Cheers,
> JB
>
>
> _______________________________________________
> 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/20131126/d0e3074a/attachment.html>

From marquett at iap.fr  Tue Nov 26 13:09:49 2013
From: marquett at iap.fr (Jean-Baptiste Marquette)
Date: Tue, 26 Nov 2013 19:09:49 +0100
Subject: [AstroPy] Astropy 0.3 and TPV projection
In-Reply-To: <CA+G92RcUx+LWnLrif8iXdVD2=v2Sqo6j2TffK4JDwW6TMm7GMg@mail.gmail.com>
References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr>
	<CA+G92RcUx+LWnLrif8iXdVD2=v2Sqo6j2TffK4JDwW6TMm7GMg@mail.gmail.com>
Message-ID: <9C37FC34-9B56-4C32-BF3D-6519F8B33C28@iap.fr>

Hi Tim,

> You can use pyast for the moment.
> 

Thanks for this reminder!

Cheers,
JB

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

From embray at stsci.edu  Wed Nov 27 11:27:59 2013
From: embray at stsci.edu (Erik Bray)
Date: Wed, 27 Nov 2013 11:27:59 -0500
Subject: [AstroPy] [ANN] PyFITS 3.2.0 Released (along with 3.1.3 and 3.0.12)
Message-ID: <52961D8F.8090708@stsci.edu>

Hello all,

It is my honor to announce the latest feature release of PyFITS, v3.2.0.  It is 
accompanied by bug fix releases to the v3.1.x and v3.0.x series which include 
fixes backported from v3.2.0.  Thanks to everyone who raised issues and offered 
pull requests to get this done.  As always, you can submit any new issues that 
arise at PyFITS' GitHub [1], or through the Astropy project [2], or to 
help at stsci.edu.

It is worth noting also that this release coincides with Astropy v0.3 in that 
this version of PyFITS is essentially identical to the astropy.io.fits package 
in that release.  From now on we will try to keep PyFITS releases synchronized 
with Astropy releases so as to minimize differences between the two.

The PyFITS official website 
(http://www.stsci.edu/institute/software_hardware/pyfits/Download) provides 
installation instructions and lists downloads for all current versions.


Highlights of 3.2.0
===================

- PyFITS now supports the latest version (2.3) of the Tiled Image Convention
   for compressed FITS images.  It will be better at keeping pace with this
   standard through better integration with CFITSIO.  A copy of the current
   version of CFITSIO (3.35) is included in the source distribution.
   (System packagers should take note of the README file in cextern/ for linking
   PyFITS with system copies of CFITSIO.)

- Support for the Q column format in BINARY tables.  This is identical to the P
   format (variable length arrays), except that it supports heap sizes greater
   that 4 GB.  In particular, this enables tile compression of larger images.

- Improved support for columns in BINARY tables holding "pseudo-unsigned"
   integers--that is, signed integers that are rescaled to unsigned integers
   using the appropriate TSCALn value.  As with uint support in images, it is
   necessary, for now, to open a file with the `uint=True` argument in order to
   enable support for this convention (thanks to Benjamin Weaver for contributing
   the lion's share of work on this).


Removed deprecated interfaces
=============================

As warned in the previous release, some interfaces that have been marked 
"deprecated" since the v3.0.0 release have been removed in order to reduce 
maintenance overhead.  Most of these are are rarely used directly, though the 
most common one would be Header.has_key.  Please use the `'key' in header` 
syntax to check presence of keywords in FITS headers, as this usage has been 
supported since at least v2.3.  For the complete list, please see the changelog [3].


Announcing *pending* end of support for Python 2.5
==================================================

The PyFITS v3.3.0 release (not the current v3.2.0) will be the last to support 
Python 2.5.  PyFITS v3.4 and above will require Python 2.6 or greater.  It's 
doubtful that there will even be many stand-alone PyFITS releases beyond that, 
as most new development will ship to Astropy.


Announcing *pending* end of support for PyFITS v3.0.x
=====================================================

After the next PyFITS feature release (v3.3.0) no new bug fix releases will be 
made for the PyFITS 3.0.x series.  Exceptions may be made on a case by case 
basis if there is some critical operational need, but the download statistics 
suggest that there will not be much demand.


[1] https://github.com/spacetelescope/PyFITS
[2] http://www.astropy.org/help.html
[3] http://pythonhosted.org/pyfits/appendix/changelog.html


From erik.tollerud at gmail.com  Wed Nov 27 14:12:53 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 27 Nov 2013 14:12:53 -0500
Subject: [AstroPy] New astropy web site
Message-ID: <CAARXUwUYUgVyMFyKvR1Roe31SWdaUMUq22-ASsLvLXtCVUMASQ@mail.gmail.com>

For those who haven't been paying close attention, I wanted to mention
this: there is a new http://www.astropy.org web site!  We of course
welcome any feedback, but we hope it's a big improvement over the old
one.

I'd like to offer a special thanks to Kaylea Nelson
(http://kayleanelson.com/) for actually designing the site!


-- 
Erik T


From maik.riechert at arcor.de  Fri Nov 29 06:06:02 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Fri, 29 Nov 2013 12:06:02 +0100
Subject: [AstroPy] Unnecessary warning "cdelt will be ignored since cd is
	present"
Message-ID: <5298751A.4060009@arcor.de>

Hi,

I use astropy 0.3 and get the warning "cdelt will be ignored since cd is 
present" when I call wcs.printwcs() even though the FITS headers don't 
contain cdelt:

SIMPLE  =                    T / Standard FITS file
BITPIX  =                    8 / ASCII or bytes array
NAXIS   =                    0 / Minimal header
EXTEND  =                    T / There may be FITS ext
WCSAXES =                    2 / no comment
CTYPE1  = 'RA---TAN' / TAN (gnomic) projection
CTYPE2  = 'DEC--TAN' / TAN (gnomic) projection
EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
LONPOLE =                180.0 / no comment
LATPOLE =                  0.0 / no comment
CRVAL1  =        282.428453019 / RA  of reference point
CRVAL2  =        36.6483063538 / DEC of reference point
CRPIX1  =        1938.20328776 / X reference pixel
CRPIX2  =        1163.46704102 / Y reference pixel
CUNIT1  = 'deg     ' / X pixel scale units
CUNIT2  = 'deg     ' / Y pixel scale units
CD1_1   =     -0.0164029166118 / Transformation matrix
CD1_2   =     0.00410727100937 / no comment
CD2_1   =    -0.00410727100937 / no comment
CD2_2   =     -0.0164029166118 / no comment
IMAGEW  =                 4256 / Image width,  in pixels.
IMAGEH  =                 2832 / Image height, in pixels.
HISTORY...
DATE    = '2013-11-29T11:55:49' / Date this file was created.
COMMENT...
END

I know printwcs() is declared as an internal function and I don't get 
the message when I don't call printwcs(), but still, I thought I let you 
know, just in case.

Cheers
Maik


From mdroe at stsci.edu  Fri Nov 29 13:01:27 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Fri, 29 Nov 2013 13:01:27 -0500
Subject: [AstroPy] Unnecessary warning "cdelt will be ignored since cd
 is present"
In-Reply-To: <5298751A.4060009@arcor.de>
References: <5298751A.4060009@arcor.de>
Message-ID: <5298D677.8030507@stsci.edu>

Thanks for the report.  Indeed, it's a little too zealous in the warning.

There is a proposed fix here:

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

Mike

On 11/29/2013 06:06 AM, Maik Riechert wrote:
> Hi,
>
> I use astropy 0.3 and get the warning "cdelt will be ignored since cd is
> present" when I call wcs.printwcs() even though the FITS headers don't
> contain cdelt:
>
> SIMPLE  =                    T / Standard FITS file
> BITPIX  =                    8 / ASCII or bytes array
> NAXIS   =                    0 / Minimal header
> EXTEND  =                    T / There may be FITS ext
> WCSAXES =                    2 / no comment
> CTYPE1  = 'RA---TAN' / TAN (gnomic) projection
> CTYPE2  = 'DEC--TAN' / TAN (gnomic) projection
> EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
> LONPOLE =                180.0 / no comment
> LATPOLE =                  0.0 / no comment
> CRVAL1  =        282.428453019 / RA  of reference point
> CRVAL2  =        36.6483063538 / DEC of reference point
> CRPIX1  =        1938.20328776 / X reference pixel
> CRPIX2  =        1163.46704102 / Y reference pixel
> CUNIT1  = 'deg     ' / X pixel scale units
> CUNIT2  = 'deg     ' / Y pixel scale units
> CD1_1   =     -0.0164029166118 / Transformation matrix
> CD1_2   =     0.00410727100937 / no comment
> CD2_1   =    -0.00410727100937 / no comment
> CD2_2   =     -0.0164029166118 / no comment
> IMAGEW  =                 4256 / Image width,  in pixels.
> IMAGEH  =                 2832 / Image height, in pixels.
> HISTORY...
> DATE    = '2013-11-29T11:55:49' / Date this file was created.
> COMMENT...
> END
>
> I know printwcs() is declared as an internal function and I don't get
> the message when I don't call printwcs(), but still, I thought I let you
> know, just in case.
>
> Cheers
> Maik
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


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

http://www.droettboom.com