From thomas.robitaille at gmail.com Sun Dec 1 15:29:01 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sun, 1 Dec 2013 21:29:01 +0100 Subject: [AstroPy] Job Ad: Scientific (Python) Software Developer in a Max Planck Research Group In-Reply-To: References: Message-ID: For anyone interested in the job ad I sent out a couple of weeks ago, the AAS job register ad is now out: http://jobregister.aas.org/job_view?JobID=46897 Please let me know if you have any questions! Cheers, Tom On 21 November 2013 15:49, Thomas Robitaille wrote: > Dear colleagues, > > I am hiring someone to work on Scientific Python software development > in my research group at the Max Planck Institute for Astronomy in > Heidelberg: > > http://www.mpia.de/Public/MPIA/jobs/13-16en.pdf > > This is a fixed-term position, and you do not need to have a formal > computer science education to apply - the position would therefore be > ideal for example for people in Astronomy who would like to transition > to a software development job and perfect their coding skills, or > people with a computer science background who want to learn more about > Astronomy. > > If you have any questions about the position, please do not hesitate > to contact me at robitaille-mprg-applications at mpia.de > > Please forward this message to anyone that you think might be interested! > > Best regards, > Thomas Robitaille From foadhanassi-savari at hotmail.co.uk Mon Dec 2 06:40:31 2013 From: foadhanassi-savari at hotmail.co.uk (foad hanassi-savari) Date: Mon, 2 Dec 2013 11:40:31 +0000 Subject: [AstroPy] problem with 'test the installation' of python Message-ID: Hi there, I have installed ipython via anaconda and it seems to be working fine and I installed the packages as instructed on the website: http://python4astronomers.github.io/installation/python_install.html. I have installed the packages as instructed and am able to import astropy, aplpy, pyregion and pyparsing.The issue rises when trying to test the installation! the magic cells in my version of the ipython (ipython(py2.7)) are written as %%python (I don't really understand the difference between these and the suggested test on the website). This is not a problem, however, %%ipython is not listed on my cell magic list (%lsmagic) but when I type %%ipython I don't get an error! print numpy.__version__, prints 1.7.1 print scipy.__version__, prints 0.13.0and print matplotlib.__version__, gives me an error unless I import matplotlib (I don't know if that is a problem or not!) But the main issue is that I don't get a plot of sin wave, instead when I type (plot(x, sin(x)) I get an error saying that plot is not defined! Also, I am using windows. Can you please help me out here, I am planning to study astrophysics and I really need/want to be good at programming. Thank you, -------------- next part -------------- An HTML attachment was scrubbed... URL: From indiajoe at gmail.com Mon Dec 2 06:59:09 2013 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Mon, 2 Dec 2013 17:29:09 +0530 Subject: [AstroPy] problem with 'test the installation' of python In-Reply-To: References: Message-ID: Hi, For the plot issue, Try giving %pylab after starting the ipython session before the plot command. It will basically load numpy and matplotlib to work interactively. http://ipython.org/ipython-doc/stable/api/generated/IPython.core.magics.pylab.html?highlight=pylab#IPython.core.magics.pylab.PylabMagics.pylab If you plan to adapt the codes to script later, it is better to do plots in the straight forward way as follows x=range(10) import matplotlib.pyplot as plt plt.plot(x,sin(x)) plt.show() -cheers joe On 2 December 2013 17:10, foad hanassi-savari < foadhanassi-savari at hotmail.co.uk> wrote: > Hi there, > > I have installed ipython via anaconda and it seems to be working fine and > I installed the packages as instructed on the website: > http://python4astronomers.github.io/installation/python_install.html. > I have installed the packages as instructed and am able to import astropy, > aplpy, pyregion and pyparsing. > The issue rises when trying to test the installation! the magic cells in > my version of the ipython (ipython(py2.7)) are written as %%python (I don't > really understand the difference between these and the suggested test on > the website). This is not a problem, however, %%ipython is not listed on my > cell magic list (%lsmagic) but when I type %%ipython I don't get an error! > print numpy.__version__, prints 1.7.1 > print scipy.__version__, prints 0.13.0 > and > print matplotlib.__version__, gives me an error unless I import matplotlib > (I don't know if that is a problem or not!) > > But the main issue is that I don't get a plot of sin wave, instead when I > type (plot(x, sin(x)) I get an error saying that plot is not defined! > > Also, I am using windows. > > Can you please help me out here, I am planning to study astrophysics and I > really need/want to be good at programming. > > Thank you, > > > _______________________________________________ > 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 http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinberoiz at gmail.com Tue Dec 3 14:54:33 2013 From: martinberoiz at gmail.com (Martin Beroiz) Date: Tue, 3 Dec 2013 13:54:33 -0600 Subject: [AstroPy] iraf-like library? Message-ID: Hello all, I'm a newbie and I'm trying to do some photometry in python without getting into iraf. Probably this has been asked many times, but I couldn't find an answer. Is there any equivalent python library that works like iraf? I don't mean pyraf because that would require installing iraf am I right? I plan to build some pipeline in python and I would like to make it iraf-independent. I particularly would like to do stuff like daophot and also any tool that can find individual sources on an image (or at least count them). Thanks in advance, M. From kyle at anl.gov Tue Dec 3 15:15:59 2013 From: kyle at anl.gov (Kyle Barbary) Date: Tue, 3 Dec 2013 14:15:59 -0600 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> Message-ID: The TPV projection [1] is also being used by the Dark Energy Survey. I think support for TPV would have to be implemented in Mark Calabretta's wcslib C library, which underlies astropy.wcs. It seems like programs that do support TPV generally use the "other" wcs library [2]. Does anyone know if support for TPV is planned for wcslib? It would be really nice to have. [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html On Tue, Nov 26, 2013 at 11:54 AM, Jean-Baptiste Marquette wrote: > Hi Astropy gurus, > > I'm just testing this new and impressive release with images from the SSO > SkyMapper telescope, and got trouble with the TPV projection, since these > images were calibrated using Emmanuel Bertin's SCAMP package. The message > is: > > WARNING: FITSFixedWarning: 'celfix' made the change 'Unrecognized > projection code (TPV in CTYPE1)'. [astropy.wcs.wcs] > > I previously seamlessly used the astLib package, and both ds9 and > Gaia/Starlink image browsers recognize the TPV projection. Integration in > Astropy's wcs module would be greatly appreciated as well. > > Thanks for your help, > Cheers, > JB > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Tue Dec 3 15:20:48 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 3 Dec 2013 20:20:48 +0000 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> Message-ID: On 3 December 2013 20:15, Kyle Barbary wrote: > The TPV projection [1] is also being used by the Dark Energy Survey. I > think support for TPV would have to be implemented in Mark Calabretta's > wcslib C library, which underlies astropy.wcs. It seems like programs that > do support TPV generally use the "other" wcs library [2]. Does anyone know > if support for TPV is planned for wcslib? > It would be really nice to have. > > Not part of astropy, but pyast includes support for TPV. pyast is a python wrapper round the AST library, which is the WCS library used by DS9. See: http://dsberry.github.io/starlink/pyast.html David > [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html > [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html > > > On Tue, Nov 26, 2013 at 11:54 AM, Jean-Baptiste Marquette > wrote: > >> Hi Astropy gurus, >> >> I'm just testing this new and impressive release with images from the SSO >> SkyMapper telescope, and got trouble with the TPV projection, since these >> images were calibrated using Emmanuel Bertin's SCAMP package. The message >> is: >> >> WARNING: FITSFixedWarning: 'celfix' made the change 'Unrecognized >> projection code (TPV in CTYPE1)'. [astropy.wcs.wcs] >> >> I previously seamlessly used the astLib package, and both ds9 and >> Gaia/Starlink image browsers recognize the TPV projection. Integration in >> Astropy's wcs module would be greatly appreciated as well. >> >> Thanks for your help, >> Cheers, >> JB >> >> >> _______________________________________________ >> 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 shupe at ipac.caltech.edu Tue Dec 3 15:42:01 2013 From: shupe at ipac.caltech.edu (David Shupe) Date: Tue, 3 Dec 2013 12:42:01 -0800 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> Message-ID: <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> On Dec 3, 2013, at 12:15 PM, Kyle Barbary wrote: > The TPV projection [1] is also being used by the Dark Energy Survey. I think support for TPV would have to be implemented in Mark Calabretta's wcslib C library, which underlies astropy.wcs. It seems like programs that do support TPV generally use the "other" wcs library [2]. Does anyone know if support for TPV is planned for wcslib? > It would be really nice to have. I believe Mark Calabretta is limiting his wcslib to implementing the WCS standard. TPV, like SIP [3], is a registered convention but is not a part of the official standard. As I understand it, there's some modification done to Calabretta's library in astropy.wcs to support SIP. Michael Droettboom is the expert on the details. I have code that translates between SIP and TPV [4] that I'd like to incorporate into astropy.wcs, but there's some paperwork to push through to be able to release it. David Shupe IPAC/Caltech > [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html > [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html > [3] http://fits.gsfc.nasa.gov/registry/sip.html [4] http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1363103 also at http://web.ipac.caltech.edu/staff/shupe/reprints/SIP_to_PV_SPIE2012.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle at anl.gov Tue Dec 3 15:49:12 2013 From: kyle at anl.gov (Kyle Barbary) Date: Tue, 3 Dec 2013 14:49:12 -0600 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> Message-ID: Thanks for the explanation David. I wonder if there should be a blurb describing this, and listing the supported projections (that *are* part of the WCS standard) in the astropy.wcs docs? Or is something like that already there and I missed it? - Kyle On Tue, Dec 3, 2013 at 2:42 PM, David Shupe wrote: > > On Dec 3, 2013, at 12:15 PM, Kyle Barbary wrote: > > The TPV projection [1] is also being used by the Dark Energy Survey. I > think support for TPV would have to be implemented in Mark Calabretta's > wcslib C library, which underlies astropy.wcs. It seems like programs that > do support TPV generally use the "other" wcs library [2]. Does anyone know > if support for TPV is planned for wcslib? > It would be really nice to have. > > > I believe Mark Calabretta is limiting his wcslib to implementing the WCS > standard. TPV, like SIP [3], is a registered convention but is not a part > of the official standard. > > As I understand it, there's some modification done to Calabretta's library > in astropy.wcs to support SIP. Michael Droettboom is the expert on the > details. > > I have code that translates between SIP and TPV [4] that I'd like to > incorporate into astropy.wcs, but there's some paperwork to push through to > be able to release it. > > David Shupe > IPAC/Caltech > > [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html > [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html > > > [3] http://fits.gsfc.nasa.gov/registry/sip.html > [4] > http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1363103 also > at http://web.ipac.caltech.edu/staff/shupe/reprints/SIP_to_PV_SPIE2012.pdf > > > _______________________________________________ > 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 Tue Dec 3 16:20:29 2013 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 3 Dec 2013 16:20:29 -0500 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> Message-ID: <529E4B1D.6060208@stsci.edu> On 12/03/2013 03:42 PM, David Shupe wrote: > As I understand it, there's some modification done to Calabretta's > library in astropy.wcs to support SIP. Michael Droettboom is the > expert on the details. Effectively, yes. More accurately, astropy.wcs adds a layer on top of wcslib to support SIP. There are not modifications made to wcslib itself. > > I have code that translates between SIP and TPV [4] that I'd like to > incorporate into astropy.wcs, but there's some paperwork to push > through to be able to release it. That would be most welcome, I'm sure. Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com From mdroe at stsci.edu Tue Dec 3 16:22:33 2013 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 3 Dec 2013 16:22:33 -0500 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> Message-ID: <529E4B99.6030908@stsci.edu> On 12/03/2013 03:49 PM, Kyle Barbary wrote: > Thanks for the explanation David. I wonder if there should be a blurb > describing this, and listing the supported projections (that *are* > part of the WCS standard) in the astropy.wcs docs? Or is something > like that already there and I missed it? I don't think we do have it in the astropy documentation, but we should. This is what it is (copied from the wcslib source code): |const char prj_codes[28][4] = {"AZP", "SZP", "TAN", "STG", "SIN", "ARC", "ZPN", "ZEA", "AIR", "CYP", "CEA", "CAR", "MER", "COP", "COE", "COD", "COO", "SFL", "PAR", "MOL", "AIT", "BON", "PCO", "TSC", "CSC", "QSC", "HPX", "XPH"};| Mike > - Kyle > > > On Tue, Dec 3, 2013 at 2:42 PM, David Shupe > wrote: > > > On Dec 3, 2013, at 12:15 PM, Kyle Barbary > wrote: > >> The TPV projection [1] is also being used by the Dark Energy >> Survey. I think support for TPV would have to be implemented in >> Mark Calabretta's wcslib C library, which underlies astropy.wcs. >> It seems like programs that do support TPV generally use the >> "other" wcs library [2]. Does anyone know if support for TPV is >> planned for wcslib? >> It would be really nice to have. > > I believe Mark Calabretta is limiting his wcslib to implementing > the WCS standard. TPV, like SIP [3], is a registered convention > but is not a part of the official standard. > > As I understand it, there's some modification done to Calabretta's > library in astropy.wcs to support SIP. Michael Droettboom is the > expert on the details. > > I have code that translates between SIP and TPV [4] that I'd like > to incorporate into astropy.wcs, but there's some paperwork to > push through to be able to release it. > > David Shupe > IPAC/Caltech > >> [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html >> [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html >> > > [3] http://fits.gsfc.nasa.gov/registry/sip.html > [4] > http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1363103 also > at > http://web.ipac.caltech.edu/staff/shupe/reprints/SIP_to_PV_SPIE2012.pdf > > > _______________________________________________ > 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 -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Tue Dec 3 16:39:36 2013 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 3 Dec 2013 16:39:36 -0500 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: <529E4B99.6030908@stsci.edu> References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> <529E4B99.6030908@stsci.edu> Message-ID: <529E4F98.4050106@stsci.edu> I've created a pull request to add these to the documentation. See here: https://github.com/astropy/astropy/pull/1861 Comments welcome. Mike On 12/03/2013 04:22 PM, Michael Droettboom wrote: > > On 12/03/2013 03:49 PM, Kyle Barbary wrote: > >> Thanks for the explanation David. I wonder if there should be a blurb >> describing this, and listing the supported projections (that *are* >> part of the WCS standard) in the astropy.wcs docs? Or is something >> like that already there and I missed it? > > I don't think we do have it in the astropy documentation, but we > should. This is what it is (copied from the wcslib source code): > > |const char prj_codes[28][4] = > {"AZP", "SZP", "TAN", "STG", "SIN", "ARC", "ZPN", "ZEA", "AIR", "CYP", > "CEA", "CAR", "MER", "COP", "COE", "COD", "COO", "SFL", "PAR", "MOL", > "AIT", "BON", "PCO", "TSC", "CSC", "QSC", "HPX", "XPH"};| > Mike > >> - Kyle >> >> >> On Tue, Dec 3, 2013 at 2:42 PM, David Shupe > > wrote: >> >> >> On Dec 3, 2013, at 12:15 PM, Kyle Barbary > > wrote: >> >>> The TPV projection [1] is also being used by the Dark Energy >>> Survey. I think support for TPV would have to be implemented in >>> Mark Calabretta's wcslib C library, which underlies astropy.wcs. >>> It seems like programs that do support TPV generally use the >>> "other" wcs library [2]. Does anyone know if support for TPV is >>> planned for wcslib? >>> It would be really nice to have. >> >> I believe Mark Calabretta is limiting his wcslib to implementing >> the WCS standard. TPV, like SIP [3], is a registered convention >> but is not a part of the official standard. >> >> As I understand it, there's some modification done to >> Calabretta's library in astropy.wcs to support SIP. Michael >> Droettboom is the expert on the details. >> >> I have code that translates between SIP and TPV [4] that I'd like >> to incorporate into astropy.wcs, but there's some paperwork to >> push through to be able to release it. >> >> David Shupe >> IPAC/Caltech >> >>> [1] http://fits.gsfc.nasa.gov/registry/tpvwcs.html >>> [2] http://tdc-www.harvard.edu/software/wcstools/libwcs.subs.html >>> >> >> [3] http://fits.gsfc.nasa.gov/registry/sip.html >> [4] >> http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1363103 also >> at >> http://web.ipac.caltech.edu/staff/shupe/reprints/SIP_to_PV_SPIE2012.pdf >> >> >> _______________________________________________ >> 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 > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquett at iap.fr Wed Dec 4 05:04:40 2013 From: marquett at iap.fr (Jean-Baptiste Marquette) Date: Wed, 4 Dec 2013 11:04:40 +0100 Subject: [AstroPy] Astropy 0.3 and TPV projection In-Reply-To: <529E4F98.4050106@stsci.edu> References: <0A381D81-B7BC-4C46-B778-F500EB5902D5@iap.fr> <52C8AE82-78EF-4F8C-BF31-5814B5B178A1@ipac.caltech.edu> <529E4B99.6030908@stsci.edu> <529E4F98.4050106@stsci.edu> Message-ID: <7E748C4D-F348-4348-B68A-A7F7B088EC9F@iap.fr> Hi Michael et al. > I've created a pull request to add these to the documentation. See here: > > https://github.com/astropy/astropy/pull/1861 Thanks for this useful and interesting conversation, the context appears more clear now. Cheers, JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From cslocum at stsci.edu Wed Dec 4 13:13:33 2013 From: cslocum at stsci.edu (Christine Slocum) Date: Wed, 4 Dec 2013 18:13:33 +0000 Subject: [AstroPy] Ureka 1.0 is now available Message-ID: STScI and Gemini are announcing the release of Ureka 1.0. Improvements (with respect to beta 6): - test for completeness of OS library dependencies - many installation improvements - expanded documentation - support for Ubuntu 13.10, Fedora 19, and OS X Mavericks (10.9) - menu shortcuts on Linux - optional support for MySQL and PostgreSQL - bundled Fortran run-time library is always used to avoid conflict with OS version(s) Updated packages: - Gemini IRAF 1.12 - virtualenv (1.10.1) - SciPy (0.13.0) - wheel (0.22.0) - scikit-image (0.9.3) - Pillow (2.2.1) - CFITSIO (3350) - scikit-learn (0.14.1) - Tornado (3.1.1) - setuptools (1.3) - NumPy (1.8.0) - stsci.distutils (0.3.2) - astropy (0.3) - d2to1 (0.2.11) - PyParsing (2.0.1) New packages: - PyKE (2.4.0) - Six (1.4.1) - PyTZ (2013.8) - kapteyn (2.2.1b17) - BeautifulSoup (3.2.1) - mechanize (0.2.5) - jsonschema (2.1.0) - numexpr (2.2.2) - Dateutil (2.2) - mock (1.0.1) Ureka is a binary packaging installer for common astronomical software (primarily for the UV/Optical/IR community). The goals of the Ureka installer are to: 1) minimize the number of actions needed to install all the different software components. We are seeking a "one button install" (it's not quite one button, but not far from it). 2) permit installation without requiring system privileges. 3) make installs as problem-free as possible for the great majority of users. 4) allow users to install their own software (particularly Python-based) within this framework, or update versions of software within the framework. 5) permit different Ureka installations to coexist and to easily switch between them. 6) enable installing different versions of the same software package under a particular Ureka installation. 7) support Macs and most popular Linux variants. Ureka does not use LD_LIBRARY_PATH (or its Mac equivalent), nor require PYTHONPATH, minimizing the possibility of affecting existing software after installation or use. Should conflicts nevertheless arise, Ureka can easily be disabled temporarily or enabled only in specific terminal windows. Keep in mind that no installation system is completely foolproof (that's very nearly impossible to achieve). In particular, when users update or add software to the Ureka framework, they increase the risk of breaking something, but we feel that is an option that users should have as long as they understand the possible risks. This release includes IRAF 2.16 and associated packages for IRAF, DS9, and a fairly full suite of Python scientific software packages (e.g., numpy, scipy, and matplotlib). The full listing of included software can be found at this link: http://ssb.stsci.edu/ureka/1.0/docs/components.html Ureka can be downloaded from: http://ssb.stsci.edu/ureka/ (choose "1.0"). Installation and usage instructions can be found on the same web page. Please send questions or feedback to help at stsci.edu. From 20175132 at nwu.ac.za Thu Dec 5 01:58:44 2013 From: 20175132 at nwu.ac.za (Robert Czanik) Date: Thu, 05 Dec 2013 08:58:44 +0200 Subject: [AstroPy] iraf-like library? In-Reply-To: References: Message-ID: <52A04044020000BA002F30C6@v-pgw-nlx2.p.nwu.ac.za> Hi Martin There is a Python suite called astropysics which includes some photometric routines. You can find it through pip or the website is: http://pythonhosted.org/Astropysics/ Regrards RJC Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html >>> Martin Beroiz 12/03/13 9:55 PM >>> Hello all, I'm a newbie and I'm trying to do some photometry in python without getting into iraf. Probably this has been asked many times, but I couldn't find an answer. Is there any equivalent python library that works like iraf? I don't mean pyraf because that would require installing iraf am I right? I plan to build some pipeline in python and I would like to make it iraf-independent. I particularly would like to do stuff like daophot and also any tool that can find individual sources on an image (or at least count them). Thanks in advance, M. _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Deil at mpi-hd.mpg.de Thu Dec 5 09:07:10 2013 From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil) Date: Thu, 5 Dec 2013 15:07:10 +0100 Subject: [AstroPy] General method to compute pixel solid angle for any WCS projection? Message-ID: Hi, does anyone know a good general method to compute pixel solid angles for arbitrary WCS FITS maps? I know there is HEALPIX and for some WCS projections there are analytical formulae for pixel area, but I was wondering if there is a standard robust method to implement it for any WCS. I did find methods to compute the area of polygons on the sphere: http://stackoverflow.com/questions/4681737/how-to-calculate-the-area-of-a-polygon-on-the-earths-surface-using-python Would representing each pixel as a 4-corner polygon (or subdividing the pixel sides into parts if the pixels are large and precision is needed) and using that method be the best option? Christoph From eperez at iaa.es Thu Dec 5 09:01:34 2013 From: eperez at iaa.es (ES.Enrique Perez) Date: Thu, 5 Dec 2013 08:01:34 -0600 Subject: [AstroPy] astropy.cosmology Message-ID: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> Geetings. I may have overlooked the answer in the docs, but really haven't been able to find it: astropy.cosmology age(some_redshift) provides the age corresponding to a given redshfit, but what is the reverse function that provides the redshift corresponding to a given age? Thanks, Enrique From jdsant at iaa.es Thu Dec 5 12:06:44 2013 From: jdsant at iaa.es (Juande Santander Vela) Date: Thu, 5 Dec 2013 14:06:44 -0300 Subject: [AstroPy] astropy.cosmology In-Reply-To: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> References: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> Message-ID: Hi, Enrique, I don?t find the age function in astropy.cosmology, but the loopback_time, but I think the answer stands. If you want to obtain the inverse function, assuming loopback_time is continuous, and it should, you can use scipy.optimize methods to find out the redshift. For instance, the redshift corresponding to a 0.2Gyears lookback time, you can do: from scipy.optimize import newton import astropy.cosmology as cosmo newton(lambda x: cosmo.lookback_time(x).value-0.2, 0) or, in general: from scipy.optimize import newton import astropy.cosmology as cosmo def redshift_from_lookback_time(gyears): return newton(lambda x: cosmo.lookback_time(x).value-gyears, 0) Hope that helps. El 05/12/2013, a las 11:01, ES.Enrique Perez escribi?: > Geetings. > > I may have overlooked the answer in the docs, but really haven't been able to find it: > > astropy.cosmology age(some_redshift) provides the age corresponding to a given redshfit, > but what is the reverse function that provides the redshift corresponding to a given age? > > Thanks, > Enrique > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Juande Santander Vela VIA-SKA Project Manager Instituto de Astrof?sica de Andaluc?a (IAA-CSIC) Glorieta de la Astronom?a s/n, E-18008, Granada, Spain Henry Ford: La mayor?a de la gente gasta m?s tiempo y energ?as en intentar esquivar los problemas que en tratar de resolverlos. From mdroe at stsci.edu Thu Dec 5 12:11:51 2013 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 5 Dec 2013 12:11:51 -0500 Subject: [AstroPy] General method to compute pixel solid angle for any WCS projection? In-Reply-To: References: Message-ID: <52A0B3D7.3070906@stsci.edu> On 12/05/2013 09:07 AM, Christoph Deil wrote: > Hi, > > does anyone know a good general method to compute pixel solid angles for arbitrary WCS FITS maps? > > I know there is HEALPIX and for some WCS projections there are analytical formulae for pixel area, but I was wondering if there is a standard robust method to implement it for any WCS. > > I did find methods to compute the area of polygons on the sphere: > http://stackoverflow.com/questions/4681737/how-to-calculate-the-area-of-a-polygon-on-the-earths-surface-using-python > Would representing each pixel as a 4-corner polygon (or subdividing the pixel sides into parts if the pixels are large and precision is needed) and using that method be the best option? Yes, I was going to suggest something similar. From a quick glance at the stackoverflow page, it seems some of those methods may have distortions or discontinuities at the poles, and this is the shortcoming of many geography-based methods. I would do something like: 1) transform the four corners of the pixel using wcs.all_pix2sky 2) project the Ra and Dec into Cartesian point on the unit sphere: x = cos(ra) * cos(dec), y = sin(ra) * cos(dec), z = sin(dec) 3) The area of a well-behaved polygon on the unit sphere is "sum(interior_angles) - (n - 2)pi", where n is the number of angles. So first we calculate the interior angles: Given points A, B, C, the angle at B is: acos((B x (A x B)) . (B x (C x B))) (x for cross product, . for dot product). I have a spherical geometry library that *somewhat* does this, but given that it tries to handle arbitrary polygons (including concave and self-crossing ones), it's a lot more complex and unfortunately still a little prone to blowing up. The simple case of a quadrilateral is much simpler -- and I should probably add that to my library. This is still an approximation, of course, as it assumes the edges of the pixel are a straight shot along on the unit sphere rather than taking into account any distortion at the subpixel level. Usually this doesn't matter, of course. Mike > > Christoph > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com From thomas.robitaille at gmail.com Thu Dec 5 12:36:31 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 5 Dec 2013 18:36:31 +0100 Subject: [AstroPy] General method to compute pixel solid angle for any WCS projection? In-Reply-To: <52A0B3D7.3070906@stsci.edu> References: <52A0B3D7.3070906@stsci.edu> Message-ID: Hi Christoph and Mike, Montage does exactly this and I started wrapping (with permission from the Montage developers) the core routine in Python: https://github.com/astrofrog/python-reprojection I didn't get very far due to lack of time, but you're very welcome to check this out. You first need to read in an image with WCS, convert the pixel corners to world coordinates, then use the routine I'm attempting to wrap, and it should give the overlap area. Because I didn't get very far yet, it may not return the area yet, but it should. Feel free to work on the wrapper to improve it! Cheers, Tom On 5 December 2013 18:11, Michael Droettboom wrote: > On 12/05/2013 09:07 AM, Christoph Deil wrote: >> Hi, >> >> does anyone know a good general method to compute pixel solid angles for arbitrary WCS FITS maps? >> >> I know there is HEALPIX and for some WCS projections there are analytical formulae for pixel area, but I was wondering if there is a standard robust method to implement it for any WCS. >> >> I did find methods to compute the area of polygons on the sphere: >> http://stackoverflow.com/questions/4681737/how-to-calculate-the-area-of-a-polygon-on-the-earths-surface-using-python >> Would representing each pixel as a 4-corner polygon (or subdividing the pixel sides into parts if the pixels are large and precision is needed) and using that method be the best option? > > Yes, I was going to suggest something similar. From a quick glance at > the stackoverflow page, it seems some of those methods may have > distortions or discontinuities at the poles, and this is the shortcoming > of many geography-based methods. > > I would do something like: > > 1) transform the four corners of the pixel using wcs.all_pix2sky > > 2) project the Ra and Dec into Cartesian point on the unit sphere: > > x = cos(ra) * cos(dec), > y = sin(ra) * cos(dec), > z = sin(dec) > > 3) The area of a well-behaved polygon on the unit sphere is > "sum(interior_angles) - (n - 2)pi", where n is the number of angles. So > first we calculate the interior angles: > > Given points A, B, C, the angle at B is: > > acos((B x (A x B)) . (B x (C x B))) > > (x for cross product, . for dot product). > > I have a spherical geometry library that *somewhat* does this, but given > that it tries to handle arbitrary polygons (including concave and > self-crossing ones), it's a lot more complex and unfortunately still a > little prone to blowing up. The simple case of a quadrilateral is much > simpler -- and I should probably add that to my library. > > This is still an approximation, of course, as it assumes the edges of > the pixel are a straight shot along on the unit sphere rather than > taking into account any distortion at the subpixel level. Usually this > doesn't matter, of course. > > Mike > > >> >> Christoph >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From martinberoiz at gmail.com Thu Dec 5 13:55:37 2013 From: martinberoiz at gmail.com (martin) Date: Thu, 5 Dec 2013 12:55:37 -0600 Subject: [AstroPy] iraf-like library? In-Reply-To: <52A04044020000BA002F30C6@v-pgw-nlx2.p.nwu.ac.za> References: <52A04044020000BA002F30C6@v-pgw-nlx2.p.nwu.ac.za> Message-ID: <1C04831F-141A-4C57-87BA-F1BEFCA0DF89@gmail.com> Thanks, I realize now that my question might have been a bit off-topic since this is a list for the Astropy package, but I thank your replies. This is what I needed, thanks. M. On Dec 5, 2013, at 12:58 AM, Robert Czanik <20175132 at nwu.ac.za> wrote: > Hi Martin > > There is a Python suite called astropysics which includes some photometric routines. > You can find it through pip or the website is: http://pythonhosted.org/Astropysics/ > > Regrards > RJC > > > Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html > > > >>> Martin Beroiz 12/03/13 9:55 PM >>> > Hello all, > > I'm a newbie and I'm trying to do some photometry in python without getting into iraf. > Probably this has been asked many times, but I couldn't find an answer. > Is there any equivalent python library that works like iraf? I don't mean pyraf because > that would require installing iraf am I right? > > I plan to build some pipeline in python and I would like to make it iraf-independent. > I particularly would like to do stuff like daophot and also any tool that can find individual > sources on an image (or at least count them). > > Thanks in advance, > M. > _______________________________________________ > 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 googlemail.com Fri Dec 6 05:30:20 2013 From: deil.christoph at googlemail.com (Christoph Deil) Date: Fri, 6 Dec 2013 11:30:20 +0100 Subject: [AstroPy] General method to compute pixel solid angle for any WCS projection? In-Reply-To: References: <52A0B3D7.3070906@stsci.edu> Message-ID: <781DC637-F8FD-42CF-AAEB-52F239CBEB4A@gmail.com> Hi Mike and Tom, thank you very much for your replies ? very helpful! Christoph On 05 Dec 2013, at 18:36, Thomas Robitaille wrote: > Hi Christoph and Mike, > > Montage does exactly this and I started wrapping (with permission from > the Montage developers) the core routine in Python: > > https://github.com/astrofrog/python-reprojection > > I didn't get very far due to lack of time, but you're very welcome to > check this out. You first need to read in an image with WCS, convert > the pixel corners to world coordinates, then use the routine I'm > attempting to wrap, and it should give the overlap area. Because I > didn't get very far yet, it may not return the area yet, but it > should. Feel free to work on the wrapper to improve it! > > Cheers, > Tom > > On 5 December 2013 18:11, Michael Droettboom wrote: >> On 12/05/2013 09:07 AM, Christoph Deil wrote: >>> Hi, >>> >>> does anyone know a good general method to compute pixel solid angles for arbitrary WCS FITS maps? >>> >>> I know there is HEALPIX and for some WCS projections there are analytical formulae for pixel area, but I was wondering if there is a standard robust method to implement it for any WCS. >>> >>> I did find methods to compute the area of polygons on the sphere: >>> http://stackoverflow.com/questions/4681737/how-to-calculate-the-area-of-a-polygon-on-the-earths-surface-using-python >>> Would representing each pixel as a 4-corner polygon (or subdividing the pixel sides into parts if the pixels are large and precision is needed) and using that method be the best option? >> >> Yes, I was going to suggest something similar. From a quick glance at >> the stackoverflow page, it seems some of those methods may have >> distortions or discontinuities at the poles, and this is the shortcoming >> of many geography-based methods. >> >> I would do something like: >> >> 1) transform the four corners of the pixel using wcs.all_pix2sky >> >> 2) project the Ra and Dec into Cartesian point on the unit sphere: >> >> x = cos(ra) * cos(dec), >> y = sin(ra) * cos(dec), >> z = sin(dec) >> >> 3) The area of a well-behaved polygon on the unit sphere is >> "sum(interior_angles) - (n - 2)pi", where n is the number of angles. So >> first we calculate the interior angles: >> >> Given points A, B, C, the angle at B is: >> >> acos((B x (A x B)) . (B x (C x B))) >> >> (x for cross product, . for dot product). >> >> I have a spherical geometry library that *somewhat* does this, but given >> that it tries to handle arbitrary polygons (including concave and >> self-crossing ones), it's a lot more complex and unfortunately still a >> little prone to blowing up. The simple case of a quadrilateral is much >> simpler -- and I should probably add that to my library. Is this library open source? >> >> This is still an approximation, of course, as it assumes the edges of >> the pixel are a straight shot along on the unit sphere rather than >> taking into account any distortion at the subpixel level. Usually this >> doesn't matter, of course. >> >> Mike >> >> >>> >>> Christoph >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> -- >> _ >> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >> >> http://www.droettboom.com >> >> _______________________________________________ >> 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 hoangthuong.hust at gmail.com Fri Dec 6 07:29:42 2013 From: hoangthuong.hust at gmail.com (=?UTF-8?B?SG/DoG5nIMSQ4bupYyBUaMaw4budbmc=?=) Date: Fri, 6 Dec 2013 19:29:42 +0700 Subject: [AstroPy] Convert GPS time to UTC time Message-ID: Hi, May anyone help me? I want to write a program convert GPS time to UTC time. Then how can I understand the algorithm ? Thank you ! -- ================================================ Hoang Duc Thuong Universit? des Sciences et des Technologies de Hanoi(USTH) University of Science and Technology of Hanoi(USTH) Hanoi University of Science and Technology (HUST) Email: hoangthuong.hust at gmail.com Tel: +84 01692887738 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Fri Dec 6 09:11:59 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Fri, 6 Dec 2013 14:11:59 +0000 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: GPS is offset by 19 seconds from TAI. TAI is itself offset from UTC by an integer number of seconds that increments each time a leap second occurs. So it's pretty easy to code, but you need to know what the current UTC-TAI value is. As an example, here is how to could be done using pyast. pyast does not yet support GPS directly, but it's a simple job to add on the extra 19 seconds. David import starlink.Ast as Ast # Create frames describing UTC and TAI, in seconds. Indicate that values # should be formatted using a standard ISO date and time string with 3 # decimal places in the seconds field. tai_frame = Ast.TimeFrame( "TimeScale=TAI,Unit=s,Format=iso.3" ) utc_frame = Ast.TimeFrame( "TimeScale=UTC,Unit=s,Format=iso.3" ) # Get a mapping from TAI to UTC. tai_to_utc = tai_frame.convert( utc_frame ) # TAI is GPS plus 19 seconds. Create a Mapping to describe this shift. gps_to_tai = Ast.ShiftMap( 19.0 ) # Combine these mappings to get the total GPS to UTC mapping. gps_to_utc = Ast.CmpMap( gps_to_tai, tai_to_utc ) # Convert an example UTC date and time string to a floating point # value in seconds. ( nc, utc_value ) = utc_frame.unformat( 1, "2013-10-03 12:22:02.1" ) # Using the above mapping to transform the seconds value to GPS. gps_value = gps_to_utc.tran( utc_value ) # Convert the result to a date and time string and print. Use the TAI # frame here as a convenience - it's only being used to do the formatting, # which is the same for all timescales. print( tai_frame.format( 1, gps_value ) ) On 6 December 2013 12:29, Ho?ng ??c Th??ng wrote: > Hi, > > May anyone help me? I want to write a program convert GPS time to UTC > time. Then how can I understand the algorithm ? > > Thank you ! > > -- > > ================================================ > Hoang Duc Thuong > > Universit? des Sciences et des Technologies de Hanoi(USTH) > University of Science and Technology of Hanoi(USTH) > Hanoi University of Science and Technology (HUST) > > Email: hoangthuong.hust at gmail.com > Tel: +84 01692887738 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Fri Dec 6 09:17:46 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Fri, 6 Dec 2013 14:17:46 +0000 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: On 6 December 2013 14:11, David Berry wrote: > GPS is offset by 19 seconds from TAI. TAI is itself offset from UTC by an > integer number of seconds that increments each time a leap second occurs. > So it's pretty easy to code, but you need to know what the current UTC-TAI > value is. > > As an example, here is how to could be done using pyast. pyast does not > yet support GPS directly, but it's a simple job to add on the extra 19 > seconds. > > David > > > Spot the obvious error! It should have been... import starlink.Ast as Ast # Create frames describing UTC and TAI, in seconds. Indicate that values # should be formatted using a standard ISO date and time string with 3 # decimal places in the seconds field. tai_frame = Ast.TimeFrame( "TimeScale=TAI,Unit=s,Format=iso.3" ) utc_frame = Ast.TimeFrame( "TimeScale=UTC,Unit=s,Format=iso.3" ) # Get a mapping from TAI to UTC. tai_to_utc = tai_frame.convert( utc_frame ) # TAI is GPS plus 19 seconds. Create a Mapping to describe this shift. gps_to_tai = Ast.ShiftMap( 19.0 ) # Conbine these mappings to get the total GPS to UTC mapping. gps_to_utc = Ast.CmpMap( gps_to_tai, tai_to_utc ) # Convert an example GPS date and time string to a floating point # value in seconds. We use the TAI frame here as a convenience - it's # only being used to do the parsing, which is the same for all timescales. ( nc, gps_value ) = tai_frame.unformat( 1, "2013-10-03 12:22:02.1" ) # Using the above mapping to transform it to UTC. utc_value = gps_to_utc.tran( gps_value ) # Convert the result to a date and time string and print. print( utc_frame.format( 1, utc_value ) ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Fri Dec 6 09:28:05 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 6 Dec 2013 15:28:05 +0100 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: Since GPS is currently coded up as a format in Astropy, does this mean it really should be set up as a scale too? Maybe Tom Aldcroft can comment on this? Cheers, Tom On 6 December 2013 15:11, David Berry wrote: > GPS is offset by 19 seconds from TAI. TAI is itself offset from UTC by an > integer number of seconds that increments each time a leap second occurs. So > it's pretty easy to code, but you need to know what the current UTC-TAI > value is. > > As an example, here is how to could be done using pyast. pyast does not yet > support GPS directly, but it's a simple job to add on the extra 19 seconds. > > David > > > import starlink.Ast as Ast > > # Create frames describing UTC and TAI, in seconds. Indicate that values > # should be formatted using a standard ISO date and time string with 3 > # decimal places in the seconds field. > tai_frame = Ast.TimeFrame( "TimeScale=TAI,Unit=s,Format=iso.3" ) > utc_frame = Ast.TimeFrame( "TimeScale=UTC,Unit=s,Format=iso.3" ) > > # Get a mapping from TAI to UTC. > tai_to_utc = tai_frame.convert( utc_frame ) > > # TAI is GPS plus 19 seconds. Create a Mapping to describe this shift. > gps_to_tai = Ast.ShiftMap( 19.0 ) > > # Combine these mappings to get the total GPS to UTC mapping. > gps_to_utc = Ast.CmpMap( gps_to_tai, tai_to_utc ) > > # Convert an example UTC date and time string to a floating point > # value in seconds. > ( nc, utc_value ) = utc_frame.unformat( 1, "2013-10-03 12:22:02.1" ) > > # Using the above mapping to transform the seconds value to GPS. > gps_value = gps_to_utc.tran( utc_value ) > > # Convert the result to a date and time string and print. Use the TAI > # frame here as a convenience - it's only being used to do the formatting, > # which is the same for all timescales. > print( tai_frame.format( 1, gps_value ) ) > > > > On 6 December 2013 12:29, Ho?ng ??c Th??ng > wrote: >> >> Hi, >> >> May anyone help me? I want to write a program convert GPS time to UTC >> time. Then how can I understand the algorithm ? >> >> Thank you ! >> >> -- >> >> ================================================ >> Hoang Duc Thuong >> >> Universit? des Sciences et des Technologies de Hanoi(USTH) >> University of Science and Technology of Hanoi(USTH) >> Hanoi University of Science and Technology (HUST) >> >> Email: hoangthuong.hust at gmail.com >> Tel: +84 01692887738 >> >> >> _______________________________________________ >> 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 jniehof at lanl.gov Fri Dec 6 11:22:10 2013 From: jniehof at lanl.gov (Jonathan T. Niehof) Date: Fri, 06 Dec 2013 09:22:10 -0700 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: <52A1F9B2.5050504@lanl.gov> On 12/06/13 05:29, Ho?ng ??c Th??ng wrote: > Hi, > > May anyone help me? I want to write a program convert GPS time to UTC > time. Then how can I understand the algorithm ? SpacePy's ticktock class handles GPS time, if you want to take a look there. http://spacepy.lanl.gov/ and http://sourceforge.net/projects/spacepy/ -- Jonathan Niehof ISR-3 Space Data Systems Los Alamos National Laboratory MS-D466 Los Alamos, NM 87545 Phone: 505-667-9595 email: jniehof at lanl.gov Correspondence / Technical data or Software Publicly Available From thomas.robitaille at gmail.com Fri Dec 6 11:51:06 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 6 Dec 2013 17:51:06 +0100 Subject: [AstroPy] Fwd: Call for Lorentz Center Workshop proposals. Deadline 15 January 2014 In-Reply-To: References: <7CEBA1BE5F23144C8648778FAA00868B08822339@SPMXM01.VUW.leidenuniv.nl> Message-ID: Hi everyone, The Lorentz center in Leiden has put out a call for workshop proposals (see below). I would like to put in a proposal to organize a week-long Python in Astronomy workshop during which we can have presentations, sprints, tutorials, etc. If a proposal is accepted, the full costs for the conference are paid for by the Lorentz center, so this doesn't require applying for any other source of funding. If you think the idea is interesting and would potentially be interested in joining forces to write such a proposal, please let me know! It might be nice to have a one-off meeting on specifically python in astronomy rather than just a special session at a SciPy meeting, and I think a LOT could be achieved by bringing together a few dozen developers, users, etc. The Lorentz center is really nice - every participant gets their own desk (typically 2-3 people per office), and there are several bigger meeting rooms in addition to the lecture room, so it would be an amazing place to hold a workshop with an emphasis on making real progress in the coordination and development of Astropy python packages. Cheers, Tom ---------- Forwarded message ---------- From: Lorentz Center - Announcements Date: 6 December 2013 16:51 Subject: Call for Lorentz Center Workshop proposals. Deadline 15 January 2014 Dear Colleague, The Lorentz Center calls for proposals for workshops in all fields of natural and exact sciences, life sciences, computational science, and technology. The workshops may also aim to connect one or more one of these fields with the humanities and/or social sciences. The deadline for application is 15 January 2014, for workshops that will take place before May 2015. Notice that the Lorentz Center has several collaborations: - With NIAS (Netherlands Institute of Advanced Studies), to support workshops that aim at bridging the humanities/social sciences on the one hand with natural/technological sciences on the other. - With NLeSC (Netherlands eSciences Center), supporting workshops related to ?Big Data? challenges. - With CECAM (Centre Europ?en de Calcule Atomique et Mol?culaire), physical and chemical computational science. Here you can find a pdf with information about our workshops. I?m happy to discuss your ideas and answer any further questions you may have about proposing a workshop. Please distribute this information to any scientist you think may be interested. Also on behalf Arjen Doelman, director of the Lorentz Center, Sincerely, Henriette Jensenius ______________________________________________________ Dr. Henriette Jensenius Science Planning and Evaluation e-mail: jensenius at lorentzcenter.nl Tel +31 71 527 5580 ______________________________________________________ Lorentz Center: http://www.lorentzcenter.nl/ Proposal instructions: http://www.lorentzcenter.nl/proposals.php -- Thomas P. Robitaille | Max Planck Research Group Leader Max Planck Institute for Astronomy http://www.mpia-hd.mpg.de/~robitaille/ From erik.tollerud at gmail.com Fri Dec 6 15:19:16 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 6 Dec 2013 15:19:16 -0500 Subject: [AstroPy] astropy.cosmology In-Reply-To: References: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> Message-ID: Right now I think Juande's solution is indeed the best way right now. I think the reason for only having the "forward" version of these is that it's not clear exactly which of all the cosmology functions should have inverses. But we could add inverse versions of everything, basically implemented the way Juande is suggesting here. Then they could later be optimized when someone wants to make them faster. If anyone wants to issue a PR doing that, I think it might be useful... On Thu, Dec 5, 2013 at 12:06 PM, Juande Santander Vela wrote: > Hi, Enrique, > > I don?t find the age function in astropy.cosmology, but the loopback_time, but I think the answer stands. > > If you want to obtain the inverse function, assuming loopback_time is continuous, and it should, you can use scipy.optimize methods to find out the redshift. For instance, the redshift corresponding to a 0.2Gyears lookback time, you can do: > > from scipy.optimize import newton > import astropy.cosmology as cosmo > > newton(lambda x: cosmo.lookback_time(x).value-0.2, 0) > > or, in general: > > from scipy.optimize import newton > import astropy.cosmology as cosmo > > def redshift_from_lookback_time(gyears): > return newton(lambda x: cosmo.lookback_time(x).value-gyears, 0) > > Hope that helps. > > El 05/12/2013, a las 11:01, ES.Enrique Perez escribi?: > >> Geetings. >> >> I may have overlooked the answer in the docs, but really haven't been able to find it: >> >> astropy.cosmology age(some_redshift) provides the age corresponding to a given redshfit, >> but what is the reverse function that provides the redshift corresponding to a given age? >> >> Thanks, >> Enrique >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > -- > Juande Santander Vela > VIA-SKA Project Manager > Instituto de Astrof?sica de Andaluc?a (IAA-CSIC) > Glorieta de la Astronom?a s/n, E-18008, Granada, Spain > > Henry Ford: La mayor?a de la gente gasta m?s tiempo y energ?as en intentar esquivar los problemas que en tratar de resolverlos. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Erik From juandesant at gmail.com Fri Dec 6 16:15:01 2013 From: juandesant at gmail.com (Juande Santander Vela) Date: Fri, 6 Dec 2013 18:15:01 -0300 Subject: [AstroPy] astropy.cosmology In-Reply-To: References: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> Message-ID: I could do that for a couple of them (Enrique's input might be useful here as use cases), but they should return Quantities, so I should familiarize myself with how to do that. -- Juande Santander Vela > On 6 Dec 2013, at 17:19, Erik Tollerud wrote: > > Right now I think Juande's solution is indeed the best way right now. > I think the reason for only having the "forward" version of these is > that it's not clear exactly which of all the cosmology functions > should have inverses. > > But we could add inverse versions of everything, basically implemented > the way Juande is suggesting here. Then they could later be optimized > when someone wants to make them faster. If anyone wants to issue a PR > doing that, I think it might be useful... > >> On Thu, Dec 5, 2013 at 12:06 PM, Juande Santander Vela wrote: >> Hi, Enrique, >> >> I don?t find the age function in astropy.cosmology, but the loopback_time, but I think the answer stands. >> >> If you want to obtain the inverse function, assuming loopback_time is continuous, and it should, you can use scipy.optimize methods to find out the redshift. For instance, the redshift corresponding to a 0.2Gyears lookback time, you can do: >> >> from scipy.optimize import newton >> import astropy.cosmology as cosmo >> >> newton(lambda x: cosmo.lookback_time(x).value-0.2, 0) >> >> or, in general: >> >> from scipy.optimize import newton >> import astropy.cosmology as cosmo >> >> def redshift_from_lookback_time(gyears): >> return newton(lambda x: cosmo.lookback_time(x).value-gyears, 0) >> >> Hope that helps. >> >>> El 05/12/2013, a las 11:01, ES.Enrique Perez escribi?: >>> >>> Geetings. >>> >>> I may have overlooked the answer in the docs, but really haven't been able to find it: >>> >>> astropy.cosmology age(some_redshift) provides the age corresponding to a given redshfit, >>> but what is the reverse function that provides the redshift corresponding to a given age? >>> >>> Thanks, >>> Enrique >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> -- >> Juande Santander Vela >> VIA-SKA Project Manager >> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC) >> Glorieta de la Astronom?a s/n, E-18008, Granada, Spain >> >> Henry Ford: La mayor?a de la gente gasta m?s tiempo y energ?as en intentar esquivar los problemas que en tratar de resolverlos. >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Erik From tim.jenness at gmail.com Mon Dec 9 11:32:54 2013 From: tim.jenness at gmail.com (Tim Jenness) Date: Mon, 9 Dec 2013 09:32:54 -0700 Subject: [AstroPy] Learning from FITS paper Message-ID: Sorry for the slightly off-topic email, but some of us are working on a paper for Astronomy & Computing detailing how a future astronomical data format could learn from FITS. A draft PDF is available at https://drive.google.com/file/d/0Bydi4JsSwrczN19BbHA0Ulg4Tkk/edit?usp=sharing and the source is also on github at https://github.com/timj/aandc-fits We are moving towards a final draft but there is still scope for people to sign up to the paper. We don't require anything from you other than the support of your name and you reading the paper and wanting to be on it. Deadline for accepting new authors is December 13th. -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From hoangthuong.hust at gmail.com Mon Dec 9 11:38:22 2013 From: hoangthuong.hust at gmail.com (=?UTF-8?B?SG/DoG5nIMSQ4bupYyBUaMaw4budbmc=?=) Date: Mon, 9 Dec 2013 23:38:22 +0700 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: <52A1F9B2.5050504@lanl.gov> References: <52A1F9B2.5050504@lanl.gov> Message-ID: I try to write a simple function, comment it for me thank you, plz 2013/12/6 Jonathan T. Niehof > On 12/06/13 05:29, Ho?ng ??c Th??ng wrote: > >> Hi, >> >> May anyone help me? I want to write a program convert GPS time to UTC >> time. Then how can I understand the algorithm ? >> > > SpacePy's ticktock class handles GPS time, if you want to take a look > there. http://spacepy.lanl.gov/ and http://sourceforge.net/ > projects/spacepy/ > > -- > Jonathan Niehof > ISR-3 Space Data Systems > Los Alamos National Laboratory > MS-D466 > Los Alamos, NM 87545 > > Phone: 505-667-9595 > email: jniehof at lanl.gov > > Correspondence / > Technical data or Software Publicly Available > -- ================================================ Hoang Duc Thuong Universit? des Sciences et des Technologies de Hanoi(USTH) University of Science and Technology of Hanoi(USTH) Hanoi University of Science and Technology (HUST) Email: hoangthuong.hust at gmail.com Tel: +84 01692887738 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GPS2UTC_THUONG.py Type: text/x-python Size: 2569 bytes Desc: not available URL: From aldcroft at head.cfa.harvard.edu Mon Dec 9 11:57:27 2013 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 9 Dec 2013 11:57:27 -0500 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: How about this with astropy 0.3: >>> from astropy.time import Time >>> t_gps = Time(3600.0, format='gps') # seconds since 1980-01-06 00:00:00 UTC >>> t_gps.utc.iso '1980-01-06 01:00:00.000' This basically creates a Time object with the GPS format representation. By default this object is in TAI scale, so you first convert to UTC and then ask for the ISO format representation. As I understand GPS is not a time scale, but a simple difference of time in the TAI scale from the given epoch. - Tom On Fri, Dec 6, 2013 at 7:29 AM, Ho?ng ??c Th??ng wrote: > Hi, > > May anyone help me? I want to write a program convert GPS time to UTC > time. Then how can I understand the algorithm ? > > Thank you ! > > -- > > ================================================ > Hoang Duc Thuong > > Universit? des Sciences et des Technologies de Hanoi(USTH) > University of Science and Technology of Hanoi(USTH) > Hanoi University of Science and Technology (HUST) > > Email: hoangthuong.hust at gmail.com > Tel: +84 01692887738 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Mon Dec 9 12:22:43 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Mon, 9 Dec 2013 17:22:43 +0000 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: On 9 December 2013 16:57, Aldcroft, Thomas wrote: > How about this with astropy 0.3: > >>>> from astropy.time import Time >>>> t_gps = Time(3600.0, format='gps') # seconds since 1980-01-06 00:00:00 >>>> UTC >>>> t_gps.utc.iso > '1980-01-06 01:00:00.000' > > This basically creates a Time object with the GPS format representation. By > default this object is in TAI scale, so you first convert to UTC and then > ask for the ISO format representation. As I understand GPS is not a time > scale, but a simple difference of time in the TAI scale from the given > epoch. Doesn't that make it a timescale? After all TT (Terrestrial Time) is also just a constant offset from TAI. David From aldcroft at head.cfa.harvard.edu Mon Dec 9 14:48:21 2013 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 9 Dec 2013 14:48:21 -0500 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 12:22 PM, David Berry wrote: > On 9 December 2013 16:57, Aldcroft, Thomas > wrote: > > How about this with astropy 0.3: > > > >>>> from astropy.time import Time > >>>> t_gps = Time(3600.0, format='gps') # seconds since 1980-01-06 > 00:00:00 > >>>> UTC > >>>> t_gps.utc.iso > > '1980-01-06 01:00:00.000' > > > > This basically creates a Time object with the GPS format representation. > By > > default this object is in TAI scale, so you first convert to UTC and then > > ask for the ISO format representation. As I understand GPS is not a time > > scale, but a simple difference of time in the TAI scale from the given > > epoch. > > Doesn't that make it a timescale? After all TT (Terrestrial Time) is > also just a constant offset from TAI. > This is a good question and one for which I'm definitely interested in input. >From what I can see there are two ways to view "GPS time": 1. As a time scale which is behind TAI by 19 seconds. 2. As a time format which is the floating point number giving the number of TAI seconds since UTC 1980-01-06 00:00:00. This is roughly similar to the "unix" format or "cxcsec" format. The latter (2) is what is currently implemented in astropy because that is my (limited) understanding of what is actually used, for instance in satellite communication. It seems that GPS time may also be represented as an integer number of weeks + float seconds since the epoch, but this is a trivial transformation from float seconds. Version (1) is easy enough to implement as a new time scale, except for a technical detail: there is a namespace clash with the existing "gps" format because of the way formats and scales are both available via attribute access from a Time object. We could have that discussion on astropy-dev or github, but the immediate question is whether astropy.time should have a GPS scale ala (1). Cheers, Tom > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foadhanassi-savari at hotmail.co.uk Mon Dec 9 15:52:15 2013 From: foadhanassi-savari at hotmail.co.uk (foad hanassi-savari) Date: Mon, 9 Dec 2013 20:52:15 +0000 Subject: [AstroPy] command shell to start up ipython Message-ID: Hi everyone,I have a trivial question. I am trying to open ipython in the anaconda command prompt (in windows 7 64-bits).I am currently doing the python for astronomers introductory course on astropython.org. I have already upgraded ipython and the packages like astropy, aplpy etc and they work fine. At the moment I'm on the 'take your python for a spin!' section but cannot start up ipython in the command prompt. I have installed 7-zip and have untar-ed the file.Simply running %pylab doesn't work, I have tried so many different commands and non works for me. Can anyone help me please? Thank you,Foad -------------- next part -------------- An HTML attachment was scrubbed... URL: From phirst at gemini.edu Mon Dec 9 15:58:23 2013 From: phirst at gemini.edu (Paul Hirst) Date: Mon, 9 Dec 2013 20:58:23 +0000 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: On 9/12/13, 09:48 , "Aldcroft, Thomas" > wrote: On Mon, Dec 9, 2013 at 12:22 PM, David Berry > wrote: On 9 December 2013 16:57, Aldcroft, Thomas > wrote: > This basically creates a Time object with the GPS format representation. By > default this object is in TAI scale, so you first convert to UTC and then > ask for the ISO format representation. As I understand GPS is not a time > scale, but a simple difference of time in the TAI scale from the given > epoch. Doesn't that make it a timescale? After all TT (Terrestrial Time) is also just a constant offset from TAI. This is a good question and one for which I'm definitely interested in input. >From what I can see there are two ways to view "GPS time": 1. As a time scale which is behind TAI by 19 seconds. 2. As a time format which is the floating point number giving the number of TAI seconds since UTC 1980-01-06 00:00:00. This is roughly similar to the "unix" format or "cxcsec" format. I would have thought (1) was actually a more appropriate representation. I'm not sure of the formal definition, but I always considered GPS time to be another timescale, which just happens to have a nice and simple transformation to and from TAI - I understand it's by definition just the simple and exact 19.0 second offset. Depending on the level of accuracy required, I don't think that's true for TT as suggested above, the TT = TAI - 32.184s is an approximation; a more accurate transformation is given at eg ftp://tai.bipm.org/TFG/TT(BIPM)/TTBIPM.12 Now, I'm not suggesting that this is a priority for implementation right now, but in general I'm thinking that having things as separate time scales would make it easier in the future for someone to contribute a more advanced transformation - as opposed to figuring out how to make it a separate timescale first. Cheers, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzuhone at gmail.com Mon Dec 9 16:45:39 2013 From: jzuhone at gmail.com (John ZuHone) Date: Mon, 9 Dec 2013 16:45:39 -0500 Subject: [AstroPy] command shell to start up ipython In-Reply-To: References: Message-ID: <124146D7-7755-492A-9A61-7AB58C22E954@gmail.com> Hi Foad, Are you trying to run ipython from *within* python or from the windows command prompt? ipython is a command that must be run from the windows command line, which starts up the ipython interactive python environment. Best, John On Dec 9, 2013, at 3:52 PM, foad hanassi-savari wrote: > Hi everyone, > I have a trivial question. I am trying to open ipython in the anaconda command prompt (in windows 7 64-bits). > I am currently doing the python for astronomers introductory course onastropython.org. I have already upgraded ipython and the packages like astropy, aplpy etc and they work fine. At the moment I'm on the 'take your python for a spin!' section but cannot start up ipython in the command prompt. I have installed 7-zip and have untar-ed the file. > Simply running %pylab doesn't work, I have tried so many different commands and non works for me. Can anyone help me please? > > Thank you, > Foad > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Mon Dec 9 18:37:38 2013 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 9 Dec 2013 18:37:38 -0500 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: Based on the discussion here I added an astropy issue to consider adding a GPS time scale: https://github.com/astropy/astropy/issues/1879 Cheers, Tom On Mon, Dec 9, 2013 at 3:58 PM, Paul Hirst wrote: > On 9/12/13, 09:48 , "Aldcroft, Thomas" > wrote: > > > On Mon, Dec 9, 2013 at 12:22 PM, David Berry wrote: > >> On 9 December 2013 16:57, Aldcroft, Thomas >> wrote: >> > This basically creates a Time object with the GPS format >> representation. By >> > default this object is in TAI scale, so you first convert to UTC and >> then >> > ask for the ISO format representation. As I understand GPS is not a >> time >> > scale, but a simple difference of time in the TAI scale from the given >> > epoch. >> >> Doesn't that make it a timescale? After all TT (Terrestrial Time) is >> also just a constant offset from TAI. >> > > This is a good question and one for which I'm definitely interested in > input. > > From what I can see there are two ways to view "GPS time": > > 1. As a time scale which is behind TAI by 19 seconds. > 2. As a time format which is the floating point number giving the number > of TAI seconds since UTC 1980-01-06 00:00:00. This is roughly similar to > the "unix" format or "cxcsec" format. > > > > I would have thought (1) was actually a more appropriate representation. > I'm not sure of the formal definition, but I always considered GPS time to > be another timescale, which just happens to have a nice and simple > transformation to and from TAI - I understand it's by definition just the > simple and exact 19.0 second offset. > > Depending on the level of accuracy required, I don't think that's true > for TT as suggested above, the TT = TAI - 32.184s is an approximation; a > more accurate transformation is given at eg > ftp://tai.bipm.org/TFG/TT(BIPM)/TTBIPM.12 > > Now, I'm not suggesting that this is a priority for implementation right > now, but in general I'm thinking that having things as separate time scales > would make it easier in the future for someone to contribute a more > advanced transformation - as opposed to figuring out how to make it a > separate timescale first. > > Cheers, > Paul. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pebarrett at gmail.com Tue Dec 10 11:35:42 2013 From: pebarrett at gmail.com (Paul Barrett) Date: Tue, 10 Dec 2013 11:35:42 -0500 Subject: [AstroPy] Convert GPS time to UTC time In-Reply-To: References: Message-ID: GPS time is its own time scale, since it is defined as a Composite Clock. It just happens to be steered to UTC by USNO, but if necessary can be run autonomously. For more details, see http://tycho.usno.navy.mil/gpstt.html. -- Paul On Mon, Dec 9, 2013 at 6:37 PM, Aldcroft, Thomas < aldcroft at head.cfa.harvard.edu> wrote: > Based on the discussion here I added an astropy issue to consider adding a > GPS time scale: > > https://github.com/astropy/astropy/issues/1879 > > Cheers, > Tom > > > On Mon, Dec 9, 2013 at 3:58 PM, Paul Hirst wrote: > >> On 9/12/13, 09:48 , "Aldcroft, Thomas" >> wrote: >> >> >> On Mon, Dec 9, 2013 at 12:22 PM, David Berry wrote: >> >>> On 9 December 2013 16:57, Aldcroft, Thomas >>> wrote: >>> > This basically creates a Time object with the GPS format >>> representation. By >>> > default this object is in TAI scale, so you first convert to UTC and >>> then >>> > ask for the ISO format representation. As I understand GPS is not a >>> time >>> > scale, but a simple difference of time in the TAI scale from the given >>> > epoch. >>> >>> Doesn't that make it a timescale? After all TT (Terrestrial Time) is >>> also just a constant offset from TAI. >>> >> >> This is a good question and one for which I'm definitely interested in >> input. >> >> From what I can see there are two ways to view "GPS time": >> >> 1. As a time scale which is behind TAI by 19 seconds. >> 2. As a time format which is the floating point number giving the number >> of TAI seconds since UTC 1980-01-06 00:00:00. This is roughly similar to >> the "unix" format or "cxcsec" format. >> >> >> >> I would have thought (1) was actually a more appropriate >> representation. I'm not sure of the formal definition, but I always >> considered GPS time to be another timescale, which just happens to have a >> nice and simple transformation to and from TAI - I understand it's by >> definition just the simple and exact 19.0 second offset. >> >> Depending on the level of accuracy required, I don't think that's true >> for TT as suggested above, the TT = TAI - 32.184s is an approximation; a >> more accurate transformation is given at eg >> ftp://tai.bipm.org/TFG/TT(BIPM)/TTBIPM.12 >> >> Now, I'm not suggesting that this is a priority for implementation >> right now, but in general I'm thinking that having things as separate time >> scales would make it easier in the future for someone to contribute a more >> advanced transformation - as opposed to figuring out how to make it a >> separate timescale first. >> >> Cheers, >> Paul. >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.macleod at ligo.org Tue Dec 10 23:33:27 2013 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Tue, 10 Dec 2013 22:33:27 -0600 Subject: [AstroPy] Cannot download astropy sphinx objects.inv Message-ID: Hi guys, I am developing a project using sphinx that tries to reference the astropy docs, but I?m getting the following error: WARNING: intersphinx inventory 'http://www.astropy.org/objects.inv' not fetchable due to : HTTP Error 404: Not Found Is there a new/correct intersphinx URL for the astropy docs? Thanks Duncan -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed Dec 11 06:01:20 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 11 Dec 2013 12:01:20 +0100 Subject: [AstroPy] Cannot download astropy sphinx objects.inv In-Reply-To: References: Message-ID: Hi Duncan, We are in the process of fixing it, the URL should be http://docs.astropy.org/en/stable/objects.inv You can fix it by adding intersphinx_mapping = { 'astropy': ('http://docs.astropy.org/en/stable/', None), } to your conf.py. Any luck? Tom On 11 December 2013 05:33, Duncan Macleod wrote: > Hi guys, > > I am developing a project using sphinx that tries to reference the astropy > docs, but I?m getting the following error: > > WARNING: intersphinx inventory 'http://www.astropy.org/objects.inv' not > fetchable due to : HTTP Error 404: Not Found > > Is there a new/correct intersphinx URL for the astropy docs? > > > Thanks > Duncan > -- > Duncan Macleod > duncan.macleod at ligo.org > LIGO Data Grid systems development > Louisiana State University > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From erik.tollerud at gmail.com Wed Dec 11 11:41:12 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 11 Dec 2013 11:41:12 -0500 Subject: [AstroPy] astropy.cosmology In-Reply-To: <5B774FC1-16A8-4AF1-88D0-403788E46CAE@gmail.com> References: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> <5B774FC1-16A8-4AF1-88D0-403788E46CAE@gmail.com> Message-ID: > I don?t see much point in implementing reverse functions of -everything- ? > it?s hard to imagine scenarios where most of them would be interesting. > When will somebody want to know what redshift corresponds to a given > luminosity distance? Age is really the only one I can imagine having > wide interest, so I would just start with that in the interest of avoiding > bloat. Suppose you have a galaxy where you think you know what its absolute magnitude should be (say its a standard candle) and have an apparent magnitude, and you want to use it to know what redshift it's at. Then you need this, because the distance modulus is tied to the luminosity distance (this example came to mind because I've actually needed this for actual science in the past). My point here is mainly that just because we don't want all of them, doesn't mean some other users don't have a need. That said, I see your point in that others are probably generally less useful (e.g. AD distance), and duplicating every function/method does make everything harder to deal with. Perhaps the solution is to add an `inverse` function to `astropy.cosmology`? You could then do something like ``z = cosmology.inverse(WMAP.age, 1 * u.Gyr)``. That would keep the API cleaner, and it would be fairly trivial to implement it that way using the method Juande and Alex are talking about. Then if we decide to optimize some of them later, we can add those in and have the `inverse` function use those if they are present. > > Alex > -- Erik From bjw at as.arizona.edu Wed Dec 11 15:07:25 2013 From: bjw at as.arizona.edu (Benjamin Weiner) Date: Wed, 11 Dec 2013 13:07:25 -0700 Subject: [AstroPy] astropy.cosmology Message-ID: > > [Erik wrote] > > Suppose you have a galaxy where you think you know what its absolute > magnitude should be (say its a standard candle) and have an apparent > magnitude, and you want to use it to know what redshift it's at. Then > you need this, because the distance modulus is tied to the luminosity > distance (this example came to mind because I've actually needed this > for actual science in the past). My point here is mainly that just > because we don't want all of them, doesn't mean some other users don't > have a need. > Hi, Not to belabor this point, but it is very common to want an inverse function for redshift or comoving distance when you are trying to deal with selection limits. For example the 1/Vmax luminosity function calculation asks, given an object of known luminosity, and a selection limit, to what Dmax could I see it? So you know a distance modulus and want to know comoving_volume(z(distmod)). Wanting the inverse of angular distance is less common but I could imagine using it, for example, answering to what redshift can HST resolve a 1 kpc diameter? As an aside, I didn't think astropy.cosmology included a function for the comoving volume element dV_c or the integrated comoving volume from 0 to z, which are both useful. However, looking in the source, comoving_volume is there, but it and several other functions were not in the documentation. Ben -- Benjamin Weiner Associate Astronomer, Steward Observatory bjw at as.arizona.edu http://mingus.as.arizona.edu/~bjw/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlw at stsci.edu Wed Dec 11 15:17:47 2013 From: rlw at stsci.edu (Rick White) Date: Wed, 11 Dec 2013 15:17:47 -0500 Subject: [AstroPy] astropy.cosmology In-Reply-To: References: Message-ID: <0268E5F3-AC6A-4077-8FFF-9A0E73F3D27F@stsci.edu> A problem with inverse angular diameter distance is that it is not a single-valued function. Luminosity & comoving distance both increase monotonically with redshift, so the inverse is unambiguous. Angular diameter distance increases, then has a maximum and decreases as redshift increases. So there would be some justification for providing inverses only for luminosity & comoving distance... On Dec 11, 2013, at 3:07 PM, Benjamin Weiner wrote: > [Erik wrote] > Suppose you have a galaxy where you think you know what its absolute > magnitude should be (say its a standard candle) and have an apparent > magnitude, and you want to use it to know what redshift it's at. Then > you need this, because the distance modulus is tied to the luminosity > distance (this example came to mind because I've actually needed this > for actual science in the past). My point here is mainly that just > because we don't want all of them, doesn't mean some other users don't > have a need. > > Hi, > > Not to belabor this point, but it is very common to > want an inverse function for redshift or comoving distance > when you are trying to deal with selection limits. For example > the 1/Vmax luminosity function calculation asks, given an > object of known luminosity, and a selection limit, to what > Dmax could I see it? So you know a distance modulus > and want to know comoving_volume(z(distmod)). > > Wanting the inverse of angular distance is less common > but I could imagine using it, for example, answering to what > redshift can HST resolve a 1 kpc diameter? > > As an aside, I didn't think astropy.cosmology included a > function for the comoving volume element dV_c or the > integrated comoving volume from 0 to z, which are both > useful. However, looking in the source, comoving_volume > is there, but it and several other functions were not in the > documentation. > > Ben > > > > > -- > Benjamin Weiner > Associate Astronomer, Steward Observatory > bjw at as.arizona.edu > http://mingus.as.arizona.edu/~bjw/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilcrighton at gmail.com Wed Dec 11 18:37:38 2013 From: neilcrighton at gmail.com (Neil Crighton) Date: Thu, 12 Dec 2013 10:37:38 +1100 Subject: [AstroPy] astropy.cosmology In-Reply-To: <0268E5F3-AC6A-4077-8FFF-9A0E73F3D27F@stsci.edu> References: <0268E5F3-AC6A-4077-8FFF-9A0E73F3D27F@stsci.edu> Message-ID: The cosmology.inverse function idea sounds good, I vote to do that. We can give a warning for cases that are non-monotonic for the standard cosmology, but I think we should trust users to understand what they're doing. That's weird there's no age function, I thought all the methods and functions were eventually mirrored. I'm also not sure why the comoving volume isn't described in the documentation. Probably this is my fault :) We can also add the comoving volume element, dV_comoving. Are there any other quantities it would be useful to have? I can open a PR making these changes in the next day or so, unless someone beats me to it. Neil On 12 December 2013 07:17, Rick White wrote: > A problem with inverse angular diameter distance is that it is not a > single-valued function. Luminosity & comoving distance both increase > monotonically with redshift, so the inverse is unambiguous. Angular > diameter distance increases, then has a maximum and decreases as redshift > increases. > > So there would be some justification for providing inverses only for > luminosity & comoving distance... > > On Dec 11, 2013, at 3:07 PM, Benjamin Weiner wrote: > > [Erik wrote] >> >> Suppose you have a galaxy where you think you know what its absolute >> magnitude should be (say its a standard candle) and have an apparent >> magnitude, and you want to use it to know what redshift it's at. Then >> you need this, because the distance modulus is tied to the luminosity >> distance (this example came to mind because I've actually needed this >> for actual science in the past). My point here is mainly that just >> because we don't want all of them, doesn't mean some other users don't >> have a need. >> > > Hi, > > Not to belabor this point, but it is very common to > want an inverse function for redshift or comoving distance > when you are trying to deal with selection limits. For example > the 1/Vmax luminosity function calculation asks, given an > object of known luminosity, and a selection limit, to what > Dmax could I see it? So you know a distance modulus > and want to know comoving_volume(z(distmod)). > > Wanting the inverse of angular distance is less common > but I could imagine using it, for example, answering to what > redshift can HST resolve a 1 kpc diameter? > > As an aside, I didn't think astropy.cosmology included a > function for the comoving volume element dV_c or the > integrated comoving volume from 0 to z, which are both > useful. However, looking in the source, comoving_volume > is there, but it and several other functions were not in the > documentation. > > Ben > > > > > -- > Benjamin Weiner > Associate Astronomer, Steward Observatory > bjw at as.arizona.edu > http://mingus.as.arizona.edu/~bjw/ > _______________________________________________ > 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 duncan.macleod at ligo.org Fri Dec 13 01:01:42 2013 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Fri, 13 Dec 2013 00:01:42 -0600 Subject: [AstroPy] Cannot download astropy sphinx objects.inv In-Reply-To: References: Message-ID: Hi Thomas, On 11 Dec 2013, at 05:01, Thomas Robitaille wrote: > Hi Duncan, > > We are in the process of fixing it, the URL should be > http://docs.astropy.org/en/stable/objects.inv > > You can fix it by adding > > intersphinx_mapping = { > 'astropy': ('http://docs.astropy.org/en/stable/', None), > } > > to your conf.py. Any luck? Yes, this works just fine. Thanks Duncan > > Tom > > On 11 December 2013 05:33, Duncan Macleod wrote: >> Hi guys, >> >> I am developing a project using sphinx that tries to reference the astropy >> docs, but I?m getting the following error: >> >> WARNING: intersphinx inventory 'http://www.astropy.org/objects.inv' not >> fetchable due to : HTTP Error 404: Not Found >> >> Is there a new/correct intersphinx URL for the astropy docs? >> >> >> Thanks >> Duncan >> -- >> Duncan Macleod >> duncan.macleod at ligo.org >> LIGO Data Grid systems development >> Louisiana State University >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.macleod at ligo.org Fri Dec 13 01:05:12 2013 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Fri, 13 Dec 2013 00:05:12 -0600 Subject: [AstroPy] Unified file read method without opening file? Message-ID: <4A543406-FC3B-46DA-B0A5-A9FB815F29F2@ligo.org> Hi all, I?m a big fan of the astropy unified file read/write interface, and have used it in a project for reading gravitational-wave data. Is there a way to not have the astropy.io.registry.read method open all file paths if format=None, the lower-level methods that then get called take in filepaths themselves, not open files (e.g. h5py.File) and I don?t want to then have two open copies of the same file? Thanks Duncan -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Fri Dec 13 13:52:04 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 13 Dec 2013 13:52:04 -0500 Subject: [AstroPy] astropy.cosmology In-Reply-To: References: <76484526-11C2-4DBE-8439-B8E6F0EDEE60@iaa.es> <5B774FC1-16A8-4AF1-88D0-403788E46CAE@gmail.com> Message-ID: (Passing on a message from Alex Conley here about a complication in the inverse function scheme, same as Rick White pointed out.) But I disagree that this is "bloat" - the fact that three people on this list have already said they need it for science shows that it's a useful thing to include. Inverting it with scipy functions is not necessarily trivial, and having an informative warning that specifically states the non-monotonicity is in the cosmology module is a reason to make it specific to astropy.cosmology . Anyway, we'll see what Neil comes up with and see then whether it seems like it will be difficult to maintain (the main disavantage of "bloat"). On Wed, Dec 11, 2013 at 11:58 AM, Alex Conley wrote: > That seems pretty contrived, honestly. It doesn?t sound like you were up > to much good when you did this. > > Maybe a more serious issue: luminosity distance is not monotonic in closed Universes. > And the angular diameter distance is not monotonic in most, including the > one we live in. Age, at least, is always monotonic, at least in Universes with a Big Bang. > So most of the inverses you want are ill-defined. > >>>> from astropy.cosmology import LambdaCDM >>>> cos = LambdaCDM(70, 0.2, 1.4) >>>> cos.luminosity_distance([1.3044, 3.0, 5.5]) > > >>>> from astropy.cosmology import WMAP9 >>>> WMAP9.angular_diameter_distance([0.668, 3, 4.0]) > > > Even assuming you overcame this problem ? what about the function > inverter says: should be specific to astropy.cosmology? This screams > code bloat to me. > > PS: I?m not subscribed to astropy at scipy.org, so it will not let me > post. > On 11-Dec-2013, at 9:41 AM, Erik Tollerud wrote: > >>> I don?t see much point in implementing reverse functions of -everything- ? >>> it?s hard to imagine scenarios where most of them would be interesting. >>> When will somebody want to know what redshift corresponds to a given >>> luminosity distance? Age is really the only one I can imagine having >>> wide interest, so I would just start with that in the interest of avoiding >>> bloat. >> >> Suppose you have a galaxy where you think you know what its absolute >> magnitude should be (say its a standard candle) and have an apparent >> magnitude, and you want to use it to know what redshift it's at. Then >> you need this, because the distance modulus is tied to the luminosity >> distance (this example came to mind because I've actually needed this >> for actual science in the past). My point here is mainly that just >> because we don't want all of them, doesn't mean some other users don't >> have a need. >> >> That said, I see your point in that others are probably generally less >> useful (e.g. AD distance), and duplicating every function/method does >> make everything harder to deal with. Perhaps the solution is to add an >> `inverse` function to `astropy.cosmology`? You could then do >> something like ``z = cosmology.inverse(WMAP.age, 1 * u.Gyr)``. That >> would keep the API cleaner, and it would be fairly trivial to >> implement it that way using the method Juande and Alex are talking >> about. Then if we decide to optimize some of them later, we can add >> those in and have the `inverse` function use those if they are >> present. -- Erik From ghang.naoc at gmail.com Sat Dec 14 11:14:45 2013 From: ghang.naoc at gmail.com (gonghang.naoc) Date: Sun, 15 Dec 2013 00:14:45 +0800 Subject: [AstroPy] how to mark spectral lines in matplotlib? Message-ID: Hi astropyers, I have a ready made spectral line atlas. Is there a direct way to mark the spectral lines in one spectrum plot? I have found a module called lineid_plot. However,I can not install it. The images below are three examples. http://www.cv.nrao.edu/course/astr534/images/bandscan.gif http://skyserver.sdss3.org/dr8/en/tools/quicklook/quickobj.asp?id=1237662661600608302 http://inspirehep.net/record/878108/files/plot_mean_spec1.png Thank you. hang -------------- next part -------------- An HTML attachment was scrubbed... URL: From indiajoe at gmail.com Sat Dec 14 11:46:38 2013 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Sat, 14 Dec 2013 22:16:38 +0530 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: References: Message-ID: Hi, There might be better options, but you can always use annotate function in matplotlib inside a for loop to add all the spectral line labels. Following is an example to show the syntax. plt.annotate(r'H$\alpha$', xy=(6563, 1.2), xytext=(6600, 1.7), arrowprops=dict(arrowstyle="->",facecolor='black') ) -cheers joe On 14 December 2013 21:44, gonghang.naoc wrote: > Hi astropyers, > I have a ready made spectral line atlas. Is there a direct way to mark the > spectral lines in one spectrum plot? > I have found a module called lineid_plot. However,I can not install it. > > The images below are three examples. > http://www.cv.nrao.edu/course/astr534/images/bandscan.gif > > http://skyserver.sdss3.org/dr8/en/tools/quicklook/quickobj.asp?id=1237662661600608302 > http://inspirehep.net/record/878108/files/plot_mean_spec1.png > > Thank you. > > hang > > _______________________________________________ > 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 http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Sat Dec 14 11:50:59 2013 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Sat, 14 Dec 2013 17:50:59 +0100 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: References: Message-ID: <79C3F052-8926-4109-9D7F-BFD78B4F020E@astro.physik.uni-goettingen.de> Hi Hang, On 14.12.2013, at 5:14PM, gonghang.naoc wrote: > I have a ready made spectral line atlas. Is there a direct way to mark the spectral lines in one spectrum plot? > I have found a module called lineid_plot. However,I can not install it. what were your problems with installing it? lineid_plot would have been my best recommendation, too, and I'd really like to get it to cooperate with specutils. Cheers, Derek From trive at astro.su.se Sat Dec 14 18:33:33 2013 From: trive at astro.su.se (=?ISO-8859-1?Q?Th=F8ger_Emil_Rivera-Thorsen?=) Date: Sun, 15 Dec 2013 00:33:33 +0100 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: References: Message-ID: <52ACEACD.1020402@astro.su.se> On 14-12-2013 17:14, gonghang.naoc wrote: > Hi astropyers, > I have a ready made spectral line atlas. Is there a direct way to mark > the spectral lines in one spectrum plot? > I have found a module called lineid_plot. However,I can not install it. > > The images below are three examples. > http://www.cv.nrao.edu/course/astr534/images/bandscan.gif > http://skyserver.sdss3.org/dr8/en/tools/quicklook/quickobj.asp?id=1237662661600608302 > http://inspirehep.net/record/878108/files/plot_mean_spec1.png > > Thank you. > > hang I usually do this by reading my lines into a dict of the form |{'Line Name': wavelength}| and then using a code snippet like this: |for thelinein MWlines.keys(): ax.axvline( x=MWlines[theline], ymin=.5, ymax=.99, lw=1.5, color='grey', ls=':') ax.annotate( theline+' MW', (MWlines[theline]-.0,2.2), backgroundcolor='white', rotation='vertical', horizontalalignment='center', color='grey')| This will of course be varied slightly depending on the context, but that's the basic idea. > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghang.naoc at gmail.com Sun Dec 15 10:52:24 2013 From: ghang.naoc at gmail.com (gonghang.naoc) Date: Sun, 15 Dec 2013 23:52:24 +0800 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: <52ACEACD.1020402@astro.su.se> References: <52ACEACD.1020402@astro.su.se> Message-ID: Hi, Thank you. The method 'annotate' works. I tried pip to install module lineid_plot but failed. My python environment is messed up now. I downloaded the tar.gz file lineid_plot-0.2.tar.gz ,then $python setup.py usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: no commands supplied However since 'annotate' works well, I will use this general way. cheers, hang On Sun, Dec 15, 2013 at 7:33 AM, Th?ger Emil Rivera-Thorsen < trive at astro.su.se> wrote: > On 14-12-2013 17:14, gonghang.naoc wrote: > > Hi astropyers, > I have a ready made spectral line atlas. Is there a direct way to mark > the spectral lines in one spectrum plot? > I have found a module called lineid_plot. However,I can not install it. > > The images below are three examples. > http://www.cv.nrao.edu/course/astr534/images/bandscan.gif > > http://skyserver.sdss3.org/dr8/en/tools/quicklook/quickobj.asp?id=1237662661600608302 > http://inspirehep.net/record/878108/files/plot_mean_spec1.png > > Thank you. > > hang > > I usually do this by reading my lines into a dict of the form {'Line > Name': wavelength} and then using a code snippet like this: > > for theline in MWlines.keys(): > ax.axvline( > x=MWlines[theline], ymin=.5, ymax=.99, > lw=1.5, color='grey', ls=':') > ax.annotate( > theline+' MW', (MWlines[theline]-.0, 2.2), > backgroundcolor='white', rotation='vertical', > horizontalalignment='center', color='grey') > > This will of course be varied slightly depending on the context, but > that?s the basic idea. > > > > _______________________________________________ > AstroPy mailing listAstroPy at scipy.orghttp://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.deval at gmail.com Sun Dec 15 11:02:18 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Sun, 15 Dec 2013 11:02:18 -0500 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: References: <52ACEACD.1020402@astro.su.se> Message-ID: <20131215160218.GI31348@phs5.astro.Princeton.EDU> Hi Hang, On Sun, Dec 15, 2013 at 11:52:24PM +0800, gonghang.naoc wrote: > Hi, > Thank you. The method 'annotate' works. > I tried pip to install module lineid_plot but failed. > My python environment is messed up now. I downloaded the tar.gz file > lineid_plot-0.2.tar.gz ,then > $python setup.py > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > or: setup.py --help [cmd1 cmd2 ...] > or: setup.py --help-commands > or: setup.py cmd --help > > error: no commands supplied > > However since 'annotate' works well, I will use this general way. It looks like you also need to to provide the setup command, for instance python setup.py install will build and install the module from the source code. Regards, Miguel From ghang.naoc at gmail.com Sun Dec 15 21:52:13 2013 From: ghang.naoc at gmail.com (gonghang.naoc) Date: Mon, 16 Dec 2013 10:52:13 +0800 Subject: [AstroPy] how to mark spectral lines in matplotlib? In-Reply-To: <20131215160218.GI31348@phs5.astro.Princeton.EDU> References: <52ACEACD.1020402@astro.su.se> <20131215160218.GI31348@phs5.astro.Princeton.EDU> Message-ID: Hi Miguel, Thank you.I have made a figure with lineid_plot successfully. Regards, hang On Mon, Dec 16, 2013 at 12:02 AM, Miguel de Val-Borro < miguel.deval at gmail.com> wrote: > Hi Hang, > > On Sun, Dec 15, 2013 at 11:52:24PM +0800, gonghang.naoc wrote: > > Hi, > > Thank you. The method 'annotate' works. > > I tried pip to install module lineid_plot but failed. > > My python environment is messed up now. I downloaded the tar.gz file > > lineid_plot-0.2.tar.gz ,then > > $python setup.py > > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > > or: setup.py --help [cmd1 cmd2 ...] > > or: setup.py --help-commands > > or: setup.py cmd --help > > > > error: no commands supplied > > > > However since 'annotate' works well, I will use this general way. > > It looks like you also need to to provide the setup command, for > instance > > python setup.py install > > will build and install the module from the source code. > > Regards, > Miguel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iafe.leticia at gmail.com Wed Dec 18 11:29:33 2013 From: iafe.leticia at gmail.com (Leticia Rodriguez) Date: Wed, 18 Dec 2013 14:29:33 -0200 Subject: [AstroPy] Coordinates Message-ID: Hi, I'm trying to do an example from release 0.3 doc: >>> from astropy import coordinates as coords>>> c = coords.ICRS.from_name('M31') but i'm getting this error: ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] Traceback (most recent call last): File "coordinates.py", line 7, in c = coords.ICRS.from_name('M31') AttributeError: 'module' object has no attribute 'ICRS' Does anyone has the same error? Cheers, Leticia. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.deval at gmail.com Wed Dec 18 11:40:49 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Wed, 18 Dec 2013 11:40:49 -0500 Subject: [AstroPy] Coordinates In-Reply-To: References: Message-ID: <20131218164049.GK10472@phs5.astro.Princeton.EDU> Hi Leticia, The coordinates example should work on astropy 0.3. Which method have you used to install astropy on your system? Could you print astropy.__version__ in the interpreter to make sure that you are importing the latest astropy release? Best, Miguel On Wed, Dec 18, 2013 at 02:29:33PM -0200, Leticia Rodriguez wrote: > Hi, > > I'm trying to do an example from release 0.3 doc: > > >>> from astropy import coordinates as coords>>> c = coords.ICRS.from_name('M31') > > > but i'm getting this error: > > ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] > Traceback (most recent call last): > File "coordinates.py", line 7, in > c = coords.ICRS.from_name('M31') > AttributeError: 'module' object has no attribute 'ICRS' > > Does anyone has the same error? > > Cheers, > Leticia. > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From iafe.leticia at gmail.com Wed Dec 18 11:42:40 2013 From: iafe.leticia at gmail.com (Leticia Rodriguez) Date: Wed, 18 Dec 2013 14:42:40 -0200 Subject: [AstroPy] Coordinates In-Reply-To: <20131218164049.GK10472@phs5.astro.Princeton.EDU> References: <20131218164049.GK10472@phs5.astro.Princeton.EDU> Message-ID: Hi Miguel, I used pip but I'm having some problems with the Linux version to upgrade astropy. It's on version 0.2.4 I'm going to fix it. Thanks for all your answers. BR Leticia. 2013/12/18 Miguel de Val-Borro > Hi Leticia, > > The coordinates example should work on astropy 0.3. Which method have > you used to install astropy on your system? Could you print > astropy.__version__ in the interpreter to make sure that you are > importing the latest astropy release? > > Best, > Miguel > > On Wed, Dec 18, 2013 at 02:29:33PM -0200, Leticia Rodriguez wrote: > > Hi, > > > > I'm trying to do an example from release 0.3 doc: > > > > >>> from astropy import coordinates as coords>>> c = > coords.ICRS.from_name('M31') > > > > > > but i'm getting this error: > > > > ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] > > Traceback (most recent call last): > > File "coordinates.py", line 7, in > > c = coords.ICRS.from_name('M31') > > AttributeError: 'module' object has no attribute 'ICRS' > > > > Does anyone has the same error? > > > > Cheers, > > Leticia. > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.deval at gmail.com Wed Dec 18 11:53:04 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Wed, 18 Dec 2013 11:53:04 -0500 Subject: [AstroPy] Coordinates In-Reply-To: References: <20131218164049.GK10472@phs5.astro.Princeton.EDU> Message-ID: <20131218165304.GL10472@phs5.astro.Princeton.EDU> Hi Leticia, This command will install the newest available release and uninstall the previous one (if it was installed by pip). pip install --upgrade astropy Miguel On Wed, Dec 18, 2013 at 02:42:40PM -0200, Leticia Rodriguez wrote: > Hi Miguel, > > I used pip but I'm having some problems with the Linux version to upgrade > astropy. > > It's on version 0.2.4 > > I'm going to fix it. > Thanks for all your answers. > > BR > Leticia. > > > 2013/12/18 Miguel de Val-Borro > > > Hi Leticia, > > > > The coordinates example should work on astropy 0.3. Which method have > > you used to install astropy on your system? Could you print > > astropy.__version__ in the interpreter to make sure that you are > > importing the latest astropy release? > > > > Best, > > Miguel > > > > On Wed, Dec 18, 2013 at 02:29:33PM -0200, Leticia Rodriguez wrote: > > > Hi, > > > > > > I'm trying to do an example from release 0.3 doc: > > > > > > >>> from astropy import coordinates as coords>>> c = > > coords.ICRS.from_name('M31') > > > > > > > > > but i'm getting this error: > > > > > > ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] > > > Traceback (most recent call last): > > > File "coordinates.py", line 7, in > > > c = coords.ICRS.from_name('M31') > > > AttributeError: 'module' object has no attribute 'ICRS' > > > > > > Does anyone has the same error? > > > > > > Cheers, > > > Leticia. > > > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > From mcraig at mnstate.edu Wed Dec 18 14:13:01 2013 From: mcraig at mnstate.edu (Matthew Craig) Date: Wed, 18 Dec 2013 13:13:01 -0600 Subject: [AstroPy] Coordinates In-Reply-To: <20131218165304.GL10472@phs5.astro.Princeton.EDU> References: <20131218164049.GK10472@phs5.astro.Princeton.EDU> <20131218165304.GL10472@phs5.astro.Princeton.EDU> Message-ID: <0409F5CA-9CCB-4B7A-B28F-3EA9B9A9B67A@mnstate.edu> Hi, > pip install --upgrade astropy A heads-up?this will also try to upgrade any packages on which astropy depends that also has newer version, including some, like numpy, that can take a very long time to compile. If you want to upgrade astropy but *not* any of the packages on which it depends add the --no-deps option: pip install --no-deps --upgrade astropy upgrades astropy but nothing else. Matt Craig On sabbatical 2013-14: email is the best way to reach me ---- Professor Department of Physics and Astronomy Minnesota State University Moorhead On Dec 18, 2013, at 10:53 AM, Miguel de Val-Borro wrote: > Hi Leticia, > > This command will install the newest available release and uninstall the > previous one (if it was installed by pip). > > pip install --upgrade astropy > > Miguel > > On Wed, Dec 18, 2013 at 02:42:40PM -0200, Leticia Rodriguez wrote: >> Hi Miguel, >> >> I used pip but I'm having some problems with the Linux version to upgrade >> astropy. >> >> It's on version 0.2.4 >> >> I'm going to fix it. >> Thanks for all your answers. >> >> BR >> Leticia. >> >> >> 2013/12/18 Miguel de Val-Borro >> >>> Hi Leticia, >>> >>> The coordinates example should work on astropy 0.3. Which method have >>> you used to install astropy on your system? Could you print >>> astropy.__version__ in the interpreter to make sure that you are >>> importing the latest astropy release? >>> >>> Best, >>> Miguel >>> >>> On Wed, Dec 18, 2013 at 02:29:33PM -0200, Leticia Rodriguez wrote: >>>> Hi, >>>> >>>> I'm trying to do an example from release 0.3 doc: >>>> >>>>>>> from astropy import coordinates as coords>>> c = >>> coords.ICRS.from_name('M31') >>>> >>>> >>>> but i'm getting this error: >>>> >>>> ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] >>>> Traceback (most recent call last): >>>> File "coordinates.py", line 7, in >>>> c = coords.ICRS.from_name('M31') >>>> AttributeError: 'module' object has no attribute 'ICRS' >>>> >>>> Does anyone has the same error? >>>> >>>> Cheers, >>>> Leticia. >>> >>>> _______________________________________________ >>>> 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 Thu Dec 19 11:03:41 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 19 Dec 2013 17:03:41 +0100 Subject: [AstroPy] Unified file read method without opening file? In-Reply-To: <4A543406-FC3B-46DA-B0A5-A9FB815F29F2@ligo.org> References: <4A543406-FC3B-46DA-B0A5-A9FB815F29F2@ligo.org> Message-ID: Hi Duncan, You should be able to pass an open h5py file object to Table.read and Table.write. Does it not work for you? Cheers, Tom On 13 December 2013 07:05, Duncan Macleod wrote: > Hi all, > > I?m a big fan of the astropy unified file read/write interface, and have > used it in a project for reading gravitational-wave data. Is there a way to > not have the astropy.io.registry.read method open all file paths if > format=None, the lower-level methods that then get called take in filepaths > themselves, not open files (e.g. h5py.File) and I don?t want to then have > two open copies of the same file? > > > Thanks > Duncan > -- > Duncan Macleod > duncan.macleod at ligo.org > LIGO Data Grid systems development > Louisiana State University > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From iafe.leticia at gmail.com Thu Dec 19 11:06:06 2013 From: iafe.leticia at gmail.com (Leticia Rodriguez) Date: Thu, 19 Dec 2013 14:06:06 -0200 Subject: [AstroPy] Coordinates In-Reply-To: <0409F5CA-9CCB-4B7A-B28F-3EA9B9A9B67A@mnstate.edu> References: <20131218164049.GK10472@phs5.astro.Princeton.EDU> <20131218165304.GL10472@phs5.astro.Princeton.EDU> <0409F5CA-9CCB-4B7A-B28F-3EA9B9A9B67A@mnstate.edu> Message-ID: Thanks for yours answers! Sincerely, Leticia. 2013/12/18 Matthew Craig > Hi, > > pip install --upgrade astropy > > > A heads-up?this will also try to upgrade any packages on which astropy > depends that also has newer version, including some, like numpy, that can > take a very long time to compile. > > If you want to upgrade astropy but *not* any of the packages on which it > depends add the --no-deps option: > > pip install --no-deps --upgrade astropy > > upgrades astropy but nothing else. > > Matt Craig > > On sabbatical 2013-14: email is the best way to reach me > ---- > Professor > Department of Physics and Astronomy > Minnesota State University Moorhead > > On Dec 18, 2013, at 10:53 AM, Miguel de Val-Borro > wrote: > > Hi Leticia, > > This command will install the newest available release and uninstall the > previous one (if it was installed by pip). > > pip install --upgrade astropy > > Miguel > > On Wed, Dec 18, 2013 at 02:42:40PM -0200, Leticia Rodriguez wrote: > > Hi Miguel, > > I used pip but I'm having some problems with the Linux version to upgrade > astropy. > > It's on version 0.2.4 > > I'm going to fix it. > Thanks for all your answers. > > BR > Leticia. > > > 2013/12/18 Miguel de Val-Borro > > Hi Leticia, > > The coordinates example should work on astropy 0.3. Which method have > you used to install astropy on your system? Could you print > astropy.__version__ in the interpreter to make sure that you are > importing the latest astropy release? > > Best, > Miguel > > On Wed, Dec 18, 2013 at 02:29:33PM -0200, Leticia Rodriguez wrote: > > Hi, > > I'm trying to do an example from release 0.3 doc: > > from astropy import coordinates as coords>>> c = > > coords.ICRS.from_name('M31') > > > > but i'm getting this error: > > ERROR: AttributeError: 'module' object has no attribute 'ICRS' [__main__] > Traceback (most recent call last): > File "coordinates.py", line 7, in > c = coords.ICRS.from_name('M31') > AttributeError: 'module' object has no attribute 'ICRS' > > Does anyone has the same error? > > Cheers, > Leticia. > > > _______________________________________________ > 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 ejensen1 at swarthmore.edu Fri Dec 20 11:07:46 2013 From: ejensen1 at swarthmore.edu (Eric Jensen) Date: Fri, 20 Dec 2013 11:07:46 -0500 Subject: [AstroPy] Documentation or examples for working with UV-FITS files? Message-ID: <0B9ED55D-1409-40BF-8660-8316D3339E8C@swarthmore.edu> Hi all, Can anyone point me to any documentation about UV-FITS files? I'd like to be able to take two UV-FITS files written from CASA (one of observed data and one of a model) and calculate the chi-squared of the data-model comparison in uv space. But I just can't find enough (read: any) documentation of the format to get a sense of how to do this. There's some information linked from here: https://safe.nrao.edu/wiki/bin/view/Software/CasaAipsSpwDefinition but it's a little hard (for me at least) to parse. As far as python implementation, Googling reveals this set of basic routines: http://www.mrao.cam.ac.uk/~bn204/alma/memo-turb/uvfits.py but no documentation. And CASA has some uv data handling routines, but it doesn't appear to have general arithmetic routines for uv data. So I'd like to try to implement this in python, but I need some docs to help me get started. Thanks in advance for any help you can give, Eric From adam.g.ginsburg at gmail.com Fri Dec 20 11:35:40 2013 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Fri, 20 Dec 2013 17:35:40 +0100 Subject: [AstroPy] Documentation or examples for working with UV-FITS files? In-Reply-To: <0B9ED55D-1409-40BF-8660-8316D3339E8C@swarthmore.edu> References: <0B9ED55D-1409-40BF-8660-8316D3339E8C@swarthmore.edu> Message-ID: Hi Eric, This should probably be submitted to the NRAO as a feature request in CASA or a helpdesk ticket; it's probably possible within CASA but just not well-documented. If we figure out how to do this, we should probably get the solution posted on casaguides.nrao.edu. That said, UVFITS files are FITS binary tables. They can be accesses with astropy.io.fits. For anyone interested in having a look, there are a lot of nicely reduced UVFITS files available from https://archive.nrao.edu/cgi-bin/nvas-pos.pl (which can also be queried via astroquery.readthedocs.org/en/latest/nvas.html). Here's an example of how you can examine the contents of a UVFITS file: In [13]: d = fits.open('1.48F27CB_AY0015_1986OCT06_1.uvfits') In [14]: d Out[14]: [, , , , , ] In [15]: [(x,x.data.shape,x.data.dtype.names) for x in d] Out[15]: [(, (0, 777777701), None), (, (1,), ('FRQSEL', 'IF FREQ', 'CH WIDTH', 'TOTAL BANDWIDTH', 'SIDEBAND')), (, (29,), ('ANNAME', 'STABXYZ', 'NOSTA', 'MNTSTA', 'STAXOF', 'POLTYA', 'POLAA', 'POLCALA', 'POLTYB', 'POLAB', 'POLCALB')), (, (2007,), ('TIME', 'TIME_INTERVAL', 'ANTENNA_NO', 'SUBARRAY', 'TEMPERATURE', 'PRESSURE', 'DEWPOINT', 'WIND_VELOCITY', 'WIND_DIRECTION', 'WVR_H2O', 'IONOS_ELECTRON')), (, (623,), ('TIME1', 'TIME2', 'SOURCE', 'AMPLITUDE', 'RMS', 'WEIGHT', 'CLOSURE')), (, (50544,), ('UU---SIN', 'VV---SIN', 'WW---SIN', 'BASELINE', 'DATE', 'VISIBILITIES'))] The visibilities are in the last header, so you can grab that table and plot its various contents: In [28]: uvtable = d[-1].data In [29]: vis = uvtable['VISIBILITIES'] In [30]: plot(uvtable['UU---SIN'],uvtable['VV---SIN'],',') Out[30]: [] In [31]: plot(uvtable['UU---SIN'],vis.reshape([vis.shape[0],np.product(vis.shape[1:])]),',') [snipped - there are lots] Note the last reshaping is because there are lots of axes in visibilities for polarization and other parameters; I haven't figure out which headers/keywords describe them, but the information appears to be there. This should get you started... On Fri, Dec 20, 2013 at 5:07 PM, Eric Jensen wrote: > Hi all, > > Can anyone point me to any documentation about UV-FITS files? I'd like to be able to take two UV-FITS files written from CASA (one of observed data and one of a model) and calculate the chi-squared of the data-model comparison in uv space. But I just can't find enough (read: any) documentation of the format to get a sense of how to do this. > > There's some information linked from here: https://safe.nrao.edu/wiki/bin/view/Software/CasaAipsSpwDefinition > but it's a little hard (for me at least) to parse. > > As far as python implementation, Googling reveals this set of basic routines: > > http://www.mrao.cam.ac.uk/~bn204/alma/memo-turb/uvfits.py > > but no documentation. And CASA has some uv data handling routines, but it doesn't appear to have general arithmetic routines for uv data. So I'd like to try to implement this in python, but I need some docs to help me get started. > > Thanks in advance for any help you can give, > > Eric > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From jslavin at cfa.harvard.edu Mon Dec 23 11:16:24 2013 From: jslavin at cfa.harvard.edu (Slavin, Jonathan) Date: Mon, 23 Dec 2013 11:16:24 -0500 Subject: [AstroPy] fits table column values Message-ID: Hi all, Maybe I'm being dense today, but I'm not clear on how to do something pretty basic. The issue is that I have essentially 3-D data wherein the data is not known on a uniform grid. That is, although the data is on an x-y grid, neither the x values nor the y values are uniform. I want to save the values (i.e. z values) at each point in the grid in a fits file. The natural thing to do is either create an image or a table, but specifying the grid is not quite so straightforward in either case. For a table one could have one column be an axis (e.g. 'y') and save the y values, but then the x values are the table column 'names', which I think have to be strings. Nothing is fundamentally unworkable about that, it's just a little awkward to have string versions of the numeric axis values. If I output an image instead, then I'm left with specifying the grid locations in the header. So, I do have ways of doing what I want to do, but it just seems that the ways I've thought of are not the simplest ways. And I wonder if there isn't some other way that I haven't thought of. Any hints on this would be appreciated. Maybe some other output format (e.g. hdf5) would be better? Jon -- ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 fax: (617) 496-7577 USA ________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evert.rol at gmail.com Mon Dec 23 11:39:00 2013 From: evert.rol at gmail.com (Evert Rol) Date: Mon, 23 Dec 2013 17:39:00 +0100 Subject: [AstroPy] fits table column values In-Reply-To: References: Message-ID: <1FEA5A22-1E9E-4589-BDA1-0A39D28DDA0E@gmail.com> Hi Jon, I think you can use a table perfectly fine. Though I'm not used to FITS tables, you can afaik store vectors there as well, so a floating point 3-vector for each entry could work. In HDF 5, a simple compound table with x, y and z floating points column works also fine (which is what I'd use). If you want to go the image way, you probably need a second "flag" image to indicate the valid pixels. But yes, you'd get (a lot of) non-essential data. I assume you only want FITS to store the data; not use it to inspect the data in e.g. DS9. In fact, rereading about the FITS vector tables, perhaps you can just create an 3 x N image, with N your number of points and the other axis indicating x, y and z. So each pixel contains the x, y or z value (essentially thus the table disguised as an image); just what you feel comfortable with. (Though I'd be curious to hear if there are objections against this approach). Cheers, Evert > Hi all, > > Maybe I'm being dense today, but I'm not clear on how to do something pretty basic. The issue is that I have essentially 3-D data wherein the data is not known on a uniform grid. That is, although the data is on an x-y grid, neither the x values nor the y values are uniform. I want to save the values (i.e. z values) at each point in the grid in a fits file. The natural thing to do is either create an image or a table, but specifying the grid is not quite so straightforward in either case. For a table one could have one column be an axis (e.g. 'y') and save the y values, but then the x values are the table column 'names', which I think have to be strings. Nothing is fundamentally unworkable about that, it's just a little awkward to have string versions of the numeric axis values. If I output an image instead, then I'm left with specifying the grid locations in the header. > > So, I do have ways of doing what I want to do, but it just seems that the ways I've thought of are not the simplest ways. And I wonder if there isn't some other way that I haven't thought of. Any hints on this would be appreciated. Maybe some other output format (e.g. hdf5) would be better? > > Jon > > -- > ________________________________________________________ > Jonathan D. Slavin Harvard-Smithsonian CfA > jslavin at cfa.harvard.edu 60 Garden Street, MS 83 > phone: (617) 496-7981 Cambridge, MA 02138-1516 > fax: (617) 496-7577 USA > ________________________________________________________ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From aldcroft at head.cfa.harvard.edu Mon Dec 23 12:40:25 2013 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 23 Dec 2013 12:40:25 -0500 Subject: [AstroPy] fits table column values In-Reply-To: References: Message-ID: On Mon, Dec 23, 2013 at 11:16 AM, Slavin, Jonathan wrote: > Hi all, > > Maybe I'm being dense today, but I'm not clear on how to do something > pretty basic. The issue is that I have essentially 3-D data wherein the > data is not known on a uniform grid. That is, although the data is on an > x-y grid, neither the x values nor the y values are uniform. I want to > save the values (i.e. z values) at each point in the grid in a fits file. > The natural thing to do is either create an image or a table, but > specifying the grid is not quite so straightforward in either case. For a > table one could have one column be an axis (e.g. 'y') and save the y > values, but then the x values are the table column 'names', which I think > have to be strings. Nothing is fundamentally unworkable about that, it's > just a little awkward to have string versions of the numeric axis values. > If I output an image instead, then I'm left with specifying the grid > locations in the header. > If I understand, you have data values Z on a rectilinear 2-d grid (X, Y). If so one solution I've seen before [1] is storing an image in the primary HDU and then the X and Y grid values in the second HDU as a table with two columns X, Y and just one row. Each of those two columns is actually a vector of the appropriate length. This is a little contorted, but FITS is not an ideal match for this. [1] I forget exactly where, but there is a FITS standard for calibration data products that uses this layout for N-d data defined on rectilinear grids. > > So, I do have ways of doing what I want to do, but it just seems that the > ways I've thought of are not the simplest ways. And I wonder if there > isn't some other way that I haven't thought of. Any hints on this would be > appreciated. Maybe some other output format (e.g. hdf5) would be better? > Certainly HDF5 is more flexible and would let you store the two vectors of X and Y grid locations in a more natural way. - Tom > > Jon > > -- > ________________________________________________________ > Jonathan D. Slavin Harvard-Smithsonian CfA > jslavin at cfa.harvard.edu 60 Garden Street, MS 83 > phone: (617) 496-7981 Cambridge, MA 02138-1516 > fax: (617) 496-7577 USA > ________________________________________________________ > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jslavin at cfa.harvard.edu Mon Dec 23 13:08:43 2013 From: jslavin at cfa.harvard.edu (Slavin, Jonathan) Date: Mon, 23 Dec 2013 13:08:43 -0500 Subject: [AstroPy] fits table column values Message-ID: Hi Tom, You have it right. I actually like that approach -- i.e. store the z data as the primary image and the grid as a table in an extension, though because the axis arrays are different lengths it is a bit awkward -- requiring as you say vector columns. I should learn to use HDF5, but then I would also have to learn how to access the data (in my case) in IDL (not my choice). I wish the docs for h5py were a bit better. Evert, I think you're not understanding the data structure quite. The data has a non-uniform distribution in x and y, though there are (z) values for every x and y on the grid -- that is, it is a grid but a non-uniform one. If the grid were uniform I would just specify something like the start point and spacing for each dimension in the header. In this case, it is possible to specify all the values for each dimension in the header, though not quite so convenient. Jon On Mon, Dec 23, 2013 at 12:40 PM, Aldcroft, Thomas < aldcroft at head.cfa.harvard.edu> wrote: > > > > On Mon, Dec 23, 2013 at 11:16 AM, Slavin, Jonathan < > jslavin at cfa.harvard.edu> wrote: > >> Hi all, >> >> Maybe I'm being dense today, but I'm not clear on how to do something >> pretty basic. The issue is that I have essentially 3-D data wherein the >> data is not known on a uniform grid. That is, although the data is on an >> x-y grid, neither the x values nor the y values are uniform. I want to >> save the values (i.e. z values) at each point in the grid in a fits file. >> The natural thing to do is either create an image or a table, but >> specifying the grid is not quite so straightforward in either case. For a >> table one could have one column be an axis (e.g. 'y') and save the y >> values, but then the x values are the table column 'names', which I think >> have to be strings. Nothing is fundamentally unworkable about that, it's >> just a little awkward to have string versions of the numeric axis values. >> If I output an image instead, then I'm left with specifying the grid >> locations in the header. >> > > If I understand, you have data values Z on a rectilinear 2-d grid (X, Y). > If so one solution I've seen before [1] is storing an image in the primary > HDU and then the X and Y grid values in the second HDU as a table with two > columns X, Y and just one row. Each of those two columns is actually a > vector of the appropriate length. This is a little contorted, but FITS is > not an ideal match for this. > > [1] I forget exactly where, but there is a FITS standard for calibration > data products that uses this layout for N-d data defined on rectilinear > grids. > > >> >> So, I do have ways of doing what I want to do, but it just seems that the >> ways I've thought of are not the simplest ways. And I wonder if there >> isn't some other way that I haven't thought of. Any hints on this would be >> appreciated. Maybe some other output format (e.g. hdf5) would be better? >> > > Certainly HDF5 is more flexible and would let you store the two vectors of > X and Y grid locations in a more natural way. > > - Tom > > >> >> Jon >> >> -- >> ________________________________________________________ >> Jonathan D. Slavin Harvard-Smithsonian CfA >> jslavin at cfa.harvard.edu 60 Garden Street, MS 83 >> phone: (617) 496-7981 Cambridge, MA 02138-1516 >> fax: (617) 496-7577 USA >> ________________________________________________________ >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > -- ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 fax: (617) 496-7577 USA ________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanlu001 at gmail.com Sat Dec 28 04:32:16 2013 From: juanlu001 at gmail.com (Juan Luis Cano) Date: Sat, 28 Dec 2013 10:32:16 +0100 Subject: [AstroPy] Trouble when creating a vectorial Quantity from its components Message-ID: <52BE9AA0.90405@gmail.com> Hello all, I'm using astropy 0.3 under python 3.3 with numpy 1.8.0, and while I was trying to build a vector `Quantity` from its components I found this: ``` >>> import numpy as np >>> from astropy import units as u >>> p = 1000 * u.km; p >>> nu = 28 * u.deg >>> r = [p * np.cos(nu), p * np.sin(nu), 0]; r [, , 0] ``` This is perfectly normal, but I expected a vectorial `Quantity`. Trying to convert to an array didn't work: ``` >>> np.array(r) Traceback (most recent call last): File "", line 1, in ValueError: setting an array element with a sequence. ``` Is there any way I can avoid doing this? ``` >>> r = [p.si.value * np.cos(nu), p.si.value * np.sin(nu), 0] * p.si.unit; r ``` because it might get quite verbose if there are more magnitudes. Thanks! From evert.rol at gmail.com Sat Dec 28 06:49:57 2013 From: evert.rol at gmail.com (Evert Rol) Date: Sat, 28 Dec 2013 12:49:57 +0100 Subject: [AstroPy] Trouble when creating a vectorial Quantity from its components In-Reply-To: <52BE9AA0.90405@gmail.com> References: <52BE9AA0.90405@gmail.com> Message-ID: <4542BEB7-3839-4B34-B93D-74E21672C76F@gmail.com> Hi Juan, > Is there any way I can avoid doing this? > > ``` >>>> r = [p.si.value * np.cos(nu), p.si.value * np.sin(nu), 0] * > p.si.unit; r > > ``` > > because it might get quite verbose if there are more magnitudes. Can't you simply do >>> r = np.array([np.cos(nu), np.sin(nu), 0]) * p; r So just move p outside the array. Or is that still to verbose? From your example, I'm assuming p is always the same. If not, you can make p an array of just lengths and multiple that with np.array([np.cos(nu), np.sin(nu), 0]): >>> p = np.array([1000, 2000, 3000]) * u.km >>> r = np.array([np.cos(nu), np.sin(nu), 0]) * p; r Cheers, Evert From juanlu001 at gmail.com Sat Dec 28 07:09:47 2013 From: juanlu001 at gmail.com (Juan Luis Cano) Date: Sat, 28 Dec 2013 13:09:47 +0100 Subject: [AstroPy] Trouble when creating a vectorial Quantity from its components In-Reply-To: <4542BEB7-3839-4B34-B93D-74E21672C76F@gmail.com> References: <52BE9AA0.90405@gmail.com> <4542BEB7-3839-4B34-B93D-74E21672C76F@gmail.com> Message-ID: <52BEBF8B.6090009@gmail.com> On 12/28/2013 12:49 PM, Evert Rol wrote: > Hi Juan, > >> Is there any way I can avoid doing this? >> >> ``` >> >>> r = [p.si.value * np.cos(nu), p.si.value * np.sin(nu), 0] * p.si.unit; r >> >> ``` >> >> because it might get quite verbose if there are more magnitudes. > Can't you simply do > > >>> r = np.array([np.cos(nu), np.sin(nu), 0]) * p; r > > > So just move p outside the array. Or is that still to verbose? Well, that's a good idea! It will do the trick for me, not worried about corner cases right now. Thanks! > From your example, I'm assuming p is always the same. If not, you can make p an array of just lengths and multiple that with np.array([np.cos(nu), np.sin(nu), 0]): > >>> p = np.array([1000, 2000, 3000]) * u.km > >>> r = np.array([np.cos(nu), np.sin(nu), 0]) * p; r > > > > Cheers, > > Evert > From lsinger at caltech.edu Tue Dec 31 15:58:55 2013 From: lsinger at caltech.edu (Leo Singer) Date: Tue, 31 Dec 2013 12:58:55 -0800 Subject: [AstroPy] Ecliptic coordinates in astropy.coordinates? Message-ID: <01AE182F-2521-4039-A63E-B1F855D3E662@caltech.edu> Hi, Is it possible to convert from ICRS to ecliptic coordinates in astropy? Thanks, Leo Singer Graduate Student @ LIGO-Caltech