From William.T.Bridgman.1 at gsfc.nasa.gov Thu Jan 4 11:39:06 2007 From: William.T.Bridgman.1 at gsfc.nasa.gov (W.T. Bridgman) Date: Thu, 4 Jan 2007 11:39:06 -0500 Subject: [AstroPy] Any progress on AstroLibWCS? Message-ID: <51C8E668-71BB-4AF8-AB11-2CC1E353464D@gsfc.nasa.gov> I just checked the wiki and don't find much. I've got a project where I need to redo my coordinate handling from the FITS header for a solar mission. I'm already using an (old) version of pyfits for reading the data but now need to examine scanning the headers for one or more sets of WCS coordinates. Anything available for testing or to at least guide my code organization? Thanks, Tom -- Dr. William T."Tom" Bridgman Scientific Visualization Studio Global Science & Technology, Inc. NASA/Goddard Space Flight Center Email: William.T.Bridgman.1 at gsfc.nasa.gov Code 610.3 Phone: 301-286-1346 Greenbelt, MD 20771 FAX: 301-286-1634 http://svs.gsfc.nasa.gov/ From perry at stsci.edu Thu Jan 4 14:48:51 2007 From: perry at stsci.edu (Perry Greenfield) Date: Thu, 4 Jan 2007 14:48:51 -0500 Subject: [AstroPy] Any progress on AstroLibWCS? In-Reply-To: <51C8E668-71BB-4AF8-AB11-2CC1E353464D@gsfc.nasa.gov> References: <51C8E668-71BB-4AF8-AB11-2CC1E353464D@gsfc.nasa.gov> Message-ID: <9C343280-E6D0-47BA-A3CB-0C943F10E12C@stsci.edu> On Jan 4, 2007, at 11:39 AM, W.T. Bridgman wrote: > I just checked the wiki and don't find much. > > I've got a project where I need to redo my coordinate handling from > the FITS header for a solar mission. I'm already using an (old) > version of pyfits for reading the data but now need to examine > scanning the headers for one or more sets of WCS coordinates. > > Anything available for testing or to at least guide my code > organization? > The short answer is that we haven't done much in the last year since we've been drawn away to work on other projects and have been short- handed. I hope that is now ending (or shortly anyway). Phil Hodge did some preliminary work on this but I don't think it was checked in yet. I'll have him send you what he did so far. Even though we should be able to get back to doing more on Python library work, this isn't an area we will likely do much work on in the next couple of months, so if you would like to carry on, we'd be happy to have you do so (and provide some input on what we think would be useful features and such as well as testing) Perry From rudolph at ska.ac.za Wed Jan 10 06:52:32 2007 From: rudolph at ska.ac.za (Rudolph van der Merwe) Date: Wed, 10 Jan 2007 13:52:32 +0200 Subject: [AstroPy] Variable Length Array Tables in PyFits/Numpy Message-ID: <97670e910701100352w431e498cw9f5985f009010359@mail.gmail.com> I'm running into trouble trying to use PyFITS 1.1b3 (built against Numpy) to create a binary variable length array table (section 6.2.1 in the PyFITS manual). The manual states that for such a table, the field data (attribute 'array') must be a numarray objects array. If I use the equivalent Numpy object array, i.e. numpy.array([a, b], dtype=object) PyFits aborts with an error. Here is a full listing of my sessions: In [2]: import numpy as np In [3]: import pyfits as pf In [4]: a=np.array([1,2,3], dtype=int) In [5]: b=np.array([4,5], dtype=int) In [6]: x=np.array([a,b], dtype=object) In [7]: c1 = pf.Column(name='var', format='PJ()', array=x) In [8]: cols = pf.ColDefs([c1]) In [9]: tbHDU = pf.new_table(cols) --------------------------------------------------------------------------- exceptions.TypeError Traceback (most recent call last) /usr/lib/python2.4/site-packages/pyfits/NP_pyfits.py in new_table(input, header, nrows, fill, tbtype) 3110 elif isinstance(tmp._recformats[i], _FormatP): 3111 # hdu.data._convert[i] = _makep(tmp._arrays[i][:n], hdu.data._parent.field(i)[:n], tmp._recformats[i]._dtype) -> 3112 hdu.data._convert[i] = _makep(tmp._arrays[i][:n], rec.recarray.field(hdu.data,i)[:n], tmp._recformats[i]._dtype) 3113 else: 3114 if tbtype == 'TableHDU': /usr/lib/python2.4/site-packages/pyfits/NP_pyfits.py in _makep(input, desp_output, dtype) 2584 2585 _offset = 0 -> 2586 data_output = _VLF([None]*len(input)) 2587 data_output._dtype = dtype 2588 TypeError: an integer is required In [10]: Any idea how to address this? R. -- Rudolph van der Merwe KAT (Karoo Array Telescope) / www.kat.ac.za From perry at stsci.edu Wed Jan 10 09:24:18 2007 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 10 Jan 2007 09:24:18 -0500 Subject: [AstroPy] Variable Length Array Tables in PyFits/Numpy In-Reply-To: <97670e910701100352w431e498cw9f5985f009010359@mail.gmail.com> References: <97670e910701100352w431e498cw9f5985f009010359@mail.gmail.com> Message-ID: It's a bug that we are working on now. Basically, variable length array tables don't work with numpy at the moment. We'll post when we have a fix. Perry On Jan 10, 2007, at 6:52 AM, Rudolph van der Merwe wrote: > I'm running into trouble trying to use PyFITS 1.1b3 (built against > Numpy) to create a binary variable length array table (section 6.2.1 > in the PyFITS manual). > > The manual states that for such a table, the field data (attribute > 'array') must be a numarray objects array. If I use the equivalent > Numpy object array, i.e. > > numpy.array([a, b], dtype=object) > > PyFits aborts with an error. Here is a full listing of my sessions: > > In [2]: import numpy as np > > In [3]: import pyfits as pf > > In [4]: a=np.array([1,2,3], dtype=int) > > In [5]: b=np.array([4,5], dtype=int) > > In [6]: x=np.array([a,b], dtype=object) > > In [7]: c1 = pf.Column(name='var', format='PJ()', array=x) > > In [8]: cols = pf.ColDefs([c1]) > > In [9]: tbHDU = pf.new_table(cols) > ---------------------------------------------------------------------- > ----- > exceptions.TypeError Traceback (most > recent call last) > > /usr/lib/python2.4/site-packages/pyfits/NP_pyfits.py in > new_table(input, header, nrows, fill, tbtype) > 3110 elif isinstance(tmp._recformats[i], _FormatP): > 3111 # hdu.data._convert[i] = > _makep(tmp._arrays[i][:n], hdu.data._parent.field(i)[:n], > tmp._recformats[i]._dtype) > -> 3112 hdu.data._convert[i] = > _makep(tmp._arrays[i][:n], rec.recarray.field(hdu.data,i)[:n], > tmp._recformats[i]._dtype) > 3113 else: > 3114 if tbtype == 'TableHDU': > > /usr/lib/python2.4/site-packages/pyfits/NP_pyfits.py in _makep(input, > desp_output, dtype) > 2584 > 2585 _offset = 0 > -> 2586 data_output = _VLF([None]*len(input)) > 2587 data_output._dtype = dtype > 2588 > > TypeError: an integer is required > > In [10]: > > > Any idea how to address this? > > R. > > > -- > Rudolph van der Merwe > KAT (Karoo Array Telescope) / www.kat.ac.za > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.net > http://www.scipy.net/mailman/listinfo/astropy From laidler at stsci.edu Thu Jan 25 14:58:05 2007 From: laidler at stsci.edu (Victoria G. Laidler) Date: Thu, 25 Jan 2007 14:58:05 -0500 Subject: [AstroPy] Coords v0.25 release now available Message-ID: <45B90BCD.20606@stsci.edu> Version 0.25 of the Coords package has been released and is now available at http://stsdas.stsci.edu/astrolib/. This is a bugfix release. Release notes: The following issues have been addressed: - Negative degrees in sexagesimal specification is now handled - Longitude/RA convention for TPM-based method calls is now consistent with the rest of the package - Example text has been updated An explanatory note about time: There are three times of interest associated with a celestial coordinate. TPM calls these - the equinox == time at which precession is zero - the epoch == time at which proper motion is zero - the timetag of the coordinate At present (v0.25), the Coords package enforces equinox=B1950 for galactic coordinates and J1984 for ecliptic coordinates; celestial coordinates may be specified at J2000 or B1950, or at an arbitary Julian (decimal) year. For all coordinate systems, it enforces epoch=J2000 and timetag="time now" -- that is, it uses the current system time. Galactic and celestial coordinate systems are very insensitive to changes in "time now", but due to the nature of the ecliptic reference frame, ecliptic coordinates are quite sensitive. The v0.3 release of the Coords package is planned to include the ability to specify the timetag of the coordinate. Release history: - v0.2: included TPM capability to handle precession - v0.1: initial release