From eebanado at uc.cl Mon Sep 2 10:39:08 2013 From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=) Date: Mon, 2 Sep 2013 16:39:08 +0200 Subject: [AstroPy] what changed in astropy.io.fits? Message-ID: Hi all, I recently upgraded to astropy version '0.3.dev5121'. I tried to run one of my old codes and it failed because was using hdr.has_key('CDELT1'). And now seems that the header does not have that attribute anymore: AttributeError: 'CompImageHeader' object has no attribute 'has_key' If I use the old pyfits I don't get any error. Trying to understand what happened, I open the same file using astropy.io.fits and pyfits 2.3.2 and found that the hdu objects were different, they had different number of Cards and different formats. I solved my original problem replacing if hdr.has_key('CDELT1'): by if 'CDELT1' in hdr.keys(): However I am still puzzled by the other changes I see in the HDUs, and I wonder if they have some other implications. Here is a code showing that the HDUs are different using astropy.fits and pyfits (I think the problem should be independent of the image used so I am not attaching it) ================ from astropy.io import fits import pyfits imgname = 'image.fits' hdu1 = pyfits.open(imgname) hdu2 = fits.open(imgname) hdr1 = hdu1[1].header hdr2 = hdu2[1].header print "hdu1 == hdu2? ", hdu1 == hdu2 print hdu1.info() print hdu2.info() ================ The output is: hdu1 == hdu2? False Filename: image.fits No. Name Type Cards Dimensions Format 0 PRIMARY PrimaryHDU 6 () int16 1 CompImageHDU 172 (1200, 1200) float32 None Filename: image.fits No. Name Type Cards Dimensions Format 0 PRIMARY PrimaryHDU 6 () int16 1 CompImageHDU 174 (1200, 1200) int16 None The Cards number changes from 172 to 174 and the Format from float32 to int16. And the attributes of the headers are different Cheers, -- Eduardo Ba?ados -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Tue Sep 3 11:05:17 2013 From: embray at stsci.edu (Erik Bray) Date: Tue, 3 Sep 2013 11:05:17 -0400 Subject: [AstroPy] what changed in astropy.io.fits? In-Reply-To: References: Message-ID: <5225FAAD.5090900@stsci.edu> On 09/02/2013 10:39 AM, Eduardo Ba?ados Torres wrote: > Hi all, > > I recently upgraded to astropy version '0.3.dev5121'. I tried to run one of my > old codes and it failed because was using hdr.has_key('CDELT1'). And now seems > that the header does not have that attribute anymore: AttributeError: > 'CompImageHeader' object has no attribute 'has_key' The `has_key` method on Headers has been deprecated for some time, and is slated for removal in the next release (along with some other deprecated interfaces) so they have already been removed in the development version. If you are on Python 2.7 it may not display deprecation warnings by default. To run Python with deprecation warnings forced on run `python -Wd`. See http://pyfits.readthedocs.org/en/v3.1.2/users_guide/users_misc.html#warning-messages for more information as well as http://pyfits.readthedocs.org/en/v3.1.2/appendix/changelog.html#id23 and http://pyfits.readthedocs.org/en/v3.1.2/appendix/changelog.html#id5 for notices of deprecated interfaces. > If I use the old pyfits I don't get any error. > Trying to understand what happened, I open the same file using astropy.io.fits > and pyfits 2.3.2 and found that the hdu objects were different, they had > different number of Cards and different formats. > > I solved my original problem replacing > if hdr.has_key('CDELT1'): by if 'CDELT1' in hdr.keys(): The correct way to do this is: `if 'CDELT1' in hdr:` just like with Python dicts. No need for the `.keys()` call. > However I am still puzzled by the other changes I see in the HDUs, and I wonder > if they have some other implications. > > Here is a code showing that the HDUs are different using astropy.fits and pyfits > (I think the problem should be independent of the image used so I am not > attaching it) The development versions of pyfits and astropy.io.fits are not exactly in sync at the moment, though my plan is for pyfits 3.2 and astropy 0.3 to be identical. Indeed, since pyfits is slowly being deprecated in favor of astropy, future pyfits releases will be more closely pinned to astropy releases. Hope that clarifies things, Erik > ================ > from astropy.io import fits > import pyfits > > imgname = 'image.fits' > > hdu1 = pyfits.open(imgname) > hdu2 = fits.open(imgname) > > hdr1 = hdu1[1].header > hdr2 = hdu2[1].header > > print "hdu1 == hdu2? ", hdu1 == hdu2 > print hdu1.info () > print hdu2.info () > ================ > > The output is: > > hdu1 == hdu2? False > Filename: image.fits > No. Name Type Cards Dimensions Format > 0 PRIMARY PrimaryHDU 6 () int16 > 1 CompImageHDU 172 (1200, 1200) float32 > None > Filename: image.fits > No. Name Type Cards Dimensions Format > 0 PRIMARY PrimaryHDU 6 () int16 > 1 CompImageHDU 174 (1200, 1200) int16 > None > > > The Cards number changes from 172 to 174 and the Format from float32 to int16. > And the attributes of the headers are different > > Cheers, > > -- > Eduardo Ba?ados > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From john.parejko at yale.edu Wed Sep 4 18:00:04 2013 From: john.parejko at yale.edu (John K. Parejko) Date: Wed, 4 Sep 2013 18:00:04 -0400 Subject: [AstroPy] pyfits: checksum/datasum not both required in fits files Message-ID: <6E20226E-2023-49D9-B5E4-D2883A164315@yale.edu> Hello, It looks like the fits checksum proposal does not require both DATASUM and CHECKSUM in the header (2nd paragraph of the PDF): http://fits.gsfc.nasa.gov/registry/checksum.html verify_checksun in pyfits 3.1.2 does not calculate a matching checksum if "CHECKSUM" is present, but "DATASUM" is not, because it assumes datasum is 0. If I pre-compute datasum and pass that to hdu._calculate_checksum(), I do get the matching checksum. This problem came up because we have some data written with nom.tam.fits v1.06.0, which only writes CHECKSUM, not DATASUM. We've hacked around it when reading the data with pyfits, but it'd be nice to not need that hack. Unfortunately, the correct behavior seems unspecified in the proposal, in the case where CHECKSUM is present but DATASUM is not. Should pyfits relax this requirement, and attempt to pre-compute the data checksum before calling _calculate_checksum(), instead of assuming 0? John -- ************************* John Parejko john.parejko at yale.edu http://www.astro.yale.edu/~jp727/ 203 432-9759 JWG 465 Department of Physics Yale University New Haven, CT ************************** From john.parejko at yale.edu Thu Sep 5 16:00:04 2013 From: john.parejko at yale.edu (John K. Parejko) Date: Thu, 5 Sep 2013 16:00:04 -0400 Subject: [AstroPy] pyfits: checksum/datasum not both required in fits files In-Reply-To: <6E20226E-2023-49D9-B5E4-D2883A164315@yale.edu> References: <6E20226E-2023-49D9-B5E4-D2883A164315@yale.edu> Message-ID: <4F2B8CDB-714C-48E0-8070-0D921EAA5F76@yale.edu> Replying to my self on this with a further question: What is the correct datasum/checksum for unsigned int data with BZERO=37268, BSCALE=1? Should it be calculated on the original bits, or on the scaled values? I ask, because it appears that pyfits and IDL's fits_test_checksum[1] seem to disagree on the correct checksums for unsigned in data. Also, pyfits transparently removes BZERO/BSCALE when writing files if "uint=True" is specified on open(). Essentially, the interaction between uint, scale_back, do_not_scale_image_data, DATASUM/CHECKSUM, and BZERO/BSCALE is very unclear to me. Could someone provide some guidance on this? John 1: http://idlastro.gsfc.nasa.gov/ftp/pro/fits/fits_test_checksum.pro On 4Sep 2013, at 18:00, John K. Parejko wrote: > Hello, > > It looks like the fits checksum proposal does not require both DATASUM and CHECKSUM in the header (2nd paragraph of the PDF): > > http://fits.gsfc.nasa.gov/registry/checksum.html > > verify_checksun in pyfits 3.1.2 does not calculate a matching checksum if "CHECKSUM" is present, but "DATASUM" is not, because it assumes datasum is 0. If I pre-compute datasum and pass that to hdu._calculate_checksum(), I do get the matching checksum. > > This problem came up because we have some data written with nom.tam.fits v1.06.0, which only writes CHECKSUM, not DATASUM. We've hacked around it when reading the data with pyfits, but it'd be nice to not need that hack. Unfortunately, the correct behavior seems unspecified in the proposal, in the case where CHECKSUM is present but DATASUM is not. > > Should pyfits relax this requirement, and attempt to pre-compute the data checksum before calling _calculate_checksum(), instead of assuming 0? > > John From embray at stsci.edu Thu Sep 5 17:12:39 2013 From: embray at stsci.edu (Erik Bray) Date: Thu, 5 Sep 2013 17:12:39 -0400 Subject: [AstroPy] pyfits: checksum/datasum not both required in fits files In-Reply-To: <6E20226E-2023-49D9-B5E4-D2883A164315@yale.edu> References: <6E20226E-2023-49D9-B5E4-D2883A164315@yale.edu> Message-ID: <5228F3C7.5040003@stsci.edu> On 09/04/2013 06:00 PM, John K. Parejko wrote: > Hello, > > It looks like the fits checksum proposal does not require both DATASUM and CHECKSUM in the header (2nd paragraph of the PDF): > > http://fits.gsfc.nasa.gov/registry/checksum.html > > verify_checksun in pyfits 3.1.2 does not calculate a matching checksum if "CHECKSUM" is present, but "DATASUM" is not, because it assumes datasum is 0. If I pre-compute datasum and pass that to hdu._calculate_checksum(), I do get the matching checksum. > > This problem came up because we have some data written with nom.tam.fits v1.06.0, which only writes CHECKSUM, not DATASUM. We've hacked around it when reading the data with pyfits, but it'd be nice to not need that hack. Unfortunately, the correct behavior seems unspecified in the proposal, in the case where CHECKSUM is present but DATASUM is not. > > Should pyfits relax this requirement, and attempt to pre-compute the data checksum before calling _calculate_checksum(), instead of assuming 0? I agree, this is a bug. Looking over the code, it seems PyFITS is trying to be "clever" by using the already calculated DATASUM and just adding to it the checksum of the header to produce the full CHECKSUM value. Of course, if the DATASUM keyword isn't present it should just compute the full checksum of the HDU including the data portion. Instead it seems to be assuming that if the DATASUM keyword is absent then there is no data for which to compute the checksum. I think that it's far more "typical" for a FITS HDU to have both DATASUM and CHECKSUM in the header, rather than just one or the other. But agree, the specification does not require both. (If I had to wager a guess, I'd say this confusion might have come in when whoever implemented this was following section A.2 of the spec: "Recommended CHECKSUM Keyword Implementation". In step 3 is reads "Calculate the checksum for the entire HDU by adding ... the checksum accumulated over the header records to the checksum accumulated over the data records (i.e., the previously computed DATASUM keyword value)." Even the specification *assumes* that the DATASUM keyword has been computed (and nowhere does it specify what to do if it hasn't been, but I assume the answer is to 'compute it' even if it's not saved in the header). > What is the correct datasum/checksum for unsigned int data with BZERO=37268, > BSCALE=1? Should it be calculated on the original bits, or on the scaled > values? The checksum should use the raw bytes. > I ask, because it appears that pyfits and IDL's fits_test_checksum[1] seem to > disagree on the correct checksums for unsigned in data. Also, pyfits > transparently removes BZERO/BSCALE when writing files if "uint=True" is > specified on open(). I think this might be the usual confusion, about how pyfits automatically rescales the data if you open a file and then write it to a new file with writeto(). See https://pyfits.readthedocs.org/en/v3.1.2/appendix/faq.html#why-is-an-image-containing-integer-data-being-converted-unexpectedly-to-floats (the symptoms are different, but the root cause is the same). Erik > John > > -- > ************************* > John Parejko > john.parejko at yale.edu > http://www.astro.yale.edu/~jp727/ > 203 432-9759 > JWG 465 > Department of Physics > Yale University > New Haven, CT > ************************** > > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From embray at stsci.edu Mon Sep 9 19:02:37 2013 From: embray at stsci.edu (Erik Bray) Date: Mon, 9 Sep 2013 19:02:37 -0400 Subject: [AstroPy] pyfits does not write to gzip ab+ objects In-Reply-To: <1B3E32CA-9C5D-4B1B-A915-9F2965050B06@yale.edu> References: <1B3E32CA-9C5D-4B1B-A915-9F2965050B06@yale.edu> Message-ID: <522E538D.7080303@stsci.edu> On 08/23/2013 01:49 AM, John K. Parejko wrote: > Hello, > > On python2.7/pyfits3.1.2 , when I try to write to a gzip object in append mode, 'ab+', I receive an IOError: [Errno 9] read() on write-only GzipFile object. Whereas when I use mode 'ab', I receive no error. > > The former worked in pyfits 2.4-ish (what we were previously using). We use NamedTemporaryFiles to prevent accidental filename collision, and pass that through a gzip object to select the compression level, before writing with hdu.writeto(tempFile,checksum=True). > > I'm not sure whether pyfits or gzip is really the culprit here. I've attached an example. > > Thanks in advance, > John I was just taking another look at this because I've been working on refactoring some of the file handling code in pyfits. And one thing that I noticed is that the `writeto()` method was only ever really designed for writing out a *new* file, and doesn't support appending to an existing file. Now, it should still accept a file with 'ab+' mode and just write a new file (so long as a file with the given name doesn't already exist). But in the case that the file doesn't already exist there's no reason to use append mode. Just 'wb' should be fine. Erik > # Example: > > import gzip > import pyfits > import numpy as np > > hdu=pyfits.PrimaryHDU(np.random.random(10)) > > #IOError: [Errno 9] read() on write-only GzipFile object > f=gzip.GzipFile(filename='foo.fits.gz',mode='ab+',compresslevel=4) > hdu.writeto(f) > > #works, resulting file is gzipped. > f=gzip.GzipFile(filename='foo.fits.gz',mode='ab',compresslevel=4) > hdu.writeto(f) > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From orfeo.colebatch at utoronto.ca Tue Sep 10 14:14:25 2013 From: orfeo.colebatch at utoronto.ca (Orfeo Colebatch) Date: Tue, 10 Sep 2013 18:14:25 +0000 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle Message-ID: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> Hi All, We have a alt/az sun tracker whose coding requires the calculation of the parallactic angle in order to do some coordinate transformations between the alt/az mount and a camera monitoring the image it produces. I have found Ian's Astro Python code (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) which works when i use it conjunction with the coordinates output by this site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted to decimal hours. I have tried to calculate the same hour angle using coordinates.angles.RA.hour_angle (among other codes) bu have not been able to reproduce that Hour Angle (HA) from the above site. E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W longitude I get a HA of -64.73 degreees (or +295 degrees) By doing the following in python with ephem and astropy i get the following In [1]: import ephem In [2]: from astropy import coordinates as coord In [3]: from astropy.time import Time In [4]: from astropy import units as u In [5]: obs = ephem.Observer() In [6]: from datetime import datetime as dt In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d %H:%M:%S') In [8]: obs.date = time In [9]: obs.lon =-79.4 In [10]: obs.lat = 43.66 In [11]: obs.elevation = 174.0 In [12]: sun = ephem.Sun() In [13]: sun.compute(obs) In [14]: ra = sun.g_ra In [15]: ra Out[15]: 1.573768747713852 In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) Out[16]: In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian )) In [18]: c Out[18]: In [19]: c.ra Out[19]: In [20]: sun.ra Out[20]: 1.573725506944724 In [21: c.ra * ephem.pi/180 Out[21]: In [22]: c.ra Out[22]: In [23]: coord.angles.RA.hour_angle(c.ra,t) Out[23]: In [24]: t.lat = 43.66 In [25]: t.lon =-79.4 In [26]: coord.angles.RA.hour_angle(c.ra,t) Out[26]: As you can see the angle is off by 20 degrees. I know this must be a unit problem, but i'm not sure what as of yet. If anyone has any idea's i'd be interested. Perhaps i should be calculating RA inside astropy? and not switching between ephem and astropy? I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the code for the above sun web page( http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like to avoid coding that all up in python. If anyone has any advise i'm all ears. kind regards Orfeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Sep 10 15:11:56 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 10 Sep 2013 15:11:56 -0400 Subject: [AstroPy] X marks the spot Message-ID: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Hi, What the current state of the art in Python-based FITS viewers? If I have a FITS file and a coordinate, does anyone have a template piece of code that would load the image, display it, and draw an x on the coordinate(s) I provide? Thanks! Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ From stsci.perry at gmail.com Tue Sep 10 15:21:46 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Tue, 10 Sep 2013 15:21:46 -0400 Subject: [AstroPy] X marks the spot In-Reply-To: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Message-ID: <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> Have you looked at ginga? On Sep 10, 2013, at 3:11 PM, Demitri Muna wrote: > Hi, > > What the current state of the art in Python-based FITS viewers? > > If I have a FITS file and a coordinate, does anyone have a template piece of code that would load the image, display it, and draw an x on the coordinate(s) I provide? > > Thanks! > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From tim.jenness at gmail.com Tue Sep 10 15:27:55 2013 From: tim.jenness at gmail.com (Tim Jenness) Date: Tue, 10 Sep 2013 15:27:55 -0400 Subject: [AstroPy] X marks the spot In-Reply-To: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Message-ID: On Tue, Sep 10, 2013 at 3:11 PM, Demitri Muna wrote: > > > If I have a FITS file and a coordinate, does anyone have a template piece > of code that would load the image, display it, and draw an x on the > coordinate(s) I provide? > > pyast is designed for this. The Plot classes are specifically there to support what you are asking. You define a Plot and then a mapping from your world coordinates to the plot window. It goes both ways so supports the feedback of you getting an ra/dec from a position on the plot as well as putting markers and lines on the plot using ra/dec. -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From wschoenell at gmail.com Tue Sep 10 15:32:31 2013 From: wschoenell at gmail.com (William Schoenell) Date: Tue, 10 Sep 2013 16:32:31 -0300 Subject: [AstroPy] X marks the spot In-Reply-To: References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Message-ID: Hi, There is some effort on developing a matplotlib-compatible API to do these plots... I saw few weeks ago but did not tried. Take a look on this link: https://github.com/astropy/astropy-api/blob/master/wcs_axes/wcs_api.md Cheers, William On Tue, Sep 10, 2013 at 4:27 PM, Tim Jenness wrote: > > > > On Tue, Sep 10, 2013 at 3:11 PM, Demitri Muna wrote: > >> >> >> If I have a FITS file and a coordinate, does anyone have a template piece >> of code that would load the image, display it, and draw an x on the >> coordinate(s) I provide? >> >> > pyast is designed for this. The Plot classes are specifically there to > support what you are asking. You define a Plot and then a mapping from your > world coordinates to the plot window. It goes both ways so supports the > feedback of you getting an ra/dec from a position on the plot as well as > putting markers and lines on the plot using ra/dec. > > -- > Tim Jenness > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- -------------------------------------------------------------------- William Schoenell Instituto de Astrof?sica de Andaluc?a - CSIC Glorieta de la Astronom?a, s/n. E-18008 Granada - Spain Work Phone: +34 958 230 626 -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Tue Sep 10 15:57:21 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 10 Sep 2013 20:57:21 +0100 Subject: [AstroPy] X marks the spot In-Reply-To: References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Message-ID: On 10 September 2013 20:27, Tim Jenness wrote: > > > > On Tue, Sep 10, 2013 at 3:11 PM, Demitri Muna > wrote: >> >> >> >> If I have a FITS file and a coordinate, does anyone have a template piece >> of code that would load the image, display it, and draw an x on the >> coordinate(s) I provide? >> > > pyast is designed for this. The Plot classes are specifically there to > support what you are asking. You define a Plot and then a mapping from your > world coordinates to the plot window. It goes both ways so supports the > feedback of you getting an ra/dec from a position on the plot as well as > putting markers and lines on the plot using ra/dec. The only thing being that pyast only draws the graphics - it cannot display an image itself (something else needs to have done that first). David From cslocum at stsci.edu Tue Sep 10 16:04:46 2013 From: cslocum at stsci.edu (Christine Slocum) Date: Tue, 10 Sep 2013 20:04:46 +0000 Subject: [AstroPy] Ureka 1.0 beta 6 is now available In-Reply-To: Message-ID: STScI and Gemini are announcing the release of Ureka 1.0 beta 6. This is a minor update which includes some upgraded Python packages and a few bug fixes. New/upgraded packages: - Python 2.7.5 - NumPy 1.7.1 - Matplotlib 1.3.0 - SciPy 0.12.0 - pandas 0.12.0 - scikit-image 0.7.1 - scikit-learn 0.13.1 - HDF5 1.8.11 - yolk 0.4.3 - wheel 0.21.0 - pip 1.4 - virtualenv 1.10 - Parsely 1.2 - Pillow 2.0.0 Ureka is a binary packaging installer for common astronomical software (primarily for the UV/Optical/IR community). The goals of the Ureka installer are to: 1) minimize the number of actions needed to install all the different software components. We are seeking a "one button install" (it's not quite one button, but not far from it). 2) permit installation without requiring system privileges. 3) make installs as problem-free as possible for the great majority of users. 4) allow users to install their own software (particularly Python-based) within this framework, or update versions of software within the framework. 5) permit different Ureka installations to coexist and to easily switch between them. 6) enable installing different versions of the same software package under a particular Ureka installation. 7) support Macs and most popular Linux variants. Ureka does not use LD_LIBRARY_PATH (or its Mac equivalent) and thus should not affect existing software after installation or use. Keep in mind that no installation system is completely foolproof (that's very nearly impossible to achieve). In particular, when users update or add software to the Ureka framework, they increase the risk of breaking something, but we feel that is an option that users should have as long as they understand the possible risks. This beta version includes IRAF and associated packages for IRAF, DS9, and a fairly full suite of Python scientific software packages (e.g., numpy, scipy, and matplotlib). The full listing of included software can be found at this link: http://ssb.stsci.edu/ureka/1.0beta6/docs/components.html Ureka can be downloaded from: http://ssb.stsci.edu/ureka/ (choose "1.0 beta 6"). Installation and usage instructions can be found on the same web page. This is a beta release. We do expect to uncover some problems that testing at Gemini and STScI did not encounter. If you do find problems, please let us know (help at stsci.edu). Feedback on additional software components that would be considered generally essential for this distribution is also welcome. From shupe at ipac.caltech.edu Tue Sep 10 16:18:58 2013 From: shupe at ipac.caltech.edu (David Shupe) Date: Tue, 10 Sep 2013 13:18:58 -0700 Subject: [AstroPy] X marks the spot In-Reply-To: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> Message-ID: <77FCE350-33B2-48F1-B4F4-CF04E6571959@ipac.caltech.edu> My first thought was APLpy: http://aplpy.github.io Regards, Dave On Sep 10, 2013, at 12:11 PM, Demitri Muna wrote: > Hi, > > What the current state of the art in Python-based FITS viewers? > > If I have a FITS file and a coordinate, does anyone have a template piece of code that would load the image, display it, and draw an x on the coordinate(s) I provide? > > Thanks! > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From demitri.muna at gmail.com Tue Sep 10 17:54:45 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 10 Sep 2013 17:54:45 -0400 Subject: [AstroPy] X marks the spot In-Reply-To: <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> Message-ID: On Sep 10, 2013, at 3:21 PM, Perry Greenfield wrote: > Have you looked at ginga? I did a little while ago, but the installation process was so daunting on my Mac that I never ran it. I don't get the impression that things have changed. On Sep 10, 2013, at 3:27 PM, Tim Jenness wrote: > pyast is designed for this. The Plot classes are specifically there to support what you are asking. You define a Plot and then a mapping from your world coordinates to the plot window. It goes both ways so supports the feedback of you getting an ra/dec from a position on the plot as well as putting markers and lines on the plot using ra/dec. Any simple example code? This has to be one of the simplest examples I can think of. On Sep 10, 2013, at 3:32 PM, William Schoenell wrote: > There is some effort on developing a matplotlib-compatible API to do these plots... I saw few weeks ago but did not tried. Take a look on this link: https://github.com/astropy/astropy-api/blob/master/wcs_axes/wcs_api.md That looks good (my problems with matplotlib notwithstanding), but `import from __future__` doesn't actually work like that. :) On Sep 10, 2013, at 4:18 PM, David Shupe wrote: > My first thought was APLpy: http://aplpy.github.io We have a winner! APLpy takes it for ease of installation (normal process) and clear examples on the web site. import aplpy gc = aplpy.FITSFigure('V1.fits') gc.show_grayscale() gc.show_markers(187, -72.73, edgecolor='red', facecolor='red', marker='o', s=10, alpha=0.8) Would have preferred that ra/dec were named parameters, but that's just being picky. Cheers, Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Tue Sep 10 21:00:42 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 10 Sep 2013 21:00:42 -0400 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle In-Reply-To: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> References: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> Message-ID: This example seems to be incomplete, because I can't see where `t` is defined. That's important, because `hour_angle` doesn't compute sidereal time based on location, it just accepts and LST and gives you out an hour angle. Are you perhaps missing a line somewhere above? On Tue, Sep 10, 2013 at 2:14 PM, Orfeo Colebatch wrote: > Hi All, > > We have a alt/az sun tracker whose coding requires the calculation of the > parallactic angle in order to do some coordinate transformations between the > alt/az mount and a camera monitoring the image it produces. > > I have found Ian's Astro Python code > (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) > which works when i use it conjunction with the coordinates output by this > site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted > to decimal hours. > > I have tried to calculate the same hour angle using > coordinates.angles.RA.hour_angle (among other codes) bu have not been able > to reproduce that Hour Angle (HA) from the above site. > > E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W > longitude I get a HA of -64.73 degreees (or +295 degrees) > > > By doing the following in python with ephem and astropy i get the following > > > In [1]: import ephem > > In [2]: from astropy import coordinates as coord > > In [3]: from astropy.time import Time > > In [4]: from astropy import units as u > > In [5]: obs = ephem.Observer() > > In [6]: from datetime import datetime as dt > > In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d > %H:%M:%S') > > In [8]: obs.date = time > > In [9]: obs.lon =-79.4 > > In [10]: obs.lat = 43.66 > > In [11]: obs.elevation = 174.0 > > In [12]: sun = ephem.Sun() > > In [13]: sun.compute(obs) > > In [14]: ra = sun.g_ra > > In [15]: ra > Out[15]: 1.573768747713852 > > In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, > u.radian)) > Out[16]: > > In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, > u.radian > )) > > In [18]: c > Out[18]: > > In [19]: c.ra > Out[19]: > > In [20]: sun.ra > Out[20]: 1.573725506944724 > > In [21: c.ra * ephem.pi/180 > Out[21]: > > In [22]: c.ra > Out[22]: > > In [23]: coord.angles.RA.hour_angle(c.ra,t) > Out[23]: > > In [24]: t.lat = 43.66 > > In [25]: t.lon =-79.4 > > In [26]: coord.angles.RA.hour_angle(c.ra,t) > Out[26]: > > > > As you can see the angle is off by 20 degrees. I know this must be a unit > problem, but i'm not sure what as of yet. If anyone has any idea's i'd be > interested. Perhaps i should be calculating RA inside astropy? and not > switching between ephem and astropy? > > > I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the > code for the above sun web page( > http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like > to avoid coding that all up in python. > > If anyone has any advise i'm all ears. > > kind regards > > > Orfeo > > > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik From eric at naoj.org Tue Sep 10 22:07:44 2013 From: eric at naoj.org (Eric Jeschke) Date: Tue, 10 Sep 2013 16:07:44 -1000 Subject: [AstroPy] X marks the spot Message-ID: As Perry mentioned, Ginga can do that pretty easily, as well has handling two-way interaction. Check out this demo using an ipython notebook . Regards, ~Eric -- Eric Jeschke | eric at naoj.org | ????,??? Software Engineer | 808-934-5908 | ??????????? Subaru Telescope | | ?????? National Astronomical Observatory of Japan http://naoj.org/staff/eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at naoj.org Tue Sep 10 22:33:25 2013 From: eric at naoj.org (Eric Jeschke) Date: Tue, 10 Sep 2013 16:33:25 -1000 Subject: [AstroPy] AstroPy Digest, Vol 84, Issue 6 In-Reply-To: References: Message-ID: As Perry mentioned, Ginga can do that pretty easily, as well has handling two-way interaction. Check out this demo using an ipython notebook . Here's a snippet of code to draw a point on an ra, dec (assuming you have a viewer 'v1' open as shown in the demo): # ra/dec in degrees ra_deg, dec_deg = (299.64881091007464, 22.821619885325994) # load an image from ginga.AstroImage import AstroImage img = AstroImage() img.load_file("/path/to/your/fits/image.fits") v1.set_image(img) # draw a point there x, y = img.radectopix(ra_deg, dec_deg) Point = v1.getDrawClass('point') v1.add(Point(x, y, radius=10, color='yellow')) This uses astropy under the hood to do the coordinates. Regards, ~Eric On Tue, Sep 10, 2013 at 10:12 AM, wrote: > Date: Tue, 10 Sep 2013 15:11:56 -0400 > From: Demitri Muna > Subject: [AstroPy] X marks the spot > To: "astropy at scipy.org" > Message-ID: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > What the current state of the art in Python-based FITS viewers? > > If I have a FITS file and a coordinate, does anyone have a template piece > of code that would load the image, display it, and draw an x on the > coordinate(s) I provide? > > Thanks! > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > > -- Eric Jeschke | eric at naoj.org | ????,??? Software Engineer | 808-934-5908 | ??????????? Subaru Telescope | | ?????? National Astronomical Observatory of Japan http://naoj.org/staff/eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.kosack at cea.fr Wed Sep 11 04:02:12 2013 From: karl.kosack at cea.fr (Karl Kosack) Date: Wed, 11 Sep 2013 10:02:12 +0200 Subject: [AstroPy] X marks the spot In-Reply-To: References: Message-ID: On 10 September 2013 21:11, Demitri Muna wrote: > Hi, > > What the current state of the art in Python-based FITS viewers? > > If I have a FITS file and a coordinate, does anyone have a template piece > of code that would load the image, display it, and draw an x on the > coordinate(s) I provide? > I'd suggest looking at the Kapteyn library: http://www.astro.rug.nl/software/kapteyn/ It's fully matplotlib compatible and is designed specifically for FITS plotting (including all all-sky projections). It also has excellent documentation and examples. Cheers, Karl > > Thanks! > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Karl Kosack CEA Saclay Bat 709 DSM/IRFU/SAp F-91191 Gif sur Yvette Cedex FRANCE -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Wed Sep 11 07:35:29 2013 From: deil.christoph at googlemail.com (Christoph Deil) Date: Wed, 11 Sep 2013 13:35:29 +0200 Subject: [AstroPy] X marks the spot In-Reply-To: References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> Message-ID: On Sep 10, 2013, at 11:54 PM, Demitri Muna wrote: > > On Sep 10, 2013, at 3:21 PM, Perry Greenfield wrote: > >> Have you looked at ginga? > > > I did a little while ago, but the installation process was so daunting on my Mac that I never ran it. I don't get the impression that things have changed. Hi Demitri, I'm using Ginga on Mac and it works great. Installing GUI packages is always a daunting task, but becomes easy when using a package manager. To use Ginga on Mac, you can install Macports following the instructions at http://www.macports.org and then execute these commands to install Qt GUI: sudo port install py27-pyside py27-astropy py27-pip Then install Ginga: pip-2.7 install ginga --user Or use Python 3 if you prefer, that works as well. Christoph > > On Sep 10, 2013, at 3:27 PM, Tim Jenness wrote: > >> pyast is designed for this. The Plot classes are specifically there to support what you are asking. You define a Plot and then a mapping from your world coordinates to the plot window. It goes both ways so supports the feedback of you getting an ra/dec from a position on the plot as well as putting markers and lines on the plot using ra/dec. > > > Any simple example code? This has to be one of the simplest examples I can think of. > > > On Sep 10, 2013, at 3:32 PM, William Schoenell wrote: > >> There is some effort on developing a matplotlib-compatible API to do these plots... I saw few weeks ago but did not tried. Take a look on this link: https://github.com/astropy/astropy-api/blob/master/wcs_axes/wcs_api.md > > > That looks good (my problems with matplotlib notwithstanding), but `import from __future__` doesn't actually work like that. :) > > On Sep 10, 2013, at 4:18 PM, David Shupe wrote: > >> My first thought was APLpy: http://aplpy.github.io > > We have a winner! APLpy takes it for ease of installation (normal process) and clear examples on the web site. > > import aplpy > gc = aplpy.FITSFigure('V1.fits') > gc.show_grayscale() > gc.show_markers(187, -72.73, edgecolor='red', facecolor='red', marker='o', s=10, alpha=0.8) > > Would have preferred that ra/dec were named parameters, but that's just being picky. > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From orfeo.colebatch at utoronto.ca Wed Sep 11 10:32:58 2013 From: orfeo.colebatch at utoronto.ca (Orfeo Colebatch) Date: Wed, 11 Sep 2013 14:32:58 +0000 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle In-Reply-To: References: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca>, Message-ID: <10679715308F314F8C655A3568A532A22D84D7E6@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Thanks Erik and Tim, I forgot to include the t object definition. I used the astropy.time module to set t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') I wasn't sure if i needed to set this time (t) to Toronto Canada time (UTC-4 currently) but i thought as long as i used the actual UTC time which corresponds to 09:00:00 Toronto time that would be ok. I corrected my code below (also changed the ephem time to 13:00:00). Still no change in the Hour Angle. I'm looking into sidereal time now as that looks like it's probably the cause, my vague understanding of LST is that i need to correct my Local time (or UTC) by the longitude i sit at (Toronto -79.4 W). Hopefully i can figure this out but if you have any further pointers i'm all ears. Regards orfeo import ephem from astropy import coordinates as coord from astropy.time import Time from astropy import units as u from datetime import datetime as dt def HA(): obs = ephem.Observer() time = dt.strptime('2013/6/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') obs.date = time obs.lon =-79.4 lat = 43.66 obs.elevation = 174.0 sun = ephem.Sun() sun.compute(obs) ra = sun.g_ra c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') t.lat = 43.66 t.lon =-79.4 ha = coord.angles.RA.hour_angle(c.ra,t) return ha if __name__== '__main__': print 'Calculating Hour Angle as ', HA() -------------------------------------------- In [1]: import ha_astropy In [2]: ha_astropy.HA() Out[2]: ________________________________________ From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] Sent: 10 September 2013 21:00 To: Orfeo Colebatch; astropy at scipy.org Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle This example seems to be incomplete, because I can't see where `t` is defined. That's important, because `hour_angle` doesn't compute sidereal time based on location, it just accepts and LST and gives you out an hour angle. Are you perhaps missing a line somewhere above? On Tue, Sep 10, 2013 at 2:14 PM, Orfeo Colebatch wrote: > Hi All, > > We have a alt/az sun tracker whose coding requires the calculation of the > parallactic angle in order to do some coordinate transformations between the > alt/az mount and a camera monitoring the image it produces. > > I have found Ian's Astro Python code > (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) > which works when i use it conjunction with the coordinates output by this > site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted > to decimal hours. > > I have tried to calculate the same hour angle using > coordinates.angles.RA.hour_angle (among other codes) bu have not been able > to reproduce that Hour Angle (HA) from the above site. > > E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W > longitude I get a HA of -64.73 degreees (or +295 degrees) > > > By doing the following in python with ephem and astropy i get the following > > > In [1]: import ephem > > In [2]: from astropy import coordinates as coord > > In [3]: from astropy.time import Time > > In [4]: from astropy import units as u > > In [5]: obs = ephem.Observer() > > In [6]: from datetime import datetime as dt > > In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d > %H:%M:%S') > > In [8]: obs.date = time > > In [9]: obs.lon =-79.4 > > In [10]: obs.lat = 43.66 > > In [11]: obs.elevation = 174.0 > > In [12]: sun = ephem.Sun() > > In [13]: sun.compute(obs) > > In [14]: ra = sun.g_ra > > In [15]: ra > Out[15]: 1.573768747713852 > > In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, > u.radian)) > Out[16]: > > In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, > u.radian > )) > > In [18]: c > Out[18]: > > In [19]: c.ra > Out[19]: > > In [20]: sun.ra > Out[20]: 1.573725506944724 > > In [21: c.ra * ephem.pi/180 > Out[21]: > > In [22]: c.ra > Out[22]: > > In [23]: coord.angles.RA.hour_angle(c.ra,t) > Out[23]: > > In [24]: t.lat = 43.66 > > In [25]: t.lon =-79.4 > > In [26]: coord.angles.RA.hour_angle(c.ra,t) > Out[26]: > > > > As you can see the angle is off by 20 degrees. I know this must be a unit > problem, but i'm not sure what as of yet. If anyone has any idea's i'd be > interested. Perhaps i should be calculating RA inside astropy? and not > switching between ephem and astropy? > > > I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the > code for the above sun web page( > http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like > to avoid coding that all up in python. > > If anyone has any advise i'm all ears. > > kind regards > > > Orfeo > > > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik From erik.tollerud at gmail.com Wed Sep 11 10:52:39 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 11 Sep 2013 10:52:39 -0400 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle In-Reply-To: <10679715308F314F8C655A3568A532A22D84D7E6@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> References: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> <10679715308F314F8C655A3568A532A22D84D7E6@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Message-ID: Ah, that's your problem. As I think you've now surmised, the time that goes into `hour_angle` is the Local Sidereal Time, *not* the local time. Given that you're already using pyephem, the easiest thing is to just use the Observer.sidereal_time method. (E.g., obs.sidereal_time() ) in your example. One other thing you should know, though: pyephem uses radians for essentially everything. So in you're example, when you do e.g., ``obs.lon =-79.4``, pyephem is treating that is -79.4 radians, not degrees. I think you can use strings somehow to tell it to use degrees, but you'll have to look more closely at the documentation, as I don't remember exactly how that works. Regardless, though, `obs.sidereal_time` will probably give you radians out, so you'll need to do something like ``t = coord.Angle(obs.sidereal_time(), u.radian)`` to make sure the units work out. On Wed, Sep 11, 2013 at 10:32 AM, Orfeo Colebatch wrote: > Thanks Erik and Tim, > > > I forgot to include the t object definition. I used the astropy.time module to set > > t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') > > I wasn't sure if i needed to set this time (t) to Toronto Canada time (UTC-4 currently) but i thought as long as i used the actual UTC time which corresponds to 09:00:00 Toronto time that would be ok. I corrected my code below (also changed the ephem time to 13:00:00). Still no change in the Hour Angle. > > > I'm looking into sidereal time now as that looks like it's probably the cause, my vague understanding of LST is that i need to correct my Local time (or UTC) by the longitude i sit at (Toronto -79.4 W). > > Hopefully i can figure this out but if you have any further pointers i'm all ears. > > Regards > orfeo > > > > > > > import ephem > > from astropy import coordinates as coord > > from astropy.time import Time > > from astropy import units as u > > from datetime import datetime as dt > > def HA(): > obs = ephem.Observer() > > time = dt.strptime('2013/6/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') > > obs.date = time > > obs.lon =-79.4 > > lat = 43.66 > > obs.elevation = 174.0 > > sun = ephem.Sun() > > sun.compute(obs) > > ra = sun.g_ra > > c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) > > t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') > > t.lat = 43.66 > > t.lon =-79.4 > > ha = coord.angles.RA.hour_angle(c.ra,t) > > return ha > > > if __name__== '__main__': > print 'Calculating Hour Angle as ', HA() > > > -------------------------------------------- > > In [1]: import ha_astropy > > In [2]: ha_astropy.HA() > Out[2]: > > > > > > > > > > ________________________________________ > From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] > Sent: 10 September 2013 21:00 > To: Orfeo Colebatch; astropy at scipy.org > Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle > > This example seems to be incomplete, because I can't see where `t` is > defined. That's important, because `hour_angle` doesn't compute > sidereal time based on location, it just accepts and LST and gives you > out an hour angle. Are you perhaps missing a line somewhere above? > > On Tue, Sep 10, 2013 at 2:14 PM, Orfeo Colebatch > wrote: >> Hi All, >> >> We have a alt/az sun tracker whose coding requires the calculation of the >> parallactic angle in order to do some coordinate transformations between the >> alt/az mount and a camera monitoring the image it produces. >> >> I have found Ian's Astro Python code >> (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) >> which works when i use it conjunction with the coordinates output by this >> site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted >> to decimal hours. >> >> I have tried to calculate the same hour angle using >> coordinates.angles.RA.hour_angle (among other codes) bu have not been able >> to reproduce that Hour Angle (HA) from the above site. >> >> E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W >> longitude I get a HA of -64.73 degreees (or +295 degrees) >> >> >> By doing the following in python with ephem and astropy i get the following >> >> >> In [1]: import ephem >> >> In [2]: from astropy import coordinates as coord >> >> In [3]: from astropy.time import Time >> >> In [4]: from astropy import units as u >> >> In [5]: obs = ephem.Observer() >> >> In [6]: from datetime import datetime as dt >> >> In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d >> %H:%M:%S') >> >> In [8]: obs.date = time >> >> In [9]: obs.lon =-79.4 >> >> In [10]: obs.lat = 43.66 >> >> In [11]: obs.elevation = 174.0 >> >> In [12]: sun = ephem.Sun() >> >> In [13]: sun.compute(obs) >> >> In [14]: ra = sun.g_ra >> >> In [15]: ra >> Out[15]: 1.573768747713852 >> >> In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >> u.radian)) >> Out[16]: >> >> In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >> u.radian >> )) >> >> In [18]: c >> Out[18]: >> >> In [19]: c.ra >> Out[19]: >> >> In [20]: sun.ra >> Out[20]: 1.573725506944724 >> >> In [21: c.ra * ephem.pi/180 >> Out[21]: >> >> In [22]: c.ra >> Out[22]: >> >> In [23]: coord.angles.RA.hour_angle(c.ra,t) >> Out[23]: >> >> In [24]: t.lat = 43.66 >> >> In [25]: t.lon =-79.4 >> >> In [26]: coord.angles.RA.hour_angle(c.ra,t) >> Out[26]: >> >> >> >> As you can see the angle is off by 20 degrees. I know this must be a unit >> problem, but i'm not sure what as of yet. If anyone has any idea's i'd be >> interested. Perhaps i should be calculating RA inside astropy? and not >> switching between ephem and astropy? >> >> >> I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the >> code for the above sun web page( >> http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like >> to avoid coding that all up in python. >> >> If anyone has any advise i'm all ears. >> >> kind regards >> >> >> Orfeo >> >> >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > > -- > Erik -- Erik From erik.tollerud at gmail.com Wed Sep 11 11:03:06 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 11 Sep 2013 11:03:06 -0400 Subject: [AstroPy] Acknowledging Astropy in talks with "astropy-powered" logo Message-ID: Hello all, For those among you that are using the Astropy package for work that you will be presenting in a talk, I'd like to briefly mention a new section of the Astropy web site you may want to look at: http://www.astropy.org/#presentations Specifically, there is now an "Astropy-powered" logo that you can put on the title and/or acknowledgements slide of your talk to credit Astropy if you feel it contributed substantially to your work. Also, if there are slightly different color schemes/text sizes you think might be useful for your talk, feel free to edit the .svg originals at https://github.com/astropy/astropy-logo and issue a pull request. Hopefully you find this helpful! -- Erik Tollerud From orfeo.colebatch at utoronto.ca Wed Sep 11 11:45:41 2013 From: orfeo.colebatch at utoronto.ca (Orfeo Colebatch) Date: Wed, 11 Sep 2013 15:45:41 +0000 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle In-Reply-To: References: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> <10679715308F314F8C655A3568A532A22D84D7E6@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca>, Message-ID: <10679715308F314F8C655A3568A532A22D84D805@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Thanks Erik, You're spot on, thanks for the tips on converting the radians of ephem to the coord.Angle of astropy. The hour angle being returned is now matching the website. I just need to put it in decimal hours by dividing by 15 and i should be set to put it into Ian's Astro-Python Code ( http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle ) in order to calculate the hour angle. Regrads orfeo ps here's my code import ephem from astropy import coordinates as coord from astropy.time import Time from astropy import units as u from datetime import datetime as dt def HA(): obs = ephem.Observer() time = dt.strptime('2013/10/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') obs.date = time obs.lon =ephem.degrees('-79.4') obs.lat = ephem.degrees('43.66') obs.elevation = 174.0 sun = ephem.Sun() sun.compute(obs) ra = sun.g_ra c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) t = coord.Angle(obs.sidereal_time(),u.radian) t.lat = 43.66 t.lon =-79.4 ha = coord.angles.RA.hour_angle(c.ra,t) return ha if __name__ == '__main__': print ' Calculated hour angle is ', HA() ________________________________________ From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] Sent: 11 September 2013 10:52 To: Orfeo Colebatch Cc: astropy at scipy.org Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle Ah, that's your problem. As I think you've now surmised, the time that goes into `hour_angle` is the Local Sidereal Time, *not* the local time. Given that you're already using pyephem, the easiest thing is to just use the Observer.sidereal_time method. (E.g., obs.sidereal_time() ) in your example. One other thing you should know, though: pyephem uses radians for essentially everything. So in you're example, when you do e.g., ``obs.lon =-79.4``, pyephem is treating that is -79.4 radians, not degrees. I think you can use strings somehow to tell it to use degrees, but you'll have to look more closely at the documentation, as I don't remember exactly how that works. Regardless, though, `obs.sidereal_time` will probably give you radians out, so you'll need to do something like ``t = coord.Angle(obs.sidereal_time(), u.radian)`` to make sure the units work out. On Wed, Sep 11, 2013 at 10:32 AM, Orfeo Colebatch wrote: > Thanks Erik and Tim, > > > I forgot to include the t object definition. I used the astropy.time module to set > > t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') > > I wasn't sure if i needed to set this time (t) to Toronto Canada time (UTC-4 currently) but i thought as long as i used the actual UTC time which corresponds to 09:00:00 Toronto time that would be ok. I corrected my code below (also changed the ephem time to 13:00:00). Still no change in the Hour Angle. > > > I'm looking into sidereal time now as that looks like it's probably the cause, my vague understanding of LST is that i need to correct my Local time (or UTC) by the longitude i sit at (Toronto -79.4 W). > > Hopefully i can figure this out but if you have any further pointers i'm all ears. > > Regards > orfeo > > > > > > > import ephem > > from astropy import coordinates as coord > > from astropy.time import Time > > from astropy import units as u > > from datetime import datetime as dt > > def HA(): > obs = ephem.Observer() > > time = dt.strptime('2013/6/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') > > obs.date = time > > obs.lon =-79.4 > > lat = 43.66 > > obs.elevation = 174.0 > > sun = ephem.Sun() > > sun.compute(obs) > > ra = sun.g_ra > > c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) > > t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') > > t.lat = 43.66 > > t.lon =-79.4 > > ha = coord.angles.RA.hour_angle(c.ra,t) > > return ha > > > if __name__== '__main__': > print 'Calculating Hour Angle as ', HA() > > > -------------------------------------------- > > In [1]: import ha_astropy > > In [2]: ha_astropy.HA() > Out[2]: > > > > > > > > > > ________________________________________ > From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] > Sent: 10 September 2013 21:00 > To: Orfeo Colebatch; astropy at scipy.org > Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle > > This example seems to be incomplete, because I can't see where `t` is > defined. That's important, because `hour_angle` doesn't compute > sidereal time based on location, it just accepts and LST and gives you > out an hour angle. Are you perhaps missing a line somewhere above? > > On Tue, Sep 10, 2013 at 2:14 PM, Orfeo Colebatch > wrote: >> Hi All, >> >> We have a alt/az sun tracker whose coding requires the calculation of the >> parallactic angle in order to do some coordinate transformations between the >> alt/az mount and a camera monitoring the image it produces. >> >> I have found Ian's Astro Python code >> (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) >> which works when i use it conjunction with the coordinates output by this >> site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted >> to decimal hours. >> >> I have tried to calculate the same hour angle using >> coordinates.angles.RA.hour_angle (among other codes) bu have not been able >> to reproduce that Hour Angle (HA) from the above site. >> >> E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W >> longitude I get a HA of -64.73 degreees (or +295 degrees) >> >> >> By doing the following in python with ephem and astropy i get the following >> >> >> In [1]: import ephem >> >> In [2]: from astropy import coordinates as coord >> >> In [3]: from astropy.time import Time >> >> In [4]: from astropy import units as u >> >> In [5]: obs = ephem.Observer() >> >> In [6]: from datetime import datetime as dt >> >> In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d >> %H:%M:%S') >> >> In [8]: obs.date = time >> >> In [9]: obs.lon =-79.4 >> >> In [10]: obs.lat = 43.66 >> >> In [11]: obs.elevation = 174.0 >> >> In [12]: sun = ephem.Sun() >> >> In [13]: sun.compute(obs) >> >> In [14]: ra = sun.g_ra >> >> In [15]: ra >> Out[15]: 1.573768747713852 >> >> In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >> u.radian)) >> Out[16]: >> >> In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >> u.radian >> )) >> >> In [18]: c >> Out[18]: >> >> In [19]: c.ra >> Out[19]: >> >> In [20]: sun.ra >> Out[20]: 1.573725506944724 >> >> In [21: c.ra * ephem.pi/180 >> Out[21]: >> >> In [22]: c.ra >> Out[22]: >> >> In [23]: coord.angles.RA.hour_angle(c.ra,t) >> Out[23]: >> >> In [24]: t.lat = 43.66 >> >> In [25]: t.lon =-79.4 >> >> In [26]: coord.angles.RA.hour_angle(c.ra,t) >> Out[26]: >> >> >> >> As you can see the angle is off by 20 degrees. I know this must be a unit >> problem, but i'm not sure what as of yet. If anyone has any idea's i'd be >> interested. Perhaps i should be calculating RA inside astropy? and not >> switching between ephem and astropy? >> >> >> I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the >> code for the above sun web page( >> http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like >> to avoid coding that all up in python. >> >> If anyone has any advise i'm all ears. >> >> kind regards >> >> >> Orfeo >> >> >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > > -- > Erik -- Erik From demitri.muna at gmail.com Wed Sep 11 12:08:48 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Wed, 11 Sep 2013 12:08:48 -0400 Subject: [AstroPy] X marks the spot In-Reply-To: References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> Message-ID: <7B9A09C7-F74D-4CC9-99F4-B73FD7C2E95E@gmail.com> On Sep 11, 2013, at 7:35 AM, Christoph Deil wrote: > Installing GUI packages is always a daunting task, but becomes easy when using a package manager. Thanks for the directions. I know how to do that, but I'm not a fan of package managers. Most of the time installing something from source is just easy enough. I was burned many years ago by Fink, but I know that MacPorts is better and I've heard even better things about Homebrew (http://brew.sh). But I don't use any package managers on my Mac, and in particular I'd rather not have my Python installation be part of that either. I also have run into too many instances where the package was out of date compared to what I wanted to run. (On Linux, huge fan of package managers! But they're integral to the system.) Is ginga driven by Python, or simply written in Python/GTK (and or Qt)? Can it be distributed as a standalone, double-clickable application with static libraries? These links look promising: https://wiki.gnome.org/GTK+/OSX/Building https://wiki.gnome.org/GTK%2B/OSX/Bundling On Sep 10, 2013, at 9:04 PM, Erik Tollerud wrote: > That said, I think ginga is not necessarily what you want for this > application, as it is more for interactive image viewing/GUI interface > a la ds9 or atv. And it sounds like you want to instead make plots > (as you found, APLpy is probably the easiest there). Well, you know me. I want everything. :) Cheers, Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From magee at ucolick.org Wed Sep 11 12:19:18 2013 From: magee at ucolick.org (Daniel Magee) Date: Wed, 11 Sep 2013 09:19:18 -0700 Subject: [AstroPy] calculating Hour Angle to obtain Parallactic angle In-Reply-To: <10679715308F314F8C655A3568A532A22D84D805@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> References: <10679715308F314F8C655A3568A532A22D72F4D8@arborexmbx2.UTORARBOR.UTORAD.Utoronto.ca> <10679715308F314F8C655A3568A532A22D84D7E6@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca>, <10679715308F314F8C655A3568A532A22D84D805@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Message-ID: <3C3384CE-4E45-4652-876F-6A18E180D854@ucolick.org> Hi Orfeo, I wrote a Python module a few years back that you might find useful. It computes the airmass for a target throughout a give night (along with the HA, Parallactic angle, ?) for a give site/observatory. http://www.ucolick.org/~magee/observer/ It's dependent on the PyEphem (http://rhodesmill.org/pyephem/) module Cheers, Dan On Sep 11, 2013, at 8:45 AM, Orfeo Colebatch wrote: > Thanks Erik, > > You're spot on, thanks for the tips on converting the radians of ephem to the coord.Angle of astropy. The hour angle being returned is now matching the website. I just need to put it in decimal hours by dividing by 15 and i should be set to put it into Ian's Astro-Python Code ( http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle ) in order to calculate the hour angle. > > > Regrads > orfeo > > ps here's my code > > > import ephem > > from astropy import coordinates as coord > > from astropy.time import Time > > from astropy import units as u > > from datetime import datetime as dt > > def HA(): > > obs = ephem.Observer() > > time = dt.strptime('2013/10/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') > > obs.date = time > > obs.lon =ephem.degrees('-79.4') > > obs.lat = ephem.degrees('43.66') > > obs.elevation = 174.0 > > sun = ephem.Sun() > sun.compute(obs) > > ra = sun.g_ra > > c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) > > t = coord.Angle(obs.sidereal_time(),u.radian) > > t.lat = 43.66 > > t.lon =-79.4 > > ha = coord.angles.RA.hour_angle(c.ra,t) > > return ha > > if __name__ == '__main__': > print ' Calculated hour angle is ', HA() > > > > > > ________________________________________ > From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] > Sent: 11 September 2013 10:52 > To: Orfeo Colebatch > Cc: astropy at scipy.org > Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle > > Ah, that's your problem. As I think you've now surmised, the time > that goes into `hour_angle` is the Local Sidereal Time, *not* the > local time. Given that you're already using pyephem, the easiest > thing is to just use the Observer.sidereal_time method. (E.g., > obs.sidereal_time() ) in your example. > > One other thing you should know, though: pyephem uses radians for > essentially everything. So in you're example, when you do e.g., > ``obs.lon =-79.4``, pyephem is treating that is -79.4 radians, not > degrees. I think you can use strings somehow to tell it to use > degrees, but you'll have to look more closely at the documentation, as > I don't remember exactly how that works. Regardless, though, > `obs.sidereal_time` will probably give you radians out, so you'll need > to do something like ``t = coord.Angle(obs.sidereal_time(), > u.radian)`` to make sure the units work out. > > On Wed, Sep 11, 2013 at 10:32 AM, Orfeo Colebatch > wrote: >> Thanks Erik and Tim, >> >> >> I forgot to include the t object definition. I used the astropy.time module to set >> >> t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') >> >> I wasn't sure if i needed to set this time (t) to Toronto Canada time (UTC-4 currently) but i thought as long as i used the actual UTC time which corresponds to 09:00:00 Toronto time that would be ok. I corrected my code below (also changed the ephem time to 13:00:00). Still no change in the Hour Angle. >> >> >> I'm looking into sidereal time now as that looks like it's probably the cause, my vague understanding of LST is that i need to correct my Local time (or UTC) by the longitude i sit at (Toronto -79.4 W). >> >> Hopefully i can figure this out but if you have any further pointers i'm all ears. >> >> Regards >> orfeo >> >> >> >> >> >> >> import ephem >> >> from astropy import coordinates as coord >> >> from astropy.time import Time >> >> from astropy import units as u >> >> from datetime import datetime as dt >> >> def HA(): >> obs = ephem.Observer() >> >> time = dt.strptime('2013/6/21' +' ' + '13:00:00', '%Y/%m/%d %H:%M:%S') >> >> obs.date = time >> >> obs.lon =-79.4 >> >> lat = 43.66 >> >> obs.elevation = 174.0 >> >> sun = ephem.Sun() >> >> sun.compute(obs) >> >> ra = sun.g_ra >> >> c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, u.radian)) >> >> t = Time('2013-06-21 13:00:00', format = 'iso', scale = 'utc') >> >> t.lat = 43.66 >> >> t.lon =-79.4 >> >> ha = coord.angles.RA.hour_angle(c.ra,t) >> >> return ha >> >> >> if __name__== '__main__': >> print 'Calculating Hour Angle as ', HA() >> >> >> -------------------------------------------- >> >> In [1]: import ha_astropy >> >> In [2]: ha_astropy.HA() >> Out[2]: >> >> >> >> >> >> >> >> >> >> ________________________________________ >> From: etollerud at gmail.com [etollerud at gmail.com] on behalf of Erik Tollerud [erik.tollerud at gmail.com] >> Sent: 10 September 2013 21:00 >> To: Orfeo Colebatch; astropy at scipy.org >> Subject: Re: [AstroPy] calculating Hour Angle to obtain Parallactic angle >> >> This example seems to be incomplete, because I can't see where `t` is >> defined. That's important, because `hour_angle` doesn't compute >> sidereal time based on location, it just accepts and LST and gives you >> out an hour angle. Are you perhaps missing a line somewhere above? >> >> On Tue, Sep 10, 2013 at 2:14 PM, Orfeo Colebatch >> wrote: >>> Hi All, >>> >>> We have a alt/az sun tracker whose coding requires the calculation of the >>> parallactic angle in order to do some coordinate transformations between the >>> alt/az mount and a camera monitoring the image it produces. >>> >>> I have found Ian's Astro Python code >>> (http://www.mpia-hd.mpg.de/homes/ianc/python/_modules/spec.html#parangle) >>> which works when i use it conjunction with the coordinates output by this >>> site (http://www.jgiesen.de/astro/suncalc/) when the Hour Angle is converted >>> to decimal hours. >>> >>> I have tried to calculate the same hour angle using >>> coordinates.angles.RA.hour_angle (among other codes) bu have not been able >>> to reproduce that Hour Angle (HA) from the above site. >>> >>> E.g for 21st June 2013, 13:00 UTC (9:00 GMT-4), 43.66 deg latitude, -79.4 W >>> longitude I get a HA of -64.73 degreees (or +295 degrees) >>> >>> >>> By doing the following in python with ephem and astropy i get the following >>> >>> >>> In [1]: import ephem >>> >>> In [2]: from astropy import coordinates as coord >>> >>> In [3]: from astropy.time import Time >>> >>> In [4]: from astropy import units as u >>> >>> In [5]: obs = ephem.Observer() >>> >>> In [6]: from datetime import datetime as dt >>> >>> In [7]: time = dt.strptime('2013/6/21' +' ' + '09:00:00', '%Y/%m/%d >>> %H:%M:%S') >>> >>> In [8]: obs.date = time >>> >>> In [9]: obs.lon =-79.4 >>> >>> In [10]: obs.lat = 43.66 >>> >>> In [11]: obs.elevation = 174.0 >>> >>> In [12]: sun = ephem.Sun() >>> >>> In [13]: sun.compute(obs) >>> >>> In [14]: ra = sun.g_ra >>> >>> In [15]: ra >>> Out[15]: 1.573768747713852 >>> >>> In [16]: coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >>> u.radian)) >>> Out[16]: >>> >>> In [17]: c= coord.ICRSCoordinates(ra=ra, dec = sun.dec, unit=(u.radian, >>> u.radian >>> )) >>> >>> In [18]: c >>> Out[18]: >>> >>> In [19]: c.ra >>> Out[19]: >>> >>> In [20]: sun.ra >>> Out[20]: 1.573725506944724 >>> >>> In [21: c.ra * ephem.pi/180 >>> Out[21]: >>> >>> In [22]: c.ra >>> Out[22]: >>> >>> In [23]: coord.angles.RA.hour_angle(c.ra,t) >>> Out[23]: >>> >>> In [24]: t.lat = 43.66 >>> >>> In [25]: t.lon =-79.4 >>> >>> In [26]: coord.angles.RA.hour_angle(c.ra,t) >>> Out[26]: >>> >>> >>> >>> As you can see the angle is off by 20 degrees. I know this must be a unit >>> problem, but i'm not sure what as of yet. If anyone has any idea's i'd be >>> interested. Perhaps i should be calculating RA inside astropy? and not >>> switching between ephem and astropy? >>> >>> >>> I do have access to this IDL code (http://idlastro.gsfc.nasa.gov/) and the >>> code for the above sun web page( >>> http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html) but i would like >>> to avoid coding that all up in python. >>> >>> If anyone has any advise i'm all ears. >>> >>> kind regards >>> >>> >>> Orfeo >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> >> >> >> -- >> Erik > > > > -- > Erik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > !DSPAM:424,5230903518667127246057! > From tim.staley at soton.ac.uk Thu Sep 12 04:30:11 2013 From: tim.staley at soton.ac.uk (Tim Staley) Date: Thu, 12 Sep 2013 09:30:11 +0100 Subject: [AstroPy] X marks the spot In-Reply-To: <7B9A09C7-F74D-4CC9-99F4-B73FD7C2E95E@gmail.com> References: <3FDAF0B9-E676-48C0-AAD1-929DEAA862B4@gmail.com> <00F4DDD1-8432-4BBB-A314-FBA156FF3F2C@gmail.com> <7B9A09C7-F74D-4CC9-99F4-B73FD7C2E95E@gmail.com> Message-ID: <52317B93.4000608@soton.ac.uk> Hi astropy folks! just to throw another option in the works: if you want an interactive viewer (rather than a static plotter), you might consider using ds9 / xpa / pyds9 (+pyds9_ex if you're so inclined): http://hea-www.harvard.edu/RD/ds9/site/Home.html http://hea-www.harvard.edu/RD/xpa/index.html http://hea-www.harvard.edu/RD/ds9/pyds9/ https://github.com/timstaley/pyds9_ex I've no experience with Macs, but happy to help re: DS9 if I can. Cheers, Tim. On 11/09/13 17:08, Demitri Muna wrote: > > On Sep 11, 2013, at 7:35 AM, Christoph Deil > > > wrote: > >> Installing GUI packages is always a daunting task, but becomes easy >> when using a package manager. > > Thanks for the directions. I know how to do that, but I'm not a fan of > package managers. Most of the time installing something from source is > just easy enough. I was burned many years ago by Fink, but I know that > MacPorts is better and I've heard even better things about Homebrew > (http://brew.sh). But I don't use any package managers on my Mac, and > in particular I'd rather not have my Python installation be part of > that either. I also have run into too many instances where the package > was out of date compared to what I wanted to run. (On Linux, huge fan > of package managers! But they're integral to the system.) > > Is ginga driven by Python, or simply written in Python/GTK (and or > Qt)? Can it be distributed as a standalone, double-clickable > application with static libraries? These links look promising: > > https://wiki.gnome.org/GTK+/OSX/Building > https://wiki.gnome.org/GTK%2B/OSX/Bundling > > On Sep 10, 2013, at 9:04 PM, Erik Tollerud > wrote: > >> That said, I think ginga is not necessarily what you want for this >> application, as it is more for interactive image viewing/GUI interface >> a la ds9 or atv. And it sounds like you want to instead make plots >> (as you found, APLpy is probably the easiest there). > > Well, you know me. I want everything. :) > > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From stsci.perry at gmail.com Mon Sep 16 15:38:04 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 16 Sep 2013 15:38:04 -0400 Subject: [AstroPy] astropy logo clothing now available Message-ID: <4F573FE1-2D94-4FE7-9635-DC7E1F1669F7@gmail.com> We've set up an online store for astropy logo clothing that can be reached through these urls: http://fashion.astropy.org http://shirts.astropy.org All items that are purchased result in 15% of the proceeds going to the astropy project (through the NumFOCUS foundation, which actually receives the funds). I'm trying to add extra non-clothing items (e.g., tote bags, computer backpacks/cases, hats, etc.) which hopefully will appear in a day or two. Also, if you are planning to attend the Astropy Coordination meeting, you may want to hold of on ordering anything right now. I believe there will be an attempt to arrange a group order beforehand. This online store is allowed to list up to 50 items, so if there are items you are interested in that aren't shown, please contact us and we will try to accommodate such requests (different colors count as a separate listing). Click on the logosportswear.com link at the upper left to see all that they carry. Perry From stsci.perry at gmail.com Mon Sep 16 16:58:46 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 16 Sep 2013 16:58:46 -0400 Subject: [AstroPy] astropy logo clothing now available In-Reply-To: <4F573FE1-2D94-4FE7-9635-DC7E1F1669F7@gmail.com> References: <4F573FE1-2D94-4FE7-9635-DC7E1F1669F7@gmail.com> Message-ID: <4FE942D5-A2B0-4879-BD9C-F83DB75687F2@gmail.com> Alas, it has been noticed that an error has crept into the logo that none of us reviewing it noticed. If it matters to you, hold off on any orders until we have it fixed (and I get new glasses). Who knows, maybe the defective ones will have enormous market value like similar coins and stamps :-) Thanks, Perry On Sep 16, 2013, at 3:38 PM, Perry Greenfield wrote: > We've set up an online store for astropy logo clothing that can be reached through these urls: > > http://fashion.astropy.org > http://shirts.astropy.org > > All items that are purchased result in 15% of the proceeds going to the astropy project (through the NumFOCUS foundation, which actually receives the funds). > > I'm trying to add extra non-clothing items (e.g., tote bags, computer backpacks/cases, hats, etc.) which hopefully will appear in a day or two. > > Also, if you are planning to attend the Astropy Coordination meeting, you may want to hold of on ordering anything right now. I believe there will be an attempt to arrange a group order beforehand. > > This online store is allowed to list up to 50 items, so if there are items you are interested in that aren't shown, please contact us and we will try to accommodate such requests (different colors count as a separate listing). Click on the logosportswear.com link at the upper left to see all that they carry. > > Perry > From shupe at ipac.caltech.edu Mon Sep 16 18:34:45 2013 From: shupe at ipac.caltech.edu (David Shupe) Date: Mon, 16 Sep 2013 15:34:45 -0700 Subject: [AstroPy] astropy logo clothing now available In-Reply-To: <4FE942D5-A2B0-4879-BD9C-F83DB75687F2@gmail.com> References: <4F573FE1-2D94-4FE7-9635-DC7E1F1669F7@gmail.com> <4FE942D5-A2B0-4879-BD9C-F83DB75687F2@gmail.com> Message-ID: Perry, OK, I'll bite (pun intentional). Is the error at the tail end of the snake? Doesn't the logo look cooler as a rattlesnake? Seems like a fortuitous error to me? :) Dave On Sep 16, 2013, at 1:58 PM, Perry Greenfield wrote: > Alas, it has been noticed that an error has crept into the logo that none of us reviewing it noticed. If it matters to you, hold off on any orders until we have it fixed (and I get new glasses). Who knows, maybe the defective ones will have enormous market value like similar coins and stamps :-) > > Thanks, Perry > > On Sep 16, 2013, at 3:38 PM, Perry Greenfield wrote: > >> We've set up an online store for astropy logo clothing that can be reached through these urls: >> >> http://fashion.astropy.org >> http://shirts.astropy.org >> >> All items that are purchased result in 15% of the proceeds going to the astropy project (through the NumFOCUS foundation, which actually receives the funds). >> >> I'm trying to add extra non-clothing items (e.g., tote bags, computer backpacks/cases, hats, etc.) which hopefully will appear in a day or two. >> >> Also, if you are planning to attend the Astropy Coordination meeting, you may want to hold of on ordering anything right now. I believe there will be an attempt to arrange a group order beforehand. >> >> This online store is allowed to list up to 50 items, so if there are items you are interested in that aren't shown, please contact us and we will try to accommodate such requests (different colors count as a separate listing). Click on the logosportswear.com link at the upper left to see all that they carry. >> >> Perry >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ---- David Shupe NASA Herschel Science Center, IPAC, Caltech 1200 E. California Blvd, Pasadena, CA 91125 USA 1-626-395-2357 From ma.stranger at o2.co.uk Mon Sep 23 08:11:22 2013 From: ma.stranger at o2.co.uk (Morris Stranger) Date: Mon, 23 Sep 2013 13:11:22 +0100 Subject: [AstroPy] help with i2py software Message-ID: <1E0CC95D-0BEB-437D-ACC0-CBE40A6CA590@o2.co.uk> I'm having trouble using the i2py software. I have very little knowledge of computers (mainly just using my computer for the internet and downloading simple files). I am saying this because when someone gave me help last time, whilst I was very grateful, he was instructing me to do things that were beyond my knowledge. I want to get the i2py software working as a translator on my computer. My knowledge of python isn't very good either (I know how to make simple programs and how to work a bit with Numpy but nothing fancy). I downloaded the software from this link: http://code.google.com/p/i2py/downloads/detail?name=i2py-0.1.0.zip&can=2&q= and I got a folder of files but I don't know beyond that how to get the IDl2python translator up and running. I would be very grateful if someone could help me with this. Thank You, Morris Stranger From stsci.perry at gmail.com Mon Sep 23 14:16:25 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 23 Sep 2013 14:16:25 -0400 Subject: [AstroPy] astropy fashion update Message-ID: <7DE7A485-40E7-48B6-A66B-0B01510ED67A@gmail.com> A fixed logo has been applied to the previous items listed, and now there are some additional ones (in particular, women's clothing, hats, tote bag, and ipad case). Order away. Suggestions for additional items welcome (or better colors). Perry From jslavin at cfa.harvard.edu Mon Sep 23 15:12:00 2013 From: jslavin at cfa.harvard.edu (Slavin, Jonathan) Date: Mon, 23 Sep 2013 15:12:00 -0400 Subject: [AstroPy] help with i2py software (Morris Stranger) Message-ID: Morris, As far as I know, i2py is an abandoned project. I think it only worked partially even when it was maintained. Ouf of curiosity, which IDL programs did you want to convert to python? If you're familiar with IDL but not so much with python, converting IDL programs to python is a good way learn it. Jon Message: 1 > Date: Mon, 23 Sep 2013 13:11:22 +0100 > From: Morris Stranger > Subject: [AstroPy] help with i2py software > To: astropy at scipy.org > Message-ID: <1E0CC95D-0BEB-437D-ACC0-CBE40A6CA590 at o2.co.uk> > Content-Type: text/plain; charset=us-ascii > > > > I'm having trouble using the i2py software. I have very little knowledge > of computers (mainly just using my computer for the internet and > downloading simple files). I am saying this because when someone gave me > help last time, whilst I was very grateful, he was instructing me to do > things that were beyond my knowledge. I want to get the i2py software > working as a translator on my computer. My knowledge of python isn't very > good either (I know how to make simple programs and how to work a bit with > Numpy but nothing fancy). I downloaded the software from this link: > http://code.google.com/p/i2py/downloads/detail?name=i2py-0.1.0.zip&can=2&q= > and I got a folder of files but I don't know beyond that how to get the > IDl2python translator up and running. I would be very grateful if someone > could help me with this. > > Thank You, > > Morris Stranger > -- ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 fax: (617) 496-7577 USA ________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thoger.emil at gmail.com Mon Sep 23 16:37:46 2013 From: thoger.emil at gmail.com (=?ISO-8859-1?Q?Th=F8ger_Emil_Rivera-Thorsen?=) Date: Mon, 23 Sep 2013 22:37:46 +0200 Subject: [AstroPy] help with i2py software (Morris Stranger) In-Reply-To: References: Message-ID: <5240A69A.20905@gmail.com> I second that! There is even a page, Numpy for IDL Users (https://www.cfa.harvard.edu/~jbattat/computer/python/science/idl-numpy.html ), that shows a lot of function and command equivalences between the two languages. When I wrote my Master's degree thesis, my supervisor gave me some IDL scripts and told me to "read them, understand them and then run them". I took that as my chance to learn python, so I re-wrote them in Python, and ran both the IDL and python versions and checked that they gace identical results - which was actually a great jumpstart to python coding. I have never regretted it - in fact it took me only two or three weeks before I could do as much in Python as I could in IDL, plus some plotting stuff that was much easier in Python. On 23-09-2013 21:12, Slavin, Jonathan wrote: > Morris, > > As far as I know, i2py is an abandoned project. I think it only > worked partially even when it was maintained. Ouf of curiosity, which > IDL programs did you want to convert to python? If you're familiar > with IDL but not so much with python, converting IDL programs to > python is a good way learn it. > > Jon > > Message: 1 > Date: Mon, 23 Sep 2013 13:11:22 +0100 > From: Morris Stranger > > Subject: [AstroPy] help with i2py software > To: astropy at scipy.org > Message-ID: <1E0CC95D-0BEB-437D-ACC0-CBE40A6CA590 at o2.co.uk > > > Content-Type: text/plain; charset=us-ascii > > > > I'm having trouble using the i2py software. I have very little > knowledge of computers (mainly just using my computer for the > internet and downloading simple files). I am saying this because > when someone gave me help last time, whilst I was very grateful, > he was instructing me to do things that were beyond my knowledge. > I want to get the i2py software working as a translator on my > computer. My knowledge of python isn't very good either (I know > how to make simple programs and how to work a bit with Numpy but > nothing fancy). I downloaded the software from this link: > http://code.google.com/p/i2py/downloads/detail?name=i2py-0.1.0.zip&can=2&q= > and I got a folder of files but I don't know beyond that how to > get the IDl2python translator up and running. I would be very > grateful if someone could help me with this. > > Thank You, > > Morris Stranger > > -- > ________________________________________________________ > Jonathan D. Slavin Harvard-Smithsonian CfA > jslavin at cfa.harvard.edu 60 Garden > Street, MS 83 > phone: (617) 496-7981 Cambridge, MA 02138-1516 > fax: (617) 496-7577 USA > ________________________________________________________ > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From cchayward at gmail.com Mon Sep 23 17:29:35 2013 From: cchayward at gmail.com (Chris Hayward) Date: Mon, 23 Sep 2013 23:29:35 +0200 Subject: [AstroPy] help with i2py software (Morris Stranger) In-Reply-To: <5240A69A.20905@gmail.com> References: <5240A69A.20905@gmail.com> Message-ID: It's also worth noting that you can read IDL save files using scipy.io.readsav ( http://docs.scipy.org/doc/scipy/reference/generated/scipy.io.readsav.html). This is useful if, for example, you have a legacy IDL pipeline that produces some output that you then wish to analyze further using Python. If I intend to continue using an IDL script frequently, I convert it to Python, but if it's not worth converting, I use this save file approach to 'patch' together IDL and Python. Cheers, Chris On Mon, Sep 23, 2013 at 10:37 PM, Th?ger Emil Rivera-Thorsen < thoger.emil at gmail.com> wrote: > I second that! > > There is even a page, Numpy for IDL Users ( > https://www.cfa.harvard.edu/~jbattat/computer/python/science/idl-numpy.html), > that shows a lot of function and command equivalences between the two > languages. When I wrote my Master's degree thesis, my supervisor gave me > some IDL scripts and told me to "read them, understand them and then run > them". I took that as my chance to learn python, so I re-wrote them in > Python, and ran both the IDL and python versions and checked that they gace > identical results - which was actually a great jumpstart to python coding. > I have never regretted it - in fact it took me only two or three weeks > before I could do as much in Python as I could in IDL, plus some plotting > stuff that was much easier in Python. > > > On 23-09-2013 21:12, Slavin, Jonathan wrote: > > Morris, > > As far as I know, i2py is an abandoned project. I think it only worked > partially even when it was maintained. Ouf of curiosity, which IDL > programs did you want to convert to python? If you're familiar with IDL > but not so much with python, converting IDL programs to python is a good > way learn it. > > Jon > > Message: 1 >> Date: Mon, 23 Sep 2013 13:11:22 +0100 >> From: Morris Stranger >> Subject: [AstroPy] help with i2py software >> To: astropy at scipy.org >> Message-ID: <1E0CC95D-0BEB-437D-ACC0-CBE40A6CA590 at o2.co.uk> >> Content-Type: text/plain; charset=us-ascii >> >> >> >> I'm having trouble using the i2py software. I have very little knowledge >> of computers (mainly just using my computer for the internet and >> downloading simple files). I am saying this because when someone gave me >> help last time, whilst I was very grateful, he was instructing me to do >> things that were beyond my knowledge. I want to get the i2py software >> working as a translator on my computer. My knowledge of python isn't very >> good either (I know how to make simple programs and how to work a bit with >> Numpy but nothing fancy). I downloaded the software from this link: >> http://code.google.com/p/i2py/downloads/detail?name=i2py-0.1.0.zip&can=2&q= >> and I got a folder of files but I don't know beyond that how to get the >> IDl2python translator up and running. I would be very grateful if someone >> could help me with this. >> >> Thank You, >> >> Morris Stranger >> > -- > ________________________________________________________ > Jonathan D. Slavin Harvard-Smithsonian CfA > jslavin at cfa.harvard.edu 60 Garden Street, MS 83 > phone: (617) 496-7981 Cambridge, MA 02138-1516 > fax: (617) 496-7577 USA > ________________________________________________________ > > > > _______________________________________________ > AstroPy mailing listAstroPy at scipy.orghttp://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Chris Hayward Heidelberger Institut f?r Theoretische Studien Schloss-Wolfsbrunnenweg 35 69118 Heidelberg, Germany Google Voice: +1 (617) 744-9416 Office: +49 6221 533 284 Fax: +49 6221 533 298 http://www.cfa.harvard.edu/~chayward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcraig at mnstate.edu Mon Sep 23 23:26:17 2013 From: mcraig at mnstate.edu (Matthew Craig) Date: Mon, 23 Sep 2013 22:26:17 -0500 Subject: [AstroPy] astropy fashion update In-Reply-To: <7DE7A485-40E7-48B6-A66B-0B01510ED67A@gmail.com> References: <7DE7A485-40E7-48B6-A66B-0B01510ED67A@gmail.com> Message-ID: What is the fashion Web site again? Matt Craig ---- Professor Department of Physics and Astronomy Minnesota State University Moorhead On Sep 23, 2013, at 1:16 PM, Perry Greenfield wrote: > A fixed logo has been applied to the previous items listed, and now there are some additional ones (in particular, women's clothing, hats, tote bag, and ipad case). Order away. > > Suggestions for additional items welcome (or better colors). > > Perry > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From thomas.robitaille at gmail.com Tue Sep 24 03:03:47 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 24 Sep 2013 09:03:47 +0200 Subject: [AstroPy] astropy fashion update In-Reply-To: References: <7DE7A485-40E7-48B6-A66B-0B01510ED67A@gmail.com> Message-ID: The URL of the store is http://fashion.astropy.org Cheers, Tom On 24 September 2013 05:26, Matthew Craig wrote: > What is the fashion Web site again? > > Matt Craig > > ---- > Professor > Department of Physics and Astronomy > Minnesota State University Moorhead > > > On Sep 23, 2013, at 1:16 PM, Perry Greenfield wrote: > >> A fixed logo has been applied to the previous items listed, and now there are some additional ones (in particular, women's clothing, hats, tote bag, and ipad case). Order away. >> >> Suggestions for additional items welcome (or better colors). >> >> 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 From adam.ginsburg at colorado.edu Tue Sep 24 14:23:32 2013 From: adam.ginsburg at colorado.edu (Adam Ginsburg) Date: Tue, 24 Sep 2013 12:23:32 -0600 Subject: [AstroPy] Changing dimensionality of WCS Message-ID: When working with data cubes, I often need to extract WCS information for 1 or 2 of the WCS dimensions. The docs (http://docs.astropy.org/en/latest/wcs/index.html) give decent examples of how to generate a WCS from scratch, but I don't see any obvious way to extract a lower-dimensional WCS from a WCS. Does such functionality exist? If not, does it make sense to generate a WCS from scratch and copy over just the relevant parameters? The use cases I have in mind: - extract position-only information from a data cube - extract spectral-only information from a data cube - extract position-velocity from a data cube, where position may be arbitrary - or position may be any standard projection (RA---TAN, for example) The last case, in particular, I don't actually know how to do - is it possible to create a WCS axis that is not one of the built in / allowed sky projections? -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From d.berry at jach.hawaii.edu Tue Sep 24 14:49:05 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 24 Sep 2013 19:49:05 +0100 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: References: Message-ID: On 24 September 2013 19:23, Adam Ginsburg wrote: > When working with data cubes, I often need to extract WCS information > for 1 or 2 of the WCS dimensions. The docs > (http://docs.astropy.org/en/latest/wcs/index.html) give decent > examples of how to generate a WCS from scratch, but I don't see any > obvious way to extract a lower-dimensional WCS from a WCS. Does such > functionality exist? If not, does it make sense to generate a WCS > from scratch and copy over just the relevant parameters? This is an example of the general problem - given two arbitrary coordinate systems, one with N axes and one with M axes, is there a transformation between them, and if so, what is it? It is addressed in pyast by the "convert" method. If you need ideas for an API see http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html Implementing this sort of feature in a general way is tricky but can be done. For simpler cases where you just want to pick a specified subset or superset of axes from a coordinate system, pyast uses "pickaxes". See http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html I know pyast is not astropy, but I point these out in case ideas are need for how to approach these issues. David From jturner at gemini.edu Tue Sep 24 16:06:50 2013 From: jturner at gemini.edu (James Turner) Date: Tue, 24 Sep 2013 17:06:50 -0300 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: References: Message-ID: <5241F0DA.8030307@gemini.edu> I don't know the answer re. astropy.wcs but it would be good if one could ultimately slice an nddata object and have the dimensionality and WCS reduced automatically if applicable (a bit like in IRAF but, hopefully, better) :-). It seems that an NDData can already be sliced directly but "support for WCS and units is not yet implemented". Maybe some more WCS manipulation routines are needed first... Cheers, James. On 24/09/13 15:49, David Berry wrote: > On 24 September 2013 19:23, Adam Ginsburg wrote: >> When working with data cubes, I often need to extract WCS information >> for 1 or 2 of the WCS dimensions. The docs >> (http://docs.astropy.org/en/latest/wcs/index.html) give decent >> examples of how to generate a WCS from scratch, but I don't see any >> obvious way to extract a lower-dimensional WCS from a WCS. Does such >> functionality exist? If not, does it make sense to generate a WCS >> from scratch and copy over just the relevant parameters? > > This is an example of the general problem - given two arbitrary > coordinate systems, one with N axes and one with M axes, is there a > transformation between them, and if so, what is it? It is addressed in > pyast by the "convert" method. If you need ideas for an API see > > http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html > > Implementing this sort of feature in a general way is tricky but can > be done. For simpler cases where you just want to pick a specified > subset or superset of axes from a coordinate system, pyast uses > "pickaxes". See > > http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html > > I know pyast is not astropy, but I point these out in case ideas are > need for how to approach these issues. > > David > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From stsci.perry at gmail.com Tue Sep 24 16:14:44 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Tue, 24 Sep 2013 16:14:44 -0400 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: <5241F0DA.8030307@gemini.edu> References: <5241F0DA.8030307@gemini.edu> Message-ID: Keep in mind that something like this will only work if the coordinates being sliced are separable. For example, if the WCS involve a rotation of x,y, it doesn't make much sense to extract the wcs for x only since it requires as input both coordinates. Given that, I'm not sure slicing is a good approach. This would need some careful thought as far as a user interface goes (sure, you can raise an exception when it doesn't work, but is there a simple way to see what coordinates are coupled?) Perry On Sep 24, 2013, at 4:06 PM, James Turner wrote: > I don't know the answer re. astropy.wcs but it would be good if > one could ultimately slice an nddata object and have the > dimensionality and WCS reduced automatically if applicable (a bit > like in IRAF but, hopefully, better) :-). It seems that an NDData > can already be sliced directly but "support for WCS and units is > not yet implemented". Maybe some more WCS manipulation routines > are needed first... > > Cheers, > > James. > > > On 24/09/13 15:49, David Berry wrote: >> On 24 September 2013 19:23, Adam Ginsburg wrote: >>> When working with data cubes, I often need to extract WCS information >>> for 1 or 2 of the WCS dimensions. The docs >>> (http://docs.astropy.org/en/latest/wcs/index.html) give decent >>> examples of how to generate a WCS from scratch, but I don't see any >>> obvious way to extract a lower-dimensional WCS from a WCS. Does such >>> functionality exist? If not, does it make sense to generate a WCS >>> from scratch and copy over just the relevant parameters? >> >> This is an example of the general problem - given two arbitrary >> coordinate systems, one with N axes and one with M axes, is there a >> transformation between them, and if so, what is it? It is addressed in >> pyast by the "convert" method. If you need ideas for an API see >> >> http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html >> >> Implementing this sort of feature in a general way is tricky but can >> be done. For simpler cases where you just want to pick a specified >> subset or superset of axes from a coordinate system, pyast uses >> "pickaxes". See >> >> http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html >> >> I know pyast is not astropy, but I point these out in case ideas are >> need for how to approach these issues. >> >> David >> _______________________________________________ >> 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 jturner at gemini.edu Tue Sep 24 16:39:19 2013 From: jturner at gemini.edu (James Turner) Date: Tue, 24 Sep 2013 17:39:19 -0300 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: References: <5241F0DA.8030307@gemini.edu> Message-ID: <5241F877.8050807@gemini.edu> > Keep in mind that something like this will only work if the coordinates being sliced are separable. For example, if the WCS involve a rotation of x,y, it doesn't make much sense to extract the wcs for x only since it requires as input both coordinates. > > Given that, I'm not sure slicing is a good approach. This would need some careful thought as far as a user interface goes (sure, you can raise an exception when it doesn't work, but is there a simple way to see what coordinates are coupled?) Hmmm, yes, but it seems to me that the right behaviour is still well defined in that case (you have to keep any World co-ordinates that vary along the remaining axes, convert any dependence on axes that no longer exist into constants and update the zero points according to that and what subsections were used). Presumably you can scan the WCS coefficients to find out which axes each world co-ordinate depends on and I suppose if you eliminate an axis parallel to a World co-ordinate then you could retain that World co-ordinate as a constant value until asked to reduce it? Maybe I'm oversimplifying something but if I were to slice an nddata object and the WCS didn't get updated accordingly (like happens in IRAF, at least most of the time) I'd be disappointed! (I expect this will be relevant to our work at some point, so maybe I'll get to contribute something more than suggestions). That doesn't mean that slicing should be the only way to get a lower-dimensional WCS though. Cheers, James. > Perry > > On Sep 24, 2013, at 4:06 PM, James Turner wrote: > >> I don't know the answer re. astropy.wcs but it would be good if >> one could ultimately slice an nddata object and have the >> dimensionality and WCS reduced automatically if applicable (a bit >> like in IRAF but, hopefully, better) :-). It seems that an NDData >> can already be sliced directly but "support for WCS and units is >> not yet implemented". Maybe some more WCS manipulation routines >> are needed first... >> >> Cheers, >> >> James. >> >> >> On 24/09/13 15:49, David Berry wrote: >>> On 24 September 2013 19:23, Adam Ginsburg wrote: >>>> When working with data cubes, I often need to extract WCS information >>>> for 1 or 2 of the WCS dimensions. The docs >>>> (http://docs.astropy.org/en/latest/wcs/index.html) give decent >>>> examples of how to generate a WCS from scratch, but I don't see any >>>> obvious way to extract a lower-dimensional WCS from a WCS. Does such >>>> functionality exist? If not, does it make sense to generate a WCS >>>> from scratch and copy over just the relevant parameters? >>> >>> This is an example of the general problem - given two arbitrary >>> coordinate systems, one with N axes and one with M axes, is there a >>> transformation between them, and if so, what is it? It is addressed in >>> pyast by the "convert" method. If you need ideas for an API see >>> >>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html >>> >>> Implementing this sort of feature in a general way is tricky but can >>> be done. For simpler cases where you just want to pick a specified >>> subset or superset of axes from a coordinate system, pyast uses >>> "pickaxes". See >>> >>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html >>> >>> I know pyast is not astropy, but I point these out in case ideas are >>> need for how to approach these issues. >>> >>> David >>> _______________________________________________ >>> 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 d.berry at jach.hawaii.edu Tue Sep 24 17:03:08 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 24 Sep 2013 22:03:08 +0100 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: References: <5241F0DA.8030307@gemini.edu> Message-ID: On 24 September 2013 21:14, Perry Greenfield wrote: > Keep in mind that something like this will only work if the coordinates being sliced are separable. For example, if the WCS involve a rotation of x,y, it doesn't make much sense to extract the wcs for x only since it requires as input both coordinates. > > Given that, I'm not sure slicing is a good approach. This would need some careful thought as far as a user interface goes (sure, you can raise an exception when it doesn't work, but is there a simple way to see what coordinates are coupled?) There are two parts to the problem: 1) picking the axes from the coordinate system. This requires a way of identifying the axes to be picked, tacking into account the fact that they may potentially have been permuted (i.e. you may have (dec,ra) rather than (ra,dec), and they may be in some related system rather than actual system you want (i.e. (ra,dec) rather than (glon,glat)). Then some way is needed of extracting the picked axes into a new coordinate system, and then some way of creating a Mapping that describes how to get from the old frame to the new frame (pyast uses a "PermMap" ("permutation mapping")). 2) Modifying any mappings that exist between the original coordinate frame and any other related coordinate frames. For instance say you have two Frames - one describing 3D (x,y,z) pixel coords, and another describing (ra,dec,frequency) world coordinates with some suitable mapping between them, and you then extract a (x,y) slice from the pixel array. You pick the (x,y) axes from the 3D pixel Frame to create a new 2D pixel frame as described in point 1) above, and likewise pick the (ra,dec) axes from the 3D WCS Frame to create a 2D WCS Frame. You then need to modify the original mapping between pixel and WCS so that instead of being 3D in and 3D out, it is 2D in and 2D out. If the axes are separable it's easy - you just need all Mapping classes to implement a method such as astMapSplit http://starlink.jach.hawaii.edu/docs/sun211.htx/node328.html. For non-seperable axes, you need to utilize the fact that you know the z value at which the slice was extracted, and create a mapping that will "feed in" that value for the missing axis in the original mapping. We use a PermMap for this - see http://starlink.jach.hawaii.edu/docs/sun211.htx/node347.html. David You use the fact that you know the Z value at which the slice was extracted > Perry > > On Sep 24, 2013, at 4:06 PM, James Turner wrote: > >> I don't know the answer re. astropy.wcs but it would be good if >> one could ultimately slice an nddata object and have the >> dimensionality and WCS reduced automatically if applicable (a bit >> like in IRAF but, hopefully, better) :-). It seems that an NDData >> can already be sliced directly but "support for WCS and units is >> not yet implemented". Maybe some more WCS manipulation routines >> are needed first... >> >> Cheers, >> >> James. >> >> >> On 24/09/13 15:49, David Berry wrote: >>> On 24 September 2013 19:23, Adam Ginsburg wrote: >>>> When working with data cubes, I often need to extract WCS information >>>> for 1 or 2 of the WCS dimensions. The docs >>>> (http://docs.astropy.org/en/latest/wcs/index.html) give decent >>>> examples of how to generate a WCS from scratch, but I don't see any >>>> obvious way to extract a lower-dimensional WCS from a WCS. Does such >>>> functionality exist? If not, does it make sense to generate a WCS >>>> from scratch and copy over just the relevant parameters? >>> >>> This is an example of the general problem - given two arbitrary >>> coordinate systems, one with N axes and one with M axes, is there a >>> transformation between them, and if so, what is it? It is addressed in >>> pyast by the "convert" method. If you need ideas for an API see >>> >>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html >>> >>> Implementing this sort of feature in a general way is tricky but can >>> be done. For simpler cases where you just want to pick a specified >>> subset or superset of axes from a coordinate system, pyast uses >>> "pickaxes". See >>> >>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html >>> >>> I know pyast is not astropy, but I point these out in case ideas are >>> need for how to approach these issues. >>> >>> David >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From adam.ginsburg at colorado.edu Tue Sep 24 21:03:16 2013 From: adam.ginsburg at colorado.edu (Adam Ginsburg) Date: Tue, 24 Sep 2013 19:03:16 -0600 Subject: [AstroPy] Changing dimensionality of WCS In-Reply-To: References: <5241F0DA.8030307@gemini.edu> Message-ID: Thanks for the replies, and I'm glad to see this discussion going. In terms of a somewhat generalized version of the problem, but not entirely general: is it possible, in the current implementation of wcs, to create a WCS axis that is a simple transformation of another? i.e., RA with a position angle? That would easily provide for most 2D slit spectra, which would be useful for specutils. I think that topic has been discussed elsewhere, though, perhaps with respect to modeling. For my current more specific case, I've found that at least APLpy will accept an "arbitrary" WCS axis, which is what I need for now. I'm dealing with a perhaps weird case where I want the spectra tracking arbitrary positions - a position velocity diagram along a filament. An example case is shown here: http://keflavich.github.io/pvextractor/examples/IRAS05358Slicing.html What I've done works, but I suspect there are better ways to do it. On the WCS side, I'm using the hack shown here: https://github.com/keflavich/pvextractor/blob/50b634484612b83f82169229faf11acceaadea93/pvextractor/pvwcs.py basically just copying over parameters that I think are important. On Tue, Sep 24, 2013 at 3:03 PM, David Berry wrote: > On 24 September 2013 21:14, Perry Greenfield wrote: >> Keep in mind that something like this will only work if the coordinates being sliced are separable. For example, if the WCS involve a rotation of x,y, it doesn't make much sense to extract the wcs for x only since it requires as input both coordinates. >> >> Given that, I'm not sure slicing is a good approach. This would need some careful thought as far as a user interface goes (sure, you can raise an exception when it doesn't work, but is there a simple way to see what coordinates are coupled?) > > There are two parts to the problem: > > 1) picking the axes from the coordinate system. This requires a way of > identifying the axes to be picked, tacking into account the fact that > they may potentially have been permuted (i.e. you may have (dec,ra) > rather than (ra,dec), and they may be in some related system rather > than actual system you want (i.e. (ra,dec) rather than (glon,glat)). > Then some way is needed of extracting the picked axes into a new > coordinate system, and then some way of creating a Mapping that > describes how to get from the old frame to the new frame (pyast uses a > "PermMap" ("permutation mapping")). > > 2) Modifying any mappings that exist between the original coordinate > frame and any other related coordinate frames. For instance say you > have two Frames - one describing 3D (x,y,z) pixel coords, and another > describing (ra,dec,frequency) world coordinates with some suitable > mapping between them, and you then extract a (x,y) slice from the > pixel array. You pick the (x,y) axes from the 3D pixel Frame to create > a new 2D pixel frame as described in point 1) above, and likewise pick > the (ra,dec) axes from the 3D WCS Frame to create a 2D WCS Frame. You > then need to modify the original mapping between pixel and WCS so that > instead of being 3D in and 3D out, it is 2D in and 2D out. If the axes > are separable it's easy - you just need all Mapping classes to > implement a method such as astMapSplit > http://starlink.jach.hawaii.edu/docs/sun211.htx/node328.html. For > non-seperable axes, you need to utilize the fact that you know the z > value at which the slice was extracted, and create a mapping that will > "feed in" that value for the missing axis in the original mapping. We > use a PermMap for this - see > http://starlink.jach.hawaii.edu/docs/sun211.htx/node347.html. > > David > > > You use the fact that you know the Z value at which the slice was extracted > > > >> Perry >> >> On Sep 24, 2013, at 4:06 PM, James Turner wrote: >> >>> I don't know the answer re. astropy.wcs but it would be good if >>> one could ultimately slice an nddata object and have the >>> dimensionality and WCS reduced automatically if applicable (a bit >>> like in IRAF but, hopefully, better) :-). It seems that an NDData >>> can already be sliced directly but "support for WCS and units is >>> not yet implemented". Maybe some more WCS manipulation routines >>> are needed first... >>> >>> Cheers, >>> >>> James. >>> >>> >>> On 24/09/13 15:49, David Berry wrote: >>>> On 24 September 2013 19:23, Adam Ginsburg wrote: >>>>> When working with data cubes, I often need to extract WCS information >>>>> for 1 or 2 of the WCS dimensions. The docs >>>>> (http://docs.astropy.org/en/latest/wcs/index.html) give decent >>>>> examples of how to generate a WCS from scratch, but I don't see any >>>>> obvious way to extract a lower-dimensional WCS from a WCS. Does such >>>>> functionality exist? If not, does it make sense to generate a WCS >>>>> from scratch and copy over just the relevant parameters? >>>> >>>> This is an example of the general problem - given two arbitrary >>>> coordinate systems, one with N axes and one with M axes, is there a >>>> transformation between them, and if so, what is it? It is addressed in >>>> pyast by the "convert" method. If you need ideas for an API see >>>> >>>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node245.html >>>> >>>> Implementing this sort of feature in a general way is tricky but can >>>> be done. For simpler cases where you just want to pick a specified >>>> subset or superset of axes from a coordinate system, pyast uses >>>> "pickaxes". See >>>> >>>> http://starlink.jach.hawaii.edu/docs/sun211.htx/node348.html >>>> >>>> I know pyast is not astropy, but I point these out in case ideas are >>>> need for how to approach these issues. >>>> >>>> David >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From demitri.muna at gmail.com Wed Sep 25 16:35:55 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Wed, 25 Sep 2013 16:35:55 -0400 Subject: [AstroPy] PyCharm IDE is now free Message-ID: Hi, I've never used this before, but thought I'd post the news here. The PyCharm IDE is now open source (and of course, free). http://www.jetbrains.com/pycharm/ Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ From leo.huckvale at postgrad.manchester.ac.uk Mon Sep 30 10:22:41 2013 From: leo.huckvale at postgrad.manchester.ac.uk (Leo Huckvale) Date: Mon, 30 Sep 2013 16:22:41 +0200 Subject: [AstroPy] astropy fashion update Message-ID: <52498931.9090307@postgrad.manchester.ac.uk> Regarding suggestions for astropy merchandise, have you thought of coffee mugs? Regards, Leo Huckvale From stsci.perry at gmail.com Mon Sep 30 10:50:40 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 30 Sep 2013 10:50:40 -0400 Subject: [AstroPy] astropy fashion update In-Reply-To: <52498931.9090307@postgrad.manchester.ac.uk> References: <52498931.9090307@postgrad.manchester.ac.uk> Message-ID: <5FBD727F-6236-4ACE-B877-493D131707C4@gmail.com> We've looked as stickers a bit, but not mugs. I think we'll want to see the level of interest in the clothing before expanding our retail project :-) On Sep 30, 2013, at 10:22 AM, Leo Huckvale wrote: > Regarding suggestions for astropy merchandise, have you thought of > coffee mugs? > > Regards, > Leo Huckvale > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy