[AstroPy] Co-ordinating Python astronomy libraries?

Wed Jul 14 11:02:52 EDT 2010

  Hello,

So finally I also managed to put some of my libraries online at 
http://www.mso.anu.edu.au/~wkerzend/astropy. I have followed the 
discussion over the last few days and I think its great. Of course here 
my 2 cents ;-):

I have read this once or twice already: I think there's a need for 
common base classes so that we can use these new python libraries 
together. This is very important especially now that this python 
astronomy library starts to take shape.

Time and coordinate base classes were mentioned. I think pyephem might 
be the way to go here as Rhodesmill has already implemented quite a bit 
of both. The next thing is a 2D image class and I read from James's 
email that there's AstroData in preparation at Gemini . Is there any 
release ETA on AstroData?

With pyspec I have a prototype for a 1D spectrum and echelle class. It 
can easily read spectra in a column seperated format: 
data=spectrum('myspec.dat'). You can easily slice spectra: 
data2=data[4000.:4050.] (if you give it a float for slicing it will use 
the wavelength instead of the array index). You can do arithmetic with 
spectra and it does a simple linear interpolate on the second spectrum 
to match the wavelength grid of the first: data3=data1/data2.

I hope that we can get some base classes fairly soon, so that the 
development of new tools already includes them.

Distribution wise I think there's many choices at the moment. I suggest 
trying something like scipy superpack for the moment. It's basically a 
shell script that will download the package tgzs and will run python 
setup.py install on them. It works well and is easy to write.

The advantage of this system is that it is fairly easy to implement and 
the community can see what will come in the next year from distutil and 
the likes.

I'm really excited about all these developments and hope that they will 
be a big improvement for astronomy.

Cheers
     Wolfgang

On 12/07/10 9:53 PM, James Turner wrote:
> Hi Erik,
>
> I almost overlooked your first email in my SciPy folder...
>
> Astropysics is certainly looking interesting. As regards the code
> structure, I would not personally expect AstroLib to be limited to a
> collection of functional library routines. I'm particularly keen to
> use classes to present data processing code in a more accessible way,
> with the algorithmic structure exposed at the top level and the
> bookeeping details hidden (but accessible) underneath. Within Gemini,
> we already have a not-quite-released AstroData class on top of PyFITS
> that understands astronomical data at a higher level (currently it
> mainly acts as a generalized interface to metadata). I'd like us to
> extend that functionality to operators and transformations, but we're
> always a bit underresourced, so things get done on an as-needed basis.
>
> Cheers,
>
> James.
>
>
>> For the last couple years I (and a few others) have been working on
>> Astropysics (http://packages.python.org/Astropysics/ and source code
>> at https://launchpad.net/astropysics).  This initially spun out of my
>> personal need for some of the utilities these other projects discussed
>> (e.g. IDL astron-like functions), but I've been turning it in a
>> slightly different direction.  Astropysics now is being written as a
>> more "pythonic" way of doing the same tasks instead of starting from
>> cloning IDL procedural techniques.  I'm trying to leverage all the
>> existing tools that have been written in python for other domains
>> (e.g. Enthought Traits to easily make good GUIs, sphinx to make useful
>> documentation, distribute to make packaging easier).  Further, where
>> useful, I use object-oriented techniques instead of the procedural
>> approach people familiar with IDL and IRAF are used to.  The idea is
>> to start doing things on "Spectrum" and "CCDImage" objects instead of
>> passing arrays into functions and so on, and each astronomer can then
>> sub-class these classes to do whatever they want.  The aim here is to
>> eliminate the tendancy for people to take public codes and change them
>> internally, leading to some very painful efforts in disentangling
>> versions.
>>
>> So far, Astropysics includes the following modules:
>> * constants – physical constants and cosmological calculations
>> * coords – coordinate classes and coordinate conversions
>> * models – model and data-fitting classes and tools
>> * objcat – flexible, dynamically updated object catalog
>> * ccd – image processing tools
>> * spec – spectrum and SED classes and tools
>> * phot – photometry/flux measurement classes and tools
>> * obstools – miscellaneous tools for observation
>> * io – data input/output classes and tools
>> * plotting – astronomy-oriented matplotlib and mayavi plotting tools
>> * pipeline – classes for data reduction and analysis pipelines
>> * utils – utility classes and functions
>>
>> And these GUI tools, which require Enthought Traits (and Enthought
>> chaco for plots in the GUI):
>> * Spylot – Spectrum Plotter
>> * Fitgui – Interactive Curve Fitting
>> * Spectarget – MOS Targeting
>>
>> I'm making a concerted effort to document everything in a consistent
>> manner using sphinx (http://sphinx.pocoo.org) - the resulting
>> documents (http://packages.python.org/Astropysics/) end up being much
>> more useful.
>>
>> I also try to bind in python wrappers around external tools like
>> sextractor, Mike Blanton's kcorrect, MOS mask design tools, and
>> galfit (planned) ... this happens mostly as I need them for my own
>> science.  But this cuts down on the time re-implementing standard
>> programs that aren't necessarily worth re-working.
>>
>> There are two main things left before I consider it "releasable" in
>> terms of the baseline functionality: First, it needs WCS support to be
>> integrated in the coords framework, and second, the objcat package
>> should have a web server module that lets you show/edit the catalog
>> over the internet instead of within python.  Another major goal I'd
>> like to do when I or someone else gets a chance is something like ATV
>> (http://www.physics.uci.edu/~barth/atv/) utilizing the same TraitsGUI
>> framework that the other gui tools are written in.
>>
>> I hope this explains the direction I have in mind for astropysics.  As
>> far as I can tell, I have a slightly different philosophy - I'm trying
>> to set up something of a framework of my design, rather than a
>> function library.  This is why I have not been working on adding it to
>> astropy, because astropy seems much more like the traditional
>> library... That and I'm not a fan of the Trac project management
>> system.  At any rate, I think there's definitely room for all in the
>> community.  And if anyone likes what they see, feel free to drop me a
>> line if you want to contribute.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy