From thomas.robitaille at gmail.com Mon Mar 2 10:23:29 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 2 Mar 2015 16:23:29 +0100 Subject: [AstroPy] Scientific Python Survey Message-ID: Hi everyone, If you use scientific Python packages for your research/work, I would appreciate if you could take a few minutes to fill out the following survey: http://goo.gl/PXzFAk The aim of this survey is to find out what versions of Python and various scientific Python packages people are using, and how people typically install packages, in order to determine how developers can better meet the needs of the Scientific Python community (for example, a common question is which version of Numpy need to be supported by packages). This is a follow-up to a similar survey which I did back in 2012 and which provided very interesting results that you can read about here: http://astrofrog.github.io/blog/2013/01/13/what-python-installations-are-scientists-using Please feel free to forward this survey to people in your own scientific Python communities! I will publish the results online in a few weeks. Thanks! Tom From matthew.brett at gmail.com Thu Mar 5 19:35:42 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 5 Mar 2015 16:35:42 -0800 Subject: [AstroPy] OSX wheels repo Message-ID: Hi, I saw your email about the survey on scipy-user and that reminded me to make a travis wheel-building repo for astropy. It's here: https://github.com/MacPython/astropy-wheels When you send a commit or trigger a build on the associated travis-ci page: https://travis-ci.org/MacPython/astropy-wheels then the repo will build an astropy wheel from the most recent tagged astropy version, for Pythons 2.7, 3.3, 3.4, and upload them to http://wheels.scipy.org. I just did a build, wheels already uploaded to http://wheels.scipy.org To test, on standard OSX Pythons (system python, python.org Python, homebrew, macports): pip install -f http://wheels.scipy.org astropy Who should I add as administrator to this repo so y'all can push fixes / trigger builds and so on? Would you consider putting these wheels up on pypi? That is what numpy / scipy / matplotib / scikit-learn / scikit-image / h5py are doing these days... Best, Matthew From wkerzendorf at gmail.com Fri Mar 6 04:11:05 2015 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Fri, 06 Mar 2015 09:11:05 +0000 Subject: [AstroPy] [ANN] TARDIS 1.0.1 Message-ID: I?m happy to announce the 1.0.1 release of TARDIS - a 1D montecarlo spectral synthesis code for supernovae. Documentation and example files are available at http://tardis.readthedocs.org (Paper I can be found at http://labs.adsabs.harvard.edu/adsabs/abs/2014MNRAS.440..387K/). Currently, we focus on SN Ia but are in the process of implementing the necessary microphysics for Type II supernovae. This release contains all the development effort of the TARDIS team from the 0.9.2 release (June 2014) till now. The major change in this case is that most of the montecarlo part is now written in C (the user interaction is and will stay python), which in some cases gives a speed increase of a factor of 4 and more. A detailed account of our development can be seen in the changelog: https://github.com/tardis-sn/tardis/blob/master/CHANGELOG.rstThis release is the work of 9 months development work As usual, we would like to thank the astropy community, for providing not only astropy but also package-template/astropy-helpers that is used heavily within TARDIS. The code is available through PyPi and the github repo https://github.com/ tardis-sn/tardis. Please do not hesitate to let us know if you encounter any problems with the code! Happy synthesizing, Wolfgang (on behalf of the TARDIS team) -------------- next part -------------- An HTML attachment was scrubbed... URL: From godber at asu.edu Fri Mar 6 08:27:13 2015 From: godber at asu.edu (Austin Godber) Date: Fri, 6 Mar 2015 06:27:13 -0700 Subject: [AstroPy] OSX wheels repo In-Reply-To: References: Message-ID: Hi Matthew, I haven't yet used the deploy feature with Travis but it looks like the value ['deploy']['api_key']['secret'] in the travis.yml is the kind of thing that shouldn't be included in the .yml file. Travis offers an "environment variable" option in the settings for each project. I think that is where you need to store this sort of thing. So I'd regenerate you cloudfiles api key and save it as an environment variable, tweak the travis.yml. Austin PS - Once More, with Feeling is a fabulous Buffy episode. On Thu, Mar 5, 2015 at 5:35 PM, Matthew Brett wrote: > Hi, > > I saw your email about the survey on scipy-user and that reminded me > to make a travis wheel-building repo for astropy. > > It's here: > > https://github.com/MacPython/astropy-wheels > > When you send a commit or trigger a build on the associated travis-ci page: > > https://travis-ci.org/MacPython/astropy-wheels > > then the repo will build an astropy wheel from the most recent tagged > astropy version, for Pythons 2.7, 3.3, 3.4, and upload them to > http://wheels.scipy.org. > > I just did a build, wheels already uploaded to http://wheels.scipy.org > > To test, on standard OSX Pythons (system python, python.org Python, > homebrew, macports): > > pip install -f http://wheels.scipy.org astropy > > Who should I add as administrator to this repo so y'all can push fixes > / trigger builds and so on? > > Would you consider putting these wheels up on pypi? That is what > numpy / scipy / matplotib / scikit-learn / scikit-image / h5py are > doing these days... > > Best, > > Matthew > _______________________________________________ > 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 Mar 6 12:00:40 2015 From: ejensen1 at swarthmore.edu (Eric L. N. Jensen) Date: Fri, 6 Mar 2015 12:00:40 -0500 Subject: [AstroPy] Galactic UVW space motions and uncertainties in Python (a la IDL's gal_uvw) Message-ID: <14FB2C45-BFF4-4452-B1B7-3CDB341DFD26@swarthmore.edu> Hi all, I need to calculate three-dimensional Galactic space motions UVW for some stars (given position, distance, proper motion, and radial velocity as inputs), and I find that this is a task where I?m tempted to fall back on old IDL code I have, since the IDL astrolib has a gal_uvw routine to do this, and I have a complementary routine in IDL that implements the Johnson & Soderblom (1987; http://adsabs.harvard.edu/abs/1987AJ.....93..864J ) formalism for propagating uncertainties from the input quantities to the output velocities. I could tackle the task of translating the IDL code into Python, but realistically I?m unlikely to do so in the short term (and my knowledge of matrix algebra in Python is pretty thin), so I thought I would check and see if anyone else has done this already. It looks like Ian Crossfield has a Python translation of gal_uvw here: http://www.lpl.arizona.edu/~ianc/python/astrolib.html Has anyone done the corresponding coding of the error propagation for UVW? If not, and if anyone else is interested in this, I?d be happy to share the IDL code I have if someone wanted to translate it to Python. It?s not very long - the trick is just getting the matrix algebra syntax translated correctly. Thanks in advance for your help with this, Eric From matthew.brett at gmail.com Fri Mar 6 12:01:35 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 6 Mar 2015 09:01:35 -0800 Subject: [AstroPy] OSX wheels repo In-Reply-To: References: Message-ID: Hi, On Fri, Mar 6, 2015 at 5:27 AM, Austin Godber wrote: > Hi Matthew, > > I haven't yet used the deploy feature with Travis but it looks like the > value ['deploy']['api_key']['secret'] in the travis.yml is the kind of thing > that shouldn't be included in the .yml file. Travis offers an "environment > variable" option in the settings for each project. I think that is where > you need to store this sort of thing. So I'd regenerate you cloudfiles api > key and save it as an environment variable, tweak the travis.yml. Maybe I am misunderstanding, but the value here: api_key: secure: "eRvhZ4GkrB6sUpH4tNHvdgN91Jrhl+F+7J4BXuH3Kql9kCrXlLvH+TtoYsDX1x6zAFJy1eVePtNbwMdzFcWP9koQXPHD2+o7U6AFomCN8KjJxd7ha8K7HDWbvn+R+bn1/tr0Fz04pyqlLyzM0pe+QO4JvcHQ+8TsDKuIDi9cYUE=" is encrypted against the repository key - the rackspace API key is much different, and, as far as I know, unobtainable without the repository key. Or did I miss something? Cheers, Matthew From jo.bovy at gmail.com Fri Mar 6 12:11:09 2015 From: jo.bovy at gmail.com (Jo Bovy) Date: Fri, 6 Mar 2015 12:11:09 -0500 Subject: [AstroPy] Galactic UVW space motions and uncertainties in Python (a la IDL's gal_uvw) In-Reply-To: <14FB2C45-BFF4-4452-B1B7-3CDB341DFD26@swarthmore.edu> References: <14FB2C45-BFF4-4452-B1B7-3CDB341DFD26@swarthmore.edu> Message-ID: Dear Eric, galpy (https://github.com/jobovy/galpy) has routines in galpy.util.bovy_coords for most transformations of observed quantities to Galactic and Galactocentric positions and velocities: http://galpy.readthedocs.org/en/master/reference/bovycoords.html In particular, there is a routine to propagate the uncertainties to UVW (cov_dvrpmllbb_to_vxyz in combination with cov_pmrapmdec_to_pmllpmbb). vxvyvz is just UVW in the code. Best, Jo On Fri, Mar 6, 2015 at 12:00 PM, Eric L. N. Jensen wrote: > Hi all, > > I need to calculate three-dimensional Galactic space motions UVW for some > stars (given position, distance, proper motion, and radial velocity as > inputs), and I find that this is a task where I?m tempted to fall back on > old IDL code I have, since the IDL astrolib has a gal_uvw routine to do > this, and I have a complementary routine in IDL that implements the Johnson > & Soderblom (1987; http://adsabs.harvard.edu/abs/1987AJ.....93..864J ) > formalism for propagating uncertainties from the input quantities to the > output velocities. > > I could tackle the task of translating the IDL code into Python, but > realistically I?m unlikely to do so in the short term (and my knowledge of > matrix algebra in Python is pretty thin), so I thought I would check and > see if anyone else has done this already. It looks like Ian Crossfield > has a Python translation of gal_uvw here: > http://www.lpl.arizona.edu/~ianc/python/astrolib.html > > Has anyone done the corresponding coding of the error propagation for > UVW? If not, and if anyone else is interested in this, I?d be happy to > share the IDL code I have if someone wanted to translate it to Python. > It?s not very long - the trick is just getting the matrix algebra syntax > translated correctly. > > Thanks in advance for your help with this, > > Eric > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From teuben at astro.umd.edu Fri Mar 6 12:16:17 2015 From: teuben at astro.umd.edu (Peter Teuben) Date: Fri, 06 Mar 2015 12:16:17 -0500 Subject: [AstroPy] Galactic UVW space motions and uncertainties in Python (a la IDL's gal_uvw) In-Reply-To: <14FB2C45-BFF4-4452-B1B7-3CDB341DFD26@swarthmore.edu> References: <14FB2C45-BFF4-4452-B1B7-3CDB341DFD26@swarthmore.edu> Message-ID: <54F9E0E1.6020608@astro.umd.edu> Hi Eric I have some notes in the nemo program 'mkgalorbit' on this. Also note the two conventions of UVW through history. http://carma.astro.umd.edu/nemo/man_html/mkgalorbit.1.html I haven't worked on this in a few years, so I hope the information hasn't staled. peter On 03/06/2015 12:00 PM, Eric L. N. Jensen wrote: > Hi all, > > I need to calculate three-dimensional Galactic space motions UVW for some stars (given position, distance, proper motion, and radial velocity as inputs), and I find that this is a task where I?m tempted to fall back on old IDL code I have, since the IDL astrolib has a gal_uvw routine to do this, and I have a complementary routine in IDL that implements the Johnson & Soderblom (1987; http://adsabs.harvard.edu/abs/1987AJ.....93..864J ) formalism for propagating uncertainties from the input quantities to the output velocities. > > I could tackle the task of translating the IDL code into Python, but realistically I?m unlikely to do so in the short term (and my knowledge of matrix algebra in Python is pretty thin), so I thought I would check and see if anyone else has done this already. It looks like Ian Crossfield has a Python translation of gal_uvw here: http://www.lpl.arizona.edu/~ianc/python/astrolib.html > > Has anyone done the corresponding coding of the error propagation for UVW? If not, and if anyone else is interested in this, I?d be happy to share the IDL code I have if someone wanted to translate it to Python. It?s not very long - the trick is just getting the matrix algebra syntax translated correctly. > > Thanks in advance for your help with this, > > Eric > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From embray at stsci.edu Fri Mar 6 12:36:44 2015 From: embray at stsci.edu (Erik Bray) Date: Fri, 6 Mar 2015 12:36:44 -0500 Subject: [AstroPy] OSX wheels repo In-Reply-To: References: Message-ID: <54F9E5AC.9070901@stsci.edu> Matthew is right--I admit I also had forgotten how this works at first, despite having used it myself to encrypt some environment variables for a .travis.yml file. So as far as I can tell this usage seems fine, if not initially alarming-looking. For more information, see http://docs.travis-ci.com/user/encryption-keys/ Erik On 03/06/2015 12:01 PM, Matthew Brett wrote: > Hi, > > On Fri, Mar 6, 2015 at 5:27 AM, Austin Godber wrote: >> Hi Matthew, >> >> I haven't yet used the deploy feature with Travis but it looks like the >> value ['deploy']['api_key']['secret'] in the travis.yml is the kind of thing >> that shouldn't be included in the .yml file. Travis offers an "environment >> variable" option in the settings for each project. I think that is where >> you need to store this sort of thing. So I'd regenerate you cloudfiles api >> key and save it as an environment variable, tweak the travis.yml. > > Maybe I am misunderstanding, but the value here: > > api_key: > secure: "eRvhZ4GkrB6sUpH4tNHvdgN91Jrhl+F+7J4BXuH3Kql9kCrXlLvH+TtoYsDX1x6zAFJy1eVePtNbwMdzFcWP9koQXPHD2+o7U6AFomCN8KjJxd7ha8K7HDWbvn+R+bn1/tr0Fz04pyqlLyzM0pe+QO4JvcHQ+8TsDKuIDi9cYUE=" > > is encrypted against the repository key - the rackspace API key is > much different, and, as far as I know, unobtainable without the > repository key. Or did I miss something? > > Cheers, > > Matthew > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From godber at asu.edu Fri Mar 6 12:42:58 2015 From: godber at asu.edu (Austin Godber) Date: Fri, 6 Mar 2015 10:42:58 -0700 Subject: [AstroPy] OSX wheels repo In-Reply-To: <54F9E5AC.9070901@stsci.edu> References: <54F9E5AC.9070901@stsci.edu> Message-ID: Matt, that's great to hear, it's just alarming at first and I've seen the environment variables used as an alternative so I didn't want this to pass by unmentioned. I have no idea what a repository key is. I'll have to look at this mechanism. Thanks, Austin On Mar 6, 2015 10:36 AM, "Erik Bray" wrote: > Matthew is right--I admit I also had forgotten how this works at first, > despite > having used it myself to encrypt some environment variables for a > .travis.yml file. > > So as far as I can tell this usage seems fine, if not initially > alarming-looking. For more information, see > > http://docs.travis-ci.com/user/encryption-keys/ > > Erik > > On 03/06/2015 12:01 PM, Matthew Brett wrote: > > Hi, > > > > On Fri, Mar 6, 2015 at 5:27 AM, Austin Godber wrote: > >> Hi Matthew, > >> > >> I haven't yet used the deploy feature with Travis but it looks like the > >> value ['deploy']['api_key']['secret'] in the travis.yml is the kind of > thing > >> that shouldn't be included in the .yml file. Travis offers an > "environment > >> variable" option in the settings for each project. I think that is > where > >> you need to store this sort of thing. So I'd regenerate you cloudfiles > api > >> key and save it as an environment variable, tweak the travis.yml. > > > > Maybe I am misunderstanding, but the value here: > > > > api_key: > > secure: > "eRvhZ4GkrB6sUpH4tNHvdgN91Jrhl+F+7J4BXuH3Kql9kCrXlLvH+TtoYsDX1x6zAFJy1eVePtNbwMdzFcWP9koQXPHD2+o7U6AFomCN8KjJxd7ha8K7HDWbvn+R+bn1/tr0Fz04pyqlLyzM0pe+QO4JvcHQ+8TsDKuIDi9cYUE=" > > > > is encrypted against the repository key - the rackspace API key is > > much different, and, as far as I know, unobtainable without the > > repository key. Or did I miss something? > > > > Cheers, > > > > Matthew > > _______________________________________________ > > 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 embray at stsci.edu Fri Mar 6 19:07:51 2015 From: embray at stsci.edu (Erik Bray) Date: Fri, 6 Mar 2015 19:07:51 -0500 Subject: [AstroPy] [ANN] Astropy v1.0.1 Released Message-ID: <54FA4157.7040608@stsci.edu> Hi all, We don't always advertise Astropy patch releases, but I wanted to make a note of this one since it comes closely on the heels of Astropy v1.0. This release was made as soon as it was primarily to address two issues: 1) One of the key new features of Astropy v1.0, the vastly sped up ASCII table reading, was not fully functioning on Windows. [1] 2) There were a few installation issues, particularly affecting Astropy affiliated packages more than Astropy itself. [2] A handful of other bug fixes came along for the ride. You can read the full changelog here: https://github.com/astropy/astropy/blob/v1.0.x/CHANGES.rst#101-2015-03-06 Thanks to everyone involved for your continued effort to make Astropy as stable and reliable as can be! Erik B. From embray at stsci.edu Fri Mar 6 19:10:48 2015 From: embray at stsci.edu (Erik Bray) Date: Fri, 6 Mar 2015 19:10:48 -0500 Subject: [AstroPy] [ANN] Astropy v1.0.1 Released In-Reply-To: <54FA4157.7040608@stsci.edu> References: <54FA4157.7040608@stsci.edu> Message-ID: <54FA4208.5040901@stsci.edu> Sorry for the additional spam--the links referenced in the last e-mail are: [1] https://github.com/astropy/astropy/pull/3525 [2] https://github.com/astropy/astropy/issues/3541 On 03/06/2015 07:07 PM, Erik Bray wrote: > Hi all, > > We don't always advertise Astropy patch releases, but I wanted to make a note of > this one since it comes closely on the heels of Astropy v1.0. This release was > made as soon as it was primarily to address two issues: > > 1) One of the key new features of Astropy v1.0, the vastly sped up ASCII table > reading, was not fully functioning on Windows. [1] > > 2) There were a few installation issues, particularly affecting Astropy > affiliated packages more than Astropy itself. [2] > > A handful of other bug fixes came along for the ride. You can read the full > changelog here: > > https://github.com/astropy/astropy/blob/v1.0.x/CHANGES.rst#101-2015-03-06 > > Thanks to everyone involved for your continued effort to make Astropy as stable > and reliable as can be! > > Erik B. From akshat.singhal014 at gmail.com Wed Mar 11 04:47:14 2015 From: akshat.singhal014 at gmail.com (Akshat Singhal) Date: Wed, 11 Mar 2015 14:17:14 +0530 Subject: [AstroPy] RA-Dec to Alt-Az using Astropy 1.0 Message-ID: Hi all, For some of my calculation I want to convert RA-Dec coordinates of a star to Alt-Az coordinates (for given location and time), make some other computations and then convert Alt-Az back to RA-dec. First conversion is easy, I am not able to figure out how to convert Alt-Az to RA-Dec in Astropy 1.0 Any insight to this will be a lot helpful Thanks and regards Akshat Singhal -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Wed Mar 11 05:03:15 2015 From: deil.christoph at googlemail.com (Christoph Deil) Date: Wed, 11 Mar 2015 10:03:15 +0100 Subject: [AstroPy] RA-Dec to Alt-Az using Astropy 1.0 In-Reply-To: References: Message-ID: <18DED6DC-C65C-4A64-A228-255AF46BE457@gmail.com> > On 11 Mar 2015, at 09:47, Akshat Singhal wrote: > > Hi all, > > For some of my calculation I want to convert RA-Dec coordinates of a star to Alt-Az coordinates (for given location and time), > make some other computations and then convert Alt-Az back to RA-dec. > First conversion is easy, I am not able to figure out how to convert Alt-Az to RA-Dec in Astropy 1.0 > Any insight to this will be a lot helpful > > Thanks and regards > Akshat Singhal > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Hi Akshat, to transform an from Alt-Az to Ra-Dec, you should create a SkyCoord with an AltAz frame and then call it?s `transform_to(?icrs')` method or access it?s `.icrs` attribute. There?s an example here in the Astropy tests: https://github.com/astropy/astropy/blob/master/astropy/coordinates/tests/accuracy/test_altaz_icrs.py#L81 I think it would be nice to add an example involving AltAz to the docs here: http://astropy.readthedocs.org/en/latest/coordinates/transforming.html Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Thu Mar 12 18:40:58 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 12 Mar 2015 18:40:58 -0400 Subject: [AstroPy] RA-Dec to Alt-Az using Astropy 1.0 In-Reply-To: <18DED6DC-C65C-4A64-A228-255AF46BE457@gmail.com> References: <18DED6DC-C65C-4A64-A228-255AF46BE457@gmail.com> Message-ID: Another place with a complete example of the first step is: http://astropy.readthedocs.org/en/stable/coordinates/observing-example.html But it's true that this does not cover the inverse operation of AltAz -> ICRS . To do that, you create a SkyCoord in the AltAz frame, and provide the necessary information about the observer time and location. Then, just transform it to ICRS (which is usually what you mean when you say "Ra-Dec": >>> from astropy import units as u >>> from astropy.coordinates import EarthLocation, SkyCoord, ICRS >>> my_location = EarthLocation(lat=25*u.deg, lon=0*u.deg) #might be a bit hot outside during the day... >>> observation_time = 'J2014' #or for more control, use the astropy.time.Time class directly >>> altaz = SkyCoord(alt=45*u.deg, az=125*u.deg, frame='altaz', obstime= observation_time, location=my_location) >>> altaz >>> altaz.transform_to(ICRS) # could also do ``altaz.transform_to('icrs')`` or just ``altaz.icrs`` On Wed, Mar 11, 2015 at 5:03 AM, Christoph Deil < deil.christoph at googlemail.com> wrote: > > On 11 Mar 2015, at 09:47, Akshat Singhal > wrote: > > Hi all, > > For some of my calculation I want to convert RA-Dec coordinates of a star > to Alt-Az coordinates (for given location and time), > make some other computations and then convert Alt-Az back to RA-dec. > First conversion is easy, I am not able to figure out how to convert > Alt-Az to RA-Dec in Astropy 1.0 > > Any insight to this will be a lot helpful > > Thanks and regards > Akshat Singhal > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > Hi Akshat, > > to transform an from Alt-Az to Ra-Dec, you should create a SkyCoord with > an AltAz frame and then call it?s `transform_to(?icrs')` method or access > it?s `.icrs` attribute. > > There?s an example here in the Astropy tests: > > https://github.com/astropy/astropy/blob/master/astropy/coordinates/tests/accuracy/test_altaz_icrs.py#L81 > > I think it would be nice to add an example involving AltAz to the docs > here: > http://astropy.readthedocs.org/en/latest/coordinates/transforming.html > > Christoph > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- > Erik T > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akshat.singhal014 at gmail.com Fri Mar 13 05:08:18 2015 From: akshat.singhal014 at gmail.com (Akshat Singhal) Date: Fri, 13 Mar 2015 14:38:18 +0530 Subject: [AstroPy] Setting and Rising time in Astropy 1.0 Message-ID: Hi All, How can one calculate setting and rising time of star ( with given RA-Dec) from a location at given time? That is from a given location and time of an observer , how to compute when will an object (say Sun or star with known coordinates) will rise or set at horizon. Any insight to it will be very helpful. Thanks and regards, Akshat SInghal -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Fri Mar 13 05:38:44 2015 From: deil.christoph at googlemail.com (Christoph Deil) Date: Fri, 13 Mar 2015 10:38:44 +0100 Subject: [AstroPy] Setting and Rising time in Astropy 1.0 In-Reply-To: References: Message-ID: > On 13 Mar 2015, at 10:08, Akshat Singhal wrote: > > Hi All, > > How can one calculate setting and rising time of star ( with given RA-Dec) from > a location at given time? > That is from a given location and time of an observer , how to compute when > will an object (say Sun or star with known coordinates) will rise or set at horizon. > > Any insight to it will be very helpful. > > Thanks and regards, > Akshat SInghal > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Hi Akshat, PyEphem has methods to compute the previous and next transit, rising, setting time: http://rhodesmill.org/pyephem/quick.html#transit-rising-setting Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Fri Mar 13 13:34:01 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 13 Mar 2015 17:34:01 +0000 Subject: [AstroPy] Setting and Rising time in Astropy 1.0 In-Reply-To: References: Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7ADF0F@001FSN2MPN1-046.001f.mgd2.msft.net> It's not trivial. I implemented some of the Jean Meeus algorithms using Astropy here: https://github.com/firelab/met_utils/blob/master/sun.py Class "Uptime", method "approximate" calculates nominal rise/transit/set times given a body object that has a "get_apparent_position()" method. I really only implemented a Sun body, but it should be pretty easy to implement a dummy body that just lets you put in whatever position you want. Bryce From: astropy-bounces at scipy.org [mailto:astropy-bounces at scipy.org] On Behalf Of Christoph Deil Sent: Friday, March 13, 2015 3:39 AM To: Astronomical Python mailing list Subject: Re: [AstroPy] Setting and Rising time in Astropy 1.0 On 13 Mar 2015, at 10:08, Akshat Singhal > wrote: Hi All, How can one calculate setting and rising time of star ( with given RA-Dec) from a location at given time? That is from a given location and time of an observer , how to compute when will an object (say Sun or star with known coordinates) will rise or set at horizon. Any insight to it will be very helpful. Thanks and regards, Akshat SInghal _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy Hi Akshat, PyEphem has methods to compute the previous and next transit, rising, setting time: http://rhodesmill.org/pyephem/quick.html#transit-rising-setting Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.patel.1 at stonybrook.edu Tue Mar 17 21:36:19 2015 From: rahul.patel.1 at stonybrook.edu (Rahul Patel) Date: Tue, 17 Mar 2015 21:36:19 -0400 Subject: [AstroPy] Confusion about WCS origin Message-ID: Dear all, I am using the WCS package in astropy and ran into some confusion on what to set the origin. For instance, when transforming from pixel to wcs world = w.wcs_pix2world(pixcrd, 1) the doc says to use 0 for origin assuming C and numpy and 1 for fits and fortran. The above example uses "1" but everything loaded into python is a numpy array. Any clarification would be useful. Thank you. *Rahul I. Patel * ----------------------------------------------------------------- Rahul.Patel.1 at StonyBrook.edu Department of Physics and Astronomy State University of New York at Stony Brook WEB: http://www.astro.sunysb.edu/rpatel ----------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From shupe at ipac.caltech.edu Wed Mar 18 10:43:19 2015 From: shupe at ipac.caltech.edu (David Shupe) Date: Wed, 18 Mar 2015 07:43:19 -0700 Subject: [AstroPy] Confusion about WCS origin In-Reply-To: References: Message-ID: Dear Rahul, The origin parameter corresponds to the convention for numbering the pixels. The convention used in FORTRAN and FITS files is that the center of the first pixel has pixel coordinates [1.0, 1.0]. In the convention used by C and Numpy, the center of the first pixel is [0.0, 0.0]. Even though you are giving a Numpy array to the function, you must specify which pixel numbering convention you are using with the origin argument. If you view an image with ds9, you can see that it uses the FORTRAN/FITS convention for numbering pixels. Regards, David > On Mar 17, 2015, at 6:36 PM, Rahul Patel wrote: > > Dear all, > > I am using the WCS package in astropy and ran into some confusion on what to set the origin. For instance, when transforming from pixel to wcs > > world = w.wcs_pix2world(pixcrd, 1) > > the doc says to use 0 for origin assuming C and numpy and 1 for fits and fortran. The above example uses "1" but everything loaded into python is a numpy array. Any clarification would be useful. Thank you. > > > > > Rahul I. Patel > ----------------------------------------------------------------- > Rahul.Patel.1 at StonyBrook.edu > Department of Physics and Astronomy > State University of New York at Stony Brook > WEB: http://www.astro.sunysb.edu/rpatel > ----------------------------------------------------------------- > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.patel.1 at stonybrook.edu Wed Mar 18 11:47:05 2015 From: rahul.patel.1 at stonybrook.edu (Rahul Patel) Date: Wed, 18 Mar 2015 11:47:05 -0400 Subject: [AstroPy] Confusion about WCS origin In-Reply-To: References: Message-ID: Dear David, Thank you for the quick response. I understand that it refers to the origin convention depending on which type of data I'm using. However what I'm confused with is which one I should use. I'm loading a fits file, which is an origin of 1,1 . But the data loaded by astropy is in the form of a numpy array, hence to my understanding, an origin of 0,0. Perhaps I'm misunderstanding something fundamental. On Mar 18, 2015 10:43 AM, "David Shupe" wrote: > Dear Rahul, > > The origin parameter corresponds to the convention for numbering the > pixels. The convention used in FORTRAN and FITS files is that the center of > the first pixel has pixel coordinates [1.0, 1.0]. In the convention used by > C and Numpy, the center of the first pixel is [0.0, 0.0]. > > Even though you are giving a Numpy array to the function, you must specify > which pixel numbering convention you are using with the origin argument. > > If you view an image with ds9, you can see that it uses the FORTRAN/FITS > convention for numbering pixels. > > Regards, > David > > On Mar 17, 2015, at 6:36 PM, Rahul Patel > wrote: > > Dear all, > > I am using the WCS package in astropy and ran into some confusion on > what to set the origin. For instance, when transforming from pixel to wcs > > world = w.wcs_pix2world(pixcrd, 1) > > > the doc says to use 0 for origin assuming C and numpy and 1 for fits and > fortran. The above example uses "1" but everything loaded into python is a > numpy array. Any clarification would be useful. Thank you. > > > > > *Rahul I. Patel * > ----------------------------------------------------------------- > Rahul.Patel.1 at StonyBrook.edu > Department of Physics and Astronomy > State University of New York at Stony Brook > WEB: http://www.astro.sunysb.edu/rpatel > ----------------------------------------------------------------- > _______________________________________________ > 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 Deil.Christoph at gmail.com Wed Mar 18 11:59:12 2015 From: Deil.Christoph at gmail.com (Christoph Deil) Date: Wed, 18 Mar 2015 16:59:12 +0100 Subject: [AstroPy] Confusion about WCS origin In-Reply-To: References: Message-ID: > On 18 Mar 2015, at 16:47, Rahul Patel wrote: > > Dear David, > > Thank you for the quick response. I understand that it refers to the origin convention depending on which type of data I'm using. However what I'm confused with is which one I should use. > Hi Rahul, I?m pretty sure you should use origin=1. To confirm that this gives correct results, you can do this: 1) transform the pixel coordinate (0, 0) to world coordinates (with origin=1) using Astropy 2) open the image in ds9, zoom in on the lower-left pixel and read off the world coordinates of the pixel center The world coordinates you get with method 1) and 2) should match (up to the error with which you manage to put your mouse pointer over the pixel center in ds9). Hope that helps, Christoph > I'm loading a fits file, which is an origin of 1,1 . But the data loaded by astropy is in the form of a numpy array, hence to my understanding, an origin of 0,0. Perhaps I'm misunderstanding something fundamental. > > On Mar 18, 2015 10:43 AM, "David Shupe" > wrote: > Dear Rahul, > > The origin parameter corresponds to the convention for numbering the pixels. The convention used in FORTRAN and FITS files is that the center of the first pixel has pixel coordinates [1.0, 1.0]. In the convention used by C and Numpy, the center of the first pixel is [0.0, 0.0]. > > Even though you are giving a Numpy array to the function, you must specify which pixel numbering convention you are using with the origin argument. > > If you view an image with ds9, you can see that it uses the FORTRAN/FITS convention for numbering pixels. > > Regards, > David > >> On Mar 17, 2015, at 6:36 PM, Rahul Patel > wrote: >> >> Dear all, >> >> I am using the WCS package in astropy and ran into some confusion on what to set the origin. For instance, when transforming from pixel to wcs >> >> world = w.wcs_pix2world(pixcrd, 1) >> >> the doc says to use 0 for origin assuming C and numpy and 1 for fits and fortran. The above example uses "1" but everything loaded into python is a numpy array. Any clarification would be useful. Thank you. >> >> >> >> >> Rahul I. Patel >> ----------------------------------------------------------------- >> Rahul.Patel.1 at StonyBrook.edu >> Department of Physics and Astronomy >> State University of New York at Stony Brook >> WEB: http://www.astro.sunysb.edu/rpatel >> ----------------------------------------------------------------- >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shupe at ipac.caltech.edu Wed Mar 18 13:37:49 2015 From: shupe at ipac.caltech.edu (David Shupe) Date: Wed, 18 Mar 2015 10:37:49 -0700 Subject: [AstroPy] Confusion about WCS origin In-Reply-To: References: Message-ID: Hi Rahul, To elaborate a bit more on what Christoph wrote: > On Mar 18, 2015, at 8:59 AM, Christoph Deil wrote: > > To confirm that this gives correct results, you can do this: > 1) transform the pixel coordinate (0, 0) to world coordinates (with origin=1) using Astropy > 2) open the image in ds9, zoom in on the lower-left pixel and read off the world coordinates of the pixel center > > The world coordinates you get with method 1) and 2) should match (up to the error with which you manage to put your mouse pointer over the pixel center in ds9). You can use origin=1 to use the FITS convention for numbering pixels. You should be aware that to find the same pixel in your data array, you have to subtract 1 from the pixel values, and swap the order. For example: w.wcs_pix2world(np.array([[613.0, 118.0],]), 1) w.wcs_pix2world(np.array([[612.0, 117.0],]), 0) will return the same world coordinates. However, to get the value of this pixel in your data array, you must use data[117,612] 2-D Numpy arrays follow the convention used in C and Java, that the order is row and then column; and additionally, the indices are 0-based. When you look at an image in ds9, you?ll see 1-based indices in the opposite order. Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rborges at hush.com Thu Mar 19 09:21:11 2015 From: rborges at hush.com (rborges at hush.com) Date: Thu, 19 Mar 2015 14:21:11 +0100 Subject: [AstroPy] Getting errors while fitting polynomial model with tied parameters Message-ID: Hi! I am trying to adapt a working code, that fits a model 2nd degree polynomial, to use a model 2nd degree polynomial with "tied" parameters. The reason is: the data is supposed to have parabolic symmetry (it is the unwrapped phase map for a Fabry-Perot interferometer), and then I would like to find the best model that fits the data, and necessarily has the second degree coefficients equal to each other. I'm using Python 3 in Fedora 21 (therefore Astropy 0.3.2-2.fc20). The working code is this excerpt (full code can be found in the project's github repo at https://github.com/rcbrgs/tuna): from astropy.modeling import models from astropy.modeling.fitting import NonLinearLSQFitter as LevMarLSQFitter import numpy # ... Polynomial2D_model = models.Polynomial2D ( degree = 2 ) LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) This works properly, and coefficients always return with a ratio of 0.99 or better. But following documentation at http://astropy.readthedocs.org/en/latest/modeling/fitting.html, I have tried: def tied_c2_0 ( o_model ): o_c2_0 = o_model.c0_2 return o_c2_0 Polynomial2D_model = models.Polynomial2D ( degree = 2, tied = { 'c2_0' : tied_c2_0 } ) LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) However, this adaptation leads to the following error: Traceback (most recent call last): File "./eg_highres_pipeline.py", line 111, in unwrap_phase_map ( ) File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map f_scanning_wavelength = 6616.895 ) File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ ffa_unwrapped = self.unwrapped_phase_map ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D o_parabola.create_model_map_by_Polynomial2D ( ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 36, in create_model_map_by_Polynomial2D tied = { 'c2_0': tied_c2_0 } ) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 672, in __init__ param_dim=param_dim, **params) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 131, in __init__ self._validate_params(**params) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 183, in _validate_params assert(len(params) == numcoeff) AssertionError I have tried also using the other syntax suggested on the documentation: def tied_c2_0 ( o_model ): o_c2_0 = o_model.c0_2 return o_c2_0 Polynomial2D_model = models.Polynomial2D ( degree = 2 ) Polynomial2D_model.c2_0.tied = tied_c2_0 LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) But this yields this other error: Traceback (most recent call last): File "./eg_highres_pipeline.py", line 111, in unwrap_phase_map ( ) File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map f_scanning_wavelength = 6616.895 ) File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ ffa_unwrapped = self.unwrapped_phase_map ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D o_parabola.create_model_map_by_Polynomial2D ( ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 46, in create_model_map_by_Polynomial2D z = self.__ffa_unwrapped ) File "/usr/lib64/python3.3/site-packages/astropy/modeling/fitting.py", line 465, in __call__ full_output=True) File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 369, in leastsq _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (m,n)) File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 30, in _check_func raise TypeError(msg) TypeError: leastsq: there is a mismatch between the input and output shape of the 'Dfun' argument '_wrap_deriv'. I hope this is enough information to spot any known bugs, and I thank you in advance for your time. Cordially, Renato. From dencheva at stsci.edu Thu Mar 19 09:51:05 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 19 Mar 2015 13:51:05 +0000 Subject: [AstroPy] Getting errors while fitting polynomial model with tied parameters In-Reply-To: References: Message-ID: <0153364C9F56D944B0A795780ECF88DF67772C91@EXCHMAIL2.stsci.edu> Hi Renato, I can reproduce the problem with the current master. Do you mind filing an issue on the astropy github. Thanks, Nadia ________________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of rborges at hush.com [rborges at hush.com] Sent: Thursday, March 19, 2015 9:21 AM To: astropy at scipy.org Subject: [AstroPy] Getting errors while fitting polynomial model with tied parameters Hi! I am trying to adapt a working code, that fits a model 2nd degree polynomial, to use a model 2nd degree polynomial with "tied" parameters. The reason is: the data is supposed to have parabolic symmetry (it is the unwrapped phase map for a Fabry-Perot interferometer), and then I would like to find the best model that fits the data, and necessarily has the second degree coefficients equal to each other. I'm using Python 3 in Fedora 21 (therefore Astropy 0.3.2-2.fc20). The working code is this excerpt (full code can be found in the project's github repo at https://github.com/rcbrgs/tuna): from astropy.modeling import models from astropy.modeling.fitting import NonLinearLSQFitter as LevMarLSQFitter import numpy # ... Polynomial2D_model = models.Polynomial2D ( degree = 2 ) LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) This works properly, and coefficients always return with a ratio of 0.99 or better. But following documentation at http://astropy.readthedocs.org/en/latest/modeling/fitting.html, I have tried: def tied_c2_0 ( o_model ): o_c2_0 = o_model.c0_2 return o_c2_0 Polynomial2D_model = models.Polynomial2D ( degree = 2, tied = { 'c2_0' : tied_c2_0 } ) LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) However, this adaptation leads to the following error: Traceback (most recent call last): File "./eg_highres_pipeline.py", line 111, in unwrap_phase_map ( ) File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map f_scanning_wavelength = 6616.895 ) File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ ffa_unwrapped = self.unwrapped_phase_map ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D o_parabola.create_model_map_by_Polynomial2D ( ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 36, in create_model_map_by_Polynomial2D tied = { 'c2_0': tied_c2_0 } ) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 672, in __init__ param_dim=param_dim, **params) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 131, in __init__ self._validate_params(**params) File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 183, in _validate_params assert(len(params) == numcoeff) AssertionError I have tried also using the other syntax suggested on the documentation: def tied_c2_0 ( o_model ): o_c2_0 = o_model.c0_2 return o_c2_0 Polynomial2D_model = models.Polynomial2D ( degree = 2 ) Polynomial2D_model.c2_0.tied = tied_c2_0 LevMarLSQFitter_fit = LevMarLSQFitter ( ) polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) But this yields this other error: Traceback (most recent call last): File "./eg_highres_pipeline.py", line 111, in unwrap_phase_map ( ) File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map f_scanning_wavelength = 6616.895 ) File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ ffa_unwrapped = self.unwrapped_phase_map ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D o_parabola.create_model_map_by_Polynomial2D ( ) File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 46, in create_model_map_by_Polynomial2D z = self.__ffa_unwrapped ) File "/usr/lib64/python3.3/site-packages/astropy/modeling/fitting.py", line 465, in __call__ full_output=True) File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 369, in leastsq _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (m,n)) File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 30, in _check_func raise TypeError(msg) TypeError: leastsq: there is a mismatch between the input and output shape of the 'Dfun' argument '_wrap_deriv'. I hope this is enough information to spot any known bugs, and I thank you in advance for your time. Cordially, Renato. _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy From rborges at hush.com Thu Mar 19 11:47:00 2015 From: rborges at hush.com (rborges at hush.com) Date: Thu, 19 Mar 2015 16:47:00 +0100 Subject: [AstroPy] Getting errors while fitting polynomial model with tied parameters In-Reply-To: <0153364C9F56D944B0A795780ECF88DF67772C91@EXCHMAIL2.stsci.edu> References: <0153364C9F56D944B0A795780ECF88DF67772C91@EXCHMAIL2.stsci.edu> Message-ID: <30c8491e1af408de2cd0ff35f50971f9@smtp.hushmail.com> Hi Nadia! Thanks for confirming this is a reproducible bug; I have created a new issue on github, since the open ones do not seem relevant. Cordially, Renato. On Thu, Mar 19, 2015 at 01:51:05PM +0000, Nadezhda Dencheva wrote: > Hi Renato, > > I can reproduce the problem with the current master. > Do you mind filing an issue on the astropy github. > > Thanks, > Nadia > ________________________________________ > From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of rborges at hush.com [rborges at hush.com] > Sent: Thursday, March 19, 2015 9:21 AM > To: astropy at scipy.org > Subject: [AstroPy] Getting errors while fitting polynomial model with tied parameters > > Hi! > > > I am trying to adapt a working code, that fits a model 2nd degree polynomial, to use a model 2nd degree polynomial with "tied" parameters. > > The reason is: the data is supposed to have parabolic symmetry (it is the unwrapped phase map for a Fabry-Perot interferometer), and then I would like to find the best model that fits the data, and necessarily has the second degree coefficients equal to each other. > > I'm using Python 3 in Fedora 21 (therefore Astropy 0.3.2-2.fc20). > > The working code is this excerpt (full code can be found in the project's github repo at https://github.com/rcbrgs/tuna): > > from astropy.modeling import models > from astropy.modeling.fitting import NonLinearLSQFitter as LevMarLSQFitter > import numpy > # ... > Polynomial2D_model = models.Polynomial2D ( degree = 2 ) > LevMarLSQFitter_fit = LevMarLSQFitter ( ) > polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) > > This works properly, and coefficients always return with a ratio of 0.99 or better. But following documentation at http://astropy.readthedocs.org/en/latest/modeling/fitting.html, I have tried: > > def tied_c2_0 ( o_model ): > o_c2_0 = o_model.c0_2 > return o_c2_0 > > Polynomial2D_model = models.Polynomial2D ( degree = 2, tied = { 'c2_0' : tied_c2_0 } ) > LevMarLSQFitter_fit = LevMarLSQFitter ( ) > polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) > > However, this adaptation leads to the following error: > > Traceback (most recent call last): > File "./eg_highres_pipeline.py", line 111, in > unwrap_phase_map ( ) > File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map > f_scanning_wavelength = 6616.895 ) > File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ > ffa_unwrapped = self.unwrapped_phase_map ) > File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D > o_parabola.create_model_map_by_Polynomial2D ( ) > File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 36, in create_model_map_by_Polynomial2D > tied = { 'c2_0': tied_c2_0 } ) > File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 672, in __init__ > param_dim=param_dim, **params) > File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 131, in __init__ > self._validate_params(**params) > File "/usr/lib64/python3.3/site-packages/astropy/modeling/polynomial.py", line 183, in _validate_params > assert(len(params) == numcoeff) > AssertionError > > > I have tried also using the other syntax suggested on the documentation: > > def tied_c2_0 ( o_model ): > o_c2_0 = o_model.c0_2 > return o_c2_0 > > Polynomial2D_model = models.Polynomial2D ( degree = 2 ) > Polynomial2D_model.c2_0.tied = tied_c2_0 > LevMarLSQFitter_fit = LevMarLSQFitter ( ) > polynomial_fit = LevMarLSQFitter_fit ( model = Polynomial2D_model, x = iia_x_dimension, y = iia_y_dimension, z = self.__ffa_unwrapped ) > > But this yields this other error: > > Traceback (most recent call last): > File "./eg_highres_pipeline.py", line 111, in > unwrap_phase_map ( ) > File "./eg_highres_pipeline.py", line 40, in unwrap_phase_map > f_scanning_wavelength = 6616.895 ) > File "/home/nix/cloud_essential2/tuna/github/tools/phase_map/high_resolution.py", line 112, in __init__ > ffa_unwrapped = self.unwrapped_phase_map ) > File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 80, in fit_parabolic_model_by_Polynomial2D > o_parabola.create_model_map_by_Polynomial2D ( ) > File "/home/nix/cloud_essential2/tuna/github/tools/models/parabola.py", line 46, in create_model_map_by_Polynomial2D > z = self.__ffa_unwrapped ) > File "/usr/lib64/python3.3/site-packages/astropy/modeling/fitting.py", line 465, in __call__ > full_output=True) > File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 369, in leastsq > _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (m,n)) > File "/usr/lib64/python3.3/site-packages/scipy/optimize/minpack.py", line 30, in _check_func > raise TypeError(msg) > TypeError: leastsq: there is a mismatch between the input and output shape of the 'Dfun' argument '_wrap_deriv'. > > > I hope this is enough information to spot any known bugs, and I thank you in advance for your time. > > > Cordially, > Renato. > > _______________________________________________ > 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 aldcroft at head.cfa.harvard.edu Thu Mar 19 14:48:36 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Thu, 19 Mar 2015 14:48:36 -0400 Subject: [AstroPy] Python4Astronomers - refreshed and Python-3 compatible Message-ID: The Python4Astronomers site (http://python4astronomers.github.io/) has gotten a long-overdue refresh: - Python 3 compatible where possible - Remove deprecated packages like PyFITS and use astropy more consistently and idiomatically. - Update installation instructions and add Ureka as a recommended option. - Change from ipython --pylab to ipython --matplotlib everywhere. - Move VO tutorial out of the main lineup since it depends heavily on orphaned packages. - Remove section on ATPy (the inspiration and predecessor for astropy Table). Finally, but certainly not least, the site now uses a modern styling that should look very familiar! Cheers, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Tue Mar 24 14:25:33 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 24 Mar 2015 14:25:33 -0400 Subject: [AstroPy] Setting and Rising time in Astropy 1.0 In-Reply-To: References: Message-ID: While it's not a "one-liner" to do this with Astropy, you can do this in a straightforward way using the new functionality surrounding AltAz that is in Astropy v1.0. To see an example of how this works, take a look at http://docs.astropy.org/en/latest/coordinates/observing-example.html that example does many other things, but the key piece for this question is the second-to-last code sample on that page. You'll note it ends with a line that sets "m33altazs", which is an array SkyCoord that contains the AltAz coordinates for M33. To find a pretty good set (or rise) time, you can just do something like this: np.interp(0, m33altazs.alt.deg, delta_midnight) to get the rise time. This might not give quite the same answer is the Meeus approach because it at least in principal might include things like light deflection, but also has interpolation error as I've phrased it here. That's probably not too critical for most cases, though, because *realistic* rise/set times depend in detail on atmospheric conditions and the associated refraction. It would certainly make sense to write a function that will do exactly this (and transit time too) using the Astropy coordinates API... we welcome pull requests or issues to this effect! (I think this might be part of one of the possible Google Summer of Code projects, but none of that is finalized yet.) I'm planning to show a more targeted example of just this in an astropy tutorial I'm working on that showcases some of the new coordinates features. On Fri, Mar 13, 2015 at 5:08 AM, Akshat Singhal wrote: > Hi All, > > How can one calculate setting and rising time of star ( with given RA-Dec) > from > a location at given time? > That is from a given location and time of an observer , how to compute when > will an object (say Sun or star with known coordinates) will rise or set > at horizon. > > Any insight to it will be very helpful. > > Thanks and regards, > Akshat SInghal > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From astropy at liska.ath.cx Wed Mar 25 11:16:33 2015 From: astropy at liska.ath.cx (Ole Streicher) Date: Wed, 25 Mar 2015 16:16:33 +0100 Subject: [AstroPy] [ANN] Debian-Astro Sprint at DebCamp 2015 in Heidelberg Message-ID: <5512D151.9050801@liska.ath.cx> Hi all, The Debian Astronomy Working Group aims to package and maintain astronomy related software for the Debian/GNU operating system. We are planning a (one-day) debian-astro sprint at the DebCamp in Heidelberg, 14 August 2015. Debian "sprints" are developer meetings to work on specific parts and having fun doing so. The main goal is to get together, to find out common topics and issues, to discuss our future path, and to work on current problems. A quick preliminary agenda is posted on https://wiki.debian.org/Sprints/2015/Astro * Status of Packaging what is there, what else do we need? * Creation of a tasks package * Package collections: - VO tools - Astropy affiliated packages - Software provided by Astromatic.net - ESO Scisoft * Licensing issues * How to attract new packagers? Packaging by upstream? * Which coordination with other Distributions do we need? (Fedora etc.) * Workshop for newcomers: create a first package together Everyone interested is welcome to the Sprint event, and also to provide ideas or comments to the agenda. If you intent to come, please add your name to the wiki for coordination. Please feel free to forward this to anyone who might be interested. Discussion should take place in the Debian Astronomy Mailing list https://lists.debian.org/debian-astro/ Best regards Ole Streicher -- Ole Streicher Tel: +49 331 7499-666, Fax: -429 http://www.aip.de Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, 14482 Potsdam, Germany Vorstand: Prof. Dr. Matthias Steinmetz Stiftung b?rgerlichen Rechts Stiftungsverzeichnis Brandenburg: 26 742-00/7026 From duncan.macleod at ligo.org Thu Mar 26 14:00:38 2015 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Thu, 26 Mar 2015 13:00:38 -0500 Subject: [AstroPy] Quantity does not own its own data with copy=True Message-ID: Hi all, I?m wondering why a new astropy.units.Quantity doesn?t own its own data, even when I specify copy=True when creating it: >>> from astropy.units import Quantity >>> a = Quantity([1, 2, 3], copy=True) >>> print(a.flags.owndata) False I know technically how that is true, since there is a view() call in the __new__ constructor, but not why is was implemented in this way. There are lines in other parts of quantity.py that reference this fact, which makes it seem like this was a conscious decision, rather than an accident. Can someone explain the thinking behind this decision? I realise I can use Quantity([1, 2, 3]).copy() to create a clean copy that does own the data, but that seems a little inelegant. 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 gr.maravelias at gmail.com Thu Mar 26 19:47:02 2015 From: gr.maravelias at gmail.com (Grigoris Maravelias) Date: Fri, 27 Mar 2015 00:47:02 +0100 Subject: [AstroPy] getting id value from xml files Message-ID: <55149A76.5050504@gmail.com> Hi to all! I have a quick question with probably a rather straightforward answer which probably may have slipped me. What is the fastest way to call the value of a field id in an xml file (produced by astropy). For example to get the value from the ID 'sfr' Best Grigoris From jjk at uvic.ca Thu Mar 26 23:19:02 2015 From: jjk at uvic.ca (JJ Kavelaars) Date: Thu, 26 Mar 2015 20:19:02 -0700 Subject: [AstroPy] disable fatal errors on illegal keywords in FITS Header created by Header.fromstring Message-ID: <029B7C03-E391-4E6E-9886-452370E4C7EA@uvic.ca> I am creating headers with the class method Header.fromfile. These older files contain the keyword 'IRAF-B/P?. This keyword violates the FITS standard, these files pre-date the standard. In astropy the existence of the IRAF-B/P keyword causes a fatal error when attempting to print the header. Is there a flag that will set an ?ignore? flag when creating the header via the Header.fromfile method such that errors are ignored rather than fatal? thanks, JJ From simon at sconseil.fr Fri Mar 27 05:06:48 2015 From: simon at sconseil.fr (Simon Conseil) Date: Fri, 27 Mar 2015 10:06:48 +0100 Subject: [AstroPy] disable fatal errors on illegal keywords in FITS Header created by Header.fromstring In-Reply-To: <029B7C03-E391-4E6E-9886-452370E4C7EA@uvic.ca> References: <029B7C03-E391-4E6E-9886-452370E4C7EA@uvic.ca> Message-ID: <55151DA8.1050903@sconseil.fr> Hello, I had the same error with this 'IRAF-B/P? keyword, there is a related issue here: https://github.com/astropy/astropy/issues/887 Simon Le 27/03/2015 04:19, JJ Kavelaars a ?crit : > I am creating headers with the class method Header.fromfile. These older files contain the keyword 'IRAF-B/P?. This keyword violates the FITS standard, these files pre-date the standard. > > In astropy the existence of the IRAF-B/P keyword causes a fatal error when attempting to print the header. > > Is there a flag that will set an ?ignore? flag when creating the header via the Header.fromfile method such that errors are ignored rather than fatal? > > thanks, > JJ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Simon Conseil CRAL - Observatoire de Lyon 9, avenue Charles Andr? 69230 Saint-Genis-Laval From mdroe at stsci.edu Fri Mar 27 09:43:12 2015 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 27 Mar 2015 09:43:12 -0400 Subject: [AstroPy] getting id value from xml files In-Reply-To: <55149A76.5050504@gmail.com> References: <55149A76.5050504@gmail.com> Message-ID: <55155E70.8070904@stsci.edu> I assume you are asking how to do this with astropy.io.votable? INFO tags can appear in a number of places in a VOTable file, so without seeing the whole file, it?s hard to say. For example, if you had a file like: | | The you could do: |from astropy.io import votable vot = votable.parse("file.xml") value = vot.resources[0].infos[0].value | |astropy.io.votable| doesn?t currently have a ?get info by ID? method, but those exist for some other things, so should probably be added. (I?ll make a PR and update you on that). You could probably also do this with |astropy.io.votable| using Python?s built-in elementtree and XPath to match on the ID. Mike On 03/26/2015 07:47 PM, Grigoris Maravelias wrote: > Hi to all! > > I have a quick question with probably a rather straightforward answer > which probably may have slipped me. > What is the fastest way to call the value of a field id in an xml file > (produced by astropy). > > For example to get the value from the ID 'sfr' > > > Best > Grigoris > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Fri Mar 27 10:25:37 2015 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 27 Mar 2015 10:25:37 -0400 Subject: [AstroPy] getting id value from xml files In-Reply-To: <55155E70.8070904@stsci.edu> References: <55149A76.5050504@gmail.com> <55155E70.8070904@stsci.edu> Message-ID: <55156861.5090202@stsci.edu> See http://github.com/astropy/astropy/pull/3633 for an implementation of get_info_by_id. Mike On 03/27/2015 09:43 AM, Michael Droettboom wrote: > > I assume you are asking how to do this with astropy.io.votable? > > INFO tags can appear in a number of places in a VOTable file, so > without seeing the whole file, it?s hard to say. > > For example, if you had a file like: > > | > > > > > | > > The you could do: > > |from astropy.io import votable > vot = votable.parse("file.xml") > value = vot.resources[0].infos[0].value > | > > |astropy.io.votable| doesn?t currently have a ?get info by ID? method, > but those exist for some other things, so should probably be added. > (I?ll make a PR and update you on that). > > You could probably also do this with |astropy.io.votable| using > Python?s built-in elementtree and XPath to match on the ID. > > Mike > > On 03/26/2015 07:47 PM, Grigoris Maravelias wrote: > >> Hi to all! >> >> I have a quick question with probably a rather straightforward answer >> which probably may have slipped me. >> What is the fastest way to call the value of a field id in an xml file >> (produced by astropy). >> >> For example to get the value from the ID 'sfr' >> >> >> Best >> Grigoris >> >> >> _______________________________________________ >> 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 jsjeetendra at gmail.com Sat Mar 28 02:26:39 2015 From: jsjeetendra at gmail.com (Jeetendra Joshi) Date: Sat, 28 Mar 2015 11:56:39 +0530 Subject: [AstroPy] AstroPy Digest, Vol 102, Issue 12 In-Reply-To: References: Message-ID: 00000 74444 On Mar 27, 2015 7:56 PM, wrote: > Send AstroPy mailing list submissions to > astropy at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/astropy > or, via email, send a message with subject or body 'help' to > astropy-request at scipy.org > > You can reach the person managing the list at > astropy-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of AstroPy digest..." > > > Today's Topics: > > 1. Quantity does not own its own data with copy=True (Duncan Macleod) > 2. getting id value from xml files (Grigoris Maravelias) > 3. disable fatal errors on illegal keywords in FITS Header > created by Header.fromstring (JJ Kavelaars) > 4. Re: disable fatal errors on illegal keywords in FITS Header > created by Header.fromstring (Simon Conseil) > 5. Re: getting id value from xml files (Michael Droettboom) > 6. Re: getting id value from xml files (Michael Droettboom) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Mar 2015 13:00:38 -0500 > From: Duncan Macleod > Subject: [AstroPy] Quantity does not own its own data with copy=True > To: astropy > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I?m wondering why a new astropy.units.Quantity doesn?t own its own data, > even when I specify copy=True when creating it: > > >>> from astropy.units import Quantity > >>> a = Quantity([1, 2, 3], copy=True) > >>> print(a.flags.owndata) > False > > I know technically how that is true, since there is a view() call in the > __new__ constructor, but not why is was implemented in this way. There are > lines in other parts of quantity.py that reference this fact, which makes > it seem like this was a conscious decision, rather than an accident. > > Can someone explain the thinking behind this decision? > > I realise I can use Quantity([1, 2, 3]).copy() to create a clean copy that > does own the data, but that seems a little inelegant. > > > 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: > http://mail.scipy.org/pipermail/astropy/attachments/20150326/b3650171/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 27 Mar 2015 00:47:02 +0100 > From: Grigoris Maravelias > Subject: [AstroPy] getting id value from xml files > To: Astronomical Python mailing list > Message-ID: <55149A76.5050504 at gmail.com> > Content-Type: text/plain; charset=utf-8 > > Hi to all! > > I have a quick question with probably a rather straightforward answer > which probably may have slipped me. > What is the fastest way to call the value of a field id in an xml file > (produced by astropy). > > For example to get the value from the ID 'sfr' > > > Best > Grigoris > > > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Mar 2015 20:19:02 -0700 > From: JJ Kavelaars > Subject: [AstroPy] disable fatal errors on illegal keywords in FITS > Header created by Header.fromstring > To: Astronomical Python mailing list > Message-ID: <029B7C03-E391-4E6E-9886-452370E4C7EA at uvic.ca> > Content-Type: text/plain; charset=utf-8 > > I am creating headers with the class method Header.fromfile. These older > files contain the keyword 'IRAF-B/P?. This keyword violates the FITS > standard, these files pre-date the standard. > > In astropy the existence of the IRAF-B/P keyword causes a fatal error when > attempting to print the header. > > Is there a flag that will set an ?ignore? flag when creating the header > via the Header.fromfile method such that errors are ignored rather than > fatal? > > thanks, > JJ > > > > ------------------------------ > > Message: 4 > Date: Fri, 27 Mar 2015 10:06:48 +0100 > From: Simon Conseil > Subject: Re: [AstroPy] disable fatal errors on illegal keywords in > FITS Header created by Header.fromstring > To: Astronomical Python mailing list > Message-ID: <55151DA8.1050903 at sconseil.fr> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hello, > > I had the same error with this 'IRAF-B/P? keyword, there is a related > issue here: https://github.com/astropy/astropy/issues/887 > > Simon > > > Le 27/03/2015 04:19, JJ Kavelaars a ?crit : > > I am creating headers with the class method Header.fromfile. These > older files contain the keyword 'IRAF-B/P?. This keyword violates the > FITS standard, these files pre-date the standard. > > > > In astropy the existence of the IRAF-B/P keyword causes a fatal error > when attempting to print the header. > > > > Is there a flag that will set an ?ignore? flag when creating the header > via the Header.fromfile method such that errors are ignored rather than > fatal? > > > > thanks, > > JJ > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > -- > Simon Conseil > CRAL - Observatoire de Lyon > 9, avenue Charles Andr? > 69230 Saint-Genis-Laval > > > ------------------------------ > > Message: 5 > Date: Fri, 27 Mar 2015 09:43:12 -0400 > From: Michael Droettboom > Subject: Re: [AstroPy] getting id value from xml files > To: > Message-ID: <55155E70.8070904 at stsci.edu> > Content-Type: text/plain; charset="utf-8" > > I assume you are asking how to do this with astropy.io.votable? > > INFO tags can appear in a number of places in a VOTable file, so without > seeing the whole file, it?s hard to say. > > For example, if you had a file like: > > | > > > > > | > > The you could do: > > |from astropy.io import votable > vot = votable.parse("file.xml") > value = vot.resources[0].infos[0].value > | > > |astropy.io.votable| doesn?t currently have a ?get info by ID? method, > but those exist for some other things, so should probably be added. > (I?ll make a PR and update you on that). > > You could probably also do this with |astropy.io.votable| using Python?s > built-in elementtree and XPath to match on the ID. > > Mike > > On 03/26/2015 07:47 PM, Grigoris Maravelias wrote: > > > Hi to all! > > > > I have a quick question with probably a rather straightforward answer > > which probably may have slipped me. > > What is the fastest way to call the value of a field id in an xml file > > (produced by astropy). > > > > For example to get the value from the ID 'sfr' > > > > > > Best > > Grigoris > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > ? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.scipy.org/pipermail/astropy/attachments/20150327/f6ea0b7e/attachment-0001.html > > ------------------------------ > > Message: 6 > Date: Fri, 27 Mar 2015 10:25:37 -0400 > From: Michael Droettboom > Subject: Re: [AstroPy] getting id value from xml files > To: > Message-ID: <55156861.5090202 at stsci.edu> > Content-Type: text/plain; charset="utf-8" > > See http://github.com/astropy/astropy/pull/3633 for an implementation of > get_info_by_id. > > Mike > > On 03/27/2015 09:43 AM, Michael Droettboom wrote: > > > > I assume you are asking how to do this with astropy.io.votable? > > > > INFO tags can appear in a number of places in a VOTable file, so > > without seeing the whole file, it?s hard to say. > > > > For example, if you had a file like: > > > > | > > > > > > > > > > | > > > > The you could do: > > > > |from astropy.io import votable > > vot = votable.parse("file.xml") > > value = vot.resources[0].infos[0].value > > | > > > > |astropy.io.votable| doesn?t currently have a ?get info by ID? method, > > but those exist for some other things, so should probably be added. > > (I?ll make a PR and update you on that). > > > > You could probably also do this with |astropy.io.votable| using > > Python?s built-in elementtree and XPath to match on the ID. > > > > Mike > > > > On 03/26/2015 07:47 PM, Grigoris Maravelias wrote: > > > >> Hi to all! > >> > >> I have a quick question with probably a rather straightforward answer > >> which probably may have slipped me. > >> What is the fastest way to call the value of a field id in an xml file > >> (produced by astropy). > >> > >> For example to get the value from the ID 'sfr' > >> > >> > >> Best > >> Grigoris > >> > >> > >> _______________________________________________ > >> 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: > http://mail.scipy.org/pipermail/astropy/attachments/20150327/1ed50e93/attachment.html > > ------------------------------ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > End of AstroPy Digest, Vol 102, Issue 12 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gr.maravelias at gmail.com Sun Mar 29 17:21:36 2015 From: gr.maravelias at gmail.com (Grigoris Maravelias) Date: Sun, 29 Mar 2015 23:21:36 +0200 Subject: [AstroPy] getting id value from xml files In-Reply-To: <55155E70.8070904@stsci.edu> References: <55149A76.5050504@gmail.com> <55155E70.8070904@stsci.edu> Message-ID: <55186CE0.6070106@gmail.com> Hi Mike! I just found time to check it... On 03/27/2015 02:43 PM, Michael Droettboom wrote: > The you could do: > |from astropy.io import votable > vot = votable.parse("file.xml") > value = vot.resources[0].infos[0].value| |I tried that but returns an error: | |ERROR: IndexError: list index out of range [__main__] Traceback (most recent call last): File "./xml_extractor.py", line 21, in value = vot.resources[0].infos[0].value IndexError: list index out of range| > > I assume you are asking how to do this with astropy.io.votable? > > INFO tags can appear in a number of places in a VOTable file, so > without seeing the whole file, it?s hard to say. > > For example, if you had a file like: > > | > > > > > | You are almost correct. I provide an original xml file (see [1]) where you can see that I have two resource ids with assigned data on them (as far as I can understand). The following code: from astropy.table import Table from astropy.io.votable import parse xmlfile = parse('bla.xml') flm = Table.read(xmlfile,table_id='Flambda') fnu = Table.read(xmlfile,table_id='Fnu') flm_old = flm['ssp_old'] flm_young = flm['ssp_young'] flm_add = flm_old+flm_young can successfully read the the tables flm/fln as dictionaries (with corresponding data arrays). But as you see there is a number of info ids outside the resource elements, which are the ones that I would like to access (more easily than just read the file). I do not know if this helps. Best Grigoris -------------- next part -------------- An HTML attachment was scrubbed... URL: From pweilbacher at aip.de Tue Mar 31 08:00:13 2015 From: pweilbacher at aip.de (Peter Weilbacher) Date: Tue, 31 Mar 2015 14:00:13 +0200 (CEST) Subject: [AstroPy] DS9 color tables in Python Message-ID: Dear all, has anyone succeeded to set up DS9-like color tables for plotting in Python? I'm specifically interested in "heat", "sls", "hsv", and "b". I know that matplotlib defines somewhat similar tables, but e.g. "gist_heat" is just too different from DS9's (and skycat's) heat... Cheers, Peter. -- Peter Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From thomas.robitaille at gmail.com Tue Mar 31 08:25:39 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 31 Mar 2015 14:25:39 +0200 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: Message-ID: On 31 March 2015 at 14:00, Peter Weilbacher wrote: > > Dear all, > > has anyone succeeded to set up DS9-like color tables for plotting in > Python? I'm specifically interested in "heat", "sls", "hsv", and "b". > > I know that matplotlib defines somewhat similar tables, but e.g. > "gist_heat" is just too different from DS9's (and skycat's) heat... If this doesn't exist, this might be a good addition to astropy.visualization or pyds9! Tom > > > Cheers, > Peter. > -- > Peter Weilbacher http://www.aip.de/People/PWeilbacher > Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 > ------------------------------------------------------------------------ > Leibniz-Institut f?r Astrophysik Potsdam (AIP) > An der Sternwarte 16, D-14482 Potsdam > > Vorstand: Prof. Dr. Matthias Steinmetz > Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From teuben at astro.umd.edu Tue Mar 31 09:01:00 2015 From: teuben at astro.umd.edu (Peter Teuben) Date: Tue, 31 Mar 2015 09:01:00 -0400 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: Message-ID: <551A9A8C.80803@astro.umd.edu> On 03/31/2015 08:25 AM, Thomas Robitaille wrote: > On 31 March 2015 at 14:00, Peter Weilbacher wrote: >> Dear all, >> >> has anyone succeeded to set up DS9-like color tables for plotting in >> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >> >> I know that matplotlib defines somewhat similar tables, but e.g. >> "gist_heat" is just too different from DS9's (and skycat's) heat... > If this doesn't exist, this might be a good addition to > astropy.visualization or pyds9! > > Tom Since I had done something similar in a long ago past, I had a quick peek at the source distro of ds9. I was surprised to see this part documented very lightly (if at all), but the "obvious" code to look at is in saods9/saotk/colorbar/default.C where a series of red.append(new LIColor(0,0)); red.append(new LIColor(1,1)); green.append(new LIColor(0,0)); green.append(new LIColor(1,1)); blue.append(new LIColor(0,0)); blue.append(new LIColor(1,1)); create a colortable. The SLS color scheme, which happens to be my favorite, does this in RGB space: colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); ... colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); others are done programmatically (check out HSV ) I NEMO and GIPSY these live as ascii tables with 256 entries of RGB scaled 0..1, and I checked a few and the ds9 ones seem to match the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) The ds9 codebase also has some yacc & lex parsing, i'm not clear if that's still used. Clearly the distribution doesn't contain these LUT ascii type files. If we're interested in persuing this, we should check with Bill Joye about the best approach to scrape it the right way. My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, but I cannot find this in the current ds9 (7.3.x) http://carma.astro.umd.edu/nemo/man_html/lut.5.html peter From jzuhone at gmail.com Tue Mar 31 09:36:04 2015 From: jzuhone at gmail.com (John Zuhone) Date: Tue, 31 Mar 2015 09:36:04 -0400 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: <551A9A8C.80803@astro.umd.edu> References: <551A9A8C.80803@astro.umd.edu> Message-ID: It's definitely do-able, I did it for a couple of ds9 colormaps by hand for yt, actually. I can try seeing if I can script it up. On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben wrote: > On 03/31/2015 08:25 AM, Thomas Robitaille wrote: > > On 31 March 2015 at 14:00, Peter Weilbacher wrote: > >> Dear all, > >> > >> has anyone succeeded to set up DS9-like color tables for plotting in > >> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". > >> > >> I know that matplotlib defines somewhat similar tables, but e.g. > >> "gist_heat" is just too different from DS9's (and skycat's) heat... > > If this doesn't exist, this might be a good addition to > > astropy.visualization or pyds9! > > > > Tom > > > Since I had done something similar in a long ago past, I had a quick peek > at the source distro of ds9. I was surprised to see this part documented > very lightly (if at all), but the "obvious" code to look at is in > saods9/saotk/colorbar/default.C > where a series of > > red.append(new LIColor(0,0)); > red.append(new LIColor(1,1)); > > green.append(new LIColor(0,0)); > green.append(new LIColor(1,1)); > > blue.append(new LIColor(0,0)); > blue.append(new LIColor(1,1)); > > create a colortable. The SLS color scheme, which happens to > be my favorite, does this in RGB space: > > colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); > colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); > colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); > colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); > ... > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > > others are done programmatically (check out HSV ) > > I NEMO and GIPSY these live as ascii tables with 256 entries of RGB > scaled 0..1, and I checked a few and the ds9 ones seem to match > the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) > > The ds9 codebase also has some yacc & lex parsing, i'm not clear > if that's still used. Clearly the distribution doesn't contain these > LUT ascii type files. If we're interested in persuing this, we should > check with Bill Joye about the best approach to scrape it the right > way. > > My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, > but I cannot find this in the current ds9 (7.3.x) > http://carma.astro.umd.edu/nemo/man_html/lut.5.html > > peter > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzuhone at gmail.com Tue Mar 31 10:17:01 2015 From: jzuhone at gmail.com (John Zuhone) Date: Tue, 31 Mar 2015 10:17:01 -0400 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: <551A9A8C.80803@astro.umd.edu> Message-ID: So I'm able to do it in yt, which is probably just a short step from doing it in AstroPy, since it's just NumPy and Matplotlib calls: http://nbviewer.ipython.org/gist/jzuhone/3472085f67e41f20e00f CIAO (Chandra software) contains all of the ds9 colormaps, so I extracted "sls.lut" from there and just read it in. Does anyone know if there are any licensing issues with the ds9 colormaps? Tom, where would something like this go in astropy.visualization? On Tue, Mar 31, 2015 at 9:36 AM, John Zuhone wrote: > It's definitely do-able, I did it for a couple of ds9 colormaps by hand > for yt, actually. I can try seeing if I can script it up. > > On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben > wrote: > >> On 03/31/2015 08:25 AM, Thomas Robitaille wrote: >> > On 31 March 2015 at 14:00, Peter Weilbacher wrote: >> >> Dear all, >> >> >> >> has anyone succeeded to set up DS9-like color tables for plotting in >> >> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >> >> >> >> I know that matplotlib defines somewhat similar tables, but e.g. >> >> "gist_heat" is just too different from DS9's (and skycat's) heat... >> > If this doesn't exist, this might be a good addition to >> > astropy.visualization or pyds9! >> > >> > Tom >> >> >> Since I had done something similar in a long ago past, I had a quick peek >> at the source distro of ds9. I was surprised to see this part documented >> very lightly (if at all), but the "obvious" code to look at is in >> saods9/saotk/colorbar/default.C >> where a series of >> >> red.append(new LIColor(0,0)); >> red.append(new LIColor(1,1)); >> >> green.append(new LIColor(0,0)); >> green.append(new LIColor(1,1)); >> >> blue.append(new LIColor(0,0)); >> blue.append(new LIColor(1,1)); >> >> create a colortable. The SLS color scheme, which happens to >> be my favorite, does this in RGB space: >> >> colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); >> colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); >> colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); >> colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); >> ... >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> >> others are done programmatically (check out HSV ) >> >> I NEMO and GIPSY these live as ascii tables with 256 entries of RGB >> scaled 0..1, and I checked a few and the ds9 ones seem to match >> the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) >> >> The ds9 codebase also has some yacc & lex parsing, i'm not clear >> if that's still used. Clearly the distribution doesn't contain these >> LUT ascii type files. If we're interested in persuing this, we should >> check with Bill Joye about the best approach to scrape it the right >> way. >> >> My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, >> but I cannot find this in the current ds9 (7.3.x) >> http://carma.astro.umd.edu/nemo/man_html/lut.5.html >> >> peter >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > > -- > John ZuHone > > Postdoctoral Researcher > NASA/Goddard Space Flight Center > > jzuhone at gmail.com > john.zuhone at nasa.gov > -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzuhone at gmail.com Tue Mar 31 10:26:25 2015 From: jzuhone at gmail.com (John Zuhone) Date: Tue, 31 Mar 2015 10:26:25 -0400 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: <551A9A8C.80803@astro.umd.edu> Message-ID: For the curious, the relevant Matplotlib bit that yt uses to import colormaps is here: https://bitbucket.org/yt_analysis/yt/src/9ac515b537a3f2da0b70601f782fdb7dde4716dd/yt/visualization/color_maps.py?at=yt I'd be happy to PR something like it up for AstroPy, if that's what we want. On Tue, Mar 31, 2015 at 10:17 AM, John Zuhone wrote: > So I'm able to do it in yt, which is probably just a short step from doing > it in AstroPy, since it's just NumPy and Matplotlib calls: > > http://nbviewer.ipython.org/gist/jzuhone/3472085f67e41f20e00f > > CIAO (Chandra software) contains all of the ds9 colormaps, so I extracted > "sls.lut" from there and just read it in. > > Does anyone know if there are any licensing issues with the ds9 colormaps? > > Tom, where would something like this go in astropy.visualization? > > On Tue, Mar 31, 2015 at 9:36 AM, John Zuhone wrote: > >> It's definitely do-able, I did it for a couple of ds9 colormaps by hand >> for yt, actually. I can try seeing if I can script it up. >> >> On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben >> wrote: >> >>> On 03/31/2015 08:25 AM, Thomas Robitaille wrote: >>> > On 31 March 2015 at 14:00, Peter Weilbacher >>> wrote: >>> >> Dear all, >>> >> >>> >> has anyone succeeded to set up DS9-like color tables for plotting in >>> >> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >>> >> >>> >> I know that matplotlib defines somewhat similar tables, but e.g. >>> >> "gist_heat" is just too different from DS9's (and skycat's) heat... >>> > If this doesn't exist, this might be a good addition to >>> > astropy.visualization or pyds9! >>> > >>> > Tom >>> >>> >>> Since I had done something similar in a long ago past, I had a quick peek >>> at the source distro of ds9. I was surprised to see this part >>> documented >>> very lightly (if at all), but the "obvious" code to look at is in >>> saods9/saotk/colorbar/default.C >>> where a series of >>> >>> red.append(new LIColor(0,0)); >>> red.append(new LIColor(1,1)); >>> >>> green.append(new LIColor(0,0)); >>> green.append(new LIColor(1,1)); >>> >>> blue.append(new LIColor(0,0)); >>> blue.append(new LIColor(1,1)); >>> >>> create a colortable. The SLS color scheme, which happens to >>> be my favorite, does this in RGB space: >>> >>> colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); >>> colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); >>> colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); >>> colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); >>> ... >>> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >>> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >>> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >>> >>> others are done programmatically (check out HSV ) >>> >>> I NEMO and GIPSY these live as ascii tables with 256 entries of RGB >>> scaled 0..1, and I checked a few and the ds9 ones seem to match >>> the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) >>> >>> The ds9 codebase also has some yacc & lex parsing, i'm not clear >>> if that's still used. Clearly the distribution doesn't contain these >>> LUT ascii type files. If we're interested in persuing this, we should >>> check with Bill Joye about the best approach to scrape it the right >>> way. >>> >>> My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, >>> but I cannot find this in the current ds9 (7.3.x) >>> http://carma.astro.umd.edu/nemo/man_html/lut.5.html >>> >>> peter >>> >>> >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> >> >> >> -- >> John ZuHone >> >> Postdoctoral Researcher >> NASA/Goddard Space Flight Center >> >> jzuhone at gmail.com >> john.zuhone at nasa.gov >> > > > > -- > John ZuHone > > Postdoctoral Researcher > NASA/Goddard Space Flight Center > > jzuhone at gmail.com > john.zuhone at nasa.gov > -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Tue Mar 31 11:26:24 2015 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 31 Mar 2015 11:26:24 -0400 Subject: [AstroPy] getting id value from xml files In-Reply-To: <55186CE0.6070106@gmail.com> References: <55149A76.5050504@gmail.com> <55155E70.8070904@stsci.edu> <55186CE0.6070106@gmail.com> Message-ID: <551ABCA0.50101@stsci.edu> On 03/29/2015 05:21 PM, Grigoris Maravelias wrote: > Hi Mike! I just found time to check it... > > On 03/27/2015 02:43 PM, Michael Droettboom wrote: >> The you could do: >> |from astropy.io import votable >> vot = votable.parse("file.xml") >> value = vot.resources[0].infos[0].value| > |I tried that but returns an error: > | > |ERROR: IndexError: list index out of range [__main__] > Traceback (most recent call last): > File "./xml_extractor.py", line 21, in > value = vot.resources[0].infos[0].value > IndexError: list index out of range| That was just an example if your file happened to have the same layout as what I suggested -- since I hadn't seen your file, I just had to guess. Chances are your INFO element in question is in a different location, so you'll need to adjust accordingly. >> I assume you are asking how to do this with astropy.io.votable? >> >> INFO tags can appear in a number of places in a VOTable file, so >> without seeing the whole file, it?s hard to say. >> >> For example, if you had a file like: >> >> | >> >> >> >> >> | > You are almost correct. I provide an original xml file (see [1]) I don't see the target of the citation (maybe just forgot?). Cheers, Mike > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gr.maravelias at gmail.com Tue Mar 31 12:18:18 2015 From: gr.maravelias at gmail.com (Grigoris Maravelias) Date: Tue, 31 Mar 2015 18:18:18 +0200 Subject: [AstroPy] getting id value from xml files In-Reply-To: <551ABCA0.50101@stsci.edu> References: <55149A76.5050504@gmail.com> <55155E70.8070904@stsci.edu> <55186CE0.6070106@gmail.com> <551ABCA0.50101@stsci.edu> Message-ID: <551AC8CA.4090306@gmail.com> Oops...yea, sorry about that, you can find it here: https://www.dropbox.com/s/vuh1p98tu7896et/587722953306931764_best_model.xml?dl=0 On 03/31/2015 05:26 PM, Michael Droettboom wrote: > I don't see the target of the citation (maybe just forgot?). From mperrin at stsci.edu Tue Mar 31 12:35:59 2015 From: mperrin at stsci.edu (Marshall Perrin) Date: Tue, 31 Mar 2015 16:35:59 +0000 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: <551A9A8C.80803@astro.umd.edu> Message-ID: I implemented the ds9_b colormap a while ago. I hereby contribute the following code snippet to the community in the public domain - reuse freely as you desire. # A Pythoninc re-implementation of DS9's colormap 'B'. colormap_ds9_b = matplotlib.colors.LinearSegmentedColormap('DS9_B', {'red': ((0.0, 0.0, 0.0), (0.25, 0.0, 0.1), (0.50, 1.0,1.0), (0.75, 1.0, 1.0), (1.0, 1.0, 1.0)), 'green': ((0.0, 0.0, 0.0), (0.25, 0.0, 0.0), (0.50, 0.0, 0.0), (0.75, 1.0, 1.0), (1.00, 1.0, 1.0)), 'blue': ((0.00, 0.0, 0.0), (0.25, 1.0, 1.0), (0.50, 0.0, 0.0), (0.75, 0.0, 0.0), (1.00, 1.0, 1.0)) }) On Mar 31, 2015, at 7:26 AM, John Zuhone > wrote: For the curious, the relevant Matplotlib bit that yt uses to import colormaps is here: https://bitbucket.org/yt_analysis/yt/src/9ac515b537a3f2da0b70601f782fdb7dde4716dd/yt/visualization/color_maps.py?at=yt I'd be happy to PR something like it up for AstroPy, if that's what we want. On Tue, Mar 31, 2015 at 10:17 AM, John Zuhone > wrote: So I'm able to do it in yt, which is probably just a short step from doing it in AstroPy, since it's just NumPy and Matplotlib calls: http://nbviewer.ipython.org/gist/jzuhone/3472085f67e41f20e00f CIAO (Chandra software) contains all of the ds9 colormaps, so I extracted "sls.lut" from there and just read it in. Does anyone know if there are any licensing issues with the ds9 colormaps? Tom, where would something like this go in astropy.visualization? On Tue, Mar 31, 2015 at 9:36 AM, John Zuhone > wrote: It's definitely do-able, I did it for a couple of ds9 colormaps by hand for yt, actually. I can try seeing if I can script it up. On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben > wrote: On 03/31/2015 08:25 AM, Thomas Robitaille wrote: > On 31 March 2015 at 14:00, Peter Weilbacher > wrote: >> Dear all, >> >> has anyone succeeded to set up DS9-like color tables for plotting in >> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >> >> I know that matplotlib defines somewhat similar tables, but e.g. >> "gist_heat" is just too different from DS9's (and skycat's) heat... > If this doesn't exist, this might be a good addition to > astropy.visualization or pyds9! > > Tom Since I had done something similar in a long ago past, I had a quick peek at the source distro of ds9. I was surprised to see this part documented very lightly (if at all), but the "obvious" code to look at is in saods9/saotk/colorbar/default.C where a series of red.append(new LIColor(0,0)); red.append(new LIColor(1,1)); green.append(new LIColor(0,0)); green.append(new LIColor(1,1)); blue.append(new LIColor(0,0)); blue.append(new LIColor(1,1)); create a colortable. The SLS color scheme, which happens to be my favorite, does this in RGB space: colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); ... colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); others are done programmatically (check out HSV ) I NEMO and GIPSY these live as ascii tables with 256 entries of RGB scaled 0..1, and I checked a few and the ds9 ones seem to match the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) The ds9 codebase also has some yacc & lex parsing, i'm not clear if that's still used. Clearly the distribution doesn't contain these LUT ascii type files. If we're interested in persuing this, we should check with Bill Joye about the best approach to scrape it the right way. My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, but I cannot find this in the current ds9 (7.3.x) http://carma.astro.umd.edu/nemo/man_html/lut.5.html peter _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone at gmail.com john.zuhone at nasa.gov _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sosey at stsci.edu Tue Mar 31 13:11:36 2015 From: sosey at stsci.edu (Megan Sosey) Date: Tue, 31 Mar 2015 17:11:36 +0000 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: References: <551A9A8C.80803@astro.umd.edu> , Message-ID: <298730F3-9634-4C66-8316-1E8784861E51@stsci.edu> Via the intertubes > On Mar 31, 2015, at 12:59 PM, "Megan Sosey" wrote: > > you can still feed ds9 your own colormap with ?cmap? , it expects a valid colormap lookup table valid contrast values specifying level and intensity, > looking something like this, and described here http://tdc-www.harvard.edu/software/saoimage/saoimage.cmap.html : -cmap file filename.lut > > > http://ds9.si.edu/ref/file.html#ColorLookupTable > > You can save the ds9 color table you like from the gui using the ?Colormap parameters? menu, here?s the one it saved for ?heat? > > > # SAOimage color table > > PSEUDOCOLOR > > RED: > > (0,0)(0.34,1)(1,1) > > GREEN: > > (0,0)(1,1) > > BLUE: > > (0,0)(0.65,0)(0.98,1)(1,1) > > > If you want to translate that to matplotlib you can do this: > > Make a dictionary for the color translation: > > cdict= {'red': ((0., 0, 0, 0), > (0.34, 1, 1, 1), > (1, 1, 1,1)), > > 'green': ((0,0,0,0), > (1,1,1,1)), > > 'blue': ((0,0,0,0), > (0.65,0,0,0), > (0.98,1,1,1), > (1,1,1,1)) > } > > import matplotlib.pylab as plt > from matplotlib import colors > > test=colors.LinearSegmentedColormap('megan',cdict) > > plt.register_cmap(?megan?,test) > > > plt.figure() > plt.imshow(data) > plt.set_cmap(?megan?) > > > From: John Zuhone > > Reply-To: Astronomical Python mailing list > > Date: Tuesday, March 31, 2015 at 9:36 AM > To: Astronomical Python mailing list > > Subject: Re: [AstroPy] DS9 color tables in Python > > It's definitely do-able, I did it for a couple of ds9 colormaps by hand for yt, actually. I can try seeing if I can script it up. > > On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben > wrote: >> On 03/31/2015 08:25 AM, Thomas Robitaille wrote: >>> On 31 March 2015 at 14:00, Peter Weilbacher > wrote: >>> Dear all, >>> >>> has anyone succeeded to set up DS9-like color tables for plotting in >>> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >>> >>> I know that matplotlib defines somewhat similar tables, but e.g. >>> "gist_heat" is just too different from DS9's (and skycat's) heat... >> If this doesn't exist, this might be a good addition to >> astropy.visualization or pyds9! >> >> Tom > > > Since I had done something similar in a long ago past, I had a quick peek > at the source distro of ds9. I was surprised to see this part documented > very lightly (if at all), but the "obvious" code to look at is in > saods9/saotk/colorbar/default.C > where a series of > > red.append(new LIColor(0,0)); > red.append(new LIColor(1,1)); > > green.append(new LIColor(0,0)); > green.append(new LIColor(1,1)); > > blue.append(new LIColor(0,0)); > blue.append(new LIColor(1,1)); > > create a colortable. The SLS color scheme, which happens to > be my favorite, does this in RGB space: > > colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); > colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); > colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); > colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); > ... > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); > > others are done programmatically (check out HSV ) > > I NEMO and GIPSY these live as ascii tables with 256 entries of RGB > scaled 0..1, and I checked a few and the ds9 ones seem to match > the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) > > The ds9 codebase also has some yacc & lex parsing, i'm not clear > if that's still used. Clearly the distribution doesn't contain these > LUT ascii type files. If we're interested in persuing this, we should > check with Bill Joye about the best approach to scrape it the right > way. > > My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, > but I cannot find this in the current ds9 (7.3.x) > http://carma.astro.umd.edu/nemo/man_html/lut.5.html > > peter > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > John ZuHone > > Postdoctoral Researcher > NASA/Goddard Space Flight Center > > jzuhone at gmail.com > john.zuhone at nasa.gov > From bjw at as.arizona.edu Tue Mar 31 13:17:46 2015 From: bjw at as.arizona.edu (Benjamin Weiner) Date: Tue, 31 Mar 2015 10:17:46 -0700 Subject: [AstroPy] DS9 color tables in Python (Peter Teuben) Message-ID: ?Hi, In a previous version of SAOimage, I believe it was possible to export the built in colormap tables to text files, and to read in ?your own. I can't find this functionality in the current ds9 (version7.x) that I have installed, but anyone bold enough to install the older SAOimage could probably just export all the built in colormaps from it. 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 sosey at stsci.edu Tue Mar 31 13:41:42 2015 From: sosey at stsci.edu (Megan Sosey) Date: Tue, 31 Mar 2015 17:41:42 +0000 Subject: [AstroPy] DS9 color tables in Python (Peter Teuben) In-Reply-To: References: Message-ID: <2A3BCEE5-4BCE-4D4A-BDFA-4D7BCCE67D6A@stsci.edu> Did you look in the color menu under colormap parameters? It pops open a new window frame with a file menu that you can save the map from, not totally intuitive .. Meg Via the intertubes On Mar 31, 2015, at 1:17 PM, "Benjamin Weiner" > wrote: ?Hi, In a previous version of SAOimage, I believe it was possible to export the built in colormap tables to text files, and to read in ?your own. I can't find this functionality in the current ds9 (version7.x) that I have installed, but anyone bold enough to install the older SAOimage could probably just export all the built in colormaps from it. 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 teuben at astro.umd.edu Tue Mar 31 13:45:51 2015 From: teuben at astro.umd.edu (Peter Teuben) Date: Tue, 31 Mar 2015 13:45:51 -0400 Subject: [AstroPy] DS9 color tables in Python (Peter Teuben) In-Reply-To: <2A3BCEE5-4BCE-4D4A-BDFA-4D7BCCE67D6A@stsci.edu> References: <2A3BCEE5-4BCE-4D4A-BDFA-4D7BCCE67D6A@stsci.edu> Message-ID: <551ADD4F.5020206@astro.umd.edu> button overload, shameless admission. yes, there it is! thanks Meg. :-) On 03/31/2015 01:41 PM, Megan Sosey wrote: > Did you look in the color menu under colormap parameters? It pops open > a new window frame with a file menu that you can save the map from, > not totally intuitive .. > > Meg > > Via the intertubes > > On Mar 31, 2015, at 1:17 PM, "Benjamin Weiner" > wrote: > >> ?Hi, >> >> In a previous version of SAOimage, I believe it was possible to >> export the built in colormap tables to text files, and to read in ?your >> own. I can't find this functionality in the current ds9 (version7.x) >> that I have installed, but anyone bold enough to install the older >> SAOimage could probably just export all the built in colormaps >> from it. >> >> 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 thomas.robitaille at gmail.com Tue Mar 31 14:13:04 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 31 Mar 2015 20:13:04 +0200 Subject: [AstroPy] DS9 color tables in Python In-Reply-To: <298730F3-9634-4C66-8316-1E8784861E51@stsci.edu> References: <551A9A8C.80803@astro.umd.edu> , <298730F3-9634-4C66-8316-1E8784861E51@stsci.edu> Message-ID: <551AE3B0.5030409@gmail.com> Axel Donath has also coded up the ds9 colormaps in Python here: http://nbviewer.ipython.org/gist/adonath/c9a97d2f2d964ae7b9eb I feel like given that many people seem to have developed this, there's no reason it can't be included in astropy.visualization. Maybe we could have: from astropy.visualization import colormaps as cm then use cm.ds9.heat for example. But first, it would be good to check whether this can't be instead included in http://jiffyclub.github.io/palettable/ which is a specialized library for colormaps (not sure if it's too specific for that, will check with the author). Cheers, Tom Megan Sosey wrote: > > Via the intertubes > >> On Mar 31, 2015, at 12:59 PM, "Megan Sosey" wrote: >> >> you can still feed ds9 your own colormap with ?cmap? , it expects a valid colormap lookup table valid contrast values specifying level and intensity, >> looking something like this, and described here http://tdc-www.harvard.edu/software/saoimage/saoimage.cmap.html : -cmap file filename.lut >> >> >> http://ds9.si.edu/ref/file.html#ColorLookupTable >> >> You can save the ds9 color table you like from the gui using the ?Colormap parameters? menu, here?s the one it saved for ?heat? >> >> >> # SAOimage color table >> >> PSEUDOCOLOR >> >> RED: >> >> (0,0)(0.34,1)(1,1) >> >> GREEN: >> >> (0,0)(1,1) >> >> BLUE: >> >> (0,0)(0.65,0)(0.98,1)(1,1) >> >> >> If you want to translate that to matplotlib you can do this: >> >> Make a dictionary for the color translation: >> >> cdict= {'red': ((0., 0, 0, 0), >> (0.34, 1, 1, 1), >> (1, 1, 1,1)), >> >> 'green': ((0,0,0,0), >> (1,1,1,1)), >> >> 'blue': ((0,0,0,0), >> (0.65,0,0,0), >> (0.98,1,1,1), >> (1,1,1,1)) >> } >> >> import matplotlib.pylab as plt >> from matplotlib import colors >> >> test=colors.LinearSegmentedColormap('megan',cdict) >> >> plt.register_cmap(?megan?,test) >> >> >> plt.figure() >> plt.imshow(data) >> plt.set_cmap(?megan?) >> >> >> From: John Zuhone > >> Reply-To: Astronomical Python mailing list > >> Date: Tuesday, March 31, 2015 at 9:36 AM >> To: Astronomical Python mailing list > >> Subject: Re: [AstroPy] DS9 color tables in Python >> >> It's definitely do-able, I did it for a couple of ds9 colormaps by hand for yt, actually. I can try seeing if I can script it up. >> >> On Tue, Mar 31, 2015 at 9:01 AM, Peter Teuben > wrote: >>> On 03/31/2015 08:25 AM, Thomas Robitaille wrote: >>>> On 31 March 2015 at 14:00, Peter Weilbacher > wrote: >>>> Dear all, >>>> >>>> has anyone succeeded to set up DS9-like color tables for plotting in >>>> Python? I'm specifically interested in "heat", "sls", "hsv", and "b". >>>> >>>> I know that matplotlib defines somewhat similar tables, but e.g. >>>> "gist_heat" is just too different from DS9's (and skycat's) heat... >>> If this doesn't exist, this might be a good addition to >>> astropy.visualization or pyds9! >>> >>> Tom >> >> Since I had done something similar in a long ago past, I had a quick peek >> at the source distro of ds9. I was surprised to see this part documented >> very lightly (if at all), but the "obvious" code to look at is in >> saods9/saotk/colorbar/default.C >> where a series of >> >> red.append(new LIColor(0,0)); >> red.append(new LIColor(1,1)); >> >> green.append(new LIColor(0,0)); >> green.append(new LIColor(1,1)); >> >> blue.append(new LIColor(0,0)); >> blue.append(new LIColor(1,1)); >> >> create a colortable. The SLS color scheme, which happens to >> be my favorite, does this in RGB space: >> >> colors.append(new RGBColor(0.000000, 0.000000, 0.000000)); >> colors.append(new RGBColor(0.043442, 0.000000, 0.052883)); >> colors.append(new RGBColor(0.086883, 0.000000, 0.105767)); >> colors.append(new RGBColor(0.130325, 0.000000, 0.158650)); >> ... >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> colors.append(new RGBColor(1.000000, 1.000000, 1.000000)); >> >> others are done programmatically (check out HSV ) >> >> I NEMO and GIPSY these live as ascii tables with 256 entries of RGB >> scaled 0..1, and I checked a few and the ds9 ones seem to match >> the ones I see in GIPSY or NEMO. (NEMO/data/lut or GIPSY/dat/lut) >> >> The ds9 codebase also has some yacc & lex parsing, i'm not clear >> if that's still used. Clearly the distribution doesn't contain these >> LUT ascii type files. If we're interested in persuing this, we should >> check with Bill Joye about the best approach to scrape it the right >> way. >> >> My old notes from 2003 tell me that ds9 can read my LUT/RGB ascii tables, >> but I cannot find this in the current ds9 (7.3.x) >> http://carma.astro.umd.edu/nemo/man_html/lut.5.html >> >> peter >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> -- >> John ZuHone >> >> Postdoctoral Researcher >> NASA/Goddard Space Flight Center >> >> jzuhone at gmail.com >> john.zuhone at nasa.gov >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From bjw at as.arizona.edu Tue Mar 31 14:52:52 2015 From: bjw at as.arizona.edu (Benjamin Weiner) Date: Tue, 31 Mar 2015 11:52:52 -0700 Subject: [AstroPy] DS9 color tables in Python (Megan Sosey) Message-ID: Hi Megan, Thanks - I looked in that menu, Color > Colormap Parameters, but in my ds9, the window it pops up only has sliders for contrast and bias, no load/save controls. I was wrong about the version, I have ds9 6.1.2, so perhaps this came back in version 7. ?The cmap file format has been around forever,? my friend Povilas Palunas wrote a parser for SAOimage cmap files in Fortran (!!)? when we were in grad school, so inter-operating with it is nice. 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 bushouse at stsci.edu Tue Mar 31 14:56:21 2015 From: bushouse at stsci.edu (Howard Bushouse) Date: Tue, 31 Mar 2015 14:56:21 -0400 Subject: [AstroPy] DS9 color tables in Python (Megan Sosey) In-Reply-To: References: Message-ID: <551AEDD5.4060808@stsci.edu> Above the sliders there should be dropdown menus for "File", "Edit", and "Colormap". The options for saving/loading are in the "File" menu. -Howard On 03/31/2015 02:52 PM, Benjamin Weiner wrote: > Hi Megan, > > Thanks - I looked in that menu, > Color > Colormap Parameters, > but in my ds9, the window it pops up only has sliders for > contrast and bias, no load/save controls. I was wrong > about the version, I have ds9 6.1.2, so perhaps this > came back in version 7. > > ?The cmap file format has been around forever,? my friend > Povilas Palunas wrote a parser for SAOimage cmap files > in Fortran (!!)? when we were in grad school, so inter-operating > with it is nice. > > 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 derek at astro.physik.uni-goettingen.de Tue Mar 31 17:33:34 2015 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 31 Mar 2015 23:33:34 +0200 Subject: [AstroPy] Fast ASCII reader with Fortran notation Message-ID: Hi all, first thanks to everyone who contributed to the fast C parser framework in 1.0?s io.ascii, having decent speed when dealing with cumbersome text files has been on my wish list for some time! My next highest priority was always being able to read in Fortran-written ascii files with its standard double-precision notation (1.495978707D+13?) without further processing, which required setting up converters for each column with np.loadtxt or np.genfromtxt. I decided to take a shot at the fast_reader module to enable the c parser to directly recognise the ?D? as exponential character, a branch from the stable tree is here https://github.com/dhomeier/astropy/tree/fortranio which adds ?fortran_dexp? as new option to the fast_reader arguments. Is there general interest for a pull request against stable or master? I?d also like to put some questions on refinements for discussion: 1. This patch automatically activates the fast_converter, as changing the call to xstrtod was by far the simplest implementation. I guess it would be possible to add it to the more precise parser as well, but don?t know how big the demand for this is. I have yet to see a case where use_fast_converter gave a different result. 2. Currently ?fortran_dexp?=True changes the recognised exponential character to ?d? or ?D? only, it?s easy to add any other character or an ?automatic? option that will both recognise ?e? and ?d? in the same file, at a seemingly small performance penalty of 5-10 %. If there is interest I could definitely add the second option. Cheers, Derek