From crpennypacker at lbl.gov  Fri Oct  2 18:43:58 2015
From: crpennypacker at lbl.gov (Carl Pennypacker)
Date: Fri, 2 Oct 2015 12:43:58 -1000
Subject: [AstroPy] Python powered GUI for secondary school education image
 processing and possible porting to Tablets and Smart Phones
Message-ID: <560F08AE.1090809@lbl.gov>

Dear Astropy Community,

I seek your help on the following: I am interested in a Python based
GUI with powerful underlying astronomy/.fts image handling
and analysis features. Over the past decades, our
Hands-On Universe program (see http://handsonuniverse.org/) has evolved 
through several such systems,
including initially a C++ version, an IDL based system, and finally to a 
system
based on NIH image (Image J now), called Salsa J (available from 
euhou.net).  We seek
features   such as aperture photometry, image
subtraction, image division/multiplication, flat fielding, adjusting
contrast in the display., surface plot, plotting of profiles (graph) 
across a
user-marked line, etc.  All these features work from pull down menus
while one's image is displayed. It is a huge amount of fun,
and students learn a lot.   This Salsa J resembles DS-9, which is good, but
we like Salsa J better (I apologize to folks at SAO).

Do you all know of anyone who has developed a nice GUI sitting on top of
AstroPy features, like I describe above with such features as are in our 
current Salsa J
system?  This seems like a very logical evolution of our software.

Finally, has anyone tried to compile such a python GUI or other
python routines onto Androids or Apple
tablets?  One the web, I see a number of systems that claim they
can take Python code and make it work on smart phones, without
having to learn Android or Iphone language..

If we had such a image processing system for tablets, we could reach 
many more
teachers with our educational system and community.

        Many Thanks,

       Carl Pennypacker
      UC Berkeley


From joshuapaultan at gmail.com  Thu Oct  1 16:30:25 2015
From: joshuapaultan at gmail.com (Josh Tan)
Date: Thu, 1 Oct 2015 17:30:25 -0300
Subject: [AstroPy] Query about Table.add_row() method for masked tables
Message-ID: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>

Hello,

I have been trying to use astropy tables and have found that you cannot add a `None` row with a mask. While I can go and add np.zeroes by hand, it?s a bit annoying to me that it behaves this way. (See examples below.)

Josh

In [69]:

t = Table([[1], [2]], names=('a', 'b'), masked=True)
t.add_row(None, mask=True)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-69-4b6f404ff930> in <module>()
      1 t = Table([[1], [2]], names=('a', 'b'), masked=True)
----> 2 t.add_row(None, mask=True)

/Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc in add_row(self, vals, mask)
   1623              3   6   9
   1624         """
-> 1625         self.insert_row(len(self), vals, mask)
   1626 
   1627     def insert_row(self, index, vals=None, mask=None):

/Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc in insert_row(self, index, vals, mask)
   1674             # that have entries for each table column.
   1675             if mask is not None and not _is_mapping(mask):
-> 1676                 raise TypeError("Mismatch between type of vals and mask")
   1677 
   1678             # Now check that the mask is specified for the same keys as the

TypeError: Mismatch between type of vals and mask

In [74]:

t = Table([[1], [2]], names=('a', 'b'), masked=True)
t.add_row(None, mask=len(t.colnames)*[True])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-74-ae9160dbf05d> in <module>()
      1 t = Table([[1], [2]], names=('a', 'b'), masked=True)
----> 2 t.add_row(None, mask=len(t.colnames)*[True])

/Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc in add_row(self, vals, mask)
   1623              3   6   9
   1624         """
-> 1625         self.insert_row(len(self), vals, mask)
   1626 
   1627     def insert_row(self, index, vals=None, mask=None):

/Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc in insert_row(self, index, vals, mask)
   1674             # that have entries for each table column.
   1675             if mask is not None and not _is_mapping(mask):
-> 1676                 raise TypeError("Mismatch between type of vals and mask")
   1677 
   1678             # Now check that the mask is specified for the same keys as the

TypeError: Mismatch between type of vals and mask

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

From erik.tollerud at gmail.com  Fri Oct  2 00:43:48 2015
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Fri, 2 Oct 2015 00:43:48 -0400
Subject: [AstroPy] deprecation warning from ipython
In-Reply-To: <CACcRS=e=Q3k3s1uzD65HWq0X=rrFwu=L2XBOpB5iooCCm_q4sQ@mail.gmail.com>
References: <CACcRS=e=Q3k3s1uzD65HWq0X=rrFwu=L2XBOpB5iooCCm_q4sQ@mail.gmail.com>
Message-ID: <CAARXUwURFKSFeasAp+XcT7jHuhYENkYYj2eyrgY-wYrQ-R5VAA@mail.gmail.com>

Hello Jonathan,

It looks to me like #4078 (https://github.com/astropy/astropy/pull/4078)
was supposed to fix this, and its already merged so you shouldn't be seeing
the error if you're got that change in.  Were you seeing this on the
development branch of astropy, or a release (which wouldn't have this yet)?


On Tue, Sep 15, 2015 at 1:33 PM, Jonathan Slavin <jslavin at cfa.harvard.edu>
wrote:

> Hi all,
>
> I was curious why I've started getting a deprecation warning from ipython
> when I import astropy:
>
> /export/slavin/python/anaconda/lib/python2.7/site-packages/IPython/kernel/__init__.py:13:
> ShimWarning: The `IPython.kernel` package has been deprecated. You should
> import from ipykernel or jupyter_client instead.
>   "You should import from ipykernel or jupyter_client instead.",
> ShimWarning)
>
> ?It looks like it's related to the "Big Split" between ipython and
> jupyter.  Are there plans to change the relevant part(s) of the code?  Or
> is it an ipython issue?
>
> Regards,
> Jon?
>
> --
> ________________________________________________________
> Jonathan D. Slavin                 Harvard-Smithsonian CfA
> jslavin at cfa.harvard.edu       60 Garden Street, MS 83
> phone: (617) 496-7981       Cambridge, MA 02138-1516
> cell: (781) 363-0035             USA
> ________________________________________________________
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Erik T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151002/386bf04d/attachment.html>

From mcraig at mnstate.edu  Fri Oct  2 00:48:56 2015
From: mcraig at mnstate.edu (Matthew Craig)
Date: Fri, 2 Oct 2015 04:48:56 +0000
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
In-Reply-To: <560F08AE.1090809@lbl.gov>
References: <560F08AE.1090809@lbl.gov>
Message-ID: <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>

Hi Carl,

The really short answer is that as far as I know, no, if you want something right now that has the same capabilities as Salsa J (I?ve used AstroImageJ with the undergrads I work with, but think in the past I looked at SalsaJ for occasional work with a high school).

There are a couple things going on now that have some potential for this kind of use:

a. The package Toyz (http://fred3m.github.io/toyz/overview.html, and also see https://github.com/fred3m/toyz) was presented at the Python in Astronomy conference in 2015. I believe the model is that data is stored on a server, accessed via a browser, not sure how involved the setup is. I?d contact the author, Fred Moolekamp, for more details (actually, seeing his github page screenshots reminded me I should contact him too :). Contact information is on his github page, https://github.com/fred3m My memory from the conference is that he has used Toyz for some outreach.

b.  [Disclaimer: shameless self-promotion] I?ve developed an ipython/jupyter-based notebook for reducing data (not what you are looking for, I think), and am starting work this semester on a set of notebook-based tools for doing photometry. You can get an idea of what the current reducer interface looks like at http://reducer.readthedocs.org/en/latest/quickstart.html#quickstart ?it is *not* at all a replacement for  salsa j  at the moment, but the photometry notebook would closer be closer to that.

I think the future of easily usable python-based astro software will be:

+ astropy-based on the backend, or backed by python code that is tested and maintained at a similar level. Two reasons:
- it is tested and maintained
- if everyone doing this kind of outreach that touches much larger numbers is using a small set of well-validated tools then they can be doing useful science as well as learning (which is not to imply that useful science cannot be done with SalsaJ and kin, just that if you can use the tools the pros use, why wouldn?t you?)

+ browser-based for the user, with  ipython/jupyter running on a server hosted in the cloud (where the data is too), serving up notebook instances and saving user results. Several reasons:
- The jupyter/ipython infrastructure infrastructure is being adopted in a wide variety of industries ? the most interesting new widget work I saw at SciPy was by a developer who works at Bloomberg making clickable interfaces for traders. That scope of buy-in should ensure a long lifetime for the project.
- The jupyterhub infrastructure for doing cloud hosting is also developing rapidly.
- The anaconda python distribution has made installation much easier, but still hard for a novice.
- Notebooks are essentially editable apps, so that with a little teacher training and the right notebook design you could have a notebook that offers all of the menus and options that Salsa J has, but with the ability for teachers to remove components/complexity if they don?t need it.

A browser-based solution has the additional advantage that tablets/phones already have those, though the touch interface is still a work in progress.

I?m biased, but I also think easy-to-use tools will be developed first at the undergraduate level or lower, where there is a premium on minimizing the spin-up time for a new learner/researcher.  Eventually, it will trickle-up to larger institutions if the backend is something like astropy, and the interface makes doing what they need to do easier.

Let me know if you are interested in talking more ? I?m committed to building out a more complete set of undergrad-accessible tools in order to get more done with the undergrads at my university (limited, as always, by time and resources) but it would great to explore whether we might have some overlap.

Matt Craig

schedule:  http://physics.mnstate.edu/craig
??

Professor
Department of Physics and Astronomy
Minnesota State University Moorhead
1104 7th Ave S, Moorhead MN 56563

phone: (218) 477-2439
fax: (218) 477-2290

On Oct 2, 2015, at 5:43 PM, Carl Pennypacker <crpennypacker at lbl.gov<mailto:crpennypacker at lbl.gov>> wrote:

Dear Astropy Community,

I seek your help on the following: I am interested in a Python based
GUI with powerful underlying astronomy/.fts image handling
and analysis features. Over the past decades, our
Hands-On Universe program (see http://handsonuniverse.org/) has evolved through several such systems,
including initially a C++ version, an IDL based system, and finally to a system
based on NIH image (Image J now), called Salsa J (available from euhou.net<http://euhou.net>).  We seek
features   such as aperture photometry, image
subtraction, image division/multiplication, flat fielding, adjusting
contrast in the display., surface plot, plotting of profiles (graph) across a
user-marked line, etc.  All these features work from pull down menus
while one's image is displayed. It is a huge amount of fun,
and students learn a lot.   This Salsa J resembles DS-9, which is good, but
we like Salsa J better (I apologize to folks at SAO).

Do you all know of anyone who has developed a nice GUI sitting on top of
AstroPy features, like I describe above with such features as are in our current Salsa J
system?  This seems like a very logical evolution of our software.

Finally, has anyone tried to compile such a python GUI or other
python routines onto Androids or Apple
tablets?  One the web, I see a number of systems that claim they
can take Python code and make it work on smart phones, without
having to learn Android or Iphone language..

If we had such a image processing system for tablets, we could reach many more
teachers with our educational system and community.

      Many Thanks,

     Carl Pennypacker
    UC Berkeley
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

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

From rborges at hush.com  Fri Oct  2 06:18:49 2015
From: rborges at hush.com (rborges at hush.com)
Date: Fri, 2 Oct 2015 12:18:49 +0200
Subject: [AstroPy] Query about Table.add_row() method for masked tables
In-Reply-To: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>
References: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>
Message-ID: <dc4cd8c68aa95a774a375a377efc96ff@smtp.hushmail.com>

Hi Josh!


On Thu, Oct 01, 2015 at 05:30:25PM -0300, Josh Tan wrote:
>    Hello,
> 
>    I have been trying to use astropy tables and have found that you cannot
>    add a `None` row with a mask. While I can go and add np.zeroes by hand,
>    it?s a bit annoying to me that it behaves this way. (See examples
>    below.)
> 
>    Josh
> 
>    In [69]:
> t = Table([[1], [2]], names=('a', 'b'), masked=True)
> t.add_row(None, mask=True)
[...]
> TypeError: Mismatch between type of vals and mask
> 
>    In [74]:
> t = Table([[1], [2]], names=('a', 'b'), masked=True)
> t.add_row(None, mask=len(t.colnames)*[True])
[...]
> TypeError: Mismatch between type of vals and mask

I have reproduced your situation.

I believe your goal is: to find a syntax that allows you to append a row of invalid values, that are masked as "True".

I managed to find a solution, as long as it is not relevant that the values be "None"s.

t.add_row( [ 0 for x in t.columns.keys ( ) ], mask = [ True for x in t.columns.keys ( ) ] )

If you try to use "None"s on the first list comprehension, astropy.table complains about the type.

In case you absolutely require 'None's, or find it easier to remember, you can take a two-step approach:

t.add_row ( None )
t.mask [ -1 ] = [ True for x in t.columns.keys ( ) ]

Final note: I am not experienced with atropy.table, so maybe there is a quicker syntax for getting the number of columns.


Hope this helps,
Renato.



From jslavin at cfa.harvard.edu  Fri Oct  2 08:34:21 2015
From: jslavin at cfa.harvard.edu (Slavin, Jonathan)
Date: Fri, 2 Oct 2015 08:34:21 -0400
Subject: [AstroPy] deprecation warning from ipython
In-Reply-To: <CAARXUwURFKSFeasAp+XcT7jHuhYENkYYj2eyrgY-wYrQ-R5VAA@mail.gmail.com>
References: <CACcRS=e=Q3k3s1uzD65HWq0X=rrFwu=L2XBOpB5iooCCm_q4sQ@mail.gmail.com>
 <CAARXUwURFKSFeasAp+XcT7jHuhYENkYYj2eyrgY-wYrQ-R5VAA@mail.gmail.com>
Message-ID: <CACcRS=dZt4bxL8PZ67_fVtO08SYiDVjKUyxqh5CCkr4-rNGiYw@mail.gmail.com>

Hi Erik,

My astropy version is 1.0.4 which I got via anaconda.  It appears this is
the latest released version of astropy.  I'm not sure which version that
pull request was merged into.

Regards,
Jon

On Fri, Oct 2, 2015 at 12:43 AM, Erik Tollerud <erik.tollerud at gmail.com>
wrote:

> Hello Jonathan,
>
> It looks to me like #4078 (https://github.com/astropy/astropy/pull/4078)
> was supposed to fix this, and its already merged so you shouldn't be seeing
> the error if you're got that change in.  Were you seeing this on the
> development branch of astropy, or a release (which wouldn't have this yet)?
>
>
> On Tue, Sep 15, 2015 at 1:33 PM, Jonathan Slavin <jslavin at cfa.harvard.edu>
> wrote:
>
>> Hi all,
>>
>> I was curious why I've started getting a deprecation warning from ipython
>> when I import astropy:
>>
>> /export/slavin/python/anaconda/lib/python2.7/site-packages/IPython/kernel/__init__.py:13:
>> ShimWarning: The `IPython.kernel` package has been deprecated. You should
>> import from ipykernel or jupyter_client instead.
>>   "You should import from ipykernel or jupyter_client instead.",
>> ShimWarning)
>>
>> ?It looks like it's related to the "Big Split" between ipython and
>> jupyter.  Are there plans to change the relevant part(s) of the code?  Or
>> is it an ipython issue?
>>
>> Regards,
>> Jon?
>>
>> --
>> ________________________________________________________
>> Jonathan D. Slavin                 Harvard-Smithsonian CfA
>> jslavin at cfa.harvard.edu       60 Garden Street, MS 83
>> phone: (617) 496-7981       Cambridge, MA 02138-1516
>> cell: (781) 363-0035             USA
>> ________________________________________________________
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
> --
> Erik T
>



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

From lbradley at stsci.edu  Fri Oct  2 08:57:25 2015
From: lbradley at stsci.edu (Larry Bradley)
Date: Fri, 2 Oct 2015 08:57:25 -0400
Subject: [AstroPy] deprecation warning from ipython
In-Reply-To: <CACcRS=dZt4bxL8PZ67_fVtO08SYiDVjKUyxqh5CCkr4-rNGiYw@mail.gmail.com>
References: <CACcRS=e=Q3k3s1uzD65HWq0X=rrFwu=L2XBOpB5iooCCm_q4sQ@mail.gmail.com>
 <CAARXUwURFKSFeasAp+XcT7jHuhYENkYYj2eyrgY-wYrQ-R5VAA@mail.gmail.com>
 <CACcRS=dZt4bxL8PZ67_fVtO08SYiDVjKUyxqh5CCkr4-rNGiYw@mail.gmail.com>
Message-ID: <CAFfmSa0QASBEK1XXv0a5qFBDxZfQKDhHPKsPE_0VhXYj2+Emjg@mail.gmail.com>

I sent email this a few weeks ago, but it must not have gone through.
Trying again....
--------

Jonathan,

Yes, this deprecation warning occurs with iPython 4.0/Jupyter 1.0, the
first releases after the Big Split.  I fixed this in astropy master a
while back [1].  It will appear in the astropy 1.0.5 release.

Thanks,
Larry


On Fri, Oct 2, 2015 at 8:34 AM, Slavin, Jonathan
<jslavin at cfa.harvard.edu> wrote:
> Hi Erik,
>
> My astropy version is 1.0.4 which I got via anaconda.  It appears this is
> the latest released version of astropy.  I'm not sure which version that
> pull request was merged into.
>
> Regards,
> Jon
>
> On Fri, Oct 2, 2015 at 12:43 AM, Erik Tollerud <erik.tollerud at gmail.com>
> wrote:
>>
>> Hello Jonathan,
>>
>> It looks to me like #4078 (https://github.com/astropy/astropy/pull/4078)
>> was supposed to fix this, and its already merged so you shouldn't be seeing
>> the error if you're got that change in.  Were you seeing this on the
>> development branch of astropy, or a release (which wouldn't have this yet)?
>>
>> On Tue, Sep 15, 2015 at 1:33 PM, Jonathan Slavin <jslavin at cfa.harvard.edu>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I was curious why I've started getting a deprecation warning from ipython
>>> when I import astropy:
>>>
>>>
>>> /export/slavin/python/anaconda/lib/python2.7/site-packages/IPython/kernel/__init__.py:13:
>>> ShimWarning: The `IPython.kernel` package has been deprecated. You should
>>> import from ipykernel or jupyter_client instead.
>>>   "You should import from ipykernel or jupyter_client instead.",
>>> ShimWarning)
>>>
>>> It looks like it's related to the "Big Split" between ipython and
>>> jupyter.  Are there plans to change the relevant part(s) of the code?  Or is
>>> it an ipython issue?
>>>
>>> Regards,
>>> Jon
>>>
>>> --
>>> ________________________________________________________
>>> Jonathan D. Slavin                 Harvard-Smithsonian CfA
>>> jslavin at cfa.harvard.edu       60 Garden Street, MS 83
>>> phone: (617) 496-7981       Cambridge, MA 02138-1516
>>> cell: (781) 363-0035             USA
>>> ________________________________________________________
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>>
>> --
>> Erik T
>
>
>
>
> --
> ________________________________________________________
> Jonathan D. Slavin                 Harvard-Smithsonian CfA
> jslavin at cfa.harvard.edu       60 Garden Street, MS 83
> phone: (617) 496-7981       Cambridge, MA 02138-1516
> cell: (781) 363-0035             USA
> ________________________________________________________
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From embray at stsci.edu  Fri Oct  2 11:48:39 2015
From: embray at stsci.edu (Erik Bray)
Date: Fri, 2 Oct 2015 11:48:39 -0400
Subject: [AstroPy] Query about Table.add_row() method for masked tables
In-Reply-To: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>
References: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>
Message-ID: <560EA757.4000806@stsci.edu>

On 10/1/2015 4:30 PM, Josh Tan wrote:
> Hello,
>
> I have been trying to use astropy tables and have found that you cannot add a
> `None` row with a mask. While I can go and add np.zeroes by hand, it?s a bit
> annoying to me that it behaves this way. (See examples below.)

Hi Josh,

There definitely seems to be some conflict between add_row(None) and 
add_row(..., mask=...).  It seems to be that the allowed formats for the mask 
value aren't really compatible with the add_row(None) syntax.  I think that 
could be fixed--the way you were trying to do it, add_row(None, mask=True), 
makes sense to me.

Erik

> In [69]:
>
> t  =Table([[1], [2]],names=('a','b'),masked=True)
>
> t.add_row(None,mask=True)
>
> ---------------------------------------------------------------------------
> TypeError                                  Traceback (most recent call last)
> <ipython-input-69-4b6f404ff930>  in<module>() 1 t=  Table([[1],  [2]],  names=('a',  'b'),  masked=True)
> ----> 2t.add_row(None,  mask=True)
>
> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc  inadd_row(self, vals, mask) 1623 3 6 9
> 1624          """
> -> 1625self.insert_row(len(self),  vals,  mask)
> 1626
> 1627      def  insert_row(self,  index,  vals=None,  mask=None):
>
> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc  ininsert_row(self, index, vals, mask) 1674 # that have entries for each table column.
> 1675              if  maskis  not  Noneand  not  _is_mapping(mask):
> -> 1676raise TypeError("Mismatch between type of vals and mask")
> 1677
> 1678              # Now check that the mask is specified for the same keys as the
>
> TypeError: Mismatch between type of vals and mask
>
>
> In [74]:
>
> t  =Table([[1], [2]],names=('a','b'),masked=True)
>
> t.add_row(None,mask=len(t.colnames)*[True])
>
> ---------------------------------------------------------------------------
> TypeError                                  Traceback (most recent call last)
> <ipython-input-74-ae9160dbf05d>  in<module>() 1 t=  Table([[1],  [2]],  names=('a',  'b'),  masked=True)
> ----> 2t.add_row(None,  mask=len(t.colnames)*[True])
>
> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc  inadd_row(self, vals, mask) 1623 3 6 9
> 1624          """
> -> 1625self.insert_row(len(self),  vals,  mask)
> 1626
> 1627      def  insert_row(self,  index,  vals=None,  mask=None):
>
> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc  ininsert_row(self, index, vals, mask) 1674 # that have entries for each table column.
> 1675              if  maskis  not  Noneand  not  _is_mapping(mask):
> -> 1676raise TypeError("Mismatch between type of vals and mask")
> 1677
> 1678              # Now check that the mask is specified for the same keys as the
>
> TypeError: Mismatch between type of vals and mask
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



From crpennypacker at lbl.gov  Sat Oct  3 14:55:26 2015
From: crpennypacker at lbl.gov (Carl Pennypacker)
Date: Sat, 3 Oct 2015 08:55:26 -1000
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
In-Reply-To: <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
References: <560F08AE.1090809@lbl.gov>
 <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
Message-ID: <5610249E.6050000@lbl.gov>

Hello Matt,

Your comments are very enlightening and I am encouraged by them!
(I was one of the Salsa J testers, btw, and my friends in Paris developed
it, based on our HOU C++ software).

I like the reduce package you developed!

I strongly support your ideas concerning using pro-quality engines like  
astropy,
but gettng an easier interface for my students.  We had tried this with 
IDL, but
ran out of money and scalability issues kind of got us..

My feeling now is that if we have a big server role, we still need 
embedded in a potential app for
tablets much of the arithmetic for image display. I did a calculation based
on current server gflop charges, and even something like each HOU
student changing image contrasts 20 times a day for say four weeks, would
cost huge amounts of server dollars.

Can we talk on the phone, say next week?

    Many Thanks,

      Carl

On 10/1/15 6:48 PM, Matthew Craig wrote:
> Hi Carl,
>
> The really short answer is that as far as I know, no, if you 
> want something right now that has the same capabilities as Salsa J 
> (I?ve used AstroImageJ with the undergrads I work with, but think 
> in the past I looked at SalsaJ for occasional work with a high school).
>
> There are a couple things going on now that have some potential for 
> this kind of use:
>
> a. The package Toyz (http://fred3m.github.io/toyz/overview.html, and 
> also see https://github.com/fred3m/toyz) was presented at the Python 
> in Astronomy conference in 2015. I believe the model is that data is 
> stored on a server, accessed via a browser, not sure how involved the 
> setup is. I?d contact the author, Fred Moolekamp, for more details 
> (actually, seeing his github page screenshots reminded me I should 
> contact him too :). Contact information is on his github page, 
> https://github.com/fred3m My memory from the conference is that he has 
> used Toyz for some outreach.
>
> b.  [Disclaimer: shameless self-promotion] I?ve developed an 
> ipython/jupyter-based notebook for reducing data (not what you are 
> looking for, I think), and am starting work this semester on a set 
> of notebook-based tools for doing photometry. You can get an idea of 
> what the current reducer interface looks like at 
> http://reducer.readthedocs.org/en/latest/quickstart.html#quickstart ?it is 
> *not* at all a replacement for  salsa j  at the moment, but the 
> photometry notebook would closer be closer to that.
>
> I think the future of easily usable python-based astro software will be:
>
> + astropy-based on the backend, or backed by python code that is 
> tested and maintained at a similar level. Two reasons:
> - it is tested and maintained
> - if everyone doing this kind of outreach that touches much larger 
> numbers is using a small set of well-validated tools then they can be 
> doing useful science as well as learning (which is not to imply that 
> useful science cannot be done with SalsaJ and kin, just that if you 
> can use the tools the pros use, why wouldn?t you?)
>
> + browser-based for the user, with  ipython/jupyter running on a 
> server hosted in the cloud (where the data is too), serving up 
> notebook instances and saving user results. Several reasons:
> - The jupyter/ipython infrastructure infrastructure is being adopted 
> in a wide variety of industries ? the most interesting new widget work 
> I saw at SciPy was by a developer who works at Bloomberg making 
> clickable interfaces for traders. That scope of buy-in should ensure a 
> long lifetime for the project.
> - The jupyterhub infrastructure for doing cloud hosting is also 
> developing rapidly.
> - The anaconda python distribution has made installation much easier, 
> but still hard for a novice.
> - Notebooks are essentially editable apps, so that with a little 
> teacher training and the right notebook design you could have 
> a notebook that offers all of the menus and options that Salsa J has, 
> but with the ability for teachers to remove components/complexity if 
> they don?t need it.
>
> A browser-based solution has the additional advantage that 
> tablets/phones already have those, though the touch interface is still 
> a work in progress.
>
> I?m biased, but I also think easy-to-use tools will be developed first 
> at the undergraduate level or lower, where there is a premium on 
> minimizing the spin-up time for a new learner/researcher.  Eventually, 
> it will trickle-up to larger institutions if the backend is something 
> like astropy, and the interface makes doing what they need to do easier.
>
> Let me know if you are interested in talking more ? I?m committed 
> to building out a more complete set of undergrad-accessible tools in 
> order to get more done with the undergrads at my university (limited, 
> as always, by time and resources) but it would great to explore 
> whether we might have some overlap.
>
> Matt Craig
>
> schedule: http://physics.mnstate.edu/craig
> ??
>
> Professor
> Department of Physics and Astronomy
> Minnesota State University Moorhead
> 1104 7th Ave S, Moorhead MN 56563
>
> phone: (218) 477-2439
> fax: (218) 477-2290
>
>> On Oct 2, 2015, at 5:43 PM, Carl Pennypacker <crpennypacker at lbl.gov 
>> <mailto:crpennypacker at lbl.gov>> wrote:
>>
>> Dear Astropy Community,
>>
>> I seek your help on the following: I am interested in a Python based
>> GUI with powerful underlying astronomy/.fts image handling
>> and analysis features. Over the past decades, our
>> Hands-On Universe program (see http://handsonuniverse.org/) has 
>> evolved through several such systems,
>> including initially a C++ version, an IDL based system, and finally 
>> to a system
>> based on NIH image (Image J now), called Salsa J (available from 
>> euhou.net <http://euhou.net>).  We seek
>> features   such as aperture photometry, image
>> subtraction, image division/multiplication, flat fielding, adjusting
>> contrast in the display., surface plot, plotting of profiles (graph) 
>> across a
>> user-marked line, etc.  All these features work from pull down menus
>> while one's image is displayed. It is a huge amount of fun,
>> and students learn a lot.   This Salsa J resembles DS-9, which is 
>> good, but
>> we like Salsa J better (I apologize to folks at SAO).
>>
>> Do you all know of anyone who has developed a nice GUI sitting on top of
>> AstroPy features, like I describe above with such features as are in 
>> our current Salsa J
>> system?  This seems like a very logical evolution of our software.
>>
>> Finally, has anyone tried to compile such a python GUI or other
>> python routines onto Androids or Apple
>> tablets?  One the web, I see a number of systems that claim they
>> can take Python code and make it work on smart phones, without
>> having to learn Android or Iphone language..
>>
>> If we had such a image processing system for tablets, we could reach 
>> many more
>> teachers with our educational system and community.
>>
>>       Many Thanks,
>>
>>      Carl Pennypacker
>>     UC Berkeley
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

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

From fred3public at gmail.com  Fri Oct  2 14:09:47 2015
From: fred3public at gmail.com (Fred Moolekamp)
Date: Fri, 2 Oct 2015 14:09:47 -0400
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
In-Reply-To: <5610249E.6050000@lbl.gov>
References: <560F08AE.1090809@lbl.gov>
 <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
 <5610249E.6050000@lbl.gov>
Message-ID: <CAGdJfBX9rXZb2CrxLTL8V09N262T0duSMJWCNCzYsE4EF+J6=A@mail.gmail.com>

Hi Carl,
In the long run Toyz and Astro Toyz are designed to do exactly what you are
requesting. Currently you are only able to view and blink images (along
with surface plots and adjustment of the bias and contrast) and create
interactive plots from a variety of data sources but as long as I find a
post doc or teaching position I plan to continue to work on Toyz this
summer and next year so that it will become a GUI for astropy. Some of the
things planned for the immediate future include the ability to detect
sources (using SEP or photutils), perform aperture and PSF photometry (I
have updates to photutils to fit groups of stars but haven't pushed my
changes yet), display the catalogs on the images, perform coordinate
transformations, match source catalogs to catalogs in Vizier and get an
astrometric solution (using astroquery and astrometry.net). Further in the
future I also plan to include a separate webpage that can be used to modify
the data contained in a separate session, which runs in a browser much like
iPython but with an interface more like Spyder or R Studio. A lot of the
above upgrades exist in

To install Toyz and Astro Toyz just run

pip install astrotoyz[all]

This will install Toyz, Astro Toyz, and all of their dependent packages not
currently installed on your system (I think it's just numpy, scipy,
astropy, pandas, pillow, tornado, passlib, matplotlib, and sqlalchemy, many
of which you probably have installed already). I highly recommend doing
this from a virtualenv as some people have experienced conflicts with other
modules on their systems.

In addition to the document links proved by Matt you can also check out a
demo <https://www.youtube.com/watch?v=aY-11VcqHGs> and a few tutorials
<https://www.youtube.com/playlist?list=PLNzyj3J441TGvlWm1_NGx-APgPSaZn0hp>
to help you get started. In the future I plan to improve these tutorials
and make more to help walk users through many of Toyz's features.

Best,
-Fred

On Sat, Oct 3, 2015 at 2:55 PM, Carl Pennypacker <crpennypacker at lbl.gov>
wrote:

> Hello Matt,
>
> Your comments are very enlightening and I am encouraged by them!
> (I was one of the Salsa J testers, btw, and my friends in Paris developed
> it, based on our HOU C++ software).
>
> I like the reduce package you developed!
>
> I strongly support your ideas concerning using pro-quality engines like
> astropy,
> but gettng an easier interface for my students.  We had tried this with
> IDL, but
> ran out of money and scalability issues kind of got us..
>
> My feeling now is that if we have a big server role, we still need
> embedded in a potential app for
> tablets much of the arithmetic for image display. I did a calculation based
> on current server gflop charges, and even something like each HOU
> student changing image contrasts 20 times a day for say four weeks, would
> cost huge amounts of server dollars.
>
> Can we talk on the phone, say next week?
>
>    Many Thanks,
>
>      Carl
>
>
> On 10/1/15 6:48 PM, Matthew Craig wrote:
>
> Hi Carl,
>
> The really short answer is that as far as I know, no, if you
> want something right now that has the same capabilities as Salsa J (I?ve
> used AstroImageJ with the undergrads I work with, but think in the past I
> looked at SalsaJ for occasional work with a high school).
>
> There are a couple things going on now that have some potential for this
> kind of use:
>
> a. The package Toyz (http://fred3m.github.io/toyz/overview.html, and also
> see https://github.com/fred3m/toyz) was presented at the Python in
> Astronomy conference in 2015. I believe the model is that data is stored on
> a server, accessed via a browser, not sure how involved the setup is. I?d
> contact the author, Fred Moolekamp, for more details (actually, seeing his
> github page screenshots reminded me I should contact him too :).
> Contact information is on his github page,  <https://github.com/fred3m>
> https://github.com/fred3m My memory from the conference is that he has
> used Toyz for some outreach.
>
> b.  [Disclaimer: shameless self-promotion] I?ve developed an
> ipython/jupyter-based notebook for reducing data (not what you are looking
> for, I think), and am starting work this semester on a set
> of notebook-based tools for doing photometry. You can get an idea of
> what the current reducer interface looks like at
> http://reducer.readthedocs.org/en/latest/quickstart.html#quickstart ?it
> is *not* at all a replacement for  salsa j  at the moment, but the
> photometry notebook would closer be closer to that.
>
> I think the future of easily usable python-based astro software will be:
>
> + astropy-based on the backend, or backed by python code that is
> tested and maintained at a similar level. Two reasons:
> - it is tested and maintained
> - if everyone doing this kind of outreach that touches much larger numbers
> is using a small set of well-validated tools then they can be doing useful
> science as well as learning (which is not to imply that useful science
> cannot be done with SalsaJ and kin, just that if you can use the tools the
> pros use, why wouldn?t you?)
>
> + browser-based for the user, with  ipython/jupyter running on a server
> hosted in the cloud (where the data is too), serving up notebook
> instances and saving user results. Several reasons:
> - The jupyter/ipython infrastructure infrastructure is being adopted in a
> wide variety of industries ? the most interesting new widget work I saw at
> SciPy was by a developer who works at Bloomberg making clickable interfaces
> for traders. That scope of buy-in should ensure a long lifetime for the
> project.
> - The jupyterhub infrastructure for doing cloud hosting is also developing
> rapidly.
> - The anaconda python distribution has made installation much easier, but
> still hard for a novice.
> - Notebooks are essentially editable apps, so that with a little teacher
> training and the right notebook design you could have a notebook that
> offers all of the menus and options that Salsa J has, but with the ability
> for teachers to remove components/complexity if they don?t need it.
>
> A browser-based solution has the additional advantage that tablets/phones
> already have those, though the touch interface is still a work in progress.
>
> I?m biased, but I also think easy-to-use tools will be developed first
> at the undergraduate level or lower, where there is a premium on
> minimizing the spin-up time for a new learner/researcher.  Eventually, it
> will trickle-up to larger institutions if the backend is something like
> astropy, and the interface makes doing what they need to do easier.
>
> Let me know if you are interested in talking more ? I?m committed
> to building out a more complete set of undergrad-accessible tools in order
> to get more done with the undergrads at my university (limited, as always,
> by time and resources) but it would great to explore whether we might have
> some overlap.
>
> Matt Craig
>
> schedule:  http://physics.mnstate.edu/craig
> ??
>
> Professor
> Department of Physics and Astronomy
> Minnesota State University Moorhead
> 1104 7th Ave S, Moorhead MN 56563
>
> phone: (218) 477-2439
> fax: (218) 477-2290
>
> On Oct 2, 2015, at 5:43 PM, Carl Pennypacker <crpennypacker at lbl.gov>
> wrote:
>
> Dear Astropy Community,
>
> I seek your help on the following: I am interested in a Python based
> GUI with powerful underlying astronomy/.fts image handling
> and analysis features. Over the past decades, our
> Hands-On Universe program (see http://handsonuniverse.org/) has evolved
> through several such systems,
> including initially a C++ version, an IDL based system, and finally to a
> system
> based on NIH image (Image J now), called Salsa J (available from euhou.net).
> We seek
> features   such as aperture photometry, image
> subtraction, image division/multiplication, flat fielding, adjusting
> contrast in the display., surface plot, plotting of profiles (graph)
> across a
> user-marked line, etc.  All these features work from pull down menus
> while one's image is displayed. It is a huge amount of fun,
> and students learn a lot.   This Salsa J resembles DS-9, which is good, but
> we like Salsa J better (I apologize to folks at SAO).
>
> Do you all know of anyone who has developed a nice GUI sitting on top of
> AstroPy features, like I describe above with such features as are in our
> current Salsa J
> system?  This seems like a very logical evolution of our software.
>
> Finally, has anyone tried to compile such a python GUI or other
> python routines onto Androids or Apple
> tablets?  One the web, I see a number of systems that claim they
> can take Python code and make it work on smart phones, without
> having to learn Android or Iphone language..
>
> If we had such a image processing system for tablets, we could reach many
> more
> teachers with our educational system and community.
>
>       Many Thanks,
>
>      Carl Pennypacker
>     UC Berkeley
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151002/6e6ae480/attachment.html>

From elenc at me.com  Fri Oct  2 18:46:31 2015
From: elenc at me.com (Emil Lenc)
Date: Sat, 03 Oct 2015 08:46:31 +1000
Subject: [AstroPy] Healpy
Message-ID: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>

Hi All,

I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.

Cheers,

Emil.

From npkuin at gmail.com  Fri Oct  2 19:18:09 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Sat, 3 Oct 2015 00:18:09 +0100
Subject: [AstroPy] Healpy
In-Reply-To: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
Message-ID: <CANoQ6N2Rd65rwUxVRpNg_FXWCrUtkDci-x42Df9sme_=gf+Z=Q@mail.gmail.com>

I second that.


On Fri, Oct 2, 2015 at 11:46 PM, Emil Lenc <elenc at me.com> wrote:

> Hi All,
>
> I was wondering if there were any plans to incorporate healpy (the python
> interface to the HEALPIX library) into astropy? I often work between
> HEALPIX and FITS format images and it would be really convenient to have
> these two common formats available within the same package.
>
> Cheers,
>
> Emil.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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/20151003/dc76e489/attachment.html>

From nathan12343 at gmail.com  Fri Oct  2 19:49:05 2015
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Fri, 2 Oct 2015 18:49:05 -0500
Subject: [AstroPy] Healpy
In-Reply-To: <CANoQ6N2Rd65rwUxVRpNg_FXWCrUtkDci-x42Df9sme_=gf+Z=Q@mail.gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <CANoQ6N2Rd65rwUxVRpNg_FXWCrUtkDci-x42Df9sme_=gf+Z=Q@mail.gmail.com>
Message-ID: <CAJXewOnbLPsKpXrjh-71z2GNMJnrS+Zko=57_wxtr-9-7FLS_w@mail.gmail.com>

Healpy, like the healpix library itself is licensed GPLv2, which is
incompatible with astropy's BSD license.

As far as I understand the GPL's linking clause, if astropy imported
healpy, the astropy package would need to be released under a GPLv2
license. Of course that doesn't stop anyone from making a GPL licensed
supplementary package that monkey patches astropy to include features from
healpy, but it can never be part of the main astropy distribution without
relicensing.

The healpix license was chosen a long time ago. I doubt they would have
predicted the dominance of non-copy left free software licenses
today. Given the current state of the scientific Python ecosystem (and
really scientific computing in general), healpix would likely get more
real-world use if it were relicensed. I'm sure that would be a lot of work
and would not only involve getting the appropriate people at NASA on board
but maybe also the original authors of healpix.

On Friday, October 2, 2015, Paul Kuin <npkuin at gmail.com> wrote:

> I second that.
>
>
> On Fri, Oct 2, 2015 at 11:46 PM, Emil Lenc <elenc at me.com
> <javascript:_e(%7B%7D,'cvml','elenc at me.com');>> wrote:
>
>> Hi All,
>>
>> I was wondering if there were any plans to incorporate healpy (the python
>> interface to the HEALPIX library) into astropy? I often work between
>> HEALPIX and FITS format images and it would be really convenient to have
>> these two common formats available within the same package.
>>
>> Cheers,
>>
>> Emil.
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <javascript:_e(%7B%7D,'cvml','AstroPy at scipy.org');>
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
>
> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk
> <javascript:_e(%7B%7D,'cvml','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/20151002/308bb2b3/attachment.html>

From npkuin at gmail.com  Fri Oct  2 19:55:49 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Sat, 3 Oct 2015 00:55:49 +0100
Subject: [AstroPy] Healpy
In-Reply-To: <CAJXewOnbLPsKpXrjh-71z2GNMJnrS+Zko=57_wxtr-9-7FLS_w@mail.gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <CANoQ6N2Rd65rwUxVRpNg_FXWCrUtkDci-x42Df9sme_=gf+Z=Q@mail.gmail.com>
 <CAJXewOnbLPsKpXrjh-71z2GNMJnrS+Zko=57_wxtr-9-7FLS_w@mail.gmail.com>
Message-ID: <CANoQ6N3DUD3JAgxuKA9zrRYpuGYiVwT=etGVwsE_GmyG-oaA1g@mail.gmail.com>

good point. I'll talk to some people.

On Sat, Oct 3, 2015 at 12:49 AM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

> Healpy, like the healpix library itself is licensed GPLv2, which is
> incompatible with astropy's BSD license.
>
> As far as I understand the GPL's linking clause, if astropy imported
> healpy, the astropy package would need to be released under a GPLv2
> license. Of course that doesn't stop anyone from making a GPL licensed
> supplementary package that monkey patches astropy to include features from
> healpy, but it can never be part of the main astropy distribution without
> relicensing.
>
> The healpix license was chosen a long time ago. I doubt they would have
> predicted the dominance of non-copy left free software licenses
> today. Given the current state of the scientific Python ecosystem (and
> really scientific computing in general), healpix would likely get more
> real-world use if it were relicensed. I'm sure that would be a lot of work
> and would not only involve getting the appropriate people at NASA on
> board but maybe also the original authors of healpix.
>
> On Friday, October 2, 2015, Paul Kuin <npkuin at gmail.com> wrote:
>
>> I second that.
>>
>>
>> On Fri, Oct 2, 2015 at 11:46 PM, Emil Lenc <elenc at me.com> wrote:
>>
>>> Hi All,
>>>
>>> I was wondering if there were any plans to incorporate healpy (the
>>> python interface to the HEALPIX library) into astropy? I often work between
>>> HEALPIX and FITS format images and it would be really convenient to have
>>> these two common formats available within the same package.
>>>
>>> Cheers,
>>>
>>> Emil.
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://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.
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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/20151003/fcc103d6/attachment.html>

From mcraig at mnstate.edu  Fri Oct  2 22:43:38 2015
From: mcraig at mnstate.edu (Matthew Craig)
Date: Sat, 3 Oct 2015 02:43:38 +0000
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
In-Reply-To: <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
References: <560F08AE.1090809@lbl.gov>
 <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
Message-ID: <7FA589B3-46EF-450E-92C0-3D220C0040BB@mnstate.edu>

Hi again,

A couple other projects that are python-based but use non-web backends (like I said in my original reply, I?m biased :)) that were mentioned off list but might be of interest to others are:

+ ginga, main contact is Eric Jeschke, screenshots at http://ejeschke.github.io/ginga/? ginger is a QT-based toolkit that also comes with a basic image browser, though that basic browser is intended as a demonstration of capabilities.

+ imexam, main contact Megan Sosey, https://github.com/sosey, screenshots at http://imexam.readthedocs.org/en/latest/imexam/imexam_command.html . I didn?t mention this initially because the original interface was DS9, but there is a version that uses ginger for the viewer. If you wanted to try something immediately on a tablet, I?d try dropping it in to one of the frameworks that claims to take python to multiple platforms.

Matt Craig

PS I know there is one more I?m forgetting?.

schedule:  http://physics.mnstate.edu/craig
??

Professor
Department of Physics and Astronomy
Minnesota State University Moorhead
1104 7th Ave S, Moorhead MN 56563

phone: (218) 477-2439
fax: (218) 477-2290

On Oct 1, 2015, at 11:48 PM, Matthew Craig <mcraig at mnstate.edu<mailto:mcraig at mnstate.edu>> wrote:

Hi Carl,

The really short answer is that as far as I know, no, if you want something right now that has the same capabilities as Salsa J (I?ve used AstroImageJ with the undergrads I work with, but think in the past I looked at SalsaJ for occasional work with a high school).

There are a couple things going on now that have some potential for this kind of use:

a. The package Toyz (http://fred3m.github.io/toyz/overview.html, and also see https://github.com/fred3m/toyz) was presented at the Python in Astronomy conference in 2015. I believe the model is that data is stored on a server, accessed via a browser, not sure how involved the setup is. I?d contact the author, Fred Moolekamp, for more details (actually, seeing his github page screenshots reminded me I should contact him too :). Contact information is on his github page, https://github.com/fred3m My memory from the conference is that he has used Toyz for some outreach.

b.  [Disclaimer: shameless self-promotion] I?ve developed an ipython/jupyter-based notebook for reducing data (not what you are looking for, I think), and am starting work this semester on a set of notebook-based tools for doing photometry. You can get an idea of what the current reducer interface looks like at http://reducer.readthedocs.org/en/latest/quickstart.html#quickstart ?it is *not* at all a replacement for  salsa j  at the moment, but the photometry notebook would closer be closer to that.

I think the future of easily usable python-based astro software will be:

+ astropy-based on the backend, or backed by python code that is tested and maintained at a similar level. Two reasons:
- it is tested and maintained
- if everyone doing this kind of outreach that touches much larger numbers is using a small set of well-validated tools then they can be doing useful science as well as learning (which is not to imply that useful science cannot be done with SalsaJ and kin, just that if you can use the tools the pros use, why wouldn?t you?)

+ browser-based for the user, with  ipython/jupyter running on a server hosted in the cloud (where the data is too), serving up notebook instances and saving user results. Several reasons:
- The jupyter/ipython infrastructure infrastructure is being adopted in a wide variety of industries ? the most interesting new widget work I saw at SciPy was by a developer who works at Bloomberg making clickable interfaces for traders. That scope of buy-in should ensure a long lifetime for the project.
- The jupyterhub infrastructure for doing cloud hosting is also developing rapidly.
- The anaconda python distribution has made installation much easier, but still hard for a novice.
- Notebooks are essentially editable apps, so that with a little teacher training and the right notebook design you could have a notebook that offers all of the menus and options that Salsa J has, but with the ability for teachers to remove components/complexity if they don?t need it.

A browser-based solution has the additional advantage that tablets/phones already have those, though the touch interface is still a work in progress.

I?m biased, but I also think easy-to-use tools will be developed first at the undergraduate level or lower, where there is a premium on minimizing the spin-up time for a new learner/researcher.  Eventually, it will trickle-up to larger institutions if the backend is something like astropy, and the interface makes doing what they need to do easier.

Let me know if you are interested in talking more ? I?m committed to building out a more complete set of undergrad-accessible tools in order to get more done with the undergrads at my university (limited, as always, by time and resources) but it would great to explore whether we might have some overlap.

Matt Craig

schedule:  http://physics.mnstate.edu/craig
??

Professor
Department of Physics and Astronomy
Minnesota State University Moorhead
1104 7th Ave S, Moorhead MN 56563

phone: (218) 477-2439
fax: (218) 477-2290

On Oct 2, 2015, at 5:43 PM, Carl Pennypacker <crpennypacker at lbl.gov<mailto:crpennypacker at lbl.gov>> wrote:

Dear Astropy Community,

I seek your help on the following: I am interested in a Python based
GUI with powerful underlying astronomy/.fts image handling
and analysis features. Over the past decades, our
Hands-On Universe program (see http://handsonuniverse.org/) has evolved through several such systems,
including initially a C++ version, an IDL based system, and finally to a system
based on NIH image (Image J now), called Salsa J (available from euhou.net<http://euhou.net/>).  We seek
features   such as aperture photometry, image
subtraction, image division/multiplication, flat fielding, adjusting
contrast in the display., surface plot, plotting of profiles (graph) across a
user-marked line, etc.  All these features work from pull down menus
while one's image is displayed. It is a huge amount of fun,
and students learn a lot.   This Salsa J resembles DS-9, which is good, but
we like Salsa J better (I apologize to folks at SAO).

Do you all know of anyone who has developed a nice GUI sitting on top of
AstroPy features, like I describe above with such features as are in our current Salsa J
system?  This seems like a very logical evolution of our software.

Finally, has anyone tried to compile such a python GUI or other
python routines onto Androids or Apple
tablets?  One the web, I see a number of systems that claim they
can take Python code and make it work on smart phones, without
having to learn Android or Iphone language..

If we had such a image processing system for tablets, we could reach many more
teachers with our educational system and community.

      Many Thanks,

     Carl Pennypacker
    UC Berkeley
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

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

From thomas.robitaille at gmail.com  Sat Oct  3 03:46:43 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sat, 03 Oct 2015 09:46:43 +0200
Subject: [AstroPy] Healpy
In-Reply-To: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
Message-ID: <560F87E3.5060103@gmail.com>

Hi Emil,

The 'reproject' Astropy-affiliated package provides a way to easily
reproject images using Healpy in addition to astropy.wcs:

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

The functionality with Healpy is optional, so the package is normally
BSD-licensed, but if you do install Healpy, then as indicated here:

http://reproject.readthedocs.org/en/stable/healpix.html

you have to abide by the GPL license instead.

Cheers,
Tom

Emil Lenc wrote:
> Hi All,
> 
> I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.
> 
> Cheers,
> 
> Emil.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From eric at naoj.org  Sat Oct  3 19:06:05 2015
From: eric at naoj.org (Eric Jeschke)
Date: Sat, 3 Oct 2015 13:06:05 -1000
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
Message-ID: <CA+PoO+UvKXtKS2k-ik5yLBLmZgOJEC5Vf7PNZNQdacdsdd1KmA@mail.gmail.com>

A quick follow-up to Matt's reply.

I agree with him that Ipython/Jupyter notebooks are really compelling
vehicles for teaching and documenting the use of python libraries, both for
students and practitioners.  Ginga has only nascent web-capabilities so
far, but you can get a little taste of what it has by checking out this
example notebook <http://nbviewer.ipython.org/gist/ejeschke/6067409>.

Ginga supports not only qt4/qt5/pyside, but also gtk2, tk, matplotlib and
now HTML backends.  We are considering adding one for bokeh.

~Eric


On Fri, Oct 2, 2015 at 4:43 PM, <astropy-request at scipy.org> wrote:

>
> Subject: Re: [AstroPy] Python powered GUI for secondary school
>         education image processing and possible porting to Tablets and
> Smart
>         Phones
> Message-ID: <7FA589B3-46EF-450E-92C0-3D220C0040BB at mnstate.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Hi again,
>
> A couple other projects that are python-based but use non-web backends
> (like I said in my original reply, I?m biased :)) that were mentioned off
> list but might be of interest to others are:
>
> + ginga, main contact is Eric Jeschke, screenshots at
> http://ejeschke.github.io/ginga/? ginger is a QT-based toolkit that also
> comes with a basic image browser, though that basic browser is intended as
> a demonstration of capabilities.
>
> + imexam, main contact Megan Sosey, https://github.com/sosey, screenshots
> at http://imexam.readthedocs.org/en/latest/imexam/imexam_command.html . I
> didn?t mention this initially because the original interface was DS9, but
> there is a version that uses ginger for the viewer. If you wanted to try
> something immediately on a tablet, I?d try dropping it in to one of the
> frameworks that claims to take python to multiple platforms.
>
> Matt Craig
>
> --
Eric Jeschke          |    eric at naoj.org    | ????,????
Software Engineer     |     808-934-5908    | ???????????
Subaru Telescope      |                     | ??????
National Astronomical Observatory of Japan

http://naoj.org/staff/eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151003/9df2f0eb/attachment.html>

From thomas.robitaille at gmail.com  Sun Oct  4 12:28:38 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sun, 04 Oct 2015 18:28:38 +0200
Subject: [AstroPy] Query about Table.add_row() method for masked tables
In-Reply-To: <560EA757.4000806@stsci.edu>
References: <A0DF21C9-9729-47BC-9D29-AF42290BD4EC@gmail.com>
 <560EA757.4000806@stsci.edu>
Message-ID: <561153B6.6030606@gmail.com>

Hi Josh,

The following should work:

    In [8]: t = Table([[1], [2]], names=('a','b'), masked=True)

    In [9]: t.add_row({})

    In [10]: t
    Out[10]:
    <Table masked=True length=2>
      a     b
    int64 int64
    ----- -----
        1     2
       --    --

Is this what you need?

Cheers,
Tom


Erik Bray wrote:
> On 10/1/2015 4:30 PM, Josh Tan wrote:
>> Hello,
>>
>> I have been trying to use astropy tables and have found that you
>> cannot add a
>> `None` row with a mask. While I can go and add np.zeroes by hand, it?s
>> a bit
>> annoying to me that it behaves this way. (See examples below.)
> 
> Hi Josh,
> 
> There definitely seems to be some conflict between add_row(None) and
> add_row(..., mask=...).  It seems to be that the allowed formats for the
> mask value aren't really compatible with the add_row(None) syntax.  I
> think that could be fixed--the way you were trying to do it,
> add_row(None, mask=True), makes sense to me.
> 
> Erik
> 
>> In [69]:
>>
>> t  =Table([[1], [2]],names=('a','b'),masked=True)
>>
>> t.add_row(None,mask=True)
>>
>> ---------------------------------------------------------------------------
>>
>> TypeError                                  Traceback (most recent call
>> last)
>> <ipython-input-69-4b6f404ff930>  in<module>() 1 t=  Table([[1], 
>> [2]],  names=('a',  'b'),  masked=True)
>> ----> 2t.add_row(None,  mask=True)
>>
>> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc 
>> inadd_row(self, vals, mask) 1623 3 6 9
>> 1624          """
>> -> 1625self.insert_row(len(self),  vals,  mask)
>> 1626
>> 1627      def  insert_row(self,  index,  vals=None,  mask=None):
>>
>> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc 
>> ininsert_row(self, index, vals, mask) 1674 # that have entries for
>> each table column.
>> 1675              if  maskis  not  Noneand  not  _is_mapping(mask):
>> -> 1676raise TypeError("Mismatch between type of vals and mask")
>> 1677
>> 1678              # Now check that the mask is specified for the same
>> keys as the
>>
>> TypeError: Mismatch between type of vals and mask
>>
>>
>> In [74]:
>>
>> t  =Table([[1], [2]],names=('a','b'),masked=True)
>>
>> t.add_row(None,mask=len(t.colnames)*[True])
>>
>> ---------------------------------------------------------------------------
>>
>> TypeError                                  Traceback (most recent call
>> last)
>> <ipython-input-74-ae9160dbf05d>  in<module>() 1 t=  Table([[1], 
>> [2]],  names=('a',  'b'),  masked=True)
>> ----> 2t.add_row(None,  mask=len(t.colnames)*[True])
>>
>> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc 
>> inadd_row(self, vals, mask) 1623 3 6 9
>> 1624          """
>> -> 1625self.insert_row(len(self),  vals,  mask)
>> 1626
>> 1627      def  insert_row(self,  index,  vals=None,  mask=None):
>>
>> /Users/joshuaschroeder/Documents/Ureka/python/lib/python2.7/site-packages/astropy/table/table.pyc 
>> ininsert_row(self, index, vals, mask) 1674 # that have entries for
>> each table column.
>> 1675              if  maskis  not  Noneand  not  _is_mapping(mask):
>> -> 1676raise TypeError("Mismatch between type of vals and mask")
>> 1677
>> 1678              # Now check that the mask is specified for the same
>> keys as the
>>
>> TypeError: Mismatch between type of vals and mask
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From elenc at me.com  Mon Oct  5 03:00:28 2015
From: elenc at me.com (Emil Lenc)
Date: Mon, 05 Oct 2015 18:00:28 +1100
Subject: [AstroPy] Healpy
In-Reply-To: <560F87E3.5060103@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
Message-ID: <03124D08-1957-49AD-8B17-89096247F422@me.com>

Thanks everyone for the useful input.

Tom, thanks also for highlighting the reprojection functionality as I wasn?t aware of it - that?s certainly something that?ll be useful to keep in mind. BTW, one of the additional bits of functionality that healpy provides is functionality associated with spherical harmonics. I?m fairly new in terms of working in this domain and I could be wrong but I assume this is not available elsewhere?

It would be a shame if licensing was the primary issue that prevented healpy from being incorporated - hopefully this can change in future.

Cheers,

Emil.

> On 3 Oct 2015, at 17:46, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
> 
> Hi Emil,
> 
> The 'reproject' Astropy-affiliated package provides a way to easily
> reproject images using Healpy in addition to astropy.wcs:
> 
> http://reproject.readthedocs.org/en/stable/
> 
> The functionality with Healpy is optional, so the package is normally
> BSD-licensed, but if you do install Healpy, then as indicated here:
> 
> http://reproject.readthedocs.org/en/stable/healpix.html
> 
> you have to abide by the GPL license instead.
> 
> Cheers,
> Tom
> 
> Emil Lenc wrote:
>> Hi All,
>> 
>> I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.
>> 
>> Cheers,
>> 
>> Emil.
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Mon Oct  5 05:01:31 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 5 Oct 2015 11:01:31 +0200
Subject: [AstroPy] ValueError in vstacking tables
In-Reply-To: <43427FA1-884D-4D70-BF21-EC7C0E3E97C5@di.utoronto.ca>
References: <46F38639-106E-4EF2-8449-6D6A949D851A@di.utoronto.ca>
 <CAMtEP6zd2iBnhCUauPNUD9OmP_aKP-H+3WM8z4hwv3fuhCPaaA@mail.gmail.com>
 <751D45BA-F658-40DF-9F42-1386499AD2B5@di.utoronto.ca>
 <70485B93-CED7-4C4D-8618-84EA06D8C483@di.utoronto.ca>
 <CAGMHX_0vzeoWC0kqFg30hio+6vENhXgqKU299HNHf5fRg=bcFA@mail.gmail.com>
 <BECEA73E-96CB-4C59-BA47-B4593D1E2A21@di.utoronto.ca>
 <CAGMHX_0anQWx2jT-2XOC=D=ty3Fv1U+7RsQeU887XL4-_7Ugqg@mail.gmail.com>
 <D163D344-FEC9-446B-8E5B-0AE501A94B86@di.utoronto.ca>
 <CAGMHX_3S0hJSz3RXr_GuzmgYKzwJvmDM0-ZGj7PeawUtCwP2qg@mail.gmail.com>
 <43427FA1-884D-4D70-BF21-EC7C0E3E97C5@di.utoronto.ca>
Message-ID: <CAGMHX_1gJRzZujTwaFr17Xg6ZeS+wK5rZfbFq330JD6dQ95raw@mail.gmail.com>

Hi Brian,

Just to follow up on this issue, a fix has now been merged into Numpy,
and will be available in Numpy 1.11 (unfortunately it missed the boat
for 1.10). The bug is basically just in the printing, and you can work
around it by doing

print table3[0:1]

In other words, the table itself is fine, it's just the printing of
single rows when accessed with a single index that was buggy.

Cheers,
Tom


On 23 June 2015 at 16:12, Brian Cherinka <cherinka at di.utoronto.ca> wrote:
> Hi Thomas,
>
> Excellent!  Thanks a lot.  Really appreciate it.
>
> Cheers, Brian
>
> ---------------------------------------
> Brian Cherinka, Ph.D
> Dunlap Institute for Astronomy & Astrophysics
> University of Toronto
> Toronto, ON, Canada M5S 3H4
> phone: 416-978-7299
> email: cherinka at di.utoronto.ca
> ----------------------------------------
>
> On Jun 23, 2015, at 10:10 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
>
>> Hi Brian,
>>
>> Thanks, this is helpful, and I managed to boil this down to a simple
>> failing example that I've reported here:
>>
>> https://github.com/astropy/astropy/issues/3877
>>
>> It seems to be due to the vector columns. We'll look into it!
>>
>> Cheers,
>> Tom
>>
>>
>> On 23 June 2015 at 14:58, Brian Cherinka <cherinka at di.utoronto.ca> wrote:
>>> Hi Thomas,
>>>
>>> In [187]: t1.dtype
>>> Out[187]: dtype([('plate', '>i8'), ('ifudsgn', 'S5'), ('plateifu', 'S9'),
>>> ('mangaid', 'S4'), ('versdrp2', 'S30'), ('versdrp3', 'S30'), ('verscore',
>>> 'S30'), ('versutil', 'S30'), ('platetyp', 'S30'), ('srvymode', 'S30'),
>>> ('objRA', '>f8'), ('objDEC', '>f8'), ('objGLON', '>f8'), ('objGLAT', '>f8'),
>>> ('ebvgal', '>f8'), ('nexp', '>i8'), ('exptime', '>f8'), ('drp3qual', '>i8'),
>>> ('bluesn2', '>f8'), ('redsn2', '>f8'), ('harname', 'S30'), ('frlplug',
>>> '>i8'), ('cartid', 'S30'), ('designid', '>i8'), ('cenRA', '>f8'), ('cenDEC',
>>> '>f8'), ('airmsmin', '>f8'), ('airmsmed', '>f8'), ('airmsmax', '>f8'),
>>> ('seemin', '>f8'), ('seemed', '>f8'), ('seemax', '>f8'), ('transmin',
>>> '>f8'), ('transmed', '>f8'), ('transmax', '>f8'), ('mjdmin', '>i8'),
>>> ('mjdmed', '>i8'), ('mjdmax', '>i8'), ('ufwhm', '>f8'), ('gfwhm', '>f8'),
>>> ('rfwhm', '>f8'), ('ifwhm', '>f8'), ('zfwhm', '>f8'), ('mngtarg1', '>i8'),
>>> ('mngtarg2', '>i8'), ('mngtarg3', '>i8'), ('catidnum', '>i8'), ('plttarg',
>>> 'S30')])
>>>
>>> In [188]: t2.dtype
>>> Out[188]: dtype([('manga_tileid', '<i8'), ('ifu_ra', '<f8'), ('ifu_dec',
>>> '<f8'), ('target_ra', '<f8'), ('target_dec', '<f8'), ('iauname', 'S19'),
>>> ('ifudesignsize', '<i8'), ('ifutargetsize', '<i8'), ('ifudesignwrongsize',
>>> '<i8'), ('field', '<i8'), ('run', '<i8'), ('nsa_version', 'S6'), ('nsa_id',
>>> '<i8'), ('nsa_id100', '<i8'), ('nsa_redshift', '<f8'), ('nsa_zdist', '<f8'),
>>> ('nsa_absmag', '<f8', (7,)), ('nsa_absmag_el', '<f8', (7,)),
>>> ('nsa_amivar_el', '<f8', (7,)), ('nsa_mstar', '<f8'), ('nsa_mstar_el',
>>> '<f8'), ('nsa_ba', '<f8'), ('nsa_phi', '<f8'), ('nsa_extinction', '<f8',
>>> (7,)), ('nsa_petro_th50', '<f8'), ('nsa_petro_th50_el', '<f8'),
>>> ('nsa_petroflux', '<f8', (7,)), ('nsa_petroflux_ivar', '<f8', (7,)),
>>> ('nsa_petroflux_el', '<f8', (7,)), ('nsa_petroflux_el_ivar', '<f8', (7,)),
>>> ('nsa_sersic_ba', '<f8'), ('nsa_sersic_n', '<f8'), ('nsa_sersic_phi',
>>> '<f8'), ('nsa_sersic_th50', '<f8'), ('nsa_sersicflux', '<f8', (7,)),
>>> ('nsa_sersicflux_ivar', '<f8', (7,))])
>>>
>>> t3 = hstack([t1,t2],join_type='outer?)  completes with no errors, however
>>>
>>> t3[0] gives
>>>
>>> <repr(<astropy.table.row.Row at 0x108af0b90>) failed: ValueError: setting an
>>> array element with a sequence.>
>>>
>>> then vstacking t3 with t4 completes with no errors, but gives the same error
>>> when row indexing.
>>>
>>> Cheers, Brian
>>>
>>> ---------------------------------------
>>> Brian Cherinka, Ph.D
>>> Dunlap Institute for Astronomy & Astrophysics
>>> University of Toronto
>>> Toronto, ON, Canada M5S 3H4
>>> phone: 416-978-7299
>>> email: cherinka at di.utoronto.ca
>>> ----------------------------------------
>>>
>>> On Jun 23, 2015, at 9:53 AM, Thomas Robitaille <thomas.robitaille at gmail.com>
>>> wrote:
>>>
>>> Hi Brian,
>>>
>>> On 23 June 2015 at 14:49, Brian Cherinka <cherinka at di.utoronto.ca> wrote:
>>>
>>> Hi Thomas,
>>>
>>> Could you let us know what table1.dtype and table3.dtype are equal to,
>>> and how many rows are in each table?
>>>
>>>
>>> The two tables, t1 and t2, that I am hstacking have 48 columns, and 36
>>> columns, respectively, each with 29 rows.  The dtype of those columns are a
>>> mix of things.  Mostly float and string scalars.  I do have several columns
>>> of float arrays.
>>>
>>>
>>> Just to clarify, could you copy and paste the exact output from
>>> table1.dtype and table3.dtype here so that we can try and reproduce
>>> the exact issue? (it may be a corner case due to the type of one of
>>> the columns).
>>>
>>> Thanks!
>>> Tom
>>>
>>> After hstacking, the resulting table (84 columns, 29 rows) is combined as
>>> expected, although I can no longer index the rows.  Then I vstack it with
>>> another table 3, which has the same number of columns, and same dtype.  I
>>> can?t row index that table either.
>>>
>>>
>>>
>>>
>>> Cheers, Brian
>>>
>>>
>>> ---------------------------------------
>>> Brian Cherinka, Ph.D
>>> Dunlap Institute for Astronomy & Astrophysics
>>> University of Toronto
>>> Toronto, ON, Canada M5S 3H4
>>> phone: 416-978-7299
>>> email: cherinka at di.utoronto.ca
>>> ----------------------------------------
>>>
>>> On Jun 19, 2015, at 8:43 AM, Thomas Robitaille <thomas.robitaille at gmail.com>
>>> wrote:
>>>
>>> Hi Brian,
>>>
>>> Could you let us know what table1.dtype and table3.dtype are equal to,
>>> and how many rows are in each table?
>>>
>>> Thanks!
>>> Tom
>>>
>>>
>>> On 18 June 2015 at 16:34, Brian Cherinka <cherinka at di.utoronto.ca> wrote:
>>>
>>> Anymore thoughts on this?  My table length issue wasn?t the problem.  I?m
>>> stilling having a problem with my resulting hstacks and vstacks.  The stacks
>>> happen without error.  I just lose the ability to index by row.
>>>
>>> Cheers, Brian
>>>
>>> ---------------------------------------
>>> Brian Cherinka, Ph.D
>>> Dunlap Institute for Astronomy & Astrophysics
>>> University of Toronto
>>> Toronto, ON, Canada M5S 3H4
>>> phone: 416-978-7299
>>> email: cherinka at di.utoronto.ca
>>> ----------------------------------------
>>>
>>> On Jun 17, 2015, at 3:25 PM, Brian Cherinka <cherinka at di.utoronto.ca> wrote:
>>>
>>> Hi Thomas,
>>>
>>> Your example does indeed work for me.  I cannot yet guess why it doesn?t
>>> work in my full example.  However it?s not quite a complete reconstruction
>>> of what I?m doing.  Technically, I?m hstacking two tables together, and then
>>> vstacking that result with another table.  Something like this, which works
>>> just fine.
>>>
>>> In [382]: t1 = Table([[1], [2]], names=['a', 'b'])
>>>
>>> In [383]: t2 = Table([[3], [4]], names=['c','d'])
>>>
>>> In [384]: t3 = hstack([t1,t2],join_type='outer')
>>>
>>> In [386]: t4 = Table([[5], [6]], names=['a', 'b'])
>>>
>>> In [387]: t34 = vstack([t3,t4],join_type='outer')
>>>
>>> In [388]: t34
>>> Out[388]:
>>> <Table masked=True length=2>
>>> a     b     c     d
>>> int64 int64 int64 int64
>>> ----- ----- ----- -----
>>>  1     2     3     4
>>>  5     6    --    --
>>>
>>> In [389]: t34[0]
>>> Out[389]:
>>> <Row 0 of table
>>> values=(1, 2, 3, 4)
>>> dtype=[('a', '<i8'), ('b', '<i8'), ('c', '<i8'), ('d', '<i8')]>
>>>
>>> In my full example, I did find though that I can row index the individual
>>> tables t1 and t2, but cannot row index table t3 after hstacking.  I get the
>>> same ValueError.  When I attempt to vstack with table t4, that error
>>> propagates forward.  I can row index t4 but not t34.  Looking at it a bit
>>> more, it might be that my rows in the initial tables t1, t2 do not match up
>>> with one another, and I appear to have one extra row in table t2, than I
>>> should.   I?ll dig a bit more.
>>>
>>> Cheers, Brian
>>>
>>> ---------------------------------------
>>> Brian Cherinka, Ph.D
>>> Dunlap Institute for Astronomy & Astrophysics
>>> University of Toronto
>>> Toronto, ON, Canada M5S 3H4
>>> phone: 416-978-7299
>>> email: cherinka at di.utoronto.ca
>>> ----------------------------------------
>>>
>>> On Jun 17, 2015, at 2:20 PM, Aldcroft, Thomas
>>> <aldcroft at head.cfa.harvard.edu> wrote:
>>>
>>> Hi Brian,
>>>
>>> Below is what I think is a minimal example of what you are describing.  Can
>>> you look at this and first reproduce that this works for you, and second,
>>> can you guess what might be different in your full example vs. my minimal
>>> example?
>>>
>>> In [19]: t1 = Table([[1], [2]], names=['a', 'b'])
>>>
>>> In [20]: t2 = Table([[3], [4]], names=['b', 'c'])
>>>
>>> In [23]: t12 = vstack([t1, t2], join_type='outer')
>>>
>>> In [24]: t12
>>> Out[24]:
>>> <Table masked=True length=2>
>>> a     b     c
>>> int64 int64 int64
>>> ----- ----- -----
>>>  1     2    --
>>> --     3     4
>>>
>>> In [25]: t12[0]
>>> Out[25]:
>>> <Row 0 of table
>>> values=(1, 2, --)
>>> dtype=[('a', '<i8'), ('b', '<i8'), ('c', '<i8')]>
>>>
>>>
>>> On Wed, Jun 17, 2015 at 2:08 PM, Brian Cherinka <cherinka at di.utoronto.ca>
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I?m trying to vstack (vertically stack) two Astropy tables with different
>>> numbers of columns.  The tables appear to stack correctly without error.
>>> However, upon attempting to index a row in the table, it throws me this
>>> error
>>>
>>> <repr(<astropy.table.row.Row at 0x10c72ed50>) failed: ValueError: setting
>>> an array element with a sequence.>
>>>
>>> I?m not trying to do anything fancy with mixed columns, or Quantities.
>>> Just stackin? two good ol? natural Tables together.     One table has 84
>>> columns, and another has 57, which are all a part of the 84 in the first
>>> table.  At first glance I would guess it?s a mismatch in the dtypes of a
>>> particular column that I?m trying to merge.  However, the columns all have
>>> the same dtype, format, and they are in the same order.  I get no messages
>>> regarding any kind of merge errors.
>>>
>>> Any ideas on this?
>>>
>>> Thanks, Brian
>>>
>>> P.S. Full print of traceback below
>>>
>>> table3 = vstack([table1, table3],join_type=?outer?)
>>> print table3[0]
>>>
>>> ---------------------------------------------------------------------------
>>> ValueError                                Traceback (most recent call
>>> last)
>>> <ipython-input-278-a0c75e8d3ef3> in <module>()
>>> ----> 1 print tmp3[0]
>>>
>>> /Users/Brian/anaconda/lib/python2.7/site-packages/astropy/table/row.pyc in
>>> __repr__(self)
>>>  176     def __repr__(self):
>>>  177         return "<{3} {0} of table\n values={1!r}\n
>>> dtype={2}>".format(
>>> --> 178             self.index, self.as_void(), self.dtype,
>>> self.__class__.__name__)
>>>  179
>>>  180
>>>
>>> /Users/Brian/anaconda/lib/python2.7/site-packages/numpy/ma/core.pyc in
>>> __repr__(self)
>>> 5699             return self._data.__repr__()
>>> 5700         m = tuple(m)
>>> -> 5701         if not any(m):
>>> 5702             return self._data.__repr__()
>>> 5703         p = masked_print_option
>>>
>>> /Users/Brian/anaconda/lib/python2.7/site-packages/numpy/ma/core.pyc in
>>> __call__(self, a, *args, **params)
>>> 6089         method = getattr(MaskedArray, method_name, None)
>>> 6090         if method is not None:
>>> -> 6091             return method(MaskedArray(a), *args, **params)
>>> 6092         # Still here ? OK, let's call the corresponding np
>>> function
>>> 6093         method = getattr(np, method_name)
>>>
>>> /Users/Brian/anaconda/lib/python2.7/site-packages/numpy/ma/core.pyc in
>>> __new__(cls, data, mask, dtype, copy, subok, ndmin, fill_value, keep_mask,
>>> hard_mask, shrink, **options)
>>> 2649         """
>>> 2650         # Process data............
>>> -> 2651         _data = np.array(data, dtype=dtype, copy=copy, subok=True,
>>> ndmin=ndmin)
>>> 2652         _baseclass = getattr(data, '_baseclass', type(_data))
>>> 2653         # Check that we're not erasing the mask..........
>>>
>>> ValueError: setting an array element with a sequence.
>>>
>>>
>>>
>>>
>>> ---------------------------------------
>>> Brian Cherinka, Ph.D
>>> Dunlap Institute for Astronomy & Astrophysics
>>> University of Toronto
>>> Toronto, ON, Canada M5S 3H4
>>> phone: 416-978-7299
>>> email: cherinka at di.utoronto.ca
>>> ----------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From wkerzendorf at gmail.com  Mon Oct  5 05:26:54 2015
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Mon, 05 Oct 2015 09:26:54 +0000
Subject: [AstroPy] Healpy
In-Reply-To: <03124D08-1957-49AD-8B17-89096247F422@me.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <03124D08-1957-49AD-8B17-89096247F422@me.com>
Message-ID: <CAH33GGE0Qs4v0y=3Di=dcy28WD3e3T+GMv6-Rg1tp3ygNX62+A@mail.gmail.com>

Hi Emil,

I personally believe that astropy shouldn't go out and incorporate all the
smaller packates into astropy core. Everytime something is incorporated,
the astropy core team would need to support and maintenance of the package
(and astropy core is already stretched thin). So I think it's better for
everyone if they stay independent (it's trivial to type pip install healpy
and works well). BUT, what I totally agree with you is that the astro
packages should easily work together. I would be very keen to hear what
functionality is still clunky? How would you like astropy and healpy to
work better together?

Cheers,
   Wolfgang

--
Dr. Wolfgang E Kerzendorf
ESO Fellow
European Southern Observatory
Karl-Schwarzschild Str. 2, 85748
Garching bei Muenchen, Germany

On Mon, Oct 5, 2015 at 9:00 AM Emil Lenc <elenc at me.com> wrote:

> Thanks everyone for the useful input.
>
> Tom, thanks also for highlighting the reprojection functionality as I
> wasn?t aware of it - that?s certainly something that?ll be useful to keep
> in mind. BTW, one of the additional bits of functionality that healpy
> provides is functionality associated with spherical harmonics. I?m fairly
> new in terms of working in this domain and I could be wrong but I assume
> this is not available elsewhere?
>
> It would be a shame if licensing was the primary issue that prevented
> healpy from being incorporated - hopefully this can change in future.
>
> Cheers,
>
> Emil.
>
> > On 3 Oct 2015, at 17:46, Thomas Robitaille <thomas.robitaille at gmail.com>
> wrote:
> >
> > Hi Emil,
> >
> > The 'reproject' Astropy-affiliated package provides a way to easily
> > reproject images using Healpy in addition to astropy.wcs:
> >
> > http://reproject.readthedocs.org/en/stable/
> >
> > The functionality with Healpy is optional, so the package is normally
> > BSD-licensed, but if you do install Healpy, then as indicated here:
> >
> > http://reproject.readthedocs.org/en/stable/healpix.html
> >
> > you have to abide by the GPL license instead.
> >
> > Cheers,
> > Tom
> >
> > Emil Lenc wrote:
> >> Hi All,
> >>
> >> I was wondering if there were any plans to incorporate healpy (the
> python interface to the HEALPIX library) into astropy? I often work between
> HEALPIX and FITS format images and it would be really convenient to have
> these two common formats available within the same package.
> >>
> >> Cheers,
> >>
> >> Emil.
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/astropy
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151005/277a3d1f/attachment.html>

From embray at stsci.edu  Mon Oct  5 11:53:17 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 5 Oct 2015 11:53:17 -0400
Subject: [AstroPy] Healpy
In-Reply-To: <CAH33GGE0Qs4v0y=3Di=dcy28WD3e3T+GMv6-Rg1tp3ygNX62+A@mail.gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com> <03124D08-1957-49AD-8B17-89096247F422@me.com>
 <CAH33GGE0Qs4v0y=3Di=dcy28WD3e3T+GMv6-Rg1tp3ygNX62+A@mail.gmail.com>
Message-ID: <56129CED.7060607@stsci.edu>

I strongly agree with Wolfgang here--licensing issues aside I don't think 
healpy, or some equivalent thereof, really belongs in the Astropy core package 
in the first place.  But having a Pythonic interface to healpix that works 
seamlessly with other Astropy-ish code is good and the reproject package seems 
to be the place for that.  Couldn't have said it better.

Erik

On 10/05/2015 05:26 AM, Wolfgang Kerzendorf wrote:
> Hi Emil,
>
> I personally believe that astropy shouldn't go out and incorporate all the
> smaller packates into astropy core. Everytime something is incorporated, the
> astropy core team would need to support and maintenance of the package (and
> astropy core is already stretched thin). So I think it's better for everyone if
> they stay independent (it's trivial to type pip install healpy and works well).
> BUT, what I totally agree with you is that the astro packages should easily work
> together. I would be very keen to hear what functionality is still clunky? How
> would you like astropy and healpy to work better together?
>
> Cheers,
>     Wolfgang
>
> --
> Dr. Wolfgang E Kerzendorf
> ESO Fellow
> European Southern Observatory
> Karl-Schwarzschild Str. 2, 85748
> Garching bei Muenchen, Germany
>
> On Mon, Oct 5, 2015 at 9:00 AM Emil Lenc <elenc at me.com <mailto:elenc at me.com>> wrote:
>
>     Thanks everyone for the useful input.
>
>     Tom, thanks also for highlighting the reprojection functionality as I wasn?t
>     aware of it - that?s certainly something that?ll be useful to keep in mind.
>     BTW, one of the additional bits of functionality that healpy provides is
>     functionality associated with spherical harmonics. I?m fairly new in terms
>     of working in this domain and I could be wrong but I assume this is not
>     available elsewhere?
>
>     It would be a shame if licensing was the primary issue that prevented healpy
>     from being incorporated - hopefully this can change in future.
>
>     Cheers,
>
>     Emil.
>
>      > On 3 Oct 2015, at 17:46, Thomas Robitaille <thomas.robitaille at gmail.com
>     <mailto:thomas.robitaille at gmail.com>> wrote:
>      >
>      > Hi Emil,
>      >
>      > The 'reproject' Astropy-affiliated package provides a way to easily
>      > reproject images using Healpy in addition to astropy.wcs:
>      >
>      > http://reproject.readthedocs.org/en/stable/
>      >
>      > The functionality with Healpy is optional, so the package is normally
>      > BSD-licensed, but if you do install Healpy, then as indicated here:
>      >
>      > http://reproject.readthedocs.org/en/stable/healpix.html
>      >
>      > you have to abide by the GPL license instead.
>      >
>      > Cheers,
>      > Tom
>      >
>      > Emil Lenc wrote:
>      >> Hi All,
>      >>
>      >> I was wondering if there were any plans to incorporate healpy (the
>     python interface to the HEALPIX library) into astropy? I often work between
>     HEALPIX and FITS format images and it would be really convenient to have
>     these two common formats available within the same package.
>      >>
>      >> Cheers,
>      >>
>      >> Emil.
>      >> _______________________________________________
>      >> AstroPy mailing list
>      >> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>      >> https://mail.scipy.org/mailman/listinfo/astropy
>      > _______________________________________________
>      > AstroPy mailing list
>      > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>      > https://mail.scipy.org/mailman/listinfo/astropy
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



From nathan12343 at gmail.com  Mon Oct  5 12:07:02 2015
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Mon, 5 Oct 2015 11:07:02 -0500
Subject: [AstroPy] Healpy
In-Reply-To: <560F87E3.5060103@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
Message-ID: <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>

On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Emil,
>
> The 'reproject' Astropy-affiliated package provides a way to easily
> reproject images using Healpy in addition to astropy.wcs:
>
> http://reproject.readthedocs.org/en/stable/
>
> The functionality with Healpy is optional, so the package is normally
> BSD-licensed, but if you do install Healpy, then as indicated here:
>
> http://reproject.readthedocs.org/en/stable/healpix.html
>
> you have to abide by the GPL license instead.
>

Hi Tom,

I don't want to stir up any problems for you, but I don't understand how
this works legally.

You're distributing code that imports healpy. Even if it's "optional"
functionality, the code that imports healpy is being distributed under a
BSD license. As far as I understand it, the intent of the user doesn't
matter for the licensing, all that matters is the license the code is
distributed under.

I'd strongly urge you to contact e.g. debian-legal or the software freedom
conservancy about this to get an opinion from an expert. I suspect your
only legal recourses here are either to no longer import healpy in the
reproject package or relicense reproject under a GPLv2 compatible license.

-Nathan


> Cheers,
> Tom
>
> Emil Lenc wrote:
> > Hi All,
> >
> > I was wondering if there were any plans to incorporate healpy (the
> python interface to the HEALPIX library) into astropy? I often work between
> HEALPIX and FITS format images and it would be really convenient to have
> these two common formats available within the same package.
> >
> > Cheers,
> >
> > Emil.
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151005/92348d9d/attachment.html>

From npkuin at gmail.com  Mon Oct  5 12:17:49 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 17:17:49 +0100
Subject: [AstroPy] fits coordinate system keyword
Message-ID: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>

I am getting very annoyed of the warning that keeps popping up

WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]

I'm not sure when the FITS standard changed, but MOST legacy fits files (I
use) will have the RADECSYS keyword. It works, and I do not see why someone
felt the need to keep this warning being popped up all the time.

I think that by default it should be off.

Since you all probably think it should be there, I would like to know how
to turn it off ?  any suggestion on how to do that?

Thanks,

    Paul


-- 

* * * * * * * * 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/20151005/23e7bbcd/attachment.html>

From stsci.perry at gmail.com  Mon Oct  5 12:20:50 2015
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 5 Oct 2015 12:20:50 -0400
Subject: [AstroPy] Healpy
In-Reply-To: <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
Message-ID: <04B7577C-483E-4792-9258-046D565E9232@gmail.com>

If that were the case then Python would have to be licensed as GPL since it uses readline optionally. But it isn?t and I know that they have looked at that issue carefully. From what I understand, if the functionality is not core to the package, and it isn?t bundled with the package, it doesn?t force the licensing of it. There probably are subtleties here since one might argue that readline is doesn?t add functionality to Python (but obviously it does), and healpy does. 

In this case I?m inclined to worry unless someone wants to make a legal issue of it, and in that even about the most that would happen is a cease-and-desist order. They aren?t going to make a lot of money suing Astropy (well, given the current checking account, they are bound to lose a lot of money in legal fees).

Perry

On Oct 5, 2015, at 12:07 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:

> 
> 
> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
> Hi Emil,
> 
> The 'reproject' Astropy-affiliated package provides a way to easily
> reproject images using Healpy in addition to astropy.wcs:
> 
> http://reproject.readthedocs.org/en/stable/
> 
> The functionality with Healpy is optional, so the package is normally
> BSD-licensed, but if you do install Healpy, then as indicated here:
> 
> http://reproject.readthedocs.org/en/stable/healpix.html
> 
> you have to abide by the GPL license instead.
> 
> Hi Tom,
> 
> I don't want to stir up any problems for you, but I don't understand how this works legally.
> 
> You're distributing code that imports healpy. Even if it's "optional" functionality, the code that imports healpy is being distributed under a BSD license. As far as I understand it, the intent of the user doesn't matter for the licensing, all that matters is the license the code is distributed under.
> 
> I'd strongly urge you to contact e.g. debian-legal or the software freedom conservancy about this to get an opinion from an expert. I suspect your only legal recourses here are either to no longer import healpy in the reproject package or relicense reproject under a GPLv2 compatible license.
>  
> -Nathan
> 
> 
> Cheers,
> Tom
> 
> Emil Lenc wrote:
> > Hi All,
> >
> > I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.
> >
> > Cheers,
> >
> > Emil.
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From embray at stsci.edu  Mon Oct  5 12:25:34 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 5 Oct 2015 12:25:34 -0400
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
Message-ID: <5612A47E.5010701@stsci.edu>

On 10/05/2015 12:17 PM, Paul Kuin wrote:
>
>
> I am getting very annoyed of the warning that keeps popping up
>
> WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
>
> I'm not sure when the FITS standard changed, but MOST legacy fits files (I use)
> will have the RADECSYS keyword. It works, and I do not see why someone felt the
> need to keep this warning being popped up all the time.

Probably as a warning to remind authors of new files that they shouldn't be 
using that keyword.  I don't know that it necessarily needs to be displayed 
every time reading in a WCS except maybe to head off cases of ambiguity.  But I 
don't know this particular issue well enough to be sure if the warning is 
appropriate in all cases or not.

> I think that by default it should be off.
>
> Since you all probably think it should be there, I would like to know how to
> turn it off ?  any suggestion on how to do that?

http://docs.astropy.org/en/stable/warnings.html


Erik



From wkerzendorf at gmail.com  Mon Oct  5 12:30:07 2015
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Mon, 5 Oct 2015 18:30:07 +0200
Subject: [AstroPy] Healpy
In-Reply-To: <04B7577C-483E-4792-9258-046D565E9232@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <04B7577C-483E-4792-9258-046D565E9232@gmail.com>
Message-ID: <8EB1E973-DE19-49C6-8E41-233FC1F6A31F@gmail.com>

This is very off topic:

I thought you just can?t ship a non-GPL package with GPL libraries. BUT: If Microsoft makes Word relying on some GPLed library (core-functionality), then they can ship a closed source copy of Word as long as the user needs to download the GPL library from some other source? 

Isn?t that right?

Cheers, 
   Wolfgang
> On Oct 5, 2015, at 18:20, Perry Greenfield <stsci.perry at gmail.com> wrote:
> 
> If that were the case then Python would have to be licensed as GPL since it uses readline optionally. But it isn?t and I know that they have looked at that issue carefully. From what I understand, if the functionality is not core to the package, and it isn?t bundled with the package, it doesn?t force the licensing of it. There probably are subtleties here since one might argue that readline is doesn?t add functionality to Python (but obviously it does), and healpy does. 
> 
> In this case I?m inclined to worry unless someone wants to make a legal issue of it, and in that even about the most that would happen is a cease-and-desist order. They aren?t going to make a lot of money suing Astropy (well, given the current checking account, they are bound to lose a lot of money in legal fees).
> 
> Perry
> 
> On Oct 5, 2015, at 12:07 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 
>> 
>> 
>> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
>> Hi Emil,
>> 
>> The 'reproject' Astropy-affiliated package provides a way to easily
>> reproject images using Healpy in addition to astropy.wcs:
>> 
>> http://reproject.readthedocs.org/en/stable/
>> 
>> The functionality with Healpy is optional, so the package is normally
>> BSD-licensed, but if you do install Healpy, then as indicated here:
>> 
>> http://reproject.readthedocs.org/en/stable/healpix.html
>> 
>> you have to abide by the GPL license instead.
>> 
>> Hi Tom,
>> 
>> I don't want to stir up any problems for you, but I don't understand how this works legally.
>> 
>> You're distributing code that imports healpy. Even if it's "optional" functionality, the code that imports healpy is being distributed under a BSD license. As far as I understand it, the intent of the user doesn't matter for the licensing, all that matters is the license the code is distributed under.
>> 
>> I'd strongly urge you to contact e.g. debian-legal or the software freedom conservancy about this to get an opinion from an expert. I suspect your only legal recourses here are either to no longer import healpy in the reproject package or relicense reproject under a GPLv2 compatible license.
>> 
>> -Nathan
>> 
>> 
>> Cheers,
>> Tom
>> 
>> Emil Lenc wrote:
>>> Hi All,
>>> 
>>> I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.
>>> 
>>> Cheers,
>>> 
>>> Emil.
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20151005/336ed2b9/attachment.bin>

From stsci.perry at gmail.com  Mon Oct  5 12:32:21 2015
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 5 Oct 2015 12:32:21 -0400
Subject: [AstroPy] Healpy
In-Reply-To: <8EB1E973-DE19-49C6-8E41-233FC1F6A31F@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <04B7577C-483E-4792-9258-046D565E9232@gmail.com>
 <8EB1E973-DE19-49C6-8E41-233FC1F6A31F@gmail.com>
Message-ID: <485720EA-E2AE-4EE1-88B0-A380649B7ED7@gmail.com>

Not if the functionality is essential to the package (at least from what I understand). I?ll see if I can dig that aspect of the license that specifically mentions it (or legal discussion around it).

Cheers, Perry

On Oct 5, 2015, at 12:30 PM, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:

> This is very off topic:
> 
> I thought you just can?t ship a non-GPL package with GPL libraries. BUT: If Microsoft makes Word relying on some GPLed library (core-functionality), then they can ship a closed source copy of Word as long as the user needs to download the GPL library from some other source? 
> 
> Isn?t that right?
> 
> Cheers, 
>   Wolfgang
>> On Oct 5, 2015, at 18:20, Perry Greenfield <stsci.perry at gmail.com> wrote:
>> 
>> If that were the case then Python would have to be licensed as GPL since it uses readline optionally. But it isn?t and I know that they have looked at that issue carefully. From what I understand, if the functionality is not core to the package, and it isn?t bundled with the package, it doesn?t force the licensing of it. There probably are subtleties here since one might argue that readline is doesn?t add functionality to Python (but obviously it does), and healpy does. 
>> 
>> In this case I?m inclined to worry unless someone wants to make a legal issue of it, and in that even about the most that would happen is a cease-and-desist order. They aren?t going to make a lot of money suing Astropy (well, given the current checking account, they are bound to lose a lot of money in legal fees).
>> 
>> Perry
>> 
>> On Oct 5, 2015, at 12:07 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
>> 
>>> 
>>> 
>>> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
>>> Hi Emil,
>>> 
>>> The 'reproject' Astropy-affiliated package provides a way to easily
>>> reproject images using Healpy in addition to astropy.wcs:
>>> 
>>> http://reproject.readthedocs.org/en/stable/
>>> 
>>> The functionality with Healpy is optional, so the package is normally
>>> BSD-licensed, but if you do install Healpy, then as indicated here:
>>> 
>>> http://reproject.readthedocs.org/en/stable/healpix.html
>>> 
>>> you have to abide by the GPL license instead.
>>> 
>>> Hi Tom,
>>> 
>>> I don't want to stir up any problems for you, but I don't understand how this works legally.
>>> 
>>> You're distributing code that imports healpy. Even if it's "optional" functionality, the code that imports healpy is being distributed under a BSD license. As far as I understand it, the intent of the user doesn't matter for the licensing, all that matters is the license the code is distributed under.
>>> 
>>> I'd strongly urge you to contact e.g. debian-legal or the software freedom conservancy about this to get an opinion from an expert. I suspect your only legal recourses here are either to no longer import healpy in the reproject package or relicense reproject under a GPLv2 compatible license.
>>> 
>>> -Nathan
>>> 
>>> 
>>> Cheers,
>>> Tom
>>> 
>>> Emil Lenc wrote:
>>>> Hi All,
>>>> 
>>>> I was wondering if there were any plans to incorporate healpy (the python interface to the HEALPIX library) into astropy? I often work between HEALPIX and FITS format images and it would be really convenient to have these two common formats available within the same package.
>>>> 
>>>> Cheers,
>>>> 
>>>> Emil.
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From peter at newton.cx  Mon Oct  5 13:20:08 2015
From: peter at newton.cx (Peter Williams)
Date: Mon, 05 Oct 2015 13:20:08 -0400
Subject: [AstroPy] Healpy
In-Reply-To: <485720EA-E2AE-4EE1-88B0-A380649B7ED7@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <04B7577C-483E-4792-9258-046D565E9232@gmail.com>
 <8EB1E973-DE19-49C6-8E41-233FC1F6A31F@gmail.com>
 <485720EA-E2AE-4EE1-88B0-A380649B7ED7@gmail.com>
Message-ID: <1444065608.3634.23.camel@newton.cx>

The last paragraph in this FAQ entry:

http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

seems, to me, to make it clear that using a GPL'd module inside an
interpreted program/library (e.g. astropy) obliges you to make it
available under GPL-compatible terms. I am generally positive about the
GPL but I find this to be unfortunate.

I think the best solution in these cases is to provide extension hooks
in the core (BSD/MIT-type-licensed) module so that you can load up an
optional GPL-licensed module so that GPL-only features can be used in a
relatively convenient way through the core module's API.

Peter

On Mon, 2015-10-05 at 12:32 -0400, Perry Greenfield wrote:
> Not if the functionality is essential to the package (at least from
> what I understand). I?ll see if I can dig that aspect of the license
> that specifically mentions it (or legal discussion around it).
> 
> Cheers, Perry
> 
> On Oct 5, 2015, at 12:30 PM, Wolfgang Kerzendorf <
> wkerzendorf at gmail.com> wrote:
> 
> > This is very off topic:
> > 
> > I thought you just can?t ship a non-GPL package with GPL libraries.
> > BUT: If Microsoft makes Word relying on some GPLed library (core
> > -functionality), then they can ship a closed source copy of Word as
> > long as the user needs to download the GPL library from some other
> > source? 
> > 
> > Isn?t that right?
> > 
> > Cheers, 
> >   Wolfgang
> > > On Oct 5, 2015, at 18:20, Perry Greenfield <stsci.perry at gmail.com
> > > > wrote:
> > > 
> > > If that were the case then Python would have to be licensed as
> > > GPL since it uses readline optionally. But it isn?t and I know
> > > that they have looked at that issue carefully. From what I
> > > understand, if the functionality is not core to the package, and
> > > it isn?t bundled with the package, it doesn?t force the licensing
> > > of it. There probably are subtleties here since one might argue
> > > that readline is doesn?t add functionality to Python (but
> > > obviously it does), and healpy does. 
> > > 
> > > In this case I?m inclined to worry unless someone wants to make a
> > > legal issue of it, and in that even about the most that would
> > > happen is a cease-and-desist order. They aren?t going to make a
> > > lot of money suing Astropy (well, given the current checking
> > > account, they are bound to lose a lot of money in legal fees).
> > > 
> > > Perry
> > > 
> > > On Oct 5, 2015, at 12:07 PM, Nathan Goldbaum <
> > > nathan12343 at gmail.com> wrote:
> > > 
> > > > 
> > > > 
> > > > On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <
> > > > thomas.robitaille at gmail.com> wrote:
> > > > Hi Emil,
> > > > 
> > > > The 'reproject' Astropy-affiliated package provides a way to
> > > > easily
> > > > reproject images using Healpy in addition to astropy.wcs:
> > > > 
> > > > http://reproject.readthedocs.org/en/stable/
> > > > 
> > > > The functionality with Healpy is optional, so the package is
> > > > normally
> > > > BSD-licensed, but if you do install Healpy, then as indicated
> > > > here:
> > > > 
> > > > http://reproject.readthedocs.org/en/stable/healpix.html
> > > > 
> > > > you have to abide by the GPL license instead.
> > > > 
> > > > Hi Tom,
> > > > 
> > > > I don't want to stir up any problems for you, but I don't
> > > > understand how this works legally.
> > > > 
> > > > You're distributing code that imports healpy. Even if it's
> > > > "optional" functionality, the code that imports healpy is being
> > > > distributed under a BSD license. As far as I understand it, the
> > > > intent of the user doesn't matter for the licensing, all that
> > > > matters is the license the code is distributed under.
> > > > 
> > > > I'd strongly urge you to contact e.g. debian-legal or the
> > > > software freedom conservancy about this to get an opinion from
> > > > an expert. I suspect your only legal recourses here are either
> > > > to no longer import healpy in the reproject package or
> > > > relicense reproject under a GPLv2 compatible license.
> > > > 
> > > > -Nathan
> > > > 
> > > > 
> > > > Cheers,
> > > > Tom
> > > > 
> > > > Emil Lenc wrote:
> > > > > Hi All,
> > > > > 
> > > > > I was wondering if there were any plans to incorporate healpy
> > > > > (the python interface to the HEALPIX library) into astropy? I
> > > > > often work between HEALPIX and FITS format images and it
> > > > > would be really convenient to have these two common formats
> > > > > available within the same package.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Emil.
> > > > > _______________________________________________
> > > > > AstroPy mailing list
> > > > > AstroPy at scipy.org
> > > > > https://mail.scipy.org/mailman/listinfo/astropy
> > > > _______________________________________________
> > > > AstroPy mailing list
> > > > AstroPy at scipy.org
> > > > https://mail.scipy.org/mailman/listinfo/astropy
> > > > 
> > > > _______________________________________________
> > > > AstroPy mailing list
> > > > AstroPy at scipy.org
> > > > https://mail.scipy.org/mailman/listinfo/astropy
> > > 
> > > _______________________________________________
> > > AstroPy mailing list
> > > AstroPy at scipy.org
> > > https://mail.scipy.org/mailman/listinfo/astropy
> > 
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 
> 


From stsci.perry at gmail.com  Mon Oct  5 13:29:17 2015
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 5 Oct 2015 13:29:17 -0400
Subject: [AstroPy] Healpy
In-Reply-To: <1444065608.3634.23.camel@newton.cx>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <04B7577C-483E-4792-9258-046D565E9232@gmail.com>
 <8EB1E973-DE19-49C6-8E41-233FC1F6A31F@gmail.com>
 <485720EA-E2AE-4EE1-88B0-A380649B7ED7@gmail.com>
 <1444065608.3634.23.camel@newton.cx>
Message-ID: <C242281A-E934-4892-AD95-039AD05A9D33@gmail.com>

That doesn?t say quite that. It says ?GPL-compatible? and 3-clause BSD is GPL compatible. A contrasting example is if you released software that had a GPL incompatible license (e.g., as SOFA did), you just can?t use GPL code at all, period, in any release.

This FAQ item is more relevant: http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

Note the third paragraph. ?Borderline? :-)

In any case, if even the current usage was prohibited, then one just designs the library to use a generic plug-in feature, and all the GPL-dependent plug-ins are released under the GPL separately somewhere else.

So long as there is no essential functionality needed in the plugin (e.g., there is no usefulness to the package without using the GPL software) then that probably skirts the issue effectively.

Cheers, Perry


On Oct 5, 2015, at 1:20 PM, Peter Williams <peter at newton.cx> wrote:

> The last paragraph in this FAQ entry:
> 
> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
> 
> seems, to me, to make it clear that using a GPL'd module inside an
> interpreted program/library (e.g. astropy) obliges you to make it
> available under GPL-compatible terms. I am generally positive about the
> GPL but I find this to be unfortunate.
> 
> I think the best solution in these cases is to provide extension hooks
> in the core (BSD/MIT-type-licensed) module so that you can load up an
> optional GPL-licensed module so that GPL-only features can be used in a
> relatively convenient way through the core module's API.
> 
> Peter
> 
> On Mon, 2015-10-05 at 12:32 -0400, Perry Greenfield wrote:
>> Not if the functionality is essential to the package (at least from
>> what I understand). I?ll see if I can dig that aspect of the license
>> that specifically mentions it (or legal discussion around it).
>> 
>> Cheers, Perry
>> 
>> On Oct 5, 2015, at 12:30 PM, Wolfgang Kerzendorf <
>> wkerzendorf at gmail.com> wrote:
>> 
>>> This is very off topic:
>>> 
>>> I thought you just can?t ship a non-GPL package with GPL libraries.
>>> BUT: If Microsoft makes Word relying on some GPLed library (core
>>> -functionality), then they can ship a closed source copy of Word as
>>> long as the user needs to download the GPL library from some other
>>> source? 
>>> 
>>> Isn?t that right?
>>> 
>>> Cheers, 
>>>  Wolfgang
>>>> On Oct 5, 2015, at 18:20, Perry Greenfield <stsci.perry at gmail.com
>>>>> wrote:
>>>> 
>>>> If that were the case then Python would have to be licensed as
>>>> GPL since it uses readline optionally. But it isn?t and I know
>>>> that they have looked at that issue carefully. From what I
>>>> understand, if the functionality is not core to the package, and
>>>> it isn?t bundled with the package, it doesn?t force the licensing
>>>> of it. There probably are subtleties here since one might argue
>>>> that readline is doesn?t add functionality to Python (but
>>>> obviously it does), and healpy does. 
>>>> 
>>>> In this case I?m inclined to worry unless someone wants to make a
>>>> legal issue of it, and in that even about the most that would
>>>> happen is a cease-and-desist order. They aren?t going to make a
>>>> lot of money suing Astropy (well, given the current checking
>>>> account, they are bound to lose a lot of money in legal fees).
>>>> 
>>>> Perry
>>>> 
>>>> On Oct 5, 2015, at 12:07 PM, Nathan Goldbaum <
>>>> nathan12343 at gmail.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille <
>>>>> thomas.robitaille at gmail.com> wrote:
>>>>> Hi Emil,
>>>>> 
>>>>> The 'reproject' Astropy-affiliated package provides a way to
>>>>> easily
>>>>> reproject images using Healpy in addition to astropy.wcs:
>>>>> 
>>>>> http://reproject.readthedocs.org/en/stable/
>>>>> 
>>>>> The functionality with Healpy is optional, so the package is
>>>>> normally
>>>>> BSD-licensed, but if you do install Healpy, then as indicated
>>>>> here:
>>>>> 
>>>>> http://reproject.readthedocs.org/en/stable/healpix.html
>>>>> 
>>>>> you have to abide by the GPL license instead.
>>>>> 
>>>>> Hi Tom,
>>>>> 
>>>>> I don't want to stir up any problems for you, but I don't
>>>>> understand how this works legally.
>>>>> 
>>>>> You're distributing code that imports healpy. Even if it's
>>>>> "optional" functionality, the code that imports healpy is being
>>>>> distributed under a BSD license. As far as I understand it, the
>>>>> intent of the user doesn't matter for the licensing, all that
>>>>> matters is the license the code is distributed under.
>>>>> 
>>>>> I'd strongly urge you to contact e.g. debian-legal or the
>>>>> software freedom conservancy about this to get an opinion from
>>>>> an expert. I suspect your only legal recourses here are either
>>>>> to no longer import healpy in the reproject package or
>>>>> relicense reproject under a GPLv2 compatible license.
>>>>> 
>>>>> -Nathan
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Tom
>>>>> 
>>>>> Emil Lenc wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> I was wondering if there were any plans to incorporate healpy
>>>>>> (the python interface to the HEALPIX library) into astropy? I
>>>>>> often work between HEALPIX and FITS format images and it
>>>>>> would be really convenient to have these two common formats
>>>>>> available within the same package.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Emil.
>>>>>> _______________________________________________
>>>>>> AstroPy mailing list
>>>>>> AstroPy at scipy.org
>>>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at scipy.org
>>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>>> 
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at scipy.org
>>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>> 
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Mon Oct  5 14:48:30 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 05 Oct 2015 20:48:30 +0200
Subject: [AstroPy] Healpy
In-Reply-To: <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
Message-ID: <5612C5FE.7060709@gmail.com>

Hi Nathan and others,

I already tried to contact the Free Software Foundation about this kind
of question (they have a special address for licensing questions), but
got no reply.

In these kinds of discussion, people often claim to know the answer (one
way or another), but none of us are lawyers, and the truth is that the
term 'derivative work' as used in GPL is poorly defined. There is a
whole section in the GPL Wikipedia article regarding statically linking
and dynamically linking against a GPL library:

https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

with different point of views rather than a single interpretation. I
think there really is no clear answer and we won't know until it's
tested in court. Since this is not a solved issue for linking, the
situation is even fuzzier for importing Python packages.

As a side note, I did contact the HEALPIX developers, and asked if they
could re-license under LGPL (or other) to avoid these issues, and one of
the developers answered and actually argued that healpy and any package
using it could actually be BSD as long as they don't modify HEALPIX, and
that they wouldn't seriously consider a change of license unless we can
definitely prove that this is an issue when importing Python modules.
All they want to do is prevent linking with proprietary codes (so I very
much doubt they will sue us).

Regarding my email about reproject, I did not say that users should
abide by the GPL only if they use the healpy-based functionality, but if
they *install* healpy. After all, if a user installs the reproject
package into an empty Python environment with just Astropy, and does not
have healpy installed, there is no reason they need to use that code and
obey the GPL just because my code contains the words 'import healpy'. In
a way, I am dual-licensing the software - if healpy is not installed,
people can use it under the BSD license, and if healpy is installed,
they should follow the GPL.

In any case, the issue will be moot soon. WCSLIB includes an
implementation of HEALPIX which I plan to swtich to as soon as possible.

Cheers,
Tom

Nathan Goldbaum wrote:
>
> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille
> > wrote:
>
>     Hi Emil,
>
>     The 'reproject' Astropy-affiliated package provides a way to easily
>     reproject images using Healpy in addition to astropy.wcs:
>
>     http://reproject.readthedocs.org/en/stable/
>
>     The functionality with Healpy is optional, so the package is normally
>     BSD-licensed, but if you do install Healpy, then as indicated here:
>
>     http://reproject.readthedocs.org/en/stable/healpix.html
>
>     you have to abide by the GPL license instead.
>
>
> Hi Tom,
>
> I don't want to stir up any problems for you, but I don't understand how
> this works legally.
>
> You're distributing code that imports healpy. Even if it's "optional"
> functionality, the code that imports healpy is being distributed under a
> BSD license. As far as I understand it, the intent of the user doesn't
> matter for the licensing, all that matters is the license the code is
> distributed under.
>
> I'd strongly urge you to contact e.g. debian-legal or the software
> freedom conservancy about this to get an opinion from an expert. I
> suspect your only legal recourses here are either to no longer import
> healpy in the reproject package or relicense reproject under a GPLv2
> compatible license.

>  
> -Nathan
>
>
>     Cheers,
>     Tom
>
>     Emil Lenc wrote:
>     > Hi All,
>     >
>     > I was wondering if there were any plans to incorporate healpy (the
>     python interface to the HEALPIX library) into astropy? I often work
>     between HEALPIX and FITS format images and it would be really
>     convenient to have these two common formats available within the
>     same package.
>     >
>     > Cheers,
>     >
>     > Emil.
>     > _______________________________________________
>     > AstroPy mailing list
>     > AstroPy at scipy.org 
>     > https://mail.scipy.org/mailman/listinfo/astropy
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org 
>     https://mail.scipy.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From nathan12343 at gmail.com  Mon Oct  5 15:02:11 2015
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Mon, 5 Oct 2015 14:02:11 -0500
Subject: [AstroPy] Healpy
In-Reply-To: <5612C5FE.7060709@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <5612C5FE.7060709@gmail.com>
Message-ID: <CAJXewOmHusPV1jRd-cNx7WXpDER5XWFxYDxdkHb+0USvwMSmoA@mail.gmail.com>

Thanks for the additional context, Tom!

On Mon, Oct 5, 2015 at 1:48 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Nathan and others,
>
> I already tried to contact the Free Software Foundation about this kind
> of question (they have a special address for licensing questions), but
> got no reply.
>
> In these kinds of discussion, people often claim to know the answer (one
> way or another), but none of us are lawyers, and the truth is that the
> term 'derivative work' as used in GPL is poorly defined. There is a
> whole section in the GPL Wikipedia article regarding statically linking
> and dynamically linking against a GPL library:
>
>
> https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
>
> with different point of views rather than a single interpretation. I
> think there really is no clear answer and we won't know until it's
> tested in court. Since this is not a solved issue for linking, the
> situation is even fuzzier for importing Python packages.
>
> As a side note, I did contact the HEALPIX developers, and asked if they
> could re-license under LGPL (or other) to avoid these issues, and one of
> the developers answered and actually argued that healpy and any package
> using it could actually be BSD as long as they don't modify HEALPIX, and
> that they wouldn't seriously consider a change of license unless we can
> definitely prove that this is an issue when importing Python modules.
> All they want to do is prevent linking with proprietary codes (so I very
> much doubt they will sue us).
>
> Regarding my email about reproject, I did not say that users should
> abide by the GPL only if they use the healpy-based functionality, but if
> they *install* healpy. After all, if a user installs the reproject
> package into an empty Python environment with just Astropy, and does not
> have healpy installed, there is no reason they need to use that code and
> obey the GPL just because my code contains the words 'import healpy'. In
> a way, I am dual-licensing the software - if healpy is not installed,
> people can use it under the BSD license, and if healpy is installed,
> they should follow the GPL.
>
> In any case, the issue will be moot soon. WCSLIB includes an
> implementation of HEALPIX which I plan to swtich to as soon as possible.
>
> Cheers,
> Tom
>
> Nathan Goldbaum wrote:
> >
> > On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille
> > > wrote:
> >
> >     Hi Emil,
> >
> >     The 'reproject' Astropy-affiliated package provides a way to easily
> >     reproject images using Healpy in addition to astropy.wcs:
> >
> >     http://reproject.readthedocs.org/en/stable/
> >
> >     The functionality with Healpy is optional, so the package is normally
> >     BSD-licensed, but if you do install Healpy, then as indicated here:
> >
> >     http://reproject.readthedocs.org/en/stable/healpix.html
> >
> >     you have to abide by the GPL license instead.
> >
> >
> > Hi Tom,
> >
> > I don't want to stir up any problems for you, but I don't understand how
> > this works legally.
> >
> > You're distributing code that imports healpy. Even if it's "optional"
> > functionality, the code that imports healpy is being distributed under a
> > BSD license. As far as I understand it, the intent of the user doesn't
> > matter for the licensing, all that matters is the license the code is
> > distributed under.
> >
> > I'd strongly urge you to contact e.g. debian-legal or the software
> > freedom conservancy about this to get an opinion from an expert. I
> > suspect your only legal recourses here are either to no longer import
> > healpy in the reproject package or relicense reproject under a GPLv2
> > compatible license.
>
> >
> > -Nathan
> >
> >
> >     Cheers,
> >     Tom
> >
> >     Emil Lenc wrote:
> >     > Hi All,
> >     >
> >     > I was wondering if there were any plans to incorporate healpy (the
> >     python interface to the HEALPIX library) into astropy? I often work
> >     between HEALPIX and FITS format images and it would be really
> >     convenient to have these two common formats available within the
> >     same package.
> >     >
> >     > Cheers,
> >     >
> >     > Emil.
> >     > _______________________________________________
> >     > AstroPy mailing list
> >     > AstroPy at scipy.org
> >     > https://mail.scipy.org/mailman/listinfo/astropy
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org
> >     https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151005/4b264614/attachment.html>

From npkuin at gmail.com  Mon Oct  5 15:20:05 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 20:20:05 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <5612A47E.5010701@stsci.edu>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
Message-ID: <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>

Actually, one of the basic tenets of FITS is to be completely backward
compatible, so any keyword that was valid in the past is valid now. So that
warning is also inaccurate. If it was standard, it still is, and ever will
be.



On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu> wrote:

> On 10/05/2015 12:17 PM, Paul Kuin wrote:
>
>>
>>
>> I am getting very annoyed of the warning that keeps popping up
>>
>> WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>> RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
>>
>> I'm not sure when the FITS standard changed, but MOST legacy fits files
>> (I use)
>> will have the RADECSYS keyword. It works, and I do not see why someone
>> felt the
>> need to keep this warning being popped up all the time.
>>
>
> Probably as a warning to remind authors of new files that they shouldn't
> be using that keyword.  I don't know that it necessarily needs to be
> displayed every time reading in a WCS except maybe to head off cases of
> ambiguity.  But I don't know this particular issue well enough to be sure
> if the warning is appropriate in all cases or not.
>
> I think that by default it should be off.
>>
>> Since you all probably think it should be there, I would like to know how
>> to
>> turn it off ?  any suggestion on how to do that?
>>
>
> http://docs.astropy.org/en/stable/warnings.html
>
>
> Erik
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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/20151005/fb50620e/attachment.html>

From leo.p.singer at nasa.gov  Mon Oct  5 15:24:00 2015
From: leo.p.singer at nasa.gov (Singer, Leo P. (GSFC-661.0)[OAK RIDGE ASSOCIATED UNIVERSITIES (ORAU)])
Date: Mon, 5 Oct 2015 19:24:00 +0000
Subject: [AstroPy] Healpy
In-Reply-To: <5612C5FE.7060709@gmail.com>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <5612C5FE.7060709@gmail.com>
Message-ID: <32059E10-45AA-4E2E-A400-68D43E95A68E@nasa.gov>

Hi,

I help out a little with Healpy, mainly on bug fixes and software packaging. Healpy has a kind of specialized build process because the underlying healpix_cxx library uses some bleeding edge C++ and runtime features. I think that the Healpy developers would be delighted to have some help making Healpy an Astropy-affiliated package. At a technical level, wouldn't that be a step closer to actual integration with Astropy?

Thanks,
Leo P. Singer
NASA Postdoctoral Program Fellow
Goddard Space Flight Center

> On Oct 5, 2015, at 14:48, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
> 
> Hi Nathan and others,
> 
> I already tried to contact the Free Software Foundation about this kind
> of question (they have a special address for licensing questions), but
> got no reply.
> 
> In these kinds of discussion, people often claim to know the answer (one
> way or another), but none of us are lawyers, and the truth is that the
> term 'derivative work' as used in GPL is poorly defined. There is a
> whole section in the GPL Wikipedia article regarding statically linking
> and dynamically linking against a GPL library:
> 
> https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
> 
> with different point of views rather than a single interpretation. I
> think there really is no clear answer and we won't know until it's
> tested in court. Since this is not a solved issue for linking, the
> situation is even fuzzier for importing Python packages.
> 
> As a side note, I did contact the HEALPIX developers, and asked if they
> could re-license under LGPL (or other) to avoid these issues, and one of
> the developers answered and actually argued that healpy and any package
> using it could actually be BSD as long as they don't modify HEALPIX, and
> that they wouldn't seriously consider a change of license unless we can
> definitely prove that this is an issue when importing Python modules.
> All they want to do is prevent linking with proprietary codes (so I very
> much doubt they will sue us).
> 
> Regarding my email about reproject, I did not say that users should
> abide by the GPL only if they use the healpy-based functionality, but if
> they *install* healpy. After all, if a user installs the reproject
> package into an empty Python environment with just Astropy, and does not
> have healpy installed, there is no reason they need to use that code and
> obey the GPL just because my code contains the words 'import healpy'. In
> a way, I am dual-licensing the software - if healpy is not installed,
> people can use it under the BSD license, and if healpy is installed,
> they should follow the GPL.
> 
> In any case, the issue will be moot soon. WCSLIB includes an
> implementation of HEALPIX which I plan to swtich to as soon as possible.
> 
> Cheers,
> Tom
> 
> Nathan Goldbaum wrote:
>> 
>> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille
>>> wrote:
>> 
>>    Hi Emil,
>> 
>>    The 'reproject' Astropy-affiliated package provides a way to easily
>>    reproject images using Healpy in addition to astropy.wcs:
>> 
>>    http://reproject.readthedocs.org/en/stable/
>> 
>>    The functionality with Healpy is optional, so the package is normally
>>    BSD-licensed, but if you do install Healpy, then as indicated here:
>> 
>>    http://reproject.readthedocs.org/en/stable/healpix.html
>> 
>>    you have to abide by the GPL license instead.
>> 
>> 
>> Hi Tom,
>> 
>> I don't want to stir up any problems for you, but I don't understand how
>> this works legally.
>> 
>> You're distributing code that imports healpy. Even if it's "optional"
>> functionality, the code that imports healpy is being distributed under a
>> BSD license. As far as I understand it, the intent of the user doesn't
>> matter for the licensing, all that matters is the license the code is
>> distributed under.
>> 
>> I'd strongly urge you to contact e.g. debian-legal or the software
>> freedom conservancy about this to get an opinion from an expert. I
>> suspect your only legal recourses here are either to no longer import
>> healpy in the reproject package or relicense reproject under a GPLv2
>> compatible license.
> 
>> 
>> -Nathan
>> 
>> 
>>    Cheers,
>>    Tom
>> 
>>    Emil Lenc wrote:
>>> Hi All,
>>> 
>>> I was wondering if there were any plans to incorporate healpy (the
>>    python interface to the HEALPIX library) into astropy? I often work
>>    between HEALPIX and FITS format images and it would be really
>>    convenient to have these two common formats available within the
>>    same package.
>>> 
>>> Cheers,
>>> 
>>> Emil.
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org 
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>    _______________________________________________
>>    AstroPy mailing list
>>    AstroPy at scipy.org 
>>    https://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 


From thomas.robitaille at gmail.com  Mon Oct  5 15:28:25 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 05 Oct 2015 21:28:25 +0200
Subject: [AstroPy] Healpy
In-Reply-To: <32059E10-45AA-4E2E-A400-68D43E95A68E@nasa.gov>
References: <88DEBC5F-7814-4810-93FC-2BFB4913CD6C@me.com>
 <560F87E3.5060103@gmail.com>
 <CAJXewO=5Re__7D3m50FbTK3QMjzg7mPTJnGJXhnKxbtz_DFJcQ@mail.gmail.com>
 <5612C5FE.7060709@gmail.com> <32059E10-45AA-4E2E-A400-68D43E95A68E@nasa.gov>
Message-ID: <5612CF59.6020309@gmail.com>

Hi Leo,

Yes, this would be great - and note that affiliated packages don't have
to be BSD (in fact, that was one of the reasons to have affiliated
packages - to allow different licenses if needed).

Cheers,
Tom

Singer, Leo P. (GSFC-661.0)[OAK RIDGE ASSOCIATED UNIVERSITIES (ORAU)] wrote:
> Hi,
> 
> I help out a little with Healpy, mainly on bug fixes and software packaging. Healpy has a kind of specialized build process because the underlying healpix_cxx library uses some bleeding edge C++ and runtime features. I think that the Healpy developers would be delighted to have some help making Healpy an Astropy-affiliated package. At a technical level, wouldn't that be a step closer to actual integration with Astropy?
> 
> Thanks,
> Leo P. Singer
> NASA Postdoctoral Program Fellow
> Goddard Space Flight Center
> 
>> On Oct 5, 2015, at 14:48, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
>>
>> Hi Nathan and others,
>>
>> I already tried to contact the Free Software Foundation about this kind
>> of question (they have a special address for licensing questions), but
>> got no reply.
>>
>> In these kinds of discussion, people often claim to know the answer (one
>> way or another), but none of us are lawyers, and the truth is that the
>> term 'derivative work' as used in GPL is poorly defined. There is a
>> whole section in the GPL Wikipedia article regarding statically linking
>> and dynamically linking against a GPL library:
>>
>> https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
>>
>> with different point of views rather than a single interpretation. I
>> think there really is no clear answer and we won't know until it's
>> tested in court. Since this is not a solved issue for linking, the
>> situation is even fuzzier for importing Python packages.
>>
>> As a side note, I did contact the HEALPIX developers, and asked if they
>> could re-license under LGPL (or other) to avoid these issues, and one of
>> the developers answered and actually argued that healpy and any package
>> using it could actually be BSD as long as they don't modify HEALPIX, and
>> that they wouldn't seriously consider a change of license unless we can
>> definitely prove that this is an issue when importing Python modules.
>> All they want to do is prevent linking with proprietary codes (so I very
>> much doubt they will sue us).
>>
>> Regarding my email about reproject, I did not say that users should
>> abide by the GPL only if they use the healpy-based functionality, but if
>> they *install* healpy. After all, if a user installs the reproject
>> package into an empty Python environment with just Astropy, and does not
>> have healpy installed, there is no reason they need to use that code and
>> obey the GPL just because my code contains the words 'import healpy'. In
>> a way, I am dual-licensing the software - if healpy is not installed,
>> people can use it under the BSD license, and if healpy is installed,
>> they should follow the GPL.
>>
>> In any case, the issue will be moot soon. WCSLIB includes an
>> implementation of HEALPIX which I plan to swtich to as soon as possible.
>>
>> Cheers,
>> Tom
>>
>> Nathan Goldbaum wrote:
>>> On Sat, Oct 3, 2015 at 2:46 AM, Thomas Robitaille
>>>> wrote:
>>>    Hi Emil,
>>>
>>>    The 'reproject' Astropy-affiliated package provides a way to easily
>>>    reproject images using Healpy in addition to astropy.wcs:
>>>
>>>    http://reproject.readthedocs.org/en/stable/
>>>
>>>    The functionality with Healpy is optional, so the package is normally
>>>    BSD-licensed, but if you do install Healpy, then as indicated here:
>>>
>>>    http://reproject.readthedocs.org/en/stable/healpix.html
>>>
>>>    you have to abide by the GPL license instead.
>>>
>>>
>>> Hi Tom,
>>>
>>> I don't want to stir up any problems for you, but I don't understand how
>>> this works legally.
>>>
>>> You're distributing code that imports healpy. Even if it's "optional"
>>> functionality, the code that imports healpy is being distributed under a
>>> BSD license. As far as I understand it, the intent of the user doesn't
>>> matter for the licensing, all that matters is the license the code is
>>> distributed under.
>>>
>>> I'd strongly urge you to contact e.g. debian-legal or the software
>>> freedom conservancy about this to get an opinion from an expert. I
>>> suspect your only legal recourses here are either to no longer import
>>> healpy in the reproject package or relicense reproject under a GPLv2
>>> compatible license.
>>> -Nathan
>>>
>>>
>>>    Cheers,
>>>    Tom
>>>
>>>    Emil Lenc wrote:
>>>> Hi All,
>>>>
>>>> I was wondering if there were any plans to incorporate healpy (the
>>>    python interface to the HEALPIX library) into astropy? I often work
>>>    between HEALPIX and FITS format images and it would be really
>>>    convenient to have these two common formats available within the
>>>    same package.
>>>> Cheers,
>>>>
>>>> Emil.
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org 
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>    _______________________________________________
>>>    AstroPy mailing list
>>>    AstroPy at scipy.org 
>>>    https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy


From thomas.robitaille at gmail.com  Mon Oct  5 15:34:33 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 05 Oct 2015 21:34:33 +0200
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
Message-ID: <5612D0C9.7060805@gmail.com>

Hi Paul,

Just out of curiosity, was RADECSYS ever a keyword in the FITS standard,
as opposed to RADESYS? (which is the currently valid keyword). If so, in
what version of the standard?

Cheers,
Tom

Paul Kuin wrote:
> Actually, one of the basic tenets of FITS is to be completely backward
> compatible, so any keyword that was valid in the past is valid now. So
> that warning is also inaccurate. If it was standard, it still is, and
> ever will be.
> 
> 
> 
> On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> <mailto:embray at stsci.edu>> wrote:
> 
>     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> 
> 
> 
>         I am getting very annoyed of the warning that keeps popping up
> 
>         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> 
>         I'm not sure when the FITS standard changed, but MOST legacy
>         fits files (I use)
>         will have the RADECSYS keyword. It works, and I do not see why
>         someone felt the
>         need to keep this warning being popped up all the time.
> 
> 
>     Probably as a warning to remind authors of new files that they
>     shouldn't be using that keyword.  I don't know that it necessarily
>     needs to be displayed every time reading in a WCS except maybe to
>     head off cases of ambiguity.  But I don't know this particular issue
>     well enough to be sure if the warning is appropriate in all cases or
>     not.
> 
>         I think that by default it should be off.
> 
>         Since you all probably think it should be there, I would like to
>         know how to
>         turn it off ?  any suggestion on how to do that?
> 
> 
>     http://docs.astropy.org/en/stable/warnings.html
> 
> 
>     Erik
> 
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> 
> 
> -- 
> 
> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From npkuin at gmail.com  Mon Oct  5 15:55:31 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 20:55:31 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <5612D0C9.7060805@gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
Message-ID: <CANoQ6N3t10OTFdOA0GeXBt-O0ueKJ5bkQgHEk3-0H=2PgHzFDA@mail.gmail.com>

Hi Tom,

I forwarded the question to Bill Pence who seems to be now the Fits support
office person. (Sorry forgot to cc you). Also, it is the heasarc files from
Swift that I use, so there is another thing (Bill is part of Heasarc, I
think). In any case, the Fits support office kept track of these kind of
issues in the past, and it is good to push the rusty wheels once again.

Now for the wait...

   Cheers,

        Paul

On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Paul,
>
> Just out of curiosity, was RADECSYS ever a keyword in the FITS standard,
> as opposed to RADESYS? (which is the currently valid keyword). If so, in
> what version of the standard?
>
> Cheers,
> Tom
>
> Paul Kuin wrote:
> > Actually, one of the basic tenets of FITS is to be completely backward
> > compatible, so any keyword that was valid in the past is valid now. So
> > that warning is also inaccurate. If it was standard, it still is, and
> > ever will be.
> >
> >
> >
> > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> > <mailto:embray at stsci.edu>> wrote:
> >
> >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >
> >
> >
> >         I am getting very annoyed of the warning that keeps popping up
> >
> >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> >
> >         I'm not sure when the FITS standard changed, but MOST legacy
> >         fits files (I use)
> >         will have the RADECSYS keyword. It works, and I do not see why
> >         someone felt the
> >         need to keep this warning being popped up all the time.
> >
> >
> >     Probably as a warning to remind authors of new files that they
> >     shouldn't be using that keyword.  I don't know that it necessarily
> >     needs to be displayed every time reading in a WCS except maybe to
> >     head off cases of ambiguity.  But I don't know this particular issue
> >     well enough to be sure if the warning is appropriate in all cases or
> >     not.
> >
> >         I think that by default it should be off.
> >
> >         Since you all probably think it should be there, I would like to
> >         know how to
> >         turn it off ?  any suggestion on how to do that?
> >
> >
> >     http://docs.astropy.org/en/stable/warnings.html
> >
> >
> >     Erik
> >
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > --
> >
> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151005/196a1509/attachment.html>

From stsci.perry at gmail.com  Mon Oct  5 15:57:20 2015
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Mon, 5 Oct 2015 15:57:20 -0400
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
Message-ID: <5FA389CB-73D7-4CDD-85BA-D5C362ECD608@gmail.com>

That?s somewhat arguable. Say in 1990 I had a header with 

PC1_1 = ?BOZO?

That would have been legal. After the WCS standard was accepted, it would have been illegal.

Perry

On Oct 5, 2015, at 3:20 PM, Paul Kuin <npkuin at gmail.com> wrote:

> Actually, one of the basic tenets of FITS is to be completely backward compatible, so any keyword that was valid in the past is valid now. So that warning is also inaccurate. If it was standard, it still is, and ever will be. 
> 
> 
> 
> On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu> wrote:
> On 10/05/2015 12:17 PM, Paul Kuin wrote:
> 
> 
> I am getting very annoyed of the warning that keeps popping up
> 
> WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> 
> I'm not sure when the FITS standard changed, but MOST legacy fits files (I use)
> will have the RADECSYS keyword. It works, and I do not see why someone felt the
> need to keep this warning being popped up all the time.
> 
> Probably as a warning to remind authors of new files that they shouldn't be using that keyword.  I don't know that it necessarily needs to be displayed every time reading in a WCS except maybe to head off cases of ambiguity.  But I don't know this particular issue well enough to be sure if the warning is appropriate in all cases or not.
> 
> I think that by default it should be off.
> 
> Since you all probably think it should be there, I would like to know how to
> turn it off ?  any suggestion on how to do that?
> 
> http://docs.astropy.org/en/stable/warnings.html
> 
> 
> Erik
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From npkuin at gmail.com  Mon Oct  5 15:59:38 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 20:59:38 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <5FA389CB-73D7-4CDD-85BA-D5C362ECD608@gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5FA389CB-73D7-4CDD-85BA-D5C362ECD608@gmail.com>
Message-ID: <CANoQ6N3yvpzzrpVEAPPRGX9rAESjOvf5hZ0kuk97sDwgXkHqtQ@mail.gmail.com>

I think we had at the time that discussion and asked for feedback on the
keywords, When that period ended, I think it was set in stone.

So, I don't agree that it is arguable.

Paul

On Mon, Oct 5, 2015 at 8:57 PM, Perry Greenfield <stsci.perry at gmail.com>
wrote:

> That?s somewhat arguable. Say in 1990 I had a header with
>
> PC1_1 = ?BOZO?
>
> That would have been legal. After the WCS standard was accepted, it would
> have been illegal.
>
> Perry
>
> On Oct 5, 2015, at 3:20 PM, Paul Kuin <npkuin at gmail.com> wrote:
>
> > Actually, one of the basic tenets of FITS is to be completely backward
> compatible, so any keyword that was valid in the past is valid now. So that
> warning is also inaccurate. If it was standard, it still is, and ever will
> be.
> >
> >
> >
> > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu> wrote:
> > On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >
> >
> > I am getting very annoyed of the warning that keeps popping up
> >
> > WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> > RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> >
> > I'm not sure when the FITS standard changed, but MOST legacy fits files
> (I use)
> > will have the RADECSYS keyword. It works, and I do not see why someone
> felt the
> > need to keep this warning being popped up all the time.
> >
> > Probably as a warning to remind authors of new files that they shouldn't
> be using that keyword.  I don't know that it necessarily needs to be
> displayed every time reading in a WCS except maybe to head off cases of
> ambiguity.  But I don't know this particular issue well enough to be sure
> if the warning is appropriate in all cases or not.
> >
> > I think that by default it should be off.
> >
> > Since you all probably think it should be there, I would like to know
> how to
> > turn it off ?  any suggestion on how to do that?
> >
> > http://docs.astropy.org/en/stable/warnings.html
> >
> >
> > Erik
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://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.
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151005/ed4e9d03/attachment.html>

From npkuin at gmail.com  Mon Oct  5 16:50:20 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 21:50:20 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <5612D0C9.7060805@gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
Message-ID: <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>

In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
Representations of celestial coordinates in FITS
http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079 the
is a table defining some variables used. In particular 'a' is alternate
version code 'blank or [A-Z]. In table 2 on page 1082, the definition is
RADESYSa, meaning that valid versions are either RADESYS, RADESYSA,
RADESYSB, ... , RADESYSZ.

So it always was defined as a valid. Similar, EQUINOXa/. I've seen that
mostly used as just EQUINOX. If the header has just one WCS block, or a
preferred one, that is useful to have.

Let's see what Bill Pence says. Maybe there were some changes after all.



On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Paul,
>
> Just out of curiosity, was RADECSYS ever a keyword in the FITS standard,
> as opposed to RADESYS? (which is the currently valid keyword). If so, in
> what version of the standard?
>
> Cheers,
> Tom
>
> Paul Kuin wrote:
> > Actually, one of the basic tenets of FITS is to be completely backward
> > compatible, so any keyword that was valid in the past is valid now. So
> > that warning is also inaccurate. If it was standard, it still is, and
> > ever will be.
> >
> >
> >
> > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> > <mailto:embray at stsci.edu>> wrote:
> >
> >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >
> >
> >
> >         I am getting very annoyed of the warning that keeps popping up
> >
> >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> >
> >         I'm not sure when the FITS standard changed, but MOST legacy
> >         fits files (I use)
> >         will have the RADECSYS keyword. It works, and I do not see why
> >         someone felt the
> >         need to keep this warning being popped up all the time.
> >
> >
> >     Probably as a warning to remind authors of new files that they
> >     shouldn't be using that keyword.  I don't know that it necessarily
> >     needs to be displayed every time reading in a WCS except maybe to
> >     head off cases of ambiguity.  But I don't know this particular issue
> >     well enough to be sure if the warning is appropriate in all cases or
> >     not.
> >
> >         I think that by default it should be off.
> >
> >         Since you all probably think it should be there, I would like to
> >         know how to
> >         turn it off ?  any suggestion on how to do that?
> >
> >
> >     http://docs.astropy.org/en/stable/warnings.html
> >
> >
> >     Erik
> >
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > --
> >
> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151005/2c746cbc/attachment.html>

From thomas.robitaille at gmail.com  Mon Oct  5 17:17:25 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 05 Oct 2015 23:17:25 +0200
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
Message-ID: <5612E8E5.4020700@gmail.com>

I think there is a misunderstanding:

RADECSYS is not valid

RADESYS is valid

(note the extra C). We are not debating that RADESYS is valid - it is -
but the warning concerns the common mis-spelling of RADE*C*SYS. Does
this make sense?

Cheers,
Tom

Paul Kuin wrote:
> In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
> Representations of celestial coordinates in FITS
> http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079
> the is a table defining some variables used. In particular 'a' is
> alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
> definition is RADESYSa, meaning that valid versions are either RADESYS,
> RADESYSA, RADESYSB, ... , RADESYSZ.
> 
> So it always was defined as a valid. Similar, EQUINOXa/. I've seen that
> mostly used as just EQUINOX. If the header has just one WCS block, or a
> preferred one, that is useful to have.
> 
> Let's see what Bill Pence says. Maybe there were some changes after all.
> 
> 
> 
> On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
> <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>> wrote:
> 
>     Hi Paul,
> 
>     Just out of curiosity, was RADECSYS ever a keyword in the FITS standard,
>     as opposed to RADESYS? (which is the currently valid keyword). If so, in
>     what version of the standard?
> 
>     Cheers,
>     Tom
> 
>     Paul Kuin wrote:
>     > Actually, one of the basic tenets of FITS is to be completely backward
>     > compatible, so any keyword that was valid in the past is valid now. So
>     > that warning is also inaccurate. If it was standard, it still is, and
>     > ever will be.
>     >
>     >
>     >
>     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
>     <mailto:embray at stsci.edu>
>     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
>     >
>     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
>     >
>     >
>     >
>     >         I am getting very annoyed of the warning that keeps popping up
>     >
>     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>     >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
>     >
>     >         I'm not sure when the FITS standard changed, but MOST legacy
>     >         fits files (I use)
>     >         will have the RADECSYS keyword. It works, and I do not see why
>     >         someone felt the
>     >         need to keep this warning being popped up all the time.
>     >
>     >
>     >     Probably as a warning to remind authors of new files that they
>     >     shouldn't be using that keyword.  I don't know that it necessarily
>     >     needs to be displayed every time reading in a WCS except maybe to
>     >     head off cases of ambiguity.  But I don't know this particular
>     issue
>     >     well enough to be sure if the warning is appropriate in all
>     cases or
>     >     not.
>     >
>     >         I think that by default it should be off.
>     >
>     >         Since you all probably think it should be there, I would
>     like to
>     >         know how to
>     >         turn it off ?  any suggestion on how to do that?
>     >
>     >
>     >     http://docs.astropy.org/en/stable/warnings.html
>     >
>     >
>     >     Erik
>     >
>     >     _______________________________________________
>     >     AstroPy mailing list
>     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
>     >     https://mail.scipy.org/mailman/listinfo/astropy
>     >
>     >
>     >
>     >
>     > --
>     >
>     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>
>     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
>     > phone +44-(0)1483 (prefix) -204927 (work)
>     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype ID: npkuin
>     > Mullard Space Science Laboratory  ? University College London  ?
>     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
>     >
>     > _______________________________________________
>     > AstroPy mailing list
>     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     > https://mail.scipy.org/mailman/listinfo/astropy
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> 
> 
> -- 
> 
> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From npkuin at gmail.com  Mon Oct  5 17:47:11 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 5 Oct 2015 22:47:11 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <5612E8E5.4020700@gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
Message-ID: <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>

That is so. You're absolutely right!  I'm so sorry! I did not catch that
one.

That is probably an error that sneeked into the FITS headers from Swift.
Perhaps its a Heasarc thing, but somehow I think its a bug.

Thank you all for  helping with this.

Paul

On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> I think there is a misunderstanding:
>
> RADECSYS is not valid
>
> RADESYS is valid
>
> (note the extra C). We are not debating that RADESYS is valid - it is -
> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
> this make sense?
>
> Cheers,
> Tom
>
> Paul Kuin wrote:
> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
> > Representations of celestial coordinates in FITS
> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079
> > the is a table defining some variables used. In particular 'a' is
> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
> > definition is RADESYSa, meaning that valid versions are either RADESYS,
> > RADESYSA, RADESYSB, ... , RADESYSZ.
> >
> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen that
> > mostly used as just EQUINOX. If the header has just one WCS block, or a
> > preferred one, that is useful to have.
> >
> > Let's see what Bill Pence says. Maybe there were some changes after all.
> >
> >
> >
> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
> wrote:
> >
> >     Hi Paul,
> >
> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
> standard,
> >     as opposed to RADESYS? (which is the currently valid keyword). If
> so, in
> >     what version of the standard?
> >
> >     Cheers,
> >     Tom
> >
> >     Paul Kuin wrote:
> >     > Actually, one of the basic tenets of FITS is to be completely
> backward
> >     > compatible, so any keyword that was valid in the past is valid
> now. So
> >     > that warning is also inaccurate. If it was standard, it still is,
> and
> >     > ever will be.
> >     >
> >     >
> >     >
> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> >     <mailto:embray at stsci.edu>
> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
> >     >
> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >     >
> >     >
> >     >
> >     >         I am getting very annoyed of the warning that keeps
> popping up
> >     >
> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> >     >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
> >     >
> >     >         I'm not sure when the FITS standard changed, but MOST
> legacy
> >     >         fits files (I use)
> >     >         will have the RADECSYS keyword. It works, and I do not see
> why
> >     >         someone felt the
> >     >         need to keep this warning being popped up all the time.
> >     >
> >     >
> >     >     Probably as a warning to remind authors of new files that they
> >     >     shouldn't be using that keyword.  I don't know that it
> necessarily
> >     >     needs to be displayed every time reading in a WCS except maybe
> to
> >     >     head off cases of ambiguity.  But I don't know this particular
> >     issue
> >     >     well enough to be sure if the warning is appropriate in all
> >     cases or
> >     >     not.
> >     >
> >     >         I think that by default it should be off.
> >     >
> >     >         Since you all probably think it should be there, I would
> >     like to
> >     >         know how to
> >     >         turn it off ?  any suggestion on how to do that?
> >     >
> >     >
> >     >     http://docs.astropy.org/en/stable/warnings.html
> >     >
> >     >
> >     >     Erik
> >     >
> >     >     _______________________________________________
> >     >     AstroPy mailing list
> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
> >     >     https://mail.scipy.org/mailman/listinfo/astropy
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     >
> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>
> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
> >     > phone +44-(0)1483 (prefix) -204927 (work)
> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype ID:
> npkuin
> >     > Mullard Space Science Laboratory  ? University College London  ?
> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
> >     >
> >     > _______________________________________________
> >     > AstroPy mailing list
> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     > https://mail.scipy.org/mailman/listinfo/astropy
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> >
> > --
> >
> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151005/9ad9d957/attachment.html>

From tim.jenness at gmail.com  Mon Oct  5 18:03:44 2015
From: tim.jenness at gmail.com (Tim Jenness)
Date: Mon, 5 Oct 2015 15:03:44 -0700
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
Message-ID: <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>

RADECSYS is a very common historic header that was used before support was
added for multiple WCS definitions in a single header. I think it was
dropped before the official paper II standard was published was was part of
the initial draft:

See e.g. http://www.adass.org/adass/proceedings/adass99/P1-29/

-- 
Tim Jenness

On Mon, Oct 5, 2015 at 2:47 PM, Paul Kuin <npkuin at gmail.com> wrote:

> That is so. You're absolutely right!  I'm so sorry! I did not catch that
> one.
>
> That is probably an error that sneeked into the FITS headers from Swift.
> Perhaps its a Heasarc thing, but somehow I think its a bug.
>
> Thank you all for  helping with this.
>
> Paul
>
> On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille <
> thomas.robitaille at gmail.com> wrote:
>
>> I think there is a misunderstanding:
>>
>> RADECSYS is not valid
>>
>> RADESYS is valid
>>
>> (note the extra C). We are not debating that RADESYS is valid - it is -
>> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
>> this make sense?
>>
>> Cheers,
>> Tom
>>
>> Paul Kuin wrote:
>> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
>> > Representations of celestial coordinates in FITS
>> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079
>> > the is a table defining some variables used. In particular 'a' is
>> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
>> > definition is RADESYSa, meaning that valid versions are either RADESYS,
>> > RADESYSA, RADESYSB, ... , RADESYSZ.
>> >
>> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen that
>> > mostly used as just EQUINOX. If the header has just one WCS block, or a
>> > preferred one, that is useful to have.
>> >
>> > Let's see what Bill Pence says. Maybe there were some changes after all.
>> >
>> >
>> >
>> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
>> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
>> wrote:
>> >
>> >     Hi Paul,
>> >
>> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
>> standard,
>> >     as opposed to RADESYS? (which is the currently valid keyword). If
>> so, in
>> >     what version of the standard?
>> >
>> >     Cheers,
>> >     Tom
>> >
>> >     Paul Kuin wrote:
>> >     > Actually, one of the basic tenets of FITS is to be completely
>> backward
>> >     > compatible, so any keyword that was valid in the past is valid
>> now. So
>> >     > that warning is also inaccurate. If it was standard, it still is,
>> and
>> >     > ever will be.
>> >     >
>> >     >
>> >     >
>> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
>> >     <mailto:embray at stsci.edu>
>> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
>> >     >
>> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
>> >     >
>> >     >
>> >     >
>> >     >         I am getting very annoyed of the warning that keeps
>> popping up
>> >     >
>> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>> >     >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
>> >     >
>> >     >         I'm not sure when the FITS standard changed, but MOST
>> legacy
>> >     >         fits files (I use)
>> >     >         will have the RADECSYS keyword. It works, and I do not
>> see why
>> >     >         someone felt the
>> >     >         need to keep this warning being popped up all the time.
>> >     >
>> >     >
>> >     >     Probably as a warning to remind authors of new files that they
>> >     >     shouldn't be using that keyword.  I don't know that it
>> necessarily
>> >     >     needs to be displayed every time reading in a WCS except
>> maybe to
>> >     >     head off cases of ambiguity.  But I don't know this particular
>> >     issue
>> >     >     well enough to be sure if the warning is appropriate in all
>> >     cases or
>> >     >     not.
>> >     >
>> >     >         I think that by default it should be off.
>> >     >
>> >     >         Since you all probably think it should be there, I would
>> >     like to
>> >     >         know how to
>> >     >         turn it off ?  any suggestion on how to do that?
>> >     >
>> >     >
>> >     >     http://docs.astropy.org/en/stable/warnings.html
>> >     >
>> >     >
>> >     >     Erik
>> >     >
>> >     >     _______________________________________________
>> >     >     AstroPy mailing list
>> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
>> >     >     https://mail.scipy.org/mailman/listinfo/astropy
>> >     >
>> >     >
>> >     >
>> >     >
>> >     > --
>> >     >
>> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>
>> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
>> >     > phone +44-(0)1483 (prefix) -204927 (work)
>> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype ID:
>> npkuin
>> >     > Mullard Space Science Laboratory  ? University College London  ?
>> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
>> >     >
>> >     > _______________________________________________
>> >     > AstroPy mailing list
>> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >     > https://mail.scipy.org/mailman/listinfo/astropy
>> >     _______________________________________________
>> >     AstroPy mailing list
>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >     https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> >
>> >
>> > --
>> >
>> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > https://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
>
> * * * * * * * * 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.
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151005/313dacb2/attachment.html>

From embray at stsci.edu  Mon Oct  5 18:06:56 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 5 Oct 2015 18:06:56 -0400
Subject: [AstroPy] [ANN] Astropy v1.0.5 released
Message-ID: <5612F480.5080504@stsci.edu>

Hi all,

It's my pleasure to announce Astropy v1.0.5, the latest bug fix
release to the v1.0 series.

This release is somewhat significant compared to other bug fix
releases, in that it also includes the necessary fixes to support the
recently released Python 3.5.  This also includes fixes to better
support IPython 4.0 / Jupyter 1.0, and to the test suite so that it
runs on py.test >= 2.7.

This includes a number of other miscellaneous bug fixes, the full list
of which can be read in the changelog:

https://github.com/astropy/astropy/blob/v1.0.5/CHANGES.rst#105-2015-10-05

It can be downloaded from PyPI at:
https://pypi.python.org/pypi/astropy/1.0.5, using pip as usual.
Packages for conda will be available shortly as well.

Thanks to everyone who contributed fixes, and also who were patient
with me while I struggled to resolve numerous build issues that held
up this release.

Erik B.


(P.S. Although the changelog contains a section for bug fixes to
astropy.wcs, this is just an accidental artifact.  There were no
specific fixes to astropy.wcs in this release.)


From npkuin at gmail.com  Tue Oct  6 03:15:36 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Tue, 6 Oct 2015 08:15:36 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
Message-ID: <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>

It seems that WCS RADECSYS was not dropped then; it just ended up in the
standard in a different way. Probably to preserve backward compatibility to
old FITS files. It did throw me off, with just one letter difference!  I
think there must be some  old software that is still being used to create
fits files that do use RADECSYS.   I was using it (not bothering to check
the standard all the time, - yes bad!) and I suspect that Swift UVOT
software uses it (which is built on the HEASARC FTOOLS - so that might use
it also).  I'll bring it up in the UVOT group, but with the kind of very
limited software support that is left after 10 years of Swift mission, it
might not be possible to make the changes.

To get back to my original issue. I think this means the WCS keywords are a
historical set that is still supported, but non-standard.  I also think
that getting a warning each time a file is opened is wrong.

In my software I'd like to disable that warning.  I guess I'll need to have
a good look at the error handling in Astropy as I have somewhere another
warning pop up with loads of verbage, opening an ascii file. It actually
worked, just is very loud.   I hope there is a way to get a different
 response for errors and warnings  to be used during testing and actual
use.

Thanks again for all the responses.

   Paul Kuin



On Mon, Oct 5, 2015 at 11:03 PM, Tim Jenness <tim.jenness at gmail.com> wrote:

> RADECSYS is a very common historic header that was used before support was
> added for multiple WCS definitions in a single header. I think it was
> dropped before the official paper II standard was published was was part of
> the initial draft:
>
> See e.g. http://www.adass.org/adass/proceedings/adass99/P1-29/
>
> --
> Tim Jenness
>
> On Mon, Oct 5, 2015 at 2:47 PM, Paul Kuin <npkuin at gmail.com> wrote:
>
>> That is so. You're absolutely right!  I'm so sorry! I did not catch that
>> one.
>>
>> That is probably an error that sneeked into the FITS headers from Swift.
>> Perhaps its a Heasarc thing, but somehow I think its a bug.
>>
>> Thank you all for  helping with this.
>>
>> Paul
>>
>> On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille <
>> thomas.robitaille at gmail.com> wrote:
>>
>>> I think there is a misunderstanding:
>>>
>>> RADECSYS is not valid
>>>
>>> RADESYS is valid
>>>
>>> (note the extra C). We are not debating that RADESYS is valid - it is -
>>> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
>>> this make sense?
>>>
>>> Cheers,
>>> Tom
>>>
>>> Paul Kuin wrote:
>>> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
>>> > Representations of celestial coordinates in FITS
>>> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079
>>> > the is a table defining some variables used. In particular 'a' is
>>> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
>>> > definition is RADESYSa, meaning that valid versions are either RADESYS,
>>> > RADESYSA, RADESYSB, ... , RADESYSZ.
>>> >
>>> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen that
>>> > mostly used as just EQUINOX. If the header has just one WCS block, or a
>>> > preferred one, that is useful to have.
>>> >
>>> > Let's see what Bill Pence says. Maybe there were some changes after
>>> all.
>>> >
>>> >
>>> >
>>> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
>>> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
>>> wrote:
>>> >
>>> >     Hi Paul,
>>> >
>>> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
>>> standard,
>>> >     as opposed to RADESYS? (which is the currently valid keyword). If
>>> so, in
>>> >     what version of the standard?
>>> >
>>> >     Cheers,
>>> >     Tom
>>> >
>>> >     Paul Kuin wrote:
>>> >     > Actually, one of the basic tenets of FITS is to be completely
>>> backward
>>> >     > compatible, so any keyword that was valid in the past is valid
>>> now. So
>>> >     > that warning is also inaccurate. If it was standard, it still
>>> is, and
>>> >     > ever will be.
>>> >     >
>>> >     >
>>> >     >
>>> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
>>> >     <mailto:embray at stsci.edu>
>>> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
>>> >     >
>>> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
>>> >     >
>>> >     >
>>> >     >
>>> >     >         I am getting very annoyed of the warning that keeps
>>> popping up
>>> >     >
>>> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>>> >     >         RADECSYS is non-standard, use RADESYSa. [astropy.wcs.wcs]
>>> >     >
>>> >     >         I'm not sure when the FITS standard changed, but MOST
>>> legacy
>>> >     >         fits files (I use)
>>> >     >         will have the RADECSYS keyword. It works, and I do not
>>> see why
>>> >     >         someone felt the
>>> >     >         need to keep this warning being popped up all the time.
>>> >     >
>>> >     >
>>> >     >     Probably as a warning to remind authors of new files that
>>> they
>>> >     >     shouldn't be using that keyword.  I don't know that it
>>> necessarily
>>> >     >     needs to be displayed every time reading in a WCS except
>>> maybe to
>>> >     >     head off cases of ambiguity.  But I don't know this
>>> particular
>>> >     issue
>>> >     >     well enough to be sure if the warning is appropriate in all
>>> >     cases or
>>> >     >     not.
>>> >     >
>>> >     >         I think that by default it should be off.
>>> >     >
>>> >     >         Since you all probably think it should be there, I would
>>> >     like to
>>> >     >         know how to
>>> >     >         turn it off ?  any suggestion on how to do that?
>>> >     >
>>> >     >
>>> >     >     http://docs.astropy.org/en/stable/warnings.html
>>> >     >
>>> >     >
>>> >     >     Erik
>>> >     >
>>> >     >     _______________________________________________
>>> >     >     AstroPy mailing list
>>> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
>>> >     >     https://mail.scipy.org/mailman/listinfo/astropy
>>> >     >
>>> >     >
>>> >     >
>>> >     >
>>> >     > --
>>> >     >
>>> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>>> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>
>>> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
>>> >     > phone +44-(0)1483 (prefix) -204927 (work)
>>> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype ID:
>>> npkuin
>>> >     > Mullard Space Science Laboratory  ? University College London  ?
>>> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
>>> >     >
>>> >     > _______________________________________________
>>> >     > AstroPy mailing list
>>> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >     > https://mail.scipy.org/mailman/listinfo/astropy
>>> >     _______________________________________________
>>> >     AstroPy mailing list
>>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >     https://mail.scipy.org/mailman/listinfo/astropy
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>>> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
>>> >
>>> > _______________________________________________
>>> > AstroPy mailing list
>>> > AstroPy at scipy.org
>>> > https://mail.scipy.org/mailman/listinfo/astropy
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>>
>> --
>>
>> * * * * * * * * 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.
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 

* * * * * * * * 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/20151006/e7b4f551/attachment.html>

From thomas.robitaille at gmail.com  Tue Oct  6 08:15:30 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 6 Oct 2015 14:15:30 +0200
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
 <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
Message-ID: <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>

Hi Paul,

As far as I'm aware, the error shouldn't be happening when you open
the file, but when you pass the header to the WCS class from
astropy.wcs. I think you can get rid of the warnings by simply doing

wcs = WCS(header, fix=False)

See http://docs.astropy.org/en/stable/api/astropy.wcs.WCS.html#astropy.wcs.WCS

Cheers,
Tom

On 6 October 2015 at 09:15, Paul Kuin <npkuin at gmail.com> wrote:
> It seems that WCS RADECSYS was not dropped then; it just ended up in the
> standard in a different way. Probably to preserve backward compatibility to
> old FITS files. It did throw me off, with just one letter difference!  I
> think there must be some  old software that is still being used to create
> fits files that do use RADECSYS.   I was using it (not bothering to check
> the standard all the time, - yes bad!) and I suspect that Swift UVOT
> software uses it (which is built on the HEASARC FTOOLS - so that might use
> it also).  I'll bring it up in the UVOT group, but with the kind of very
> limited software support that is left after 10 years of Swift mission, it
> might not be possible to make the changes.
>
> To get back to my original issue. I think this means the WCS keywords are a
> historical set that is still supported, but non-standard.  I also think that
> getting a warning each time a file is opened is wrong.
>
> In my software I'd like to disable that warning.  I guess I'll need to have
> a good look at the error handling in Astropy as I have somewhere another
> warning pop up with loads of verbage, opening an ascii file. It actually
> worked, just is very loud.   I hope there is a way to get a different
> response for errors and warnings  to be used during testing and actual use.
>
> Thanks again for all the responses.
>
>    Paul Kuin
>
>
>
> On Mon, Oct 5, 2015 at 11:03 PM, Tim Jenness <tim.jenness at gmail.com> wrote:
>>
>> RADECSYS is a very common historic header that was used before support was
>> added for multiple WCS definitions in a single header. I think it was
>> dropped before the official paper II standard was published was was part of
>> the initial draft:
>>
>> See e.g. http://www.adass.org/adass/proceedings/adass99/P1-29/
>>
>> --
>> Tim Jenness
>>
>> On Mon, Oct 5, 2015 at 2:47 PM, Paul Kuin <npkuin at gmail.com> wrote:
>>>
>>> That is so. You're absolutely right!  I'm so sorry! I did not catch that
>>> one.
>>>
>>> That is probably an error that sneeked into the FITS headers from Swift.
>>> Perhaps its a Heasarc thing, but somehow I think its a bug.
>>>
>>> Thank you all for  helping with this.
>>>
>>> Paul
>>>
>>> On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille
>>> <thomas.robitaille at gmail.com> wrote:
>>>>
>>>> I think there is a misunderstanding:
>>>>
>>>> RADECSYS is not valid
>>>>
>>>> RADESYS is valid
>>>>
>>>> (note the extra C). We are not debating that RADESYS is valid - it is -
>>>> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
>>>> this make sense?
>>>>
>>>> Cheers,
>>>> Tom
>>>>
>>>> Paul Kuin wrote:
>>>> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
>>>> > Representations of celestial coordinates in FITS
>>>> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page 1079
>>>> > the is a table defining some variables used. In particular 'a' is
>>>> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
>>>> > definition is RADESYSa, meaning that valid versions are either
>>>> > RADESYS,
>>>> > RADESYSA, RADESYSB, ... , RADESYSZ.
>>>> >
>>>> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen
>>>> > that
>>>> > mostly used as just EQUINOX. If the header has just one WCS block, or
>>>> > a
>>>> > preferred one, that is useful to have.
>>>> >
>>>> > Let's see what Bill Pence says. Maybe there were some changes after
>>>> > all.
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
>>>> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
>>>> > wrote:
>>>> >
>>>> >     Hi Paul,
>>>> >
>>>> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
>>>> > standard,
>>>> >     as opposed to RADESYS? (which is the currently valid keyword). If
>>>> > so, in
>>>> >     what version of the standard?
>>>> >
>>>> >     Cheers,
>>>> >     Tom
>>>> >
>>>> >     Paul Kuin wrote:
>>>> >     > Actually, one of the basic tenets of FITS is to be completely
>>>> > backward
>>>> >     > compatible, so any keyword that was valid in the past is valid
>>>> > now. So
>>>> >     > that warning is also inaccurate. If it was standard, it still
>>>> > is, and
>>>> >     > ever will be.
>>>> >     >
>>>> >     >
>>>> >     >
>>>> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
>>>> >     <mailto:embray at stsci.edu>
>>>> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
>>>> >     >
>>>> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
>>>> >     >
>>>> >     >
>>>> >     >
>>>> >     >         I am getting very annoyed of the warning that keeps
>>>> > popping up
>>>> >     >
>>>> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
>>>> >     >         RADECSYS is non-standard, use RADESYSa.
>>>> > [astropy.wcs.wcs]
>>>> >     >
>>>> >     >         I'm not sure when the FITS standard changed, but MOST
>>>> > legacy
>>>> >     >         fits files (I use)
>>>> >     >         will have the RADECSYS keyword. It works, and I do not
>>>> > see why
>>>> >     >         someone felt the
>>>> >     >         need to keep this warning being popped up all the time.
>>>> >     >
>>>> >     >
>>>> >     >     Probably as a warning to remind authors of new files that
>>>> > they
>>>> >     >     shouldn't be using that keyword.  I don't know that it
>>>> > necessarily
>>>> >     >     needs to be displayed every time reading in a WCS except
>>>> > maybe to
>>>> >     >     head off cases of ambiguity.  But I don't know this
>>>> > particular
>>>> >     issue
>>>> >     >     well enough to be sure if the warning is appropriate in all
>>>> >     cases or
>>>> >     >     not.
>>>> >     >
>>>> >     >         I think that by default it should be off.
>>>> >     >
>>>> >     >         Since you all probably think it should be there, I would
>>>> >     like to
>>>> >     >         know how to
>>>> >     >         turn it off ?  any suggestion on how to do that?
>>>> >     >
>>>> >     >
>>>> >     >     http://docs.astropy.org/en/stable/warnings.html
>>>> >     >
>>>> >     >
>>>> >     >     Erik
>>>> >     >
>>>> >     >     _______________________________________________
>>>> >     >     AstroPy mailing list
>>>> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
>>>> >     >     https://mail.scipy.org/mailman/listinfo/astropy
>>>> >     >
>>>> >     >
>>>> >     >
>>>> >     >
>>>> >     > --
>>>> >     >
>>>> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>>>> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>
>>>> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
>>>> >     > phone +44-(0)1483 (prefix) -204927 (work)
>>>> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype ID:
>>>> > npkuin
>>>> >     > Mullard Space Science Laboratory  ? University College London  ?
>>>> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
>>>> >     >
>>>> >     > _______________________________________________
>>>> >     > AstroPy mailing list
>>>> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>> >     > https://mail.scipy.org/mailman/listinfo/astropy
>>>> >     _______________________________________________
>>>> >     AstroPy mailing list
>>>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>> >     https://mail.scipy.org/mailman/listinfo/astropy
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>>>> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
>>>> >
>>>> > _______________________________________________
>>>> > AstroPy mailing list
>>>> > AstroPy at scipy.org
>>>> > https://mail.scipy.org/mailman/listinfo/astropy
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>>
>>>
>>> --
>>>
>>> * * * * * * * * 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.
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
>
> * * * * * * * * 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.
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From embray at stsci.edu  Tue Oct  6 10:59:59 2015
From: embray at stsci.edu (Erik Bray)
Date: Tue, 6 Oct 2015 10:59:59 -0400
Subject: [AstroPy] Python powered GUI for secondary school education
 image processing and possible porting to Tablets and Smart Phones
In-Reply-To: <7FA589B3-46EF-450E-92C0-3D220C0040BB@mnstate.edu>
References: <560F08AE.1090809@lbl.gov>
 <8D10CC84-A73B-4921-AA40-0983C985A5E9@mnstate.edu>
 <7FA589B3-46EF-450E-92C0-3D220C0040BB@mnstate.edu>
Message-ID: <5613E1EF.8080404@stsci.edu>

On 10/02/2015 10:43 PM, Matthew Craig wrote:
> Hi again,
>
> A couple other projects that are python-based but use non-web backends (like I
> said in my original reply, I?m biased :)) that were mentioned off list but might
> be of interest to others are:
>
> + ginga, main contact is Eric Jeschke, screenshots at
> http://ejeschke.github.io/ginga/? ginger is a QT-based toolkit that also comes
> with a basic image browser, though that basic browser is intended as a
> demonstration of capabilities.

I was going to bring up ginga as well.  Something worth emphasizing about ginga 
is that it's more than just an DS9-alike image viewer, but also a framework for 
making one's own tools.  Its core is an image viewer GUI, but it has a nice 
plugin interface for building one's own tools around the core GUI.  So even if 
it doesn't do everything you need it to out of the box it's pretty extensible.

>>> On Oct 2, 2015, at 5:43 PM, Carl Pennypacker <crpennypacker at lbl.gov
>>> <mailto:crpennypacker at lbl.gov>> wrote:
>>> Finally, has anyone tried to compile such a python GUI or other
>>> python routines onto Androids or Apple
>>> tablets?  One the web, I see a number of systems that claim they
>>> can take Python code and make it work on smart phones, without
>>> having to learn Android or Iphone language..

I've had some experience in the past (it's been a couple years) with 
python-for-android: https://github.com/kivy/python-for-android

Depending on what you're trying to do and how complicated it is one may still 
have to dig in to some Android code (though if you get a build toolchain working 
you can get students adding Python code with relative ease.  But my experience 
has been that building stuff for Android is still not as easy as one would 
hope...  python-for-android is also centered around supporting pygame and 
pysdl2, as opposed to "traditional" desktop GUIs (which of course don't 
translate over well to smartphones anyhow).

Erik


From npkuin at gmail.com  Tue Oct  6 11:20:24 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Tue, 6 Oct 2015 16:20:24 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
 <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
 <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
Message-ID: <CANoQ6N0s4xSRQADFAue8DJSSt7Wb3xp+YumVBXQSXpv51wi+LQ@mail.gmail.com>

Hi Tom,

Correct. I did first read then pass the header to WCS.

The way I interpret the parameter fix-False description, it seems like the
WCS header with the warning is that it will fail ? I'll give it a try
later.

Thanks, Paul

On Tue, Oct 6, 2015 at 1:15 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Paul,
>
> As far as I'm aware, the error shouldn't be happening when you open
> the file, but when you pass the header to the WCS class from
> astropy.wcs. I think you can get rid of the warnings by simply doing
>
> wcs = WCS(header, fix=False)
>
> See
> http://docs.astropy.org/en/stable/api/astropy.wcs.WCS.html#astropy.wcs.WCS
>
> Cheers,
> Tom
>
> On 6 October 2015 at 09:15, Paul Kuin <npkuin at gmail.com> wrote:
> > It seems that WCS RADECSYS was not dropped then; it just ended up in the
> > standard in a different way. Probably to preserve backward compatibility
> to
> > old FITS files. It did throw me off, with just one letter difference!  I
> > think there must be some  old software that is still being used to create
> > fits files that do use RADECSYS.   I was using it (not bothering to check
> > the standard all the time, - yes bad!) and I suspect that Swift UVOT
> > software uses it (which is built on the HEASARC FTOOLS - so that might
> use
> > it also).  I'll bring it up in the UVOT group, but with the kind of very
> > limited software support that is left after 10 years of Swift mission, it
> > might not be possible to make the changes.
> >
> > To get back to my original issue. I think this means the WCS keywords
> are a
> > historical set that is still supported, but non-standard.  I also think
> that
> > getting a warning each time a file is opened is wrong.
> >
> > In my software I'd like to disable that warning.  I guess I'll need to
> have
> > a good look at the error handling in Astropy as I have somewhere another
> > warning pop up with loads of verbage, opening an ascii file. It actually
> > worked, just is very loud.   I hope there is a way to get a different
> > response for errors and warnings  to be used during testing and actual
> use.
> >
> > Thanks again for all the responses.
> >
> >    Paul Kuin
> >
> >
> >
> > On Mon, Oct 5, 2015 at 11:03 PM, Tim Jenness <tim.jenness at gmail.com>
> wrote:
> >>
> >> RADECSYS is a very common historic header that was used before support
> was
> >> added for multiple WCS definitions in a single header. I think it was
> >> dropped before the official paper II standard was published was was
> part of
> >> the initial draft:
> >>
> >> See e.g. http://www.adass.org/adass/proceedings/adass99/P1-29/
> >>
> >> --
> >> Tim Jenness
> >>
> >> On Mon, Oct 5, 2015 at 2:47 PM, Paul Kuin <npkuin at gmail.com> wrote:
> >>>
> >>> That is so. You're absolutely right!  I'm so sorry! I did not catch
> that
> >>> one.
> >>>
> >>> That is probably an error that sneeked into the FITS headers from
> Swift.
> >>> Perhaps its a Heasarc thing, but somehow I think its a bug.
> >>>
> >>> Thank you all for  helping with this.
> >>>
> >>> Paul
> >>>
> >>> On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille
> >>> <thomas.robitaille at gmail.com> wrote:
> >>>>
> >>>> I think there is a misunderstanding:
> >>>>
> >>>> RADECSYS is not valid
> >>>>
> >>>> RADESYS is valid
> >>>>
> >>>> (note the extra C). We are not debating that RADESYS is valid - it is
> -
> >>>> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
> >>>> this make sense?
> >>>>
> >>>> Cheers,
> >>>> Tom
> >>>>
> >>>> Paul Kuin wrote:
> >>>> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
> >>>> > Representations of celestial coordinates in FITS
> >>>> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page
> 1079
> >>>> > the is a table defining some variables used. In particular 'a' is
> >>>> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
> >>>> > definition is RADESYSa, meaning that valid versions are either
> >>>> > RADESYS,
> >>>> > RADESYSA, RADESYSB, ... , RADESYSZ.
> >>>> >
> >>>> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen
> >>>> > that
> >>>> > mostly used as just EQUINOX. If the header has just one WCS block,
> or
> >>>> > a
> >>>> > preferred one, that is useful to have.
> >>>> >
> >>>> > Let's see what Bill Pence says. Maybe there were some changes after
> >>>> > all.
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
> >>>> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
> >>>> > wrote:
> >>>> >
> >>>> >     Hi Paul,
> >>>> >
> >>>> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
> >>>> > standard,
> >>>> >     as opposed to RADESYS? (which is the currently valid keyword).
> If
> >>>> > so, in
> >>>> >     what version of the standard?
> >>>> >
> >>>> >     Cheers,
> >>>> >     Tom
> >>>> >
> >>>> >     Paul Kuin wrote:
> >>>> >     > Actually, one of the basic tenets of FITS is to be completely
> >>>> > backward
> >>>> >     > compatible, so any keyword that was valid in the past is valid
> >>>> > now. So
> >>>> >     > that warning is also inaccurate. If it was standard, it still
> >>>> > is, and
> >>>> >     > ever will be.
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> >>>> >     <mailto:embray at stsci.edu>
> >>>> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
> >>>> >     >
> >>>> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     >         I am getting very annoyed of the warning that keeps
> >>>> > popping up
> >>>> >     >
> >>>> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> >>>> >     >         RADECSYS is non-standard, use RADESYSa.
> >>>> > [astropy.wcs.wcs]
> >>>> >     >
> >>>> >     >         I'm not sure when the FITS standard changed, but MOST
> >>>> > legacy
> >>>> >     >         fits files (I use)
> >>>> >     >         will have the RADECSYS keyword. It works, and I do not
> >>>> > see why
> >>>> >     >         someone felt the
> >>>> >     >         need to keep this warning being popped up all the
> time.
> >>>> >     >
> >>>> >     >
> >>>> >     >     Probably as a warning to remind authors of new files that
> >>>> > they
> >>>> >     >     shouldn't be using that keyword.  I don't know that it
> >>>> > necessarily
> >>>> >     >     needs to be displayed every time reading in a WCS except
> >>>> > maybe to
> >>>> >     >     head off cases of ambiguity.  But I don't know this
> >>>> > particular
> >>>> >     issue
> >>>> >     >     well enough to be sure if the warning is appropriate in
> all
> >>>> >     cases or
> >>>> >     >     not.
> >>>> >     >
> >>>> >     >         I think that by default it should be off.
> >>>> >     >
> >>>> >     >         Since you all probably think it should be there, I
> would
> >>>> >     like to
> >>>> >     >         know how to
> >>>> >     >         turn it off ?  any suggestion on how to do that?
> >>>> >     >
> >>>> >     >
> >>>> >     >     http://docs.astropy.org/en/stable/warnings.html
> >>>> >     >
> >>>> >     >
> >>>> >     >     Erik
> >>>> >     >
> >>>> >     >     _______________________________________________
> >>>> >     >     AstroPy mailing list
> >>>> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
> >>>> >     >     https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     > --
> >>>> >     >
> >>>> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> >>>> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:
> n.kuin at ucl.ac.uk>
> >>>> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
> >>>> >     > phone +44-(0)1483 (prefix) -204927 (work)
> >>>> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype
> ID:
> >>>> > npkuin
> >>>> >     > Mullard Space Science Laboratory  ? University College
> London  ?
> >>>> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
> >>>> >     >
> >>>> >     > _______________________________________________
> >>>> >     > AstroPy mailing list
> >>>> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     > https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >     _______________________________________________
> >>>> >     AstroPy mailing list
> >>>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> >
> >>>> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> >>>> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> >>>> >
> >>>> > _______________________________________________
> >>>> > AstroPy mailing list
> >>>> > AstroPy at scipy.org
> >>>> > https://mail.scipy.org/mailman/listinfo/astropy
> >>>> _______________________________________________
> >>>> AstroPy mailing list
> >>>> AstroPy at scipy.org
> >>>> https://mail.scipy.org/mailman/listinfo/astropy
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> * * * * * * * * 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.
> >>>
> >>> _______________________________________________
> >>> AstroPy mailing list
> >>> AstroPy at scipy.org
> >>> https://mail.scipy.org/mailman/listinfo/astropy
> >>>
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >>
> >
> >
> >
> > --
> >
> > * * * * * * * * 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.
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151006/bf7b9648/attachment.html>

From thomas.robitaille at gmail.com  Thu Oct  8 03:18:11 2015
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 8 Oct 2015 09:18:11 +0200
Subject: [AstroPy] Apply now for the Python in Astronomy 2016
 conference! (21-25th March 2016)
In-Reply-To: <CAGMHX_2FnQngA-6V1eUeh0AXZPCZKJEZuY_CbvduEEP4khMSCA@mail.gmail.com>
References: <CAGMHX_2FnQngA-6V1eUeh0AXZPCZKJEZuY_CbvduEEP4khMSCA@mail.gmail.com>
Message-ID: <CAGMHX_35Rdf0gHWFBsBjKhQ3PpQLeNN2kfAENyrG+AbA4HOiMQ@mail.gmail.com>

Hi everyone,

Just a reminder that the deadline to apply to attend Python in
Astronomy 2016 is tomorrow! (see below for more details)

Cheers,
Tom


On 9 September 2015 at 16:16, Thomas Robitaille
<thomas.robitaille at gmail.com> wrote:
> Dear colleagues,
>
> We are very pleased to inform you that applications are now open for
> the Python in Astronomy 2016 conference:
>
>    Python in Astronomy
>    University of Washington eScience Institute
>    Seattle, WA, USA
>    21-25th March 2016
>    http://python-in-astronomy.github.io/2016/
>
> This meeting aims to bring together researchers, Python developers,
> users, and educators, and will include presentations, tutorials,
> unconference sessions, and coding sprints.
>
> In addition to sharing information about state-of-the-art Python
> Astronomy packages, the workshop will also focus on improving
> interoperability between astronomical Python packages, providing
> training for new contributors, and developing educational materials
> for Python in Astronomy. The meeting is therefore aimed not only at
> current developers, but also users and educators who are interested in
> being involved in these efforts.
>
> Note that this meeting is not intended to be a Python 'boot camp', and
> we do expect participants to have already at least used Python for
> some of their projects, even if only at a beginner level.
>
> To apply, please go to the following page:
>
>  http://python-in-astronomy.github.io/2016/
>
> and follow the link to the application form. Applications should be
> submitted by 9th October 2015 at the latest, and we hope to let you
> know by mid- to late November whether you have been accepted.
>
> Contingent on sponsorship, we hope to offer financial support for
> travel for a few participants. If you would like to apply for
> financial support, please indicate this in the last section of the
> application form.
>
> Please forward this email to anyone who may be interested!
>
> Best regards,
>
> The organizing committee:
>
> Kelle Cruz
> Perry Greenfield
> Eric Jeschke
> Mario Juric
> Stuart Mumford
> Chanda Prescod-Weinstein
> Thomas Robitaille
> Megan Sosey
> Erik Tollerud
> Jake Vanderplas


From archibald at astron.nl  Thu Oct  8 17:05:32 2015
From: archibald at astron.nl (Anne Archibald)
Date: Thu, 08 Oct 2015 21:05:32 +0000
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
Message-ID: <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>

Hi Kyle,

I am very interested in nestle as an alternative MCMC method for a project
I'm working on (testing general relativity with pulsar timing observations
of a triple system; see http://adsabs.harvard.edu/abs/2014Natur.505..520R for
more). I was considering multinest but the ability to get "under the hood"
is really valuable. I have several concerns with using the code; maybe you
have the experience to point me in the right direction.

The first concern is that my likelihood function is really slow (seconds).
I have access to many cores, but each evaluation can only use one. So I'd
like to enlist some parallelism in the MCMC algorithm. As written, nestle
is purely sequential, but I can see several places parallelism is
available. The first and easiest is when picking a new point to replace the
worst: if this takes many tries, you could speculatively evaluate the
function at many new candidate points and take the first acceptable one.
Multinest is able to do this, and I can see how one might add it to the
code here. The second possibility is suggested by your "update_interval"
parameter. Until the family of ellipsoids is updated, all new points are
being generated from the same distribution, so the evaluation of their
likelihoods can be carried out in parallel. This guarantees at least a
factor update_interval worth of parallelism, which might be worth it even
for expensive likelihood evaluations. Implementation would maintain a list
of N (~ number of cores) Futures representing evaluations drawn from the
current set of ellipsoids; every time the code needs a new point it waits
for the first Future to finish and gets the coordinates and log-likelihood
from that, then creates another Future for later. When the ellipsoids need
to be changed, all unused Futures can be cancelled. The result should be
statistically identical to the current algorithm, though it sometimes uses
extra RNG calls, so the actual call sequence won't be the same (and will
depend on N but nothing else).

The second concern is that I'm worried my problem is going to take forever
with nested sampling. It's a somewhat high-dimensional problem - 20-30
parameters - and the change in parameter volume from prior to posterior is
staggering: while the prior is a bit fuzzy, our knowledge of (say) the
inner orbital period goes from "about 1.6 days" to "1.629401788(5) days";
many other parameters are similarly constrained. Since nested sampling
relies on gradually shrinking ellipses from the entire space down to the
target region, I worry that it will take a very large number of steps (if
the ellipse's volume shrinks by a factor 1.2 each time, that's ~3000
steps). This appears worryingly supported by a numerical experiment I am
running with a fast likelihood function that nevertheless puts very tight
constraints on the result.

The third concern is about covariances. Of course ellipses are intended to
enclose potentially very skinny error regions, but I ran into problems
where my error region was so narrow that representing it with a covariance
matrix ran into matrix numerical headaches. I have analytically
marginalized out the worst offenders, but even the simple problem that my
parameters can be constrained on very different scales - a sin i is known
about a thousand times better than a cos i - can wreck matrix algorithms. I
guess I have to try this and see whether problems arise.

Currently I am working with emcee, which has its drawbacks, but can use
parallelism (to evaluate likelihoods for many walkers at once) and is
fairly robust against covariances (the point coordinates themselves are
used to generate candidates as linear combinations). But since I'm trying
to test a hypothesis - GR is better than not-GR - it sure would be nice to
use a tool that supports hypothesis testing!

Thanks,
Anne

On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com> wrote:

> Yes, possibly! Nestle currently implements the basic MultiNest method, but
> doesn't implement later improvements such as importance reweighting or
> polychord. I'm open to contributions and improvements. (But be mindful of
> reading the MultiNest source code due to licensing issues!)
>
> Best,
> -- Kyle
>
> On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi <
> johann.cohentanugi at gmail.com> wrote:
>
>> likewise!
>> Any prospect toward the polychord extension? See
>> http://arxiv.org/abs/1506.00171v1
>> cheers,
>> Johann
>>
>>
>> On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>>
>> HI Kyle,
>>
>> Very nice. I'll definitely have a look at that.
>>
>> Cheers,
>>    Wolfgang
>> --
>> Dr. Wolfgang E Kerzendorf
>> ESO Fellow
>> European Southern Observatory
>> Karl-Schwarzschild Str. 2, 85748
>> Garching bei Muenchen, Germany
>>
>> On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary < <kylebarbary at gmail.com>
>> kylebarbary at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm pleased to announce the initial release of Nestle, a small Python
>>> package for nested sampling. ("Nestle" rhymes with "wrestle".) Nested
>>> sampling is a statistical technique for parameter estimation and model
>>> comparison, commonly used in cosmology. We've been using it in the sncosmo
>>> package and have found it to be a robust global optimizer in addition to
>>> its more typically cited benefits.
>>>
>>> Nestle implements an algorithm similar to that used in the MultiNest
>>> software, but in an open-source (MIT) licensed and easy-to-install (pure
>>> Python) package. (It was written based only on the literature, not the
>>> MultiNest source code.) In addition to this algorithm, Nestle also
>>> implements the "classic" nested sampling algorithm and the "single
>>> ellipsoid" algorithm.
>>>
>>> Nestle depends on only numpy and (optionally) scipy and supports both
>>> Python 3 and Legacy Python (formerly known as Python 2).
>>>
>>> docs:  <http://kbarbary.github.io/nestle>
>>> http://kbarbary.github.io/nestle
>>> source:  <http://github.com/kbarbary/nestle>
>>> http://github.com/kbarbary/nestle
>>>
>>> I'd appreciate any feedback on this initial release, particularly about
>>> application to real-world problems and comparisons with results from
>>> MultiNest. Thanks!
>>>
>>> - Kyle
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>> _______________________________________________
>> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151008/95f484d2/attachment.html>

From kylebarbary at gmail.com  Fri Oct  9 02:45:17 2015
From: kylebarbary at gmail.com (Kyle Barbary)
Date: Thu, 8 Oct 2015 23:45:17 -0700
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
 <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
Message-ID: <CANO7-x-M6HsyPBbHzY1O92mMxuKXF5duD1nRz3EfNWKjD-4gGw@mail.gmail.com>

Hi Anne,

You're absolutely right about the opportunity for parallelism and thanks
for the PR! (https://github.com/kbarbary/nestle/pull/13)

Regarding nested sampling taking forever to converge: Yes, this will
definitely be an issue for your problem: the constrained region shrinks by
a factor of exp(1 / N_points) on each iteration, which is quite small for
large N_points (and N_points should indeed be relatively large for
high-dimensional problems). As far as I'm aware, this shrinkage factor is a
general characteristic of nested sampling and I don't know a way around it.
My only advice would be to cheat a bit and use a different method, such as
optimization, to first narrow down the prior volume if possible (assuming
that most of the prior contributes negligibly to the evidence and that the
posterior does not have widely separated significant peaks).

Regarding covariances, you are probably aware of this, but just for
clarity: the ellipsoids are calculated in the unit cube corresponding to
the prior volume, rather than in real parameter space. So, to the extent
that the shrinkage ratio is the same in each dimension, the constrained
area will be spherical. Conversely, if one parameter is much more
constrained by the data than another, the ellipsoid will be quite skinny. I
would recommend trying classic nested sampling, where calculating the point
covariance isn't as integral to the method, but unfortunately the current
implementation of classic nested sampling in nestle does use the
covariance. That could be changed though.

Sorry I don't have better answers for you -- sounds like you have a tough
problem!

-- Kyle

On Thu, Oct 8, 2015 at 2:05 PM, Anne Archibald <archibald at astron.nl> wrote:

> Hi Kyle,
>
> I am very interested in nestle as an alternative MCMC method for a project
> I'm working on (testing general relativity with pulsar timing observations
> of a triple system; see http://adsabs.harvard.edu/abs/2014Natur.505..520R for
> more). I was considering multinest but the ability to get "under the hood"
> is really valuable. I have several concerns with using the code; maybe you
> have the experience to point me in the right direction.
>
> The first concern is that my likelihood function is really slow (seconds).
> I have access to many cores, but each evaluation can only use one. So I'd
> like to enlist some parallelism in the MCMC algorithm. As written, nestle
> is purely sequential, but I can see several places parallelism is
> available. The first and easiest is when picking a new point to replace the
> worst: if this takes many tries, you could speculatively evaluate the
> function at many new candidate points and take the first acceptable one.
> Multinest is able to do this, and I can see how one might add it to the
> code here. The second possibility is suggested by your "update_interval"
> parameter. Until the family of ellipsoids is updated, all new points are
> being generated from the same distribution, so the evaluation of their
> likelihoods can be carried out in parallel. This guarantees at least a
> factor update_interval worth of parallelism, which might be worth it even
> for expensive likelihood evaluations. Implementation would maintain a list
> of N (~ number of cores) Futures representing evaluations drawn from the
> current set of ellipsoids; every time the code needs a new point it waits
> for the first Future to finish and gets the coordinates and log-likelihood
> from that, then creates another Future for later. When the ellipsoids need
> to be changed, all unused Futures can be cancelled. The result should be
> statistically identical to the current algorithm, though it sometimes uses
> extra RNG calls, so the actual call sequence won't be the same (and will
> depend on N but nothing else).
>
> The second concern is that I'm worried my problem is going to take forever
> with nested sampling. It's a somewhat high-dimensional problem - 20-30
> parameters - and the change in parameter volume from prior to posterior is
> staggering: while the prior is a bit fuzzy, our knowledge of (say) the
> inner orbital period goes from "about 1.6 days" to "1.629401788(5) days";
> many other parameters are similarly constrained. Since nested sampling
> relies on gradually shrinking ellipses from the entire space down to the
> target region, I worry that it will take a very large number of steps (if
> the ellipse's volume shrinks by a factor 1.2 each time, that's ~3000
> steps). This appears worryingly supported by a numerical experiment I am
> running with a fast likelihood function that nevertheless puts very tight
> constraints on the result.
>
> The third concern is about covariances. Of course ellipses are intended to
> enclose potentially very skinny error regions, but I ran into problems
> where my error region was so narrow that representing it with a covariance
> matrix ran into matrix numerical headaches. I have analytically
> marginalized out the worst offenders, but even the simple problem that my
> parameters can be constrained on very different scales - a sin i is known
> about a thousand times better than a cos i - can wreck matrix algorithms. I
> guess I have to try this and see whether problems arise.
>
> Currently I am working with emcee, which has its drawbacks, but can use
> parallelism (to evaluate likelihoods for many walkers at once) and is
> fairly robust against covariances (the point coordinates themselves are
> used to generate candidates as linear combinations). But since I'm trying
> to test a hypothesis - GR is better than not-GR - it sure would be nice to
> use a tool that supports hypothesis testing!
>
> Thanks,
> Anne
>
> On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com>
> wrote:
>
>> Yes, possibly! Nestle currently implements the basic MultiNest method,
>> but doesn't implement later improvements such as importance reweighting or
>> polychord. I'm open to contributions and improvements. (But be mindful of
>> reading the MultiNest source code due to licensing issues!)
>>
>> Best,
>> -- Kyle
>>
>> On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi <
>> johann.cohentanugi at gmail.com> wrote:
>>
>>> likewise!
>>> Any prospect toward the polychord extension? See
>>> http://arxiv.org/abs/1506.00171v1
>>> cheers,
>>> Johann
>>>
>>>
>>> On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>>>
>>> HI Kyle,
>>>
>>> Very nice. I'll definitely have a look at that.
>>>
>>> Cheers,
>>>    Wolfgang
>>> --
>>> Dr. Wolfgang E Kerzendorf
>>> ESO Fellow
>>> European Southern Observatory
>>> Karl-Schwarzschild Str. 2, 85748
>>> Garching bei Muenchen, Germany
>>>
>>> On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary < <kylebarbary at gmail.com>
>>> kylebarbary at gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm pleased to announce the initial release of Nestle, a small Python
>>>> package for nested sampling. ("Nestle" rhymes with "wrestle".) Nested
>>>> sampling is a statistical technique for parameter estimation and model
>>>> comparison, commonly used in cosmology. We've been using it in the sncosmo
>>>> package and have found it to be a robust global optimizer in addition to
>>>> its more typically cited benefits.
>>>>
>>>> Nestle implements an algorithm similar to that used in the MultiNest
>>>> software, but in an open-source (MIT) licensed and easy-to-install (pure
>>>> Python) package. (It was written based only on the literature, not the
>>>> MultiNest source code.) In addition to this algorithm, Nestle also
>>>> implements the "classic" nested sampling algorithm and the "single
>>>> ellipsoid" algorithm.
>>>>
>>>> Nestle depends on only numpy and (optionally) scipy and supports both
>>>> Python 3 and Legacy Python (formerly known as Python 2).
>>>>
>>>> docs:  <http://kbarbary.github.io/nestle>
>>>> http://kbarbary.github.io/nestle
>>>> source:  <http://github.com/kbarbary/nestle>
>>>> http://github.com/kbarbary/nestle
>>>>
>>>> I'd appreciate any feedback on this initial release, particularly about
>>>> application to real-world problems and comparisons with results from
>>>> MultiNest. Thanks!
>>>>
>>>> - Kyle
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151008/81297646/attachment.html>

From sransom at nrao.edu  Fri Oct  9 11:58:58 2015
From: sransom at nrao.edu (Scott Ransom)
Date: Fri, 9 Oct 2015 11:58:58 -0400
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
 <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
Message-ID: <5617E442.6050301@nrao.edu>

Hey Anne,

Can you use parallel tempering MCMC to estimate the evidence for 
hypothesis testing?  Or will that work terribly badly for us given the 
dynamic range between prior to posterior?

e.g. http://dan.iel.fm/emcee/current/user/pt/

Scott

On 10/08/2015 05:05 PM, Anne Archibald wrote:
> Hi Kyle,
>
> I am very interested in nestle as an alternative MCMC method for a
> project I'm working on (testing general relativity with pulsar timing
> observations of a triple system; see
> http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
> considering multinest but the ability to get "under the hood" is really
> valuable. I have several concerns with using the code; maybe you have
> the experience to point me in the right direction.
>
> The first concern is that my likelihood function is really slow
> (seconds). I have access to many cores, but each evaluation can only use
> one. So I'd like to enlist some parallelism in the MCMC algorithm. As
> written, nestle is purely sequential, but I can see several places
> parallelism is available. The first and easiest is when picking a new
> point to replace the worst: if this takes many tries, you could
> speculatively evaluate the function at many new candidate points and
> take the first acceptable one. Multinest is able to do this, and I can
> see how one might add it to the code here. The second possibility is
> suggested by your "update_interval" parameter. Until the family of
> ellipsoids is updated, all new points are being generated from the same
> distribution, so the evaluation of their likelihoods can be carried out
> in parallel. This guarantees at least a factor update_interval worth of
> parallelism, which might be worth it even for expensive likelihood
> evaluations. Implementation would maintain a list of N (~ number of
> cores) Futures representing evaluations drawn from the current set of
> ellipsoids; every time the code needs a new point it waits for the first
> Future to finish and gets the coordinates and log-likelihood from that,
> then creates another Future for later. When the ellipsoids need to be
> changed, all unused Futures can be cancelled. The result should be
> statistically identical to the current algorithm, though it sometimes
> uses extra RNG calls, so the actual call sequence won't be the same (and
> will depend on N but nothing else).
>
> The second concern is that I'm worried my problem is going to take
> forever with nested sampling. It's a somewhat high-dimensional problem -
> 20-30 parameters - and the change in parameter volume from prior to
> posterior is staggering: while the prior is a bit fuzzy, our knowledge
> of (say) the inner orbital period goes from "about 1.6 days" to
> "1.629401788(5) days"; many other parameters are similarly constrained.
> Since nested sampling relies on gradually shrinking ellipses from the
> entire space down to the target region, I worry that it will take a very
> large number of steps (if the ellipse's volume shrinks by a factor 1.2
> each time, that's ~3000 steps). This appears worryingly supported by a
> numerical experiment I am running with a fast likelihood function that
> nevertheless puts very tight constraints on the result.
>
> The third concern is about covariances. Of course ellipses are intended
> to enclose potentially very skinny error regions, but I ran into
> problems where my error region was so narrow that representing it with a
> covariance matrix ran into matrix numerical headaches. I have
> analytically marginalized out the worst offenders, but even the simple
> problem that my parameters can be constrained on very different scales -
> a sin i is known about a thousand times better than a cos i - can wreck
> matrix algorithms. I guess I have to try this and see whether problems
> arise.
>
> Currently I am working with emcee, which has its drawbacks, but can use
> parallelism (to evaluate likelihoods for many walkers at once) and is
> fairly robust against covariances (the point coordinates themselves are
> used to generate candidates as linear combinations). But since I'm
> trying to test a hypothesis - GR is better than not-GR - it sure would
> be nice to use a tool that supports hypothesis testing!
>
> Thanks,
> Anne
>
> On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
> <mailto:kylebarbary at gmail.com>> wrote:
>
>     Yes, possibly! Nestle currently implements the basic MultiNest
>     method, but doesn't implement later improvements such as importance
>     reweighting or polychord. I'm open to contributions and
>     improvements. (But be mindful of reading the MultiNest source code
>     due to licensing issues!)
>
>     Best,
>     -- Kyle
>
>     On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
>     <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>>
>     wrote:
>
>         likewise!
>         Any prospect toward the polychord extension? See
>         http://arxiv.org/abs/1506.00171v1
>         cheers,
>         Johann
>
>
>         On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>>         HI Kyle,
>>
>>         Very nice. I'll definitely have a look at that.
>>
>>         Cheers,
>>            Wolfgang
>>         --
>>         Dr. Wolfgang E Kerzendorf
>>         ESO Fellow
>>         European Southern Observatory
>>         Karl-Schwarzschild Str. 2, 85748
>>         Garching bei Muenchen, Germany
>>
>>         On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
>>         <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
>>         <mailto:kylebarbary at gmail.com>> wrote:
>>
>>             Hi all,
>>
>>             I'm pleased to announce the initial release of Nestle, a
>>             small Python package for nested sampling. ("Nestle" rhymes
>>             with "wrestle".) Nested sampling is a statistical
>>             technique for parameter estimation and model comparison,
>>             commonly used in cosmology. We've been using it in the
>>             sncosmo package and have found it to be a robust global
>>             optimizer in addition to its more typically cited benefits.
>>
>>             Nestle implements an algorithm similar to that used in the
>>             MultiNest software, but in an open-source (MIT) licensed
>>             and easy-to-install (pure Python) package. (It was written
>>             based only on the literature, not the MultiNest source
>>             code.) In addition to this algorithm, Nestle also
>>             implements the "classic" nested sampling algorithm and the
>>             "single ellipsoid" algorithm.
>>
>>             Nestle depends on only numpy and (optionally) scipy and
>>             supports both Python 3 and Legacy Python (formerly known
>>             as Python 2).
>>
>>             docs:
>>             <http://kbarbary.github.io/nestle>http://kbarbary.github.io/nestle
>>             source:
>>             <http://github.com/kbarbary/nestle>http://github.com/kbarbary/nestle
>>
>>             I'd appreciate any feedback on this initial release,
>>             particularly about application to real-world problems and
>>             comparisons with results from MultiNest. Thanks!
>>
>>             - Kyle
>>             _______________________________________________
>>             AstroPy mailing list
>>             AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>             https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>>         _______________________________________________
>>         AstroPy mailing list
>>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>         https://mail.scipy.org/mailman/listinfo/astropy
>
>
>         _______________________________________________
>         AstroPy mailing list
>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>         https://mail.scipy.org/mailman/listinfo/astropy
>
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989


From archibald at astron.nl  Fri Oct  9 12:26:25 2015
From: archibald at astron.nl (Anne Archibald)
Date: Fri, 09 Oct 2015 16:26:25 +0000
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <5617E442.6050301@nrao.edu>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
 <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
 <5617E442.6050301@nrao.edu>
Message-ID: <CANm_+Zo4Zu-jkv9wJz+hzeQW9HNFNKPMAuvqp0jTRE1ZXEt_Gg@mail.gmail.com>

Hi Scott,

In fact I had parallel tempering working for a while, as a help to the
minimization. In one sense it's relatively cheap: since the
different-temperature chains are run in parallel, you can throw more
walkers and hence more cores at the problem. But it suffers from something
of the same problem as nested sampling: if you want to explore the whole
space, you need much higher temperatures than the base one, and the
temperature spacing can't be more than about 2^(1/n_parameters). So you
need a bazillion chains. That said, I don't know how much actual
probability the far-away parts of the space contribute to the integral, or
how to evaluate how well parallel tempering is working. For context,
though, the problem as implemented has two identical optima: a cos i and -a
cos i are equivalent until I put in the full astrometry. But parallel
tempering didn't find the other optimum.

For the problem of testing GR versus not-GR specifically, we might be able
to get away with using priors based on the Newtonian fit - it's the same
data, so that's maybe not quite kosher, but it does very dramatically
reduce the prior volume, maybe to a manageable level.

How is the PINT BTX model? I have a test problem - 30000 data points, two
sinusoids - that should produce similar prior/posterior constraints, but it
doesn't have that many parameters. If PINT BTX could be used, that would
give me a slightly more realistic problem. I could use the
two-noninteracting-Keplerian model I have but it's actually even slower to
evaluate than the integrator (don't ask). Anyway, the way to answer these
questions about what parallel tempering and nested sampling can do is to
run some tests with a much cheaper log-likelihood.

Anne

On Fri, Oct 9, 2015 at 5:59 PM Scott Ransom <sransom at nrao.edu> wrote:

> Hey Anne,
>
> Can you use parallel tempering MCMC to estimate the evidence for
> hypothesis testing?  Or will that work terribly badly for us given the
> dynamic range between prior to posterior?
>
> e.g. http://dan.iel.fm/emcee/current/user/pt/
>
> Scott
>
> On 10/08/2015 05:05 PM, Anne Archibald wrote:
> > Hi Kyle,
> >
> > I am very interested in nestle as an alternative MCMC method for a
> > project I'm working on (testing general relativity with pulsar timing
> > observations of a triple system; see
> > http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
> > considering multinest but the ability to get "under the hood" is really
> > valuable. I have several concerns with using the code; maybe you have
> > the experience to point me in the right direction.
> >
> > The first concern is that my likelihood function is really slow
> > (seconds). I have access to many cores, but each evaluation can only use
> > one. So I'd like to enlist some parallelism in the MCMC algorithm. As
> > written, nestle is purely sequential, but I can see several places
> > parallelism is available. The first and easiest is when picking a new
> > point to replace the worst: if this takes many tries, you could
> > speculatively evaluate the function at many new candidate points and
> > take the first acceptable one. Multinest is able to do this, and I can
> > see how one might add it to the code here. The second possibility is
> > suggested by your "update_interval" parameter. Until the family of
> > ellipsoids is updated, all new points are being generated from the same
> > distribution, so the evaluation of their likelihoods can be carried out
> > in parallel. This guarantees at least a factor update_interval worth of
> > parallelism, which might be worth it even for expensive likelihood
> > evaluations. Implementation would maintain a list of N (~ number of
> > cores) Futures representing evaluations drawn from the current set of
> > ellipsoids; every time the code needs a new point it waits for the first
> > Future to finish and gets the coordinates and log-likelihood from that,
> > then creates another Future for later. When the ellipsoids need to be
> > changed, all unused Futures can be cancelled. The result should be
> > statistically identical to the current algorithm, though it sometimes
> > uses extra RNG calls, so the actual call sequence won't be the same (and
> > will depend on N but nothing else).
> >
> > The second concern is that I'm worried my problem is going to take
> > forever with nested sampling. It's a somewhat high-dimensional problem -
> > 20-30 parameters - and the change in parameter volume from prior to
> > posterior is staggering: while the prior is a bit fuzzy, our knowledge
> > of (say) the inner orbital period goes from "about 1.6 days" to
> > "1.629401788(5) days"; many other parameters are similarly constrained.
> > Since nested sampling relies on gradually shrinking ellipses from the
> > entire space down to the target region, I worry that it will take a very
> > large number of steps (if the ellipse's volume shrinks by a factor 1.2
> > each time, that's ~3000 steps). This appears worryingly supported by a
> > numerical experiment I am running with a fast likelihood function that
> > nevertheless puts very tight constraints on the result.
> >
> > The third concern is about covariances. Of course ellipses are intended
> > to enclose potentially very skinny error regions, but I ran into
> > problems where my error region was so narrow that representing it with a
> > covariance matrix ran into matrix numerical headaches. I have
> > analytically marginalized out the worst offenders, but even the simple
> > problem that my parameters can be constrained on very different scales -
> > a sin i is known about a thousand times better than a cos i - can wreck
> > matrix algorithms. I guess I have to try this and see whether problems
> > arise.
> >
> > Currently I am working with emcee, which has its drawbacks, but can use
> > parallelism (to evaluate likelihoods for many walkers at once) and is
> > fairly robust against covariances (the point coordinates themselves are
> > used to generate candidates as linear combinations). But since I'm
> > trying to test a hypothesis - GR is better than not-GR - it sure would
> > be nice to use a tool that supports hypothesis testing!
> >
> > Thanks,
> > Anne
> >
> > On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
> > <mailto:kylebarbary at gmail.com>> wrote:
> >
> >     Yes, possibly! Nestle currently implements the basic MultiNest
> >     method, but doesn't implement later improvements such as importance
> >     reweighting or polychord. I'm open to contributions and
> >     improvements. (But be mindful of reading the MultiNest source code
> >     due to licensing issues!)
> >
> >     Best,
> >     -- Kyle
> >
> >     On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
> >     <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>>
> >     wrote:
> >
> >         likewise!
> >         Any prospect toward the polychord extension? See
> >         http://arxiv.org/abs/1506.00171v1
> >         cheers,
> >         Johann
> >
> >
> >         On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
> >>         HI Kyle,
> >>
> >>         Very nice. I'll definitely have a look at that.
> >>
> >>         Cheers,
> >>            Wolfgang
> >>         --
> >>         Dr. Wolfgang E Kerzendorf
> >>         ESO Fellow
> >>         European Southern Observatory
> >>         Karl-Schwarzschild Str. 2, 85748
> >>         Garching bei Muenchen, Germany
> >>
> >>         On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
> >>         <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
> >>         <mailto:kylebarbary at gmail.com>> wrote:
> >>
> >>             Hi all,
> >>
> >>             I'm pleased to announce the initial release of Nestle, a
> >>             small Python package for nested sampling. ("Nestle" rhymes
> >>             with "wrestle".) Nested sampling is a statistical
> >>             technique for parameter estimation and model comparison,
> >>             commonly used in cosmology. We've been using it in the
> >>             sncosmo package and have found it to be a robust global
> >>             optimizer in addition to its more typically cited benefits.
> >>
> >>             Nestle implements an algorithm similar to that used in the
> >>             MultiNest software, but in an open-source (MIT) licensed
> >>             and easy-to-install (pure Python) package. (It was written
> >>             based only on the literature, not the MultiNest source
> >>             code.) In addition to this algorithm, Nestle also
> >>             implements the "classic" nested sampling algorithm and the
> >>             "single ellipsoid" algorithm.
> >>
> >>             Nestle depends on only numpy and (optionally) scipy and
> >>             supports both Python 3 and Legacy Python (formerly known
> >>             as Python 2).
> >>
> >>             docs:
> >>             <http://kbarbary.github.io/nestle>
> http://kbarbary.github.io/nestle
> >>             source:
> >>             <http://github.com/kbarbary/nestle>
> http://github.com/kbarbary/nestle
> >>
> >>             I'd appreciate any feedback on this initial release,
> >>             particularly about application to real-world problems and
> >>             comparisons with results from MultiNest. Thanks!
> >>
> >>             - Kyle
> >>             _______________________________________________
> >>             AstroPy mailing list
> >>             AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>             https://mail.scipy.org/mailman/listinfo/astropy
> >>
> >>
> >>
> >>         _______________________________________________
> >>         AstroPy mailing list
> >>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>         https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >         _______________________________________________
> >         AstroPy mailing list
> >         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >         https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >     _______________________________________________
> >     AstroPy mailing list
> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >     https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
>
> --
> Scott M. Ransom            Address:  NRAO
> Phone:  (434) 296-0320               520 Edgemont Rd.
> email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
> GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151009/03246573/attachment.html>

From wkerzendorf at gmail.com  Sat Oct 10 11:12:33 2015
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Sat, 10 Oct 2015 15:12:33 +0000
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <CANm_+Zo4Zu-jkv9wJz+hzeQW9HNFNKPMAuvqp0jTRE1ZXEt_Gg@mail.gmail.com>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
 <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
 <5617E442.6050301@nrao.edu>
 <CANm_+Zo4Zu-jkv9wJz+hzeQW9HNFNKPMAuvqp0jTRE1ZXEt_Gg@mail.gmail.com>
Message-ID: <CAH33GGGjJJaG-GsubZRjgc2OPTkXLoBi4Xgoi=P9eYaP1FmZGg@mail.gmail.com>

Hi Anne,

We are facing a similar problem of having a likelihood with 15 dimensions
(in the simplest form) with an evaluation time of 60 - 100 seconds.
MultiNest can be run in parallel via MPI and we did this - however to no
avail as of yet. For now we employ different maximum likelihood methods
with some success.

Cheers,
   Wolfgang

--
Dr. Wolfgang E Kerzendorf
ESO Fellow
European Southern Observatory
Karl-Schwarzschild Str. 2, 85748
Garching bei Muenchen, Germany

On Fri, Oct 9, 2015 at 6:26 PM Anne Archibald <archibald at astron.nl> wrote:

> Hi Scott,
>
> In fact I had parallel tempering working for a while, as a help to the
> minimization. In one sense it's relatively cheap: since the
> different-temperature chains are run in parallel, you can throw more
> walkers and hence more cores at the problem. But it suffers from something
> of the same problem as nested sampling: if you want to explore the whole
> space, you need much higher temperatures than the base one, and the
> temperature spacing can't be more than about 2^(1/n_parameters). So you
> need a bazillion chains. That said, I don't know how much actual
> probability the far-away parts of the space contribute to the integral, or
> how to evaluate how well parallel tempering is working. For context,
> though, the problem as implemented has two identical optima: a cos i and -a
> cos i are equivalent until I put in the full astrometry. But parallel
> tempering didn't find the other optimum.
>
> For the problem of testing GR versus not-GR specifically, we might be able
> to get away with using priors based on the Newtonian fit - it's the same
> data, so that's maybe not quite kosher, but it does very dramatically
> reduce the prior volume, maybe to a manageable level.
>
> How is the PINT BTX model? I have a test problem - 30000 data points, two
> sinusoids - that should produce similar prior/posterior constraints, but it
> doesn't have that many parameters. If PINT BTX could be used, that would
> give me a slightly more realistic problem. I could use the
> two-noninteracting-Keplerian model I have but it's actually even slower to
> evaluate than the integrator (don't ask). Anyway, the way to answer these
> questions about what parallel tempering and nested sampling can do is to
> run some tests with a much cheaper log-likelihood.
>
> Anne
>
> On Fri, Oct 9, 2015 at 5:59 PM Scott Ransom <sransom at nrao.edu> wrote:
>
>> Hey Anne,
>>
>> Can you use parallel tempering MCMC to estimate the evidence for
>> hypothesis testing?  Or will that work terribly badly for us given the
>> dynamic range between prior to posterior?
>>
>> e.g. http://dan.iel.fm/emcee/current/user/pt/
>>
>> Scott
>>
>> On 10/08/2015 05:05 PM, Anne Archibald wrote:
>> > Hi Kyle,
>> >
>> > I am very interested in nestle as an alternative MCMC method for a
>> > project I'm working on (testing general relativity with pulsar timing
>> > observations of a triple system; see
>> > http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
>> > considering multinest but the ability to get "under the hood" is really
>> > valuable. I have several concerns with using the code; maybe you have
>> > the experience to point me in the right direction.
>> >
>> > The first concern is that my likelihood function is really slow
>> > (seconds). I have access to many cores, but each evaluation can only use
>> > one. So I'd like to enlist some parallelism in the MCMC algorithm. As
>> > written, nestle is purely sequential, but I can see several places
>> > parallelism is available. The first and easiest is when picking a new
>> > point to replace the worst: if this takes many tries, you could
>> > speculatively evaluate the function at many new candidate points and
>> > take the first acceptable one. Multinest is able to do this, and I can
>> > see how one might add it to the code here. The second possibility is
>> > suggested by your "update_interval" parameter. Until the family of
>> > ellipsoids is updated, all new points are being generated from the same
>> > distribution, so the evaluation of their likelihoods can be carried out
>> > in parallel. This guarantees at least a factor update_interval worth of
>> > parallelism, which might be worth it even for expensive likelihood
>> > evaluations. Implementation would maintain a list of N (~ number of
>> > cores) Futures representing evaluations drawn from the current set of
>> > ellipsoids; every time the code needs a new point it waits for the first
>> > Future to finish and gets the coordinates and log-likelihood from that,
>> > then creates another Future for later. When the ellipsoids need to be
>> > changed, all unused Futures can be cancelled. The result should be
>> > statistically identical to the current algorithm, though it sometimes
>> > uses extra RNG calls, so the actual call sequence won't be the same (and
>> > will depend on N but nothing else).
>> >
>> > The second concern is that I'm worried my problem is going to take
>> > forever with nested sampling. It's a somewhat high-dimensional problem -
>> > 20-30 parameters - and the change in parameter volume from prior to
>> > posterior is staggering: while the prior is a bit fuzzy, our knowledge
>> > of (say) the inner orbital period goes from "about 1.6 days" to
>> > "1.629401788(5) days"; many other parameters are similarly constrained.
>> > Since nested sampling relies on gradually shrinking ellipses from the
>> > entire space down to the target region, I worry that it will take a very
>> > large number of steps (if the ellipse's volume shrinks by a factor 1.2
>> > each time, that's ~3000 steps). This appears worryingly supported by a
>> > numerical experiment I am running with a fast likelihood function that
>> > nevertheless puts very tight constraints on the result.
>> >
>> > The third concern is about covariances. Of course ellipses are intended
>> > to enclose potentially very skinny error regions, but I ran into
>> > problems where my error region was so narrow that representing it with a
>> > covariance matrix ran into matrix numerical headaches. I have
>> > analytically marginalized out the worst offenders, but even the simple
>> > problem that my parameters can be constrained on very different scales -
>> > a sin i is known about a thousand times better than a cos i - can wreck
>> > matrix algorithms. I guess I have to try this and see whether problems
>> > arise.
>> >
>> > Currently I am working with emcee, which has its drawbacks, but can use
>> > parallelism (to evaluate likelihoods for many walkers at once) and is
>> > fairly robust against covariances (the point coordinates themselves are
>> > used to generate candidates as linear combinations). But since I'm
>> > trying to test a hypothesis - GR is better than not-GR - it sure would
>> > be nice to use a tool that supports hypothesis testing!
>> >
>> > Thanks,
>> > Anne
>> >
>> > On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
>> > <mailto:kylebarbary at gmail.com>> wrote:
>> >
>> >     Yes, possibly! Nestle currently implements the basic MultiNest
>> >     method, but doesn't implement later improvements such as importance
>> >     reweighting or polychord. I'm open to contributions and
>> >     improvements. (But be mindful of reading the MultiNest source code
>> >     due to licensing issues!)
>> >
>> >     Best,
>> >     -- Kyle
>> >
>> >     On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
>> >     <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com
>> >>
>> >     wrote:
>> >
>> >         likewise!
>> >         Any prospect toward the polychord extension? See
>> >         http://arxiv.org/abs/1506.00171v1
>> >         cheers,
>> >         Johann
>> >
>> >
>> >         On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>> >>         HI Kyle,
>> >>
>> >>         Very nice. I'll definitely have a look at that.
>> >>
>> >>         Cheers,
>> >>            Wolfgang
>> >>         --
>> >>         Dr. Wolfgang E Kerzendorf
>> >>         ESO Fellow
>> >>         European Southern Observatory
>> >>         Karl-Schwarzschild Str. 2, 85748
>> >>         Garching bei Muenchen, Germany
>> >>
>> >>         On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
>> >>         <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
>> >>         <mailto:kylebarbary at gmail.com>> wrote:
>> >>
>> >>             Hi all,
>> >>
>> >>             I'm pleased to announce the initial release of Nestle, a
>> >>             small Python package for nested sampling. ("Nestle" rhymes
>> >>             with "wrestle".) Nested sampling is a statistical
>> >>             technique for parameter estimation and model comparison,
>> >>             commonly used in cosmology. We've been using it in the
>> >>             sncosmo package and have found it to be a robust global
>> >>             optimizer in addition to its more typically cited benefits.
>> >>
>> >>             Nestle implements an algorithm similar to that used in the
>> >>             MultiNest software, but in an open-source (MIT) licensed
>> >>             and easy-to-install (pure Python) package. (It was written
>> >>             based only on the literature, not the MultiNest source
>> >>             code.) In addition to this algorithm, Nestle also
>> >>             implements the "classic" nested sampling algorithm and the
>> >>             "single ellipsoid" algorithm.
>> >>
>> >>             Nestle depends on only numpy and (optionally) scipy and
>> >>             supports both Python 3 and Legacy Python (formerly known
>> >>             as Python 2).
>> >>
>> >>             docs:
>> >>             <http://kbarbary.github.io/nestle>
>> http://kbarbary.github.io/nestle
>> >>             source:
>> >>             <http://github.com/kbarbary/nestle>
>> http://github.com/kbarbary/nestle
>> >>
>> >>             I'd appreciate any feedback on this initial release,
>> >>             particularly about application to real-world problems and
>> >>             comparisons with results from MultiNest. Thanks!
>> >>
>> >>             - Kyle
>> >>             _______________________________________________
>> >>             AstroPy mailing list
>> >>             AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >>             https://mail.scipy.org/mailman/listinfo/astropy
>> >>
>> >>
>> >>
>> >>         _______________________________________________
>> >>         AstroPy mailing list
>> >>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >>         https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> >         _______________________________________________
>> >         AstroPy mailing list
>> >         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >         https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> >     _______________________________________________
>> >     AstroPy mailing list
>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >     https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > https://mail.scipy.org/mailman/listinfo/astropy
>> >
>>
>> --
>> Scott M. Ransom            Address:  NRAO
>> Phone:  (434) 296-0320               520 Edgemont Rd.
>> email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
>> GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151010/335b9841/attachment.html>

From archibald at astron.nl  Sun Oct 11 13:16:00 2015
From: archibald at astron.nl (Anne Archibald)
Date: Sun, 11 Oct 2015 17:16:00 +0000
Subject: [AstroPy] [ANN] Nestle: Nested sampling
In-Reply-To: <CAH33GGGjJJaG-GsubZRjgc2OPTkXLoBi4Xgoi=P9eYaP1FmZGg@mail.gmail.com>
References: <CANO7-x8kM4PT0RzPmDvq5g48S3en3x58Krz_NLThWhnJr9QwGw@mail.gmail.com>
 <CAH33GGGXEyQJ9LfbeooR-VCP1YguV2AA42ZfeRFwX9+CgVipyA@mail.gmail.com>
 <560AC447.1090700@gmail.com>
 <CANO7-x9fSM+w-VZHNu24Mt=U_L5wjbihEiWafu=SFqnUiWtuEA@mail.gmail.com>
 <CANm_+ZrizwUSPL2Le1e4uKkY=UUs4Tzn70+N+OZNBLUd_xFggw@mail.gmail.com>
 <5617E442.6050301@nrao.edu>
 <CANm_+Zo4Zu-jkv9wJz+hzeQW9HNFNKPMAuvqp0jTRE1ZXEt_Gg@mail.gmail.com>
 <CAH33GGGjJJaG-GsubZRjgc2OPTkXLoBi4Xgoi=P9eYaP1FmZGg@mail.gmail.com>
Message-ID: <CANm_+ZreAiMLVEAn3AN28jEZgSXPAXxhFKSYA-eW7gAXuU_JSQ@mail.gmail.com>

Hi Wolfgang,

I have some techniques that have proved useful. In particular, I have a
hack that should make it possible to achieve about 30-fold parallelism in
local minimizers - parallelize the gradient evaluation:
http://lighthouseinthesky.blogspot.nl/2015/10/numerical-derivatives-in-parallel.html

I also found emcee was able to make use of some amount of parallelism. For
one thing, my objective function involves evaluation of a differential
equation, so there is some numerical roughness, which may make the local
minimizers fail to find the best fit. MCMC is of course not too concerned
with smoothness. And emcee uses multiple "walkers" to produce trial points;
these can be evaluated in parallel.

I find that emcee's runs happen in three stages: first the blob of walkers
crawls downhill to the general vicinity of the minimum (of minus
log-likelihood, say). Then the blob reshapes itself to match the posterior
distribution. Finally the system is capable of efficiently generating
posterior samples. The first stage can be accelerated dramatically by
starting near the minimum, possibly through the use of a local minimizer (I
often run the local minimizer multiple times, restarting it every time
emcee finds a better point than the local minimizer). The second stage,
mapping out the error ellipse, dominates my computation time; it helps to
keep the collection of walkers from a previous run, shifted in position to
center on the new minimum. Once the collection of walkers is reasonable,
generating posterior samples happens very quickly (by comparison). It's not
clear how much increasing the number of walkers accelerates the convergence
steps; I can't recommend more walkers than a few times the number of cores.

This may not be applicable to you, but in my case once you fix a (large)
subset of the parameters, the last few become a linear least-squares
problem. So I found it helped to analytically marginalize over these - drop
them as parameters, use the best-fit values, and add a correction factor
for the marginalization. In my case, these parameters were strongly
covariant with some of the others, so dropping them also made the error
ellipses much less singular.

You might also take a second look at nestle - we're working on the
parallelization (see PR and discussion), but it should be possible to
request much more aggressive parallelization from nestle than multinest
provides. It won't solve the dimensionality problem, but if you've got lots
of cores to throw at the problem, this may help.

Anne

On Sat, Oct 10, 2015 at 5:12 PM Wolfgang Kerzendorf <wkerzendorf at gmail.com>
wrote:

> Hi Anne,
>
> We are facing a similar problem of having a likelihood with 15 dimensions
> (in the simplest form) with an evaluation time of 60 - 100 seconds.
> MultiNest can be run in parallel via MPI and we did this - however to no
> avail as of yet. For now we employ different maximum likelihood methods
> with some success.
>
> Cheers,
>    Wolfgang
>
> --
> Dr. Wolfgang E Kerzendorf
> ESO Fellow
> European Southern Observatory
> Karl-Schwarzschild Str. 2, 85748
> Garching bei Muenchen, Germany
>
> On Fri, Oct 9, 2015 at 6:26 PM Anne Archibald <archibald at astron.nl> wrote:
>
>> Hi Scott,
>>
>> In fact I had parallel tempering working for a while, as a help to the
>> minimization. In one sense it's relatively cheap: since the
>> different-temperature chains are run in parallel, you can throw more
>> walkers and hence more cores at the problem. But it suffers from something
>> of the same problem as nested sampling: if you want to explore the whole
>> space, you need much higher temperatures than the base one, and the
>> temperature spacing can't be more than about 2^(1/n_parameters). So you
>> need a bazillion chains. That said, I don't know how much actual
>> probability the far-away parts of the space contribute to the integral, or
>> how to evaluate how well parallel tempering is working. For context,
>> though, the problem as implemented has two identical optima: a cos i and -a
>> cos i are equivalent until I put in the full astrometry. But parallel
>> tempering didn't find the other optimum.
>>
>> For the problem of testing GR versus not-GR specifically, we might be
>> able to get away with using priors based on the Newtonian fit - it's the
>> same data, so that's maybe not quite kosher, but it does very dramatically
>> reduce the prior volume, maybe to a manageable level.
>>
>> How is the PINT BTX model? I have a test problem - 30000 data points, two
>> sinusoids - that should produce similar prior/posterior constraints, but it
>> doesn't have that many parameters. If PINT BTX could be used, that would
>> give me a slightly more realistic problem. I could use the
>> two-noninteracting-Keplerian model I have but it's actually even slower to
>> evaluate than the integrator (don't ask). Anyway, the way to answer these
>> questions about what parallel tempering and nested sampling can do is to
>> run some tests with a much cheaper log-likelihood.
>>
>> Anne
>>
>> On Fri, Oct 9, 2015 at 5:59 PM Scott Ransom <sransom at nrao.edu> wrote:
>>
>>> Hey Anne,
>>>
>>> Can you use parallel tempering MCMC to estimate the evidence for
>>> hypothesis testing?  Or will that work terribly badly for us given the
>>> dynamic range between prior to posterior?
>>>
>>> e.g. http://dan.iel.fm/emcee/current/user/pt/
>>>
>>> Scott
>>>
>>> On 10/08/2015 05:05 PM, Anne Archibald wrote:
>>> > Hi Kyle,
>>> >
>>> > I am very interested in nestle as an alternative MCMC method for a
>>> > project I'm working on (testing general relativity with pulsar timing
>>> > observations of a triple system; see
>>> > http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
>>> > considering multinest but the ability to get "under the hood" is really
>>> > valuable. I have several concerns with using the code; maybe you have
>>> > the experience to point me in the right direction.
>>> >
>>> > The first concern is that my likelihood function is really slow
>>> > (seconds). I have access to many cores, but each evaluation can only
>>> use
>>> > one. So I'd like to enlist some parallelism in the MCMC algorithm. As
>>> > written, nestle is purely sequential, but I can see several places
>>> > parallelism is available. The first and easiest is when picking a new
>>> > point to replace the worst: if this takes many tries, you could
>>> > speculatively evaluate the function at many new candidate points and
>>> > take the first acceptable one. Multinest is able to do this, and I can
>>> > see how one might add it to the code here. The second possibility is
>>> > suggested by your "update_interval" parameter. Until the family of
>>> > ellipsoids is updated, all new points are being generated from the same
>>> > distribution, so the evaluation of their likelihoods can be carried out
>>> > in parallel. This guarantees at least a factor update_interval worth of
>>> > parallelism, which might be worth it even for expensive likelihood
>>> > evaluations. Implementation would maintain a list of N (~ number of
>>> > cores) Futures representing evaluations drawn from the current set of
>>> > ellipsoids; every time the code needs a new point it waits for the
>>> first
>>> > Future to finish and gets the coordinates and log-likelihood from that,
>>> > then creates another Future for later. When the ellipsoids need to be
>>> > changed, all unused Futures can be cancelled. The result should be
>>> > statistically identical to the current algorithm, though it sometimes
>>> > uses extra RNG calls, so the actual call sequence won't be the same
>>> (and
>>> > will depend on N but nothing else).
>>> >
>>> > The second concern is that I'm worried my problem is going to take
>>> > forever with nested sampling. It's a somewhat high-dimensional problem
>>> -
>>> > 20-30 parameters - and the change in parameter volume from prior to
>>> > posterior is staggering: while the prior is a bit fuzzy, our knowledge
>>> > of (say) the inner orbital period goes from "about 1.6 days" to
>>> > "1.629401788(5) days"; many other parameters are similarly constrained.
>>> > Since nested sampling relies on gradually shrinking ellipses from the
>>> > entire space down to the target region, I worry that it will take a
>>> very
>>> > large number of steps (if the ellipse's volume shrinks by a factor 1.2
>>> > each time, that's ~3000 steps). This appears worryingly supported by a
>>> > numerical experiment I am running with a fast likelihood function that
>>> > nevertheless puts very tight constraints on the result.
>>> >
>>> > The third concern is about covariances. Of course ellipses are intended
>>> > to enclose potentially very skinny error regions, but I ran into
>>> > problems where my error region was so narrow that representing it with
>>> a
>>> > covariance matrix ran into matrix numerical headaches. I have
>>> > analytically marginalized out the worst offenders, but even the simple
>>> > problem that my parameters can be constrained on very different scales
>>> -
>>> > a sin i is known about a thousand times better than a cos i - can wreck
>>> > matrix algorithms. I guess I have to try this and see whether problems
>>> > arise.
>>> >
>>> > Currently I am working with emcee, which has its drawbacks, but can use
>>> > parallelism (to evaluate likelihoods for many walkers at once) and is
>>> > fairly robust against covariances (the point coordinates themselves are
>>> > used to generate candidates as linear combinations). But since I'm
>>> > trying to test a hypothesis - GR is better than not-GR - it sure would
>>> > be nice to use a tool that supports hypothesis testing!
>>> >
>>> > Thanks,
>>> > Anne
>>> >
>>> > On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
>>> > <mailto:kylebarbary at gmail.com>> wrote:
>>> >
>>> >     Yes, possibly! Nestle currently implements the basic MultiNest
>>> >     method, but doesn't implement later improvements such as importance
>>> >     reweighting or polychord. I'm open to contributions and
>>> >     improvements. (But be mindful of reading the MultiNest source code
>>> >     due to licensing issues!)
>>> >
>>> >     Best,
>>> >     -- Kyle
>>> >
>>> >     On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
>>> >     <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com
>>> >>
>>> >     wrote:
>>> >
>>> >         likewise!
>>> >         Any prospect toward the polychord extension? See
>>> >         http://arxiv.org/abs/1506.00171v1
>>> >         cheers,
>>> >         Johann
>>> >
>>> >
>>> >         On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>>> >>         HI Kyle,
>>> >>
>>> >>         Very nice. I'll definitely have a look at that.
>>> >>
>>> >>         Cheers,
>>> >>            Wolfgang
>>> >>         --
>>> >>         Dr. Wolfgang E Kerzendorf
>>> >>         ESO Fellow
>>> >>         European Southern Observatory
>>> >>         Karl-Schwarzschild Str. 2, 85748
>>> >>         Garching bei Muenchen, Germany
>>> >>
>>> >>         On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
>>> >>         <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
>>> >>         <mailto:kylebarbary at gmail.com>> wrote:
>>> >>
>>> >>             Hi all,
>>> >>
>>> >>             I'm pleased to announce the initial release of Nestle, a
>>> >>             small Python package for nested sampling. ("Nestle" rhymes
>>> >>             with "wrestle".) Nested sampling is a statistical
>>> >>             technique for parameter estimation and model comparison,
>>> >>             commonly used in cosmology. We've been using it in the
>>> >>             sncosmo package and have found it to be a robust global
>>> >>             optimizer in addition to its more typically cited
>>> benefits.
>>> >>
>>> >>             Nestle implements an algorithm similar to that used in the
>>> >>             MultiNest software, but in an open-source (MIT) licensed
>>> >>             and easy-to-install (pure Python) package. (It was written
>>> >>             based only on the literature, not the MultiNest source
>>> >>             code.) In addition to this algorithm, Nestle also
>>> >>             implements the "classic" nested sampling algorithm and the
>>> >>             "single ellipsoid" algorithm.
>>> >>
>>> >>             Nestle depends on only numpy and (optionally) scipy and
>>> >>             supports both Python 3 and Legacy Python (formerly known
>>> >>             as Python 2).
>>> >>
>>> >>             docs:
>>> >>             <http://kbarbary.github.io/nestle>
>>> http://kbarbary.github.io/nestle
>>> >>             source:
>>> >>             <http://github.com/kbarbary/nestle>
>>> http://github.com/kbarbary/nestle
>>> >>
>>> >>             I'd appreciate any feedback on this initial release,
>>> >>             particularly about application to real-world problems and
>>> >>             comparisons with results from MultiNest. Thanks!
>>> >>
>>> >>             - Kyle
>>> >>             _______________________________________________
>>> >>             AstroPy mailing list
>>> >>             AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >>             https://mail.scipy.org/mailman/listinfo/astropy
>>> >>
>>> >>
>>> >>
>>> >>         _______________________________________________
>>> >>         AstroPy mailing list
>>> >>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >>         https://mail.scipy.org/mailman/listinfo/astropy
>>> >
>>> >
>>> >         _______________________________________________
>>> >         AstroPy mailing list
>>> >         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >         https://mail.scipy.org/mailman/listinfo/astropy
>>> >
>>> >
>>> >     _______________________________________________
>>> >     AstroPy mailing list
>>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> >     https://mail.scipy.org/mailman/listinfo/astropy
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > AstroPy mailing list
>>> > AstroPy at scipy.org
>>> > https://mail.scipy.org/mailman/listinfo/astropy
>>> >
>>>
>>> --
>>> Scott M. Ransom            Address:  NRAO
>>> Phone:  (434) 296-0320               520 Edgemont Rd.
>>> email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
>>> GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151011/d0814c22/attachment.html>

From aldcroft at head.cfa.harvard.edu  Mon Oct 12 13:52:07 2015
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Mon, 12 Oct 2015 13:52:07 -0400
Subject: [AstroPy] Happy 4th birthday Astropy!
Message-ID: <CAMtEP6xt3fhYy2v08ufk4xxcwiZKsVxw_BhdsnrbGpiJ2ypnnA@mail.gmail.com>

It was four years ago today that the first Astropy coordination meeting
took place at CfA with the following agenda:

   https://github.com/astropy/astropy/wiki/CfAMeeting2011Agenda

This meeting was the first time that words were really put into action [1],
and now it's amazing to see how the ideas (dreams?) from the meeting have
become reality.  Thanks to all those in the community who have devoted time
and energy to making this happen!

Cheers,
Tom

[1]: I would say that this email from Marshall Perrin
<https://mail.scipy.org/pipermail/astropy/2011-June/001380.html> is the
moment when the idea of Astropy was conceived (an exciting moment to be
sure!), and the first meeting was the birth of Astropy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151012/f222b0d5/attachment.html>

From eric at depagne.org  Mon Oct 12 14:46:07 2015
From: eric at depagne.org (=?ISO-8859-1?Q?=C9ric?= Depagne)
Date: Mon, 12 Oct 2015 20:46:07 +0200
Subject: [AstroPy] Happy 4th birthday Astropy!
In-Reply-To: <CAMtEP6xt3fhYy2v08ufk4xxcwiZKsVxw_BhdsnrbGpiJ2ypnnA@mail.gmail.com>
References: <CAMtEP6xt3fhYy2v08ufk4xxcwiZKsVxw_BhdsnrbGpiJ2ypnnA@mail.gmail.com>
Message-ID: <2077399.bsBSrHocWC@notebook>

On Monday 12 October 2015 13:52:07 Aldcroft, Thomas wrote:
Happy birthday, and thanks to all!

?ric.
> It was four years ago today that the first Astropy coordination meeting
> took place at CfA with the following agenda:
> 
>    https://github.com/astropy/astropy/wiki/CfAMeeting2011Agenda
> 
> This meeting was the first time that words were really put into action [1],
> and now it's amazing to see how the ideas (dreams?) from the meeting have
> become reality.  Thanks to all those in the community who have devoted time
> and energy to making this happen!
> 
> Cheers,
> Tom
> 
> [1]: I would say that this email from Marshall Perrin
> <https://mail.scipy.org/pipermail/astropy/2011-June/001380.html> is the
> moment when the idea of Astropy was conceived (an exciting moment to be
> sure!), and the first meeting was the birth of Astropy.

-- 
Un clavier azerty en vaut deux
----------------------------------------------------------
?ric Depagne                            eric at depagne.org



From npkuin at gmail.com  Mon Oct 12 15:14:31 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 12 Oct 2015 20:14:31 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
 <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
 <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
Message-ID: <CANoQ6N1su4BL6Rcn_AE6jgxwGYGVnzzyLjzrrzKLQQ03k2TaTg@mail.gmail.com>

Hello all,

I tried the suggestion from Tom, using the 'fix = False' parameter, but
that did not work. Now I'm in the middle of major updates, so perhaps it is
something that was fixed later (i'm now at Astropy 1.0.5).

However, I believe the correct thing is to use the 'relax=True' parameter
option for this. The reason is that it is now clear that before the 2002
WCS FITS standard was adopted, informal standards using 'RADECSYS' were
already used, for example, by HEASARC.  So it is not really a failure to
follow the standards, rather the standard is new.

Bill Pence, for the FITS Support Office at GSFC, said:

"The 8 character RADECSYS keyword appeared in early drafts of the WCS I &
II papers on the late 1990s, but by the time the papers were officially
approved as part of the FITS Standard in 2002, the name had been changed to
the 7-letter RADESYS.  Thus, the 8-character form was never officially
sanctioned, although it was still widely used at the time.

My personal opinion is that an if an observatory is still generating FITS
files with the old RADECSYS keyword name, then this should be considered
bad practice and the files should be flagged with a warning.    However, if
software encounters the RADECSYS keyword in files that were created before
about 2005 or so, then I would consider that OK."

I'm not going along with that, as I believe that the 'relax' option in the
WCS module in Astropy is just fit for purpose.

However, I also agree with Bill that there should be a warning for newly
minted FITS files. I.e., a 'writeto' should trigger a WARNING when 'verify'
is on.

So that's where the issue stands right now. I wonder if you all support
this now, or not.

Cheers,

    Paul

On Tue, Oct 6, 2015 at 1:15 PM, Thomas Robitaille <
thomas.robitaille at gmail.com> wrote:

> Hi Paul,
>
> As far as I'm aware, the error shouldn't be happening when you open
> the file, but when you pass the header to the WCS class from
> astropy.wcs. I think you can get rid of the warnings by simply doing
>
> wcs = WCS(header, fix=False)
>
> See
> http://docs.astropy.org/en/stable/api/astropy.wcs.WCS.html#astropy.wcs.WCS
>
> Cheers,
> Tom
>
> On 6 October 2015 at 09:15, Paul Kuin <npkuin at gmail.com> wrote:
> > It seems that WCS RADECSYS was not dropped then; it just ended up in the
> > standard in a different way. Probably to preserve backward compatibility
> to
> > old FITS files. It did throw me off, with just one letter difference!  I
> > think there must be some  old software that is still being used to create
> > fits files that do use RADECSYS.   I was using it (not bothering to check
> > the standard all the time, - yes bad!) and I suspect that Swift UVOT
> > software uses it (which is built on the HEASARC FTOOLS - so that might
> use
> > it also).  I'll bring it up in the UVOT group, but with the kind of very
> > limited software support that is left after 10 years of Swift mission, it
> > might not be possible to make the changes.
> >
> > To get back to my original issue. I think this means the WCS keywords
> are a
> > historical set that is still supported, but non-standard.  I also think
> that
> > getting a warning each time a file is opened is wrong.
> >
> > In my software I'd like to disable that warning.  I guess I'll need to
> have
> > a good look at the error handling in Astropy as I have somewhere another
> > warning pop up with loads of verbage, opening an ascii file. It actually
> > worked, just is very loud.   I hope there is a way to get a different
> > response for errors and warnings  to be used during testing and actual
> use.
> >
> > Thanks again for all the responses.
> >
> >    Paul Kuin
> >
> >
> >
> > On Mon, Oct 5, 2015 at 11:03 PM, Tim Jenness <tim.jenness at gmail.com>
> wrote:
> >>
> >> RADECSYS is a very common historic header that was used before support
> was
> >> added for multiple WCS definitions in a single header. I think it was
> >> dropped before the official paper II standard was published was was
> part of
> >> the initial draft:
> >>
> >> See e.g. http://www.adass.org/adass/proceedings/adass99/P1-29/
> >>
> >> --
> >> Tim Jenness
> >>
> >> On Mon, Oct 5, 2015 at 2:47 PM, Paul Kuin <npkuin at gmail.com> wrote:
> >>>
> >>> That is so. You're absolutely right!  I'm so sorry! I did not catch
> that
> >>> one.
> >>>
> >>> That is probably an error that sneeked into the FITS headers from
> Swift.
> >>> Perhaps its a Heasarc thing, but somehow I think its a bug.
> >>>
> >>> Thank you all for  helping with this.
> >>>
> >>> Paul
> >>>
> >>> On Mon, Oct 5, 2015 at 10:17 PM, Thomas Robitaille
> >>> <thomas.robitaille at gmail.com> wrote:
> >>>>
> >>>> I think there is a misunderstanding:
> >>>>
> >>>> RADECSYS is not valid
> >>>>
> >>>> RADESYS is valid
> >>>>
> >>>> (note the extra C). We are not debating that RADESYS is valid - it is
> -
> >>>> but the warning concerns the common mis-spelling of RADE*C*SYS. Does
> >>>> this make sense?
> >>>>
> >>>> Cheers,
> >>>> Tom
> >>>>
> >>>> Paul Kuin wrote:
> >>>> > In the WCS II standard paper ( M. R. Calabretta and E. W. Greisen:
> >>>> > Representations of celestial coordinates in FITS
> >>>> > http://www.aanda.org/articles/aa/pdf/2002/45/aah3860.pdf) on page
> 1079
> >>>> > the is a table defining some variables used. In particular 'a' is
> >>>> > alternate version code 'blank or [A-Z]. In table 2 on page 1082, the
> >>>> > definition is RADESYSa, meaning that valid versions are either
> >>>> > RADESYS,
> >>>> > RADESYSA, RADESYSB, ... , RADESYSZ.
> >>>> >
> >>>> > So it always was defined as a valid. Similar, EQUINOXa/. I've seen
> >>>> > that
> >>>> > mostly used as just EQUINOX. If the header has just one WCS block,
> or
> >>>> > a
> >>>> > preferred one, that is useful to have.
> >>>> >
> >>>> > Let's see what Bill Pence says. Maybe there were some changes after
> >>>> > all.
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Mon, Oct 5, 2015 at 8:34 PM, Thomas Robitaille
> >>>> > <thomas.robitaille at gmail.com <mailto:thomas.robitaille at gmail.com>>
> >>>> > wrote:
> >>>> >
> >>>> >     Hi Paul,
> >>>> >
> >>>> >     Just out of curiosity, was RADECSYS ever a keyword in the FITS
> >>>> > standard,
> >>>> >     as opposed to RADESYS? (which is the currently valid keyword).
> If
> >>>> > so, in
> >>>> >     what version of the standard?
> >>>> >
> >>>> >     Cheers,
> >>>> >     Tom
> >>>> >
> >>>> >     Paul Kuin wrote:
> >>>> >     > Actually, one of the basic tenets of FITS is to be completely
> >>>> > backward
> >>>> >     > compatible, so any keyword that was valid in the past is valid
> >>>> > now. So
> >>>> >     > that warning is also inaccurate. If it was standard, it still
> >>>> > is, and
> >>>> >     > ever will be.
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     > On Mon, Oct 5, 2015 at 5:25 PM, Erik Bray <embray at stsci.edu
> >>>> >     <mailto:embray at stsci.edu>
> >>>> >     > <mailto:embray at stsci.edu <mailto:embray at stsci.edu>>> wrote:
> >>>> >     >
> >>>> >     >     On 10/05/2015 12:17 PM, Paul Kuin wrote:
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     >         I am getting very annoyed of the warning that keeps
> >>>> > popping up
> >>>> >     >
> >>>> >     >         WARNING: FITSFixedWarning: RADECSYS= 'FK5' / default
> >>>> >     >         RADECSYS is non-standard, use RADESYSa.
> >>>> > [astropy.wcs.wcs]
> >>>> >     >
> >>>> >     >         I'm not sure when the FITS standard changed, but MOST
> >>>> > legacy
> >>>> >     >         fits files (I use)
> >>>> >     >         will have the RADECSYS keyword. It works, and I do not
> >>>> > see why
> >>>> >     >         someone felt the
> >>>> >     >         need to keep this warning being popped up all the
> time.
> >>>> >     >
> >>>> >     >
> >>>> >     >     Probably as a warning to remind authors of new files that
> >>>> > they
> >>>> >     >     shouldn't be using that keyword.  I don't know that it
> >>>> > necessarily
> >>>> >     >     needs to be displayed every time reading in a WCS except
> >>>> > maybe to
> >>>> >     >     head off cases of ambiguity.  But I don't know this
> >>>> > particular
> >>>> >     issue
> >>>> >     >     well enough to be sure if the warning is appropriate in
> all
> >>>> >     cases or
> >>>> >     >     not.
> >>>> >     >
> >>>> >     >         I think that by default it should be off.
> >>>> >     >
> >>>> >     >         Since you all probably think it should be there, I
> would
> >>>> >     like to
> >>>> >     >         know how to
> >>>> >     >         turn it off ?  any suggestion on how to do that?
> >>>> >     >
> >>>> >     >
> >>>> >     >     http://docs.astropy.org/en/stable/warnings.html
> >>>> >     >
> >>>> >     >
> >>>> >     >     Erik
> >>>> >     >
> >>>> >     >     _______________________________________________
> >>>> >     >     AstroPy mailing list
> >>>> >     >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     <mailto:AstroPy at scipy.org <mailto:AstroPy at scipy.org>>
> >>>> >     >     https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     >
> >>>> >     > --
> >>>> >     >
> >>>> >     > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> >>>> >     > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto:
> n.kuin at ucl.ac.uk>
> >>>> >     <mailto:n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>>)
> >>>> >     > phone +44-(0)1483 (prefix) -204927 (work)
> >>>> >     > mobile +44(0)7806985366 <tel:%2B44%280%297806985366>  skype
> ID:
> >>>> > npkuin
> >>>> >     > Mullard Space Science Laboratory  ? University College
> London  ?
> >>>> >     > Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
> >>>> >     >
> >>>> >     > _______________________________________________
> >>>> >     > AstroPy mailing list
> >>>> >     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     > https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >     _______________________________________________
> >>>> >     AstroPy mailing list
> >>>> >     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >>>> >     https://mail.scipy.org/mailman/listinfo/astropy
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> >
> >>>> > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
> >>>> > Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk <mailto: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.
> >>>> >
> >>>> > _______________________________________________
> >>>> > AstroPy mailing list
> >>>> > AstroPy at scipy.org
> >>>> > https://mail.scipy.org/mailman/listinfo/astropy
> >>>> _______________________________________________
> >>>> AstroPy mailing list
> >>>> AstroPy at scipy.org
> >>>> https://mail.scipy.org/mailman/listinfo/astropy
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> * * * * * * * * 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.
> >>>
> >>> _______________________________________________
> >>> AstroPy mailing list
> >>> AstroPy at scipy.org
> >>> https://mail.scipy.org/mailman/listinfo/astropy
> >>>
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >>
> >
> >
> >
> > --
> >
> > * * * * * * * * 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.
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * 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/20151012/6661b469/attachment.html>

From pweilbacher at aip.de  Mon Oct 12 15:37:40 2015
From: pweilbacher at aip.de (Peter Weilbacher)
Date: Mon, 12 Oct 2015 21:37:40 +0200 (CEST)
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <CANoQ6N1su4BL6Rcn_AE6jgxwGYGVnzzyLjzrrzKLQQ03k2TaTg@mail.gmail.com>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
 <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
 <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
 <CANoQ6N1su4BL6Rcn_AE6jgxwGYGVnzzyLjzrrzKLQQ03k2TaTg@mail.gmail.com>
Message-ID: <alpine.LSU.2.00.1510122119090.3742@durham.aip.de>

Hi Paul,

I'm probably missing something in this discussion, but why don't you
just rename the keyword from RADECSYS to RADESYS after reading in the
header? I.e. before passing the header to the WCS module

  file = fits.open(...)
  file[0].header.rename_keyword('RADECSYS', 'RADESYS')
  wcs = wcs.WCS(file[0].header)

Then the changed and saved file (if you save it again...) will also
match the current official FITS standard.

Cheers,
   Peter.

On Mon, 12 Oct 2015, Paul Kuin wrote:

> Hello all,
>
> I tried the suggestion from Tom, using the 'fix = False' parameter, but
> that did not work. Now I'm in the middle of major updates, so perhaps it is
> something that was fixed later (i'm now at Astropy 1.0.5).
>
> However, I believe the correct thing is to use the 'relax=True' parameter
> option for this. The reason is that it is now clear that before the 2002
> WCS FITS standard was adopted, informal standards using 'RADECSYS' were
> already used, for example, by HEASARC.  So it is not really a failure to
> follow the standards, rather the standard is new.
>
> Bill Pence, for the FITS Support Office at GSFC, said:
>
> "The 8 character RADECSYS keyword appeared in early drafts of the WCS I &
> II papers on the late 1990s, but by the time the papers were officially
> approved as part of the FITS Standard in 2002, the name had been changed to
> the 7-letter RADESYS.  Thus, the 8-character form was never officially
> sanctioned, although it was still widely used at the time.
>
> My personal opinion is that an if an observatory is still generating FITS
> files with the old RADECSYS keyword name, then this should be considered
> bad practice and the files should be flagged with a warning.    However, if
> software encounters the RADECSYS keyword in files that were created before
> about 2005 or so, then I would consider that OK."
>
> I'm not going along with that, as I believe that the 'relax' option in the
> WCS module in Astropy is just fit for purpose.
>
> However, I also agree with Bill that there should be a warning for newly
> minted FITS files. I.e., a 'writeto' should trigger a WARNING when 'verify'
> is on.
>
> So that's where the issue stands right now. I wonder if you all support
> this now, or not.
>
> Cheers,
>
>     Paul

-- 
Dr. Peter Weilbacher                http://www.aip.de/People/PWeilbacher
Phone +49 331 74 99-667                       encryption key ID 7D6B4AA0
------------------------------------------------------------------------
Leibniz-Institut f?r Astrophysik Potsdam (AIP)
An der Sternwarte 16, D-14482 Potsdam

Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker
Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026


From npkuin at gmail.com  Mon Oct 12 15:47:03 2015
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 12 Oct 2015 20:47:03 +0100
Subject: [AstroPy] fits coordinate system keyword
In-Reply-To: <alpine.LSU.2.00.1510122119090.3742@durham.aip.de>
References: <CANoQ6N3W5em9noSQd3tND-KwjonEiXsuBkM3Fe3arRd_HWHkwA@mail.gmail.com>
 <5612A47E.5010701@stsci.edu>
 <CANoQ6N2HyNP+g47zk14DHnLzy1AcEDJnEpGgSW10Se80jAcKRg@mail.gmail.com>
 <5612D0C9.7060805@gmail.com>
 <CANoQ6N0YpYJS5M5G+P_5Njw4pxqOkaXrKCA+-RXC4QHrKeXqsw@mail.gmail.com>
 <5612E8E5.4020700@gmail.com>
 <CANoQ6N1DqMUCrL+EGau0mE+TyWXC2LQckkAmUwexBrmO6j7LgQ@mail.gmail.com>
 <CA+G92Re_xSqpJnO3vTSuWj=UKwPBnAL_B9OP1zG4FRLJEw8n3g@mail.gmail.com>
 <CANoQ6N11dSyj2cFZV+UnSVVWaryx5uSqH3wvYEGxZQdjyxfOBw@mail.gmail.com>
 <CAGMHX_3HFA8KA6y1k_AF_kPK4K9OB24epKmGoTrH+wSSGPGJvA@mail.gmail.com>
 <CANoQ6N1su4BL6Rcn_AE6jgxwGYGVnzzyLjzrrzKLQQ03k2TaTg@mail.gmail.com>
 <alpine.LSU.2.00.1510122119090.3742@durham.aip.de>
Message-ID: <CANoQ6N3EZ8=_yUX=OOJJqtJNYnNuuK7_aNr4k0nRjQiU7r1XNQ@mail.gmail.com>

Hi Peter,

The problem is that I have a program to reduce Swift UVOT data,
specifically to reduce grism spectra. Each time a Swift data file wcs
header is read in with those 'old' keyword versions, Astropy.wcs issues a 2
line warning. I don't know if some people will get confused, but it is
plainly annoying.

Of course I can fix my code to have a work around. If we would do that for
every thing that is not right, we would have a job cut out for us. I'd
rather do astronomy. And then there is the issue of duplication. Would
everyone have to make this kind of hack because the main code cannot be
fixed ?

I know, we're getting into the philosophy of things. Looking for the Zen of
Astropy.

And with "happy 4th Birthday Astropy" I'd like to see it become more
perfect everyday!

  Cheers,

       Paul

On Mon, Oct 12, 2015 at 8:37 PM, Peter Weilbacher <pweilbacher at aip.de>
wrote:

> Hi Paul,
>
> I'm probably missing something in this discussion, but why don't you
> just rename the keyword from RADECSYS to RADESYS after reading in the
> header? I.e. before passing the header to the WCS module
>
>   file = fits.open(...)
>   file[0].header.rename_keyword('RADECSYS', 'RADESYS')
>   wcs = wcs.WCS(file[0].header)
>
> Then the changed and saved file (if you save it again...) will also
> match the current official FITS standard.
>
> Cheers,
>    Peter.
>
> On Mon, 12 Oct 2015, Paul Kuin wrote:
>
> > Hello all,
> >
> > I tried the suggestion from Tom, using the 'fix = False' parameter, but
> > that did not work. Now I'm in the middle of major updates, so perhaps it
> is
> > something that was fixed later (i'm now at Astropy 1.0.5).
> >
> > However, I believe the correct thing is to use the 'relax=True' parameter
> > option for this. The reason is that it is now clear that before the 2002
> > WCS FITS standard was adopted, informal standards using 'RADECSYS' were
> > already used, for example, by HEASARC.  So it is not really a failure to
> > follow the standards, rather the standard is new.
> >
> > Bill Pence, for the FITS Support Office at GSFC, said:
> >
> > "The 8 character RADECSYS keyword appeared in early drafts of the WCS I &
> > II papers on the late 1990s, but by the time the papers were officially
> > approved as part of the FITS Standard in 2002, the name had been changed
> to
> > the 7-letter RADESYS.  Thus, the 8-character form was never officially
> > sanctioned, although it was still widely used at the time.
> >
> > My personal opinion is that an if an observatory is still generating FITS
> > files with the old RADECSYS keyword name, then this should be considered
> > bad practice and the files should be flagged with a warning.    However,
> if
> > software encounters the RADECSYS keyword in files that were created
> before
> > about 2005 or so, then I would consider that OK."
> >
> > I'm not going along with that, as I believe that the 'relax' option in
> the
> > WCS module in Astropy is just fit for purpose.
> >
> > However, I also agree with Bill that there should be a warning for newly
> > minted FITS files. I.e., a 'writeto' should trigger a WARNING when
> 'verify'
> > is on.
> >
> > So that's where the issue stands right now. I wonder if you all support
> > this now, or not.
> >
> > Cheers,
> >
> >     Paul
>
> --
> Dr. Peter Weilbacher                http://www.aip.de/People/PWeilbacher
> Phone +49 331 74 99-667                       encryption key ID 7D6B4AA0
> ------------------------------------------------------------------------
> Leibniz-Institut f?r Astrophysik Potsdam (AIP)
> An der Sternwarte 16, D-14482 Potsdam
>
> Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker
> Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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/20151012/0ca07e9d/attachment.html>

From jmangum at nrao.edu  Fri Oct 16 09:11:56 2015
From: jmangum at nrao.edu (Jeff Mangum)
Date: Fri, 16 Oct 2015 09:11:56 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
Message-ID: <5620F79C.8050202@nrao.edu>

Hello,

Long-time listener but first-time caller.  Have been trying to use the 
2D Gaussian fitting capabilities within astropy.models to fit a 2D 
Gaussian to an image (in FITS format).  Here is my script:

import numpy as np
import radio_beam
from astropy.modeling import models, fitting
from astropy import units as u
from astropy.io import fits
import astropy.coordinates as coord
import astropy.wcs as wcs
import matplotlib
import pylab as pl

# The following is the position of the peak in both J1 and J2, so use
# it as the starting guess
ra0 = '13h15m03.50s'
dec0 = '24d37m08.2s'

radeg = coord.Angle(ra0, unit=u.hour).degree
decdeg = coord.Angle(dec0, unit=u.degree)

# Now open the image
hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
#hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
w = wcs.WCS(hdulist[0].header, hdulist)

yy,xx = np.indices(hdulist[0].data.shape)

x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)

# Now fit 2D gaussian
g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0, 
x_stddev=1, y_stddev=1)
fit_g = fitting.LevMarLSQFitter()
g = fit_g(g_init, xx, yy, hdulist[0].data)


When I look at g_init (which is where I believe the fit results should 
be), I see that the fit has not moved from its initial settings.  It 
appears that the fitter just did not run.  With Adam Ginsburg's help I 
have a workaround using gaussfitter, but would certainly like to make 
this work with astropy.models.  Thanks!

-- Jeff


From crawford at saao.ac.za  Fri Oct 16 09:28:59 2015
From: crawford at saao.ac.za (Steve Crawford)
Date: Fri, 16 Oct 2015 15:28:59 +0200 (SAST)
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <5620F79C.8050202@nrao.edu>
References: <5620F79C.8050202@nrao.edu>
Message-ID: <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>



Hi Jeff--

The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.

Cheers
Steve

----- Original Message -----
From: "Jeff Mangum" <jmangum at nrao.edu>
To: astropy at scipy.org
Sent: Friday, October 16, 2015 3:11:56 PM
Subject: [AstroPy] Gaussian models fitter non-functional?

Hello,

Long-time listener but first-time caller.  Have been trying to use the 
2D Gaussian fitting capabilities within astropy.models to fit a 2D 
Gaussian to an image (in FITS format).  Here is my script:

import numpy as np
import radio_beam
from astropy.modeling import models, fitting
from astropy import units as u
from astropy.io import fits
import astropy.coordinates as coord
import astropy.wcs as wcs
import matplotlib
import pylab as pl

# The following is the position of the peak in both J1 and J2, so use
# it as the starting guess
ra0 = '13h15m03.50s'
dec0 = '24d37m08.2s'

radeg = coord.Angle(ra0, unit=u.hour).degree
decdeg = coord.Angle(dec0, unit=u.degree)

# Now open the image
hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
#hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
w = wcs.WCS(hdulist[0].header, hdulist)

yy,xx = np.indices(hdulist[0].data.shape)

x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)

# Now fit 2D gaussian
g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0, 
x_stddev=1, y_stddev=1)
fit_g = fitting.LevMarLSQFitter()
g = fit_g(g_init, xx, yy, hdulist[0].data)


When I look at g_init (which is where I believe the fit results should 
be), I see that the fit has not moved from its initial settings.  It 
appears that the fitter just did not run.  With Adam Ginsburg's help I 
have a workaround using gaussfitter, but would certainly like to make 
this work with astropy.models.  Thanks!

-- Jeff
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
https://mail.scipy.org/mailman/listinfo/astropy

!DSPAM:5620f7a993681466218807!




From jmangum at nrao.edu  Fri Oct 16 09:36:27 2015
From: jmangum at nrao.edu (Jeff Mangum)
Date: Fri, 16 Oct 2015 09:36:27 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
Message-ID: <5620FD5B.6070200@nrao.edu>

Thank you Steve.  I mis-typed.  Yes, "g" is where the fit should be.  
Unfortunately, it is equal to g_init:

In [304]: g
Out[304]: <Gaussian2D(amplitude=1.0, x_mean=55.873445625871355, 
y_mean=55.410802834496835, x_stddev=1.0, y_stddev=1.0, theta=0.0)>

Still looks to me like the fitter is not fitting...

-- Jeff


On 10/16/15 9:28 AM, Steve Crawford wrote:
>
> Hi Jeff--
>
> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
>
> Cheers
> Steve
>
> ----- Original Message -----
> From: "Jeff Mangum" <jmangum at nrao.edu>
> To: astropy at scipy.org
> Sent: Friday, October 16, 2015 3:11:56 PM
> Subject: [AstroPy] Gaussian models fitter non-functional?
>
> Hello,
>
> Long-time listener but first-time caller.  Have been trying to use the
> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
> Gaussian to an image (in FITS format).  Here is my script:
>
> import numpy as np
> import radio_beam
> from astropy.modeling import models, fitting
> from astropy import units as u
> from astropy.io import fits
> import astropy.coordinates as coord
> import astropy.wcs as wcs
> import matplotlib
> import pylab as pl
>
> # The following is the position of the peak in both J1 and J2, so use
> # it as the starting guess
> ra0 = '13h15m03.50s'
> dec0 = '24d37m08.2s'
>
> radeg = coord.Angle(ra0, unit=u.hour).degree
> decdeg = coord.Angle(dec0, unit=u.degree)
>
> # Now open the image
> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
> w = wcs.WCS(hdulist[0].header, hdulist)
>
> yy,xx = np.indices(hdulist[0].data.shape)
>
> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>
> # Now fit 2D gaussian
> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
> x_stddev=1, y_stddev=1)
> fit_g = fitting.LevMarLSQFitter()
> g = fit_g(g_init, xx, yy, hdulist[0].data)
>
>
> When I look at g_init (which is where I believe the fit results should
> be), I see that the fit has not moved from its initial settings.  It
> appears that the fitter just did not run.  With Adam Ginsburg's help I
> have a workaround using gaussfitter, but would certainly like to make
> this work with astropy.models.  Thanks!
>
> -- Jeff
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
> !DSPAM:5620f7a993681466218807!
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From giuliano.iorio at unibo.it  Fri Oct 16 09:47:23 2015
From: giuliano.iorio at unibo.it (Giuliano Iorio)
Date: Fri, 16 Oct 2015 13:47:23 +0000
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
References: <5620F79C.8050202@nrao.edu>,
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
Message-ID: <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>


Hi Jeff, 
this is the kind of staff that usually happens if the position of the initial guess is too far away the right one. Did you plot the contour of the fitted gaussian on the image? 
It can be also that the image is too noisy around the target to fit. I usually use only a little subarray around the target, then I search the position of the maximum and I set the initial guess of xo and yo to its position. After I normalize all the subarray to the value of the maximum and cut all the signal below a certain threshold (usually 0.1).
In this way I am able to obtain a robust fit also in very noisy map.

best regards,
Giuliano
> Il giorno 16 ott 2015, alle ore 15:29, Steve Crawford <crawford at saao.ac.za> ha scritto:
> 
> 
> 
> Hi Jeff--
> 
> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
> 
> Cheers
> Steve
> 
> ----- Original Message -----
> From: "Jeff Mangum" <jmangum at nrao.edu>
> To: astropy at scipy.org
> Sent: Friday, October 16, 2015 3:11:56 PM
> Subject: [AstroPy] Gaussian models fitter non-functional?
> 
> Hello,
> 
> Long-time listener but first-time caller.  Have been trying to use the 
> 2D Gaussian fitting capabilities within astropy.models to fit a 2D 
> Gaussian to an image (in FITS format).  Here is my script:
> 
> import numpy as np
> import radio_beam
> from astropy.modeling import models, fitting
> from astropy import units as u
> from astropy.io import fits
> import astropy.coordinates as coord
> import astropy.wcs as wcs
> import matplotlib
> import pylab as pl
> 
> # The following is the position of the peak in both J1 and J2, so use
> # it as the starting guess
> ra0 = '13h15m03.50s'
> dec0 = '24d37m08.2s'
> 
> radeg = coord.Angle(ra0, unit=u.hour).degree
> decdeg = coord.Angle(dec0, unit=u.degree)
> 
> # Now open the image
> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
> w = wcs.WCS(hdulist[0].header, hdulist)
> 
> yy,xx = np.indices(hdulist[0].data.shape)
> 
> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
> 
> # Now fit 2D gaussian
> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0, 
> x_stddev=1, y_stddev=1)
> fit_g = fitting.LevMarLSQFitter()
> g = fit_g(g_init, xx, yy, hdulist[0].data)
> 
> 
> When I look at g_init (which is where I believe the fit results should 
> be), I see that the fit has not moved from its initial settings.  It 
> appears that the fitter just did not run.  With Adam Ginsburg's help I 
> have a workaround using gaussfitter, but would certainly like to make 
> this work with astropy.models.  Thanks!
> 
> -- Jeff
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 
> !DSPAM:5620f7a993681466218807!
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From jmangum at nrao.edu  Fri Oct 16 10:23:24 2015
From: jmangum at nrao.edu (Jeff Mangum)
Date: Fri, 16 Oct 2015 10:23:24 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>
References: <5620F79C.8050202@nrao.edu>,
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>
Message-ID: <5621085C.6010306@nrao.edu>

Hello Guiliano,

On 10/16/15 9:47 AM, Giuliano Iorio wrote:
> Hi Jeff,
> this is the kind of staff that usually happens if the position of the initial guess is too far away the right one. Did you plot the contour of the fitted gaussian on the image?

Yes.  The initial guess I give the fitter is right on the peak.

> It can be also that the image is too noisy around the target to fit. I usually use only a little subarray around the target, then I search the position of the maximum and I set the initial guess of xo and yo to its position. After I normalize all the subarray to the value of the maximum and cut all the signal below a certain threshold (usually 0.1).
> In this way I am able to obtain a robust fit also in very noisy map.

The final signal-to-noise on peak is more than 100:1.  Note that I have 
used gaussfitter to solve this problem using the same inputs as I tried 
to use with astropy.models, and that worked beautifully.

-- Jeff

>
> best regards,
> Giuliano
>> Il giorno 16 ott 2015, alle ore 15:29, Steve Crawford <crawford at saao.ac.za> ha scritto:
>>
>>
>>
>> Hi Jeff--
>>
>> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
>>
>> Cheers
>> Steve
>>
>> ----- Original Message -----
>> From: "Jeff Mangum" <jmangum at nrao.edu>
>> To: astropy at scipy.org
>> Sent: Friday, October 16, 2015 3:11:56 PM
>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>
>> Hello,
>>
>> Long-time listener but first-time caller.  Have been trying to use the
>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>> Gaussian to an image (in FITS format).  Here is my script:
>>
>> import numpy as np
>> import radio_beam
>> from astropy.modeling import models, fitting
>> from astropy import units as u
>> from astropy.io import fits
>> import astropy.coordinates as coord
>> import astropy.wcs as wcs
>> import matplotlib
>> import pylab as pl
>>
>> # The following is the position of the peak in both J1 and J2, so use
>> # it as the starting guess
>> ra0 = '13h15m03.50s'
>> dec0 = '24d37m08.2s'
>>
>> radeg = coord.Angle(ra0, unit=u.hour).degree
>> decdeg = coord.Angle(dec0, unit=u.degree)
>>
>> # Now open the image
>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>> w = wcs.WCS(hdulist[0].header, hdulist)
>>
>> yy,xx = np.indices(hdulist[0].data.shape)
>>
>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>
>> # Now fit 2D gaussian
>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>> x_stddev=1, y_stddev=1)
>> fit_g = fitting.LevMarLSQFitter()
>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>
>>
>> When I look at g_init (which is where I believe the fit results should
>> be), I see that the fit has not moved from its initial settings.  It
>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>> have a workaround using gaussfitter, but would certainly like to make
>> this work with astropy.models.  Thanks!
>>
>> -- Jeff
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>> !DSPAM:5620f7a993681466218807!
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From giuliano.iorio at unibo.it  Fri Oct 16 10:42:26 2015
From: giuliano.iorio at unibo.it (Giuliano Iorio)
Date: Fri, 16 Oct 2015 14:42:26 +0000
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <5621085C.6010306@nrao.edu>
References: <5620F79C.8050202@nrao.edu>,
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>,<5621085C.6010306@nrao.edu>
Message-ID: <6CC10EA5-9DCA-4E12-8190-DECA6A71BE82@unibo.it>

It is really strange, I have used intensivly the 2D Gaussian fitting this last month and I have never had this kind of problem. I do not know gaussfitter and i usually work directly on the numpy array index of the image, instead to use the coordinate and the wcs utility. To definitevely exclude some bugs or errors in the steps before the fit, I suggest you to try to not use the coordinate of the peak, but instead find it with np.argmax

Cheers,
Giuliano
> Il giorno 16 ott 2015, alle ore 16:23, Jeff Mangum <jmangum at nrao.edu> ha scritto:
> 
> Hello Guiliano,
> 
>> On 10/16/15 9:47 AM, Giuliano Iorio wrote:
>> Hi Jeff,
>> this is the kind of staff that usually happens if the position of the initial guess is too far away the right one. Did you plot the contour of the fitted gaussian on the image?
> 
> Yes.  The initial guess I give the fitter is right on the peak.
> 
>> It can be also that the image is too noisy around the target to fit. I usually use only a little subarray around the target, then I search the position of the maximum and I set the initial guess of xo and yo to its position. After I normalize all the subarray to the value of the maximum and cut all the signal below a certain threshold (usually 0.1).
>> In this way I am able to obtain a robust fit also in very noisy map.
> 
> The final signal-to-noise on peak is more than 100:1.  Note that I have used gaussfitter to solve this problem using the same inputs as I tried to use with astropy.models, and that worked beautifully.
> 
> -- Jeff
> 
>> 
>> best regards,
>> Giuliano
>>> Il giorno 16 ott 2015, alle ore 15:29, Steve Crawford <crawford at saao.ac.za> ha scritto:
>>> 
>>> 
>>> 
>>> Hi Jeff--
>>> 
>>> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
>>> 
>>> Cheers
>>> Steve
>>> 
>>> ----- Original Message -----
>>> From: "Jeff Mangum" <jmangum at nrao.edu>
>>> To: astropy at scipy.org
>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>> 
>>> Hello,
>>> 
>>> Long-time listener but first-time caller.  Have been trying to use the
>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>> Gaussian to an image (in FITS format).  Here is my script:
>>> 
>>> import numpy as np
>>> import radio_beam
>>> from astropy.modeling import models, fitting
>>> from astropy import units as u
>>> from astropy.io import fits
>>> import astropy.coordinates as coord
>>> import astropy.wcs as wcs
>>> import matplotlib
>>> import pylab as pl
>>> 
>>> # The following is the position of the peak in both J1 and J2, so use
>>> # it as the starting guess
>>> ra0 = '13h15m03.50s'
>>> dec0 = '24d37m08.2s'
>>> 
>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>> 
>>> # Now open the image
>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>> 
>>> yy,xx = np.indices(hdulist[0].data.shape)
>>> 
>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>> 
>>> # Now fit 2D gaussian
>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>> x_stddev=1, y_stddev=1)
>>> fit_g = fitting.LevMarLSQFitter()
>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>> 
>>> 
>>> When I look at g_init (which is where I believe the fit results should
>>> be), I see that the fit has not moved from its initial settings.  It
>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>> have a workaround using gaussfitter, but would certainly like to make
>>> this work with astropy.models.  Thanks!
>>> 
>>> -- Jeff
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> 
>>> !DSPAM:5620f7a993681466218807!
>>> 
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From banyal at iiap.res.in  Fri Oct 16 23:15:32 2015
From: banyal at iiap.res.in (banyal)
Date: Sat, 17 Oct 2015 08:45:32 +0530
Subject: [AstroPy] =?utf-8?q?Gaussian_models_fitter_non-functional=3F?=
In-Reply-To: <5620FD5B.6070200@nrao.edu>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <5620FD5B.6070200@nrao.edu>
Message-ID: <ecb5a3efe2240f3c84a6d970bc01f5dd@iiap.res.in>



Hi Jeff, 

The fits data is located in hdulist[1].data and not in hdulist[0].data 

g = fit_g(g_init, xx, yy, hdulist[1].data) instead of 

g = fit_g(g_init, xx, yy, hdulist[0].data)

-Ravi

On 2015-10-16 19:06, Jeff Mangum wrote: 

> Thank you Steve. I mis-typed. Yes, "g" is where the fit should be. 
> Unfortunately, it is equal to g_init:
> 
> In [304]: g
> Out[304]: <Gaussian2D(amplitude=1.0, x_mean=55.873445625871355, 
> y_mean=55.410802834496835, x_stddev=1.0, y_stddev=1.0, theta=0.0)>
> 
> Still looks to me like the fitter is not fitting...
> 
> -- Jeff
> 
> On 10/16/15 9:28 AM, Steve Crawford wrote:
> 
>> Hi Jeff-- The fitted model will not be in g_init (this remains unchanged), but in g. If you take a look in g, you should be able to see the fitted results. Cheers Steve ----- Original Message ----- From: "Jeff Mangum" <jmangum at nrao.edu> To: astropy at scipy.org Sent: Friday, October 16, 2015 3:11:56 PM Subject: [AstroPy] Gaussian models fitter non-functional? Hello, Long-time listener but first-time caller. Have been trying to use the 2D Gaussian fitting capabilities within astropy.models to fit a 2D Gaussian to an image (in FITS format). Here is my script: import numpy as np import radio_beam from astropy.modeling import models, fitting from astropy import units as u from astropy.io import fits import astropy.coordinates as coord import astropy.wcs as wcs import matplotlib import pylab as pl # The following is the position of the peak in both J1 and J2, so use # it as the starting guess ra0 = '13h15m03.50s' dec0 = '24d37m08.2s' radeg = coord.Angle(ra0, unit=u.hour).degree de
 cdeg =
coord.Angle(dec0, unit=u.degree) # Now open the image hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits') #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits') w = wcs.WCS(hdulist[0].header, hdulist) yy,xx = np.indices(hdulist[0].data.shape) x0,y0 = w.wcs_world2pix(radeg, decdeg, 1) # Now fit 2D gaussian g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0, x_stddev=1, y_stddev=1) fit_g = fitting.LevMarLSQFitter() g = fit_g(g_init, xx, yy, hdulist[0].data) When I look at g_init (which is where I believe the fit results should be), I see that the fit has not moved from its initial settings. It appears that the fitter just did not run. With Adam Ginsburg's help I have a workaround using gaussfitter, but would certainly like to make this work with astropy.models. Thanks! -- Jeff _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy [1] !DSPAM:5620f7a993681466218807!
_______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy [1]
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy [1]



Links:
------
[1] https://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151017/6d36a66c/attachment.html>

From josevinicius at iecom.org.br  Sat Oct 17 16:19:42 2015
From: josevinicius at iecom.org.br (=?UTF-8?B?Sm9zw6kgVmluw61jaXVz?=)
Date: Sat, 17 Oct 2015 17:19:42 -0300
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <ecb5a3efe2240f3c84a6d970bc01f5dd@iiap.res.in>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <5620FD5B.6070200@nrao.edu>
 <ecb5a3efe2240f3c84a6d970bc01f5dd@iiap.res.in>
Message-ID: <CAA9_Grk-u1JkRoctO97b=kMz-9w5jr+35fu3nZorQ0EeYT0nnA@mail.gmail.com>

Hi all,

On 10/16/15 9:47 AM, Giuliano Iorio wrote:

> It can be also that the image is too noisy around the target to fit. I
> usually use only a little subarray around the target, then I search the
> position of the maximum and I set the initial guess of xo and yo to its
> position. After I normalize all the subarray to the value of the maximum
> and cut all the signal below a certain threshold (usually 0.1).
> In this way I am able to obtain a robust fit also in very noisy map.


?That's an interesting approach, I'm going to give it a try.?

?

Another clever approach too, which I have used to calculate initial guesses
for maximum likelihood estimators (which usually needs a rather closer
initial guess than least squares), is simply to take the centroid of the
amplitudes in the region of interest. It's fairly robust even in very noisy
(poisson + gaussian) scenarios.

Cheers,
-Jose.

CVLattes: http://lattes.cnpq.br/3267230342393209

On Sat, Oct 17, 2015 at 12:15 AM, banyal <banyal at iiap.res.in> wrote:

> Hi Jeff,
>
> The  fits data  is located in  hdulist[1].data and not in hdulist[0].data
>
> g = fit_g(g_init, xx, yy, hdulist[1].data)     instead of
>
> g = fit_g(g_init, xx, yy, hdulist[0].data)
>
>
> -Ravi
>
> On 2015-10-16 19:06, Jeff Mangum wrote:
>
> Thank you Steve.  I mis-typed.  Yes, "g" is where the fit should be.
> Unfortunately, it is equal to g_init:
>
> In [304]: g
> Out[304]: <Gaussian2D(amplitude=1.0, x_mean=55.873445625871355,
> y_mean=55.410802834496835, x_stddev=1.0, y_stddev=1.0, theta=0.0)>
>
> Still looks to me like the fitter is not fitting...
>
> -- Jeff
>
>
> On 10/16/15 9:28 AM, Steve Crawford wrote:
>
> Hi Jeff-- The fitted model will not be in g_init (this remains unchanged),
> but in g. If you take a look in g, you should be able to see the fitted
> results. Cheers Steve ----- Original Message ----- From: "Jeff Mangum" <
> jmangum at nrao.edu> To: astropy at scipy.org Sent: Friday, October 16, 2015
> 3:11:56 PM Subject: [AstroPy] Gaussian models fitter non-functional? Hello,
> Long-time listener but first-time caller. Have been trying to use the 2D
> Gaussian fitting capabilities within astropy.models to fit a 2D Gaussian to
> an image (in FITS format). Here is my script: import numpy as np import
> radio_beam from astropy.modeling import models, fitting from astropy import
> units as u from astropy.io import fits import astropy.coordinates as
> coord import astropy.wcs as wcs import matplotlib import pylab as pl # The
> following is the position of the peak in both J1 and J2, so use # it as the
> starting guess ra0 = '13h15m03.50s' dec0 = '24d37m08.2s' radeg =
> coord.Angle(ra0, unit=u.hour).degree decdeg = coord.Angle(dec0,
> unit=u.degree) # Now open the image hdulist =
> fits.open('IC860CbandCarrayH2COJ1_moment0.fits') #hdulist =
> fits.open('IC860KubandDarrayH2COJ2_moment0.fits') w =
> wcs.WCS(hdulist[0].header, hdulist) yy,xx =
> np.indices(hdulist[0].data.shape) x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
> # Now fit 2D gaussian g_init = models.Gaussian2D(amplitude=1., x_mean=x0,
> y_mean=y0, x_stddev=1, y_stddev=1) fit_g = fitting.LevMarLSQFitter() g =
> fit_g(g_init, xx, yy, hdulist[0].data) When I look at g_init (which is
> where I believe the fit results should be), I see that the fit has not
> moved from its initial settings. It appears that the fitter just did not
> run. With Adam Ginsburg's help I have a workaround using gaussfitter, but
> would certainly like to make this work with astropy.models. Thanks! -- Jeff
> _______________________________________________ AstroPy mailing list
> AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy
> !DSPAM:5620f7a993681466218807!
> _______________________________________________ AstroPy mailing list
> AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151017/203aab62/attachment.html>

From embray at stsci.edu  Mon Oct 19 11:00:05 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 19 Oct 2015 11:00:05 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it>
Message-ID: <56250575.3010307@stsci.edu>

On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>
> Hi Jeff,
> this is the kind of staff that usually happens if the position of the initial guess is too far away the right one. Did you plot the contour of the fitted gaussian on the image?
> It can be also that the image is too noisy around the target to fit. I usually use only a little subarray around the target, then I search the position of the maximum and I set the initial guess of xo and yo to its position. After I normalize all the subarray to the value of the maximum and cut all the signal below a certain threshold (usually 0.1).
> In this way I am able to obtain a robust fit also in very noisy map.

I agree pretty much with all of Giuliano's advice.  And again it might help to 
exclude data outside a smaller subarray.  Without actually seeing the data it's 
hard to provide much other advice.

Have you tried a different optimizer?  There are a couple other non-linear 
fitters in the package and some have different sensitivities to initial 
conditions.  But it's certainly not "non-functional".

Erik

>> Hi Jeff--
>>
>> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
>>
>> Cheers
>> Steve
>>
>> ----- Original Message -----
>> From: "Jeff Mangum" <jmangum at nrao.edu>
>> To: astropy at scipy.org
>> Sent: Friday, October 16, 2015 3:11:56 PM
>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>
>> Hello,
>>
>> Long-time listener but first-time caller.  Have been trying to use the
>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>> Gaussian to an image (in FITS format).  Here is my script:
>>
>> import numpy as np
>> import radio_beam
>> from astropy.modeling import models, fitting
>> from astropy import units as u
>> from astropy.io import fits
>> import astropy.coordinates as coord
>> import astropy.wcs as wcs
>> import matplotlib
>> import pylab as pl
>>
>> # The following is the position of the peak in both J1 and J2, so use
>> # it as the starting guess
>> ra0 = '13h15m03.50s'
>> dec0 = '24d37m08.2s'
>>
>> radeg = coord.Angle(ra0, unit=u.hour).degree
>> decdeg = coord.Angle(dec0, unit=u.degree)
>>
>> # Now open the image
>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>> w = wcs.WCS(hdulist[0].header, hdulist)
>>
>> yy,xx = np.indices(hdulist[0].data.shape)
>>
>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>
>> # Now fit 2D gaussian
>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>> x_stddev=1, y_stddev=1)
>> fit_g = fitting.LevMarLSQFitter()
>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>
>>
>> When I look at g_init (which is where I believe the fit results should
>> be), I see that the fit has not moved from its initial settings.  It
>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>> have a workaround using gaussfitter, but would certainly like to make
>> this work with astropy.models.  Thanks!
>>
>> -- Jeff
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>> !DSPAM:5620f7a993681466218807!
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



From d.f.evans at keele.ac.uk  Mon Oct 19 11:19:22 2015
From: d.f.evans at keele.ac.uk (Daniel Evans)
Date: Mon, 19 Oct 2015 16:19:22 +0100
Subject: [AstroPy] Opening 2MASS fits file returns all NaN data
Message-ID: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>

Hello all,

I am attempting to open a set of .fits files containing 2MASS images using
astropy.io.fits (astropy v1.0.4). The files open without any errors, the
headers show correctly, and the data array has the correct shape, but all
the data values are set to NaN.

DS9 is able to display the images without any problem, whilst pyfits v3.3.0
shows the same problem (perhaps unsurprising).

An example file is available at:
http://www.astro.keele.ac.uk/~devans/WASP-99_aH_asky_991014s1130092.fits

Any thoughts?

Regards,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151019/c2f7293d/attachment.html>

From burtscher at mpe.mpg.de  Mon Oct 19 11:28:29 2015
From: burtscher at mpe.mpg.de (Leonard Burtscher)
Date: Mon, 19 Oct 2015 17:28:29 +0200
Subject: [AstroPy] Opening 2MASS fits file returns all NaN data
In-Reply-To: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
References: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
Message-ID: <2D92EAC4-AF51-475A-BE50-44FBC3919E82@mpe.mpg.de>

Hi Daniel,

Are you sure the image is just NaNs if opened with astropy? When I open your file, I see some nans in the first column, but the rest of the image seems to be OK.

Can you try:
a=fits.open("WASP-99_aH_asky_991014s1130092.fits")
a[0].data[500,500]

It returns 352.42224 on my machine.

Cheers,
Leonard


> Am 19.10.2015 um 17:19 schrieb Daniel Evans <d.f.evans at keele.ac.uk>:
> 
> Hello all,
> 
> I am attempting to open a set of .fits files containing 2MASS images using astropy.io.fits (astropy v1.0.4). The files open without any errors, the headers show correctly, and the data array has the correct shape, but all the data values are set to NaN.
> 
> DS9 is able to display the images without any problem, whilst pyfits v3.3.0 shows the same problem (perhaps unsurprising).
> 
> An example file is available at: http://www.astro.keele.ac.uk/~devans/WASP-99_aH_asky_991014s1130092.fits
> 
> Any thoughts?
> 
> Regards,
> Daniel
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From bgarwood at nrao.edu  Mon Oct 19 11:29:26 2015
From: bgarwood at nrao.edu (Bob Garwood)
Date: Mon, 19 Oct 2015 11:29:26 -0400
Subject: [AstroPy] Opening 2MASS fits file returns all NaN data
In-Reply-To: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
References: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
Message-ID: <56250C56.1080503@nrao.edu>

I just used pyfits 3.3 to read in this file and the returned data values 
aren't all NaNs.  There's a lot of NaNs, but there's also plenty of 
finite values.

Bob

On 10/19/2015 11:19 AM, Daniel Evans wrote:
> Hello all,
>
> I am attempting to open a set of .fits files containing 2MASS images 
> using astropy.io.fits (astropy v1.0.4). The files open without any 
> errors, the headers show correctly, and the data array has the correct 
> shape, but all the data values are set to NaN.
>
> DS9 is able to display the images without any problem, whilst pyfits 
> v3.3.0 shows the same problem (perhaps unsurprising).
>
> An example file is available at: 
> http://www.astro.keele.ac.uk/~devans/WASP-99_aH_asky_991014s1130092.fits 
> <http://www.astro.keele.ac.uk/%7Edevans/WASP-99_aH_asky_991014s1130092.fits>
>
> Any thoughts?
>
> Regards,
> Daniel
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

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

From embray at stsci.edu  Mon Oct 19 11:30:25 2015
From: embray at stsci.edu (Erik Bray)
Date: Mon, 19 Oct 2015 11:30:25 -0400
Subject: [AstroPy] Opening 2MASS fits file returns all NaN data
In-Reply-To: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
References: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
Message-ID: <56250C91.6050701@stsci.edu>

On 10/19/2015 11:19 AM, Daniel Evans wrote:
> Hello all,
>
> I am attempting to open a set of .fits files containing 2MASS images using
> astropy.io.fits (astropy v1.0.4). The files open without any errors, the headers
> show correctly, and the data array has the correct shape, but all the data
> values are set to NaN.
>
> DS9 is able to display the images without any problem, whilst pyfits v3.3.0
> shows the same problem (perhaps unsurprising).
>
> An example file is available at:
> http://www.astro.keele.ac.uk/~devans/WASP-99_aH_asky_991014s1130092.fits
>
> Any thoughts?

There are just NaNs around the borders, which is typical.

Erik



From d.f.evans at keele.ac.uk  Mon Oct 19 11:32:06 2015
From: d.f.evans at keele.ac.uk (Daniel Evans)
Date: Mon, 19 Oct 2015 16:32:06 +0100
Subject: [AstroPy] Opening 2MASS fits file returns all NaN data
In-Reply-To: <2D92EAC4-AF51-475A-BE50-44FBC3919E82@mpe.mpg.de>
References: <CANnaQaZZ5zWzHikAfzsHJ4g7ZZER==w9hNR-pdQo65DAJCQ7Kw@mail.gmail.com>
 <2D92EAC4-AF51-475A-BE50-44FBC3919E82@mpe.mpg.de>
Message-ID: <CANnaQaZfVTT=HY7yObGigr_vDCv715MVqVr7pq6chi1mRNHM=g@mail.gmail.com>

Thanks Leonard (and many others!) for pointing out that I didn't look hard
enough - there's just enough of a border that my initial probing found
nothing but NaNs!

Regards,
Daniel

On 19 October 2015 at 16:28, Leonard Burtscher <burtscher at mpe.mpg.de> wrote:

> Hi Daniel,
>
> Are you sure the image is just NaNs if opened with astropy? When I open
> your file, I see some nans in the first column, but the rest of the image
> seems to be OK.
>
> Can you try:
> a=fits.open("WASP-99_aH_asky_991014s1130092.fits")
> a[0].data[500,500]
>
> It returns 352.42224 on my machine.
>
> Cheers,
> Leonard
>
>
> > Am 19.10.2015 um 17:19 schrieb Daniel Evans <d.f.evans at keele.ac.uk>:
> >
> > Hello all,
> >
> > I am attempting to open a set of .fits files containing 2MASS images
> using astropy.io.fits (astropy v1.0.4). The files open without any errors,
> the headers show correctly, and the data array has the correct shape, but
> all the data values are set to NaN.
> >
> > DS9 is able to display the images without any problem, whilst pyfits
> v3.3.0 shows the same problem (perhaps unsurprising).
> >
> > An example file is available at:
> http://www.astro.keele.ac.uk/~devans/WASP-99_aH_asky_991014s1130092.fits
> >
> > Any thoughts?
> >
> > Regards,
> > Daniel
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151019/f1126dc3/attachment.html>

From jmangum at nrao.edu  Mon Oct 19 14:45:27 2015
From: jmangum at nrao.edu (Jeff Mangum)
Date: Mon, 19 Oct 2015 14:45:27 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <56250575.3010307@stsci.edu>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
Message-ID: <56253A47.60500@nrao.edu>

Thanks for the responses.  Adam Ginsburg and I iterated a bit on this 
problem and found that the issue was the fact that the image I was 
fitting contained nans.  Once I removed the nans the gaussian fit 
routine works.  Note that if the fitter in astropy.models is not able to 
handle images with nans, then perhaps it should issue a warning.

-- Jeff

On 10/19/15 11:00 AM, Erik Bray wrote:
> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>>
>> Hi Jeff,
>> this is the kind of staff that usually happens if the position of the 
>> initial guess is too far away the right one. Did you plot the contour 
>> of the fitted gaussian on the image?
>> It can be also that the image is too noisy around the target to fit. 
>> I usually use only a little subarray around the target, then I search 
>> the position of the maximum and I set the initial guess of xo and yo 
>> to its position. After I normalize all the subarray to the value of 
>> the maximum and cut all the signal below a certain threshold (usually 
>> 0.1).
>> In this way I am able to obtain a robust fit also in very noisy map.
>
> I agree pretty much with all of Giuliano's advice.  And again it might 
> help to exclude data outside a smaller subarray.  Without actually 
> seeing the data it's hard to provide much other advice.
>
> Have you tried a different optimizer?  There are a couple other 
> non-linear fitters in the package and some have different 
> sensitivities to initial conditions.  But it's certainly not 
> "non-functional".
>
> Erik
>
>>> Hi Jeff--
>>>
>>> The fitted model will not be in g_init (this remains unchanged), but 
>>> in g.   If you take a look in g, you should be able to see the 
>>> fitted results.
>>>
>>> Cheers
>>> Steve
>>>
>>> ----- Original Message -----
>>> From: "Jeff Mangum" <jmangum at nrao.edu>
>>> To: astropy at scipy.org
>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>>
>>> Hello,
>>>
>>> Long-time listener but first-time caller.  Have been trying to use the
>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>> Gaussian to an image (in FITS format).  Here is my script:
>>>
>>> import numpy as np
>>> import radio_beam
>>> from astropy.modeling import models, fitting
>>> from astropy import units as u
>>> from astropy.io import fits
>>> import astropy.coordinates as coord
>>> import astropy.wcs as wcs
>>> import matplotlib
>>> import pylab as pl
>>>
>>> # The following is the position of the peak in both J1 and J2, so use
>>> # it as the starting guess
>>> ra0 = '13h15m03.50s'
>>> dec0 = '24d37m08.2s'
>>>
>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>>
>>> # Now open the image
>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>>
>>> yy,xx = np.indices(hdulist[0].data.shape)
>>>
>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>>
>>> # Now fit 2D gaussian
>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>> x_stddev=1, y_stddev=1)
>>> fit_g = fitting.LevMarLSQFitter()
>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>>
>>>
>>> When I look at g_init (which is where I believe the fit results should
>>> be), I see that the fit has not moved from its initial settings.  It
>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>> have a workaround using gaussfitter, but would certainly like to make
>>> this work with astropy.models.  Thanks!
>>>
>>> -- Jeff
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>> !DSPAM:5620f7a993681466218807!
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



From johnw at lyric.com  Mon Oct 19 17:56:02 2015
From: johnw at lyric.com (John Wainwright)
Date: Mon, 19 Oct 2015 14:56:02 -0700
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <56253A47.60500@nrao.edu>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu>
Message-ID: <9146A406-94D8-4099-860E-6571606C7488@lyric.com>

Just on the topic of PSF fitting, is there any plan to implement Moffat PSF models?  I'm trying to replicate some of the PSF fitting <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html> capabilities found in PixInsight <http://pixinsight.com/> which provides excellent Moffat modeling support.

Thanks very much,
John.

> On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu> wrote:
> 
> Thanks for the responses.  Adam Ginsburg and I iterated a bit on this problem and found that the issue was the fact that the image I was fitting contained nans.  Once I removed the nans the gaussian fit routine works.  Note that if the fitter in astropy.models is not able to handle images with nans, then perhaps it should issue a warning.
> 
> -- Jeff
> 
> On 10/19/15 11:00 AM, Erik Bray wrote:
>> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>>> 
>>> Hi Jeff,
>>> this is the kind of staff that usually happens if the position of the initial guess is too far away the right one. Did you plot the contour of the fitted gaussian on the image?
>>> It can be also that the image is too noisy around the target to fit. I usually use only a little subarray around the target, then I search the position of the maximum and I set the initial guess of xo and yo to its position. After I normalize all the subarray to the value of the maximum and cut all the signal below a certain threshold (usually 0.1).
>>> In this way I am able to obtain a robust fit also in very noisy map.
>> 
>> I agree pretty much with all of Giuliano's advice.  And again it might help to exclude data outside a smaller subarray.  Without actually seeing the data it's hard to provide much other advice.
>> 
>> Have you tried a different optimizer?  There are a couple other non-linear fitters in the package and some have different sensitivities to initial conditions.  But it's certainly not "non-functional".
>> 
>> Erik
>> 
>>>> Hi Jeff--
>>>> 
>>>> The fitted model will not be in g_init (this remains unchanged), but in g.   If you take a look in g, you should be able to see the fitted results.
>>>> 
>>>> Cheers
>>>> Steve
>>>> 
>>>> ----- Original Message -----
>>>> From: "Jeff Mangum" <jmangum at nrao.edu>
>>>> To: astropy at scipy.org
>>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>>> 
>>>> Hello,
>>>> 
>>>> Long-time listener but first-time caller.  Have been trying to use the
>>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>>> Gaussian to an image (in FITS format).  Here is my script:
>>>> 
>>>> import numpy as np
>>>> import radio_beam
>>>> from astropy.modeling import models, fitting
>>>> from astropy import units as u
>>>> from astropy.io import fits
>>>> import astropy.coordinates as coord
>>>> import astropy.wcs as wcs
>>>> import matplotlib
>>>> import pylab as pl
>>>> 
>>>> # The following is the position of the peak in both J1 and J2, so use
>>>> # it as the starting guess
>>>> ra0 = '13h15m03.50s'
>>>> dec0 = '24d37m08.2s'
>>>> 
>>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>>> 
>>>> # Now open the image
>>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>>> 
>>>> yy,xx = np.indices(hdulist[0].data.shape)
>>>> 
>>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>>> 
>>>> # Now fit 2D gaussian
>>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>>> x_stddev=1, y_stddev=1)
>>>> fit_g = fitting.LevMarLSQFitter()
>>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>>> 
>>>> 
>>>> When I look at g_init (which is where I believe the fit results should
>>>> be), I see that the fit has not moved from its initial settings.  It
>>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>>> have a workaround using gaussfitter, but would certainly like to make
>>>> this work with astropy.models.  Thanks!
>>>> 
>>>> -- Jeff
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>> 
>>>> !DSPAM:5620f7a993681466218807!
>>>> 
>>>> 
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 

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

From embray at stsci.edu  Tue Oct 20 10:01:22 2015
From: embray at stsci.edu (Erik Bray)
Date: Tue, 20 Oct 2015 10:01:22 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu> <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
Message-ID: <56264932.2020404@stsci.edu>

On 10/19/2015 05:56 PM, John Wainwright wrote:
> Just on the topic of PSF fitting, is there any plan to implement Moffat PSF
> models?  I'm trying to replicate some of the PSF fitting
> <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html> capabilities found
> in PixInsight <http://pixinsight.com/> which provides excellent Moffat modeling
> support.

Well, there are are already these implementations:

http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D

http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D

So you can check how they compare.  You can also always add your own version:

http://docs.astropy.org/en/latest/modeling/new.html



>> On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu
>> <mailto:jmangum at nrao.edu>> wrote:
>>
>> Thanks for the responses.  Adam Ginsburg and I iterated a bit on this problem
>> and found that the issue was the fact that the image I was fitting contained
>> nans.  Once I removed the nans the gaussian fit routine works.  Note that if
>> the fitter in astropy.models is not able to handle images with nans, then
>> perhaps it should issue a warning.
>>
>> -- Jeff
>>
>> On 10/19/15 11:00 AM, Erik Bray wrote:
>>> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>>>>
>>>> Hi Jeff,
>>>> this is the kind of staff that usually happens if the position of the
>>>> initial guess is too far away the right one. Did you plot the contour of the
>>>> fitted gaussian on the image?
>>>> It can be also that the image is too noisy around the target to fit. I
>>>> usually use only a little subarray around the target, then I search the
>>>> position of the maximum and I set the initial guess of xo and yo to its
>>>> position. After I normalize all the subarray to the value of the maximum and
>>>> cut all the signal below a certain threshold (usually 0.1).
>>>> In this way I am able to obtain a robust fit also in very noisy map.
>>>
>>> I agree pretty much with all of Giuliano's advice.  And again it might help
>>> to exclude data outside a smaller subarray.  Without actually seeing the data
>>> it's hard to provide much other advice.
>>>
>>> Have you tried a different optimizer?  There are a couple other non-linear
>>> fitters in the package and some have different sensitivities to initial
>>> conditions.  But it's certainly not "non-functional".
>>>
>>> Erik
>>>
>>>>> Hi Jeff--
>>>>>
>>>>> The fitted model will not be in g_init (this remains unchanged), but in g.
>>>>>   If you take a look in g, you should be able to see the fitted results.
>>>>>
>>>>> Cheers
>>>>> Steve
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Jeff Mangum" <jmangum at nrao.edu <mailto:jmangum at nrao.edu>>
>>>>> To: astropy at scipy.org <mailto:astropy at scipy.org>
>>>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>>>>
>>>>> Hello,
>>>>>
>>>>> Long-time listener but first-time caller.  Have been trying to use the
>>>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>>>> Gaussian to an image (in FITS format).  Here is my script:
>>>>>
>>>>> import numpy as np
>>>>> import radio_beam
>>>>> from astropy.modeling import models, fitting
>>>>> from astropy import units as u
>>>>> from astropy.io import fits
>>>>> import astropy.coordinates as coord
>>>>> import astropy.wcs as wcs
>>>>> import matplotlib
>>>>> import pylab as pl
>>>>>
>>>>> # The following is the position of the peak in both J1 and J2, so use
>>>>> # it as the starting guess
>>>>> ra0 = '13h15m03.50s'
>>>>> dec0 = '24d37m08.2s'
>>>>>
>>>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>>>>
>>>>> # Now open the image
>>>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>>>>
>>>>> yy,xx = np.indices(hdulist[0].data.shape)
>>>>>
>>>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>>>>
>>>>> # Now fit 2D gaussian
>>>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>>>> x_stddev=1, y_stddev=1)
>>>>> fit_g = fitting.LevMarLSQFitter()
>>>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>>>>
>>>>>
>>>>> When I look at g_init (which is where I believe the fit results should
>>>>> be), I see that the fit has not moved from its initial settings.  It
>>>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>>>> have a workaround using gaussfitter, but would certainly like to make
>>>>> this work with astropy.models.  Thanks!
>>>>>
>>>>> -- Jeff



From ghang.naoc at gmail.com  Thu Oct 22 00:21:01 2015
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Thu, 22 Oct 2015 12:21:01 +0800
Subject: [AstroPy] timeing analysis(scipy.fftpack)
Message-ID: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>

Hi all,
Does anyone use scipy.fftpack to do power spectrum for time series?
Its doc file is here:
http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/fftpack.html

What does the y axis in figure 1 and figure 2 mean? In Figure 1, it seems y
axis does not  stand for the sifnificane at least.

Besides FFT, I use Lomb-Scargle to do timing analysis, and find there is a
big difference between the significance given by L-S and fft. Significant
peaks which appear in L-S do not necessarily appear in FFT.
Which method should I believe then?

Thank you.
regards
Hang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/efe773c5/attachment.html>

From matteo at matteobachetti.it  Thu Oct 22 03:20:57 2015
From: matteo at matteobachetti.it (Matteo)
Date: Thu, 22 Oct 2015 09:20:57 +0200
Subject: [AstroPy] timeing analysis(scipy.fftpack)
In-Reply-To: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>
References: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>
Message-ID: <CACygX+ZgudvcBf1yOoTD8OEPS2uFNYuEHhNsERxuTZRUdK-+=Q@mail.gmail.com>

Hi Hang,
that plot does not measure significance but just the value of the FFT. In
the real world, significance depends also on the uncertainties of the time
series. For example, for event data (and Poisson-distributed light curves)
people often calculate the power density spectrum (|FFT|^2) and normalize
it by 2 / <number of photons>. Then, significances are calculated based on
the chi^2 statistics (Leahy et al. '83).

For the comparison between L-S and fft, it's difficult to answer without at
least some example data. Do you take the square modulus of the FFT? Do you
use an irregular sampling? Do you have gaps in data? How do you normalize
the periodograms?  Etc.
e.g.
http://stackoverflow.com/questions/20658318/my-power-spectra-are-believable-a-comparison-between-lomb-scargle-and-fft-scip

Cheers,

Matteo


PS: for X-ray timing analysis, you can take a look at
http://maltpynt.readthedocs.org


On Thu, Oct 22, 2015 at 6:21 AM, gonghang.naoc <ghang.naoc at gmail.com> wrote:

> Hi all,
> Does anyone use scipy.fftpack to do power spectrum for time series?
> Its doc file is here:
> http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/fftpack.html
>
> What does the y axis in figure 1 and figure 2 mean? In Figure 1, it seems
> y axis does not  stand for the sifnificane at least.
>
> Besides FFT, I use Lomb-Scargle to do timing analysis, and find there is a
> big difference between the significance given by L-S and fft. Significant
> peaks which appear in L-S do not necessarily appear in FFT.
> Which method should I believe then?
>
> Thank you.
> regards
> Hang
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
*********************************************
Matteo Bachetti

www.matteobachetti.it

"I would love to change the world,
but they won't give me the source code"
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/130ee4c4/attachment.html>

From ghang.naoc at gmail.com  Thu Oct 22 04:29:56 2015
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Thu, 22 Oct 2015 16:29:56 +0800
Subject: [AstroPy] timeing analysis(scipy.fftpack)
In-Reply-To: <CACygX+ZgudvcBf1yOoTD8OEPS2uFNYuEHhNsERxuTZRUdK-+=Q@mail.gmail.com>
References: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>
 <CACygX+ZgudvcBf1yOoTD8OEPS2uFNYuEHhNsERxuTZRUdK-+=Q@mail.gmail.com>
Message-ID: <CABb23ms85fyveNKLjyPfMwHKSLCtTvOxMBfggF0SLGQP+CaihQ@mail.gmail.com>

Hi Matteo,
L-S and FFT should get a similar result  if we 'treat' the data correctly?
Using the same regularly sampled data, I meet artifacts generated by some
method, but this kind of artifact does not necessarily appear in some other
method.

Hang

On Thu, Oct 22, 2015 at 3:20 PM, Matteo <matteo at matteobachetti.it> wrote:

> Hi Hang,
> that plot does not measure significance but just the value of the FFT. In
> the real world, significance depends also on the uncertainties of the time
> series. For example, for event data (and Poisson-distributed light curves)
> people often calculate the power density spectrum (|FFT|^2) and normalize
> it by 2 / <number of photons>. Then, significances are calculated based on
> the chi^2 statistics (Leahy et al. '83).
>
> For the comparison between L-S and fft, it's difficult to answer without
> at least some example data. Do you take the square modulus of the FFT? Do
> you use an irregular sampling? Do you have gaps in data? How do you
> normalize the periodograms?  Etc.
> e.g.
> http://stackoverflow.com/questions/20658318/my-power-spectra-are-believable-a-comparison-between-lomb-scargle-and-fft-scip
>
> Cheers,
>
> Matteo
>
>
> PS: for X-ray timing analysis, you can take a look at
> http://maltpynt.readthedocs.org
>
>
> On Thu, Oct 22, 2015 at 6:21 AM, gonghang.naoc <ghang.naoc at gmail.com>
> wrote:
>
>> Hi all,
>> Does anyone use scipy.fftpack to do power spectrum for time series?
>> Its doc file is here:
>> http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/fftpack.html
>>
>> What does the y axis in figure 1 and figure 2 mean? In Figure 1, it seems
>> y axis does not  stand for the sifnificane at least.
>>
>> Besides FFT, I use Lomb-Scargle to do timing analysis, and find there is
>> a big difference between the significance given by L-S and fft. Significant
>> peaks which appear in L-S do not necessarily appear in FFT.
>> Which method should I believe then?
>>
>> Thank you.
>> regards
>> Hang
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
> --
> *********************************************
> Matteo Bachetti
>
> www.matteobachetti.it
>
> "I would love to change the world,
> but they won't give me the source code"
> *********************************************
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/362e686a/attachment.html>

From matteo at matteobachetti.it  Thu Oct 22 05:54:16 2015
From: matteo at matteobachetti.it (Matteo)
Date: Thu, 22 Oct 2015 11:54:16 +0200
Subject: [AstroPy] timeing analysis(scipy.fftpack)
In-Reply-To: <CABb23ms85fyveNKLjyPfMwHKSLCtTvOxMBfggF0SLGQP+CaihQ@mail.gmail.com>
References: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>
 <CACygX+ZgudvcBf1yOoTD8OEPS2uFNYuEHhNsERxuTZRUdK-+=Q@mail.gmail.com>
 <CABb23ms85fyveNKLjyPfMwHKSLCtTvOxMBfggF0SLGQP+CaihQ@mail.gmail.com>
Message-ID: <CACygX+Zrba+fwfpgsRDMLLtZcBz7M6q69tfhDSg_TBc9MpGYMg@mail.gmail.com>

Hi Hang,


> L-S and FFT should get a similar result  if we 'treat' the data correctly?
>
In principle yes.


> Using the same regularly sampled data, I meet artifacts generated by some
> method, but this kind of artifact does not necessarily appear in some other
> method.
>
Artifacts might be given by a number of different effects. What kinds of
artifacts are you talking about? Harmonics? Peaks at regular frequencies?
Do you have gaps in your time series?

Can you provide a minimum working example with a few lines of the code used
to calculate the spectra and a sample data file? You can copy and paste
some code from this iPython notebook to simulate noisy pulsar data if you
want (Section Finding pulsars: the buried clock):
https://bitbucket.org/mbachett/timing-lectures/src/8ac9774f2c8a8d33e8f214af0045801ced32f539/Pulsar_Timing.ipynb?at=master&fileviewer=file-view-default

Cheers,
Matteo


>
> Hang
>
> On Thu, Oct 22, 2015 at 3:20 PM, Matteo <matteo at matteobachetti.it> wrote:
>
>> Hi Hang,
>> that plot does not measure significance but just the value of the FFT. In
>> the real world, significance depends also on the uncertainties of the time
>> series. For example, for event data (and Poisson-distributed light curves)
>> people often calculate the power density spectrum (|FFT|^2) and normalize
>> it by 2 / <number of photons>. Then, significances are calculated based on
>> the chi^2 statistics (Leahy et al. '83).
>>
>> For the comparison between L-S and fft, it's difficult to answer without
>> at least some example data. Do you take the square modulus of the FFT? Do
>> you use an irregular sampling? Do you have gaps in data? How do you
>> normalize the periodograms?  Etc.
>> e.g.
>> http://stackoverflow.com/questions/20658318/my-power-spectra-are-believable-a-comparison-between-lomb-scargle-and-fft-scip
>>
>> Cheers,
>>
>> Matteo
>>
>>
>> PS: for X-ray timing analysis, you can take a look at
>> http://maltpynt.readthedocs.org
>>
>>
>> On Thu, Oct 22, 2015 at 6:21 AM, gonghang.naoc <ghang.naoc at gmail.com>
>> wrote:
>>
>>> Hi all,
>>> Does anyone use scipy.fftpack to do power spectrum for time series?
>>> Its doc file is here:
>>> http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/fftpack.html
>>>
>>> What does the y axis in figure 1 and figure 2 mean? In Figure 1, it
>>> seems y axis does not  stand for the sifnificane at least.
>>>
>>> Besides FFT, I use Lomb-Scargle to do timing analysis, and find there is
>>> a big difference between the significance given by L-S and fft. Significant
>>> peaks which appear in L-S do not necessarily appear in FFT.
>>> Which method should I believe then?
>>>
>>> Thank you.
>>> regards
>>> Hang
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>
>>
>> --
>> *********************************************
>> Matteo Bachetti
>>
>> www.matteobachetti.it
>>
>> "I would love to change the world,
>> but they won't give me the source code"
>> *********************************************
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
*********************************************
Matteo Bachetti

www.matteobachetti.it

"I would love to change the world,
but they won't give me the source code"
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/db784f68/attachment.html>

From matteo at matteobachetti.it  Thu Oct 22 06:18:57 2015
From: matteo at matteobachetti.it (Matteo)
Date: Thu, 22 Oct 2015 12:18:57 +0200
Subject: [AstroPy] timeing analysis(scipy.fftpack)
In-Reply-To: <CABb23ms85fyveNKLjyPfMwHKSLCtTvOxMBfggF0SLGQP+CaihQ@mail.gmail.com>
References: <CABb23mvfAH9TRh=MZaSjFyUbGg9sak8mdozHHc10tmnanrne8g@mail.gmail.com>
 <CACygX+ZgudvcBf1yOoTD8OEPS2uFNYuEHhNsERxuTZRUdK-+=Q@mail.gmail.com>
 <CABb23ms85fyveNKLjyPfMwHKSLCtTvOxMBfggF0SLGQP+CaihQ@mail.gmail.com>
Message-ID: <CACygX+bDJ301BCd2NMO953a+gf2CUued=aAo+7XNYa1-DKE2vA@mail.gmail.com>

Hi Hang,


> L-S and FFT should get a similar result  if we 'treat' the data correctly?
>
In principle yes.


> Using the same regularly sampled data, I meet artifacts generated by some
> method, but this kind of artifact does not necessarily appear in some other
> method.
>
Artifacts might be given by a number of different effects. What kinds of
artifacts are you talking about? Harmonics? Peaks at regular frequencies?
Do you have gaps in your time series?

Can you provide a minimum working example with a few lines of the code used
to calculate the spectra and a sample data file? If you have proprietary
data problems, you can simulate them. Copy and paste some code from this
iPython notebook if you want (Section Finding pulsars: the buried clock):
https://bitbucket.org/mbachett/timing-lectures/src/8ac9774f2c8a8d33e8f214af0045801ced32f539/Pulsar_Timing.ipynb?at=master&fileviewer=file-view-default

Cheers,
Matteo



>
> Hang
>
> On Thu, Oct 22, 2015 at 3:20 PM, Matteo <matteo at matteobachetti.it> wrote:
>
>> Hi Hang,
>> that plot does not measure significance but just the value of the FFT. In
>> the real world, significance depends also on the uncertainties of the time
>> series. For example, for event data (and Poisson-distributed light curves)
>> people often calculate the power density spectrum (|FFT|^2) and normalize
>> it by 2 / <number of photons>. Then, significances are calculated based on
>> the chi^2 statistics (Leahy et al. '83).
>>
>> For the comparison between L-S and fft, it's difficult to answer without
>> at least some example data. Do you take the square modulus of the FFT? Do
>> you use an irregular sampling? Do you have gaps in data? How do you
>> normalize the periodograms?  Etc.
>> e.g.
>> http://stackoverflow.com/questions/20658318/my-power-spectra-are-believable-a-comparison-between-lomb-scargle-and-fft-scip
>>
>> Cheers,
>>
>> Matteo
>>
>>
>> PS: for X-ray timing analysis, you can take a look at
>> http://maltpynt.readthedocs.org
>>
>>
>> On Thu, Oct 22, 2015 at 6:21 AM, gonghang.naoc <ghang.naoc at gmail.com>
>> wrote:
>>
>>> Hi all,
>>> Does anyone use scipy.fftpack to do power spectrum for time series?
>>> Its doc file is here:
>>> http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/fftpack.html
>>>
>>> What does the y axis in figure 1 and figure 2 mean? In Figure 1, it
>>> seems y axis does not  stand for the sifnificane at least.
>>>
>>> Besides FFT, I use Lomb-Scargle to do timing analysis, and find there is
>>> a big difference between the significance given by L-S and fft. Significant
>>> peaks which appear in L-S do not necessarily appear in FFT.
>>> Which method should I believe then?
>>>
>>> Thank you.
>>> regards
>>> Hang
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>
>>
>> --
>> *********************************************
>> Matteo Bachetti
>>
>> www.matteobachetti.it
>>
>> "I would love to change the world,
>> but they won't give me the source code"
>> *********************************************
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
*********************************************
Matteo Bachetti

www.matteobachetti.it

"I would love to change the world,
but they won't give me the source code"
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/53eabb73/attachment.html>

From johnw at lyric.com  Thu Oct 22 12:08:57 2015
From: johnw at lyric.com (John Wainwright)
Date: Thu, 22 Oct 2015 09:08:57 -0700
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <56264932.2020404@stsci.edu>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu> <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
 <56264932.2020404@stsci.edu>
Message-ID: <D81F0037-2771-4D89-B5AC-C9417D531446@lyric.com>

Thanks Erik, and sorry, I should have found those.  I realize now I was asking relative to the detect_sources() and segment_properties() functions in the photutils <http://photutils.readthedocs.org/en/latest/index.html> affiliate package, which I think use a 2D Gaussian fit to generate the basic morphological properties I've been getting.   Presumably, I could use the centroids from that data as peak seeds for a Moffat2D model fit.

Thanks again,
John.

> On Oct 20, 2015, at 7:01 AM, Erik Bray <embray at stsci.edu> wrote:
> 
> On 10/19/2015 05:56 PM, John Wainwright wrote:
>> Just on the topic of PSF fitting, is there any plan to implement Moffat PSF
>> models?  I'm trying to replicate some of the PSF fitting
>> <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html> capabilities found
>> in PixInsight <http://pixinsight.com/> which provides excellent Moffat modeling
>> support.
> 
> Well, there are are already these implementations:
> 
> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D
> 
> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D
> 
> So you can check how they compare.  You can also always add your own version:
> 
> http://docs.astropy.org/en/latest/modeling/new.html
> 
> 
> 
>>> On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu
>>> <mailto:jmangum at nrao.edu>> wrote:
>>> 
>>> Thanks for the responses.  Adam Ginsburg and I iterated a bit on this problem
>>> and found that the issue was the fact that the image I was fitting contained
>>> nans.  Once I removed the nans the gaussian fit routine works.  Note that if
>>> the fitter in astropy.models is not able to handle images with nans, then
>>> perhaps it should issue a warning.
>>> 
>>> -- Jeff
>>> 
>>> On 10/19/15 11:00 AM, Erik Bray wrote:
>>>> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>>>>> 
>>>>> Hi Jeff,
>>>>> this is the kind of staff that usually happens if the position of the
>>>>> initial guess is too far away the right one. Did you plot the contour of the
>>>>> fitted gaussian on the image?
>>>>> It can be also that the image is too noisy around the target to fit. I
>>>>> usually use only a little subarray around the target, then I search the
>>>>> position of the maximum and I set the initial guess of xo and yo to its
>>>>> position. After I normalize all the subarray to the value of the maximum and
>>>>> cut all the signal below a certain threshold (usually 0.1).
>>>>> In this way I am able to obtain a robust fit also in very noisy map.
>>>> 
>>>> I agree pretty much with all of Giuliano's advice.  And again it might help
>>>> to exclude data outside a smaller subarray.  Without actually seeing the data
>>>> it's hard to provide much other advice.
>>>> 
>>>> Have you tried a different optimizer?  There are a couple other non-linear
>>>> fitters in the package and some have different sensitivities to initial
>>>> conditions.  But it's certainly not "non-functional".
>>>> 
>>>> Erik
>>>> 
>>>>>> Hi Jeff--
>>>>>> 
>>>>>> The fitted model will not be in g_init (this remains unchanged), but in g.
>>>>>>  If you take a look in g, you should be able to see the fitted results.
>>>>>> 
>>>>>> Cheers
>>>>>> Steve
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>> From: "Jeff Mangum" <jmangum at nrao.edu <mailto:jmangum at nrao.edu>>
>>>>>> To: astropy at scipy.org <mailto:astropy at scipy.org>
>>>>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>>>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Long-time listener but first-time caller.  Have been trying to use the
>>>>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>>>>> Gaussian to an image (in FITS format).  Here is my script:
>>>>>> 
>>>>>> import numpy as np
>>>>>> import radio_beam
>>>>>> from astropy.modeling import models, fitting
>>>>>> from astropy import units as u
>>>>>> from astropy.io import fits
>>>>>> import astropy.coordinates as coord
>>>>>> import astropy.wcs as wcs
>>>>>> import matplotlib
>>>>>> import pylab as pl
>>>>>> 
>>>>>> # The following is the position of the peak in both J1 and J2, so use
>>>>>> # it as the starting guess
>>>>>> ra0 = '13h15m03.50s'
>>>>>> dec0 = '24d37m08.2s'
>>>>>> 
>>>>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>>>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>>>>> 
>>>>>> # Now open the image
>>>>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>>>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>>>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>>>>> 
>>>>>> yy,xx = np.indices(hdulist[0].data.shape)
>>>>>> 
>>>>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>>>>> 
>>>>>> # Now fit 2D gaussian
>>>>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>>>>> x_stddev=1, y_stddev=1)
>>>>>> fit_g = fitting.LevMarLSQFitter()
>>>>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>>>>> 
>>>>>> 
>>>>>> When I look at g_init (which is where I believe the fit results should
>>>>>> be), I see that the fit has not moved from its initial settings.  It
>>>>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>>>>> have a workaround using gaussfitter, but would certainly like to make
>>>>>> this work with astropy.models.  Thanks!
>>>>>> 
>>>>>> -- Jeff
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 

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

From lbradley at stsci.edu  Thu Oct 22 12:19:19 2015
From: lbradley at stsci.edu (Larry Bradley)
Date: Thu, 22 Oct 2015 12:19:19 -0400
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <D81F0037-2771-4D89-B5AC-C9417D531446@lyric.com>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu> <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
 <56264932.2020404@stsci.edu> <D81F0037-2771-4D89-B5AC-C9417D531446@lyric.com>
Message-ID: <CAFfmSa3sVHCEB=Cd3iKW9Rw66n_CS8A5qqKQGWxqwzmLk6ypQw@mail.gmail.com>

Hi John,

Just to clarify, the morphological properties calculated by
photutils.segment_properties() are derived from the 2D image moments of the
source (within the defined segment) -- 2D Gaussian fits are not used
there.  Photutils also has a local peak finder (photutils.find_peaks()),
which does have an option to use a 2D Gaussian fit for better precision.

Cheers,
Larry

On Thu, Oct 22, 2015 at 12:08 PM, John Wainwright <johnw at lyric.com> wrote:

> Thanks Erik, and sorry, I should have found those.  I realize now I was
> asking relative to the detect_sources() and segment_properties() functions
> in the photutils <http://photutils.readthedocs.org/en/latest/index.html> affiliate
> package, which I think use a 2D Gaussian fit to generate the basic
> morphological properties I've been getting.   Presumably, I could use the
> centroids from that data as peak seeds for a Moffat2D model fit.
>
> Thanks again,
> John.
>
> On Oct 20, 2015, at 7:01 AM, Erik Bray <embray at stsci.edu> wrote:
>
> On 10/19/2015 05:56 PM, John Wainwright wrote:
>
> Just on the topic of PSF fitting, is there any plan to implement Moffat PSF
> models?  I'm trying to replicate some of the PSF fitting
> <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html> capabilities
> found
> in PixInsight <http://pixinsight.com/> which provides excellent Moffat
> modeling
> support.
>
>
> Well, there are are already these implementations:
>
>
> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D
>
>
> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D
>
> So you can check how they compare.  You can also always add your own
> version:
>
> http://docs.astropy.org/en/latest/modeling/new.html
>
>
>
> On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu
> <mailto:jmangum at nrao.edu>> wrote:
>
> Thanks for the responses.  Adam Ginsburg and I iterated a bit on this
> problem
> and found that the issue was the fact that the image I was fitting
> contained
> nans.  Once I removed the nans the gaussian fit routine works.  Note that
> if
> the fitter in astropy.models is not able to handle images with nans, then
> perhaps it should issue a warning.
>
> -- Jeff
>
> On 10/19/15 11:00 AM, Erik Bray wrote:
>
> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>
>
> Hi Jeff,
> this is the kind of staff that usually happens if the position of the
> initial guess is too far away the right one. Did you plot the contour of
> the
> fitted gaussian on the image?
> It can be also that the image is too noisy around the target to fit. I
> usually use only a little subarray around the target, then I search the
> position of the maximum and I set the initial guess of xo and yo to its
> position. After I normalize all the subarray to the value of the maximum
> and
> cut all the signal below a certain threshold (usually 0.1).
> In this way I am able to obtain a robust fit also in very noisy map.
>
>
> I agree pretty much with all of Giuliano's advice.  And again it might help
> to exclude data outside a smaller subarray.  Without actually seeing the
> data
> it's hard to provide much other advice.
>
> Have you tried a different optimizer?  There are a couple other non-linear
> fitters in the package and some have different sensitivities to initial
> conditions.  But it's certainly not "non-functional".
>
> Erik
>
> Hi Jeff--
>
> The fitted model will not be in g_init (this remains unchanged), but in g.
>  If you take a look in g, you should be able to see the fitted results.
>
> Cheers
> Steve
>
> ----- Original Message -----
> From: "Jeff Mangum" <jmangum at nrao.edu <mailto:jmangum at nrao.edu>>
> To: astropy at scipy.org <mailto:astropy at scipy.org>
> Sent: Friday, October 16, 2015 3:11:56 PM
> Subject: [AstroPy] Gaussian models fitter non-functional?
>
> Hello,
>
> Long-time listener but first-time caller.  Have been trying to use the
> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
> Gaussian to an image (in FITS format).  Here is my script:
>
> import numpy as np
> import radio_beam
> from astropy.modeling import models, fitting
> from astropy import units as u
> from astropy.io import fits
> import astropy.coordinates as coord
> import astropy.wcs as wcs
> import matplotlib
> import pylab as pl
>
> # The following is the position of the peak in both J1 and J2, so use
> # it as the starting guess
> ra0 = '13h15m03.50s'
> dec0 = '24d37m08.2s'
>
> radeg = coord.Angle(ra0, unit=u.hour).degree
> decdeg = coord.Angle(dec0, unit=u.degree)
>
> # Now open the image
> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
> w = wcs.WCS(hdulist[0].header, hdulist)
>
> yy,xx = np.indices(hdulist[0].data.shape)
>
> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>
> # Now fit 2D gaussian
> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
> x_stddev=1, y_stddev=1)
> fit_g = fitting.LevMarLSQFitter()
> g = fit_g(g_init, xx, yy, hdulist[0].data)
>
>
> When I look at g_init (which is where I believe the fit results should
> be), I see that the fit has not moved from its initial settings.  It
> appears that the fitter just did not run.  With Adam Ginsburg's help I
> have a workaround using gaussfitter, but would certainly like to make
> this work with astropy.models.  Thanks!
>
> -- Jeff
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/991739c8/attachment.html>

From panopg at physics.uoc.gr  Thu Oct 22 13:06:19 2015
From: panopg at physics.uoc.gr (Gina Panopoulou)
Date: Thu, 22 Oct 2015 20:06:19 +0300
Subject: [AstroPy] aplpy.FITSFIgure: Fortran-only origin workaround?
Message-ID: <5629178B.1060502@physics.uoc.gr>

Hi everyone,

I'm having an issue with aplpy.FITSFigure's pixel2world.
When I try to overplot the center of a pixel on the image using
pixel2world (as shown below) it is misplaced ([1,1] is put where the
[0,0] pixel is). This offset obviously happens for all pixels.

import aplpy
import matplotlib.pyplot as plt

fig = aplpy.FITSFigure(fitsfilename)
fig.show_grayscale()
coords = fig.pixel2world([1],[1])
fig.show_circles(coords[0], coords[1], layer = 'l1', radius = 0.001)
plt.show()

I traced the root of the problem to the definitions of pixel2world (in
core.py) and pix2world (in wcs_util.py): they do not support non-Fortran
origins (i.e. 0) because when calling wcs_pix2world they use 1 as the
origin. I'm using aplpy version 0.9.13, but I checked and this has not
changed in v 1.0 .

So I wanted to ask if there is any way of telling FITSFigure that I want
it to use python-based indexing besides messing with the defs of these
functions, which is what I did now.

Thanks in advance,
Gina

-- 
G. V. Panopoulou
PhD student
Physics department
University of Crete
Heraklion, 71003, Greece


From embray at stsci.edu  Thu Oct 22 19:38:59 2015
From: embray at stsci.edu (Erik Bray)
Date: Thu, 22 Oct 2015 19:38:59 -0400
Subject: [AstroPy] [ANN] Astropy v1.0.6 released
Message-ID: <56297393.6070106@stsci.edu>

Hi all,

This is just a quick announcement that I've released v1.0.6 of Astropy--a new 
bug fix release.

The primary reason for this release is to complete support for Numpy v1.10. 
Previously, Astropy mostly supported Numpy v1.10, but there were some issues 
primarily in the FITS module.

A few other fixes came along for the ride, which you can check in the full 
changelog [1].

I should also note there is one known issue [2] due to a regression in Numpy 
itself that can cause severe slowdown in reading *some* FITS tables.  However, 
this only affects FITS tables that contain columns with very large 
multi-dimensional arrays as elements.  For example, binary tables that store 
images in a column.  The workaround, for now, is to downgrade to Numpy 1.9.x.

There is one other known issue I found while testing the release [3] that 
affects FITS tables on Numpy 1.10, but it is not likely to affect many users, if 
any.

Thanks,
Erik B.

[1] https://github.com/astropy/astropy/blob/v1.0.6/CHANGES.rst#106-2015-10-22
[2] https://github.com/astropy/astropy/issues/4259
[3] https://github.com/astropy/astropy/issues/4266


From pppzzzxxx at 163.com  Thu Oct 22 21:17:34 2015
From: pppzzzxxx at 163.com (peng)
Date: Fri, 23 Oct 2015 09:17:34 +0800
Subject: [AstroPy] [ANN] Astropy v1.0.6 released
In-Reply-To: <56297393.6070106@stsci.edu>
References: <56297393.6070106@stsci.edu>
Message-ID: <7C6B4612-342C-49F4-8BBB-0DB7C8BE94FD@163.com>

Hi Erik,

I upgrade my astropy to v1.0.6 but get the error message as follow. I think I need upgrade again via sudo, but previous astropy version haven?t this problem. 

###
    ?
    running build_ext
    running pre_hook from astropy._erfa.setup_package for build_ext command
    WARNING: The autogenerated wrappers in astropy._erfa seem to be older than the source templates used to create them. Because this is a release version we will use them anyway, but this might be a sign of some sort of version mismatch or other tampering. Or it might just mean you moved some files around or otherwise accidentally changed timestamps.
    building 'astropy._compiler' extension
    creating build/temp.macosx-10.6-intel-3.4
    creating build/temp.macosx-10.6-intel-3.4/astropy
    gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -g -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c astropy/_compiler.c -o build/temp.macosx-10.6-intel-3.4/astropy/_compiler.o


    Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.


    error: command 'gcc' failed with exit status 69

    ----------------------------------------
  Rolling back uninstall of astropy
Command "/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4 -c "import setuptools, tokenize;__file__='/private/var/folders/4d/lbvvpwxn5312rm6lb6q5xymw0000gn/T/pip-build-j6_obgnx/astropy/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/4d/lbvvpwxn5312rm6lb6q5xymw0000gn/T/pip-s8pi3w6y-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/4d/lbvvpwxn5312rm6lb6q5xymw0000gn/T/pip-build-j6_obgnx/astropy
#####

Cheers,
Peng


> ? 2015?10?23????07:38?Erik Bray <embray at stsci.edu> ???
> 
> Hi all,
> 
> This is just a quick announcement that I've released v1.0.6 of Astropy--a new bug fix release.
> 
> The primary reason for this release is to complete support for Numpy v1.10. Previously, Astropy mostly supported Numpy v1.10, but there were some issues primarily in the FITS module.
> 
> A few other fixes came along for the ride, which you can check in the full changelog [1].
> 
> I should also note there is one known issue [2] due to a regression in Numpy itself that can cause severe slowdown in reading *some* FITS tables.  However, this only affects FITS tables that contain columns with very large multi-dimensional arrays as elements.  For example, binary tables that store images in a column.  The workaround, for now, is to downgrade to Numpy 1.9.x.
> 
> There is one other known issue I found while testing the release [3] that affects FITS tables on Numpy 1.10, but it is not likely to affect many users, if any.
> 
> Thanks,
> Erik B.
> 
> [1] https://github.com/astropy/astropy/blob/v1.0.6/CHANGES.rst#106-2015-10-22
> [2] https://github.com/astropy/astropy/issues/4259
> [3] https://github.com/astropy/astropy/issues/4266
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy




From derek at astro.physik.uni-goettingen.de  Thu Oct 22 21:24:29 2015
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 23 Oct 2015 03:24:29 +0200
Subject: [AstroPy] [ANN] Astropy v1.0.6 released
In-Reply-To: <7C6B4612-342C-49F4-8BBB-0DB7C8BE94FD@163.com>
References: <56297393.6070106@stsci.edu>
 <7C6B4612-342C-49F4-8BBB-0DB7C8BE94FD@163.com>
Message-ID: <3EFDACA0-CC36-4F9B-AB55-24FCEDD16F77@astro.physik.uni-goettingen.de>

On 23 Oct 2015, at 3:17 am, peng <pppzzzxxx at 163.com> wrote:
> 
> 
>    Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.
> 
This is not specifically an Astropy issue, rather you have probably updated your Xcode installation
(to 7.1) and need to renew your license agreement. Try either (or all) of

sudo gcc -v
sudo xcode-select ?install
sudo xcode-select -switch /Applications/Xcode.app 

which should enable you to compile again.


					Derek



From pppzzzxxx at 163.com  Thu Oct 22 21:33:10 2015
From: pppzzzxxx at 163.com (peng)
Date: Fri, 23 Oct 2015 09:33:10 +0800
Subject: [AstroPy] [ANN] Astropy v1.0.6 released
In-Reply-To: <3EFDACA0-CC36-4F9B-AB55-24FCEDD16F77@astro.physik.uni-goettingen.de>
References: <56297393.6070106@stsci.edu>
 <7C6B4612-342C-49F4-8BBB-0DB7C8BE94FD@163.com>
 <3EFDACA0-CC36-4F9B-AB55-24FCEDD16F77@astro.physik.uni-goettingen.de>
Message-ID: <9C984055-BF04-490A-B478-6A0FB63DCE05@163.com>

Thanks Derek, I?ll try after update to OS X 10.11.1 and Xcode 7.1.

Thanks again,
Peng

> ? 2015?10?23????09:24?Derek Homeier <derek at astro.physik.uni-goettingen.de> ???
> 
> On 23 Oct 2015, at 3:17 am, peng <pppzzzxxx at 163.com> wrote:
>> 
>> 
>>   Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.
>> 
> This is not specifically an Astropy issue, rather you have probably updated your Xcode installation
> (to 7.1) and need to renew your license agreement. Try either (or all) of
> 
> sudo gcc -v
> sudo xcode-select ?install
> sudo xcode-select -switch /Applications/Xcode.app 
> 
> which should enable you to compile again.
> 
> 
> 					Derek
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy




From brendan.f.griffen at gmail.com  Thu Oct 22 22:07:26 2015
From: brendan.f.griffen at gmail.com (Brendan Griffen)
Date: Thu, 22 Oct 2015 22:07:26 -0400
Subject: [AstroPy] making a URL active in table.show_in_browser
Message-ID: <CABwppRZrTNDG=6-GqLKxBy5idPYTLEGwpH20jhu+4UFV5OdwPA@mail.gmail.com>

Hi,

I have a table which has a list of URLs. When I execute:

table.show_in_browser(jsviewer = True)

It does indeed launch in browser but the URLs are not active and are just
displayed at a string.

I tried to force the situation...

urls.append('<a href="'+webLink+'">'+webLink+'</a>')

Then I wrote that to the table, but that didn't work either.

Is there a work around?

Thanks.
Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/692e4551/attachment.html>

From aldcroft at head.cfa.harvard.edu  Thu Oct 22 22:47:26 2015
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Thu, 22 Oct 2015 22:47:26 -0400
Subject: [AstroPy] making a URL active in table.show_in_browser
In-Reply-To: <CABwppRZrTNDG=6-GqLKxBy5idPYTLEGwpH20jhu+4UFV5OdwPA@mail.gmail.com>
References: <CABwppRZrTNDG=6-GqLKxBy5idPYTLEGwpH20jhu+4UFV5OdwPA@mail.gmail.com>
Message-ID: <CAMtEP6zxPtv7_MhktDWtpj3r2MeOgyWLaxPGR9qw0GNYU-nNrQ@mail.gmail.com>

On Thu, Oct 22, 2015 at 10:07 PM, Brendan Griffen <
brendan.f.griffen at gmail.com> wrote:

> Hi,
>
> I have a table which has a list of URLs. When I execute:
>
> table.show_in_browser(jsviewer = True)
>
> It does indeed launch in browser but the URLs are not active and are just
> displayed at a string.
>
> I tried to force the situation...
>
> urls.append('<a href="'+webLink+'">'+webLink+'</a>')
>
> Then I wrote that to the table, but that didn't work either.
>
> Is there a work around?
>

I recently had this problem as well.  This happens because the HTML writer
automatically escapes "<" and ">" (and other special HTML characters).  In
the current code I don't believe there is a way to disable this.

If you are lucky enough that your table doesn't include any other "<" or
">" characters, you can do an easy workaround: start with your second
attempt of putting in <a href="..."> links, then in the output HTML do a
global regular expression replacement of &gt; with > and &lt; with <.

- Tom



>
> Thanks.
> Brendan
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151022/d3fd366b/attachment.html>

From johnw at lyric.com  Fri Oct 23 11:40:05 2015
From: johnw at lyric.com (John Wainwright)
Date: Fri, 23 Oct 2015 08:40:05 -0700
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <CAFfmSa3sVHCEB=Cd3iKW9Rw66n_CS8A5qqKQGWxqwzmLk6ypQw@mail.gmail.com>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu> <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
 <56264932.2020404@stsci.edu> <D81F0037-2771-4D89-B5AC-C9417D531446@lyric.com>
 <CAFfmSa3sVHCEB=Cd3iKW9Rw66n_CS8A5qqKQGWxqwzmLk6ypQw@mail.gmail.com>
Message-ID: <706D8C4D-2059-4435-867D-6BEE90245FEB@lyric.com>

Thanks Larry.  Sorry I?m coming up to speed on this somewhat haltingly.  I?m an amateur astrophotographer (some of my images here <https://www.flickr.com/photos/jbw/albums/72157631316034648>), as well as a software engineer, and I?m working on an image-cataloging program that, among other things monitors exposures as they are captured and reports things like FHWM, estimated SNR, any correlated PSF elongation, etc., to help tune a capture session.  Astropy has been an absolute boon for this effort.

From what I can see the 2D-Gaussian fit in find_peaks() is in the dev release, which I?ll upgrade to shortly, but it doesn?t seem to report mean or std-devs or orientation of the fitted model, which I think I need for some of the above.  

So, the trick would be to use find_peaks() to get the centroid and then create cut-outs around them that I give to the fitting & modeling functions in astropy, is that right?   Or simply use detect_sources() + segment_properties() to get the cut-outs and covariance matrix from their image-moment analysis to seed the 2D Moffat fit, or whichever model I might use.  How different would you expect say a Gaussian 2D model?s centroids & orientation & standard deviations be from the segment_properties() figures on the same source?

I do hope I?m not overstepping things here as an amateur bugging you guys for help.  

Best,
John.

> On Oct 22, 2015, at 9:19 AM, Larry Bradley <lbradley at stsci.edu> wrote:
> 
> Hi John,
> 
> Just to clarify, the morphological properties calculated by photutils.segment_properties() are derived from the 2D image moments of the source (within the defined segment) -- 2D Gaussian fits are not used there.  Photutils also has a local peak finder (photutils.find_peaks()), which does have an option to use a 2D Gaussian fit for better precision.
> 
> Cheers,
> Larry
> 
> On Thu, Oct 22, 2015 at 12:08 PM, John Wainwright <johnw at lyric.com <mailto:johnw at lyric.com>> wrote:
> Thanks Erik, and sorry, I should have found those.  I realize now I was asking relative to the detect_sources() and segment_properties() functions in the photutils <http://photutils.readthedocs.org/en/latest/index.html> affiliate package, which I think use a 2D Gaussian fit to generate the basic morphological properties I've been getting.   Presumably, I could use the centroids from that data as peak seeds for a Moffat2D model fit.
> 
> Thanks again,
> John.
> 
>> On Oct 20, 2015, at 7:01 AM, Erik Bray <embray at stsci.edu <mailto:embray at stsci.edu>> wrote:
>> 
>> On 10/19/2015 05:56 PM, John Wainwright wrote:
>>> Just on the topic of PSF fitting, is there any plan to implement Moffat PSF
>>> models?  I'm trying to replicate some of the PSF fitting
>>> <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html <http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html>> capabilities found
>>> in PixInsight <http://pixinsight.com/ <http://pixinsight.com/>> which provides excellent Moffat modeling
>>> support.
>> 
>> Well, there are are already these implementations:
>> 
>> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D <http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D>
>> 
>> http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D <http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D>
>> 
>> So you can check how they compare.  You can also always add your own version:
>> 
>> http://docs.astropy.org/en/latest/modeling/new.html <http://docs.astropy.org/en/latest/modeling/new.html>
>> 
>> 
>> 
>>>> On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu <mailto:jmangum at nrao.edu>
>>>> <mailto:jmangum at nrao.edu <mailto:jmangum at nrao.edu>>> wrote:
>>>> 
>>>> Thanks for the responses.  Adam Ginsburg and I iterated a bit on this problem
>>>> and found that the issue was the fact that the image I was fitting contained
>>>> nans.  Once I removed the nans the gaussian fit routine works.  Note that if
>>>> the fitter in astropy.models is not able to handle images with nans, then
>>>> perhaps it should issue a warning.
>>>> 
>>>> -- Jeff
>>>> 
>>>> On 10/19/15 11:00 AM, Erik Bray wrote:
>>>>> On 10/16/2015 09:47 AM, Giuliano Iorio wrote:
>>>>>> 
>>>>>> Hi Jeff,
>>>>>> this is the kind of staff that usually happens if the position of the
>>>>>> initial guess is too far away the right one. Did you plot the contour of the
>>>>>> fitted gaussian on the image?
>>>>>> It can be also that the image is too noisy around the target to fit. I
>>>>>> usually use only a little subarray around the target, then I search the
>>>>>> position of the maximum and I set the initial guess of xo and yo to its
>>>>>> position. After I normalize all the subarray to the value of the maximum and
>>>>>> cut all the signal below a certain threshold (usually 0.1).
>>>>>> In this way I am able to obtain a robust fit also in very noisy map.
>>>>> 
>>>>> I agree pretty much with all of Giuliano's advice.  And again it might help
>>>>> to exclude data outside a smaller subarray.  Without actually seeing the data
>>>>> it's hard to provide much other advice.
>>>>> 
>>>>> Have you tried a different optimizer?  There are a couple other non-linear
>>>>> fitters in the package and some have different sensitivities to initial
>>>>> conditions.  But it's certainly not "non-functional".
>>>>> 
>>>>> Erik
>>>>> 
>>>>>>> Hi Jeff--
>>>>>>> 
>>>>>>> The fitted model will not be in g_init (this remains unchanged), but in g.
>>>>>>>  If you take a look in g, you should be able to see the fitted results.
>>>>>>> 
>>>>>>> Cheers
>>>>>>> Steve
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>> From: "Jeff Mangum" <jmangum at nrao.edu <mailto:jmangum at nrao.edu> <mailto:jmangum at nrao.edu <mailto:jmangum at nrao.edu>>>
>>>>>>> To: astropy at scipy.org <mailto:astropy at scipy.org> <mailto:astropy at scipy.org <mailto:astropy at scipy.org>>
>>>>>>> Sent: Friday, October 16, 2015 3:11:56 PM
>>>>>>> Subject: [AstroPy] Gaussian models fitter non-functional?
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Long-time listener but first-time caller.  Have been trying to use the
>>>>>>> 2D Gaussian fitting capabilities within astropy.models to fit a 2D
>>>>>>> Gaussian to an image (in FITS format).  Here is my script:
>>>>>>> 
>>>>>>> import numpy as np
>>>>>>> import radio_beam
>>>>>>> from astropy.modeling import models, fitting
>>>>>>> from astropy import units as u
>>>>>>> from astropy.io <http://astropy.io/> import fits
>>>>>>> import astropy.coordinates as coord
>>>>>>> import astropy.wcs as wcs
>>>>>>> import matplotlib
>>>>>>> import pylab as pl
>>>>>>> 
>>>>>>> # The following is the position of the peak in both J1 and J2, so use
>>>>>>> # it as the starting guess
>>>>>>> ra0 = '13h15m03.50s'
>>>>>>> dec0 = '24d37m08.2s'
>>>>>>> 
>>>>>>> radeg = coord.Angle(ra0, unit=u.hour).degree
>>>>>>> decdeg = coord.Angle(dec0, unit=u.degree)
>>>>>>> 
>>>>>>> # Now open the image
>>>>>>> hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
>>>>>>> #hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
>>>>>>> w = wcs.WCS(hdulist[0].header, hdulist)
>>>>>>> 
>>>>>>> yy,xx = np.indices(hdulist[0].data.shape)
>>>>>>> 
>>>>>>> x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)
>>>>>>> 
>>>>>>> # Now fit 2D gaussian
>>>>>>> g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
>>>>>>> x_stddev=1, y_stddev=1)
>>>>>>> fit_g = fitting.LevMarLSQFitter()
>>>>>>> g = fit_g(g_init, xx, yy, hdulist[0].data)
>>>>>>> 
>>>>>>> 
>>>>>>> When I look at g_init (which is where I believe the fit results should
>>>>>>> be), I see that the fit has not moved from its initial settings.  It
>>>>>>> appears that the fitter just did not run.  With Adam Ginsburg's help I
>>>>>>> have a workaround using gaussfitter, but would certainly like to make
>>>>>>> this work with astropy.models.  Thanks!
>>>>>>> 
>>>>>>> -- Jeff
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> https://mail.scipy.org/mailman/listinfo/astropy <https://mail.scipy.org/mailman/listinfo/astropy>
>> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> https://mail.scipy.org/mailman/listinfo/astropy <https://mail.scipy.org/mailman/listinfo/astropy>
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

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

From mcraig at mnstate.edu  Fri Oct 23 12:00:14 2015
From: mcraig at mnstate.edu (Matthew Craig)
Date: Fri, 23 Oct 2015 16:00:14 +0000
Subject: [AstroPy] Gaussian models fitter non-functional?
In-Reply-To: <706D8C4D-2059-4435-867D-6BEE90245FEB@lyric.com>
References: <5620F79C.8050202@nrao.edu>
 <1865565440.1301601.1445002139993.JavaMail.zimbra@saao.ac.za>
 <E3DD4D59-3C03-483B-B960-335321F7F8DF@unibo.it> <56250575.3010307@stsci.edu>
 <56253A47.60500@nrao.edu> <9146A406-94D8-4099-860E-6571606C7488@lyric.com>
 <56264932.2020404@stsci.edu> <D81F0037-2771-4D89-B5AC-C9417D531446@lyric.com>
 <CAFfmSa3sVHCEB=Cd3iKW9Rw66n_CS8A5qqKQGWxqwzmLk6ypQw@mail.gmail.com>
 <706D8C4D-2059-4435-867D-6BEE90245FEB@lyric.com>
Message-ID: <2285FBD4-E162-4332-A7B2-DB8294BF1A45@mnstate.edu>

Hi John,

You might also be interest in IQMon, a package Josh Walawender put together for assessing image quality after-the-fact. It is at https://github.com/joshwalawender/IQMon

Matt Craig

schedule:  http://physics.mnstate.edu/craig
??

Professor
Department of Physics and Astronomy
Minnesota State University Moorhead
1104 7th Ave S, Moorhead MN 56563

phone: (218) 477-2439
fax: (218) 477-2290

On Oct 23, 2015, at 10:40 AM, John Wainwright <johnw at lyric.com<mailto:johnw at lyric.com>> wrote:

Thanks Larry.  Sorry I?m coming up to speed on this somewhat haltingly.  I?m an amateur astrophotographer (some of my images here<https://www.flickr.com/photos/jbw/albums/72157631316034648>), as well as a software engineer, and I?m working on an image-cataloging program that, among other things monitors exposures as they are captured and reports things like FHWM, estimated SNR, any correlated PSF elongation, etc., to help tune a capture session.  Astropy has been an absolute boon for this effort.

From what I can see the 2D-Gaussian fit in find_peaks() is in the dev release, which I?ll upgrade to shortly, but it doesn?t seem to report mean or std-devs or orientation of the fitted model, which I think I need for some of the above.

So, the trick would be to use find_peaks() to get the centroid and then create cut-outs around them that I give to the fitting & modeling functions in astropy, is that right?   Or simply use detect_sources() + segment_properties() to get the cut-outs and covariance matrix from their image-moment analysis to seed the 2D Moffat fit, or whichever model I might use.  How different would you expect say a Gaussian 2D model?s centroids & orientation & standard deviations be from the segment_properties() figures on the same source?

I do hope I?m not overstepping things here as an amateur bugging you guys for help.

Best,
John.

On Oct 22, 2015, at 9:19 AM, Larry Bradley <lbradley at stsci.edu<mailto:lbradley at stsci.edu>> wrote:

Hi John,

Just to clarify, the morphological properties calculated by photutils.segment_properties() are derived from the 2D image moments of the source (within the defined segment) -- 2D Gaussian fits are not used there.  Photutils also has a local peak finder (photutils.find_peaks()), which does have an option to use a 2D Gaussian fit for better precision.

Cheers,
Larry

On Thu, Oct 22, 2015 at 12:08 PM, John Wainwright <johnw at lyric.com<mailto:johnw at lyric.com>> wrote:
Thanks Erik, and sorry, I should have found those.  I realize now I was asking relative to the detect_sources() and segment_properties() functions in the photutils<http://photutils.readthedocs.org/en/latest/index.html> affiliate package, which I think use a 2D Gaussian fit to generate the basic morphological properties I've been getting.   Presumably, I could use the centroids from that data as peak seeds for a Moffat2D model fit.

Thanks again,
John.

On Oct 20, 2015, at 7:01 AM, Erik Bray <embray at stsci.edu<mailto:embray at stsci.edu>> wrote:

On 10/19/2015 05:56 PM, John Wainwright wrote:
Just on the topic of PSF fitting, is there any plan to implement Moffat PSF
models?  I'm trying to replicate some of the PSF fitting
<http://pixinsight.com/doc/tools/DynamicPSF/DynamicPSF.html> capabilities found
in PixInsight <http://pixinsight.com/> which provides excellent Moffat modeling
support.

Well, there are are already these implementations:

http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat1D.html#astropy.modeling.functional_models.Moffat1D

http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Moffat2D.html#astropy.modeling.functional_models.Moffat2D

So you can check how they compare.  You can also always add your own version:

http://docs.astropy.org/en/latest/modeling/new.html



On Oct 19, 2015, at 11:45 AM, Jeff Mangum <jmangum at nrao.edu<mailto:jmangum at nrao.edu>
<mailto:jmangum at nrao.edu<mailto:jmangum at nrao.edu>>> wrote:

Thanks for the responses.  Adam Ginsburg and I iterated a bit on this problem
and found that the issue was the fact that the image I was fitting contained
nans.  Once I removed the nans the gaussian fit routine works.  Note that if
the fitter in astropy.models is not able to handle images with nans, then
perhaps it should issue a warning.

-- Jeff

On 10/19/15 11:00 AM, Erik Bray wrote:
On 10/16/2015 09:47 AM, Giuliano Iorio wrote:

Hi Jeff,
this is the kind of staff that usually happens if the position of the
initial guess is too far away the right one. Did you plot the contour of the
fitted gaussian on the image?
It can be also that the image is too noisy around the target to fit. I
usually use only a little subarray around the target, then I search the
position of the maximum and I set the initial guess of xo and yo to its
position. After I normalize all the subarray to the value of the maximum and
cut all the signal below a certain threshold (usually 0.1).
In this way I am able to obtain a robust fit also in very noisy map.

I agree pretty much with all of Giuliano's advice.  And again it might help
to exclude data outside a smaller subarray.  Without actually seeing the data
it's hard to provide much other advice.

Have you tried a different optimizer?  There are a couple other non-linear
fitters in the package and some have different sensitivities to initial
conditions.  But it's certainly not "non-functional".

Erik

Hi Jeff--

The fitted model will not be in g_init (this remains unchanged), but in g.
 If you take a look in g, you should be able to see the fitted results.

Cheers
Steve

----- Original Message -----
From: "Jeff Mangum" <jmangum at nrao.edu<mailto:jmangum at nrao.edu> <mailto:jmangum at nrao.edu<mailto:jmangum at nrao.edu>>>
To: astropy at scipy.org<mailto:astropy at scipy.org> <mailto:astropy at scipy.org<mailto:astropy at scipy.org>>
Sent: Friday, October 16, 2015 3:11:56 PM
Subject: [AstroPy] Gaussian models fitter non-functional?

Hello,

Long-time listener but first-time caller.  Have been trying to use the
2D Gaussian fitting capabilities within astropy.models to fit a 2D
Gaussian to an image (in FITS format).  Here is my script:

import numpy as np
import radio_beam
from astropy.modeling import models, fitting
from astropy import units as u
from astropy.io<http://astropy.io/> import fits
import astropy.coordinates as coord
import astropy.wcs as wcs
import matplotlib
import pylab as pl

# The following is the position of the peak in both J1 and J2, so use
# it as the starting guess
ra0 = '13h15m03.50s'
dec0 = '24d37m08.2s'

radeg = coord.Angle(ra0, unit=u.hour).degree
decdeg = coord.Angle(dec0, unit=u.degree)

# Now open the image
hdulist = fits.open('IC860CbandCarrayH2COJ1_moment0.fits')
#hdulist = fits.open('IC860KubandDarrayH2COJ2_moment0.fits')
w = wcs.WCS(hdulist[0].header, hdulist)

yy,xx = np.indices(hdulist[0].data.shape)

x0,y0 = w.wcs_world2pix(radeg, decdeg, 1)

# Now fit 2D gaussian
g_init = models.Gaussian2D(amplitude=1., x_mean=x0, y_mean=y0,
x_stddev=1, y_stddev=1)
fit_g = fitting.LevMarLSQFitter()
g = fit_g(g_init, xx, yy, hdulist[0].data)


When I look at g_init (which is where I believe the fit results should
be), I see that the fit has not moved from its initial settings.  It
appears that the fitter just did not run.  With Adam Ginsburg's help I
have a workaround using gaussfitter, but would certainly like to make
this work with astropy.models.  Thanks!

-- Jeff

_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy



_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy


_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

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

From mcraig at mnstate.edu  Sat Oct 24 23:21:58 2015
From: mcraig at mnstate.edu (Matthew Craig)
Date: Sun, 25 Oct 2015 03:21:58 +0000
Subject: [AstroPy] [ANN] ccdproc 0.3.3: CCD data reduction
Message-ID: <14D2DF4B-715A-42DE-8AE0-E788CE924681@mnstate.edu>

Dear colleagues,

We are pleased to announce the release of ccdproc v0.3.3.  This patch release fixes a couple of minor bugs and adds compatibility with astropy 1.0.5

Ccdproc is is an affiliated package for the AstroPy package for basic data reductions of CCD images.

More Information and repository
https://github.com/astropy/ccdproc

Documentation
http://ccdproc.readthedocs.org/en/latest/

Installation
http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html

Feedback, contributions, and comments are welcome.  We would especially be interested in
contributions of examples of using ccdproc and comparisons to other reduction methods.

Special thanks to new contributor William Schoenell (@ wschoenell) for his work on this release!

Cheers,

Steve Crawford and Matt Craig
Matt Craig

PS There was no 0.3.2 release of ccdproc because of an error made in packaging that release.

schedule:  http://physics.mnstate.edu/craig
??

Professor
Department of Physics and Astronomy
Minnesota State University Moorhead
1104 7th Ave S, Moorhead MN 56563

phone: (218) 477-2439
fax: (218) 477-2290

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

From rays at blue-cove.com  Sun Oct 25 11:11:40 2015
From: rays at blue-cove.com (R Schumacher)
Date: Sun, 25 Oct 2015 08:11:40 -0700
Subject: [AstroPy] [ANN] ccdproc 0.3.3: CCD data reduction
In-Reply-To: <14D2DF4B-715A-42DE-8AE0-E788CE924681@mnstate.edu>
References: <14D2DF4B-715A-42DE-8AE0-E788CE924681@mnstate.edu>
Message-ID: <201510251511.t9PFBjbJ021529@blue-cove.com>

Nice.
How would one use masked combiner.scaling() with 
exposure time as the scaler, say from FITS or EXIF/IPTC data?

- Ray Schumacher

At 08:21 PM 10/24/2015, you wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>         boundary="_000_14D2DF4B715A42DE8AE0E788CE924681mnstateedu_"
>
>Dear colleagues,
>
>We are pleased to announce the release of 
>ccdproc v0.3.3.  This patch release fixes a 
>couple of minor bugs and adds compatibility with astropy 1.0.5
>
>Ccdproc is is an affiliated package for the 
>AstroPy package for basic data reductions of CCD images.
>
>More Information and repository
><https://github.com/astropy/ccdproc>https://github.com/astropy/ccdproc
>
>Documentation
><http://ccdproc.readthedocs.org/en/latest/>http://ccdproc.readthedocs.org/en/latest/
>
>Installation
><http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html>http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html
>
>Feedback, contributions, and comments are 
>welcome.  We would especially be interested in
>contributions of examples of using ccdproc and 
>comparisons to other reduction methods.
>
>Special thanks to new contributor William 
>Schoenell (@ wschoenell) for his work on this release!
>
>Cheers,
>
>Steve Crawford and Matt Craig
>Matt Craig
>
>PS There was no 0.3.2 release of ccdproc because 
>of an error made in packaging that release.
>
>schedule:  <http://physics.mnstate.edu/craig>http://physics.mnstate.edu/craig
>?????
>
>Professor
>Department of Physics and Astronomy
>Minnesota State University Moorhead
>1104 7th Ave S, Moorhead MN 56563
>
>phone: (218) 477-2439
>fax: (218) 477-2290
>
>_______________________________________________
>AstroPy mailing list
>AstroPy at scipy.org
>https://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151025/8c59a6e3/attachment.html>

From crawford at saao.ac.za  Sun Oct 25 20:47:27 2015
From: crawford at saao.ac.za (Steve Crawford)
Date: Mon, 26 Oct 2015 02:47:27 +0200 (SAST)
Subject: [AstroPy] [ANN] ccdproc 0.3.3: CCD data reduction
In-Reply-To: <201510251511.t9PFBjbJ021529@blue-cove.com>
References: <14D2DF4B-715A-42DE-8AE0-E788CE924681@mnstate.edu>
 <201510251511.t9PFBjbJ021529@blue-cove.com>
Message-ID: <547438902.1841251.1445820447624.JavaMail.zimbra@saao.ac.za>


To use the scaling property, you would pass a list of exposure times to use for the scaling. So if you have two images (x,y) with exposure times of (10, 20), then the following should work in the most recent release of ccdproc: 

c = Combiner((x,y)) 
c.scaling = (10,20) 
z = c.average_combine() 

For more information, take a look at: 
http://ccdproc.readthedocs.org/en/latest/ccdproc/image_combination.html 

In the next major release that is not quite ready, we will have a convenience function for combining data as well as a class (ImageCollections) for easily handling image header information. You may want to try out that version if you are interested in some of the more advanced feature. Please let us know if you any questions either here or on the github repo. 

Thanks for your interest! 


----- Original Message -----

From: "R Schumacher" <rays at blue-cove.com> 
To: "Astronomical Python mailing list" <astropy at scipy.org> 
Sent: Monday, October 26, 2015 2:11:40 AM 
Subject: Re: [AstroPy] [ANN] ccdproc 0.3.3: CCD data reduction 

Nice. 
How would one use masked combiner.scaling() with exposure time as the scaler, say from FITS or EXIF/IPTC data? 

- Ray Schumacher 

At 08:21 PM 10/24/2015, you wrote: 


Content-Language: en-US 
Content-Type: multipart/alternative; 
boundary="_000_14D2DF4B715A42DE8AE0E788CE924681mnstateedu_" 

Dear colleagues, 

We are pleased to announce the release of ccdproc v0.3.3. This patch release fixes a couple of minor bugs and adds compatibility with astropy 1.0.5 

Ccdproc is is an affiliated package for the AstroPy package for basic data reductions of CCD images. 

More Information and repository 
https://github.com/astropy/ccdproc 

Documentation 
http://ccdproc.readthedocs.org/en/latest/ 

Installation 
http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html 

Feedback, contributions, and comments are welcome. We would especially be interested in 
contributions of examples of using ccdproc and comparisons to other reduction methods. 

Special thanks to new contributor William Schoenell (@ wschoenell) for his work on this release! 

Cheers, 

Steve Crawford and Matt Craig 
Matt Craig 

PS There was no 0.3.2 release of ccdproc because of an error made in packaging that release. 

schedule: http://physics.mnstate.edu/craig 
????? 

Professor 
Department of Physics and Astronomy 
Minnesota State University Moorhead 
1104 7th Ave S, Moorhead MN 56563 

phone: (218) 477-2439 
fax: (218) 477-2290 

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

!DSPAM:562cf13d122161508011287! 
_______________________________________________ 
AstroPy mailing list 
AstroPy at scipy.org 
https://mail.scipy.org/mailman/listinfo/astropy 


!DSPAM:562cf13d122161508011287! 

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

From aldcroft at head.cfa.harvard.edu  Mon Oct 26 15:26:44 2015
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Mon, 26 Oct 2015 15:26:44 -0400
Subject: [AstroPy] Job posting for Python-fluent astrophysicist
Message-ID: <CAMtEP6y2if5ef4ZS4AVA41r1wMR4cRuz8cckbhohNW5fw4mR6g@mail.gmail.com>

Sorry for the somewhat off-topic posting, but I'd like to call your
attention to a job listing for an Astrophysicist working at the Chandra
X-ray Science Center. This job in particular would be good for someone who
is skilled in Python, comfortable with modeling in Python, and familiar
with software best practices.

Please see the link below if you are interested:

  https://www.usajobs.gov/GetJob/ViewDetails/418707000

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

From stefano.covino at brera.inaf.it  Sat Oct 31 11:35:51 2015
From: stefano.covino at brera.inaf.it (Stefano Covino)
Date: Sat, 31 Oct 2015 16:35:51 +0100
Subject: [AstroPy] search_around_sky
Message-ID: <8CA53308-1B62-4E95-B3D0-74024042B944@brera.inaf.it>

Hello everybody,

I am using "search_around_sky" to match two list of sources, and it works fine.

Is there, however, a simple way to have the indices in the two input coordinate lists of the non-matched objects?

Thanks, and my apologies if the issue has already been discussed in the past.

Stefano