From mjuric at lsst.org Sun Nov 2 01:33:40 2014 From: mjuric at lsst.org (Mario Juric) Date: Sat, 01 Nov 2014 23:33:40 -0700 Subject: [AstroPy] Job ad: LSST software lead @ U. Washington (research faculty) Message-ID: <5455D044.7020903@lsst.org> Hi everyone, I wanted to bring to your attention a search (at the research faculty level) for the lead of the Large Synoptic Survey Telescope (LSST) data pipelines effort at the University of Washington: https://jobregister.aas.org/node/49445 The ad itself is pasted below; I hope you find it interesting! PS: Also as a heads up -- LSST will be hiring about a ~dozen more people in the coming ~1-2 years (@ UW, Princeton, NCSA, SLAC, and LSST HQ in Tucson) to develop various (open source, Python/C++) LSST toolkits and processing pipelines. If you're interested in software for large surveys, keep an eye on http://lsst.org/hiring. Thanks (and do feel free to e-mail me with any questions!), - Mario ======== Research Assistant or Research Associate Professor of Astronomy, University of Washington - JRID49445 The Large Synoptic Survey Telescope (LSST) is a planned, large-aperture, wide-field, ground-based telescope that will survey half the sky every few nights in six optical bands. It will create the world's first high-definition movie of the universe, detect hazardous asteroids, help uncover the mysteries of dark energy and dark matter, and more. With an 8-meter class telescope, a 3.2 gigapixel camera with a 2-second readout, and a state-of-the-art petascale data management system, the LSST will process, archive, and distribute over 15 TB of data produced every night. Once completed, the LSST will be the largest and most modern optical survey project ever built. The LSST Data Management system will be constructed by a team of about 50 members residing at partner institutions across the United States and Chile. It will include a data processing system spanning two continents, new state-of-the-art image processing algorithms, petascale computing clusters with tens of thousands of cores, large distributed databases, and next-generation analysis toolkits, among others. All LSST DM code is free software (GPL v3), written in modern Python and C++. The University of Washington (UW) LSST team is responsible for the development of the algorithms and software that will analyze this nightly data stream (including the detection and characterization of transients, variables, and moving sources). To support this work at UW, we are soliciting applications for the position of Research Assistant or Research Associate Professor in the Department of Astronomy. University of Washington faculty engage in teaching, research and service. The successful candidate will lead the LSST data management group at UW, and is expected to play a leading role in the development of the software for the nightly processing of the LSST data (including, but not limited to, the development of algorithms for image subtraction, the detection of transient and variable sources, and the characterization of transient and variable sources) and the application of the LSST Data Management system to simulated and precursor survey data. Pending appointment renewal, external funding to help support the position is anticipated to be available for up to the duration of LSST construction (8 years), with the potential opportunity for continuation into Survey Operations (10 years). The ideal candidate is an astronomer with strong interest in large surveys, hands-on experience with development of astronomical software, and the potential to lead a highly skilled team. A PhD in physics, astronomy, computer science or a related field is required. Strong C++ and Python skills, and experience with the development and application of image subtraction techniques to large astronomical surveys is preferred. Please send a statement of professional interests, CV, bibliography, and the names of at least three people who may be contacted for letters of reference. Application reviews will begin immediately, and continue through November 30, 2014 or until the position is filled. Documents will be accepted electronically in a single pdf file sent to the attention of Mario Juric, search committee chair, at mjuric at astro.washington.edu, with subject line "research faculty application (your name)". The University of Washington is proud to be one of the nation's premier educational and research institutions. Our people are the most important asset in our pursuit of achieving excellence in education, research, and community service. Our staff not only enjoys outstanding benefits and professional growth opportunities, but also an environment noted for diversity, community involvement, intellectual excitement, artistic pursuits, and natural beauty. The University of Washington is an affirmative action and equal opportunity employer. All qualified applicants will receive consideration for employment without regard to, among other things, race, religion, color, national origin, sex, age, status as protected veterans, or status as qualified individuals with disabilities ======== -- Mario Juric, UW Astronomy Faculty | UW eScience | LSST DM Project Scientist Web : http://research.majuric.org Phone : +1 609 933 1033 From thomas.robitaille at gmail.com Mon Nov 3 09:03:46 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 3 Nov 2014 15:03:46 +0100 Subject: [AstroPy] Apply now for the Python in Astronomy Lorentz workshop! (20-24th April 2015) Message-ID: Dear colleagues, We are very pleased to inform you that applications are now open for the Lorentz Center workshop on: Python in Astronomy Lorentz Center, Leiden 20-24th April 2015 http://python-in-astronomy.github.io This workshop aims to bring together researchers, Python developers, users, and educators, and will include presentations, tutorials, unconference sessions, and coding sprints. In addition to sharing information about state-of-the art Python Astronomy packages, the workshop will also focus on improving interoperability between astronomical Python packages, providing training for new contributors, and developing a common set of educational materials for Python in Astronomy. The meeting is therefore aimed not only at current developers, but also users and educators who are interested in being involved in these efforts. To apply, please go to the following page: http://python-in-astronomy.github.io/ and follow the link to the application form. Applications should be submitted by 28th November 2014 at the latest, and we will let you know by mid-December whether you have been accepted. The workshop will be hosted by the Lorentz Center, which is an international center that coordinates and hosts workshops in the sciences, based on the philosophy that science thrives on interaction between creative researchers. In addition to being supported by the Lorentz center, this meeting is being sponsored by GitHub (http://www.github.com) and NumFOCUS (http://www.numfocus.org). We are thus able to offer financial support for travel for a few junior participants. If you would like to apply for financial support in order to attend the meeting, please indicate this in the last section of the application form. Please forward this email to anyone who may be interested, including Python or workshop announcement mailing lists! Best regards, Thomas Robitaille, on behalf of the organizing committee: Pauline Barmby Eric Jeschke Sarah Kendrew Stuart Mumford Magnus Persson Thomas Robitaille From martinberoiz at gmail.com Mon Nov 3 16:45:15 2014 From: martinberoiz at gmail.com (Martin Beroiz) Date: Mon, 3 Nov 2014 15:45:15 -0600 Subject: [AstroPy] WCS creation Message-ID: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> Hello everybody, I have an image for which I have the RA-Dec information for some sources along with the pixel location. From that info, I want to create a WCS object with astropy preferably. Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. Basically, I?m looking for a python equivalent of STARAST for IDL http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro Is there a built-in way to do this with astropy or affiliated package? Thanks for your help. M. From indiajoe at gmail.com Mon Nov 3 20:13:23 2014 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Tue, 4 Nov 2014 06:43:23 +0530 Subject: [AstroPy] WCS creation In-Reply-To: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> Message-ID: Hi Martin, I am not aware of any build in method to fit WCS using astropy. But you can very easily implement a least square fit to generate best fit astropy WCS object. You can see an example here which i wrote long ago to fit WCS from a set of known stars in field. https://github.com/indiajoe/TIRSPEC/blob/master/CodesForUser/FitWCS.py -cheers joe On 4 November 2014 03:15, Martin Beroiz wrote: > Hello everybody, > > I have an image for which I have the RA-Dec information for some sources > along with the pixel location. > From that info, I want to create a WCS object with astropy preferably. > Is there a simple way to do that? I read the docs for the WCS class but it > seems it only manipulates WCS but won?t create one from the information on > a few stars. > > Basically, I?m looking for a python equivalent of STARAST for IDL > http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro > > Is there a built-in way to do this with astropy or affiliated package? > > Thanks for your help. > M. > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- Website: www.tifr.res.in/~ninan/ My GnuPG Public Key: www.tifr.res.in/~ninan/JPN_public.key -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.covino at brera.inaf.it Tue Nov 4 00:57:02 2014 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Tue, 4 Nov 2014 06:57:02 +0100 Subject: [AstroPy] WCS creation In-Reply-To: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> Message-ID: <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> Hi Martin, it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. Bye, Stefano __________________ Mobilis in mobile > Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: > > Hello everybody, > > I have an image for which I have the RA-Dec information for some sources along with the pixel location. >> From that info, I want to create a WCS object with astropy preferably. > Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. > > Basically, I?m looking for a python equivalent of STARAST for IDL > http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro > > Is there a built-in way to do this with astropy or affiliated package? > > Thanks for your help. > M. > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From hiltonm at ukzn.ac.za Tue Nov 4 01:20:25 2014 From: hiltonm at ukzn.ac.za (Matt Hilton) Date: Tue, 04 Nov 2014 08:20:25 +0200 Subject: [AstroPy] WCS creation In-Reply-To: <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> Message-ID: <54587029.8060902@ukzn.ac.za> Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in astLib to fit objects in an image to find a WCS. I use SCAMP (http://www.astromatic.net/software/scamp) for this sort of problem these days. Cheers, Matt. On 04/11/14 07:57, Stefano Covino wrote: > Hi Martin, > > it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. > > Bye, > Stefano > > > > __________________ > > Mobilis in mobile > >> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >> >> Hello everybody, >> >> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>> From that info, I want to create a WCS object with astropy preferably. >> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >> >> Basically, I?m looking for a python equivalent of STARAST for IDL >> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >> >> Is there a built-in way to do this with astropy or affiliated package? >> >> Thanks for your help. >> M. >> _______________________________________________ >> 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 stefano.covino at brera.inaf.it Tue Nov 4 01:50:31 2014 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Tue, 4 Nov 2014 07:50:31 +0100 Subject: [AstroPy] WCS creation In-Reply-To: <54587029.8060902@ukzn.ac.za> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> <54587029.8060902@ukzn.ac.za> Message-ID: <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> Hi Matt, Martin, I see that I misunderstood what Martin meant. I use astLib to create from scratch a WCS header that later I fill with the opportune parameters. Of course this is not what Martin asks, because he mentioned information from a few stars (i.e. hot to compute the opportune parameters...). As a matter of fact, I wrote a script to derive the astrometry for a FITS frame in a more or less automatic way. It is nothing special and far from being optimized, yet it works. You can find it, if you like, here: https://pypi.python.org/pypi/SRPAstro.FITS/ Bye, Stefano Mobilis in Mobile > Il giorno 04/nov/2014, alle ore 07:20, Matt Hilton ha scritto: > > Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in > astLib to fit objects in an image to find a WCS. I use SCAMP > (http://www.astromatic.net/software/scamp) for this sort of problem > these days. > > Cheers, > Matt. > >> On 04/11/14 07:57, Stefano Covino wrote: >> Hi Martin, >> >> it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. >> >> Bye, >> Stefano >> >> >> >> __________________ >> >> Mobilis in mobile >> >>> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >>> >>> Hello everybody, >>> >>> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>>> From that info, I want to create a WCS object with astropy preferably. >>> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >>> >>> Basically, I?m looking for a python equivalent of STARAST for IDL >>> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >>> >>> Is there a built-in way to do this with astropy or affiliated package? >>> >>> Thanks for your help. >>> M. >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsci.perry at gmail.com Tue Nov 4 08:47:01 2014 From: stsci.perry at gmail.com (Perry Greenfield) Date: Tue, 4 Nov 2014 08:47:01 -0500 Subject: [AstroPy] WCS creation In-Reply-To: <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> <54587029.8060902@ukzn.ac.za> <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> Message-ID: <4A8399C6-E29E-464E-8417-8F4F83E20D12@gmail.com> This is something that will be possible with the generalized WCS package we are working on now (most of the fitting functionality will be in the modeling component of WCS). The initial version won't support fitting of composite models (i.e., models created from arithmetic combinations of simpler models or models pipelined together), but that is in the plans. But for the time being, you'll either need to fit the parameters yourself, or use a different package (e.g., astlib) Perry On Nov 4, 2014, at 1:50 AM, Stefano Covino wrote: > Hi Matt, Martin, > > I see that I misunderstood what Martin meant. I use astLib to create from scratch a WCS header that later I fill with the opportune parameters. Of course this is not what Martin asks, because he mentioned information from a few stars (i.e. hot to compute the opportune parameters...). > > As a matter of fact, I wrote a script to derive the astrometry for a FITS frame in a more or less automatic way. It is nothing special and far from being optimized, yet it works. > > You can find it, if you like, here: https://pypi.python.org/pypi/SRPAstro.FITS/ > > Bye, > Stefano > > Mobilis in Mobile > > Il giorno 04/nov/2014, alle ore 07:20, Matt Hilton ha scritto: > >> Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in >> astLib to fit objects in an image to find a WCS. I use SCAMP >> (http://www.astromatic.net/software/scamp) for this sort of problem >> these days. >> >> Cheers, >> Matt. >> >> On 04/11/14 07:57, Stefano Covino wrote: >>> Hi Martin, >>> >>> it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. >>> >>> Bye, >>> Stefano >>> >>> >>> >>> __________________ >>> >>> Mobilis in mobile >>> >>>> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >>>> >>>> Hello everybody, >>>> >>>> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>>>> From that info, I want to create a WCS object with astropy preferably. >>>> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >>>> >>>> Basically, I?m looking for a python equivalent of STARAST for IDL >>>> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >>>> >>>> Is there a built-in way to do this with astropy or affiliated package? >>>> >>>> Thanks for your help. >>>> M. >>>> _______________________________________________ >>>> 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 From sosey at stsci.edu Tue Nov 4 09:00:44 2014 From: sosey at stsci.edu (Megan Sosey) Date: Tue, 4 Nov 2014 14:00:44 +0000 Subject: [AstroPy] WCS creation In-Reply-To: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> Message-ID: This is a throw back, but if you haven't found anything and have IRAF installed, I used to use imcoords in IRAF (agetim to get fits images from DSS regions if needed) in combination with the USNO-A2 catalog (or similar) to fit the WCS for ground based images with no information. Use imcoords.ccamp to compute the plate solution and then feed that to imcoords.ccsetwcs cheers megan -----Original Message-- From: Martin Beroiz Reply-To: Astronomical Python mailing list Date: Monday, November 3, 2014 4:45 PM To: Astronomical Python mailing list Subject: [AstroPy] WCS creation >Hello everybody, > >I have an image for which I have the RA-Dec information for some sources >along with the pixel location. >From that info, I want to create a WCS object with astropy preferably. >Is there a simple way to do that? I read the docs for the WCS class but >it seems it only manipulates WCS but won?t create one from the >information on a few stars. > >Basically, I?m looking for a python equivalent of STARAST for IDL >http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro > >Is there a built-in way to do this with astropy or affiliated package? > >Thanks for your help. >M. >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy From martinberoiz at gmail.com Tue Nov 4 10:38:09 2014 From: martinberoiz at gmail.com (Martin Beroiz) Date: Tue, 4 Nov 2014 09:38:09 -0600 Subject: [AstroPy] WCS creation In-Reply-To: <4A8399C6-E29E-464E-8417-8F4F83E20D12@gmail.com> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> <54587029.8060902@ukzn.ac.za> <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> <4A8399C6-E29E-464E-8417-8F4F83E20D12@gmail.com> Message-ID: <0A19EADC-42C7-462E-AD68-078A65A58830@gmail.com> Thanks to all of you for your responses, I think I?ll code my own based on some of your suggestions. I forgot to mention that I need this to be done without human intervention, in a sort of industrial 'big data' way ;) Thanks again, you?ve been very helpful! > On Nov 4, 2014, at 7:47 AM, Perry Greenfield wrote: > > This is something that will be possible with the generalized WCS package we are working on now (most of the fitting functionality will be in the modeling component of WCS). The initial version won't support fitting of composite models (i.e., models created from arithmetic combinations of simpler models or models pipelined together), but that is in the plans. But for the time being, you'll either need to fit the parameters yourself, or use a different package (e.g., astlib) > > Perry > > On Nov 4, 2014, at 1:50 AM, Stefano Covino wrote: > >> Hi Matt, Martin, >> >> I see that I misunderstood what Martin meant. I use astLib to create from scratch a WCS header that later I fill with the opportune parameters. Of course this is not what Martin asks, because he mentioned information from a few stars (i.e. hot to compute the opportune parameters...). >> >> As a matter of fact, I wrote a script to derive the astrometry for a FITS frame in a more or less automatic way. It is nothing special and far from being optimized, yet it works. >> >> You can find it, if you like, here: https://pypi.python.org/pypi/SRPAstro.FITS/ >> >> Bye, >> Stefano >> >> Mobilis in Mobile >> >> Il giorno 04/nov/2014, alle ore 07:20, Matt Hilton ha scritto: >> >>> Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in >>> astLib to fit objects in an image to find a WCS. I use SCAMP >>> (http://www.astromatic.net/software/scamp) for this sort of problem >>> these days. >>> >>> Cheers, >>> Matt. >>> >>> On 04/11/14 07:57, Stefano Covino wrote: >>>> Hi Martin, >>>> >>>> it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. >>>> >>>> Bye, >>>> Stefano >>>> >>>> >>>> >>>> __________________ >>>> >>>> Mobilis in mobile >>>> >>>>> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >>>>> >>>>> Hello everybody, >>>>> >>>>> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>>>>> From that info, I want to create a WCS object with astropy preferably. >>>>> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >>>>> >>>>> Basically, I?m looking for a python equivalent of STARAST for IDL >>>>> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >>>>> >>>>> Is there a built-in way to do this with astropy or affiliated package? >>>>> >>>>> Thanks for your help. >>>>> M. >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From mcraig at mnstate.edu Tue Nov 4 11:03:44 2014 From: mcraig at mnstate.edu (Matthew Craig) Date: Tue, 4 Nov 2014 16:03:44 +0000 Subject: [AstroPy] WCS creation In-Reply-To: <0A19EADC-42C7-462E-AD68-078A65A58830@gmail.com> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> <54587029.8060902@ukzn.ac.za> <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> <4A8399C6-E29E-464E-8417-8F4F83E20D12@gmail.com>, <0A19EADC-42C7-462E-AD68-078A65A58830@gmail.com> Message-ID: <3F03F8F8-D0D0-4F0E-881F-E0D4F2A43DE2@mnstate.edu> Another option not mentioned yet is astrometry.net. A blind search running on my laptop only takes about 1 sec per image if I feed it a reasonable accurate pixel scale. Matt Craig Sent from my iPhone > On Nov 4, 2014, at 9:38 AM, Martin Beroiz wrote: > > Thanks to all of you for your responses, I think I?ll code my own based on some of your suggestions. > I forgot to mention that I need this to be done without human intervention, in a sort of industrial 'big data' way ;) > > Thanks again, you?ve been very helpful! > >> On Nov 4, 2014, at 7:47 AM, Perry Greenfield wrote: >> >> This is something that will be possible with the generalized WCS package we are working on now (most of the fitting functionality will be in the modeling component of WCS). The initial version won't support fitting of composite models (i.e., models created from arithmetic combinations of simpler models or models pipelined together), but that is in the plans. But for the time being, you'll either need to fit the parameters yourself, or use a different package (e.g., astlib) >> >> Perry >> >>> On Nov 4, 2014, at 1:50 AM, Stefano Covino wrote: >>> >>> Hi Matt, Martin, >>> >>> I see that I misunderstood what Martin meant. I use astLib to create from scratch a WCS header that later I fill with the opportune parameters. Of course this is not what Martin asks, because he mentioned information from a few stars (i.e. hot to compute the opportune parameters...). >>> >>> As a matter of fact, I wrote a script to derive the astrometry for a FITS frame in a more or less automatic way. It is nothing special and far from being optimized, yet it works. >>> >>> You can find it, if you like, here: https://pypi.python.org/pypi/SRPAstro.FITS/ >>> >>> Bye, >>> Stefano >>> >>> Mobilis in Mobile >>> >>>> Il giorno 04/nov/2014, alle ore 07:20, Matt Hilton ha scritto: >>>> >>>> Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in >>>> astLib to fit objects in an image to find a WCS. I use SCAMP >>>> (http://www.astromatic.net/software/scamp) for this sort of problem >>>> these days. >>>> >>>> Cheers, >>>> Matt. >>>> >>>>> On 04/11/14 07:57, Stefano Covino wrote: >>>>> Hi Martin, >>>>> >>>>> it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. >>>>> >>>>> Bye, >>>>> Stefano >>>>> >>>>> >>>>> >>>>> __________________ >>>>> >>>>> Mobilis in mobile >>>>> >>>>>> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >>>>>> >>>>>> Hello everybody, >>>>>> >>>>>> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>>>>>> From that info, I want to create a WCS object with astropy preferably. >>>>>> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >>>>>> >>>>>> Basically, I?m looking for a python equivalent of STARAST for IDL >>>>>> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >>>>>> >>>>>> Is there a built-in way to do this with astropy or affiliated package? >>>>>> >>>>>> Thanks for your help. >>>>>> M. >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> 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 erwin at mpe.mpg.de Tue Nov 4 11:58:20 2014 From: erwin at mpe.mpg.de (Peter Erwin) Date: Tue, 4 Nov 2014 17:58:20 +0100 Subject: [AstroPy] WCS creation In-Reply-To: <3F03F8F8-D0D0-4F0E-881F-E0D4F2A43DE2@mnstate.edu> References: <759FE66C-683A-4BC4-B3E9-12EF0E89C405@gmail.com> <44D78EB0-58B3-44CF-88BE-5B1364D5628B@brera.inaf.it> <54587029.8060902@ukzn.ac.za> <9BD134B7-31F3-40FE-B2BB-6DC71BDCD8F2@brera.inaf.it> <4A8399C6-E29E-464E-8417-8F4F83E20D12@gmail.com>, <0A19EADC-42C7-462E-AD68-078A65A58830@gmail.com> <3F03F8F8-D0D0-4F0E-881F-E0D4F2A43DE2@mnstate.edu> Message-ID: <5386C939-F58B-496A-8ACD-7F988414F98A@mpe.mpg.de> astrometry.net is pretty awesome, but it's kind of overkill for what Martin described, since he's already got pixel coordinates and RA,Dec for several objects in the image. cheers, Peter On Nov 4, 2014, at 5:03 PM, Matthew Craig wrote: > Another option not mentioned yet is astrometry.net. A blind search running on my laptop only takes about 1 sec per image if I feed it a reasonable accurate pixel scale. > > Matt Craig > > Sent from my iPhone > >> On Nov 4, 2014, at 9:38 AM, Martin Beroiz wrote: >> >> Thanks to all of you for your responses, I think I?ll code my own based on some of your suggestions. >> I forgot to mention that I need this to be done without human intervention, in a sort of industrial 'big data' way ;) >> >> Thanks again, you?ve been very helpful! >> >>> On Nov 4, 2014, at 7:47 AM, Perry Greenfield wrote: >>> >>> This is something that will be possible with the generalized WCS package we are working on now (most of the fitting functionality will be in the modeling component of WCS). The initial version won't support fitting of composite models (i.e., models created from arithmetic combinations of simpler models or models pipelined together), but that is in the plans. But for the time being, you'll either need to fit the parameters yourself, or use a different package (e.g., astlib) >>> >>> Perry >>> >>>> On Nov 4, 2014, at 1:50 AM, Stefano Covino wrote: >>>> >>>> Hi Matt, Martin, >>>> >>>> I see that I misunderstood what Martin meant. I use astLib to create from scratch a WCS header that later I fill with the opportune parameters. Of course this is not what Martin asks, because he mentioned information from a few stars (i.e. hot to compute the opportune parameters...). >>>> >>>> As a matter of fact, I wrote a script to derive the astrometry for a FITS frame in a more or less automatic way. It is nothing special and far from being optimized, yet it works. >>>> >>>> You can find it, if you like, here: https://pypi.python.org/pypi/SRPAstro.FITS/ >>>> >>>> Bye, >>>> Stefano >>>> >>>> Mobilis in Mobile >>>> >>>>> Il giorno 04/nov/2014, alle ore 07:20, Matt Hilton ha scritto: >>>>> >>>>> Hi Stefano, Martin, I'm afraid it doesn't, i.e., there is nothing in >>>>> astLib to fit objects in an image to find a WCS. I use SCAMP >>>>> (http://www.astromatic.net/software/scamp) for this sort of problem >>>>> these days. >>>>> >>>>> Cheers, >>>>> Matt. >>>>> >>>>>> On 04/11/14 07:57, Stefano Covino wrote: >>>>>> Hi Martin, >>>>>> >>>>>> it is not part of astropy, but the astLib package (http://astlib.sourceforge.net) I think allows you to do what you need. >>>>>> >>>>>> Bye, >>>>>> Stefano >>>>>> >>>>>> >>>>>> >>>>>> __________________ >>>>>> >>>>>> Mobilis in mobile >>>>>> >>>>>>> Il giorno 03/nov/2014, alle ore 22:45, Martin Beroiz ha scritto: >>>>>>> >>>>>>> Hello everybody, >>>>>>> >>>>>>> I have an image for which I have the RA-Dec information for some sources along with the pixel location. >>>>>>>> From that info, I want to create a WCS object with astropy preferably. >>>>>>> Is there a simple way to do that? I read the docs for the WCS class but it seems it only manipulates WCS but won?t create one from the information on a few stars. >>>>>>> >>>>>>> Basically, I?m looking for a python equivalent of STARAST for IDL >>>>>>> http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/starast.pro >>>>>>> >>>>>>> Is there a built-in way to do this with astropy or affiliated package? >>>>>>> >>>>>>> Thanks for your help. >>>>>>> M. >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> _______________________________________________ >>> 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 ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)176 2481 7713 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From tim.staley at astro.ox.ac.uk Thu Nov 13 09:07:45 2014 From: tim.staley at astro.ox.ac.uk (Tim Staley) Date: Thu, 13 Nov 2014 14:07:45 +0000 Subject: [AstroPy] fourpiskytools - simple Python examples for sending and receiving VOEvents Message-ID: <5464BB31.1050404@astro.ox.ac.uk> Hi all, if any of you are working on follow-up of transient events, you might be interested in a package I've just put together: https://github.com/timstaley/fourpiskytools The package aims to provide a 'minimum working example' of how one might get started working with VOEvents, that can be easily adapted for your specific needs. VOEvents are the standardised format for distributing alerts (gamma-ray burst here, detected in optical, etc etc), and are intended to be machine readable, as opposed to the current typical method of posting human-written reports as ATels or on a dedicated project website. The transport protocol uses a 'keep-alive' connection, so they're also pretty low-latency (compared with e.g. sending emails). Finally, as compared to say NASA-GCN, they are flexible enough to be adapted for many different telescopes, and support a decentralised publication model. The hope is that if we can get more teams on-board and using VOEvent, it opens up a slew of possibilities for rapid event classification and targeted follow-up. Note that fourpiskytools is built on voevent-parse (http://voevent-parse.readthedocs.org/en/master/), a package for which I'm currently considering how best to integrate the astropy core functionality, so if that would be useful to you and you'd like to see it soon then drop a note on the relevant issue: https://github.com/timstaley/voevent-parse/issues/2 Happy transient hunting! -Tim From lsinger at caltech.edu Thu Nov 13 13:23:09 2014 From: lsinger at caltech.edu (Leo Singer) Date: Thu, 13 Nov 2014 10:23:09 -0800 Subject: [AstroPy] fourpiskytools - simple Python examples for sending and receiving VOEvents In-Reply-To: <5464BB31.1050404@astro.ox.ac.uk> References: <5464BB31.1050404@astro.ox.ac.uk> Message-ID: > On Nov 13, 2014, at 06:07, Tim Staley wrote: > > if any of you are working on follow-up of transient events, you might be interested in a package I've just put together: > > https://github.com/timstaley/fourpiskytools > > The package aims to provide a 'minimum working example' of how one might get started working with VOEvents, that can be easily adapted for your specific needs. Hi Tim, You may also be interested in PyGCN, a tiny GCN package that I wrote and that I have been using for receiving Fermi GBM alerts by Palomar Transient Factory: https://github.com/lpsinger/pygcn It's perhaps more focused on receiving GCNs. But it's super reliable and does all sorts of nice tricks like reconnecting if the socket is broken. I have run three parallel receiver threads using this package for literally months at a time. Cheers, Leo From maik.riechert at arcor.de Thu Nov 13 15:43:16 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Thu, 13 Nov 2014 21:43:16 +0100 Subject: [AstroPy] TAN WCS speedup Message-ID: <546517E4.2070801@arcor.de> Hi, I just finished implementing my own wcs_pix2world function specifically for the TAN projection using just Python with numpy and numexpr. Without numexpr I was slightly slower than astropy (15s vs 12.8s). But with numexpr I got it down to 6.8s, so nearly twice as fast. This is for 8 million pixel coordinates as input run on my 2GHz Core 2 Duo Laptop under Python 2.7 64 bit with Windows 7 and using Christoph Gohlke's numpy and numexpr binaries. I cannot post the code yet but the code is not that important anyway as I didn't do really complicated things. As numexpr seems to provide the main speedup, maybe some concepts of it could be used to speedup astropy/wcslib. I guess it's not a sensible option to actually implement all of wcslib in Python, given that there are way more complicated projections etc. than TAN which would take quite some time to reimplement/maintain. This is basically it, just wanted to share that. Cheers Maik From dencheva at stsci.edu Thu Nov 13 16:05:31 2014 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 13 Nov 2014 21:05:31 +0000 Subject: [AstroPy] TAN WCS speedup In-Reply-To: <546517E4.2070801@arcor.de> References: <546517E4.2070801@arcor.de> Message-ID: <0153364C9F56D944B0A795780ECF88DF5A5496D8@EXCHMAIL2.stsci.edu> I just want to mention that some of the projections in WCS Paper II are implemented in astropy.modeling.projections. Cheers, Nadia ________________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Maik Riechert [maik.riechert at arcor.de] Sent: Thursday, November 13, 2014 3:43 PM To: Astronomical Python mailing list Subject: [AstroPy] TAN WCS speedup Hi, I just finished implementing my own wcs_pix2world function specifically for the TAN projection using just Python with numpy and numexpr. Without numexpr I was slightly slower than astropy (15s vs 12.8s). But with numexpr I got it down to 6.8s, so nearly twice as fast. This is for 8 million pixel coordinates as input run on my 2GHz Core 2 Duo Laptop under Python 2.7 64 bit with Windows 7 and using Christoph Gohlke's numpy and numexpr binaries. I cannot post the code yet but the code is not that important anyway as I didn't do really complicated things. As numexpr seems to provide the main speedup, maybe some concepts of it could be used to speedup astropy/wcslib. I guess it's not a sensible option to actually implement all of wcslib in Python, given that there are way more complicated projections etc. than TAN which would take quite some time to reimplement/maintain. This is basically it, just wanted to share that. Cheers Maik _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy From embray at stsci.edu Thu Nov 13 16:09:50 2014 From: embray at stsci.edu (Erik Bray) Date: Thu, 13 Nov 2014 16:09:50 -0500 Subject: [AstroPy] TAN WCS speedup In-Reply-To: <0153364C9F56D944B0A795780ECF88DF5A5496D8@EXCHMAIL2.stsci.edu> References: <546517E4.2070801@arcor.de> <0153364C9F56D944B0A795780ECF88DF5A5496D8@EXCHMAIL2.stsci.edu> Message-ID: <54651E1E.9060502@stsci.edu> On 11/13/2014 04:05 PM, Nadezhda Dencheva wrote: > I just want to mention that some of the projections in WCS Paper II are > implemented in astropy.modeling.projections. They're probably not very fast though, but at least they are designed more or less to accept drop-in replacements for the actual algorithm (say, using numexpr or Cython or the like). It has definitely been a todo-list item to provide more efficient implementations of these transforms, albeit possibly on an as-needed, optional basis. > ________________________________________ > From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Maik Riechert [maik.riechert at arcor.de] > Sent: Thursday, November 13, 2014 3:43 PM > To: Astronomical Python mailing list > Subject: [AstroPy] TAN WCS speedup > > Hi, > > I just finished implementing my own wcs_pix2world function specifically > for the TAN projection using just Python with numpy and numexpr. Without > numexpr I was slightly slower than astropy (15s vs 12.8s). But with > numexpr I got it down to 6.8s, so nearly twice as fast. This is for 8 > million pixel coordinates as input run on my 2GHz Core 2 Duo Laptop > under Python 2.7 64 bit with Windows 7 and using Christoph Gohlke's > numpy and numexpr binaries. > > I cannot post the code yet but the code is not that important anyway as > I didn't do really complicated things. > > As numexpr seems to provide the main speedup, maybe some concepts of it > could be used to speedup astropy/wcslib. I guess it's not a sensible > option to actually implement all of wcslib in Python, given that there > are way more complicated projections etc. than TAN which would take > quite some time to reimplement/maintain. > > This is basically it, just wanted to share that. > > Cheers > Maik > _______________________________________________ > 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 kylebarbary at gmail.com Thu Nov 13 16:12:54 2014 From: kylebarbary at gmail.com (Kyle Barbary) Date: Thu, 13 Nov 2014 13:12:54 -0800 Subject: [AstroPy] TAN WCS speedup In-Reply-To: <546517E4.2070801@arcor.de> References: <546517E4.2070801@arcor.de> Message-ID: I'm curious if part of the speed up is due to using two cores in the numexpr version? I assume the WCSLIB C code is not threaded. - Kyle On Thu, Nov 13, 2014 at 12:43 PM, Maik Riechert wrote: > Hi, > > I just finished implementing my own wcs_pix2world function specifically > for the TAN projection using just Python with numpy and numexpr. Without > numexpr I was slightly slower than astropy (15s vs 12.8s). But with > numexpr I got it down to 6.8s, so nearly twice as fast. This is for 8 > million pixel coordinates as input run on my 2GHz Core 2 Duo Laptop > under Python 2.7 64 bit with Windows 7 and using Christoph Gohlke's > numpy and numexpr binaries. > > I cannot post the code yet but the code is not that important anyway as > I didn't do really complicated things. > > As numexpr seems to provide the main speedup, maybe some concepts of it > could be used to speedup astropy/wcslib. I guess it's not a sensible > option to actually implement all of wcslib in Python, given that there > are way more complicated projections etc. than TAN which would take > quite some time to reimplement/maintain. > > This is basically it, just wanted to share that. > > Cheers > Maik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Fri Nov 14 09:34:43 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 14 Nov 2014 09:34:43 -0500 Subject: [AstroPy] TAN WCS speedup In-Reply-To: References: <546517E4.2070801@arcor.de> Message-ID: <54661303.1060208@stsci.edu> That is correct. WCSLIB C code is single-threaded. It's a relatively straightforward calculation such that I'd be surprised if anything else could account for such a large speedup. Mike On 11/13/2014 04:12 PM, Kyle Barbary wrote: > I'm curious if part of the speed up is due to using two cores in the > numexpr version? I assume the WCSLIB C code is not threaded. > > - Kyle > > On Thu, Nov 13, 2014 at 12:43 PM, Maik Riechert > > wrote: > > Hi, > > I just finished implementing my own wcs_pix2world function > specifically > for the TAN projection using just Python with numpy and numexpr. > Without > numexpr I was slightly slower than astropy (15s vs 12.8s). But with > numexpr I got it down to 6.8s, so nearly twice as fast. This is for 8 > million pixel coordinates as input run on my 2GHz Core 2 Duo Laptop > under Python 2.7 64 bit with Windows 7 and using Christoph Gohlke's > numpy and numexpr binaries. > > I cannot post the code yet but the code is not that important > anyway as > I didn't do really complicated things. > > As numexpr seems to provide the main speedup, maybe some concepts > of it > could be used to speedup astropy/wcslib. I guess it's not a sensible > option to actually implement all of wcslib in Python, given that there > are way more complicated projections etc. than TAN which would take > quite some time to reimplement/maintain. > > This is basically it, just wanted to share that. > > Cheers > Maik > _______________________________________________ > 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Fri Nov 14 13:21:29 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Fri, 14 Nov 2014 19:21:29 +0100 Subject: [AstroPy] TAN WCS speedup In-Reply-To: <54661303.1060208@stsci.edu> References: <546517E4.2070801@arcor.de> <54661303.1060208@stsci.edu> Message-ID: <54664829.5000701@arcor.de> Michael Droettboom: > That is correct. WCSLIB C code is single-threaded. It's a relatively > straightforward calculation such that I'd be surprised if anything else > could account for such a large speedup. I just tried it with numexpr.set_num_threads(1) and indeed it is slightly slower now: 8.8s. I guess some speedup also comes numexpr handling arrays in chunks such that they fit in the CPU cache. Some other things I use: numpy.core.umath_tests.matrix_multiply (rotating vectors) I also reimplemented astropy's spherical_to_cartesian and cartesian_to_spherical in terms of numexpr with fall-back to an optimized numpy variant (which is also faster than astropy's, because it doesn't calculate things twice and reuses temporary arrays where possible). I had a quick look at astropy.modeling.projections and I think just exchanging this part wouldn't earn that much performance. Cheers Maik From joe at neoturbine.net Fri Nov 14 15:39:20 2014 From: joe at neoturbine.net (Joseph Booker) Date: Fri, 14 Nov 2014 15:39:20 -0500 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations Message-ID: Hello, I've been porting pyregion to use astropy instead of kapteyn, and tests with coordinate system conversions are slightly off. I think I've narrowed down the problem to my expectation that this should be nearly zero: In [21]: from astropy.coordinates import SkyCoord In [22]: from kapteyn import celestial In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', frame='galactic').transform_to('fk5'); print(a) In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, [292.03306305555554], [1.7592747222222223]) Out[24]: matrix([[ 171.15816386, -59.26319319]]) In [25]: SkyCoord('171.15816386d -59.26319319d', frame='fk5').separation(a).to('arcsecond') Out[25]: My question is: am I misunderstanding something about these coordinate transformations to make them not equivalent? A third of an arcsecond is significantly big deviation, particularly for HST or interferometry. AFAIK fk5 is J2000 in both libraries and galactic coordinates have no concept of epoch or equinox time. Thanks, Joseph Booker -------------- next part -------------- An HTML attachment was scrubbed... URL: From Deil.Christoph at gmail.com Sat Nov 15 08:58:39 2014 From: Deil.Christoph at gmail.com (Christoph Deil) Date: Sat, 15 Nov 2014 14:58:39 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: Message-ID: <89BF1DBF-1775-459A-A8E4-D03D42547822@gmail.com> > On 14 Nov 2014, at 21:39, Joseph Booker wrote: > > Hello, > > I've been porting pyregion to use astropy instead of kapteyn, and tests with coordinate system conversions are slightly off. > > I think I've narrowed down the problem to my expectation that this should be nearly zero: > > In [21]: from astropy.coordinates import SkyCoord > > In [22]: from kapteyn import celestial > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', frame='galactic').transform_to('fk5'); print(a) > > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, [292.03306305555554], [1.7592747222222223]) > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > In [25]: SkyCoord('171.15816386d -59.26319319d', frame='fk5').separation(a).to('arcsecond') > Out[25]: > > > My question is: am I misunderstanding something about these coordinate transformations to make them not equivalent? A third of an arcsecond is significantly big deviation, particularly for HST or interferometry. AFAIK fk5 is J2000 in both libraries and galactic coordinates have no concept of epoch or equinox time. > > Thanks, > Joseph Booker > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Hi Joseph, it must be some small difference in the definition of the Galactic or FK5 system, but I don?t know what it is. Differences of `astropy.coordinates` against `kapteyn.celestial` for Galactic to FK5 conversion at the 0.4 arcsec level have been there since the initial implementation of `astropy.coordinates`: http://www.astropy.org/coordinates-benchmark/summary.html If you or any sky coordinate experts have time to work on coordinate checks, please file issues or pull requests here: https://github.com/astropy/coordinates-benchmark/ Thanks for porting `pyregion` to use `astropy` and doing such detailed checks! Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Sat Nov 15 11:50:58 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 15 Nov 2014 17:50:58 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: <89BF1DBF-1775-459A-A8E4-D03D42547822@gmail.com> References: <89BF1DBF-1775-459A-A8E4-D03D42547822@gmail.com> Message-ID: <54678472.7090404@gmail.com> It is true that most other tools are more consistent: http://www.astropy.org/coordinates-benchmark/summary.html (see the fk5 to galactic section). It seems like we should be achieving 1-10mas agreement with other codes. The weird thing is that fk5 -> fk4 agrees with other codes, as does fk4 -> galactic. I think this is because astropy.coordinates also defines the fk5 -> galactic transformation directly so it may be related to this. It may be that the direct fk5 -> galactic transformation is not quite right. Erik T.: can you comment on this? Cheers, Tom Christoph Deil wrote: >> On 14 Nov 2014, at 21:39, Joseph Booker > wrote: >> >> Hello, >> >> I've been porting pyregion to use astropy instead of kapteyn, and >> tests with coordinate system conversions are slightly off. >> >> I think I've narrowed down the problem to my expectation that this >> should be nearly zero: >> >> In [21]: from astropy.coordinates import SkyCoord >> >> In [22]: from kapteyn import celestial >> >> In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', >> frame='galactic').transform_to('fk5'); print(a) >> >> >> In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, >> [292.03306305555554], [1.7592747222222223]) >> Out[24]: matrix([[ 171.15816386, -59.26319319]]) >> >> In [25]: SkyCoord('171.15816386d -59.26319319d', >> frame='fk5').separation(a).to('arcsecond') >> Out[25]: >> >> >> My question is: am I misunderstanding something about these coordinate >> transformations to make them not equivalent? A third of an arcsecond >> is significantly big deviation, particularly for HST or >> interferometry. AFAIK fk5 is J2000 in both libraries and galactic >> coordinates have no concept of epoch or equinox time. >> >> Thanks, >> Joseph Booker >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > Hi Joseph, > > it must be some small difference in the definition of the Galactic or > FK5 system, but I don?t know what it is. > > Differences of `astropy.coordinates` against `kapteyn.celestial` for > Galactic to FK5 conversion at the 0.4 arcsec level have been there since > the initial implementation of `astropy.coordinates`: > http://www.astropy.org/coordinates-benchmark/summary.html > > If you or any sky coordinate experts have time to work on coordinate > checks, please file issues or pull requests here: > https://github.com/astropy/coordinates-benchmark/ > > Thanks for porting `pyregion` to use `astropy` and doing such detailed > checks! > > Christoph > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From erik.tollerud at gmail.com Sat Nov 15 12:00:05 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sat, 15 Nov 2014 12:00:05 -0500 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: Message-ID: Hi Tom and Joseph, Originally, Galactic coordinates were defined to ~arcmin precision relative to FK4 (and it's not clear one way or another if this is supposed to include E-terms or not). Since then there have been recalibrations to FK5, although there's not an "official" version as far as we could find (just an appendix in a paper). So I think what's happening here is that the "shortcut" FK5-> Galactic transform is being used, which gives somewhat different results because it made different arbitrary choices. We could just turn that off if we want to always be sure to use the FK4 transformation. It's not really clear which is the "right" answer, though. I think our original thinking was that no one really uses Galactic for subarcsec precision, and there FK4 transformations are a lot slower, so this "shortcut" makes sense... Hello, I've been porting pyregion to use astropy instead of kapteyn, and tests with coordinate system conversions are slightly off. I think I've narrowed down the problem to my expectation that this should be nearly zero: In [21]: from astropy.coordinates import SkyCoord In [22]: from kapteyn import celestial In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', frame='galactic').transform_to('fk5'); print(a) In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, [292.03306305555554], [1.7592747222222223]) Out[24]: matrix([[ 171.15816386, -59.26319319]]) In [25]: SkyCoord('171.15816386d -59.26319319d', frame='fk5').separation(a).to('arcsecond') Out[25]: My question is: am I misunderstanding something about these coordinate transformations to make them not equivalent? A third of an arcsecond is significantly big deviation, particularly for HST or interferometry. AFAIK fk5 is J2000 in both libraries and galactic coordinates have no concept of epoch or equinox time. Thanks, Joseph Booker _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Deil.Christoph at gmail.com Sat Nov 15 12:05:47 2014 From: Deil.Christoph at gmail.com (Christoph Deil) Date: Sat, 15 Nov 2014 18:05:47 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: Message-ID: <05243347-28FE-46AC-90FF-4DE35A2CE6F1@gmail.com> > On 15 Nov 2014, at 18:00, Erik Tollerud wrote: > > Hi Tom and Joseph, > > Originally, Galactic coordinates were defined to ~arcmin precision relative to FK4 (and it's not clear one way or another if this is supposed to include E-terms or not). Since then there have been recalibrations to FK5, although there's not an "official" version as far as we could find (just an appendix in a paper). > > So I think what's happening here is that the "shortcut" FK5-> Galactic transform is being used, which gives somewhat different results because it made different arbitrary choices. We could just turn that off if we want to always be sure to use the FK4 transformation. > > It's not really clear which is the "right" answer, though. I think our original thinking was that no one really uses Galactic for subarcsec precision, and there FK4 transformations are a lot slower, so this "shortcut" makes sense... > > Can?t you get speed and internal consistency in this case by hard-coding the results you get via FK4? If no, then probably precision and consistency for Galactic coordinates is more important than speed for most users? Christoph > Hello, > > I've been porting pyregion to use astropy instead of kapteyn, and tests with coordinate system conversions are slightly off. > > I think I've narrowed down the problem to my expectation that this should be nearly zero: > > In [21]: from astropy.coordinates import SkyCoord > > In [22]: from kapteyn import celestial > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', frame='galactic').transform_to('fk5'); print(a) > > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, [292.03306305555554], [1.7592747222222223]) > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > In [25]: SkyCoord('171.15816386d -59.26319319d', frame='fk5').separation(a).to('arcsecond') > Out[25]: > > > My question is: am I misunderstanding something about these coordinate transformations to make them not equivalent? A third of an arcsecond is significantly big deviation, particularly for HST or interferometry. AFAIK fk5 is J2000 in both libraries and galactic coordinates have no concept of epoch or equinox time. > > Thanks, > Joseph Booker > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Sat Nov 15 12:11:51 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 15 Nov 2014 18:11:51 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: Message-ID: <54678957.5050808@gmail.com> Hi Erik, Erik Tollerud wrote: > Hi Tom and Joseph, > > Originally, Galactic coordinates were defined to ~arcmin precision > relative to FK4 (and it's not clear one way or another if this is > supposed to include E-terms or not). Since then there have been > recalibrations to FK5, although there's not an "official" version as far > as we could find (just an appendix in a paper). > > So I think what's happening here is that the "shortcut" FK5-> Galactic > transform is being used, which gives somewhat different results because > it made different arbitrary choices. We could just turn that off if we > want to always be sure to use the FK4 transformation. > > It's not really clear which is the "right" answer, though. I think our > original thinking was that no one really uses Galactic for subarcsec > precision, and there FK4 transformations are a lot slower, so this > "shortcut" makes sense... The issue of the 'right' answer is what I thought originally, but (a) all other codes (except astrolib) agree better than this so I think we should treat those as the 'right' answer, and (b) we should at least be internally consistent. It shouldn't matter if one does FK5 -> Galactic or FK5 -> FK4 -> Galactic. Maybe the values from Reid+ (2004) were just not accurate enough in FK5? Is there an easy way to re-derive the values of the NGP and lon0 in FK5 using our own FK4 -> FK5 transformation? Cheers, Tom > > Hello, > > I've been porting pyregion to use astropy instead of kapteyn, and tests > with coordinate system conversions are slightly off. > > I think I've narrowed down the problem to my expectation that this > should be nearly zero: > > In [21]: from astropy.coordinates import SkyCoord > > In [22]: from kapteyn import celestial > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > frame='galactic').transform_to('fk5'); print(a) > dec=-59.2630875829 deg> > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > [292.03306305555554], [1.7592747222222223]) > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > In [25]: SkyCoord('171.15816386d -59.26319319d', > frame='fk5').separation(a).to('arcsecond') > Out[25]: > > > My question is: am I misunderstanding something about these coordinate > transformations to make them not equivalent? A third of an arcsecond is > significantly big deviation, particularly for HST or interferometry. > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no > concept of epoch or equinox time. > > Thanks, > Joseph Booker > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From thomas.robitaille at gmail.com Sat Nov 15 12:32:06 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 15 Nov 2014 18:32:06 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: Message-ID: <54678E16.3020807@gmail.com> I've played around with this a bit more, and I found that if I set: _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) (not FK4) then I explicitly set: Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) then if I set: Galactic._lon0_J2000 = Angle(122.931918539, u.degree) Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic transformations agree within ~0.1mas, and our results are in agreement with other codes. I'll open an issue on the astropy repo and we can discuss the technical details there. Tom Erik Tollerud wrote: > Hi Tom and Joseph, > > Originally, Galactic coordinates were defined to ~arcmin precision > relative to FK4 (and it's not clear one way or another if this is > supposed to include E-terms or not). Since then there have been > recalibrations to FK5, although there's not an "official" version as far > as we could find (just an appendix in a paper). > > So I think what's happening here is that the "shortcut" FK5-> Galactic > transform is being used, which gives somewhat different results because > it made different arbitrary choices. We could just turn that off if we > want to always be sure to use the FK4 transformation. > > It's not really clear which is the "right" answer, though. I think our > original thinking was that no one really uses Galactic for subarcsec > precision, and there FK4 transformations are a lot slower, so this > "shortcut" makes sense... > > Hello, > > I've been porting pyregion to use astropy instead of kapteyn, and tests > with coordinate system conversions are slightly off. > > I think I've narrowed down the problem to my expectation that this > should be nearly zero: > > In [21]: from astropy.coordinates import SkyCoord > > In [22]: from kapteyn import celestial > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > frame='galactic').transform_to('fk5'); print(a) > dec=-59.2630875829 deg> > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > [292.03306305555554], [1.7592747222222223]) > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > In [25]: SkyCoord('171.15816386d -59.26319319d', > frame='fk5').separation(a).to('arcsecond') > Out[25]: > > > My question is: am I misunderstanding something about these coordinate > transformations to make them not equivalent? A third of an arcsecond is > significantly big deviation, particularly for HST or interferometry. > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no > concept of epoch or equinox time. > > Thanks, > Joseph Booker > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From npkuin at gmail.com Sat Nov 15 17:13:05 2014 From: npkuin at gmail.com (Paul Kuin) Date: Sat, 15 Nov 2014 22:13:05 +0000 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: <54678E16.3020807@gmail.com> References: <54678E16.3020807@gmail.com> Message-ID: I asked the chair of the IAU astrometry commission. Basically the current coordinate system is ICRS, and the galactic frame is defined with reference to that with the same accuracy. I think that is in a few milli arcsec accuracy. The SOFA implementation is to be consulted for actual algorithms, and I think this has been (or will be) implemented in astropy as the ERFA package. In summary, I would think the differences found by Joseph are way too large. It may be that the Kapteyn algorithms are also not compliant. Test should be done against the results of the ERFA/SOFA software. Thats all the help I can give. Paul On Sat, Nov 15, 2014 at 5:32 PM, Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > I've played around with this a bit more, and I found that if I set: > > _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) > > (not FK4) then I explicitly set: > > Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) > > then if I set: > > Galactic._lon0_J2000 = Angle(122.931918539, u.degree) > > Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic > transformations agree within ~0.1mas, and our results are in agreement > with other codes. I'll open an issue on the astropy repo and we can > discuss the technical details there. > > Tom > > Erik Tollerud wrote: > > Hi Tom and Joseph, > > > > Originally, Galactic coordinates were defined to ~arcmin precision > > relative to FK4 (and it's not clear one way or another if this is > > supposed to include E-terms or not). Since then there have been > > recalibrations to FK5, although there's not an "official" version as far > > as we could find (just an appendix in a paper). > > > > So I think what's happening here is that the "shortcut" FK5-> Galactic > > transform is being used, which gives somewhat different results because > > it made different arbitrary choices. We could just turn that off if we > > want to always be sure to use the FK4 transformation. > > > > It's not really clear which is the "right" answer, though. I think our > > original thinking was that no one really uses Galactic for subarcsec > > precision, and there FK4 transformations are a lot slower, so this > > "shortcut" makes sense... > > > > Hello, > > > > I've been porting pyregion to use astropy instead of kapteyn, and tests > > with coordinate system conversions are slightly off. > > > > I think I've narrowed down the problem to my expectation that this > > should be nearly zero: > > > > In [21]: from astropy.coordinates import SkyCoord > > > > In [22]: from kapteyn import celestial > > > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > > frame='galactic').transform_to('fk5'); print(a) > > > dec=-59.2630875829 deg> > > > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > > [292.03306305555554], [1.7592747222222223]) > > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > > > In [25]: SkyCoord('171.15816386d -59.26319319d', > > frame='fk5').separation(a).to('arcsecond') > > Out[25]: > > > > > > My question is: am I misunderstanding something about these coordinate > > transformations to make them not equivalent? A third of an arcsecond is > > significantly big deviation, particularly for HST or interferometry. > > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no > > concept of epoch or equinox time. > > > > Thanks, > > Joseph Booker > > > > _______________________________________________ > > 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 > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.jenness at gmail.com Sat Nov 15 17:37:34 2014 From: tim.jenness at gmail.com (Tim Jenness) Date: Sat, 15 Nov 2014 15:37:34 -0700 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: <54678E16.3020807@gmail.com> Message-ID: I was under the impression that SOFA deliberately ignores Galactic coordinates. I can't find any mention of Galactic in the SOFA/ERFA source and PAL (a SLALIB port to C using ERFA where it can) had to use the SLALIB Galactic code. -- Tim Jenness On Sat, Nov 15, 2014 at 3:13 PM, Paul Kuin wrote: > I asked the chair of the IAU astrometry commission. Basically the current > coordinate system is ICRS, and the galactic frame is defined with reference > to that with the same accuracy. I think that is in a few milli arcsec > accuracy. The SOFA implementation is to be consulted for actual algorithms, > and I think this has been (or will be) implemented in astropy as the ERFA > package. > > In summary, I would think the differences found by Joseph are way too > large. It may be that the Kapteyn algorithms are also not compliant. Test > should be done against the results of the ERFA/SOFA software. > > Thats all the help I can give. > > Paul > > On Sat, Nov 15, 2014 at 5:32 PM, Thomas Robitaille < > thomas.robitaille at gmail.com> wrote: > >> I've played around with this a bit more, and I found that if I set: >> >> _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) >> >> (not FK4) then I explicitly set: >> >> Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) >> >> then if I set: >> >> Galactic._lon0_J2000 = Angle(122.931918539, u.degree) >> >> Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic >> transformations agree within ~0.1mas, and our results are in agreement >> with other codes. I'll open an issue on the astropy repo and we can >> discuss the technical details there. >> >> Tom >> >> Erik Tollerud wrote: >> > Hi Tom and Joseph, >> > >> > Originally, Galactic coordinates were defined to ~arcmin precision >> > relative to FK4 (and it's not clear one way or another if this is >> > supposed to include E-terms or not). Since then there have been >> > recalibrations to FK5, although there's not an "official" version as far >> > as we could find (just an appendix in a paper). >> > >> > So I think what's happening here is that the "shortcut" FK5-> Galactic >> > transform is being used, which gives somewhat different results because >> > it made different arbitrary choices. We could just turn that off if we >> > want to always be sure to use the FK4 transformation. >> > >> > It's not really clear which is the "right" answer, though. I think our >> > original thinking was that no one really uses Galactic for subarcsec >> > precision, and there FK4 transformations are a lot slower, so this >> > "shortcut" makes sense... >> > >> > Hello, >> > >> > I've been porting pyregion to use astropy instead of kapteyn, and tests >> > with coordinate system conversions are slightly off. >> > >> > I think I've narrowed down the problem to my expectation that this >> > should be nearly zero: >> > >> > In [21]: from astropy.coordinates import SkyCoord >> > >> > In [22]: from kapteyn import celestial >> > >> > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', >> > frame='galactic').transform_to('fk5'); print(a) >> > > > dec=-59.2630875829 deg> >> > >> > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, >> > [292.03306305555554], [1.7592747222222223]) >> > Out[24]: matrix([[ 171.15816386, -59.26319319]]) >> > >> > In [25]: SkyCoord('171.15816386d -59.26319319d', >> > frame='fk5').separation(a).to('arcsecond') >> > Out[25]: >> > >> > >> > My question is: am I misunderstanding something about these coordinate >> > transformations to make them not equivalent? A third of an arcsecond is >> > significantly big deviation, particularly for HST or interferometry. >> > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no >> > concept of epoch or equinox time. >> > >> > Thanks, >> > Joseph Booker >> > >> > _______________________________________________ >> > 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 >> > > > > -- > > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * > Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) > phone +44-(0)1483 (prefix) -204927 (work) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Sat Nov 15 20:33:26 2014 From: npkuin at gmail.com (Paul Kuin) Date: Sun, 16 Nov 2014 01:33:26 +0000 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: <54678E16.3020807@gmail.com> Message-ID: That may be correct. It then depends on the definition of the galactic coordinates. I went looking for it. In Fits II Calabretta and Greisen mention that the Glon and Glat are reserved for the systems defined in Adriaan Blaauws paper: http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?1960MNRAS.121..123B&data_type=PDF_HIGH&whole_paper=YES&type=PRINTER&filetype=.pdf This is in 1950.0 Equinox, so FK4. Of course the pole and zero longitude can be converted into J2000 (FK5) to get the FK5 positions. It is possible that that were not done correctly. Since astropy galactic coordinates probably are tied to the FITS definition, this is the correct reference, I think. Paul On Sat, Nov 15, 2014 at 10:37 PM, Tim Jenness wrote: > I was under the impression that SOFA deliberately ignores Galactic > coordinates. I can't find any mention of Galactic in the SOFA/ERFA source > and PAL (a SLALIB port to C using ERFA where it can) had to use the SLALIB > Galactic code. > > -- > Tim Jenness > > On Sat, Nov 15, 2014 at 3:13 PM, Paul Kuin wrote: > >> I asked the chair of the IAU astrometry commission. Basically the current >> coordinate system is ICRS, and the galactic frame is defined with reference >> to that with the same accuracy. I think that is in a few milli arcsec >> accuracy. The SOFA implementation is to be consulted for actual algorithms, >> and I think this has been (or will be) implemented in astropy as the ERFA >> package. >> >> In summary, I would think the differences found by Joseph are way too >> large. It may be that the Kapteyn algorithms are also not compliant. Test >> should be done against the results of the ERFA/SOFA software. >> >> Thats all the help I can give. >> >> Paul >> >> On Sat, Nov 15, 2014 at 5:32 PM, Thomas Robitaille < >> thomas.robitaille at gmail.com> wrote: >> >>> I've played around with this a bit more, and I found that if I set: >>> >>> _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) >>> >>> (not FK4) then I explicitly set: >>> >>> Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) >>> >>> then if I set: >>> >>> Galactic._lon0_J2000 = Angle(122.931918539, u.degree) >>> >>> Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic >>> transformations agree within ~0.1mas, and our results are in agreement >>> with other codes. I'll open an issue on the astropy repo and we can >>> discuss the technical details there. >>> >>> Tom >>> >>> Erik Tollerud wrote: >>> > Hi Tom and Joseph, >>> > >>> > Originally, Galactic coordinates were defined to ~arcmin precision >>> > relative to FK4 (and it's not clear one way or another if this is >>> > supposed to include E-terms or not). Since then there have been >>> > recalibrations to FK5, although there's not an "official" version as >>> far >>> > as we could find (just an appendix in a paper). >>> > >>> > So I think what's happening here is that the "shortcut" FK5-> Galactic >>> > transform is being used, which gives somewhat different results because >>> > it made different arbitrary choices. We could just turn that off if we >>> > want to always be sure to use the FK4 transformation. >>> > >>> > It's not really clear which is the "right" answer, though. I think our >>> > original thinking was that no one really uses Galactic for subarcsec >>> > precision, and there FK4 transformations are a lot slower, so this >>> > "shortcut" makes sense... >>> > >>> > Hello, >>> > >>> > I've been porting pyregion to use astropy instead of kapteyn, and tests >>> > with coordinate system conversions are slightly off. >>> > >>> > I think I've narrowed down the problem to my expectation that this >>> > should be nearly zero: >>> > >>> > In [21]: from astropy.coordinates import SkyCoord >>> > >>> > In [22]: from kapteyn import celestial >>> > >>> > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', >>> > frame='galactic').transform_to('fk5'); print(a) >>> > >> > dec=-59.2630875829 deg> >>> > >>> > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, >>> > [292.03306305555554], [1.7592747222222223]) >>> > Out[24]: matrix([[ 171.15816386, -59.26319319]]) >>> > >>> > In [25]: SkyCoord('171.15816386d -59.26319319d', >>> > frame='fk5').separation(a).to('arcsecond') >>> > Out[25]: >>> > >>> > >>> > My question is: am I misunderstanding something about these coordinate >>> > transformations to make them not equivalent? A third of an arcsecond is >>> > significantly big deviation, particularly for HST or interferometry. >>> > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no >>> > concept of epoch or equinox time. >>> > >>> > Thanks, >>> > Joseph Booker >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> -- >> >> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * >> Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) >> phone +44-(0)1483 (prefix) -204927 (work) >> mobile +44(0)7806985366 skype ID: npkuin >> Mullard Space Science Laboratory ? University College London ? >> Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. >> >> _______________________________________________ >> 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 > > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Sun Nov 16 10:37:33 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sun, 16 Nov 2014 16:37:33 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: References: <54678E16.3020807@gmail.com> Message-ID: <5468C4BD.6010503@gmail.com> Hi Paul, Thanks for the input - as an aside, do you have any insight into whether the IAU is considering proposals such as: http://www.aanda.org/articles/aa/pdf/2011/02/aa14961-10.pdf to re-define the Galactic coordinate system relative to ICRS? Having Galactic coordinates defined relative to FK4 at the moment is not ideal and introduces a lot of confusion, so re-defining galactic coordinates relative to ICRS would be a nice solution. Cheers, Tom Paul Kuin wrote: > I asked the chair of the IAU astrometry commission. Basically the > current coordinate system is ICRS, and the galactic frame is defined > with reference to that with the same accuracy. I think that is in a few > milli arcsec accuracy. The SOFA implementation is to be consulted for > actual algorithms, and I think this has been (or will be) implemented in > astropy as the ERFA package. > > In summary, I would think the differences found by Joseph are way too > large. It may be that the Kapteyn algorithms are also not compliant. > Test should be done against the results of the ERFA/SOFA software. > > Thats all the help I can give. > > Paul > > On Sat, Nov 15, 2014 at 5:32 PM, Thomas Robitaille > > wrote: > > I've played around with this a bit more, and I found that if I set: > > _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) > > (not FK4) then I explicitly set: > > Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) > > then if I set: > > Galactic._lon0_J2000 = Angle(122.931918539, u.degree) > > Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic > transformations agree within ~0.1mas, and our results are in agreement > with other codes. I'll open an issue on the astropy repo and we can > discuss the technical details there. > > Tom > > Erik Tollerud wrote: > > Hi Tom and Joseph, > > > > Originally, Galactic coordinates were defined to ~arcmin precision > > relative to FK4 (and it's not clear one way or another if this is > > supposed to include E-terms or not). Since then there have been > > recalibrations to FK5, although there's not an "official" version > as far > > as we could find (just an appendix in a paper). > > > > So I think what's happening here is that the "shortcut" FK5-> Galactic > > transform is being used, which gives somewhat different results > because > > it made different arbitrary choices. We could just turn that off if we > > want to always be sure to use the FK4 transformation. > > > > It's not really clear which is the "right" answer, though. I think our > > original thinking was that no one really uses Galactic for subarcsec > > precision, and there FK4 transformations are a lot slower, so this > > "shortcut" makes sense... > > > > Hello, > > > > I've been porting pyregion to use astropy instead of kapteyn, and > tests > > with coordinate system conversions are slightly off. > > > > I think I've narrowed down the problem to my expectation that this > > should be nearly zero: > > > > In [21]: from astropy.coordinates import SkyCoord > > > > In [22]: from kapteyn import celestial > > > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > > frame='galactic').transform_to('fk5'); print(a) > > > dec=-59.2630875829 deg> > > > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > > [292.03306305555554], [1.7592747222222223]) > > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > > > In [25]: SkyCoord('171.15816386d -59.26319319d', > > frame='fk5').separation(a).to('arcsecond') > > Out[25]: > > > > > > My question is: am I misunderstanding something about these coordinate > > transformations to make them not equivalent? A third of an > arcsecond is > > significantly big deviation, particularly for HST or interferometry. > > AFAIK fk5 is J2000 in both libraries and galactic coordinates have no > > concept of epoch or equinox time. > > > > Thanks, > > Joseph Booker > > > > _______________________________________________ > > 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 > > > > > -- > > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * > Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk ) > phone +44-(0)1483 (prefix) -204927 (work) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From npkuin at gmail.com Sun Nov 16 11:42:30 2014 From: npkuin at gmail.com (Paul Kuin) Date: Sun, 16 Nov 2014 16:42:30 +0000 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: <5468C4BD.6010503@gmail.com> References: <54678E16.3020807@gmail.com> <5468C4BD.6010503@gmail.com> Message-ID: Hi Thomas, Good question. I browsed yesterday some of the papers of commission 8 members that have been linked from the SOFA web pages. There are two ways to look at this issue. The first one is that a "complete" set of observations can define a reference system. One such coming soon is that based on the GAIA mission, so based on optical sources. The system is typically tied to very remote sources, so Quasars. The current system is based on radio interferometric observations of quasars, and the next system (ICRS3) is probably being a refinement on that. We won't at first be dealing with that, but the errors in the positions are going to be of the order of 40-70 micro-arcseconds! I'm not sure what the position of the specialists in astrometry and coordinate systems is with regard to maintain the link to the older systems, like FK4, FK5, the old galactic coordinate system prior to the 1959 revision, etc. It seems to be a neglected area, and may be an issue with historical data. I just cc:-ed Norbert Zacharias, since I am getting out of my depth here. It may just be that we have touched upon an area that needs attention, or that we need to find the right person or publications. Regards, Paul On Sun, Nov 16, 2014 at 3:37 PM, Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > Hi Paul, > > Thanks for the input - as an aside, do you have any insight into whether > the IAU is considering proposals such as: > > http://www.aanda.org/articles/aa/pdf/2011/02/aa14961-10.pdf > > to re-define the Galactic coordinate system relative to ICRS? Having > Galactic coordinates defined relative to FK4 at the moment is not ideal > and introduces a lot of confusion, so re-defining galactic coordinates > relative to ICRS would be a nice solution. > > Cheers, > Tom > > > Paul Kuin wrote: > > I asked the chair of the IAU astrometry commission. Basically the > > current coordinate system is ICRS, and the galactic frame is defined > > with reference to that with the same accuracy. I think that is in a few > > milli arcsec accuracy. The SOFA implementation is to be consulted for > > actual algorithms, and I think this has been (or will be) implemented in > > astropy as the ERFA package. > > > > In summary, I would think the differences found by Joseph are way too > > large. It may be that the Kapteyn algorithms are also not compliant. > > Test should be done against the results of the ERFA/SOFA software. > > > > Thats all the help I can give. > > > > Paul > > > > On Sat, Nov 15, 2014 at 5:32 PM, Thomas Robitaille > > > > wrote: > > > > I've played around with this a bit more, and I found that if I set: > > > > _ngp_B1950 = FK4NoETerms(ra=192.25*u.degree, dec=27.4*u.degree) > > > > (not FK4) then I explicitly set: > > > > Galactic._ngp_J2000 = _lon0_B1950.transform_to(FK5) > > > > then if I set: > > > > Galactic._lon0_J2000 = Angle(122.931918539, u.degree) > > > > Then the astropy FK5 -> Galactic and FK5 -> FK4 -> Galactic > > transformations agree within ~0.1mas, and our results are in > agreement > > with other codes. I'll open an issue on the astropy repo and we can > > discuss the technical details there. > > > > Tom > > > > Erik Tollerud wrote: > > > Hi Tom and Joseph, > > > > > > Originally, Galactic coordinates were defined to ~arcmin precision > > > relative to FK4 (and it's not clear one way or another if this is > > > supposed to include E-terms or not). Since then there have been > > > recalibrations to FK5, although there's not an "official" version > > as far > > > as we could find (just an appendix in a paper). > > > > > > So I think what's happening here is that the "shortcut" FK5-> > Galactic > > > transform is being used, which gives somewhat different results > > because > > > it made different arbitrary choices. We could just turn that off > if we > > > want to always be sure to use the FK4 transformation. > > > > > > It's not really clear which is the "right" answer, though. I think > our > > > original thinking was that no one really uses Galactic for > subarcsec > > > precision, and there FK4 transformations are a lot slower, so this > > > "shortcut" makes sense... > > > > > > Hello, > > > > > > I've been porting pyregion to use astropy instead of kapteyn, and > > tests > > > with coordinate system conversions are slightly off. > > > > > > I think I've narrowed down the problem to my expectation that this > > > should be nearly zero: > > > > > > In [21]: from astropy.coordinates import SkyCoord > > > > > > In [22]: from kapteyn import celestial > > > > > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > > > frame='galactic').transform_to('fk5'); print(a) > > > > > dec=-59.2630875829 deg> > > > > > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > > > [292.03306305555554], [1.7592747222222223]) > > > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > > > > > In [25]: SkyCoord('171.15816386d -59.26319319d', > > > frame='fk5').separation(a).to('arcsecond') > > > Out[25]: > > > > > > > > > My question is: am I misunderstanding something about these > coordinate > > > transformations to make them not equivalent? A third of an > > arcsecond is > > > significantly big deviation, particularly for HST or > interferometry. > > > AFAIK fk5 is J2000 in both libraries and galactic coordinates have > no > > > concept of epoch or equinox time. > > > > > > Thanks, > > > Joseph Booker > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > -- > > > > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * > > Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk ) > > phone +44-(0)1483 (prefix) -204927 (work) > > mobile +44(0)7806985366 skype ID: npkuin > > Mullard Space Science Laboratory ? University College London ? > > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > > > _______________________________________________ > > 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 > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From long at stsci.edu Sun Nov 23 12:04:17 2014 From: long at stsci.edu (Knox Long) Date: Sun, 23 Nov 2014 17:04:17 +0000 Subject: [AstroPy] Access to comments in astropy.io.asccii Message-ID: I/we are trying to move to astropy.io.ascii.read for reading ascii.data, and for the most part this is working well. However, we often also want access to comment lines in our ascii data and I have not found any way to do this. Is there something I am missing. Here is an example of what I would like to be able to read: # TITLE= "test.ioncC3.dat" # Coord_Sys CYLIND x z var inwind i j 1.4000e+09 3.5000e+08 0.00e+00 -2 0 0 1.4000e+09 8.0805e+08 0.00e+00 -1 0 1 1.4000e+09 1.0575e+09 0.00e+00 -1 0 2 1.4000e+09 1.3840e+09 0.00e+00 -1 0 3 1.4000e+09 1.8113e+09 0.00e+00 -1 0 4 1.4000e+09 2.3705e+09 0.00e+00 -1 0 5 1.4000e+09 3.1023e+09 0.00e+00 -1 0 6 1.4000e+09 4.0600e+09 0.00e+00 -1 0 7 Thanks, Knox -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogelaar at astro.rug.nl Mon Nov 24 11:09:48 2014 From: vogelaar at astro.rug.nl (vogelaar at astro.rug.nl) Date: Mon, 24 Nov 2014 17:09:48 +0100 Subject: [AstroPy] astropy.coordinates vs kapteyn.celestial Coordinate Transformations In-Reply-To: <5468D639.4090104@astro.rug.nl> References: <89BF1DBF-1775-459A-A8E4-D03D42547822@gmail.com> <54678472.7090404@gmail.com> <05243347-28FE-46AC-90FF-4DE35A2CE6F1@gmail.com> <54678957.5050808@gmail.com> <54678E16.3020807@gmail.com> <5468C4BD.6010503@gmail.com> <5468D639.4090104@astro.rug.nl> Message-ID: <5ed03ff35fe995778f79c28f7eba229b.squirrel@www.intra.astro.rug.nl> Hello, There are two articles which support the decisions I made for the conversion of positions from fk5 to galactic in module celestial of the Kapteyn Package. The first article documents the rotation matrix that I used and the second article (written after the current version of celestial) documents the same matrix derived in a slightly different way. 1) Murray, C.A., 1989. The transformation of coordinates between systems of B1950.0 and J2000.0 and the principal galactic axes referred to J2000.0, Astron. Astrophys, 218, p.325-329, 2) Jia-Cheng Liu, Zi Zhu, Hong Zhang, Reconsidering the galactic coordinate system, arXiv:1010.3773 [astro-ph.GA] All the procedures implemented in celestial are documented in https://www.astro.rug.nl/software/kapteyn/celestialbackground.html The problem conversion mentioned by Joseph is: from kapteyn import celestial print celestial.sky2sky(celestial.galactic, celestial.fk5, [292.03306305555554], [1.7592747222222223]) [[ 171.158163857372 -59.263193188529]] which differs from the result by pyregion by a third of an arcsec. Murray proposed that the axes of the IAU1958 galactic coordinate system should be considered as absolute directions, unaffected by the E-term of aberration. This system is (in FITS terms) called FK4-NO-E. This approach has been approved by Adriaan Blaauw (private communications, 2008), so in fact I use: m1 = celestial.skymatrix(celestial.fk5, celestial.fk4_no_e) print m1[0] [[ 9.999256794957e-01 1.118148323917e-02 4.859003772314e-03] [ -1.118148322047e-02 9.999374848933e-01 -2.717029374405e-05] [ -4.859003815359e-03 -2.716259471425e-05 9.999881946024e-01]] This is the same matrix as Xo in Liu et al. in equation 9 m2 = celestial.skymatrix(celestial.fk4_no_e, celestial.galactic) In [27]: print m2[0] [[-0.066988739415 -0.872755765852 -0.483538914632] [ 0.492728466075 -0.45034695802 0.744584633283] [-0.867600811151 -0.188374601723 0.460199784784]] This is the same matrix as Nb in Liu et al. in equation 9 and the same as in Slalib (http://stsdas.stsci.edu/cgi-bin/gethelp.cgi?eg50.src) print m2[0]*m1[0] [[-0.054875539396 -0.873437104728 -0.48383499177 ] [ 0.494109453628 -0.444829594298 0.7469822487 ] [-0.867666135683 -0.198076389613 0.455983794521]] This is the same matrix as Nj in Liu et al. in equation 9 and Murray equation 33. The same matrix is constructed for: m3 = celestial.skymatrix(celestial.fk5, celestial.galactic) print m3[0] [[-0.054875539396 -0.873437104728 -0.48383499177 ] [ 0.494109453628 -0.444829594298 0.7469822487 ] [-0.867666135683 -0.198076389613 0.455983794521]] The inverse transformation is: lonlat= celestial.sky2sky(celestial.galactic, celestial.fk5, [0], [0]) With this expression we find the galactic center in equatorial coordinates: celestial.lon2hms(lonlat[0,0],prec=4) '17h45m37.1991s' celestial.lat2dms(lonlat[0,1],prec=4) '-28d56m10.2207s' which are the same values as in Liu et al. equation 11. For the pole: lonlat= celestial.sky2sky(celestial.galactic, celestial.fk5, [0], [90]) celestial.lon2hms(lonlat[0,0],prec=4) '12h51m26.2755s' celestial.lat2dms(lonlat[0,1],prec=4) ' 27d07m41.7043s' which are the same as the position given in Murray section 7.1 and Liu equation 10. So the transformation requires that the e-terms are removed. and it uses a rotation matrix which is documented in several articles and which guarantees that the galactic coordinate system is orthogonal. The suggestion of Thomas Robitaille seems therefore worthwhile to discuss. Martin > Hello, > > I've been porting pyregion to use astropy instead of kapteyn, and tests > with coordinate system conversions are slightly off. > > I think I've narrowed down the problem to my expectation that this should > be nearly zero: > > In [21]: from astropy.coordinates import SkyCoord > > In [22]: from kapteyn import celestial > > In [23]: a = SkyCoord('292.03306305555554d 1.7592747222222223d', > frame='galactic').transform_to('fk5'); print(a) > dec=-59.2630875829 deg> > > In [24]: celestial.sky2sky(celestial.galactic, celestial.fk5, > [292.03306305555554], [1.7592747222222223]) > Out[24]: matrix([[ 171.15816386, -59.26319319]]) > > In [25]: SkyCoord('171.15816386d -59.26319319d', > frame='fk5').separation(a).to('arcsecond') > Out[25]: > > > My question is: am I misunderstanding something about these coordinate > transformations to make them not equivalent? A third of an arcsecond is > significantly big deviation, particularly for HST or interferometry. AFAIK > fk5 is J2000 in both libraries and galactic coordinates have no concept of > epoch or equinox time. > > Thanks, > Joseph Booker > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From aldcroft at head.cfa.harvard.edu Mon Nov 24 15:18:02 2014 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 24 Nov 2014 15:18:02 -0500 Subject: [AstroPy] Access to comments in astropy.io.asccii In-Reply-To: References: Message-ID: On Sun, Nov 23, 2014 at 12:04 PM, Knox Long wrote: > I/we are trying to move to astropy.io.ascii.read for reading ascii.data, > and for the most part this is working well. However, we often also want > access to comment lines in our ascii data and I have not found any way to > do this. Is there something I am missing. Here is an example of what I > would like to be able to read: > > # TITLE= "test.ioncC3.dat" > # Coord_Sys CYLIND > x z var inwind i j > 1.4000e+09 3.5000e+08 0.00e+00 -2 0 0 > 1.4000e+09 8.0805e+08 0.00e+00 -1 0 1 > 1.4000e+09 1.0575e+09 0.00e+00 -1 0 2 > 1.4000e+09 1.3840e+09 0.00e+00 -1 0 3 > 1.4000e+09 1.8113e+09 0.00e+00 -1 0 4 > 1.4000e+09 2.3705e+09 0.00e+00 -1 0 5 > 1.4000e+09 3.1023e+09 0.00e+00 -1 0 6 > 1.4000e+09 4.0600e+09 0.00e+00 -1 0 7 > Hi Knox, Getting the comment lines is possible in your case with the following: >>> from astropy.io import ascii >>> reader = ascii.get_reader(Reader=ascii.Basic) >>> dat = reader.read(filename) >>> comments = reader.comment_lines This is not terribly convenient, and you cannot guess the format, etc. I've submitted an issue (https://github.com/astropy/astropy/issues/3136) and hopefully we can make a better mechanism. This has occurred to me before as a problem. Cheers, Tom > Thanks, > Knox > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: