From jtaylor2 at stsci.edu Thu Jun 3 15:40:51 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Thu, 3 Jun 2010 15:40:51 -0400 (EDT) Subject: [AstroPy] PyFITS Version 2.3.1 Now Available Message-ID: <20100603154051.ABK16629@comet.stsci.edu> **************************************** PyFITS Version 2.3.1 NOW AVAILABLE **************************************** The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of version 2.3.1 of PyFITS. PyFITS version 2.3.1 is being released to resolve a licensing issue in PyFITS. PyFITS 2.3.1 is distributed under a BSD license. Unforturately, PyFITS version 2.0 (January 30 2009) through version 2.3 (May 11 2010) contained a small anount of code in the Compressed Image HDU extenstion module that was covered under a GNU General Public License. Prior to PyFITS version 2.0 and beginning again with PyFITS version 2.3.1, PyFITS is covered under a BSD license. Release Notes ============= Release notes for all versions of PyFITS may be found at: http://www.stsci.edu/resources/software_hardware/pyfits/release Where to Obtain this Software ============================= PyFITS can be downloaded for the PyFITS download web site: http://www.stsci.edu/resources/software_hardware/pyfits/Download Installation instructions are available on the web site. STSCI_PYTHON Support ==================== The upcoming release of STSCI_PYTHON v2.10 will contain PyFITS version 2.3.1. From d.l.goldsmith at gmail.com Mon Jun 14 05:05:35 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Mon, 14 Jun 2010 02:05:35 -0700 Subject: [AstroPy] SciPy docs marathon Message-ID: Hi, all! The scipy doc marathon has gotten off to a very slow start this summer. We are producing less than 1000 words a week, perhaps because many universities are still finishing up spring classes. So, this is a second appeal to everyone to pitch in and help get scipy documented so that it's easy to learn how to use it. Because some of the packages are quite specialized, we need both "regular" contributors to write lots of pages, and some people experienced in using each module (and the mathematics behind the software) to make sure we don't water it down or make it wrong in the process. If you can help, please, now is the time to step forward. Thanks! On behalf of Joe and myself, David Goldsmith Olympia, WA -------------- next part -------------- An HTML attachment was scrubbed... URL: From el.seba.soy.sho at gmail.com Thu Jun 17 23:17:44 2010 From: el.seba.soy.sho at gmail.com (juan catalan) Date: Thu, 17 Jun 2010 23:17:44 -0400 Subject: [AstroPy] Geomap to Python Message-ID: Hi, all! I was wondering if: 1.- Does exists any script or something that simulate what Geomap and/or Geotrans do? 2.- Is anybody intrested to use something like this? I'm a computer science student not related in any kind to astronomy, but once i saw all the work that people that works with geomap have to do to analyse data, and i was wondering if someone is intrested to help me to develp a script that can emulate what Iraf's tools does. The idea that i've got is to develop something that works in python like: #something that handles the .coo files and creates the arrays that geomap will recive has inputs xyref,xyin,n=data.mkMatrix('../Data/xy4.coo') #something that emulate geomapy data2=gm.CoordTransform(xyref,xyin) func=data2.doFit() import pyfits as pf g1=pf.getdata('../../../S20080812S0052_grid.fits',2) #something that emulate what geotran does and show the transformed image g2=func(g1) well, hope not to bother to anyone and if someone is intrested i will be really happy to work with. PS: Sorry about my english is not really good. I'm spanish speaker ~ Juan S. Catal?n Olmos ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jturner at gemini.edu Fri Jun 18 01:17:51 2010 From: jturner at gemini.edu (James Turner) Date: Fri, 18 Jun 2010 01:17:51 -0400 Subject: [AstroPy] Geomap to Python In-Reply-To: References: Message-ID: <4C1B017F.4070700@gemini.edu> > I was wondering if: > 1.- Does exists any script or something that simulate what Geomap and/or > Geotrans do? I think an intern in Chile did some work on this with Gemini and STScI. Perhaps Perry knows what became of that code? Oh wait, I've just realized that was you, wasn't it :-). Where did you get to with that project? Cheers, James. From d.l.goldsmith at gmail.com Fri Jun 18 13:43:23 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Fri, 18 Jun 2010 10:43:23 -0700 Subject: [AstroPy] SciPy docs marathon: a little more info Message-ID: On Mon, Jun 14, 2010 at 2:05 AM, David Goldsmith wrote: > Hi, all! The scipy doc marathon has gotten off to a very slow start this > summer. We are producing less than 1000 words a week, perhaps because > many universities are still finishing up spring classes. So, this is > a second appeal to everyone to pitch in and help get scipy documented > so that it's easy to learn how to use it. Because some of the > packages are quite specialized, we need both "regular" contributors to > write lots of pages, and some people experienced in using each module > (and the mathematics behind the software) to make sure we don't water > it down or make it wrong in the process. If you can help, please, now is > the > time to step forward. Thanks! > > On behalf of Joe and myself, > > David Goldsmith > Olympia, WA > (Apparently this didn't go through the first time.) OK, a few people have come forward - thanks! Let me enumerate the categories that still have no "declared" volunteer writer-editors (all categories are in need of leaders): Max. Entropy, Misc., Image Manip. (Milestone 6) Signal processing (Milestone 8) Sparse Matrices (Milestone 9) Spatial Algorithms., Special funcs. (Milestone 10) C/C++ Integration (Milestone 13) As for the rest, only Interpolation (Milestone 3) has more than one person (but I'm one of the two), and I'm the only person on four others. So, hopefully, knowing specifically which areas are in dire need will inspire people skilled in those areas to sign up. Thanks for your time and help, DG PS: For your convenience, here's the link to the scipy Milestonespage. (Note that the Milestones link at the top of each Wiki page links, incorrectly in the case of the SciPy pages, to the NumPy Milestones page, which we are not actively working on in this Marathon; this is a known, reported bug in the Wiki program.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hack at stsci.edu Mon Jun 21 15:42:09 2010 From: hack at stsci.edu (Warren J. Hack) Date: Mon, 21 Jun 2010 15:42:09 -0400 Subject: [AstroPy] TABLES/STSDAS v3.12 and STSCI_PYTHON v2.10 NOW AVAILABLE Message-ID: <4C1FC091.30306@stsci.edu> ******************************************************* TABLES/STSDAS v3.12 and STSCI_PYTHON v2.10 NOW AVAILABLE ******************************************************* The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of version 3.12 of the Space Telescope Science Data Analysis Software (STSDAS). Concurrent with the STSDAS release, we have also released v3.12 of the TABLES external package. Both of these packages are layered upon IRAF as external packages; it is therefore necessary to obtain and install IRAF (from http://iraf.noao.edu) before installing TABLES and STSDAS. STSDAS is linked against libraries in TABLES, so TABLES must be installed before STSDAS. This release of STSDAS contains changes to NICMOS, ACS, COS, and WFC3, and the Dither packages. This release includes the same versions of the calibration software used in the pipeline to support all active HST instruments using the algorithms developed from the data taken during Servicing Mission 4, especially for the new instruments Wide Field Camera 3(WFC3) and the Cosmic Origins Spectrograph(COS). In addition, we are now including the code used by the Space Telescope European Coordinating Facility (ST-ECF) to do the final reprocessing of the FOS data that now resides in the HST archives. This package, STPOA, along with the last stand-alone version of the FOS package in HST_CALIB, are being provided purely for documentation of the algorithms used in generating the calibrated data in the archives. The code in the STPOA package is not expected to be usable for processing FOS data anymore, however, it remains a useful resource for understanding how the archived FOS data was calibrated. STSDAS also includes some Python-based tasks; running these requires the STScI Python Libraries to be installed (all the non-Python tasks can be used in the traditional way and do not require Python or the STScI Python libraries). These tasks can only be run from PyRAF using standard IRAF CL task syntax, or within Python scripts using Python syntax. The Science Software Branch of STScI also wishes to announce the availability of version 2.10 of STSCI_PYTHON. STScI_Python is a collection of Python modules, packages and C extensions that has been developed to provide a general astronomical data analysis infrastructure. They can be used for Python tasks that are accessible from within STSDAS when running under PyRAF or standalone from within Python. All tasks in this release of STScI_Python rely on the use of numpy for array operations. All references to numarray and Numeric have been removed from the code, with support no longer being provided for use of numarray or Numeric. The primary testing for this release took place under Python 2.5.4 using numpy 1.4. This release also represents the first step in our efforts to prepare our code for eventual conversion to Python 3.0. All the code in this release was updated to use the division library which will be standard for Python 3.0 through the use of 'from __future__ import division'. This code was then tested under Python 2.6 to insure that all the results are identical to those obtained under Python 2.5.4. This distribution continues to develop packages with tasks specific to each HST instrument, with updates being made to code for WFPC2 and COS. This release also contains an updated version of Multidrizzle and PyDrizzle as used by the HST ACS and WFC3 pipelines, along with significantly updated versions of PyFITS and PyRAF. Use of the Python tasks requires upgrading to this version of STSCI_PYTHON. The updated version of PyRAF included in this release can now be run in a "No-IRAF" mode, where the Python shell will run and - although no IRAF tasks will be found - the basic capabilities of the PyRAF command-line will still be supported. The release notes contain more specific information about what still works under PyRAF without IRAF. Finally, this release also includes a new package, STWCS, an HST instrument specific library which provides detector to world coordinate transformations using all distortion model information available through the WCS keywords. No More support for numarray ============================ Numarray is no longer used by tasks within STScI_Python. You are advised to migrate to numpy to use this release, as no further support will be provided for the use of numarray. Information on making the switch to numpy from numarray can be found in this document: http://www.stsci.edu/resources/software_hardware/numarray/numarray2numpy.pdf Platform Support ================ This release does not contain STSDAS/Tables binaries for PowerPC Macintosh systems. However, there are no known reasons why a user could not build this package from source code on a PowerPC using the installation instructions for STSDAS. STSDAS/Tables Binaries for this release were built on Red Hat Enterprise Linux 4 and 5, Solaris 5.8, and Mac OS X 10.5 (Intel architecture only). STSDAS/Tables Binaries were built with IRAF 2.14, except for Solaris, which were built with IRAF 2.12.2a. IRAF is available from http://iraf.net. In addition, this distribution of STScI_Python was tested to correctly support installation on Linux, Mac OS X 10.5 (Leopard), and Solaris, while also being provided for installation (without IRAF) under Windows. STSCI_Python on WINDOWS ======================= This release includes a port of stsci_python that runs natively under Windows. PyRAF is not included for use with the Windows distribution, but the source distribution for STScI_Python could potentially be installed under Cygwin to work with the IRAF installation there, although that configuration has not been verified or tested. The primary requirement for use of this installer is that the Windows executables were built against and, therefore, can run only under Python 2.5. WHERE TO OBTAIN THIS SOFTWARE ============================= STSDAS/TABLES v3.12 can be downloaded from the STSDAS web site http://www.stsci.edu/resources/software_hardware/stsdas/download Installation instructions are available on the web site. Precompiled binaries also exist for some of the ports supported by NOAO, including Sun Solaris, RedHat Linux and Mac OS X. STSCI_PYTHON v 2.10 be downloaded from the PyRAF web site http://www.stsci.edu/resources/software_hardware/pyraf/stsci_python/current/download Installation instructions are available from the PyRAF web site, with support for installations on Sun Solaris, RedHat Linux, Mac OS X, and Windows. Please contact us through e-mail (help at stsci.edu), by telephone at (410) 338-1082. -- Science Software Branch Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-1082 From mperrin at ucla.edu Mon Jun 21 19:53:19 2010 From: mperrin at ucla.edu (Marshall Perrin) Date: Mon, 21 Jun 2010 16:53:19 -0700 Subject: [AstroPy] Python interface for querying Vizier? Message-ID: <97277365-1374-47D6-B1E3-59F840E7BD60@ucla.edu> Hi all, Is there a recommended strategy for accessing the Vizier catalog service from within Python? Some equivalent to IDL's queryvizier.pro would be great, though of course a more Pythonesque object interface would be even better. Has anyone taken a stab at creating something like this? Or is there something in the VO toolkit that can do this sort of thing but that I don't know about? (I confess it seems hard for a relative outsider to the VO community to keep track of what's actually been built there so far...) Thanks in advance, - Marshall From rwagner at physics.ucsd.edu Mon Jun 21 21:55:37 2010 From: rwagner at physics.ucsd.edu (Rick Wagner) Date: Mon, 21 Jun 2010 18:55:37 -0700 Subject: [AstroPy] Python interface for querying Vizier? In-Reply-To: <97277365-1374-47D6-B1E3-59F840E7BD60@ucla.edu> References: <97277365-1374-47D6-B1E3-59F840E7BD60@ucla.edu> Message-ID: <6F7E8A10-8EDA-4ACC-A783-F18330490D39@physics.ucsd.edu> Hi Marshall, I don't know if anyone has written a Python interface specifically for VizieR, but CDS does release a command-line client [1], which could be wrapped in systems calls. However, I would probably go with using SOAPpy [2] to call the VizieR portion of the CDS Web Services [3]. I've cc'ed the IVOA Applications [4] mailing list, because that's where you're likely to find out about the latest VO tools. Feel free to ask there, and check the link for tools that might suit your needs. --Rick [1] http://cdswww.u-strasbg.fr/vizier/doc/cdsclient.html [2] http://pywebsvcs.sourceforge.net/ [3] http://cdsweb.u-strasbg.fr/cdsws.gml [4] http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaApplications On Jun 21, 2010, at 4:53 PM, Marshall Perrin wrote: > Hi all, > > Is there a recommended strategy for accessing the Vizier catalog service from within Python? Some equivalent to IDL's queryvizier.pro would be great, though of course a more Pythonesque object interface would be even better. Has anyone taken a stab at creating something like this? Or is there something in the VO toolkit that can do this sort of thing but that I don't know about? (I confess it seems hard for a relative outsider to the VO community to keep track of what's actually been built there so far...) > > Thanks in advance, > > - Marshall > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From jacobsda at sas.upenn.edu Mon Jun 21 22:03:12 2010 From: jacobsda at sas.upenn.edu (Danny Jacobs) Date: Mon, 21 Jun 2010 20:03:12 -0600 Subject: [AstroPy] Python interface for querying Vizier? In-Reply-To: <6F7E8A10-8EDA-4ACC-A783-F18330490D39@physics.ucsd.edu> References: <97277365-1374-47D6-B1E3-59F840E7BD60@ucla.edu> <6F7E8A10-8EDA-4ACC-A783-F18330490D39@physics.ucsd.edu> Message-ID: Hi Marshall, I've been doing cone searches in Vizier using VO Desktop which has a python module interface. http://www.astrogrid.org/wiki/Help/IntroScripting/AstrogridPython I don't think it has all of Vizier's functionality but you can definitely search a catalog. There were some difficulties dealing with the votable strings it returns but with a little StringIO magic and one of several table readers out there (i use atpy http://atpy.sourceforge.net/) you can get your data into a usable numpy table. Cheers, ~Danny On Mon, Jun 21, 2010 at 7:55 PM, Rick Wagner wrote: > Hi Marshall, > > I don't know if anyone has written a Python interface specifically for VizieR, but CDS does release a command-line client [1], which could be wrapped in systems calls. However, I would probably go with using SOAPpy [2] to call the VizieR portion of the CDS Web Services [3]. > > I've cc'ed the IVOA Applications [4] mailing list, because that's where you're likely to find out about the latest VO tools. Feel free to ask there, and check the link for tools that might suit your needs. > > --Rick > > [1] http://cdswww.u-strasbg.fr/vizier/doc/cdsclient.html > [2] http://pywebsvcs.sourceforge.net/ > [3] http://cdsweb.u-strasbg.fr/cdsws.gml > [4] http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaApplications > > On Jun 21, 2010, at 4:53 PM, Marshall Perrin wrote: > >> Hi all, >> >> Is there a recommended strategy for accessing the Vizier catalog service from within Python? ?Some equivalent to IDL's queryvizier.pro would be great, though of course a more Pythonesque object interface would be even better. Has anyone taken a stab at creating something like this? Or is there something in the VO toolkit that can do this sort of thing but that I don't know about? (I confess it seems hard for a relative outsider to the VO community to keep track of what's actually been built there so far...) >> >> Thanks in advance, >> >> - Marshall >> _______________________________________________ >> 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 > -- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Danny Jacobs Dept. of Physics and Astronomy University of Pennsylvania 209 South 33rd Street Philadelphia, PA 19104-6396 ------------------------------------------------- Office: Rittenhouse Lab - 1n2a Phone: (215) 280-7357 Fax: (215) 898-2010 Homepage: http://dannycjacobs.googlepages.com From d.l.goldsmith at gmail.com Thu Jun 17 00:32:08 2010 From: d.l.goldsmith at gmail.com (David Goldsmith) Date: Wed, 16 Jun 2010 21:32:08 -0700 Subject: [AstroPy] SciPy docs marathon: a little more info Message-ID: On Mon, Jun 14, 2010 at 2:05 AM, David Goldsmith wrote: > Hi, all! The scipy doc marathon has gotten off to a very slow start this > summer. We are producing less than 1000 words a week, perhaps because > many universities are still finishing up spring classes. So, this is > a second appeal to everyone to pitch in and help get scipy documented > so that it's easy to learn how to use it. Because some of the > packages are quite specialized, we need both "regular" contributors to > write lots of pages, and some people experienced in using each module > (and the mathematics behind the software) to make sure we don't water > it down or make it wrong in the process. If you can help, please, now is > the > time to step forward. Thanks! > > On behalf of Joe and myself, > > David Goldsmith > Olympia, WA > OK, a few people have come forward. Let me enumerate the categories that still have no "declared" volunteer writer-editors (all categories are in need of leaders): Max. Entropy, Misc., Image Manip. (Milestone 6) Signal processing (Milestone 8) Sparse Matrices (Milestone 9) Spatial Algorithms., Special funcs. (Milestone 10) C/C++ Integration (Milestone 13) As for the rest, only Interpolation (Milestone 3) has more than one person (but I'm one of the two), and I'm the only person on four others. So, hopefully, knowing specifically which areas are in dire need will inspire people skilled in those areas to sign up. Thanks for your time and help, DG PS: For your convenience, here's the link to the scipy Milestonespage. (Note that the Milestones link at the top of each Wiki page links, incorrectly in the case of the SciPy pages, to the NumPy Milestones page, which we are not actively working on in this Marathon; this is a known, reported bug in the Wiki program.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jturner at gemini.edu Wed Jun 30 17:48:23 2010 From: jturner at gemini.edu (James Turner) Date: Wed, 30 Jun 2010 17:48:23 -0400 Subject: [AstroPy] Co-ordinating Python astronomy libraries? Message-ID: <4C2BBBA7.5060006@gemini.edu> Dear Python users in astronomy, At SciPy 2009, I arranged an astronomy BoF where we discussed the fact that there are now a number of astronomy libraries for Python floating around and maybe it would be good to collect more code into a single place. People seemed receptive to this idea and weren't sure why it hasn't already happened, given that there has been an Astrolib page at SciPy for some years now, with an associated SVN repository: http://scipy.org/AstroLib After the meeting last August, I was supposed to contact the mailing list and some library authors I had talked to previously, to discuss this further. My apologies for taking 10 months to do that! I did draft an email the day after the BoF, but then we ran into a hurdle with setting up new committers to the AstroLib repository (which has taken a lot longer than expected to resolve), so it seemed a bad time to suggest that new people start using it. To discuss these issues further, we'd like to encourage everyone to sign up for the AstroPy mailing list if you are not already on it. The traffic is just a few messages per month. http://lists.astropy.scipy.org/mailman/listinfo/astropy We (the 2009 BoF group) would also like to hear on the list about why people have decided to host their own astronomy library (eg. not being aware of the one at SciPy). Are you interested in contributing to Astrolib? Do you have any other comments or concerns about co-ordinating tools? Our motivation is to make libraries easy to find and install, allow sharing code easily, help rationalize available functionality and fill in what's missing. A standard astronomy library with a single set of documentation should be more coherent and easier to maintain. The idea is not to limit authors' flexibility of take ownership of their code -- the sub-packages can still be maintained by different people. If you're at SciPy this week, Perry Greenfield and I would be happy to talk to you. If you would like to add your existing library to Astrolib, please contact Perry Greenfield or Mark Sienkiewicz at STScI for access (contact details at http://scipy.org/AstroLib). Note that the repository is being moved to a new server this week, after which the URLs will be updated at scipy.org. Thanks! James Turner (Gemini). Bcc: various library authors From erin.sheldon at gmail.com Wed Jun 30 19:37:15 2010 From: erin.sheldon at gmail.com (Erin Sheldon) Date: Wed, 30 Jun 2010 19:37:15 -0400 Subject: [AstroPy] Co-ordinating Python astronomy libraries? In-Reply-To: <4C2BBBA7.5060006@gemini.edu> References: <4C2BBBA7.5060006@gemini.edu> Message-ID: Dear James and AstroPy - Thanks for your note, and prompting! My collegues and I have been writing data analysis related tools for a some time now. We are all astronomers, and in addition to general analysis tools we have a growing library of astro utilities. I'd to make others aware of these, both because they may be useful and because more eyes will find more bugs. We would also welcome collaborators. So far we have hosted our own site because the tools are often so general rather than astronomy specific, but if there is interest we could migrate or mirror some of these to the astrolib svn archive. As the tools mature we have been putting them at this google sites repository: http://code.google.com/p/esutil/ Example astronomy codes currently are WCS utilities (wcsutil), cosmology calculations (cosmology), coordinate transformations (coords), and heirarchical triangular mesh sky search tools (htm). Of more general interest may be the numpy_util, stat, random, ostools, io, and integrate sub-packages. In addition to new things, there are a lot of routines derived from IDL, the Goddard IDL astronomy libraries and the SDSSIDL and IDLUTILS packages. In particular, the structure routines in those IDL packages have correspondence to recarray routines in our packages. For those writing C/C++ extensions, the include/NumpyVector.h template class designed to simplify working with 1-d numpy arrays. There is also a NumpyVoidVector for arrays whose type is determined at runtime. The recfile package is incorporated into esutil (http://code.google.com/p/recfile/) and is used for efficient io of rec files (recfile and sfile sub-packages). I would say that a primary focus of the Astro tools is on using numerical python arrays, especially recarrays. For example, the coordinate transformation and WCS codes take arrays and return arrays. For example: l,b = coords.eq2gal(ra,dec) wcs=wcsutil.WCS(fits_header) ra,dec = wcs.image2sky(x,y) where everything here can be an array. This is opposed to the other libraries out that work with coordinates as objects. There are clearly tradeoffs; we generally read data from FITS tables or databases as numerical python arrays and so it is more natural to work with data that way. I would say this is complimentary to the other approach. In addition to above sub-packages, a few more are very close to ready: * pgnumpy: a numerical python interface to postgres * numpydb:a numerical python interface to berkeley db. * columns: A simple, efficient column-oriented, pythonic database with indexing provided by numpydb. * sdsspy: Tools for working with SDSS data. * mangle: tools for working with mangle masks. I hope people find these useful, Erin Scott Sheldon Cosmology Group Brookhaven National Laboratory on behalf of Brian Gerke and Amy Kimball On Wed, Jun 30, 2010 at 5:48 PM, James Turner wrote: > Dear Python users in astronomy, > > At SciPy 2009, I arranged an astronomy BoF where we discussed the > fact that there are now a number of astronomy libraries for Python > floating around and maybe it would be good to collect more code into > a single place. People seemed receptive to this idea and weren't sure > why it hasn't already happened, given that there has been an Astrolib > page at SciPy for some years now, with an associated SVN repository: > > ? http://scipy.org/AstroLib > > After the meeting last August, I was supposed to contact the mailing > list and some library authors I had talked to previously, to discuss > this further. My apologies for taking 10 months to do that! I did > draft an email the day after the BoF, but then we ran into a hurdle > with setting up new committers to the AstroLib repository (which has > taken a lot longer than expected to resolve), so it seemed a bad > time to suggest that new people start using it. > > To discuss these issues further, we'd like to encourage everyone to > sign up for the AstroPy mailing list if you are not already on it. > The traffic is just a few messages per month. > > ? http://lists.astropy.scipy.org/mailman/listinfo/astropy > > We (the 2009 BoF group) would also like to hear on the list about > why people have decided to host their own astronomy library (eg. not > being aware of the one at SciPy). Are you interested in contributing > to Astrolib? Do you have any other comments or concerns about > co-ordinating tools? Our motivation is to make libraries easy to > find and install, allow sharing code easily, help rationalize > available functionality and fill in what's missing. A standard > astronomy library with a single set of documentation should be more > coherent and easier to maintain. The idea is not to limit authors' > flexibility of take ownership of their code -- the sub-packages > can still be maintained by different people. > > If you're at SciPy this week, Perry Greenfield and I would be happy > to talk to you. If you would like to add your existing library to > Astrolib, please contact Perry Greenfield or Mark Sienkiewicz at > STScI for access (contact details at http://scipy.org/AstroLib). > Note that the repository is being moved to a new server this week, > after which the URLs will be updated at scipy.org. > > Thanks! > > James Turner (Gemini). > > Bcc: various library authors > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From kellecruz at gmail.com Wed Jun 30 20:18:21 2010 From: kellecruz at gmail.com (Kelle Cruz) Date: Wed, 30 Jun 2010 20:18:21 -0400 Subject: [AstroPy] IDL to Python Switchers Guide Message-ID: Hi All, I've sketched out a table on the AstroBetter wiki to use a "Switchers Guide" from IDL. But it will also for developers so that they can see what's already been migrated. http://www.astrobetter.com/wiki/tiki-index.php?page=Python+Switchers+Guide My idea is to list the IDL Astrolib routines, their equivalent/similar functionality python module, followed by a brief description. The table currently includes the sum total of my Python knowledge so it's up to the community to fill it in. I also included in the table a couple IDL routines that probably have Python equivalents but that I just haven't figured out yet. (i couldn't quite figure out what to make of the Starlink package.) Also, feel free to add modules that are useful but that don't have an IDL equivalent. It's a wiki, so edit away. You'll just have to register.... I spent some time writing out the syntax for the pyfits header manipulation stuff, but if you just want to include the package and module, that'll be better than nothing. I also based the sections and their order on the Astrolib page: http://idlastro.gsfc.nasa.gov/contents.html btw, it is not my intention to duplicate the content that's already on the NumPy for IDL users site: http://mathesaurus.sourceforge.net/idl-numpy.html Anyway, for you python gurus out there...next time you're procrastinating but still want to do something productive, fill in some of the table! kelle -- Kelle Cruz, PhD Assistant Professor, Hunter College Research Associate, AMNH Visiting Associate, Caltech http://kellecruz.com/ http://astrobetter.com/ 424.645.1334 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pebarrett at gmail.com Wed Jun 30 21:37:55 2010 From: pebarrett at gmail.com (Paul Barrett) Date: Wed, 30 Jun 2010 21:37:55 -0400 Subject: [AstroPy] Co-ordinating Python astronomy libraries? In-Reply-To: <4C2BBBA7.5060006@gemini.edu> References: <4C2BBBA7.5060006@gemini.edu> Message-ID: Hi James, At the US Naval Observatory, we are currently in the process of developing a Python wrapper for the C version of NOVAS version 3.0 followed shortly by version 3.1. NOVAS is a set of very accurate functions for astrometry and planet positions. We hope to release the first version in the next few months and then develop an object-oriented version that can use arrays as input. We will contact you when we are ready for the first release. Regards, Paul Barrett US Naval Observatory