From benjamin.weaver at nyu.edu Sun May 1 14:55:37 2016 From: benjamin.weaver at nyu.edu (Benjamin Alan Weaver) Date: Sun, 1 May 2016 14:55:37 -0400 Subject: [AstroPy] ANN: Release of PyDL/0.5.0 Message-ID: Dear colleagues, PyDL, an astropy-affiliated package, version 0.5.0 has been released. PyDL implements many routines from IDL-based packages that are heavily used by SDSS. This version incorporates many changes, which are summarized at http://pydl.readthedocs.io/en/stable/pydl/changes.html. Notable improvements include: - Enhanced support for SDSS-style Yanny parameter files. - Additional support for Mangle data. - Improved spectral template processing code. - RGB color images from FITS images, using algorithms from Lupton et al. (2004), see http://pydl.readthedocs.io/en/stable/pydl/pydlutils.html#module-pydl.pydlutils.rgbcolor. More information, repository & issue tracker: https://github.com/weaverba137/pydl Documentation: http://pydl.readthedocs.io/en/stable/ Many thanks to everyone who has contributed! See http://pydl.readthedocs.io/en/stable/pydl/credits.html for a detailed listing. Feedback, contributions, and comments are welcome. Kia ora koutou, Benjamin Alan Weaver -- a.k.a. The Dream Weaver Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read. --Groucho Marx From pae9 at leicester.ac.uk Thu May 5 07:00:57 2016 From: pae9 at leicester.ac.uk (Phil Evans) Date: Thu, 5 May 2016 12:00:57 +0100 Subject: [AstroPy] All-sky plots in astropy Message-ID: <572B27E9.7060708@leicester.ac.uk> Hi, I'm fairly new to plotting in astropy (indeed, python plotting in general), so forgive me if this is basic but: I'm trying to do an all-sky plot in astropy/wcsaxes. The problem I have is that the Aitoff-plot need two grid lines at RA=0; one of the left of the plot and one at the right; however only one is rendering. A version of the code is below. I can't currently provide the FITS file or an image is they contain propretary data, although I can mock something else up if needed. The input file is a FITS image with RA---AIT and DEC--AIT as the CTYPEs. Thanks for any help you can give! Phil #!/usr/bin/env python import matplotlib.pyplot as plt import pyregion from astropy.io import fits from astropy.wcs import WCS from wcsaxes import WCSAxes from astropy import units as u import sys outfile=None if len(sys.argv)<2: print "Usage: skymap.py infile [outfile]" sys.exit(1) infile=sys.argv[1]; if len(sys.argv)>2: outfile=sys.argv[2] hdu=fits.open(infile)[0] wcs=WCS(hdu.header) fig=plt.figure() ax = WCSAxes(fig, [0.0, 0.0, 1.0, 1.0], wcs=wcs) fig.add_axes(ax) image=hdu.data ax.imshow(image, cmap='gray_r', origin='lower', vmin=0, vmax=1e-5,alpha=1.0) lon=ax.coords['RA'] lat=ax.coords['Dec'] #lon.set_axislabel("RA") #lat.set_axislabel("Dec") lon.set_major_formatter('hh:mm:ss') lon.set_ticks(spacing=30.0*u.degree) lat.set_ticks(spacing=30.0*u.degree) lon.grid(color='black', alpha=1.0, linestyle='solid') lat.grid(color='black', alpha=1.0, linestyle='solid') r=pyregion.open("sun.reg") p, text_list = r.get_mpl_patches_texts() p[0].set_facecolor('#666600') p[0].set_edgecolor('#666600') p[0].set_alpha(0.3) p[0].set_transform(ax.get_transform('fk5')) ax.add_patch(p[0]) r=pyregion.open("moon.reg") p, text_list = r.get_mpl_patches_texts() p[0].set_facecolor('cyan') p[0].set_edgecolor('cyan') p[0].set_alpha(0.3) p[0].set_transform(ax.get_transform('fk5')) ax.add_patch(p[0]) for ra in [0, 30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330] : raticklabel = str(ra/15) + '$^h$' ax.text(ra, 0, raticklabel, ha='center', transform=ax.get_transform("fk5"), color='r') for dec in [-60, -30, 30, 60]: decticklabel = str(dec) + '$^o$' ax.text(0, dec, decticklabel, ha='center', transform=ax.get_transform("fk5"), color='b') if outfile!=None: plt.savefig(outfile, dpi=144) else: plt.show() -- ------------------------- Phil Evans, Swift Development Scientist X-ray and Observational Astronomy Group, University of Leicester Tel: +44 (0)116 252 5059 Mobile: +44 (0)7780 980240 (work) Mobile: +44 (0)7974 977723 (personal) pae9 at leicester.ac.uk http://www.star.le.ac.uk/~pae9 http://www.swift.ac.uk Follow me as a Swift scientist on Twitter: @swift_phil http://www.star.le.ac.uk/~pae9/twitter From peter at newton.cx Wed May 11 12:28:00 2016 From: peter at newton.cx (Peter Williams) Date: Wed, 11 May 2016 12:28:00 -0400 Subject: [AstroPy] Writing CDS-format ASCII tables Message-ID: <1462984080.8763.22.camel@newton.cx> Hi all, I see that the Astropy CDS table interface doesn't support writing tables, which isn't at all surprising since the format is so complex and finicky. Is anyone aware of any tools out there to assist in generating such tables? I'm definitely OK with using something not written in Python if it gets the job done. ##SELECTION_END## Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From august.fly at gmail.com Wed May 11 12:31:51 2016 From: august.fly at gmail.com (August (Gus) Muench) Date: Wed, 11 May 2016 12:31:51 -0400 Subject: [AstroPy] Writing CDS-format ASCII tables In-Reply-To: <1462984080.8763.22.camel@newton.cx> References: <1462984080.8763.22.camel@newton.cx> Message-ID: Yep. CDS -- http://cds.u-strasbg.fr/resources/doku.php?id=anafile The line, "Download Python package for ReadMe generation V1.1" -- pyReadme, an astropy based tool. I was suppose to work on this (CDS table writing) over the past year but just haven't had time. - gus ---------- August (Gus) Muench august.fly at gmail.com @augustmuench On Wed, May 11, 2016 at 12:28 PM, Peter Williams wrote: > Hi all, > > I see that the Astropy CDS table interface doesn't support writing tables, > which isn't at all surprising since the format is so complex and finicky. > Is anyone aware of any tools out there to assist in generating such tables? > I'm definitely OK with using something not written in Python if it gets the > job done. > > Thanks, > > Peter > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Wed May 11 12:53:38 2016 From: npkuin at gmail.com (Paul Kuin) Date: Wed, 11 May 2016 17:53:38 +0100 Subject: [AstroPy] Writing CDS-format ASCII tables In-Reply-To: References: <1462984080.8763.22.camel@newton.cx> Message-ID: Yes, anafile is the one. It is also very handy for checking the table. On Wed, May 11, 2016 at 5:31 PM, August (Gus) Muench wrote: > Yep. CDS -- http://cds.u-strasbg.fr/resources/doku.php?id=anafile > > The line, "Download Python package for ReadMe generation V1.1" -- > pyReadme, an astropy based tool. > > I was suppose to work on this (CDS table writing) over the past year but > just haven't had time. > > - gus > > > > ---------- > August (Gus) Muench > august.fly at gmail.com > @augustmuench > > On Wed, May 11, 2016 at 12:28 PM, Peter Williams wrote: > >> Hi all, >> >> I see that the Astropy CDS table interface doesn't support writing >> tables, which isn't at all surprising since the format is so complex and >> finicky. Is anyone aware of any tools out there to assist in generating >> such tables? I'm definitely OK with using something not written in Python >> if it gets the job done. >> >> Thanks, >> >> Peter >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204111 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Wed May 11 21:19:41 2016 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Wed, 11 May 2016 21:19:41 -0400 Subject: [AstroPy] Writing CDS-format ASCII tables In-Reply-To: References: <1462984080.8763.22.camel@newton.cx> Message-ID: Wow, thanks for the heads-up! It would be excellent to take this code into astropy.io.ascii to provide a CDS writer. Unfortunately the pyreadme code there has no license that I can find, so I just sent mail to CDS asking about this. - Tom On Wed, May 11, 2016 at 12:53 PM, Paul Kuin wrote: > Yes, anafile is the one. It is also very handy for checking the table. > > On Wed, May 11, 2016 at 5:31 PM, August (Gus) Muench > wrote: > >> Yep. CDS -- http://cds.u-strasbg.fr/resources/doku.php?id=anafile >> >> The line, "Download Python package for ReadMe generation V1.1" -- >> pyReadme, an astropy based tool. >> >> I was suppose to work on this (CDS table writing) over the past year but >> just haven't had time. >> >> - gus >> >> >> >> ---------- >> August (Gus) Muench >> august.fly at gmail.com >> @augustmuench >> >> On Wed, May 11, 2016 at 12:28 PM, Peter Williams wrote: >> >>> Hi all, >>> >>> I see that the Astropy CDS table interface doesn't support writing >>> tables, which isn't at all surprising since the format is so complex and >>> finicky. Is anyone aware of any tools out there to assist in generating >>> such tables? I'm definitely OK with using something not written in Python >>> if it gets the job done. >>> >>> Thanks, >>> >>> Peter >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > > -- > > * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * > Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) > phone +44-(0)1483 (prefix) -204111 (work) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Thu May 12 06:57:53 2016 From: npkuin at gmail.com (Paul Kuin) Date: Thu, 12 May 2016 11:57:53 +0100 Subject: [AstroPy] Writing CDS-format ASCII tables In-Reply-To: References: <1462984080.8763.22.camel@newton.cx> Message-ID: The output from anafile is mainly the format table. There needs to be further editing for the description, notes to the table, etc. On Thu, May 12, 2016 at 2:19 AM, Aldcroft, Thomas < aldcroft at head.cfa.harvard.edu> wrote: > Wow, thanks for the heads-up! It would be excellent to take this code > into astropy.io.ascii to provide a CDS writer. Unfortunately the pyreadme > code there has no license that I can find, so I just sent mail to CDS > asking about this. > > - Tom > > On Wed, May 11, 2016 at 12:53 PM, Paul Kuin wrote: > >> Yes, anafile is the one. It is also very handy for checking the table. >> >> On Wed, May 11, 2016 at 5:31 PM, August (Gus) Muench < >> august.fly at gmail.com> wrote: >> >>> Yep. CDS -- http://cds.u-strasbg.fr/resources/doku.php?id=anafile >>> >>> The line, "Download Python package for ReadMe generation V1.1" -- >>> pyReadme, an astropy based tool. >>> >>> I was suppose to work on this (CDS table writing) over the past year but >>> just haven't had time. >>> >>> - gus >>> >>> >>> >>> ---------- >>> August (Gus) Muench >>> august.fly at gmail.com >>> @augustmuench >>> >>> On Wed, May 11, 2016 at 12:28 PM, Peter Williams >>> wrote: >>> >>>> Hi all, >>>> >>>> I see that the Astropy CDS table interface doesn't support writing >>>> tables, which isn't at all surprising since the format is so complex and >>>> finicky. Is anyone aware of any tools out there to assist in generating >>>> such tables? I'm definitely OK with using something not written in Python >>>> if it gets the job done. >>>> >>>> Thanks, >>>> >>>> Peter >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> https://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> >> -- >> >> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * >> Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) >> phone +44-(0)1483 (prefix) -204111 (work) >> mobile +44(0)7806985366 skype ID: npkuin >> Mullard Space Science Laboratory ? University College London ? >> Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204111 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjyanghj at gmail.com Thu May 19 11:42:05 2016 From: hjyanghj at gmail.com (Yang Hon-Jang) Date: Thu, 19 May 2016 23:42:05 +0800 Subject: [AstroPy] get_sun got wrong position ? Message-ID: Hi, As I know, spring equinox of 2016 is on 2016/3/20 4:30 GMT. I execute following statements ==== from astropy.time import Time from astropy.coordinates import get_sun t=Time('2016-03-20 4:30:00') s=get_sun(t) ==== I expect to get s.ra.degree and s.dec.degree very close to 0. But I got s.ra.degree=0.7052336 and s.dec.degree=0.30536325. Why? Hope some one can help me. Thanks. hjyanghj -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.roberts.15 at ucl.ac.uk Thu May 19 13:04:59 2016 From: michael.roberts.15 at ucl.ac.uk (Roberts, Michael) Date: Thu, 19 May 2016 17:04:59 +0000 Subject: [AstroPy] Playing with fits files/fire Message-ID: Dear all, So I'm just playing with using the fits file handler, I wanted to check how something is done. I am opening a fits file with: with fits.open('/Users/.../SWIFT/UVOTIMSUM/M33_sum_uvm2_norm.img') as ima_norm_um2: I wanted to know how I could then utilise this with the mode='update' argument, and use the flush...when using what I am using I seem to be losing my WCS coordinates that are within the primary header...so I want to go in and modify the image in the second header and then write it back to the original file...over the image extension. Is that at all possible? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pae9 at leicester.ac.uk Fri May 20 03:15:55 2016 From: pae9 at leicester.ac.uk (Phil Evans) Date: Fri, 20 May 2016 08:15:55 +0100 Subject: [AstroPy] get_sun got wrong position ? In-Reply-To: References: Message-ID: <573EB9AB.3090806@leicester.ac.uk> I can reproduce this, although I can also confirm that using ephem I get values ~0 as you expect. I believe the error must be in the get_sun module, because if I print out t.unix from your code I get 1458448200.0, which is the same as I get independently converting that date/time you gave into unix time. Not a solution to the astropy issue, but if you need the sun position urgently - attached is the pyephem-based script I use to get the Sun position (arguments are year, day-of-year, HH:MM:SS) Phil On 19/05/16 16:42, Yang Hon-Jang wrote: > Hi, > > As I know, spring equinox of 2016 is on 2016/3/20 4:30 GMT. > > I execute following statements > ==== > from astropy.time import Time > from astropy.coordinates import get_sun > t=Time('2016-03-20 4:30:00') > s=get_sun(t) > ==== > I expect to get s.ra.degree and s.dec.degree very close to 0. > But I got s.ra.degree=0.7052336 and s.dec.degree=0.30536325. > > Why? Hope some one can help me. Thanks. > > hjyanghj > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -- ------------------------- Phil Evans, Swift Development Scientist X-ray and Observational Astronomy Group, University of Leicester Tel: +44 (0)116 252 5059 Mobile: +44 (0)7780 980240 (work) Mobile: +44 (0)7974 977723 (personal) pae9 at leicester.ac.uk http://www.star.le.ac.uk/~pae9 http://www.swift.ac.uk Follow me as a Swift scientist on Twitter: @swift_phil http://www.star.le.ac.uk/~pae9/twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: getSunPos.py Type: text/x-python Size: 962 bytes Desc: not available URL: From thomas.robitaille at gmail.com Fri May 20 09:32:41 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 20 May 2016 14:32:41 +0100 Subject: [AstroPy] zscale in astropy.visualization In-Reply-To: <6C26F877-99BF-41CD-BDE2-DCECF3F4FF1B@iaa.es> References: <6C26F877-99BF-41CD-BDE2-DCECF3F4FF1B@iaa.es> Message-ID: Just to close the loop on this, this is now available in the latest developer version of Astropy thanks to Simon Conseil: https://github.com/astropy/astropy/pull/4776 http://docs.astropy.org/en/latest/visualization/normalization.html#intervals-and-normalization The feature will also be present in the upcoming Astropy 1.2 release. Cheers, Tom On 12 April 2016 at 17:55, ES.Enrique Perez wrote: > There is img_scale.py that implements zscale: > > # Written by Min-Su Shin > # Department of Astronomy, University of Michigan (2009 - ) > # Department of Astrophysical Sciences, Princeton University (2005 - 2009) > # > # You can freely use the code. > # > # http://www.astrobetter.com/making-rgb-images-from-fits-files-with-pythonmatplotlib/ > # > > >> El 12/4/2016, a las 15:11, Thomas Robitaille escribi?: >> >> Hi John, >> >> As far as I know there is no implementation of zscale in >> astropy.visualization, but it would be great to have one! I've opened >> an issue here: >> >> https://github.com/astropy/astropy/issues/4773 >> >> If anyone is interested in implementing this, just comment on the issue! >> >> Cheers, >> Tom >> >> >> On 11 April 2016 at 19:06, John K. Parejko wrote: >>> Is there something akin to the ds9-style zscaling algorithm in astropy.visualization (or elsewhere in astropy)? I don't see anything named as such, but maybe it is called differently? >>> >>> This is the algorithm described in this iraf.net email from Frank Valdes: >>> >>> http://iraf.net/forum/viewtopic.php?showtopic=134139 >>> >>> Thanks, >>> John >>> >>> -- >>> ************************* >>> John Parejko >>> parejkoj at uw.edu >>> http://staff.washington.edu/parejkoj/ >>> Department of Physics and Astronomy >>> University of Washington >>> Seattle, WA >>> ************************** >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From stuart at cadair.com Wed May 25 06:33:58 2016 From: stuart at cadair.com (Stuart Mumford) Date: Wed, 25 May 2016 11:33:58 +0100 Subject: [AstroPy] SunPy 0.7! Message-ID: Hello all, The SunPy project is happy to announce the release of SunPy 0.7.0. SunPy 0.7 is the next major release of SunPy and contains 665 commits from 27 people, 11 of which have never contributed before. The major features of this release are: * Python 3.4 and 3.5 support. This is the first version of SunPy to support Python 3, we recommend that users start to consider moving to Python 3, please report any issues you may have. * New coordinate framework. The new |sunpy.coordinates| module provides a high-level interface to converting between different physical coordinate systems such as Helioprojective and Heliographic, this is based on the astropy.coordinates package. * New |draw_rectangle| and |draw_contours| helpers for |Map|. * New functions |flareclass_to_flux| and |flux_to_flareclass| which convert between GOES flux to GOES class numbers (e.g. X12, M3.4). * Support for masks in SunPy |Map| and |MapCube|. The people who have contributed to this release are: |Stuart Mumford Pritish Chakraborty Steven Christe Jack Ireland Brigitta Sipocz David Perez-Suarez Punyaslok Pattnaik * Michael S Kirk * Andrew Leonard Alex Hamilton Andrew Inglis Daniel Ryan Sally Dacie * Sanskar Modi * Albert Y. Shih Erik M. Bray Larry Manley Priyank Lodha * Nabil Freij Ankit * Igor Babuschkin * Ole Streicher * Simon Liedtke Sudarshan Konge * Tessa D. Wilkinson * Thomas Robitaille yasintoda * | Where an * indicates their first contribution. To install SunPy 0.7 you can follow the install instructions: http://docs.sunpy.org/en/latest/guide/installation/index.html or to upgrade: If you installed SunPy using pip: pip install -U sunpy If you installed via conda, we are now building our packages on conda-forge, so you need to add the conda-forge channel: conda config --add channels conda-forge conda update sunpy Happy Pythoning, Stuart Mumford -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjyanghj at gmail.com Wed May 25 10:14:06 2016 From: hjyanghj at gmail.com (Yang Hon-Jang) Date: Wed, 25 May 2016 22:14:06 +0800 Subject: [AstroPy] get_sun got wrong position ? Message-ID: Phil, Thanks for your attachment.py hjyanghj -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed May 25 12:54:07 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 25 May 2016 17:54:07 +0100 Subject: [AstroPy] ANN: glue v0.8 Message-ID: Hi everyone, We are happy to announce the release of glue v0.8, along with glue-vispy-viewers v0.4, which adds experimental 3D viewers (powered by VisPy) to glue. ### About glue Glue is a Python library to explore relationships within and among related datasets. Its main features include: * Linked Statistical Graphics: with glue, users can create scatter plots, histograms, images, and now 3D representations of their data, as well as create their own custom viewers. Glue is focused on the brushing and linking paradigm, where selections in any graph propagate to all others. * Flexible linking across data: glue uses the logical links that exist between different data sets to overlay visualizations of different data, and to propagate selections across data sets. These links are specified by the user, and are arbitrarily flexible. * Full scripting capability: glue is written in Python, and built on top of its standard scientific libraries (i.e., Numpy, Pandas, Matplotlib, Scipy and others). Users can easily integrate their own python code for data input, cleaning, and analysis. For a 2-minute preview of glue, you can watch the following video: https://www.youtube.com/watch?v=qO3RQiRjWA4 Find out more about glue at http://www.glueviz.org! ### Changes in glue v0.8 An overview of the main changes in this release is available here: http://glueviz.org/en/stable/whatsnew/0.8.html#whatsnew-08 These include: * Playback controls for animating views of cube slices in the image viewer * An improved window for creating new components, which allows math and numpy functions to be used, and also includes on-the-fly syntax validation * The ability to more easily add data to existing glue sessions, for example those started with the qglue function. * A new preferences dialog, with new settings to control the foreground/background color in viewers as well as the default color and transparency for data. * Improved feedback and bug report windows which now allow you to provide your email address so that we can follow up any issues you may be having * The ability to use circular and polygonal regions to extract spectra from cubes (this is mainly for astronomy users) In addition, many bug fixes and small improvements have been made since the v0.7 series of releases. ### Installing/updating glue (new instructions!) You can find installation instructions at the following page: http://glueviz.org/en/stable/installation.html including information on using conda to install the latest version of glue. ### About glue-vispy-viewers The glue-vispy-viewers package is a plugin that adds 3D viewers to glue. You can find out more about this plugin here: http://www.glueviz.org/en/stable/whatsnew/experimental_3d.html#experimental-3d This includes both 3D scatter plots and volume renderings, and support selections using a variety of region types. Please note that these viewers are still experimental. ### Reporting issues/getting help Please let us know if you run into any issues using the issue trackers on GitHub: https://github.com/glue-viz/glue/issues https://github.com/glue-viz/glue-vispy-viewers/issues You can also join the glue-viz mailing list to have any discussions related to glue and/or get help: https://groups.google.com/forum/#!forum/glue-viz ### Getting involved Interested in contributing new features or helping maintain glue or the 3D viewers? Please let me know (by replying off-list to this email), and I can help you get started! Thanks to everyone who contributed to these releases! (including Penny Qian, Robin Wilson, Pey-Lian Lim, and Brett Morris) Thanks, Tom From mcbeth at broggs.org Thu May 26 09:59:12 2016 From: mcbeth at broggs.org (Jeffrey Brent McBeth) Date: Thu, 26 May 2016 09:59:12 -0400 Subject: [AstroPy] Altitude and Azimuth weirdness Message-ID: <20160526135912.GD12887@broggs.org> I have an observer on the ground, and an object in low earth orbit, both coordinates given in ITRS. Now, I want to know where to look at that object. Example code that I am trying is given below #+BEGIN_SRC python #!/usr/bin/env python import astropy.coordinates from astropy.time import Time import astropy.units as u iss = astropy.coordinates.ITRS([-4168468,-2886384,4484231]*u.meter) ground = astropy.coordinates.ITRS([-2741286,-4319576,3796101]*u.meter) aa = astropy.coordinates.AltAz(location=ground,obstime='J2000') print iss.transform_to(aa) aaOther = astropy.coordinates.AltAz(location=ground,obstime='J2005') print iss.transform_to(aaOther) #+END_SRC #+BEGIN_RESULTS #+END_RESULTS The problem that I'm seeing is that the location of where to look changes drastically based on the observation time even though both coordinates are rotating with the earth at all times and so are time agnostic. I won't yet start poking at the problem that Please illuminate my ignorance... Jeff -- "The man who does not read good books has no advantage over the man who cannot read them." -- Mark Twain From ejensen1 at swarthmore.edu Tue May 31 14:07:51 2016 From: ejensen1 at swarthmore.edu (Eric Jensen) Date: Tue, 31 May 2016 14:07:51 -0400 Subject: [AstroPy] Error when opening Vizier FITS table with astropy Table.read Message-ID: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> Hi all, I?m trying to read a FITS table associated with an ApJ paper, and getting an error I don?t understand. The table in question doesn?t have a standard ASCII/CDS version with the full header that astropy handles very well (in my experience) with format=?ascii.cds?, so I was trying to use the FITS version linked here: http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat Looking at that URL, it would appear that Vizier may be doing an on-the-fly conversion to FITS? But my hope was that using that would take into account the information in the Vizier README, and thus generate a nice table structure in Python without my having to identify columns by hand. The plain-text version (http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat) doesn?t have header info, though such info is present in the separate README file. However, when I read the FITS file like this: from astropy.table import Table datafile = 'J_ApJS_186_111_table4.dat.fits' t2 = Table.read(datafile, format='fits') I get this error: ValueError: invalid literal for int() with base 10: ' '; the header may be missing the necessary TNULL3 keyword or the table contains invalid data Looking at the FITS header, there is indeed no TNULL3 keyword, but there is a TBNUL3 keyword: TBNUL3 = ' ' / NULL (undefined) value So presumably that keyword has the needed info, but not in the field astropy is expecting. Is there any way to work around this? Possibly related - reading in that file in its text version, specifying format=?cds? and readme=?ReadMe? doesn?t work correctly either, because the ReadMe has a combined entry for Tables 4 and 5, and says in a note that the third field only applies to Table 5. So this could just be a pathological case for this particular file, but I?m curious to know if anyone has encountered anything like this or has any recommendations. Thanks in advance for your help with this, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Tue May 31 14:56:22 2016 From: npkuin at gmail.com (Paul Kuin) Date: Tue, 31 May 2016 19:56:22 +0100 Subject: [AstroPy] Error when opening Vizier FITS table with astropy Table.read In-Reply-To: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> References: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> Message-ID: Have you tried to read the fits file with astropy.io.fits ? What do you get then for the table? On Tue, May 31, 2016 at 7:07 PM, Eric Jensen wrote: > Hi all, > > I?m trying to read a FITS table associated with an ApJ paper, and getting > an error I don?t understand. The table in question doesn?t have a standard > ASCII/CDS version with the full header that astropy handles very well (in > my experience) with format=?ascii.cds?, so I was trying to use the FITS > version linked here: > > > http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat > > Looking at that URL, it would appear that Vizier may be doing an > on-the-fly conversion to FITS? But my hope was that using that would take > into account the information in the Vizier README, and thus generate a nice > table structure in Python without my having to identify columns by hand. > The plain-text version ( > http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat) > doesn?t have header info, though such info is present in the separate > README file. > > However, when I read the FITS file like this: > > from astropy.table import Table > datafile = 'J_ApJS_186_111_table4.dat.fits' > t2 = Table.read(datafile, format='fits') > > I get this error: > > ValueError: invalid literal for int() with base 10: ' '; the header may be missing the necessary TNULL3 keyword or the table contains invalid data > > Looking at the FITS header, there is indeed no TNULL3 keyword, but there > is a TBNUL3 keyword: > > TBNUL3 = ' ' / NULL (undefined) value > > > So presumably that keyword has the needed info, but not in the field > astropy is expecting. Is there any way to work around this? > > Possibly related - reading in that file in its text version, specifying > format=?cds? and readme=?ReadMe? doesn?t work correctly either, because the > ReadMe has a combined entry for Tables 4 and 5, and says in a note that the > third field only applies to Table 5. So this could just be a pathological > case for this particular file, but I?m curious to know if anyone has > encountered anything like this or has any recommendations. > > Thanks in advance for your help with this, > > Eric > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204111 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejensen1 at swarthmore.edu Tue May 31 15:25:41 2016 From: ejensen1 at swarthmore.edu (Eric Jensen) Date: Tue, 31 May 2016 15:25:41 -0400 Subject: [AstroPy] Error when opening Vizier FITS table with astropy Table.read In-Reply-To: References: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> Message-ID: On May 31, 2016, at 2:56 PM, Paul Kuin wrote: > Have you tried to read the fits file with astropy.io.fits ? What do you get then for the table? It opens the file without error, and I can examine the header. But as soon as I try to access any part of the data structure, I get the same ValueError about TNULL3 shown below. > > On Tue, May 31, 2016 at 7:07 PM, Eric Jensen wrote: > Hi all, > > I?m trying to read a FITS table associated with an ApJ paper, and getting an error I don?t understand. The table in question doesn?t have a standard ASCII/CDS version with the full header that astropy handles very well (in my experience) with format=?ascii.cds?, so I was trying to use the FITS version linked here: > > http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat > > Looking at that URL, it would appear that Vizier may be doing an on-the-fly conversion to FITS? But my hope was that using that would take into account the information in the Vizier README, and thus generate a nice table structure in Python without my having to identify columns by hand. The plain-text version (http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat) doesn?t have header info, though such info is present in the separate README file. > > However, when I read the FITS file like this: > > from astropy.table import Table > datafile = 'J_ApJS_186_111_table4.dat.fits' > t2 = Table.read(datafile, format='fits') > > I get this error: > ValueError: invalid literal for int() with base 10: ' '; the header may be missing the necessary TNULL3 keyword or the table contains invalid data > Looking at the FITS header, there is indeed no TNULL3 keyword, but there is a TBNUL3 keyword: > > TBNUL3 = ' ' / NULL (undefined) value > > So presumably that keyword has the needed info, but not in the field astropy is expecting. Is there any way to work around this? > > Possibly related - reading in that file in its text version, specifying format=?cds? and readme=?ReadMe? doesn?t work correctly either, because the ReadMe has a combined entry for Tables 4 and 5, and says in a note that the third field only applies to Table 5. So this could just be a pathological case for this particular file, but I?m curious to know if anyone has encountered anything like this or has any recommendations. > > Thanks in advance for your help with this, > > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hodge at stsci.edu Tue May 31 15:42:40 2016 From: hodge at stsci.edu (Phil Hodge) Date: Tue, 31 May 2016 15:42:40 -0400 Subject: [AstroPy] Error when opening Vizier FITS table with astropy Table.read In-Reply-To: References: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> Message-ID: <574DE930.6090902@stsci.edu> The keyword (and ones like it) should be TNULL3, not TBNUL3. You can fix this by downloading the FITS file and then opening the file as follows: import astropy.io.fits as fits fd = fits.open("J_ApJS_186_111_table4.dat.fits") Then modify the table header: hdr = fd[1].header hdr.rename_keyword("tbnul3", "tnull3") hdr.rename_keyword("tbnul4", "tnull4") hdr.rename_keyword("tbnul5", "tnull5") hdr.rename_keyword("tbnul7", "tnull7") hdr.rename_keyword("tbnul8", "tnull8") hdr.rename_keyword("tbnul10", "tnull10") hdr.rename_keyword("tbnul13", "tnull13") hdr.rename_keyword("tbnul14", "tnull14") And save it to a new file: fd.writeto("J_ApJS_186_111_table4_mod.fits") # or some other name Phil On 05/31/2016 03:25 PM, Eric Jensen wrote: > > On May 31, 2016, at 2:56 PM, Paul Kuin > wrote: > >> Have you tried to read the fits file with astropy.io.fits ? What do >> you get then for the table? > > It opens the file without error, and I can examine the header. But as > soon as I try to access any part of the data structure, I get the same > ValueError about TNULL3 shown below. > > > >> >> On Tue, May 31, 2016 at 7:07 PM, Eric Jensen > > wrote: >> >> Hi all, >> >> I?m trying to read a FITS table associated with an ApJ paper, and >> getting an error I don?t understand. The table in question >> doesn?t have a standard ASCII/CDS version with the full header >> that astropy handles very well (in my experience) with >> format=?ascii.cds?, so I was trying to use the FITS version >> linked here: >> >> http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat >> >> Looking at that URL, it would appear that Vizier may be doing an >> on-the-fly conversion to FITS? But my hope was that using that >> would take into account the information in the Vizier README, and >> thus generate a nice table structure in Python without my having >> to identify columns by hand. The plain-text version >> (http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat) >> doesn?t have header info, though such info is present in the >> separate README file. >> >> However, when I read the FITS file like this: >> >> from astropy.table import Table >> datafile = 'J_ApJS_186_111_table4.dat.fits' >> t2 = Table.read(datafile, format='fits') >> >> I get this error: >> >> ValueError: invalid literal for int() with base 10: ' '; the >> header may be missing the necessary TNULL3 keyword or the table >> contains invalid data >> >> Looking at the FITS header, there is indeed no TNULL3 keyword, >> but there is a TBNUL3 keyword: >> >> TBNUL3 = ' ' / NULL (undefined) value >> >> So presumably that keyword has the needed info, but not in the >> field astropy is expecting. Is there any way to work around this? >> >> Possibly related - reading in that file in its text version, >> specifying format=?cds? and readme=?ReadMe? doesn?t work >> correctly either, because the ReadMe has a combined entry for >> Tables 4 and 5, and says in a note that the third field only >> applies to Table 5. So this could just be a pathological case >> for this particular file, but I?m curious to know if anyone has >> encountered anything like this or has any recommendations. >> >> Thanks in advance for your help with this, >> >> Eric >> > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From hodge at stsci.edu Tue May 31 16:08:43 2016 From: hodge at stsci.edu (Phil Hodge) Date: Tue, 31 May 2016 16:08:43 -0400 Subject: [AstroPy] Error when opening Vizier FITS table with astropy Table.read In-Reply-To: <574DE930.6090902@stsci.edu> References: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu> <574DE930.6090902@stsci.edu> Message-ID: <574DEF4B.4030501@stsci.edu> It looks as if astropy.io.fits still doesn't accept an empty (or null) string as a value for an integer column in an ASCII table. If you just need to see the data values, you can use the tables package in IRAF as a workaround: --> tprint J_ApJS_186_111_table4_mod.fits[1] row=1-3 # Table J_ApJS_186_111_table4_mod.fits[1] Tue 15:57:58 31-May-2016 # row 2MASS Name Ap 3.6mag e_3.6mag f_3.6mag # pix mag mag 1 J04034930+2610520 HBC 358 A+B+C INDEF 9.15 0.02 2 J04034997+2620382 XEST 06-006 INDEF INDEF INDEF o 3 J04035084+2610531 HBC 359 INDEF 9.33 0.02 # row 4.5mag e_4.5mag f_4.5mag 5.8mag e_5.8mag f_5.8mag 8.0mag e_8.0mag f_8.0mag # mag mag mag mag mag mag 1 9.11 0.02 9.05 0.03 9.05 0.03 2 INDEF INDEF o INDEF INDEF o INDEF INDEF o 3 9.26 0.02 9.23 0.03 9.23 0.03 # row Date # "Y/M/D" 1 2005 Feb 20 2 3 2005 Feb 20 A printed value of INDEF means the table value was not defined. Phil On 05/31/2016 03:42 PM, Phil Hodge wrote: > The keyword (and ones like it) should be TNULL3, not TBNUL3. You can > fix this by downloading the FITS file and then opening the file as > follows: > > import astropy.io.fits as fits > fd = fits.open("J_ApJS_186_111_table4.dat.fits") > > Then modify the table header: > > hdr = fd[1].header > hdr.rename_keyword("tbnul3", "tnull3") > hdr.rename_keyword("tbnul4", "tnull4") > hdr.rename_keyword("tbnul5", "tnull5") > hdr.rename_keyword("tbnul7", "tnull7") > hdr.rename_keyword("tbnul8", "tnull8") > hdr.rename_keyword("tbnul10", "tnull10") > hdr.rename_keyword("tbnul13", "tnull13") > hdr.rename_keyword("tbnul14", "tnull14") > > And save it to a new file: > > fd.writeto("J_ApJS_186_111_table4_mod.fits") # or some other name > > Phil > > > > On 05/31/2016 03:25 PM, Eric Jensen wrote: >> >> On May 31, 2016, at 2:56 PM, Paul Kuin > > wrote: >> >>> Have you tried to read the fits file with astropy.io.fits ? What do >>> you get then for the table? >> >> It opens the file without error, and I can examine the header. But as >> soon as I try to access any part of the data structure, I get the >> same ValueError about TNULL3 shown below. >> >> >> >>> >>> On Tue, May 31, 2016 at 7:07 PM, Eric Jensen >>> > wrote: >>> >>> Hi all, >>> >>> I?m trying to read a FITS table associated with an ApJ paper, and >>> getting an error I don?t understand. The table in question >>> doesn?t have a standard ASCII/CDS version with the full header >>> that astropy handles very well (in my experience) with >>> format=?ascii.cds?, so I was trying to use the FITS version >>> linked here: >>> >>> http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat >>> >>> Looking at that URL, it would appear that Vizier may be doing an >>> on-the-fly conversion to FITS? But my hope was that using that >>> would take into account the information in the Vizier README, and >>> thus generate a nice table structure in Python without my having >>> to identify columns by hand. The plain-text version >>> (http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat) >>> doesn?t have header info, though such info is present in the >>> separate README file. >>> >>> However, when I read the FITS file like this: >>> >>> from astropy.table import Table >>> datafile = 'J_ApJS_186_111_table4.dat.fits' >>> t2 = Table.read(datafile, format='fits') >>> >>> I get this error: >>> >>> ValueError: invalid literal for int() with base 10: ' '; the >>> header may be missing the necessary TNULL3 keyword or the table >>> contains invalid data >>> >>> Looking at the FITS header, there is indeed no TNULL3 keyword, >>> but there is a TBNUL3 keyword: >>> >>> TBNUL3 = ' ' / NULL (undefined) value >>> >>> So presumably that keyword has the needed info, but not in the >>> field astropy is expecting. Is there any way to work around this? >>> >>> Possibly related - reading in that file in its text version, >>> specifying format=?cds? and readme=?ReadMe? doesn?t work >>> correctly either, because the ReadMe has a combined entry for >>> Tables 4 and 5, and says in a note that the third field only >>> applies to Table 5. So this could just be a pathological case >>> for this particular file, but I?m curious to know if anyone has >>> encountered anything like this or has any recommendations. >>> >>> Thanks in advance for your help with this, >>> >>> Eric >>> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy