From B.Vaidya at leeds.ac.uk  Sat Jun  2 06:10:07 2012
From: B.Vaidya at leeds.ac.uk (Bhargav Vaidya)
Date: Sat, 2 Jun 2012 11:10:07 +0100
Subject: [AstroPy] CASA Install on Mac 10.6 - Problem with matplolib.
Message-ID: <45D76B3D-AFD4-46E9-B7C6-24C9C8AD848B@leeds.ac.uk>

Hello, 

I have recently tried to install CASA 3.4 on my Mac 10.6 Intel 64 bit. from http://casa.nrao.edu/
Its the 19884 version : CASA-intel64b-10.6-19884.dmg. I think its a pre-realease version. 

However I have this error while creating the symbolic links. 

Traceback (most recent call last):
  File "/Applications/CASA.app/Contents/Resources/python/casapy.py", line 93, in <module>
    import matplotlib
  File "/Applications/CASA.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/__init__.py", line 709, in <module>
    rcParams = rc_params()
  File "/Applications/CASA.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/__init__.py", line 627, in rc_params
    fname = matplotlib_fname()
  File "/Applications/CASA.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/__init__.py", line 565, in matplotlib_fname
    fname = os.path.join(get_configdir(), 'matplotlibrc')
  File "/Applications/CASA.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/__init__.py", line 240, in wrapper
    ret = func(*args, **kwargs)
  File "/Applications/CASA.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/__init__.py", line 428, in _get_configdir
    raise RuntimeError('Could not write to MPLCONFIGDIR="%s"'%configdir)
RuntimeError: Could not write to MPLCONFIGDIR="/Users/bhargavvaidya/.casa"

It seems that there is some problem with the matplotlib compiled and given in the CASA's Python Framework. 
Also now I see the matplotlib version is 0.99 which is too old. Is there any development to use the 1.1.0 version. 

I am using EPD64.Framework as far as Python is concerned. 
Is this  is caused by conflicting Python install versions - the One imported with CASA and that of  EPD... I am not sure? 

Regards
Bhargav Vaidya

From perry at stsci.edu  Thu Jun  7 14:58:44 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 7 Jun 2012 14:58:44 -0400
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
Message-ID: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>

Currently the astropy.org domain is held by STScI. There was recent  
discussion amongst the astropy coordinators whether this should be  
held elsewhere. One natural place seemed to be the numfocus  
organization that was recently formed. They are willing to own (and  
pay the small annual fee) for the domain name. This seems like a  
sensible solution to have the domain held by such a organization  
rather than by a specific astronomical institution. But they wanted to  
know if there was any objection from the astropy community before  
doing so.

Is there any?

For reference, here is a link to numfocus: http://numfocus.org

Perry



From jturner at gemini.edu  Thu Jun  7 15:24:42 2012
From: jturner at gemini.edu (James Turner)
Date: Thu, 7 Jun 2012 15:24:42 -0400
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
In-Reply-To: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
References: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
Message-ID: <4FD0FFFA.4000105@gemini.edu>

> Currently the astropy.org domain is held by STScI.

It's held by me! (But yes, the question is the same; actually it's
more important since STScI can't be run over by a bus but I can.)

> There was recent discussion amongst the astropy coordinators whether
> this should be held elsewhere. One natural place seemed to be the
> numfocus organization that was recently formed. They are willing to
> own (and pay the small annual fee) for the domain name. This seems
> like a sensible solution to have the domain held by such a
> organization rather than by a specific astronomical institution. But
> they wanted to know if there was any objection from the astropy
> community before doing so.

That's good news.

> Is there any?

I think it should be held by a non-profit, largely for the above
reason (and so it's not subject to someone's whim/interests and to
facilitate funding it). However, I don't want to discourage anyone
else here from expressing their opinion; the community needs to be
happy with it.

> For reference, here is a link to numfocus: http://numfocus.org

Thanks. I'll have a better look at that now it's a serious prospect
but that's just the kind of thing I personally had in mind. Does
Numfocus currently administer any other domains? It looks like
scipy.org is owned by Enthought. We'll need to discuss the
technical practicalities like updating DNS some more.

Cheers,

James.


From perry at stsci.edu  Thu Jun  7 15:40:52 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 7 Jun 2012 15:40:52 -0400
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
In-Reply-To: <4FD0FFFA.4000105@gemini.edu>
References: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
	<4FD0FFFA.4000105@gemini.edu>
Message-ID: <27564E8E-2EEC-4124-AB5C-EC47206FDFEA@stsci.edu>


On Jun 7, 2012, at 3:24 PM, James Turner wrote:

>> Currently the astropy.org domain is held by STScI.
>
> It's held by me! (But yes, the question is the same; actually it's
> more important since STScI can't be run over by a bus but I can.)

Ah, I was confusing it with astrolib.org...


From pebarrett at gmail.com  Fri Jun  8 07:04:10 2012
From: pebarrett at gmail.com (Paul Barrett)
Date: Fri, 8 Jun 2012 07:04:10 -0400
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
In-Reply-To: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
References: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
Message-ID: <CAOqsD132d13f6Q5-wAfYvKDxn1U3bv+4xObn5umzv=V2EoZQ+Q@mail.gmail.com>

On Thu, Jun 7, 2012 at 2:58 PM, Perry Greenfield <perry at stsci.edu> wrote:
> Currently the astropy.org domain is held by STScI. There was recent
> discussion amongst the astropy coordinators whether this should be
> held elsewhere. One natural place seemed to be the numfocus
> organization that was recently formed. They are willing to own (and
> pay the small annual fee) for the domain name. This seems like a
> sensible solution to have the domain held by such a organization
> rather than by a specific astronomical institution. But they wanted to
> know if there was any objection from the astropy community before
> doing so.

> Is there any?

Perry, can you provide more information about the numfocus
organization?  I've looked at the web site, but do not get a clear
picture of the organization's motivation and long term goals and
stability. The latter aspect seems to be key issue, i.e., the long
term stability.  Given the inherent instability of the scientific, and
in particular, astronomical community, particularly during these times
of reduced to non-existent funding, some additional clarification
would be helpful.  I don't mean to be critical, given my lack of
support to astropy during the last few years, but such an explanation
would allow me to give my whole-hearted support to your request.

While we are on the topic. Since, I have somewhat been maintaining and
monitoring this, the astropy, maillist for about the past decade, do
you envision this maillist to be integrated with the numfocus or
astropy websites?

 -- Paul

> For reference, here is a link to numfocus: http://numfocus.org
>
> Perry
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From ghang.naoc at gmail.com  Fri Jun  8 09:12:23 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Fri, 8 Jun 2012 21:12:23 +0800
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
In-Reply-To: <CAOqsD132d13f6Q5-wAfYvKDxn1U3bv+4xObn5umzv=V2EoZQ+Q@mail.gmail.com>
References: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
	<CAOqsD132d13f6Q5-wAfYvKDxn1U3bv+4xObn5umzv=V2EoZQ+Q@mail.gmail.com>
Message-ID: <CABb23muaepH_nzh_uMnL-p4T78fnQ-sHNghUaSXzJXU2w8wznA@mail.gmail.com>

Dear all,
   Is there any python module that can make heliocentric velocity
correction?
   Thank you!

On Fri, Jun 8, 2012 at 7:04 PM, Paul Barrett <pebarrett at gmail.com> wrote:

> On Thu, Jun 7, 2012 at 2:58 PM, Perry Greenfield <perry at stsci.edu> wrote:
> > Currently the astropy.org domain is held by STScI. There was recent
> > discussion amongst the astropy coordinators whether this should be
> > held elsewhere. One natural place seemed to be the numfocus
> > organization that was recently formed. They are willing to own (and
> > pay the small annual fee) for the domain name. This seems like a
> > sensible solution to have the domain held by such a organization
> > rather than by a specific astronomical institution. But they wanted to
> > know if there was any objection from the astropy community before
> > doing so.
>
> > Is there any?
>
> Perry, can you provide more information about the numfocus
> organization?  I've looked at the web site, but do not get a clear
> picture of the organization's motivation and long term goals and
> stability. The latter aspect seems to be key issue, i.e., the long
> term stability.  Given the inherent instability of the scientific, and
> in particular, astronomical community, particularly during these times
> of reduced to non-existent funding, some additional clarification
> would be helpful.  I don't mean to be critical, given my lack of
> support to astropy during the last few years, but such an explanation
> would allow me to give my whole-hearted support to your request.
>
> While we are on the topic. Since, I have somewhat been maintaining and
> monitoring this, the astropy, maillist for about the past decade, do
> you envision this maillist to be integrated with the numfocus or
> astropy websites?
>
>  -- Paul
>
> > For reference, here is a link to numfocus: http://numfocus.org
> >
> > Perry
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120608/e5cf9f59/attachment.html>

From erik.tollerud at gmail.com  Fri Jun  8 16:51:43 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Fri, 8 Jun 2012 13:51:43 -0700
Subject: [AstroPy] transferring ownership of astropy.org to numfocus
In-Reply-To: <CAOqsD132d13f6Q5-wAfYvKDxn1U3bv+4xObn5umzv=V2EoZQ+Q@mail.gmail.com>
References: <52B4FA91-EC68-4473-A416-A69BCBC2BED8@stsci.edu>
	<CAOqsD132d13f6Q5-wAfYvKDxn1U3bv+4xObn5umzv=V2EoZQ+Q@mail.gmail.com>
Message-ID: <CAARXUwUOFxBoygQc1Hob5pc4iZRJfTcckMR5iPH1s-T=sW_PDA@mail.gmail.com>

> While we are on the topic. Since, I have somewhat been maintaining and
> monitoring this, the astropy, maillist for about the past decade, do
> you envision this maillist to be integrated with the numfocus or
> astropy websites?

I can address at least my view for this one (which I *think* the rest
of the Astropy coordinating committee agrees with) and hopefully Perry
can clarify the role/plans for numfocus, as he is a board member.

I see a dual role for this list (and right now, the astropy.org
documentation reflects this).  For one, it can act as sort of an
"astropy-users" list - e.g. questions about how to use astropy in a
practical setting, as well as general Astropy
announcements/discussions.  It would also be great to continue in the
capacity it already has: a sort of general mailing list for any python
astronomy questions.  Obviously, there's a fair amount of overlap
between the two, so hopefully the roles don't conflict.

What it is *not* is the place to discuss ongoing development of the
Astropy project.  That's what the astropy-dev
(http://groups.google.com/group/astropy-dev) is for.

As for who maintains/serves the list, the current situation
(mail.scipy.org) is fine as far as I'm concerned, and I see no reason
to change something that seems to be working.  If in the future, we
start having problems or scipy no longer wants to hold it, it might
make sense to move it, but I see no compelling reason to do so right
now.

Does that sound reasonable?


-- 
Erik Tollerud


From ghang.naoc at gmail.com  Fri Jun  8 22:52:57 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Sat, 9 Jun 2012 10:52:57 +0800
Subject: [AstroPy] Heliocentric Velocity Correction
Message-ID: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>

Dear pythoners:
          Is there any python nodule that can make heliocentric velocity
correction well?
          Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120609/7b57b99a/attachment.html>

From ghang.naoc at gmail.com  Sat Jun  9 04:20:17 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Sat, 9 Jun 2012 16:20:17 +0800
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
Message-ID: <CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>

I have checked
http://code.google.com/p/astrolibpy/source/browse/#git%2Fastrolib  and
http://www.astro.ucla.edu/~ianc/python/astrolib.html
Is there a whole astrolib module I can download and install? Or is there
any other python module that can makes heliocentric velocity correction you
suggest?
Thank you very much!

On Sat, Jun 9, 2012 at 10:52 AM, gonghang.naoc <ghang.naoc at gmail.com> wrote:

> Dear pythoners:
>           Is there any python nodule that can make heliocentric velocity
> correction well?
>           Thank you!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120609/b334c263/attachment.html>

From d.berry at jach.hawaii.edu  Sat Jun  9 05:51:54 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Sat, 9 Jun 2012 10:51:54 +0100
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
	<CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
Message-ID: <CAALafn5Sxn4i4Fdj42VXmguoNmHai+KSQtPRN9fKi1uJ3801GA@mail.gmail.com>

The SpecFrame class in pyast (https://github.com/timj/starlink-pyast)
can do corrections between various different standards of rest,
including heliocentric. pyast provides a comprehensive object-oriented
system for handling coordinate systems and transformation of many
types, including sky, spectral and time coordinate systems. See below
for an example of how to use it to convert from topocentric to
heliocentric, and see
http://www.starlink.ac.uk/docs/sun211.htx/node680.html#SpecFrame for a
full description of the SecFrame class.

David




import starlink.Ast as Ast
import copy

# First create a Frame (a SpecFrame) describing the "input" system -
# topocentric radio velocity in this example. The Unit property defaults
# to km/s for radio velocity, but could be changed (e.g. to m/s) if required.
# Here I set just the main properties, but there are lots of others.

sf1 = Ast.SpecFrame()
sf1.System = "vradio"           # Spectral system (all FITS values supported)
sf1.StdOfRest = "topo"          # Standard of rest (all FITS values supported)
sf1.Epoch = 2012.23458765       # Julian epoch of observation - could be MJD
sf1.ObsLon = 155.32311          # East longitude of observer in degs
sf1.ObsLat = 22.32311           # Latitude of observer in degs
sf1.RefRA = "16:12:23.3"        # FK5 J2000 (RA,Dec) of the source (there
sf1.RefDec = "-23:24:18.2"      # are other ways to set the source position)
sf1.RestFreq = 345.795          # In GHz


# Make a deep copy of this SpecFrame and then modify its properties to
# describe the "output" system. Here I just change the standard of rest to
# heliocentric, the spectral system to frequency and the unit to GHz (the
# default unit for frequency is Hz).

sf2 = copy.deepcopy( sf1 )
sf2.StdOfRest = "helio"
sf2.System = "freq"
sf2.Unit = "GHz"

# Create an object that knows how to convert values in the system
# described by "sf1" into the system described by "sf2".

fs = sf1.convert( sf2 )

# Use this object to convert a set of topocentric radio velocities in m/s
# into heliocentric frequencies in GHz.

topovel = [ 12234.23, -23000.3, 7823.444 ]
heliofreq = fs.tran( topovel )

print( heliofreq )


From ghang.naoc at gmail.com  Mon Jun 11 03:58:29 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Mon, 11 Jun 2012 15:58:29 +0800
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
	<CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
Message-ID: <CABb23msyximByAQi2yxxv6OE=L8fGxng81cFxrsr8K-t=e-4bw@mail.gmail.com>

Hi,according to the link below,the 3d velocity we get from astrolib has
nothing to do with the observatory position.My question is  the 3d velocity
is just the velocity of earth center?As the author claimed the precision
level is cm/s, is it necessary to  input the  longtitude, latitude and
elevation of the observatory?

Thank you!

http://www.astro.ucla.edu/~ianc/python/astrolib.htmlIDL> baryvel, jd, 2000,
vh, vb, /jpl ;JPL ephemeris==> vh = [-17.07236, -22.81126, -9.889419]
;Heliocentric km/s ==> vb = [-17.08083, -22.80484, -9.886409] ;Barycentric
km/s




On Sat, Jun 9, 2012 at 4:20 PM, gonghang.naoc <ghang.naoc at gmail.com> wrote:

> I have checked
> http://code.google.com/p/astrolibpy/source/browse/#git%2Fastrolib  and
> http://www.astro.ucla.edu/~ianc/python/astrolib.html
> Is there a whole astrolib module I can download and install? Or is there
> any other python module that can makes heliocentric velocity correction you
> suggest?
> Thank you very much!
>
>
> On Sat, Jun 9, 2012 at 10:52 AM, gonghang.naoc <ghang.naoc at gmail.com>wrote:
>
>> Dear pythoners:
>>           Is there any python nodule that can make heliocentric velocity
>> correction well?
>>           Thank you!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120611/38646834/attachment.html>

From d.berry at jach.hawaii.edu  Mon Jun 11 04:24:52 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Mon, 11 Jun 2012 09:24:52 +0100
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23msyximByAQi2yxxv6OE=L8fGxng81cFxrsr8K-t=e-4bw@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
	<CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
	<CABb23msyximByAQi2yxxv6OE=L8fGxng81cFxrsr8K-t=e-4bw@mail.gmail.com>
Message-ID: <CAALafn5c_Bmb91grf+KuGKJ9+bU4-dEn31wCX0JOxyEeAoRwyg@mail.gmail.com>

Sorry - I'm not sure I understand your question. I thought you were
trying to convert spectral positions (frequencies, velocities,
wavelengths, etc) into the heliocentric rest frame from some other
rest frame.

The exact set of properties you need to specify when converting
spectral positions depends on your original rest frame. I used
topocentric as an example, and so included the observatory position.
If instead I had used (for instance) geocentric, then the observatory
position would not have been needed.

But I see that astrolib.baryvel just returns the velocity of the earth
in the barycentric or heliocentric rest frame, so now I'm not sure
what it is you are trying to do. What velocity is it you are trying to
correct?

David

On 11 June 2012 08:58, gonghang.naoc <ghang.naoc at gmail.com> wrote:
> Hi,according to the link below,the 3d velocity we get from astrolib has
> nothing to do with the observatory position.My question is? the 3d velocity
> is just the velocity of earth center?As the author claimed the precision
> level is cm/s, is it necessary to? input the? longtitude, latitude and
> elevation of the observatory?
>
> Thank you!
>
>
> http://www.astro.ucla.edu/~ianc/python/astrolib.htmlIDL> baryvel, jd, 2000,
> vh, vb, /jpl ;JPL ephemeris ==> vh = [-17.07236, -22.81126, -9.889419]
> ;Heliocentric km/s ==> vb = [-17.08083, -22.80484, -9.886409] ;Barycentric
> km/s
>
>
>
>
> On Sat, Jun 9, 2012 at 4:20 PM, gonghang.naoc <ghang.naoc at gmail.com> wrote:
>>
>> I have checked
>> http://code.google.com/p/astrolibpy/source/browse/#git%2Fastrolib? and
>> http://www.astro.ucla.edu/~ianc/python/astrolib.html
>> Is there a whole astrolib module I can download and install? Or is there
>> any other python module that can makes heliocentric velocity correction you
>> suggest?
>> Thank you very much!
>>
>>
>> On Sat, Jun 9, 2012 at 10:52 AM, gonghang.naoc <ghang.naoc at gmail.com>
>> wrote:
>>>
>>> Dear pythoners:
>>> ????????? Is there any python nodule that can make heliocentric velocity
>>> correction well?
>>> ????????? Thank you!
>>
>>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From ghang.naoc at gmail.com  Mon Jun 11 05:36:19 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Mon, 11 Jun 2012 17:36:19 +0800
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23mv0KdR99C9XaEvPZdDGpWXa8Vi3G=kHz8CxKdU84NEJ0Q@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
	<CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
	<CABb23msyximByAQi2yxxv6OE=L8fGxng81cFxrsr8K-t=e-4bw@mail.gmail.com>
	<CAALafn5c_Bmb91grf+KuGKJ9+bU4-dEn31wCX0JOxyEeAoRwyg@mail.gmail.com>
	<CABb23mv0KdR99C9XaEvPZdDGpWXa8Vi3G=kHz8CxKdU84NEJ0Q@mail.gmail.com>
Message-ID: <CABb23mvHLZ9W72n2VGcF88H-zb40-7RAJ58=E77PYuR3RcZkiQ@mail.gmail.com>

   Thank you.

> I just want to get  the radial velocity  a star  in heliocentric
> coordinate.I think the the heliocentric correction depends on the position
> of the observatory,but the input parameters of astrolib.baryvel  are just
> dje and deq.The result is a 3d velocity.My question is  whether the
> velocity is the velocity of the  center of the earth and if not,whether I
> can input the observatory parameters,i.e. longitude,latitude,elevation.
>
>
> On Mon, Jun 11, 2012 at 4:24 PM, David Berry <d.berry at jach.hawaii.edu>wrote:
>
>> Sorry - I'm not sure I understand your question. I thought you were
>> trying to convert spectral positions (frequencies, velocities,
>> wavelengths, etc) into the heliocentric rest frame from some other
>> rest frame.
>>
>> The exact set of properties you need to specify when converting
>> spectral positions depends on your original rest frame. I used
>> topocentric as an example, and so included the observatory position.
>> If instead I had used (for instance) geocentric, then the observatory
>> position would not have been needed.
>>
>> But I see that astrolib.baryvel just returns the velocity of the earth
>> in the barycentric or heliocentric rest frame, so now I'm not sure
>> what it is you are trying to do. What velocity is it you are trying to
>> correct?
>>
>> David
>>
>> On 11 June 2012 08:58, gonghang.naoc <ghang.naoc at gmail.com> wrote:
>> > Hi,according to the link below,the 3d velocity we get from astrolib has
>> > nothing to do with the observatory position.My question is  the 3d
>> velocity
>> > is just the velocity of earth center?As the author claimed the precision
>> > level is cm/s, is it necessary to  input the  longtitude, latitude and
>> > elevation of the observatory?
>> >
>> > Thank you!
>> >
>> >
>> > http://www.astro.ucla.edu/~ianc/python/astrolib.htmlIDL> baryvel, jd,
>> 2000,
>> > vh, vb, /jpl ;JPL ephemeris ==> vh = [-17.07236, -22.81126, -9.889419]
>> > ;Heliocentric km/s ==> vb = [-17.08083, -22.80484, -9.886409]
>> ;Barycentric
>> > km/s
>> >
>> >
>> >
>> >
>> > On Sat, Jun 9, 2012 at 4:20 PM, gonghang.naoc <ghang.naoc at gmail.com>
>> wrote:
>> >>
>> >> I have checked
>> >> http://code.google.com/p/astrolibpy/source/browse/#git%2Fastrolib  and
>> >> http://www.astro.ucla.edu/~ianc/python/astrolib.html
>> >> Is there a whole astrolib module I can download and install? Or is
>> there
>> >> any other python module that can makes heliocentric velocity
>> correction you
>> >> suggest?
>> >> Thank you very much!
>> >>
>> >>
>> >> On Sat, Jun 9, 2012 at 10:52 AM, gonghang.naoc <ghang.naoc at gmail.com>
>> >> wrote:
>> >>>
>> >>> Dear pythoners:
>> >>>           Is there any python nodule that can make heliocentric
>> velocity
>> >>> correction well?
>> >>>           Thank you!
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/astropy
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120611/fd56b3bf/attachment.html>

From d.berry at jach.hawaii.edu  Mon Jun 11 06:27:43 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Mon, 11 Jun 2012 11:27:43 +0100
Subject: [AstroPy] Heliocentric Velocity Correction
In-Reply-To: <CABb23mvHLZ9W72n2VGcF88H-zb40-7RAJ58=E77PYuR3RcZkiQ@mail.gmail.com>
References: <CABb23mvEm9N3YSjY533Rvw_uQFiUw=UVw_aMkid_7-7TX2tU0A@mail.gmail.com>
	<CABb23mtApY7vyQnVnFpAt_4FSHxzM0q1ABk=eYfWbTs=G28RvQ@mail.gmail.com>
	<CABb23msyximByAQi2yxxv6OE=L8fGxng81cFxrsr8K-t=e-4bw@mail.gmail.com>
	<CAALafn5c_Bmb91grf+KuGKJ9+bU4-dEn31wCX0JOxyEeAoRwyg@mail.gmail.com>
	<CABb23mv0KdR99C9XaEvPZdDGpWXa8Vi3G=kHz8CxKdU84NEJ0Q@mail.gmail.com>
	<CABb23mvHLZ9W72n2VGcF88H-zb40-7RAJ58=E77PYuR3RcZkiQ@mail.gmail.com>
Message-ID: <CAALafn706pE3qJ5hiO82nbVoTQoDkR3+x4MfmQ1wM2VgMeuBfA@mail.gmail.com>

On 11 June 2012 10:36, gonghang.naoc <ghang.naoc at gmail.com> wrote:
>
> ?? Thank you.
>>
>> I just want to get? the radial velocity? a star? in heliocentric
>> coordinate.I think the the heliocentric correction depends on the position
>> of the observatory,but the input parameters of astrolib.baryvel? are just
>> dje and deq.The result is a 3d velocity.My question is? whether the velocity
>> is the velocity of the? center of the earth and if not,whether I can input
>> the observatory parameters,i.e. longitude,latitude,elevation.

The heliocentric correction depends on the rest frame from which you
start. If you start with a topocentric velocity (i.e. relative to the
observer), then the correction will need to take account of the
observer's position. If you start from a geocentric velocity (i.e.
relative to the centre of the earth) then the correction will not
include the observers position.

I read the documentation for the astrolib.baryvel function as meaning
that the returned velocity is the velocity of the centre of the earth.
It can't really be anything else given that it just takes an epoch and
equinox as input.

So you want the full 3D velocity of the star, rather than just the
apparent radial velocity?

David

>>
>> On Mon, Jun 11, 2012 at 4:24 PM, David Berry <d.berry at jach.hawaii.edu>
>> wrote:
>>>
>>> Sorry - I'm not sure I understand your question. I thought you were
>>> trying to convert spectral positions (frequencies, velocities,
>>> wavelengths, etc) into the heliocentric rest frame from some other
>>> rest frame.
>>>
>>> The exact set of properties you need to specify when converting
>>> spectral positions depends on your original rest frame. I used
>>> topocentric as an example, and so included the observatory position.
>>> If instead I had used (for instance) geocentric, then the observatory
>>> position would not have been needed.
>>>
>>> But I see that astrolib.baryvel just returns the velocity of the earth
>>> in the barycentric or heliocentric rest frame, so now I'm not sure
>>> what it is you are trying to do. What velocity is it you are trying to
>>> correct?
>>>
>>> David
>>>
>>> On 11 June 2012 08:58, gonghang.naoc <ghang.naoc at gmail.com> wrote:
>>> > Hi,according to the link below,the 3d velocity we get from astrolib has
>>> > nothing to do with the observatory position.My question is? the 3d
>>> > velocity
>>> > is just the velocity of earth center?As the author claimed the
>>> > precision
>>> > level is cm/s, is it necessary to? input the? longtitude, latitude and
>>> > elevation of the observatory?
>>> >
>>> > Thank you!
>>> >
>>> >
>>> > http://www.astro.ucla.edu/~ianc/python/astrolib.htmlIDL> baryvel, jd,
>>> > 2000,
>>> > vh, vb, /jpl ;JPL ephemeris ==> vh = [-17.07236, -22.81126, -9.889419]
>>> > ;Heliocentric km/s ==> vb = [-17.08083, -22.80484, -9.886409]
>>> > ;Barycentric
>>> > km/s
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Jun 9, 2012 at 4:20 PM, gonghang.naoc <ghang.naoc at gmail.com>
>>> > wrote:
>>> >>
>>> >> I have checked
>>> >> http://code.google.com/p/astrolibpy/source/browse/#git%2Fastrolib? and
>>> >> http://www.astro.ucla.edu/~ianc/python/astrolib.html
>>> >> Is there a whole astrolib module I can download and install? Or is
>>> >> there
>>> >> any other python module that can makes heliocentric velocity
>>> >> correction you
>>> >> suggest?
>>> >> Thank you very much!
>>> >>
>>> >>
>>> >> On Sat, Jun 9, 2012 at 10:52 AM, gonghang.naoc <ghang.naoc at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Dear pythoners:
>>> >>> ????????? Is there any python nodule that can make heliocentric
>>> >>> velocity
>>> >>> correction well?
>>> >>> ????????? Thank you!
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > 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 perry at stsci.edu  Mon Jun 11 15:21:00 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 11 Jun 2012 15:21:00 -0400
Subject: [AstroPy] astropy coordination meeting date
Message-ID: <579B6C7E-770F-488C-9BA6-6F5964D92CF0@stsci.edu>

We've settled on October 9-10 for the astropy coordination meeting. It  
will be held at STScI in Baltimore. I'll provide more details about  
the meeting within the next month.

Perry



From perry at stsci.edu  Mon Jun 11 15:34:06 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 11 Jun 2012 15:34:06 -0400
Subject: [AstroPy] Fwd: Numfocus & AstroPy.org
References: <E20901B7-CEC5-4666-87D5-72B0392A5407@gmail.com>
Message-ID: <A59424F7-32F2-4D10-87D0-7577E51DCE3C@stsci.edu>

I thought it would be useful to pass this along from Travis.

Begin forwarded message:

> From: Travis Oliphant <teoliphant at gmail.com>
> Date: June 8, 2012 4:01:10 PM EDT
> To: James Turner <jturner at gemini.edu>
> Cc: Perry Greenfield <perry at stsci.edu>, Thomas Robitaille <thomas.robitaille at gmail.com 
> >, Erik Tollerud <erik.tollerud at gmail.com>, admin at numfocus.org
> Subject: Re: Numfocus & AstroPy.org
>
> Hey James,
>
> Thanks for your email.  I'm CCing my response to the NumFOCUS board  
> as well.   The purpose of NumFOCUS is to support open source Python  
> for science projects.   It is a legal organization that can own  
> things and is in the process of applying for 501(c)(3) status  
> (trying to get it by November of this year).   We are registered as  
> a non-profit in Texas.
>
> The projects that NumFOCUS supports maintain their independence and  
> but can use NumFOCUS as a resource.   We are sponsoring SciPy and  
> EuroSciPy, have paid legal bills on behalf of IPython, are setting  
> up continuous integration services, are starting a technical  
> fellowship program to sponsor open-source developers, and are  
> willing to own things like domains and be a care-taker for open  
> source property.
>
> We are just now figuring out bylaws and how the organization will  
> evolve.  Right now it is governed by the board of directors which  
> consists of 5 people (me, Fernando Perez, John Hunter, Jarrod  
> Millman, and Perry).
>
> There is a full-time administrative assistant who is making sure  
> things keep going (all of us are still pretty busy with other things  
> as well).   Funding the astropy domain is certainly something we  
> should consider doing.   I had wanted to get our bylaws in place  
> which articulated how the board of directors is appointed so that  
> people could feel confident in trusting NumFOCUS to hold domains.     
> We are working on that right now and will let you know when we are  
> ready for your consideration.    In the mean-time we will discuss  
> your proposal again.   The board meets every other week and we  
> should be able to respond by the end of June.
>
> Best regards,
>
> -Travis
>
>
>
>
> On Jun 8, 2012, at 2:39 PM, James Turner wrote:
>
>> Hi Travis,
>>
>> I gather Perry has spoken to you about the possibility of your
>> Numfocus foundation looking after the astropy.org domain for us.
>> Thanks for your willingness to do that! I registered the domain
>> after last year's SciPy and am the current owner, but it would be
>> preferable for a suitable non-profit to hold it for the community.
>> (Perry may have told you that STScI owns it, but he was getting
>> mixed up with astrolib.org).
>>
>> After a quick look at the Numfocus page, I still wasn't all that
>> clear on what it's all about, its relationship with projects like
>> NumPy and its legal status etc. I understand you're currently
>> applying for non-profit status; do you have any idea how long
>> that's likely to take? Does Numfocus currently exist as a legal
>> entity that can own things (like domains)? Is its longevity
>> reasonably assured? I know there was some SciPy discussion about
>> all this, but I just can't keep up with that list :-(. Your mission
>> statement is quite high level and it would be good to know a bit
>> more about what you do and its scope.
>>
>> I also wondered whether you already own any domains, thinking
>> about the technicalities of DNS administration. I see scipy.org
>> belongs to Enthought. Currently the AstroPy committee members keep
>> fiddling with CNAME records etc., as the site is getting up and
>> running. We are registered through GoDaddy and their interface has
>> some provision for guest administrators. We'd need to figure out
>> whether there's a way for the AstroPy committee to update those
>> records through your registrar (the transfer would be easiest if
>> that's also GoDaddy but it should still be doable if not).
>>
>> Our renewal is due on 21 July and I had been expecting to transfer
>> it to "the AstroPy project" by then, but it's not really a problem
>> to pay for one more year if we're not quite ready for Numfocus to
>> take it over yet. In that case, we could talk some more at SciPy,
>> assuming I'll see you there?
>>
>> Perry has also solicited feedback on the mailing list, as I think
>> you requested, with only one reply so far that had questions
>> similar to mine.
>>
>> Thanks a lot!
>>
>> James.
>>
>> -- 
>> James E.H. Turner
>> Gemini Observatory Southern Operations Centre,
>> Casilla 603,		Tel. (+56) 51 205609
>> La Serena, Chile.	Fax. (+56) 51 205650
>



From perry at stsci.edu  Mon Jun 11 15:36:11 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 11 Jun 2012 15:36:11 -0400
Subject: [AstroPy] Fwd:  transferring ownership of astropy.org to numfocus
References: <91D7DB8B-C0C1-4B7E-A157-F26E9AB3478E@stsci.edu>
Message-ID: <AAACB111-4DB2-466F-A9A4-23715EFC57BE@stsci.edu>

[I had passed this along to the board to make sure that I wasn't  
saying anything controversial--no one commented on it so I figure it  
wasn't that far out of line; this may be useful in conjunction with  
Travis's response]

While there are a number of goals for the organization, I think it is  
fair to say that the primary one was to create a non-profit foundation  
that could be the focus of sponsorship efforts to help fund efforts in  
scientific Python to keep numpy, scipy, and other core projects at the  
forefront of science and engineering. While sponsorship is welcome  
from all areas, the hope is that significant amounts could be found  
from private companies, particularly those that are finding numerical  
Python useful for science, engineering, and finance.

As for stability, that is a reasonable point to raise. Would any  
concern about that be alleviated if there was a condition that  
ownership of domain name be transferred to some-to-be-named-entity  
should numfocus cease to be, stop being non-profit, or have a  
significant redirection in its charter?

Perry

Begin forwarded message:

> From: Paul Barrett <pebarrett at gmail.com>
> Date: June 8, 2012 7:04:10 AM EDT
> To: Perry Greenfield <perry at stsci.edu>
> Cc: astropy <astropy at scipy.org>
> Subject: Re: [AstroPy] transferring ownership of astropy.org to  
> numfocus
>
> On Thu, Jun 7, 2012 at 2:58 PM, Perry Greenfield <perry at stsci.edu>  
> wrote:
>> Currently the astropy.org domain is held by STScI. There was recent
>> discussion amongst the astropy coordinators whether this should be
>> held elsewhere. One natural place seemed to be the numfocus
>> organization that was recently formed. They are willing to own (and
>> pay the small annual fee) for the domain name. This seems like a
>> sensible solution to have the domain held by such a organization
>> rather than by a specific astronomical institution. But they wanted  
>> to
>> know if there was any objection from the astropy community before
>> doing so.
>
>> Is there any?
>
> Perry, can you provide more information about the numfocus
> organization?  I've looked at the web site, but do not get a clear
> picture of the organization's motivation and long term goals and
> stability. The latter aspect seems to be key issue, i.e., the long
> term stability.  Given the inherent instability of the scientific, and
> in particular, astronomical community, particularly during these times
> of reduced to non-existent funding, some additional clarification
> would be helpful.  I don't mean to be critical, given my lack of
> support to astropy during the last few years, but such an explanation
> would allow me to give my whole-hearted support to your request.
>
> While we are on the topic. Since, I have somewhat been maintaining and
> monitoring this, the astropy, maillist for about the past decade, do
> you envision this maillist to be integrated with the numfocus or
> astropy websites?
>
> -- Paul
>
>> For reference, here is a link to numfocus: http://numfocus.org
>>
>> Perry
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy





From jturner at gemini.edu  Mon Jun 11 15:54:49 2012
From: jturner at gemini.edu (James Turner)
Date: Mon, 11 Jun 2012 15:54:49 -0400
Subject: [AstroPy] Fwd: transferring ownership of astropy.org to numfocus
In-Reply-To: <AAACB111-4DB2-466F-A9A4-23715EFC57BE@stsci.edu>
References: <91D7DB8B-C0C1-4B7E-A157-F26E9AB3478E@stsci.edu>
	<AAACB111-4DB2-466F-A9A4-23715EFC57BE@stsci.edu>
Message-ID: <4FD64D09.9050203@gemini.edu>

> As for stability, that is a reasonable point to raise. Would any
> concern about that be alleviated if there was a condition that
> ownership of domain name be transferred to some-to-be-named-entity
> should numfocus cease to be, stop being non-profit, or have a
> significant redirection in its charter?

Yes, I was thinking of something like that too; that in the event
numfocus ceases operating, changes status or is no longer willing to
maintain the domain for the community, it is to be transferred (or
not) as instructed by the AstroPy co-ordination committee. That ought
to do it. Travis also said that projects would retain control of
property held by the foundation, so maybe all of that is implied
anyway (not sure whether control of property would extend to
re-posession).

Cheers,

James.


From astropy at liska.ath.cx  Wed Jun 13 04:28:05 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 13 Jun 2012 10:28:05 +0200
Subject: [AstroPy] [astropy-dev] SOFA license change
References: <CAGsQ-NujW_aoJ76ej4jXVH28qyhkw07xwqQi5zuRe3VtSmE9Pg@mail.gmail.com>
	<CA+G92RfDMjRCk38XLAss-p4HDgFA4He-XQc061p-BDP3X9Q6xQ@mail.gmail.com>
	<CAARXUwU54spB4pw_WHmgWLSAO4Xqt+jFgMZ9gNCLerQoTdEfvQ@mail.gmail.com>
	<A1CF9D4E-04C7-4A53-8A14-F66F04574048@gmail.com>
	<4FD652E5.80901@du.edu>
	<CAARXUwXZoH3bwV1qnNzV0BxdBBT8D=79yeH6rMUtdqQZAK973g@mail.gmail.com>
	<CAGsQ-NtnnN-S8e62tFgV65XgghqKrbWz9DNgvgwdfx5Dbd5-mQ@mail.gmail.com>
Message-ID: <ytzd3537h0q.fsf@news.ole.ath.cx>

Tom Aldcroft <aldcroft at head.cfa.harvard.edu> writes:
[iausofa_c]
> As for the part about being C, from what I saw of the actual code it
> is very simple ANSI C and the whole thing compiles in 6.9 sec with
> zero warnings using gcc -pedantic on my very old Macbook.  So while I
> agree in general that C libraries should be approached warily, I think
> this one is pretty friendly.  (But of course one never really knows
> without trying on 20 different OS's...).

Since Debian installs on a variety of platforms, I can report that the
compilation and unit test of iausofa_c succeeds at least on the
following platforms:

Linux
=====
* amd64, i386, ia64
* alpha
* PowerPC 32 and 64 bit
* arm little endian with and w/o FP emulation
* mips big & little endian
* IBM zSeries direct and userland (s390/s390x)
* SuperH RISC 

Other
=====
* Hurd on i386
* KFreebsd (BSD kernel with Debian userland) on i386 and amd64

Contrary to the original code, we build a shared library. No compilation
has failed so far. Sure, the environment is always Debian (and the
compiler is gcc), but the system architectures vary heavily, and I would
have a good feeling about the portability of the code.

The build pages:
https://buildd.debian.org/status/package.php?p=iausofa-c
http://buildd.debian-ports.org/status/package.php?p=iausofa-c&suite=sid

Best regards

Ole


From ebressert at cfa.harvard.edu  Sun Jun 17 05:28:39 2012
From: ebressert at cfa.harvard.edu (Eli Bressert)
Date: Sun, 17 Jun 2012 11:28:39 +0200
Subject: [AstroPy] Mailing list --> Stackoverflow format?
Message-ID: <CA+3+fTaa90F5yCdwfq31Df361ahQKJDvuCUvbrN9bR=RmBLgEg@mail.gmail.com>

Hi everyone,

I'm avid fan of stackoverflow.com for asking questions/finding
solutions on non-astronomy Python problems. The information format on
the website is very simple to search through and ask questions. As a
mailing list there is nothing wrong with the current format, but I do
prefer the stackoverflow format.

We can propose it on area51.stackexchange.com (Astropython Beta) and
see how it fares. I noticed that the Astronomy Beta project didn't
work out due to a lack of activity. Why the lack of activity? Not
sure. If we were to have Astropython Beta go up, I may be more
successful for several reasons.

1) We already have an active mailing list

2) Astropython Beta could act as a communication medium for
astro-related python packages and users

3) Astropy.org is about released and Astropython Beta could be a
helpful platform for new Python adopters

Having a separate mailing list for every astro-related Python package
can be tedious to follow through emails. If Astropython Beta were a
central source of communication it could make life for both the dev's
and users easier. I'm curious others think of this idea. If it has
been discussed before... sorry for bringing up the topic again.

Cheers,
Eli


From ebressert at cfa.harvard.edu  Sun Jun 17 07:17:37 2012
From: ebressert at cfa.harvard.edu (Eli Bressert)
Date: Sun, 17 Jun 2012 13:17:37 +0200
Subject: [AstroPy] Mailing list --> Stackoverflow format?
In-Reply-To: <CAMpoRhcVK_RGPhX42cGwy5hONQTGyL=BsY8NZss4=aEn9i9UCw@mail.gmail.com>
References: <CA+3+fTaa90F5yCdwfq31Df361ahQKJDvuCUvbrN9bR=RmBLgEg@mail.gmail.com>
	<CAMpoRhcVK_RGPhX42cGwy5hONQTGyL=BsY8NZss4=aEn9i9UCw@mail.gmail.com>
Message-ID: <CA+3+fTYVzawikVD8vhvYZ96dVfu=7O+5Fp-P0mAijfG=4FCs5w@mail.gmail.com>

Hi Prasanth,

Thanks for pointing that out. I knew of the website but somehow
associated it with Astronomy Beta by accident. It looks good to me. So
let me modify my question to the mailing community. Any specific
reasons why we wouldn't use Astrobabel? Still too general?

Cheers,
Eli


On Sun, Jun 17, 2012 at 12:12 PM, Prasanth <oneaufs at gmail.com> wrote:
> Hello,
>
> Isn't http://www.astrobabel.com trying to do something like this outside
> stackexchange sites? It is not just for astro-python, but perhaps having one
> place for all astronomy computing questions is an easier thing to do.
>
> Prasanth
>
> On Sun, Jun 17, 2012 at 2:58 PM, Eli Bressert <ebressert at cfa.harvard.edu>
> wrote:
>>
>> Hi everyone,
>>
>> I'm avid fan of stackoverflow.com for asking questions/finding
>> solutions on non-astronomy Python problems. The information format on
>> the website is very simple to search through and ask questions. As a
>> mailing list there is nothing wrong with the current format, but I do
>> prefer the stackoverflow format.
>>
>> We can propose it on area51.stackexchange.com (Astropython Beta) and
>> see how it fares. I noticed that the Astronomy Beta project didn't
>> work out due to a lack of activity. Why the lack of activity? Not
>> sure. If we were to have Astropython Beta go up, I may be more
>> successful for several reasons.
>>
>> 1) We already have an active mailing list
>>
>> 2) Astropython Beta could act as a communication medium for
>> astro-related python packages and users
>>
>> 3) Astropy.org is about released and Astropython Beta could be a
>> helpful platform for new Python adopters
>>
>> Having a separate mailing list for every astro-related Python package
>> can be tedious to follow through emails. If Astropython Beta were a
>> central source of communication it could make life for both the dev's
>> and users easier. I'm curious others think of this idea. If it has
>> been discussed before... sorry for bringing up the topic again.
>>
>> Cheers,
>> Eli
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>


From jturner at gemini.edu  Mon Jun 18 17:23:32 2012
From: jturner at gemini.edu (James Turner)
Date: Mon, 18 Jun 2012 17:23:32 -0400
Subject: [AstroPy] SciPy 2012
In-Reply-To: <4F735A23.9040402@gemini.edu>
References: <4F735A23.9040402@gemini.edu>
Message-ID: <4FDF9C54.7020809@gemini.edu>

Just a last minute reminder (sorry, probably too late for some) that
the early registration deadline for SciPy is today... After that it
will go up $50-100.

We have a few interesting talks and some discussion on the state and
future of Python in astronomy planned for the astronomy mini-symposium
and I'd still like to take part in an AstroPy sprint if you're
interested in joining that.

You can find a draft of the tutorials & general talks on the SciPy
page now:

   http://conference.scipy.org/scipy2012/

Cheers,

James.


From jturner at gemini.edu  Mon Jun 18 18:35:28 2012
From: jturner at gemini.edu (James Turner)
Date: Mon, 18 Jun 2012 18:35:28 -0400
Subject: [AstroPy] SciPy 2012
In-Reply-To: <CALO3=5FNSDDG0UNC6nPcNhu5Qaq3NqcrNaMm8ct27X4J0LCkMA@mail.gmail.com>
References: <4F735A23.9040402@gemini.edu> <4FDF9C54.7020809@gemini.edu>
	<CALO3=5FNSDDG0UNC6nPcNhu5Qaq3NqcrNaMm8ct27X4J0LCkMA@mail.gmail.com>
Message-ID: <4FDFAD30.7030407@gemini.edu>

On 18/06/12 17:26, Matthew Turk wrote:
> Hi James,
>
> Where is the info on the astronomy mini-symposium?
>
> -Matt

It seems not to be up there yet, but what I believe we currently
have is 3 talks (AstroPy, the upcoming STScI-Gemini Python/IRAF
release and AstroML, which is an upcoming data mining & machine
learning package for astronomy with an associated textbook), as
well as the discussion session. (I hope no-one minds me pre-empting
the conference page, given the timing). I gather Erik will also be
sending an email regarding an AstroPy sprint. It's too bad the
timing & funding aren't good for some people this year but I think
this should be a good opportunity for a group of us to gain some
momentum on improving our platform together & learn about each
other's tools.

Cheers,

James


> On Mon, Jun 18, 2012 at 5:23 PM, James Turner<jturner at gemini.edu>  wrote:
>> Just a last minute reminder (sorry, probably too late for some) that
>> the early registration deadline for SciPy is today... After that it
>> will go up $50-100.
>>
>> We have a few interesting talks and some discussion on the state and
>> future of Python in astronomy planned for the astronomy mini-symposium
>> and I'd still like to take part in an AstroPy sprint if you're
>> interested in joining that.
>>
>> You can find a draft of the tutorials&  general talks on the SciPy
>> page now:
>>
>>    http://conference.scipy.org/scipy2012/
>>
>> Cheers,
>>
>> James.
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy


From erik.tollerud at gmail.com  Tue Jun 19 02:51:23 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Tue, 19 Jun 2012 02:51:23 -0400
Subject: [AstroPy] ANN: Astropy v0.1
Message-ID: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>

Hello all,

On behalf of the Astropy team, I'm excited to announce the first
release of the Astropy core package: v0.1!

The Astropy core package is intended to provide much of the common
functionality and tools needed for performing astronomy and
astrophysics with Python.

This release should be thought of as a "developer preview" - it has
much of the packaging and data handling framework in place, but the
actual astronomy functionality and frameworks are still incomplete.
Nevertheless, you can already make use of the existing functionality,
which is fully tested. Key features include:

* Standard cosmological distance calculations (astropy.cosmology)
* Data Tables (astropy.table) including a wide variety of ASCII
formats common in astronomy (astropy.io.ascii)
* FITS File handling - formerly PyFITS (astropy.io.fits)
* VOTable parser and writer (astropy.io.vo)
* WCS representations - formerly pywcs (astropy.wcs)
* Consistent documentation style
* Utilities to ease creation of new, independent packages (affiliated packages)
* A dedicated logging system

The package can be downloaded from
http://github.com/downloads/astropy/astropy/astropy-0.1.tar.gz . More
information is available at the Astropy site ( http://astropy.org ),
the package documentation ( http://docs.astropy.org ), and the
github repository ( http://github.com/astropy/astropy ).

We also encourage developers writing new packages to begin writing the
code against this version. Packages making use of Astropy should feel
free to join up as affiliated packages and begin transitioning to the
affiliated package template
( https://github.com/astropy/package-template ). In the next version,
we hope to implement a working affiliated package installer, so it will
be worth your while!


For the Astropy developers,
Erik Tollerud


From astropy at liska.ath.cx  Tue Jun 19 11:19:31 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Tue, 19 Jun 2012 17:19:31 +0200
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
References: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>
Message-ID: <ytzpq8v5ny4.fsf@news.ole.ath.cx>

Hello,

Erik Tollerud <erik.tollerud at gmail.com> writes:
> On behalf of the Astropy team, I'm excited to announce the first
> release of the Astropy core package: v0.1!

Congratulations!!! It is nice to see that this work progresses!

I just downloaded it and had a quick look from the perspective of
packaging it.

Just a few questions/comments:

* I very much like the idea of having the external C code in a specific
  diretory tree "cextern" since this makes it easier to split this part
  and use the versions provided with the OS. I would guess that also
  the "wcslib" part will move from pywcs to cextern?

* Will pywcs survive as external package or shall we consider moving
  from pywcs to astropy.wcs in the medium term?

* I would volunteer to do the packaging for Debian (and Ubuntu).

Best regards

Ole


From perry at stsci.edu  Tue Jun 19 11:58:20 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Tue, 19 Jun 2012 11:58:20 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <ytzpq8v5ny4.fsf@news.ole.ath.cx>
References: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>
	<ytzpq8v5ny4.fsf@news.ole.ath.cx>
Message-ID: <725AF34D-D2F8-40F5-87AB-3690E36133B2@stsci.edu>


On Jun 19, 2012, at 11:19 AM, Ol? Streicher wrote:

> Hello,
>
> Erik Tollerud <erik.tollerud at gmail.com> writes:
>> On behalf of the Astropy team, I'm excited to announce the first
>> release of the Astropy core package: v0.1!
>
> Congratulations!!! It is nice to see that this work progresses!
>
> I just downloaded it and had a quick look from the perspective of
> packaging it.
>
> Just a few questions/comments:
>
> * I very much like the idea of having the external C code in a  
> specific
>  diretory tree "cextern" since this makes it easier to split this part
>  and use the versions provided with the OS. I would guess that also
>  the "wcslib" part will move from pywcs to cextern?
>
> * Will pywcs survive as external package or shall we consider moving
>  from pywcs to astropy.wcs in the medium term?
>
It is our plan to migrate pywcs (if you are talking about our version)  
to astropy exclusively. There will be some period for which it is  
available both ways, but once astropy is widely used, that is the only  
place it will reside.

Perry




From xarthisius.kk at gmail.com  Tue Jun 19 12:02:12 2012
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Tue, 19 Jun 2012 18:02:12 +0200
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <ytzpq8v5ny4.fsf@news.ole.ath.cx>
References: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>
	<ytzpq8v5ny4.fsf@news.ole.ath.cx>
Message-ID: <4FE0A284.70209@gmail.com>

Hi,
On 19.06.2012 17:19, Ol? Streicher wrote:
> * I very much like the idea of having the external C code in a specific
>   diretory tree "cextern" since this makes it easier to split this part
>   and use the versions provided with the OS. I would guess that also
>   the "wcslib" part will move from pywcs to cextern?
speaking of which, are you willing to accept patches to make usage of
cextern/* as well as astropy/extern/*, optional?
BTW, astropy-0.1 is now available in Gentoo Linux :)
Cheers,
Kacper Kowalik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/astropy/attachments/20120619/8fe54022/attachment.sig>

From jh at physics.ucf.edu  Tue Jun 19 13:25:01 2012
From: jh at physics.ucf.edu (Joe Harrington)
Date: Tue, 19 Jun 2012 13:25:01 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <mailman.1.1340125201.31750.astropy@scipy.org>
	(astropy-request@scipy.org)
Message-ID: <wl8fw9r1afm.fsf@physics.ucf.edu>

> Nevertheless, you can already make use of the existing functionality,
> which is fully tested. Key features include:

Excellent news!

The question "when to switch" comes up.  I'm sure some parts (pyfits,
pywcs, etc) are very stable and the calling syntax, data objects,
etc. won't change in the future.  I'm equally sure some things are still
highly alpha.  Would it make sense to provide a list
(help(astropy.stability())?) that lays out what you can depend on and
where you should or might expect changes?  Or, is there a pathway from
public code development with public usage and the understanding that
it might change, to freezing it and including it in astropy, such that
astropy is only mature, stable code?

--jh--


From jcpassy at gmail.com  Tue Jun 19 13:40:34 2012
From: jcpassy at gmail.com (Jean-Claude Passy)
Date: Tue, 19 Jun 2012 13:40:34 -0400
Subject: [AstroPy] error building astropy on Lion
Message-ID: <4FE0B992.3030605@uvic.ca>

Hi,

I am new on the mailing list and would like to try the astropy package. 
Unfortunately, I cannot get it installed with the pip command (see error 
below).
I have installed a full version of Python 2.7.2 through the yT package. 
I am running on Mac OS Lion.

I would really appreciate if someone could help me fix this.
Thanks a lot,

JC


------------------------------------------------------------------------------------------------
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes -DECHO -DWCSTRIG_MACRO -DASTROPY_WCS_BUILD 
-D_GNU_SOURCE -DWCSVERSION=4.10 -DNDEBUG -UDEBUG 
-I/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/numpy/core/include 
-Iastropy/wcs/src/wcslib/C -Iastropy/wcs/include 
-I/Users/jcpassy/Work/yt-x86_64/include/python2.7 -c 
astropy/wcs/src/astropy_wcs.c -o 
build/temp.macosx-10.4-x86_64-2.7/astropy/wcs/src/astropy_wcs.o

astropy/wcs/src/astropy_wcs.c:987:1: internal compiler error: in 
inline_small_functions, at ipa-inline.c:1421

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

error: command 'gcc' failed with exit status 1

----------------------------------------

Command /Users/jcpassy/Work/yt-x86_64/bin/python2.7 -c "import 
setuptools;__file__='/Users/jcpassy/Work/build/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', 
'\n'), __file__, 'exec'))" install --single-version-externally-managed 
--record 
/var/folders/t8/81q6fg4d1fz49ylm0ycp3k2h0000gp/T/pip-D4L8Ho-record/install-record.txt 
failed with error code 1 in /Users/jcpassy/Work/build/astropy

Exception information:
Traceback (most recent call last):
   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/basecommand.py", 
line 104, in main
     status = self.run(options, args)
   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/commands/install.py", 
line 250, in run
     requirement_set.install(install_options, global_options)
   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py", 
line 1133, in install
     requirement.install(install_options, global_options)
   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py", 
line 577, in install
     cwd=self.source_dir, filter_stdout=self._filter_install, 
show_stdout=False)
   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/__init__.py", 
line 256, in call_subprocess
     % (command_desc, proc.returncode, cwd))
InstallationError: Command /Users/jcpassy/Work/yt-x86_64/bin/python2.7 
-c "import 
setuptools;__file__='/Users/jcpassy/Work/build/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', 
'\n'), __file__, 'exec'))" install --single-version-externally-managed 
--record 
/var/folders/t8/81q6fg4d1fz49ylm0ycp3k2h0000gp/T/pip-D4L8Ho-record/install-record.txt 
failed with error code 1 in /Users/jcpassy/Work/build/astropy
------------------------------------------------------------------------------------------------



From tim.jenness at gmail.com  Tue Jun 19 13:51:00 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Tue, 19 Jun 2012 10:51:00 -0700
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <4FE0B992.3030605@uvic.ca>
References: <4FE0B992.3030605@uvic.ca>
Message-ID: <CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>

On Tue, Jun 19, 2012 at 10:40 AM, Jean-Claude Passy <jcpassy at gmail.com> wrote:
> Hi,
>
> I am new on the mailing list and would like to try the astropy package.
> Unfortunately, I cannot get it installed with the pip command (see error
> below).
> I have installed a full version of Python 2.7.2 through the yT package.
> I am running on Mac OS Lion.
>

I just built it on lion with the system gcc-4.2 and Python 3.2 and it
was fine in the sense that it built ok. It did fail some tests.

> I would really appreciate if someone could help me fix this.
> Thanks a lot,
>

Are you using the Xcode gcc compiler or one that you have installed
yourself? That's a fatal bug in gcc that you are reporting.

-- 
Tim Jenness


From jh at physics.ucf.edu  Tue Jun 19 13:57:16 2012
From: jh at physics.ucf.edu (Joe Harrington)
Date: Tue, 19 Jun 2012 13:57:16 -0400
Subject: [AstroPy] astropy docs: importing standards
Message-ID: <wl8d34v18xv.fsf@physics.ucf.edu>

The numpy and scipy communities wrestled with the issue of importing
into the top level and decided it was poor practice, for a variety of
reasons we don't need to rehash here.  Hence, there is the standard
"import numpy as np" and its friends.  In the astropy docs, however,
there is a lot of importing into the top level.  Usually this is just
single functions, but it breaks when you try to get example code to work
in your own function, where you imported all of astropy and need to say
"astropy." before each call.  I propose that we skip the arduous debates
those communities went through and just adopt their solution by defining
some importation standards:

import astropy as ap
import astropy.io as api
import astropy.io.fits as apif
etc.

... and fix the docs to use these consistently.  Most important is the
standard that we NEVER import * into the top level, since future
versions could include names that conflict with standard
Python names.

There are other abbreviations we could use, including:

import astropy.io.fits as pf
or
import astropy.io.fits as pyfits

since many already do:

import pyfits as pf
or
import pyfits

...and the same for pywcs.  What exact abbreviations we choose are less
important than that we choose them and always use them.  The result
otherwise is bugs and other suffering as code gets shared from place to
place and breaks.

Thanks,

--jh--
Prof. Joe Harrington
Planetary Sciences Group
Department of Physics
University of Central Florida
Orlando, FL 32816-2385
jh at physics.ucf.edu
planets.ucf.edu


From jh at physics.ucf.edu  Tue Jun 19 14:04:38 2012
From: jh at physics.ucf.edu (Joe Harrington)
Date: Tue, 19 Jun 2012 14:04:38 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com> (message from
	Wolfgang Kerzendorf on Tue, 19 Jun 2012 13:40:31 -0400)
Message-ID: <wl8a9zz18ll.fsf@physics.ucf.edu>

I'm happy with that, but it should be clearly documented in a central,
well-known place, so that people know what they can and can't depend on
to be stable.  If I'm writing software for a spacecraft project or
instrument calibration pipeline that MUST be long-term stable, I might
choose to use pyfits (now stable) but not NDData (not stable).  A
student working on a homework assignment might safely use NDData.

--jh--

On Tue, 19 Jun 2012 13:40:31 -0400 Wolfgang Kerzendorf
<wkerzendorf at gmail.com> wrote:
> 
> Hi Joe,
> 
> I would think that many other things (NDData as one prime example) are
> still i> n high alpha. I think with many of these new functions we
> will have t> o iterate somewhat between developing - usage feedback to
> get to > a stable interface. I think this release shows relatively
> well what w> ill be there (there's likely going to be a class called
> nddata) b> ut that their interfaces might change.
> 
> Cheers
>   W
> On 2012-06-19, at 1:25 PM, Joe Harrington wrote:
> 
> >> Nevertheless, you can already make use of the existing functionality,
> >> which is fully tested. Key features include:
> > 
> > Excellent news!
> > 
> > The question "when to switch" comes up.  I'm sure some parts (pyfits,
> > pywcs, etc) are very stable and the calling syntax, data objects,
> > etc. won't change in the future.  I'm equally sure some things are still
> > highly alpha.  Would it make sense to provide a list
> > (help(astropy.stability())?) that lays out what you can depend on and
> > where you should or might expect changes?  Or, is there a pathway from
> > public code development with public usage and the understanding that
> > it might change, to freezing it and including it in astropy, such that
> > astropy is only mature, stable code?
> > 
> > --jh--


From thomas.robitaille at gmail.com  Tue Jun 19 15:13:40 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 19 Jun 2012 22:13:40 +0300
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <wl8a9zz18ll.fsf@physics.ucf.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
Message-ID: <CAGMHX_2tzGMdp+Gk+7ZzZnC2PZmXNngru4kj4rKp+PEmyL8oTw@mail.gmail.com>

Just to be clear, astropy.io.fits is basically a direct port of
pyfits, astropy.wcs is a direct port of pywcs, and astropy.io.ascii is
a direct port of asciitable, so those components are likely to be as
stable as the original packages themselves. If you are using those
components, then you should be fine. However, astropy 0.1 is of course
an alpha release, so the package as a whole is still going to evolve
significantly, with a number of new components planned.

Cheers,
Tom

On 19 June 2012 21:04, Joe Harrington <jh at physics.ucf.edu> wrote:
> I'm happy with that, but it should be clearly documented in a central,
> well-known place, so that people know what they can and can't depend on
> to be stable. ?If I'm writing software for a spacecraft project or
> instrument calibration pipeline that MUST be long-term stable, I might
> choose to use pyfits (now stable) but not NDData (not stable). ?A
> student working on a homework assignment might safely use NDData.
>
> --jh--
>
> On Tue, 19 Jun 2012 13:40:31 -0400 Wolfgang Kerzendorf
> <wkerzendorf at gmail.com> wrote:
>>
>> Hi Joe,
>>
>> I would think that many other things (NDData as one prime example) are
>> still i> n high alpha. I think with many of these new functions we
>> will have t> o iterate somewhat between developing - usage feedback to
>> get to > a stable interface. I think this release shows relatively
>> well what w> ill be there (there's likely going to be a class called
>> nddata) b> ut that their interfaces might change.
>>
>> Cheers
>> ? W
>> On 2012-06-19, at 1:25 PM, Joe Harrington wrote:
>>
>> >> Nevertheless, you can already make use of the existing functionality,
>> >> which is fully tested. Key features include:
>> >
>> > Excellent news!
>> >
>> > The question "when to switch" comes up. ?I'm sure some parts (pyfits,
>> > pywcs, etc) are very stable and the calling syntax, data objects,
>> > etc. won't change in the future. ?I'm equally sure some things are still
>> > highly alpha. ?Would it make sense to provide a list
>> > (help(astropy.stability())?) that lays out what you can depend on and
>> > where you should or might expect changes? ?Or, is there a pathway from
>> > public code development with public usage and the understanding that
>> > it might change, to freezing it and including it in astropy, such that
>> > astropy is only mature, stable code?
>> >
>> > --jh--
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From embray at stsci.edu  Tue Jun 19 18:18:14 2012
From: embray at stsci.edu (Erik Bray)
Date: Tue, 19 Jun 2012 18:18:14 -0400
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <4FE0B992.3030605@uvic.ca>
References: <4FE0B992.3030605@uvic.ca>
Message-ID: <4FE0FAA6.9040305@stsci.edu>

On 06/19/2012 01:40 PM, Jean-Claude Passy wrote:
> I am running on Mac OS Lion.

Not according to your Python installation--it thinks you're still 
running OSX 10.4:

> build/temp.macosx-10.4-x86_64-2.7/astropy/wcs/src/astropy_wcs.o
              ^^^^^^^^^^^

Did you recently upgrade to Lion?  Upgrades from older OSX versions tend 
to cause all sorts of problems with older Python and/or gcc versions.

Have you tried upgrading or reinstalling your Python installation?

Erik


From embray at stsci.edu  Tue Jun 19 18:23:18 2012
From: embray at stsci.edu (Erik Bray)
Date: Tue, 19 Jun 2012 18:23:18 -0400
Subject: [AstroPy] astropy docs: importing standards
In-Reply-To: <wl8d34v18xv.fsf@physics.ucf.edu>
References: <wl8d34v18xv.fsf@physics.ucf.edu>
Message-ID: <4FE0FBD6.8040804@stsci.edu>

On 06/19/2012 01:57 PM, Joe Harrington wrote:
> I propose that we skip the arduous debates
> those communities went through and just adopt their solution by defining
> some importation standards:
>
> import astropy as ap
> import astropy.io as api

^--- Please not this.  The fact that this abbreviates to "api" is very 
confusing, considering that "API" already has a specific meaning.  I 
think many people would be confused by this.

> There are other abbreviations we could use, including:
>
> import astropy.io.fits as pf
> or
> import astropy.io.fits as pyfits

One standard we discussed for astropy is this:

 >>> from astropy.io import fits
 >>> fits.open(...)

Likewise for wcs one would use:

 >>> from astropy import wcs

Unfortunately not all of the documentation has been updated to follow 
that convention consistently.  I meant to do as much for the 
astropy.io.fits docs, but dropped the ball on that--something to do for 
the next release.

In any case, I agree there should be some conventions for this and they 
should be documented and endorsed.

Thanks,

Erik B.


From abhijithrajan at asu.edu  Tue Jun 19 19:15:17 2012
From: abhijithrajan at asu.edu (Abhijith Rajan)
Date: Tue, 19 Jun 2012 16:15:17 -0700
Subject: [AstroPy] python equivalent of gaussfold?
Message-ID: <CAHfbfxF864p5kJg3XWOi_tjde9yyD6JirR0TduA_u1wtnW=3_Q@mail.gmail.com>

Dear astropyers,

I was wondering if there is a convenient equivalent to
http://astro.uni-tuebingen.de/software/idl/aitlib/misc/gaussfold.pro.

Thanks
Abhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120619/e9f15fe0/attachment.html>

From taro at ap.smu.ca  Tue Jun 19 20:42:33 2012
From: taro at ap.smu.ca (Taro Sato)
Date: Tue, 19 Jun 2012 17:42:33 -0700
Subject: [AstroPy] python equivalent of gaussfold?
In-Reply-To: <CAHfbfxF864p5kJg3XWOi_tjde9yyD6JirR0TduA_u1wtnW=3_Q@mail.gmail.com>
References: <CAHfbfxF864p5kJg3XWOi_tjde9yyD6JirR0TduA_u1wtnW=3_Q@mail.gmail.com>
Message-ID: <CA+ABeczAig0-U65QiuqiKiWOycJxzErTHuf=6NgGOjG9NBmZWw@mail.gmail.com>

On Tue, Jun 19, 2012 at 4:15 PM, Abhijith Rajan <abhijithrajan at asu.edu> wrote:
> Dear astropyers,
>
> I was wondering if there is a convenient equivalent
> to?http://astro.uni-tuebingen.de/software/idl/aitlib/misc/gaussfold.pro.
>
> Thanks
> Abhi
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



Abhi -- For a relatively simple IDL task like this, you may just want
to take a peek at the source and look for equivalent functions in
scipy/numpy.  Perhaps the combination of something like

numpy.linspace
numpy.interp

and one of

scipy.ndimage.gaussian_filter
scipy.signal.convolve
scipy.signal.fftconvolve

would achieve what you want....


-- 
Taro Sato
Department of Astronomy & Physics
Saint Mary's University             email: taro at ap.smu.ca
Halifax, NS B3H 3C3                 phone: (902)420-5018
Canada                                web: http://ap.smu.ca/~taro


From erik.tollerud at gmail.com  Wed Jun 20 01:44:47 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 20 Jun 2012 01:44:47 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <wl8a9zz18ll.fsf@physics.ucf.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
Message-ID: <CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>

On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher <astropy at liska.ath.cx> wrote:
> * I very much like the idea of having the external C code in a specific
> ?diretory tree "cextern" since this makes it easier to split this part
> ?and use the versions provided with the OS. I would guess that also
> ?the "wcslib" part will move from pywcs to cextern?

Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
but I think his plan is to keep wcslib where it is, because the
python-level wrapper is rather closely tied to the particular version
of wcslib.  The idea is that cextern is for C code that is essentially
included "wholly" (like extern), and things that are tightly coupled
to the python code (including Cython .pyx files) will live in the
python source tree.  There's more about  this is in the README file in
the cextern directory.



On Tue, Jun 19, 2012 at 12:02 PM, Kacper Kowalik
<xarthisius.kk at gmail.com> wrote:
> speaking of which, are you willing to accept patches to make usage of
> cextern/* as well as astropy/extern/*, optional?

That's definitely in the pipeline as part of a larger system for
dealing with optional dependencies, including things like scipy and
matplotlib that we do *not* plan to bundle - see
https://github.com/astropy/astropy/issues/63. If you want to take a
stab at it, feel free! (Although you might want to email me separately
if you want to dive into this, as it probably requires some thought
about how to hook it into other parts of astropy)

> BTW, astropy-0.1 is now available in Gentoo Linux :)

Thanks - nice and fast!



On Tue, Jun 19, 2012 at 2:04 PM, Joe Harrington <jh at physics.ucf.edu> wrote:
> I'm happy with that, but it should be clearly documented in a central,
> well-known place, so that people know what they can and can't depend on
> to be stable. ?If I'm writing software for a spacecraft project or
> instrument calibration pipeline that MUST be long-term stable, I might
> choose to use pyfits (now stable) but not NDData (not stable). ?A
> student working on a homework assignment might safely use NDData.


You have a very good point her - can you create an issue in the github
repo about it so we remember to address it?  (I can do it myself, if
you'd rather not, but I prefer for people to "own" good issues that
they raise, if they're willing  -credit where credit is due and all
that.)



-- 
Erik Tollerud


From astropy at liska.ath.cx  Wed Jun 20 03:37:55 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 20 Jun 2012 09:37:55 +0200
Subject: [AstroPy] External packages in astropy (was: Re: [astropy-dev] ANN:
	Astropy v0.1)
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
Message-ID: <ytzliji5t7w.fsf_-_@news.ole.ath.cx>

Erik Tollerud <erik.tollerud at gmail.com> writes:
> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher <astropy at liska.ath.cx> wrote:
>> * I very much like the idea of having the external C code in a specific
>> ?diretory tree "cextern" since this makes it easier to split this part
>> ?and use the versions provided with the OS. I would guess that also
>> ?the "wcslib" part will move from pywcs to cextern?

> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
> but I think his plan is to keep wcslib where it is, because the
> python-level wrapper is rather closely tied to the particular version
> of wcslib.

I don't see this tight bound to a specific version. pywcs/astropy.wcs
uses the official API of wcslib, so it should work with every
version. And the shared library contains a SONAME that is going to be
changed if binary compability breaks.

Source and binary compability can be checked with the upstream tracker

http://linuxtesting.org/upstream-tracker/versions/wcslib.html

(which is down in the moment I write this), and this shows that the last
versions (from 4.8, if I remember correctly) are all compatible. 

> The idea is that cextern is for C code that is essentially included
> "wholly" (like extern), and things that are tightly coupled to the
> python code (including Cython .pyx files) will live in the python
> source tree.  There's more about this is in the README file in the
> cextern directory.

When astropy is packaged for a distribution (probably others than Debian
and Ubuntu as well), there is a need to replace convienience copies of
third-party code by references to the according packages. Making this
easier is IMO one of the uses of cextern. I would even suggest to rename
it to "thirdparty" of similar, since this is probably not limited to C
code.

At least, it would be nice to have build-time configuration options to
use external packages instead of the distributed ones (adjustable since
the external packages may vary between the Linux distributions).

I would also suggest a rule that external packages should be used
unchanged in the astropy tree (if changes are needed, they should be
discussed/included with the original authors).

Best regards

Ole


From astropy at liska.ath.cx  Wed Jun 20 03:44:09 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 20 Jun 2012 09:44:09 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
Message-ID: <ytzhau65sxi.fsf@news.ole.ath.cx>

astropy at liska.ath.cx (Ol? Streicher) writes:
> Source and binary compability can be checked with the upstream tracker
>
> http://linuxtesting.org/upstream-tracker/versions/wcslib.html

Sorry, this way the old version which is out of date now.
The correct one is

http://upstream-tracker.org/versions/wcslib.html

I remommend to put libraries that are used in astrowise there: the
maintainer (Andrey Ponomarenko) is very responsive in this, and it helps
a lot to check binary compability.

Best

Ole


From jslavin at cfa.harvard.edu  Wed Jun 20 09:09:23 2012
From: jslavin at cfa.harvard.edu (Jonathan Slavin)
Date: Wed, 20 Jun 2012 09:09:23 -0400
Subject: [AstroPy] python equivalent of gaussfold?
Message-ID: <1340197763.25720.2.camel@shevek>

I think that scipy.ndimage.filters.gaussian_filter1d will do what you
want.

Jon

> On Tue, Jun 19, 2012 at 4:15 PM, Abhijith Rajan
> <abhijithrajan at asu.edu> wrote:
> > Dear astropyers,
> >
> > I was wondering if there is a convenient equivalent
> >
> to?http://astro.uni-tuebingen.de/software/idl/aitlib/misc/gaussfold.pro.
> >
> > Thanks
> > Abhi
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
> 
> 
> 
> Abhi -- For a relatively simple IDL task like this, you may just want
> to take a peek at the source and look for equivalent functions in
> scipy/numpy.  Perhaps the combination of something like
> 
> numpy.linspace
> numpy.interp
> 
> and one of
> 
> scipy.ndimage.gaussian_filter
> scipy.signal.convolve
> scipy.signal.fftconvolve
> 
> would achieve what you want....
> 
> 
> -- 
> Taro Sato
> Department of Astronomy & Physics
> Saint Mary's University             email: taro at ap.smu.ca
> Halifax, NS B3H 3C3                 phone: (902)420-5018
> Canada                                web: http://ap.smu.ca/~taro
> 
-- 
______________________________________________________________
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
______________________________________________________________



From perry at stsci.edu  Wed Jun 20 10:36:17 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 20 Jun 2012 10:36:17 -0400
Subject: [AstroPy] External packages in astropy (was: Re: [astropy-dev]
	ANN: Astropy v0.1)
In-Reply-To: <ytzliji5t7w.fsf_-_@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
Message-ID: <A3C389CE-4053-48A6-840B-9AD7ECA84797@stsci.edu>


On Jun 20, 2012, at 3:37 AM, Ol? Streicher wrote:

> Erik Tollerud <erik.tollerud at gmail.com> writes:
>> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher  
>> <astropy at liska.ath.cx> wrote:
>>> * I very much like the idea of having the external C code in a  
>>> specific
>>>  diretory tree "cextern" since this makes it easier to split this  
>>> part
>>>  and use the versions provided with the OS. I would guess that also
>>>  the "wcslib" part will move from pywcs to cextern?
>
>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>> but I think his plan is to keep wcslib where it is, because the
>> python-level wrapper is rather closely tied to the particular version
>> of wcslib.
>
> I don't see this tight bound to a specific version. pywcs/astropy.wcs
> uses the official API of wcslib, so it should work with every
> version. And the shared library contains a SONAME that is going to be
> changed if binary compability breaks.
>
That hasn't always been true in the past. Perhaps it is stable enough  
now. Mike is the best judge of that.

Perry



From jcpassy at gmail.com  Wed Jun 20 12:17:45 2012
From: jcpassy at gmail.com (Jean-Claude Passy)
Date: Wed, 20 Jun 2012 12:17:45 -0400
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
Message-ID: <4FE1F7A9.2020107@uvic.ca>

Hello Tim,

yes, I am using the Xcode compiler:

--------------------------------------------------------------------------------

[12:15:30] Astrobook2:$ CC=/usr/bin/gcc pip install astropy

--------------------------------------------------------------------------------


Thanks,

JC

On 6/19/12 1:51 PM, Tim Jenness wrote:
> On Tue, Jun 19, 2012 at 10:40 AM, Jean-Claude Passy<jcpassy at gmail.com>  wrote:
>> Hi,
>>
>> I am new on the mailing list and would like to try the astropy package.
>> Unfortunately, I cannot get it installed with the pip command (see error
>> below).
>> I have installed a full version of Python 2.7.2 through the yT package.
>> I am running on Mac OS Lion.
>>
> I just built it on lion with the system gcc-4.2 and Python 3.2 and it
> was fine in the sense that it built ok. It did fail some tests.
>
>> I would really appreciate if someone could help me fix this.
>> Thanks a lot,
>>
> Are you using the Xcode gcc compiler or one that you have installed
> yourself? That's a fatal bug in gcc that you are reporting.
>


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

From thomas.robitaille at gmail.com  Wed Jun 20 12:25:20 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 20 Jun 2012 19:25:20 +0300
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <4FE1F7A9.2020107@uvic.ca>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
	<4FE1F7A9.2020107@uvic.ca>
Message-ID: <CAGMHX_28sx8e=V8ftzfeg9+26VKjhTN4uCFToL9bhsfoxSEioQ@mail.gmail.com>

Hi JC,

What is the output of:

/usr/bin/gcc --version

and

gcc --version

?

Cheers,
Tom

On 20 June 2012 19:17, Jean-Claude Passy <jcpassy at gmail.com> wrote:
> Hello Tim,
>
> yes, I am using the Xcode compiler:
>
> --------------------------------------------------------------------------------
> [12:15:30] Astrobook2:$ CC=/usr/bin/gcc pip install astropy
> --------------------------------------------------------------------------------
> Thanks,
>
> JC
>
>
> On 6/19/12 1:51 PM, Tim Jenness wrote:
>
> On Tue, Jun 19, 2012 at 10:40 AM, Jean-Claude Passy <jcpassy at gmail.com>
> wrote:
>
> Hi,
>
> I am new on the mailing list and would like to try the astropy package.
> Unfortunately, I cannot get it installed with the pip command (see error
> below).
> I have installed a full version of Python 2.7.2 through the yT package.
> I am running on Mac OS Lion.
>
> I just built it on lion with the system gcc-4.2 and Python 3.2 and it
> was fine in the sense that it built ok. It did fail some tests.
>
> I would really appreciate if someone could help me fix this.
> Thanks a lot,
>
> Are you using the Xcode gcc compiler or one that you have installed
> yourself? That's a fatal bug in gcc that you are reporting.
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From jcpassy at gmail.com  Wed Jun 20 12:41:32 2012
From: jcpassy at gmail.com (Jean-Claude Passy)
Date: Wed, 20 Jun 2012 12:41:32 -0400
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <CAGMHX_28sx8e=V8ftzfeg9+26VKjhTN4uCFToL9bhsfoxSEioQ@mail.gmail.com>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
	<4FE1F7A9.2020107@uvic.ca>
	<CAGMHX_28sx8e=V8ftzfeg9+26VKjhTN4uCFToL9bhsfoxSEioQ@mail.gmail.com>
Message-ID: <4FE1FD3C.2030206@uvic.ca>

Hi Tom,

here are the outputs:

-----------------------------------------------------------------

[12:36:08] Astrobook2:$ /usr/bin/gcc --version

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.9.00)

-----------------------------------------------------------------


and

-----------------------------------------------------------------

[12:37:14] Astrobook2:$ which gcc

/opt/mesasdk/bin/gcc

[12:37:17] Astrobook2:$ gcc --version

gcc (GCC) 4.7.0 20111114 (experimental)

-----------------------------------------------------------------


The gcc 4.7 is part of a package I had to install for another code. This 
is why I used $CC to specify which compiler to use.

Thanks a lot,

JC

On 6/20/12 12:25 PM, Thomas Robitaille wrote:
> Hi JC,
>
> What is the output of:
>
> /usr/bin/gcc --version
>
> and
>
> gcc --version
>
> ?
>
> Cheers,
> Tom
>
> On 20 June 2012 19:17, Jean-Claude Passy <jcpassy at gmail.com> wrote:
>> Hello Tim,
>>
>> yes, I am using the Xcode compiler:
>>
>> --------------------------------------------------------------------------------
>> [12:15:30] Astrobook2:$ CC=/usr/bin/gcc pip install astropy
>> --------------------------------------------------------------------------------
>> Thanks,
>>
>> JC
>>
>>
>> On 6/19/12 1:51 PM, Tim Jenness wrote:
>>
>> On Tue, Jun 19, 2012 at 10:40 AM, Jean-Claude Passy <jcpassy at gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I am new on the mailing list and would like to try the astropy package.
>> Unfortunately, I cannot get it installed with the pip command (see error
>> below).
>> I have installed a full version of Python 2.7.2 through the yT package.
>> I am running on Mac OS Lion.
>>
>> I just built it on lion with the system gcc-4.2 and Python 3.2 and it
>> was fine in the sense that it built ok. It did fail some tests.
>>
>> I would really appreciate if someone could help me fix this.
>> Thanks a lot,
>>
>> Are you using the Xcode gcc compiler or one that you have installed
>> yourself? That's a fatal bug in gcc that you are reporting.
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>


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

From tim.jenness at gmail.com  Wed Jun 20 12:50:12 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 20 Jun 2012 09:50:12 -0700
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <4FE1FD3C.2030206@uvic.ca>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
	<4FE1F7A9.2020107@uvic.ca>
	<CAGMHX_28sx8e=V8ftzfeg9+26VKjhTN4uCFToL9bhsfoxSEioQ@mail.gmail.com>
	<4FE1FD3C.2030206@uvic.ca>
Message-ID: <CA+G92Rfpfcy2J4LLcKuyZH4WThqkKcvjDnQ4i4287W+1bwF0AQ@mail.gmail.com>

On Wed, Jun 20, 2012 at 9:41 AM, Jean-Claude Passy <jcpassy at gmail.com> wrote:

> ----------------------------------------------------------------- [12:36:08]
> Astrobook2:$ /usr/bin/gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC)
> 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
> -----------------------------------------------------------------
> and
>
> ----------------------------------------------------------------- [12:37:14]
> Astrobook2:$ which gcc /opt/mesasdk/bin/gcc [12:37:17] Astrobook2:$ gcc
> --version gcc (GCC) 4.7.0 20111114 (experimental)
> -----------------------------------------------------------------
> The gcc 4.7 is part of a package I had to install for another code. This is
> why I used $CC to specify which compiler to use.
>

but the compile line says it's using plain "gcc" rather than
"/usr/bin/gcc" so it seems to be picking up your experimental
compiler. If you remove /opt/mesasdk/bin from your path do things
build ok?

-- 
Tim Jenness


From jcpassy at gmail.com  Wed Jun 20 13:05:38 2012
From: jcpassy at gmail.com (Jean-Claude Passy)
Date: Wed, 20 Jun 2012 13:05:38 -0400
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <CA+G92Rfpfcy2J4LLcKuyZH4WThqkKcvjDnQ4i4287W+1bwF0AQ@mail.gmail.com>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
	<4FE1F7A9.2020107@uvic.ca>
	<CAGMHX_28sx8e=V8ftzfeg9+26VKjhTN4uCFToL9bhsfoxSEioQ@mail.gmail.com>
	<4FE1FD3C.2030206@uvic.ca>
	<CA+G92Rfpfcy2J4LLcKuyZH4WThqkKcvjDnQ4i4287W+1bwF0AQ@mail.gmail.com>
Message-ID: <4FE202E2.400@uvic.ca>

Sorry, when I sent the first email I had used 'gcc'. I then specified 
$CC, and still got the same error even though it was picking the correct 
one this time (see below).

Cheers,

JC

----------------------------------------------------------------------------------------------------------------------------------

/usr/bin/gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes -DECHO -DWCSTRIG_MACRO -DASTROPY_WCS_BUILD 
-D_GNU_SOURCE -DWCSVERSION=4.10 -DNDEBUG -UDEBUG 
-I/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/numpy/core/include 
-Iastropy/wcs/src/wcslib/C -Iastropy/wcs/include 
-I/Users/jcpassy/Work/yt-x86_64/include/python2.7 -c 
astropy/wcs/src/wcslib/C/wcserr.c -o 
build/temp.macosx-10.4-x86_64-2.7/astropy/wcs/src/wcslib/C/wcserr.o


astropy/wcs/src/wcslib/C/wcserr.c:160: internal compiler error: 
Segmentation fault: 11


Please submit a full bug report,


with preprocessed source if appropriate.


See <URL:http://developer.apple.com/bugreporter> for instructions.


error: command '/usr/bin/gcc' failed with exit status 1


----------------------------------------


Command /Users/jcpassy/Work/yt-x86_64/bin/python2.7 -c "import 
setuptools;__file__='/Users/jcpassy/Work/build/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', 
'\n'), __file__, 'exec'))" install --single-version-externally-managed 
--record 
/var/folders/t8/81q6fg4d1fz49ylm0ycp3k2h0000gp/T/pip-S6j7of-record/install-record.txt 
failed with error code 1 in /Users/jcpassy/Work/build/astropy


Exception information:

Traceback (most recent call last):

   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/basecommand.py", 
line 104, in main

     status = self.run(options, args)

   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/commands/install.py", 
line 250, in run

     requirement_set.install(install_options, global_options)

   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py", 
line 1133, in install

     requirement.install(install_options, global_options)

   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py", 
line 577, in install

     cwd=self.source_dir, filter_stdout=self._filter_install, 
show_stdout=False)

   File 
"/Users/jcpassy/Work/yt-x86_64/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/__init__.py", 
line 256, in call_subprocess

     % (command_desc, proc.returncode, cwd))

InstallationError: Command /Users/jcpassy/Work/yt-x86_64/bin/python2.7 
-c "import 
setuptools;__file__='/Users/jcpassy/Work/build/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', 
'\n'), __file__, 'exec'))" install --single-version-externally-managed 
--record 
/var/folders/t8/81q6fg4d1fz49ylm0ycp3k2h0000gp/T/pip-S6j7of-record/install-record.txt 
failed with error code 1 in /Users/jcpassy/Work/build/astropy

----------------------------------------------------------------------------------------------------------------------------------



On 6/20/12 12:50 PM, Tim Jenness wrote:
> On Wed, Jun 20, 2012 at 9:41 AM, Jean-Claude Passy <jcpassy at gmail.com> wrote:
>
>> ----------------------------------------------------------------- [12:36:08]
>> Astrobook2:$ /usr/bin/gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC)
>> 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
>> -----------------------------------------------------------------
>> and
>>
>> ----------------------------------------------------------------- [12:37:14]
>> Astrobook2:$ which gcc /opt/mesasdk/bin/gcc [12:37:17] Astrobook2:$ gcc
>> --version gcc (GCC) 4.7.0 20111114 (experimental)
>> -----------------------------------------------------------------
>> The gcc 4.7 is part of a package I had to install for another code. This is
>> why I used $CC to specify which compiler to use.
>>
> but the compile line says it's using plain "gcc" rather than
> "/usr/bin/gcc" so it seems to be picking up your experimental
> compiler. If you remove /opt/mesasdk/bin from your path do things
> build ok?
>


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

From jcpassy at gmail.com  Wed Jun 20 13:41:48 2012
From: jcpassy at gmail.com (Jean-Claude Passy)
Date: Wed, 20 Jun 2012 13:41:48 -0400
Subject: [AstroPy] error building astropy on Lion
In-Reply-To: <3F1F3FB6-4F0F-40C7-8198-57BB6674A3CF@iap.fr>
References: <4FE0B992.3030605@uvic.ca>
	<CA+G92RfAuL2Ai3VndrzLGdTN0X_Q=T-MWqeHJY7HEzB7gGeC_Q@mail.gmail.com>
	<4FE1F7A9.2020107@uvic.ca>
	<3F1F3FB6-4F0F-40C7-8198-57BB6674A3CF@iap.fr>
Message-ID: <4FE20B5C.2050807@uvic.ca>

Hi JB,

thanks, it was indeed the issue. A CC=CLANG in front of the pip command 
fixed it, and I can now import the Astropy package within my python session.

Cheers,

JC


On 6/20/12 12:22 PM, Jean-Baptiste Marquette wrote:
>
> Any link to the already known issue in wcslib ?
>
> See bottom of page http://www.astro.rug.nl/software/kapteyn/intro.html
>
> I opened a ticket (#10468697 ) on Bug Reporter since last November?
>
> Cheers
> JB
>
>
>> Hello Tim,
>>
>> yes, I am using the Xcode compiler:
>>
>> --------------------------------------------------------------------------------
>>
>> [12:15:30] Astrobook2:$ CC=/usr/bin/gcc pip install astropy
>>
>> --------------------------------------------------------------------------------
>>
>>
>> Thanks,
>>
>> JC
>>
>> On 6/19/12 1:51 PM, Tim Jenness wrote:
>>> On Tue, Jun 19, 2012 at 10:40 AM, Jean-Claude Passy<jcpassy at gmail.com>  wrote:
>>>> Hi,
>>>>
>>>> I am new on the mailing list and would like to try the astropy package.
>>>> Unfortunately, I cannot get it installed with the pip command (see error
>>>> below).
>>>> I have installed a full version of Python 2.7.2 through the yT package.
>>>> I am running on Mac OS Lion.
>>>>
>>> I just built it on lion with the system gcc-4.2 and Python 3.2 and it
>>> was fine in the sense that it built ok. It did fail some tests.
>>>
>>>> I would really appreciate if someone could help me fix this.
>>>> Thanks a lot,
>>>>
>>> Are you using the Xcode gcc compiler or one that you have installed
>>> yourself? That's a fatal bug in gcc that you are reporting.
>>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> http://mail.scipy.org/mailman/listinfo/astropy
>


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

From mdroe at stsci.edu  Wed Jun 20 14:12:46 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 20 Jun 2012 14:12:46 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
Message-ID: <4FE2129E.7090002@stsci.edu>

On 06/20/2012 01:44 AM, Erik Tollerud wrote:
> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher <astropy at liska.ath.cx> wrote:
>> * I very much like the idea of having the external C code in a specific
>>   diretory tree "cextern" since this makes it easier to split this part
>>   and use the versions provided with the OS. I would guess that also
>>   the "wcslib" part will move from pywcs to cextern?
> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
> but I think his plan is to keep wcslib where it is, because the
> python-level wrapper is rather closely tied to the particular version
> of wcslib.  The idea is that cextern is for C code that is essentially
> included "wholly" (like extern), and things that are tightly coupled
> to the python code (including Cython .pyx files) will live in the
> python source tree.  There's more about  this is in the README file in
> the cextern directory.

Yes.  I also like the modularity of it -- if you want to produce an 
astropy without astropy.wcs, just delete the astropy/wcs directory. (Not 
that one would do that -- it just helps with maintenance down the road).

>
>
>
> On Tue, Jun 19, 2012 at 12:02 PM, Kacper Kowalik
> <xarthisius.kk at gmail.com> wrote:
>> speaking of which, are you willing to accept patches to make usage of
>> cextern/* as well as astropy/extern/*, optional?
> That's definitely in the pipeline as part of a larger system for
> dealing with optional dependencies, including things like scipy and
> matplotlib that we do *not* plan to bundle - see
> https://github.com/astropy/astropy/issues/63. If you want to take a
> stab at it, feel free! (Although you might want to email me separately
> if you want to dive into this, as it probably requires some thought
> about how to hook it into other parts of astropy)

For what it's worth, the only library in cextern at present is expat.  
If it fails to build, astropy.util.xml has fallback Python code to work 
around it (it will be much slower, of course).  Using the system expat 
is tricky, because the expat has to be configured the way we expect it 
to be (basically that its expat_config.h is the same as ours), and I 
don't think that's a given everywhere.

Mike


From mdroe at stsci.edu  Wed Jun 20 14:22:01 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 20 Jun 2012 14:22:01 -0400
Subject: [AstroPy] External packages in astropy
In-Reply-To: <ytzliji5t7w.fsf_-_@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
Message-ID: <4FE214C9.3030201@stsci.edu>

On 06/20/2012 03:37 AM, Ol? Streicher wrote:
> Erik Tollerud <erik.tollerud at gmail.com> writes:
>> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher <astropy at liska.ath.cx> wrote:
>>> * I very much like the idea of having the external C code in a specific
>>>   diretory tree "cextern" since this makes it easier to split this part
>>>   and use the versions provided with the OS. I would guess that also
>>>   the "wcslib" part will move from pywcs to cextern?
>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>> but I think his plan is to keep wcslib where it is, because the
>> python-level wrapper is rather closely tied to the particular version
>> of wcslib.
> I don't see this tight bound to a specific version. pywcs/astropy.wcs
> uses the official API of wcslib, so it should work with every
> version. And the shared library contains a SONAME that is going to be
> changed if binary compability breaks.
>
> Source and binary compability can be checked with the upstream tracker
>
> http://linuxtesting.org/upstream-tracker/versions/wcslib.html
>
> (which is down in the moment I write this), and this shows that the last
> versions (from 4.8, if I remember correctly) are all compatible.

I don't see how this proves that case.  API stability has no reflection 
on correctness.  There are bugfixes to the error handling in 4.13 that 
allow the astropy.wcs unit tests to pass, that do not pass with previous 
versions.

>
>> The idea is that cextern is for C code that is essentially included
>> "wholly" (like extern), and things that are tightly coupled to the
>> python code (including Cython .pyx files) will live in the python
>> source tree.  There's more about this is in the README file in the
>> cextern directory.
> When astropy is packaged for a distribution (probably others than Debian
> and Ubuntu as well), there is a need to replace convienience copies of
> third-party code by references to the according packages. Making this
> easier is IMO one of the uses of cextern. I would even suggest to rename
> it to "thirdparty" of similar, since this is probably not limited to C
> code.
>
> At least, it would be nice to have build-time configuration options to
> use external packages instead of the distributed ones (adjustable since
> the external packages may vary between the Linux distributions).
>
> I would also suggest a rule that external packages should be used
> unchanged in the astropy tree (if changes are needed, they should be
> discussed/included with the original authors).
>
You can see our patches to wcslib here:

https://github.com/astropy/astropy/tree/master/astropy/wcs/patches

"compiler_warnings.patch" is not strictly necessary, but nice to have.

"extended_ctype.patch" makes wcslib compatible with FITS files that 
contain SIP information.  This patch will not be included upstream for 
political reasons.  Without this patch, astropy.wcs can not support SIP 
and is thus effectively broken.

I have been told by the upstream author that MS-Windows compatibility is 
not something he cares about.

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

From xarthisius.kk at gmail.com  Wed Jun 20 14:26:44 2012
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Wed, 20 Jun 2012 20:26:44 +0200
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <4FE2129E.7090002@stsci.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<4FE2129E.7090002@stsci.edu>
Message-ID: <4FE215E4.6040700@gmail.com>

On 20.06.2012 20:12, Michael Droettboom wrote:
> On 06/20/2012 01:44 AM, Erik Tollerud wrote:
>> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher <astropy at liska.ath.cx> wrote:
>>> * I very much like the idea of having the external C code in a specific
>>>   diretory tree "cextern" since this makes it easier to split this part
>>>   and use the versions provided with the OS. I would guess that also
>>>   the "wcslib" part will move from pywcs to cextern?
>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>> but I think his plan is to keep wcslib where it is, because the
>> python-level wrapper is rather closely tied to the particular version
>> of wcslib.  The idea is that cextern is for C code that is essentially
>> included "wholly" (like extern), and things that are tightly coupled
>> to the python code (including Cython .pyx files) will live in the
>> python source tree.  There's more about  this is in the README file in
>> the cextern directory.
> 
> Yes.  I also like the modularity of it -- if you want to produce an 
> astropy without astropy.wcs, just delete the astropy/wcs directory. (Not 
> that one would do that -- it just helps with maintenance down the road).
> 
>>
>>
>>
>> On Tue, Jun 19, 2012 at 12:02 PM, Kacper Kowalik
>> <xarthisius.kk at gmail.com> wrote:
>>> speaking of which, are you willing to accept patches to make usage of
>>> cextern/* as well as astropy/extern/*, optional?
>> That's definitely in the pipeline as part of a larger system for
>> dealing with optional dependencies, including things like scipy and
>> matplotlib that we do *not* plan to bundle - see
>> https://github.com/astropy/astropy/issues/63. If you want to take a
>> stab at it, feel free! (Although you might want to email me separately
>> if you want to dive into this, as it probably requires some thought
>> about how to hook it into other parts of astropy)
> 
> For what it's worth, the only library in cextern at present is expat.  
> If it fails to build, astropy.util.xml has fallback Python code to work 
> around it (it will be much slower, of course).  Using the system expat 
> is tricky, because the expat has to be configured the way we expect it 
> to be (basically that its expat_config.h is the same as ours), and I 
> don't think that's a given everywhere.

I wish it was only that :/ I've just got security notice from our QA
team about bundled zlib. It's not astropy issue per se, rather pyfits'
one. Is that zlib copy modified somehow, if not is there a reason not to
use system library?
Cheers,
Kacper

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/astropy/attachments/20120620/8d136573/attachment.sig>

From mdroe at stsci.edu  Wed Jun 20 14:35:37 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 20 Jun 2012 14:35:37 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <ytzpq8v5ny4.fsf@news.ole.ath.cx>
References: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>
	<ytzpq8v5ny4.fsf@news.ole.ath.cx>
Message-ID: <4FE217F9.9010907@stsci.edu>

On 06/19/2012 11:19 AM, Ol? Streicher wrote:
> Hello,
>
> Erik Tollerud <erik.tollerud at gmail.com> writes:
>> On behalf of the Astropy team, I'm excited to announce the first
>> release of the Astropy core package: v0.1!
>
> * Will pywcs survive as external package or shall we consider moving
>    from pywcs to astropy.wcs in the medium term?
>
pywcs is still being maintained, at contains all of the bugfixes that go 
into astropy.wcs. It will probably be maintained (since we use it a lot 
internally) until astropy is a viable replacement for everything.

My other contribution, io.vo is less likely to be maintained as a 
standalone package. It would benefit enormously from being moved to the 
new Table package in astropy, which would obviously introduce a major 
dependency on astropy, so that work may as well only happen within astropy.

Mike


From embray at stsci.edu  Wed Jun 20 14:46:44 2012
From: embray at stsci.edu (Erik Bray)
Date: Wed, 20 Jun 2012 14:46:44 -0400
Subject: [AstroPy] [astropy-dev] ANN: Astropy v0.1
In-Reply-To: <4FE217F9.9010907@stsci.edu>
References: <CAARXUwWZq6eDX5nBKu2WHiSPMnx7qSEovFuhhy6nbPD3E-WT4g@mail.gmail.com>
	<ytzpq8v5ny4.fsf@news.ole.ath.cx> <4FE217F9.9010907@stsci.edu>
Message-ID: <4FE21A94.8040809@stsci.edu>

On 06/20/2012 02:35 PM, Michael Droettboom wrote:
> On 06/19/2012 11:19 AM, Ol? Streicher wrote:
>> Hello,
>>
>> Erik Tollerud<erik.tollerud at gmail.com>  writes:
>>> On behalf of the Astropy team, I'm excited to announce the first
>>> release of the Astropy core package: v0.1!
>>
>> * Will pywcs survive as external package or shall we consider moving
>>     from pywcs to astropy.wcs in the medium term?
>>
> pywcs is still being maintained, at contains all of the bugfixes that go
> into astropy.wcs. It will probably be maintained (since we use it a lot
> internally) until astropy is a viable replacement for everything.
>
> My other contribution, io.vo is less likely to be maintained as a
> standalone package. It would benefit enormously from being moved to the
> new Table package in astropy, which would obviously introduce a major
> dependency on astropy, so that work may as well only happen within astropy.

The astropy.io.fits package will likely at some point move toward using 
astropy's Table class as well for representing FITS tables (actually 
probably a subclass of it with support for FITS-specific warts).

I haven't decided yet exactly how that work will be backported to 
pyfits--it might mean including a snippet of Astropy in pyfits.  We'll see.

Erik B.


From astropy at liska.ath.cx  Wed Jun 20 15:19:46 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 20 Jun 2012 21:19:46 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx> <4FE214C9.3030201@stsci.edu>
Message-ID: <ytza9zx6bal.fsf@news.ole.ath.cx>

Michael Droettboom <mdroe at stsci.edu> writes:
>>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>>> but I think his plan is to keep wcslib where it is, because the
>>> python-level wrapper is rather closely tied to the particular
>>> version of wcslib. 
>> I don't see this tight bound to a specific version. pywcs/astropy.wcs
>> uses the official API of wcslib, so it should work with every
>> version. And the shared library contains a SONAME that is going to be
>> changed if binary compability breaks.

> I don't see how this proves that case.? API stability has no
> reflection on correctness.? There are bugfixes to the error handling
> in 4.13 that allow the astropy.wcs unit tests to pass, that do not
> pass with previous versions.

I had rather good communication with the wcslib author in the past, so I
would always prefer a bugfixing there (and, obviously, Mark fixed the
bugs your mentioned). If you find new bugs, I (and probably other
packagers) would probably also happily include fixes into the packages
until upstream incorporates them.

> "extended_ctype.patch" makes wcslib compatible with FITS files that
> contain SIP information.? 

Could you explain this a bit more? It would be interesting for the
Debian version of wcslib as well.

> This patch will not be included upstream for political reasons.?
> Without this patch, astropy.wcs can not support SIP and is thus
> effectively broken.

As broken as wcslib itself (I dont't know who of you is right here).  I,
however, see no reason to provide on a system (like Debian, or Gentoo) a
broken wcslib for direct use and a patched version for python use -- so
if your patch is useful it should go to the wcslib author, and/or into
the distribution patches.

Could you explain a bit the advantages and drawbacks of your patch?

> I have been told by the upstream author that MS-Windows compatibility
> is not something he cares about.

This is also not python specific. Also, for distribution packaging
Windows patches are not interesting.

To summarize: pywcs works well with the original wcslib (especially the
latest, bugfixed versions), and it has the same limitations as the used
wcslib. If one wants to use SIP, he needs to use a patched wcslib,
regardless of the programming language (Python or C). Right?

Best regards

Ole


From perry at stsci.edu  Wed Jun 20 15:36:30 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 20 Jun 2012 15:36:30 -0400
Subject: [AstroPy] External packages in astropy
In-Reply-To: <ytza9zx6bal.fsf@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
Message-ID: <4074545A-39AD-4655-B45A-2ED9C64D2044@stsci.edu>


On Jun 20, 2012, at 3:19 PM, Ol? Streicher wrote:

> Michael Droettboom <mdroe at stsci.edu> writes:
>
>> I have been told by the upstream author that MS-Windows compatibility
>> is not something he cares about.
>
> This is also not python specific. Also, for distribution packaging
> Windows patches are not interesting.
>
Perhaps not for unix packaging, but for windows packaging, it sure is.  
Just because you don't care doesn't mean we shouldn't (and besides, we  
have to patch it anyway for SIP).

> To summarize: pywcs works well with the original wcslib (especially  
> the
> latest, bugfixed versions), and it has the same limitations as the  
> used
> wcslib. If one wants to use SIP, he needs to use a patched wcslib,
> regardless of the programming language (Python or C). Right?
>
Yes. But I'm not sure what your point is. There are many projects that  
use SIP so doing without it isn't feasible. Yes, we could release  
patched version under a different name, but we aren't in the business  
of making a "better" version of wcslib available, nor do we want to  
incur the possible political headaches of appearing to compete with  
the original.

Cheers, Perry




From astropy at liska.ath.cx  Wed Jun 20 17:17:51 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 20 Jun 2012 23:17:51 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
	<4074545A-39AD-4655-B45A-2ED9C64D2044@stsci.edu>
Message-ID: <87fw9pznr4.fsf@news.ole.ath.cx>

Perry Greenfield <perry at stsci.edu> writes:
> Yes. But I'm not sure what your point is. There are many projects that  
> use SIP so doing without it isn't feasible. Yes, we could release  
> patched version under a different name, but we aren't in the business  
> of making a "better" version of wcslib available, nor do we want to  
> incur the possible political headaches of appearing to compete with  
> the original.

I don't just see the python world separately, and I want to provide the
optimal experience on Debian for everyone :-) 

To give a current example: I just finished the (re-)packaging of the DS9
program which was a real nightmare because it included dozens of
external packages, some of them more than once, sometimes patched and so
on. Files from wcstools occurred 2-3 times, in different versions, one
of them with bugfixes, the other left without -- just because it was
used as sub-package of another package. This is not what I would call
good software quality, this is a complete mess. DS9 was thrown out of
almost all Linux distributions because of that.

Astropy will have the potential to build applications with a similar
complexity and lifetime as DS9. From the development experience with
DS9, it would probably at some point start to include astropy, some
older packages that are based on pywcs, and some C code that uses wcslib
(and, to complete that, probably also some code from wcstools). This is,
ofcourse, just a view into my private crystal ball :-)

So, the final version would incorporate three versions of wcslib, with
differences due to "political reasons" -- this sounds like a horror
scenario to me. I think, we should not start with this, but instead try
hard to get an agreement on a common philosophy here. In the moment, we
have the realistic chance to establish wcslib as the standard library
for that purpose, we should avoid any defragmentation here. 

For Debian, I don't want to make a difference between the plain wcslib
and pywcs: either SIP should be included into wcslib and is then in
pywcs and astropy (in the moment, it is not), or it is dangerous, and
then I see no reason to keep it for pywcs/astropy users.

The other distributions have a quite similar problem -- the
"wcslib-unbundle" patch I use comes in fact from Fedora Linux.

Best regards

Ole


From perry at stsci.edu  Wed Jun 20 19:40:54 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 20 Jun 2012 19:40:54 -0400
Subject: [AstroPy] External packages in astropy
In-Reply-To: <87fw9pznr4.fsf@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
	<4074545A-39AD-4655-B45A-2ED9C64D2044@stsci.edu>
	<87fw9pznr4.fsf@news.ole.ath.cx>
Message-ID: <C0D60D62-E191-4969-84B1-AE43BCD79FBE@stsci.edu>


On Jun 20, 2012, at 5:17 PM, Ol? Streicher wrote:

> Perry Greenfield <perry at stsci.edu> writes:
>> Yes. But I'm not sure what your point is. There are many projects  
>> that
>> use SIP so doing without it isn't feasible. Yes, we could release
>> patched version under a different name, but we aren't in the business
>> of making a "better" version of wcslib available, nor do we want to
>> incur the possible political headaches of appearing to compete with
>> the original.
>
> I don't just see the python world separately, and I want to provide  
> the
> optimal experience on Debian for everyone :-)
>
> To give a current example: I just finished the (re-)packaging of the  
> DS9
> program which was a real nightmare because it included dozens of
> external packages, some of them more than once, sometimes patched  
> and so
> on. Files from wcstools occurred 2-3 times, in different versions, one
> of them with bugfixes, the other left without -- just because it was
> used as sub-package of another package. This is not what I would call
> good software quality, this is a complete mess. DS9 was thrown out of
> almost all Linux distributions because of that.
>
> Astropy will have the potential to build applications with a similar
> complexity and lifetime as DS9. From the development experience with
> DS9, it would probably at some point start to include astropy, some
> older packages that are based on pywcs, and some C code that uses  
> wcslib
> (and, to complete that, probably also some code from wcstools). This  
> is,
> ofcourse, just a view into my private crystal ball :-)
>
> So, the final version would incorporate three versions of wcslib, with
> differences due to "political reasons" -- this sounds like a horror
> scenario to me. I think, we should not start with this, but instead  
> try
> hard to get an agreement on a common philosophy here. In the moment,  
> we
> have the realistic chance to establish wcslib as the standard library
> for that purpose, we should avoid any defragmentation here.
>
> For Debian, I don't want to make a difference between the plain wcslib
> and pywcs: either SIP should be included into wcslib and is then in
> pywcs and astropy (in the moment, it is not), or it is dangerous, and
> then I see no reason to keep it for pywcs/astropy users.
>
> The other distributions have a quite similar problem -- the
> "wcslib-unbundle" patch I use comes in fact from Fedora Linux.
>
> Best regards
>
> Ole

I understand and sympathize with these difficulties. It certainly  
would be much better to have just one wcslib to deal with. How to  
achieve that is the difficult issue that has to be dealt with. But it  
isn't clear if you are suggesting that we stop using SIP. If it is,  
that isn't going to happen. That's not our decision to make (we don't  
make all the decisions about data formats as much as we would like  
to). You could get the author to incorporate SIP. That would be a big  
help. And it probably would be better coming from a different front  
with new arguments (make the case yourself directly and encourage  
others to do so--we already have). And since the author has invested a  
lot in this package, and is maintaining it (at least at some level),  
it doesn't make sense for us to try to take it over (as bad a name as  
"politics" has, it pervades all human activity, open source projects).  
If someone else would like to try to do that, all power to them, but  
it isn't going to be us. So I don't discourage efforts to achieve  
unification, but there isn't much more we can do on our front.  
Eventually this should sort itself out, but it may take a little time.

Cheers, Perry



From mdroe at stsci.edu  Wed Jun 20 21:01:25 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 20 Jun 2012 21:01:25 -0400
Subject: [AstroPy] External packages in astropy
In-Reply-To: <ytza9zx6bal.fsf@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
Message-ID: <4FE27265.7070903@stsci.edu>

On 06/20/2012 03:19 PM, Ol? Streicher wrote:
> Michael Droettboom <mdroe at stsci.edu> writes:
>>>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>>>> but I think his plan is to keep wcslib where it is, because the
>>>> python-level wrapper is rather closely tied to the particular
>>>> version of wcslib.
>>> I don't see this tight bound to a specific version. pywcs/astropy.wcs
>>> uses the official API of wcslib, so it should work with every
>>> version. And the shared library contains a SONAME that is going to be
>>> changed if binary compability breaks.
>> I don't see how this proves that case.  API stability has no
>> reflection on correctness.  There are bugfixes to the error handling
>> in 4.13 that allow the astropy.wcs unit tests to pass, that do not
>> pass with previous versions.
> I had rather good communication with the wcslib author in the past, so I
> would always prefer a bugfixing there (and, obviously, Mark fixed the
> bugs your mentioned). If you find new bugs, I (and probably other
> packagers) would probably also happily include fixes into the packages
> until upstream incorporates them.
>
>> "extended_ctype.patch" makes wcslib compatible with FITS files that
>> contain SIP information.
> Could you explain this a bit more? It would be interesting for the
> Debian version of wcslib as well.

The SIP convention extends the CTYPE keywords so they have a "SIP" 
suffix, for example "RA---TAN-SIP".  wcslib by default rejects this as 
being an invalid CTYPE.  astropy.wcs/pywcs includes SIP support, so we 
don't want to raise an exception.

This could be handled outside of wcslib by changing these values before 
passing them in, which would give us compatibility with vanilla wcslib 
-- that might be a reasonable solution.

>
>> This patch will not be included upstream for political reasons.
>> Without this patch, astropy.wcs can not support SIP and is thus
>> effectively broken.
> As broken as wcslib itself (I dont't know who of you is right here).

What I meant to apply is that pywcs would be broken because it could not 
read SIP any longer, which is one of its important reasons for being.

>    
>> I have been told by the upstream author that MS-Windows compatibility
>> is not something he cares about.
> This is also not python specific. Also, for distribution packaging
> Windows patches are not interesting.
>
> To summarize: pywcs works well with the original wcslib (especially the
> latest, bugfixed versions),

I would say "only the latest, bugfixed versions".  If astropy.wcs links 
to the system wcslib prior to 4.13, all of the *fix functions, I 
wouldn't say that's "works well".

>   and it has the same limitations as the used
> wcslib. If one wants to use SIP, he needs to use a patched wcslib,
> regardless of the programming language (Python or C). Right?

That's correct.

Mike




From d.berry at jach.hawaii.edu  Thu Jun 21 03:18:17 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 21 Jun 2012 08:18:17 +0100
Subject: [AstroPy] External packages in astropy
In-Reply-To: <4FE27265.7070903@stsci.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx> <4FE214C9.3030201@stsci.edu>
	<ytza9zx6bal.fsf@news.ole.ath.cx> <4FE27265.7070903@stsci.edu>
Message-ID: <CAALafn7EVsBPDfWZv3P4wBAsQYMYabFoBe1RZXLEODNSvtpkuA@mail.gmail.com>

The reason SIP is not supported by Mark Calabretta's wcslib is that it
is a one-off solution by a particular group to solve a problem that
the FITS-WCS series of papers is already planning to address in a
different way.  The wcslib library is the reference library for the
FITS-WCS standard and as such does not (and almost certainly never
will) handle any of the many many ad-hoc extensions to FITS-WCS that
were created both before and after the publication of the FITS-WCS
papers.

Why is SIP being singled out? What about ZPX/TNX, and the newly
labelled TPV ? These are all different attempts to solve the same
problem of polynomial distortions to basic projections, and they are
all in wide spread use. And there are many other commonly used
FITS-WCS conventions that are not handled by wcslib, because wcslib is
the reference implementation of standard FITS-WCS.

Astropy needs to solve this issue. Relying on wcslib alone will result
in there being loads of FITS file with WCS that cannot be read. This
is the reason that DS9 has switched recently from using
wcslib+wcstools to handle WCS to using the AST library. AST (and
therefore pyast) has a more pragmatic approach to handling common
FITS-WCS conventions and includes support for SIP, TNX, ZPZ, TPV.

David

On 21 June 2012 02:01, Michael Droettboom <mdroe at stsci.edu> wrote:
> On 06/20/2012 03:19 PM, Ol? Streicher wrote:
>> Michael Droettboom <mdroe at stsci.edu> writes:
>>>>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>>>>> but I think his plan is to keep wcslib where it is, because the
>>>>> python-level wrapper is rather closely tied to the particular
>>>>> version of wcslib.
>>>> I don't see this tight bound to a specific version. pywcs/astropy.wcs
>>>> uses the official API of wcslib, so it should work with every
>>>> version. And the shared library contains a SONAME that is going to be
>>>> changed if binary compability breaks.
>>> I don't see how this proves that case. ?API stability has no
>>> reflection on correctness. ?There are bugfixes to the error handling
>>> in 4.13 that allow the astropy.wcs unit tests to pass, that do not
>>> pass with previous versions.
>> I had rather good communication with the wcslib author in the past, so I
>> would always prefer a bugfixing there (and, obviously, Mark fixed the
>> bugs your mentioned). If you find new bugs, I (and probably other
>> packagers) would probably also happily include fixes into the packages
>> until upstream incorporates them.
>>
>>> "extended_ctype.patch" makes wcslib compatible with FITS files that
>>> contain SIP information.
>> Could you explain this a bit more? It would be interesting for the
>> Debian version of wcslib as well.
>
> The SIP convention extends the CTYPE keywords so they have a "SIP"
> suffix, for example "RA---TAN-SIP". ?wcslib by default rejects this as
> being an invalid CTYPE. ?astropy.wcs/pywcs includes SIP support, so we
> don't want to raise an exception.
>
> This could be handled outside of wcslib by changing these values before
> passing them in, which would give us compatibility with vanilla wcslib
> -- that might be a reasonable solution.
>
>>
>>> This patch will not be included upstream for political reasons.
>>> Without this patch, astropy.wcs can not support SIP and is thus
>>> effectively broken.
>> As broken as wcslib itself (I dont't know who of you is right here).
>
> What I meant to apply is that pywcs would be broken because it could not
> read SIP any longer, which is one of its important reasons for being.
>
>>
>>> I have been told by the upstream author that MS-Windows compatibility
>>> is not something he cares about.
>> This is also not python specific. Also, for distribution packaging
>> Windows patches are not interesting.
>>
>> To summarize: pywcs works well with the original wcslib (especially the
>> latest, bugfixed versions),
>
> I would say "only the latest, bugfixed versions". ?If astropy.wcs links
> to the system wcslib prior to 4.13, all of the *fix functions, I
> wouldn't say that's "works well".
>
>> ? and it has the same limitations as the used
>> wcslib. If one wants to use SIP, he needs to use a patched wcslib,
>> regardless of the programming language (Python or C). Right?
>
> That's correct.
>
> Mike
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From thomas.robitaille at gmail.com  Thu Jun 21 03:24:54 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 21 Jun 2012 10:24:54 +0300
Subject: [AstroPy] External packages in astropy
In-Reply-To: <4FE27265.7070903@stsci.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx> <4FE214C9.3030201@stsci.edu>
	<ytza9zx6bal.fsf@news.ole.ath.cx> <4FE27265.7070903@stsci.edu>
Message-ID: <CAGMHX_2gA+F0T1B4o3GkSVZfWvkyWzV7Bo8Qp4K4D874OSXP1A@mail.gmail.com>

> The SIP convention extends the CTYPE keywords so they have a "SIP"
> suffix, for example "RA---TAN-SIP". ?wcslib by default rejects this as
> being an invalid CTYPE. ?astropy.wcs/pywcs includes SIP support, so we
> don't want to raise an exception.
>
> This could be handled outside of wcslib by changing these values before
> passing them in, which would give us compatibility with vanilla wcslib
> -- that might be a reasonable solution.

I agree that if we could make it so that we ensure that we can use the
vanilla WCS and dealing with and stripping out the SIP stuff before
passing the header to wcslib, this would be a good solution that would
make most people happy. Then wcslib could be moved to cextern, and
disabled in package managers than include wcslib (with the caveat that
only recent versions of wcslib would be supported due to recent bug
fixes). Maybe Astropy could check the version of wcslib being used and
raise an error if it is too old?

Cheers,
Tom


From astropy at liska.ath.cx  Thu Jun 21 04:06:39 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Thu, 21 Jun 2012 10:06:39 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
	<4FE27265.7070903@stsci.edu>
	<CAALafn7EVsBPDfWZv3P4wBAsQYMYabFoBe1RZXLEODNSvtpkuA@mail.gmail.com>
Message-ID: <ytz1ul95bsg.fsf@news.ole.ath.cx>

David Berry <d.berry at jach.hawaii.edu> writes:
> Why is SIP being singled out? What about ZPX/TNX, and the newly
> labelled TPV ? These are all different attempts to solve the same
> problem of polynomial distortions to basic projections, and they are
> all in wide spread use. And there are many other commonly used
> FITS-WCS conventions that are not handled by wcslib, because wcslib is
> the reference implementation of standard FITS-WCS.

I see no contradiction here. One rule of thumb is "be lazy in your input
and be lazy in your output" -- so a wcslib implementation that would
handle SIP and other extensions could still be a reference
implementation. As a compromise, one could use an option "STRICT_WCS" to
build or use a lintian like wcslib. IMO the practical use of this is
quite limited anyway.

I would see just the problem of maintenance these extensions. Just
curious: Are there any patches ready for wcslib to correctly handle
them? 

However, this all should be discussed with Mark Calabretta...

BTW, why are there so many extensions that all seem to handle the same
problem? 

> Astropy needs to solve this issue. Relying on wcslib alone will result
> in there being loads of FITS file with WCS that cannot be read. This
> is the reason that DS9 has switched recently from using
> wcslib+wcstools to handle WCS to using the AST library. AST (and
> therefore pyast) has a more pragmatic approach to handling common
> FITS-WCS conventions and includes support for SIP, TNX, ZPZ, TPV.

.... with the danger to make the current segmentation and confusion
permanent.

AST uses its own, private, incarnation of wcstools files which have some
extensions that are not in wcstools yet. DS9 however includes another
copy of wcstools (resp. wcssubs), which does not have these
extensions. This sounds really fragile to me. Additionally, if someone
finds a bug in wcstools: how does the fix go through to ds9 finally? I
am afraid that it *will* be lost in one of its many ways to the ds9
binary. 

Best regards

Ole


From astropy at liska.ath.cx  Thu Jun 21 04:17:45 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Thu, 21 Jun 2012 10:17:45 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
	<4FE27265.7070903@stsci.edu>
	<CAGMHX_2gA+F0T1B4o3GkSVZfWvkyWzV7Bo8Qp4K4D874OSXP1A@mail.gmail.com>
Message-ID: <ytzwr313wpi.fsf@news.ole.ath.cx>

Thomas Robitaille <thomas.robitaille at gmail.com> writes:
>> This could be handled outside of wcslib by changing these values before
>> passing them in, which would give us compatibility with vanilla wcslib
>> -- that might be a reasonable solution.

> I agree that if we could make it so that we ensure that we can use the
> vanilla WCS and dealing with and stripping out the SIP stuff before
> passing the header to wcslib, this would be a good solution that would
> make most people happy. 

I would be happy with this solution in the moment (... until we get a
wcslib that fits to more situations natively).

> Then wcslib could be moved to cextern, and disabled in package
> managers than include wcslib (with the caveat that only recent
> versions of wcslib would be supported due to recent bug fixes). Maybe
> Astropy could check the version of wcslib being used and raise an
> error if it is too old?

Hmm. I think that the problem mainly occurres when using packaged
versions of pywcs or astropy. This means that usually the packages get
updated automatically, so the newest version would be used. And, the
packager can specify a required version when the package is being built
or run. So, I would not see a problem here. I would also tend to include
a bugfix patch into a current version of wcslib until it gets fixed
upstream. Having a version check would kill this attempt.

wcslib also does not provide runtime version information; so version
checking at runtime would not work anyway.

Best regards

Ole


From d.berry at jach.hawaii.edu  Thu Jun 21 05:09:45 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 21 Jun 2012 10:09:45 +0100
Subject: [AstroPy] External packages in astropy
In-Reply-To: <ytz1ul95bsg.fsf@news.ole.ath.cx>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx> <4FE214C9.3030201@stsci.edu>
	<ytza9zx6bal.fsf@news.ole.ath.cx> <4FE27265.7070903@stsci.edu>
	<CAALafn7EVsBPDfWZv3P4wBAsQYMYabFoBe1RZXLEODNSvtpkuA@mail.gmail.com>
	<ytz1ul95bsg.fsf@news.ole.ath.cx>
Message-ID: <CAALafn4HKCqB9tRtTXxW5ZTTAUhKnUjr4L66PDjeWA6U8VKo=w@mail.gmail.com>

On 21 June 2012 09:06, Ol? Streicher <astropy at liska.ath.cx> wrote:
> David Berry <d.berry at jach.hawaii.edu> writes:
>> Why is SIP being singled out? What about ZPX/TNX, and the newly
>> labelled TPV ? These are all different attempts to solve the same
>> problem of polynomial distortions to basic projections, and they are
>> all in wide spread use. And there are many other commonly used
>> FITS-WCS conventions that are not handled by wcslib, because wcslib is
>> the reference implementation of standard FITS-WCS.
>
> I see no contradiction here. One rule of thumb is "be lazy in your input
> and be lazy in your output" -- so a wcslib implementation that would
> handle SIP and other extensions could still be a reference
> implementation. As a compromise, one could use an option "STRICT_WCS" to
> build or use a lintian like wcslib. IMO the practical use of this is
> quite limited anyway.
>
> I would see just the problem of maintenance these extensions. Just
> curious: Are there any patches ready for wcslib to correctly handle
> them?

Not that I know of.

> However, this all should be discussed with Mark Calabretta...

Agreed.

> BTW, why are there so many extensions that all seem to handle the same
> problem?

Good question. I suppose everyone thought the pre-existing extensions
were not appropriate for their own data and so invented a new one. I
*think* they developed in the order TNX/ZPX (from IRAF), TPV
(contained in an early draft of FITS-WCS paper 2 but removed before
publication), and then SIP. We are still awaiting FITS-WCS paper 4
which is supposed to set the standard for distortions. SIP is more in
line with the draft of paper 4 since it can be applied to any
projection, whereas TNX and TPV can only be applied to TAN
projections.

>> Astropy needs to solve this issue. Relying on wcslib alone will result
>> in there being loads of FITS file with WCS that cannot be read. This
>> is the reason that DS9 has switched recently from using
>> wcslib+wcstools to handle WCS to using the AST library. AST (and
>> therefore pyast) has a more pragmatic approach to handling common
>> FITS-WCS conventions and includes support for SIP, TNX, ZPZ, TPV.
>
> .... with the danger to make the current segmentation and confusion
> permanent.

Not really. Whilst AST will read most common FITS-WCS variants, it is
much more strict in what it writes. Most variants are transformed into
the corresponding  standard construct, where such standards exist.
You said wcslib could "be lazy in your input and be lazy in your
output" - AST is lazy in input but strict in output.

> AST uses its own, private, incarnation of wcstools files which have some
> extensions that are not in wcstools yet.

False. AST does not have anything from wcstools in it. In it's early
days (10 years ago), it incorporated a couple of smallish files from
wcslib which have since been modified extensively and very differently
 in both wcslib and AST, so that they are now completely independent
of each other (except for the required copyright recognition). The
only external libraries that AST depends on are SOFA, and the Starlink
PAL library (a utility layer on top of SOFA), both of which come
bundled with AST in pristine unmodified form and so can be replaced
easily.

> DS9 however includes another
> copy of wcstools (resp. wcssubs), which does not have these
> extensions. This sounds really fragile to me. Additionally, if someone
> finds a bug in wcstools: how does the fix go through to ds9 finally? I
> am afraid that it *will* be lost in one of its many ways to the ds9
> binary.

You know more about the internals of DS9 than I do.  AST however is
now in a pretty clean state I think (largely as a result of your
promptings).

David


From astropy at liska.ath.cx  Thu Jun 21 05:24:02 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Thu, 21 Jun 2012 11:24:02 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <ytza9zx6bal.fsf@news.ole.ath.cx>
	<4FE27265.7070903@stsci.edu>
	<CAALafn7EVsBPDfWZv3P4wBAsQYMYabFoBe1RZXLEODNSvtpkuA@mail.gmail.com>
	<ytz1ul95bsg.fsf@news.ole.ath.cx>
	<CAALafn4HKCqB9tRtTXxW5ZTTAUhKnUjr4L66PDjeWA6U8VKo=w@mail.gmail.com>
Message-ID: <ytzsjdp3tn1.fsf@news.ole.ath.cx>

Hi David,

David Berry <d.berry at jach.hawaii.edu> writes:
>> AST uses its own, private, incarnation of wcstools files which have some
>> extensions that are not in wcstools yet.

> False. AST does not have anything from wcstools in it. In it's early
> days (10 years ago), it incorporated a couple of smallish files from
> wcslib which have since been modified extensively and very differently
>  in both wcslib and AST, so that they are now completely independent
> of each other (except for the required copyright recognition). The
> only external libraries that AST depends on are SOFA, and the Starlink
> PAL library (a utility layer on top of SOFA), both of which come
> bundled with AST in pristine unmodified form and so can be replaced
> easily.

Sorry, that was my fault. I was just confused in this moment by the
different versions of AST that were used in DS9. AST looks quite nice
from my perspective.

Best regards

Ole


From vs at obs.carnegiescience.edu  Fri Jun 22 16:03:30 2012
From: vs at obs.carnegiescience.edu (Vicky Scowcroft)
Date: Fri, 22 Jun 2012 13:03:30 -0700
Subject: [AstroPy] package requirements for pyregion
Message-ID: <4FE4CF92.5020709@obs.carnegiescience.edu>

Hi,
I'm following the setup instructions at
http://python4astronomers.github.com/installation/python_install.html

Under "MacOS or root linux install" you have:

sudo pip install --upgrade pyregion


This doesn't work without the pyrex package,
so

sudo pip install --upgrade pyrex

should be added before.

Thanks
Vicky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120622/656b33f3/attachment.html>

From aldcroft at head.cfa.harvard.edu  Sat Jun 23 20:00:43 2012
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Sat, 23 Jun 2012 20:00:43 -0400
Subject: [AstroPy] package requirements for pyregion
In-Reply-To: <4FE4CF92.5020709@obs.carnegiescience.edu>
References: <4FE4CF92.5020709@obs.carnegiescience.edu>
Message-ID: <CAGsQ-NuJoaZnMW50m+_ais+xX5zwhczeN6p6J8mi8ZJ3f==XRg@mail.gmail.com>

On Fri, Jun 22, 2012 at 4:03 PM, Vicky Scowcroft
<vs at obs.carnegiescience.edu> wrote:
> Hi,
> I'm following the setup instructions at
> http://python4astronomers.github.com/installation/python_install.html
>
> Under "MacOS or root linux install" you have:
>
> sudo pip install --upgrade pyregion
>
>
> This doesn't work without the pyrex package,
> so
>
> sudo pip install --upgrade pyrex
>
> should be added before.
>
> Thanks
> Vicky
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>

Hi Vicky,

Thanks for the feedback.  This was already reported and being tracked
[1], but we'll get on it.  As mentioned in the issue, the dependency
can be met with Cython and that is probably a better option at this
point.   Also, it looks like pyregion is supposed to build without
Pyrex or Cython [2], but this doesn't seem to work and may be a
pyregion issue.

- Tom

[1] https://github.com/python4astronomers/python4astronomers/issues/6
[2] https://github.com/leejjoon/pyregion/commit/ff785c85464d4ef912931037beca8c47c7674e53


From lee.j.joon at gmail.com  Sun Jun 24 12:10:03 2012
From: lee.j.joon at gmail.com (Jae-Joon Lee)
Date: Sun, 24 Jun 2012 06:10:03 -1000
Subject: [AstroPy] package requirements for pyregion
In-Reply-To: <CAGsQ-NuJoaZnMW50m+_ais+xX5zwhczeN6p6J8mi8ZJ3f==XRg@mail.gmail.com>
References: <4FE4CF92.5020709@obs.carnegiescience.edu>
	<CAGsQ-NuJoaZnMW50m+_ais+xX5zwhczeN6p6J8mi8ZJ3f==XRg@mail.gmail.com>
Message-ID: <CAG=uJ+nejit0=LketjEf+V5OC9HUV=JU8_JHD1aa_0GCCmWbDg@mail.gmail.com>

This is a known issue.

 https://github.com/leejjoon/pyregion/issues/10

And as far as I can see this is a bug in setuptools, which seems to be
fixed recently.

 https://bitbucket.org/tarek/distribute/issue/195/cython-build_ext-support-broken-when-using

A workaround has been implemented in the dev. branch of pyregion.

 https://github.com/leejjoon/pyregion/commit/ff785c85464d4ef912931037beca8c47c7674e53

And yes, pyregion should build okay if you don't have Pyrex or Cython.
The problem only happens when you have Cython but not pyrex.

Regards,

-JJ


On Sat, Jun 23, 2012 at 2:00 PM, Tom Aldcroft
<aldcroft at head.cfa.harvard.edu> wrote:
> On Fri, Jun 22, 2012 at 4:03 PM, Vicky Scowcroft
> <vs at obs.carnegiescience.edu> wrote:
>> Hi,
>> I'm following the setup instructions at
>> http://python4astronomers.github.com/installation/python_install.html
>>
>> Under "MacOS or root linux install" you have:
>>
>> sudo pip install --upgrade pyregion
>>
>>
>> This doesn't work without the pyrex package,
>> so
>>
>> sudo pip install --upgrade pyrex
>>
>> should be added before.
>>
>> Thanks
>> Vicky
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>
> Hi Vicky,
>
> Thanks for the feedback. ?This was already reported and being tracked
> [1], but we'll get on it. ?As mentioned in the issue, the dependency
> can be met with Cython and that is probably a better option at this
> point. ? Also, it looks like pyregion is supposed to build without
> Pyrex or Cython [2], but this doesn't seem to work and may be a
> pyregion issue.
>
> - Tom
>
> [1] https://github.com/python4astronomers/python4astronomers/issues/6
> [2] https://github.com/leejjoon/pyregion/commit/ff785c85464d4ef912931037beca8c47c7674e53
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From mdroe at stsci.edu  Tue Jun 26 10:12:05 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Tue, 26 Jun 2012 10:12:05 -0400
Subject: [AstroPy] External packages in astropy
In-Reply-To: <4FE214C9.3030201@stsci.edu>
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx> <4FE214C9.3030201@stsci.edu>
Message-ID: <4FE9C335.1040804@stsci.edu>

In a private communication with Mark Calabretta and Ole Streicher, I 
have learned that these patches will be included upstream.  I 
misunderstood the source of the earlier objections -- the SIP 
compatibility patch is considered reasonable for upstream and will allow 
wcslib to accept SIP without actually supporting itself (which is a 
reasonable thing to do).

Mike

On 06/20/2012 02:22 PM, Michael Droettboom wrote:
> On 06/20/2012 03:37 AM, Ol? Streicher wrote:
>> Erik Tollerud<erik.tollerud at gmail.com>  writes:
>>> On Tue, Jun 19, 2012 at 11:19 AM, Ol? Streicher<astropy at liska.ath.cx>  wrote:
>>>> * I very much like the idea of having the external C code in a specific
>>>>   diretory tree "cextern" since this makes it easier to split this part
>>>>   and use the versions provided with the OS. I would guess that also
>>>>   the "wcslib" part will move from pywcs to cextern?
>>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>>> but I think his plan is to keep wcslib where it is, because the
>>> python-level wrapper is rather closely tied to the particular version
>>> of wcslib.
>> I don't see this tight bound to a specific version. pywcs/astropy.wcs
>> uses the official API of wcslib, so it should work with every
>> version. And the shared library contains a SONAME that is going to be
>> changed if binary compability breaks.
>>
>> Source and binary compability can be checked with the upstream tracker
>>
>> http://linuxtesting.org/upstream-tracker/versions/wcslib.html
>>
>> (which is down in the moment I write this), and this shows that the last
>> versions (from 4.8, if I remember correctly) are all compatible.
>
> I don't see how this proves that case.  API stability has no 
> reflection on correctness.  There are bugfixes to the error handling 
> in 4.13 that allow the astropy.wcs unit tests to pass, that do not 
> pass with previous versions.
>
>>> The idea is that cextern is for C code that is essentially included
>>> "wholly" (like extern), and things that are tightly coupled to the
>>> python code (including Cython .pyx files) will live in the python
>>> source tree.  There's more about this is in the README file in the
>>> cextern directory.
>> When astropy is packaged for a distribution (probably others than Debian
>> and Ubuntu as well), there is a need to replace convienience copies of
>> third-party code by references to the according packages. Making this
>> easier is IMO one of the uses of cextern. I would even suggest to rename
>> it to "thirdparty" of similar, since this is probably not limited to C
>> code.
>>
>> At least, it would be nice to have build-time configuration options to
>> use external packages instead of the distributed ones (adjustable since
>> the external packages may vary between the Linux distributions).
>>
>> I would also suggest a rule that external packages should be used
>> unchanged in the astropy tree (if changes are needed, they should be
>> discussed/included with the original authors).
>>
> You can see our patches to wcslib here:
>
> https://github.com/astropy/astropy/tree/master/astropy/wcs/patches
>
> "compiler_warnings.patch" is not strictly necessary, but nice to have.
>
> "extended_ctype.patch" makes wcslib compatible with FITS files that 
> contain SIP information.  This patch will not be included upstream for 
> political reasons.  Without this patch, astropy.wcs can not support 
> SIP and is thus effectively broken.
>
> I have been told by the upstream author that MS-Windows compatibility 
> is not something he cares about.
>
> Mike
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


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

From astropy at liska.ath.cx  Tue Jun 26 17:52:13 2012
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Tue, 26 Jun 2012 23:52:13 +0200
Subject: [AstroPy] External packages in astropy
References: <11CFBE98-70C4-4EAA-AB93-B00E2DCEB7AB@gmail.com>
	<wl8a9zz18ll.fsf@physics.ucf.edu>
	<CAARXUwWpYeAKCnYqKUtQhCVjWC_2exkFhjCLfWZ9NFGHz11xDg@mail.gmail.com>
	<ytzliji5t7w.fsf_-_@news.ole.ath.cx>
	<4FE214C9.3030201@stsci.edu> <4FE9C335.1040804@stsci.edu>
Message-ID: <87a9zpzqpe.fsf@news.ole.ath.cx>

Michael Droettboom <mdroe at stsci.edu> writes:
> [...] the SIP compatibility patch is considered reasonable for
> upstream and will allow wcslib to accept SIP without actually
> supporting itself (which is a reasonable thing to do).

I would like to come back to my original proposal to move all external
sources to cextern (possibly renaming it to thirdparty, since it may
cover not just C code), and to have a policy that they should remain
untouched -- at least, any change there should be done only if there is
really a good reason, and that

* the original author refuses to incorporate the changes, and

* it cannot be circumvented in the Python code (or at least would have a
  huge drawback)

In this case, these changes should be well-documented, so that a
packager can discuss them with the corresponding maintainer of the
package. Target should always be to use libraries that are already
packaged whereever possible.

Does this sound reasonable?

Best regards

Ole


From rose.a.finn at gmail.com  Tue Jun 26 20:05:33 2012
From: rose.a.finn at gmail.com (Rose Finn)
Date: Tue, 26 Jun 2012 20:05:33 -0400
Subject: [AstroPy] getting the location of a subplot
Message-ID: <CAL9NRkRg7+U5AbigSfTDPPNYMzhaF9mKPrqcuzS8anNSENc4cg@mail.gmail.com>

Hi,

I am trying to use aplpy.FITSFigure() within pylab.subplots.
FITSFigure wants the [xmin,ymin,dx,dy], and I am wondering if there is
an easy to find out the top, bottom, left, and right of the subplot.

For example:

fig=figure()
fig.subplotpars.top

gives the top of the plot.

If instead I do

fig=figure()
 sub=subplot(3,3,1)


-- 
Rose A. Finn, PhD
Department of Physics & Astronomy
Siena College
Loudonville, NY
(518) 782-6764


From rose.a.finn at gmail.com  Tue Jun 26 20:08:25 2012
From: rose.a.finn at gmail.com (Rose Finn)
Date: Tue, 26 Jun 2012 20:08:25 -0400
Subject: [AstroPy] getting the location of a subplot
Message-ID: <CAL9NRkQjgMJ0MnNkSsvxLvQz=cuUHCEVuGFvk58WM3svfoK26g@mail.gmail.com>

Hi,

Sorry - I accidentally sent my first message before it was finished!

I am trying to use aplpy.FITSFigure() within pylab.subplots.
FITSFigure wants the [xmin,ymin,dx,dy], and I am wondering if there is
an easy to find out the top, bottom, left, and right of the subplot.

For example:

fig=figure()
fig.subplotpars.top

gives the top of the plot.

If instead I do

fig=figure()
sub=subplot(3,3,1)

Is there a similarly easy way to get the top, bottom, etc of the
current subplot?

Thanks,
Rose

-- 
Rose A. Finn, PhD
Department of Physics & Astronomy
Siena College
Loudonville, NY
(518) 782-6764


From vivienne.baldassare at gmail.com  Wed Jun 27 16:10:02 2012
From: vivienne.baldassare at gmail.com (Vivienne Baldassare)
Date: Wed, 27 Jun 2012 16:10:02 -0400
Subject: [AstroPy] Gaussian with constant background
Message-ID: <CAM7VxLHkUJGOjBa1NGUx0Ni3xPjyGr7Df+XhBM69kEi9Eq6xgA@mail.gmail.com>

Hello,

I've been trying to figure out how to fit a gaussian with a constant
(non-zero) background.  Aside from just subtracting off the background, I
haven't been able to do it, and googling around was not particularly
helpful.  I'd appreciate any tips!

Best,
Vivienne Baldassare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120627/62069ab5/attachment.html>

From taro at ap.smu.ca  Wed Jun 27 16:15:11 2012
From: taro at ap.smu.ca (Taro Sato)
Date: Wed, 27 Jun 2012 13:15:11 -0700
Subject: [AstroPy] Gaussian with constant background
In-Reply-To: <CAM7VxLHkUJGOjBa1NGUx0Ni3xPjyGr7Df+XhBM69kEi9Eq6xgA@mail.gmail.com>
References: <CAM7VxLHkUJGOjBa1NGUx0Ni3xPjyGr7Df+XhBM69kEi9Eq6xgA@mail.gmail.com>
Message-ID: <CA+ABecyd89fRH+bcrRGFNU1domPsMvpRWNEMONgMsUTbUsHzXQ@mail.gmail.com>

On Wed, Jun 27, 2012 at 1:10 PM, Vivienne Baldassare
<vivienne.baldassare at gmail.com> wrote:
> Hello,
>
> I've been trying to figure out how to fit a gaussian with a constant
> (non-zero) background. ?Aside from just subtracting off the background, I
> haven't been able to do it, and googling around was not particularly
> helpful. ?I'd appreciate any tips!



Why don't you learn how to use some generic non-linear fitting routine
like scipy.optimize.leastsq?  Once you learn how to do this, you can
basically fit any analytical function you like.  A few good examples
in the following page:

http://www.scipy.org/Cookbook/FittingData



-- 
Taro Sato
Department of Astronomy & Physics
Saint Mary's University? ? ? ? ? ?? email: taro at ap.smu.ca
Halifax, NS B3H 3C3? ? ? ? ? ? ? ?? phone: (902)420-5018
Canada? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? web: http://ap.smu.ca/~taro


From ianc at ucla.edu  Wed Jun 27 17:36:31 2012
From: ianc at ucla.edu (Ian Crossfield)
Date: Wed, 27 Jun 2012 14:36:31 -0700
Subject: [AstroPy] Gaussian with constant background
In-Reply-To: <CA+ABecyd89fRH+bcrRGFNU1domPsMvpRWNEMONgMsUTbUsHzXQ@mail.gmail.com>
References: <CAM7VxLHkUJGOjBa1NGUx0Ni3xPjyGr7Df+XhBM69kEi9Eq6xgA@mail.gmail.com>
	<CA+ABecyd89fRH+bcrRGFNU1domPsMvpRWNEMONgMsUTbUsHzXQ@mail.gmail.com>
Message-ID: <4FEB7CDF.3000009@ucla.edu>

I have also had good results with the Kapteyn package, which has an 
updated implementation of MPFIT.
http://www.astro.rug.nl/software/kapteyn/kmpfit.html

-Ian

On 6/27/12 1:15 PM, Taro Sato wrote:
> On Wed, Jun 27, 2012 at 1:10 PM, Vivienne Baldassare
> <vivienne.baldassare at gmail.com>  wrote:
>> Hello,
>>
>> I've been trying to figure out how to fit a gaussian with a constant
>> (non-zero) background.  Aside from just subtracting off the background, I
>> haven't been able to do it, and googling around was not particularly
>> helpful.  I'd appreciate any tips!
>
>
> Why don't you learn how to use some generic non-linear fitting routine
> like scipy.optimize.leastsq?  Once you learn how to do this, you can
> basically fit any analytical function you like.  A few good examples
> in the following page:
>
> http://www.scipy.org/Cookbook/FittingData
>
>
>

-- 
Ian Crossfield
UCLA Astronomy and
Max-Planck Instit?t f?r Astronomie
http://www.astro.ucla.edu/~ianc/



From ghang.naoc at gmail.com  Wed Jun 27 23:14:46 2012
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Thu, 28 Jun 2012 11:14:46 +0800
Subject: [AstroPy] python crawler for hst,dss image
Message-ID: <CABb23ms-A8Lzx6C57z1D-7yJEaemEW+jzGV=e8EHr134BYrvhw@mail.gmail.com>

Hi,is there any python crawler which can download hst,dss(the more
telescope,the better) image automatically?
s9 could download dss image automatically if you know ra&dec or object
name,but can not handle hst image.
Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120628/55cc465e/attachment.html>