From Christoph.Deil at mpi-hd.mpg.de Fri Apr 1 02:45:23 2016 From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil) Date: Fri, 1 Apr 2016 08:45:23 +0200 Subject: [AstroPy] AstroPy Digest, Vol 114, Issue 12 In-Reply-To: References: Message-ID: There?s a function to compute the midpoint [1] available in this spherical_geometry package [2]. Looks like it uses xyz vectors, so if you have (lon, lat) you?d have to convert to xyz, compute the midpoint, and convert back to (lon, lat) using the helper functions in [3]. [1] http://spacetelescope.github.io/sphere/api/spherical_geometry.great_circle_arc.midpoint.html [2] http://spacetelescope.github.io/sphere/spherical_geometry/index.html [3] http://spacetelescope.github.io/sphere/spherical_geometry/api.html#module-spherical_geometry.vector Christoph > On 01 Apr 2016, at 00:54, Pistacho Datil wrote: > > thanks Eric > > For the midpoint I went for > > def midpoint(coord1, coord2): > ra1 = coord1.ra > dec1 = coord1.dec > ra2 = coord2.ra > dec2 = coord2.dec > > delta_ra = ra2 - ra1 > bx = np.cos(dec2) * np.cos(delta_ra) > by = np.cos(dec2) * np.sin(delta_ra) > dec_term1 = np.sin(dec1) + np.sin(dec2) > dec_term2 = np.sqrt(np.power((np.cos(dec1) + bx), 2) + np.power(by, 2)) > decMid = np.arctan2(dec_term1, dec_term2) > raMid = ra1 + np.arctan2(by, np.cos(dec1) + bx) > > return SkyCoord(raMid, decMid, frame='fk5') > > not my code but it calculates the midpoint on sky. > > Thanks again, > > Frank > > On Thu, Mar 31, 2016 at 5:00 AM, > wrote: > Send AstroPy mailing list submissions to > astropy at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://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. calculate a new coordinate on sky given RA and Dec offsets > and midpoint coordinate between two targets on sky (Pistacho Datil) > 2. Re: calculate a new coordinate on sky given RA and Dec > offsets and midpoint coordinate between two targets on sky > (Eric Jensen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Mar 2016 17:22:23 -0700 > From: Pistacho Datil > > To: astropy at scipy.org > Subject: [AstroPy] calculate a new coordinate on sky given RA and Dec > offsets and midpoint coordinate between two targets on sky > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Hi, > > First of all apologies if these two questions are too simplistic. > > 1) I wonder if there is a way in astropy, given a target and an offset in > RA and Dec to calculate a new target on sky. > > 2) Given two targets t1 and t2, is there a way using astropy of calculating > the midpoint coordinate also on sky? > > Many thanks in advance, > > Frank > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Wed, 30 Mar 2016 21:26:21 -0400 > From: Eric Jensen > > To: Astronomical Python mailing list > > Subject: Re: [AstroPy] calculate a new coordinate on sky given RA and > Dec offsets and midpoint coordinate between two targets on sky > Message-ID: > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > For #1, here?s a way you can do it: > > from astropy.coordinates import Angle, SkyCoord > from astropy import units as u > > # Define our initial coordinate position: > old_pos = SkyCoord('00h42m30s', '+61d12m00s', frame='icrs') > > # Define the offsets: > ra_offset = Angle(15, unit=u.arcsec) > dec_offset = Angle(-4.5, unit=u.arcsec) > > # Add the offsets to create a new coordinate position: > new_pos = SkyCoord(old_pos.ra + ra_offset, old_pos.dec + dec_offset, frame='icrs') > > print(old_pos.to_string('hmsdms')) > print(new_pos.to_string('hmsdms')) > > > 00h42m30s +61d12m00s > 00h42m31s +61d11m55.5s > > One thing to watch out for if you do it this way: notice that the RA offset is 15 arcseconds *of RA*, not 15 arcseconds *on the sky*. At a dec of 61 degrees, 15 arcseconds of angle on the sky would be more like 30 arcseconds of RA (or in HMS, about 2 seconds of time rather than 1). > > If you want to specify the RA offset in real angle on the sky and convert it to the appropriate RA offset to add to the initial coords, you could change the above to do something like > > import numpy as np > ra_offset = Angle(15, unit=u.arcsec) / np.cos(old_pos.dec.to ('radian')) > > and then proceeding as before, you would get output: > > 00h42m30s +61d12m00s > 00h42m32.0757s +61d11m55.5s > > For your question number 2, you should be able to just do the arithmetic with subtracting the two RA values to find the RA separation, then halve it and add it to t1?s RA, then similarly with Dec, following the example above, to get the midpoint coordinates. > > Both of the above answers probably break down at some level if you have large angular separations, but for small separations they should be reasonably good. I also don?t know how these coordinate object handle edge cases, like crossing over RA = 0 or Dec = 90, but you could test it out. > > Eric > > > > On Mar 30, 2016, at 8:22 PM, Pistacho Datil > wrote: > > > Hi, > > > > First of all apologies if these two questions are too simplistic. > > > > 1) I wonder if there is a way in astropy, given a target and an offset in RA and Dec to calculate a new target on sky. > > > > 2) Given two targets t1 and t2, is there a way using astropy of calculating the midpoint coordinate also on sky? > > > > Many thanks in advance, > > > > Frank > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > ------------------------------ > > End of AstroPy Digest, Vol 114, Issue 12 > **************************************** > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From parejkoj at uw.edu Tue Apr 5 20:02:20 2016 From: parejkoj at uw.edu (John K. Parejko) Date: Tue, 5 Apr 2016 17:02:20 -0700 Subject: [AstroPy] Elliptical 2D gaussian kernel? Message-ID: I'm curious whether there is a 2D Gaussian convolution kernel in astropy that has different x/y sigmas and rotation? I found astropy.convolution.Gaussian2DKernel, but that's circular. Looks like this was partially worked on in #3605, but it looks like it's stalled out? https://github.com/astropy/astropy/issues/3605 John -- ************************* John Parejko parejkoj at uw.edu http://staff.washington.edu/parejkoj/ Department of Physics and Astronomy University of Washington Seattle, WA ************************** From larry.bradley at gmail.com Tue Apr 5 22:03:57 2016 From: larry.bradley at gmail.com (Larry Bradley) Date: Tue, 5 Apr 2016 22:03:57 -0400 Subject: [AstroPy] Elliptical 2D gaussian kernel? In-Reply-To: References: Message-ID: Until #3605 is completed, you can create an elliptical 2D Gaussian kernel using a combination of astropy.modeling.models.Gaussian2D and either CustomKernel or Model2DKernel from the astropy.convolution subpackage. CustomKernel creates a kernel from an odd-sized numpy array, while Model2DKernel creates a kernel from an astropy model instance. Here are concrete examples of both methods: >>> from astropy.modeling.models import Gaussian2D >>> from astropy.convolution import CustomKernel, Model2DKernel >>> from astropy.coordinates import Angle >>> theta = Angle(20, 'deg') >>> g1 = Gaussian2D(10, 50, 50, 15, 5, theta=theta.radian) >>> y, x = np.mgrid[:101, :101] >>> kernel1 = CustomKernel(g1(x, y)) >>> g2 = Gaussian2D(10, 0, 0, 15, 5, theta=theta.radian) >>> kernel2 = Model2DKernel(g2, x_size=101, y_size=101) kernel1 and kernel2 are identical. Note that for Model2DKernel the model position parameters are relative to the center of the kernel array (the g1 and g2 models have different x, y positions). Cheers, Larry On Tue, Apr 5, 2016 at 8:02 PM, John K. Parejko wrote: > I'm curious whether there is a 2D Gaussian convolution kernel in astropy > that has different x/y sigmas and rotation? I found > astropy.convolution.Gaussian2DKernel, but that's circular. > > Looks like this was partially worked on in #3605, but it looks like it's > stalled out? > > https://github.com/astropy/astropy/issues/3605 > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From teuben at astro.umd.edu Tue Apr 5 22:13:59 2016 From: teuben at astro.umd.edu (Peter Teuben) Date: Tue, 5 Apr 2016 22:13:59 -0400 Subject: [AstroPy] Elliptical 2D gaussian kernel? In-Reply-To: References: Message-ID: <570470E7.3030907@astro.umd.edu> an affiliated package has code to convolve such beams, see e.g.: https://github.com/radio-astro-tools/radio_beam/blob/master/radio_beam/beam.py and look for the Beam.convolve() On 04/05/2016 08:02 PM, John K. Parejko wrote: > I'm curious whether there is a 2D Gaussian convolution kernel in astropy that has different x/y sigmas and rotation? I found astropy.convolution.Gaussian2DKernel, but that's circular. > > Looks like this was partially worked on in #3605, but it looks like it's stalled out? > > https://github.com/astropy/astropy/issues/3605 > > 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 From parejkoj at uw.edu Mon Apr 11 19:06:39 2016 From: parejkoj at uw.edu (John K. Parejko) Date: Mon, 11 Apr 2016 16:06:39 -0700 Subject: [AstroPy] zscale in astropy.visualization Message-ID: 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 ************************** From thomas.robitaille at gmail.com Tue Apr 12 09:11:40 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 12 Apr 2016 09:11:40 -0400 Subject: [AstroPy] zscale in astropy.visualization In-Reply-To: References: Message-ID: 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 From eperez at iaa.es Tue Apr 12 12:55:33 2016 From: eperez at iaa.es (ES.Enrique Perez) Date: Tue, 12 Apr 2016 18:55:33 +0200 Subject: [AstroPy] zscale in astropy.visualization In-Reply-To: References: Message-ID: <6C26F877-99BF-41CD-BDE2-DCECF3F4FF1B@iaa.es> 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 From duncan.macleod at ligo.org Wed Apr 13 19:55:53 2016 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Wed, 13 Apr 2016 18:55:53 -0500 Subject: [AstroPy] DeprecationWarning from ipython [metadata was set from the constructor] Message-ID: Hi all, With macports installs of python/ipython/astropy, for a while now I've been getting a DeprecationWarning when import astropy, related to something in ipython. Here is the traceback when I escalate it to an error: $ python -c "import warnings; warnings.simplefilter('error', DeprecationWarning); import astropy" Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/__init__.py", line 284, in from .logger import _init_log, _teardown_log File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/logger.py", line 17, in from .utils.console import color_print File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/utils/console.py", line 29, in from IPython import get_ipython File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/__init__.py", line 48, in from .core.application import Application File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/application.py", line 25, in from IPython.core.profiledir import ProfileDir, ProfileDirError File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", line 29, in class ProfileDir(LoggingConfigurable): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", line 52, in ProfileDir `profile` option.""", File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/traitlets/traitlets.py", line 421, in __init__ DeprecationWarning, stacklevel=stacklevel) DeprecationWarning: metadata {'config': True} was set from the constructor. Metadata should be set using the .tag() method, e.g., Int().tag(key1='value1', key2='value2') Can anyone offer a reason why this is, whether it has been reported before, or whether I can disable the astropy logger in some way (I just want astropy.units!)? For the record, I have the following versions: $ port installed | egrep " python27 | py27-ipython | py27-astropy " | grep "(active)" py27-astropy @1.1.1_2 (active) py27-ipython @4.1.2_0 (active) python27 @2.7.11_2 (active) Thanks in advance 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 kyle.westfall at port.ac.uk Thu Apr 14 06:46:38 2016 From: kyle.westfall at port.ac.uk (Kyle B. Westfall) Date: Thu, 14 Apr 2016 11:46:38 +0100 Subject: [AstroPy] writing/compressing fits files In-Reply-To: <570F6AAB.9000805@port.ac.uk> References: <570F6AAB.9000805@port.ac.uk> Message-ID: <570F750E.4080509@port.ac.uk> Hi all, I'm getting what feels like odd behavior in astropy. I have a file that is 386 MB when written uncompressed by astropy.io.fits.HDUList.writeto(). If I try to write the file as *.fits.gz, instead of *.fits, it is compressed down to 77 MB. The problem is that it takes ~2 minutes longer to write the compressed version. Alternatively, I've just compressed the file using the gzip executable on my Mac: % gzip -V Apple gzip 242 This compresses the file to 14 MB in a few seconds. I want to avoid system calls, so I also tried the following: >>> import gzip >>> import shutil >>> with open('test.fits', 'rb') as f_in: ... with gzip.open('test.fits.gz', 'wb') as f_out: ... shutil.copyfileobj(f_in, f_out) ... pulled from here: https://docs.python.org/3/library/gzip.html#examples-of-usage This takes slightly longer than the system call, but not nearly as long as the astropy.io.fits.HDUList.writeto() command. And this call actually compresses the file down to 12 MB. So the above is my short-term work-around, but I'm wondering if there are better options. One option that was suggested to me was to use CompImageHDU, instead of ImageHDU. So I'll run some tests with that, as well. Thanks for any and all advice, Kyle -- ------------------------------ Kyle B. Westfall kyle.westfall at port.ac.uk Institute of Cosmology and Gravitation (ICG) University of Portsmouth Dennis Sciama Building Burnaby Road Portsmouth PO1 3FX United Kingdom +44 (0)23 9284 5158 www.icg.port.ac.uk/~westfall/ ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Thu Apr 14 07:53:42 2016 From: deil.christoph at googlemail.com (Christoph Deil) Date: Thu, 14 Apr 2016 13:53:42 +0200 Subject: [AstroPy] DeprecationWarning from ipython [metadata was set from the constructor] In-Reply-To: References: Message-ID: <63D98099-9EB0-40DA-BF68-036B6470A401@googlemail.com> > On 14 Apr 2016, at 01:55, Duncan Macleod wrote: > > Hi all, > > With macports installs of python/ipython/astropy, for a while now I've been getting a DeprecationWarning when import astropy, related to something in ipython. Here is the traceback when I escalate it to an error: > > $ python -c "import warnings; warnings.simplefilter('error', DeprecationWarning); import astropy" > Traceback (most recent call last): > File "", line 1, in > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/__init__.py", line 284, in > from .logger import _init_log, _teardown_log > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/logger.py", line 17, in > from .utils.console import color_print > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/utils/console.py", line 29, in > from IPython import get_ipython > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/__init__.py", line 48, in > from .core.application import Application > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/application.py", line 25, in > from IPython.core.profiledir import ProfileDir, ProfileDirError > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", line 29, in > class ProfileDir(LoggingConfigurable): > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", line 52, in ProfileDir > `profile` option.""", > File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/traitlets/traitlets.py", line 421, in __init__ > DeprecationWarning, stacklevel=stacklevel) > DeprecationWarning: metadata {'config': True} was set from the constructor. Metadata should be set using the .tag() method, e.g., Int().tag(key1='value1', key2='value2') > > Can anyone offer a reason why this is, whether it has been reported before, or whether I can disable the astropy logger in some way (I just want astropy.units!)? > > For the record, I have the following versions: > > $ port installed | egrep " python27 | py27-ipython | py27-astropy " | grep "(active)" > py27-astropy @1.1.1_2 (active) > py27-ipython @4.1.2_0 (active) > python27 @2.7.11_2 (active) > > > Thanks in advance > Duncan > -- > Duncan Macleod > duncan.macleod at ligo.org > LIGO Data Grid systems development > Louisiana State University > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy Hi Duncan, I see the same issue with Python 2 and Macports. (not with Python 3 though, that?s why I hadn?t noticed it) Not sure what the cause or fix is. Could you please file an issue in the Astropy tracker with the description you gave above? https://github.com/astropy/astropy/issues Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.macleod at ligo.org Thu Apr 14 10:12:25 2016 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Thu, 14 Apr 2016 09:12:25 -0500 Subject: [AstroPy] DeprecationWarning from ipython [metadata was set from the constructor] In-Reply-To: <63D98099-9EB0-40DA-BF68-036B6470A401@googlemail.com> References: <63D98099-9EB0-40DA-BF68-036B6470A401@googlemail.com> Message-ID: Done: https://github.com/astropy/astropy/issues/4780 Thanks Christoph. On 14 April 2016 at 06:53, Christoph Deil wrote: > > On 14 Apr 2016, at 01:55, Duncan Macleod wrote: > > Hi all, > > With macports installs of python/ipython/astropy, for a while now I've > been getting a DeprecationWarning when import astropy, related to something > in ipython. Here is the traceback when I escalate it to an error: > > $ python -c "import warnings; warnings.simplefilter('error', > DeprecationWarning); import astropy" > Traceback (most recent call last): > File "", line 1, in > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/__init__.py", > line 284, in > from .logger import _init_log, _teardown_log > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/logger.py", > line 17, in > from .utils.console import color_print > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy/utils/console.py", > line 29, in > from IPython import get_ipython > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/__init__.py", > line 48, in > from .core.application import Application > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/application.py", > line 25, in > from IPython.core.profiledir import ProfileDir, ProfileDirError > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", > line 29, in > class ProfileDir(LoggingConfigurable): > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/profiledir.py", > line 52, in ProfileDir > `profile` option.""", > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/traitlets/traitlets.py", > line 421, in __init__ > DeprecationWarning, stacklevel=stacklevel) > DeprecationWarning: metadata {'config': True} was set from the > constructor. Metadata should be set using the .tag() method, e.g., > Int().tag(key1='value1', key2='value2') > > Can anyone offer a reason why this is, whether it has been reported > before, or whether I can disable the astropy logger in some way (I just > want astropy.units!)? > > For the record, I have the following versions: > > $ port installed | egrep " python27 | py27-ipython | py27-astropy " | grep > "(active)" > py27-astropy @1.1.1_2 (active) > py27-ipython @4.1.2_0 (active) > python27 @2.7.11_2 (active) > > > Thanks in advance > Duncan > -- > Duncan Macleod > duncan.macleod at ligo.org > LIGO Data Grid systems development > Louisiana State University > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > > Hi Duncan, > > I see the same issue with Python 2 and Macports. > (not with Python 3 though, that?s why I hadn?t noticed it) > > Not sure what the cause or fix is. > > Could you please file an issue in the Astropy tracker with the description > you gave above? > https://github.com/astropy/astropy/issues > > Christoph > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From evert.rol at gmail.com Fri Apr 15 02:49:54 2016 From: evert.rol at gmail.com (Evert Rol) Date: Fri, 15 Apr 2016 16:49:54 +1000 Subject: [AstroPy] writing/compressing fits files In-Reply-To: <570F750E.4080509@port.ac.uk> References: <570F6AAB.9000805@port.ac.uk> <570F750E.4080509@port.ac.uk> Message-ID: <34A5A88F-F5BE-4A30-9E81-E2DB0362D435@gmail.com> Kyle, here's a guess at what might be going on. I assume your file has multiple HDUs; at this file size, that makes sense. When astropy.io.fits encounters .gz filename to write to, it opens a gzip file as a file pointer, and then iteratees over the individual headers to write them to file. I guess this is not optimal for the gzip procedure: it likes to know about the full file to optimize the compression. I don't know how the Python gzip module is implemented, but it may be going back and forth to determine the compression after (or during) every write of a single HDU. That would explain why it takes so long. Or it just takes long because it gzips every HDU individually, and you're effectively seeing the overhead cost for every HDU. If there are quite a few HDUs and each HDU is compressed individually, then the compression is also less than optimal (gzip allows concatened gzip streams inside a file, but each of them will be less optimal than combined gzipped data). Of course, all this depends on the number of HDUs in your file; if that's just a few, this seems to be unlikely the cause. If you do have a large number of HDUs, you could test if this is the problem by creating a single file of about the same size, with just one HDU (probably random data for non-optimal compression; or perhaps you can use your actual data saved into a PrimaryHDU as an N+1 array). Then save a 1-element HDUList with the same (sized) data as a gzip FITS file, and see how fast that is (depending on the used data, the compressed size may or may not be around 14 MB). Cheers, Evert ps: I don't know CompImageHDU, but a quick glance suggests that this implements the compression of the data in a HDU. That might be somewhat faster (since it would have no option of going back and forth in the file itself), but with many HDUs, the compression is still less than optimal. > Hi all, > > I'm getting what feels like odd behavior in astropy. I have a file that is 386 MB when written uncompressed by astropy.io.fits.HDUList.writeto(). If I try to write the file as *.fits.gz, instead of *.fits, it is compressed down to 77 MB. The problem is that it takes ~2 minutes longer to write the compressed version. > > > Alternatively, I've just compressed the file using the gzip executable on my Mac: > > % gzip -V > Apple gzip 242 > > This compresses the file to 14 MB in a few seconds. > > > > I want to avoid system calls, so I also tried the following: > > >>> import gzip > >>> import shutil > >>> with open('test.fits', 'rb') as f_in: > ... with gzip.open('test.fits.gz', 'wb') as f_out: > ... shutil.copyfileobj(f_in, f_out) > ... > > pulled from here: > > https://docs.python.org/3/library/gzip.html#examples-of-usage > > This takes slightly longer than the system call, but not nearly as long as the astropy.io.fits.HDUList.writeto() command. And this call actually compresses the file down to 12 MB. So the above is my short-term work-around, but I'm wondering if there are better options. > > One option that was suggested to me was to use CompImageHDU, instead of ImageHDU. So I'll run some tests with that, as well. > > Thanks for any and all advice, > Kyle > > > > > -- > ------------------------------ > Kyle B. Westfall > > kyle.westfall at port.ac.uk > > > Institute of Cosmology > and Gravitation (ICG) > University of Portsmouth > Dennis Sciama Building > Burnaby Road > Portsmouth PO1 3FX > United Kingdom > > +44 (0)23 9284 5158 > > www.icg.port.ac.uk/~westfall/ > > ------------------------------ > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From kyle.westfall at port.ac.uk Fri Apr 15 03:42:32 2016 From: kyle.westfall at port.ac.uk (Kyle B. Westfall) Date: Fri, 15 Apr 2016 08:42:32 +0100 Subject: [AstroPy] writing/compressing fits files In-Reply-To: <34A5A88F-F5BE-4A30-9E81-E2DB0362D435@gmail.com> References: <570F6AAB.9000805@port.ac.uk> <570F750E.4080509@port.ac.uk> <34A5A88F-F5BE-4A30-9E81-E2DB0362D435@gmail.com> Message-ID: <57109B68.80803@port.ac.uk> Hi Evert, Thanks for the response. The file I'm trying to write has 10 extensions: - 3 ImageHDUs with (44,44,4653) float64 values - 2 ImageHDUs with (44,44,4563) int64 values - 1 ImageHDU with 4563 float64 values - 1 ImageHDU with (44,44) int64 values - 3 BinTableHDUs with various lengths and mostly float64 values There is a lot of redundancy in the 3D ImageHDUs, which is presumably why the compression is so large. Thanks, Kyle On 15/04/2016 07:49, Evert Rol wrote: > Kyle, here's a guess at what might be going on. > I assume your file has multiple HDUs; at this file size, that makes sense. > > When astropy.io.fits encounters .gz filename to write to, it opens a gzip file as a file pointer, and then iteratees over the individual headers to write them to file. > I guess this is not optimal for the gzip procedure: it likes to know about the full file to optimize the compression. > I don't know how the Python gzip module is implemented, but it may be going back and forth to determine the compression after (or during) every write of a single HDU. That would explain why it takes so long. Or it just takes long because it gzips every HDU individually, and you're effectively seeing the overhead cost for every HDU. > If there are quite a few HDUs and each HDU is compressed individually, then the compression is also less than optimal (gzip allows concatened gzip streams inside a file, but each of them will be less optimal than combined gzipped data). > > Of course, all this depends on the number of HDUs in your file; if that's just a few, this seems to be unlikely the cause. > If you do have a large number of HDUs, you could test if this is the problem by creating a single file of about the same size, with just one HDU (probably random data for non-optimal compression; or perhaps you can use your actual data saved into a PrimaryHDU as an N+1 array). Then save a 1-element HDUList with the same (sized) data as a gzip FITS file, and see how fast that is (depending on the used data, the compressed size may or may not be around 14 MB). > > Cheers, > > Evert > > ps: I don't know CompImageHDU, but a quick glance suggests that this implements the compression of the data in a HDU. That might be somewhat faster (since it would have no option of going back and forth in the file itself), but with many HDUs, the compression is still less than optimal. > > > >> Hi all, >> >> I'm getting what feels like odd behavior in astropy. I have a file that is 386 MB when written uncompressed by astropy.io.fits.HDUList.writeto(). If I try to write the file as *.fits.gz, instead of *.fits, it is compressed down to 77 MB. The problem is that it takes ~2 minutes longer to write the compressed version. >> >> >> Alternatively, I've just compressed the file using the gzip executable on my Mac: >> >> % gzip -V >> Apple gzip 242 >> >> This compresses the file to 14 MB in a few seconds. >> >> >> >> I want to avoid system calls, so I also tried the following: >> >>>>> import gzip >>>>> import shutil >>>>> with open('test.fits', 'rb') as f_in: >> ... with gzip.open('test.fits.gz', 'wb') as f_out: >> ... shutil.copyfileobj(f_in, f_out) >> ... >> >> pulled from here: >> >> https://docs.python.org/3/library/gzip.html#examples-of-usage >> >> This takes slightly longer than the system call, but not nearly as long as the astropy.io.fits.HDUList.writeto() command. And this call actually compresses the file down to 12 MB. So the above is my short-term work-around, but I'm wondering if there are better options. >> >> One option that was suggested to me was to use CompImageHDU, instead of ImageHDU. So I'll run some tests with that, as well. >> >> Thanks for any and all advice, >> Kyle >> >> >> >> >> -- >> ------------------------------ >> Kyle B. Westfall >> >> kyle.westfall at port.ac.uk >> >> >> Institute of Cosmology >> and Gravitation (ICG) >> University of Portsmouth >> Dennis Sciama Building >> Burnaby Road >> Portsmouth PO1 3FX >> United Kingdom >> >> +44 (0)23 9284 5158 >> >> www.icg.port.ac.uk/~westfall/ >> >> ------------------------------ >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy -- ------------------------------ Kyle B. Westfall kyle.westfall at port.ac.uk Institute of Cosmology and Gravitation (ICG) University of Portsmouth Dennis Sciama Building Burnaby Road Portsmouth PO1 3FX United Kingdom +44 (0)23 9284 5158 www.icg.port.ac.uk/~westfall/ ------------------------------ From thomas.boch at astro.unistra.fr Tue Apr 19 17:30:46 2016 From: thomas.boch at astro.unistra.fr (Thomas Boch) Date: Tue, 19 Apr 2016 23:30:46 +0200 Subject: [AstroPy] Creating a WCS from a list of (x, y, ra, dec) Message-ID: <5716A386.1050106@astro.unistra.fr> Hello, I have a list of pixel coordinates (x,y) and a list of corresponding celestial coordinates (ra, dec). I would like to compute the WCS astrometry solution matching my lists. Do you know any package that would fit my need? Cheers, Thomas From stuart at cadair.com Wed Apr 20 05:17:16 2016 From: stuart at cadair.com (Stuart Mumford) Date: Wed, 20 Apr 2016 10:17:16 +0100 Subject: [AstroPy] Creating a WCS from a list of (x, y, ra, dec) In-Reply-To: <5716A386.1050106@astro.unistra.fr> References: <5716A386.1050106@astro.unistra.fr> Message-ID: Hello, I believe this will do what you wish, but it appears not to be finished: https://github.com/spacetelescope/gwcs/pull/42 Stuart From wkerzendorf at gmail.com Wed Apr 20 05:38:08 2016 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Wed, 20 Apr 2016 09:38:08 +0000 Subject: [AstroPy] Creating a WCS from a list of (x, y, ra, dec) In-Reply-To: References: <5716A386.1050106@astro.unistra.fr> Message-ID: You can just use the current WCS implementation and use one of the scipy fitters to tweak the parameters. Cheers, Wolfgang On Wed, 20 Apr 2016 at 11:17, Stuart Mumford wrote: > Hello, > > I believe this will do what you wish, but it appears not to be finished: > https://github.com/spacetelescope/gwcs/pull/42 > > > Stuart > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -- Dr. Wolfgang E Kerzendorf ESO Fellow European Southern Observatory Karl-Schwarzschild Str. 2, 85748 Garching bei Muenchen, Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed Apr 20 07:25:22 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 20 Apr 2016 12:25:22 +0100 Subject: [AstroPy] Creating a WCS from a list of (x, y, ra, dec) In-Reply-To: References: <5716A386.1050106@astro.unistra.fr> Message-ID: Hi Wolfgang, Just out of curiosity, can you provide an example of how to do this in practice? Thanks, Tom On 20 April 2016 at 10:38, Wolfgang Kerzendorf wrote: > You can just use the current WCS implementation and use one of the scipy > fitters to tweak the parameters. > > Cheers, > Wolfgang > > On Wed, 20 Apr 2016 at 11:17, Stuart Mumford wrote: >> >> Hello, >> >> I believe this will do what you wish, but it appears not to be finished: >> https://github.com/spacetelescope/gwcs/pull/42 >> >> >> Stuart >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > > -- > Dr. Wolfgang E Kerzendorf > ESO Fellow > European Southern Observatory > Karl-Schwarzschild Str. 2, 85748 > Garching bei Muenchen, Germany > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > From wkerzendorf at gmail.com Wed Apr 20 07:45:38 2016 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Wed, 20 Apr 2016 11:45:38 +0000 Subject: [AstroPy] Creating a WCS from a list of (x, y, ra, dec) In-Reply-To: References: <5716A386.1050106@astro.unistra.fr>

Message-ID: So this is a Pseudo code that shows what I mean. It simple fiddles with the parameter until a minimum is reached. https://gist.github.com/wkerzendorf/eddf21e9ba1202a5e903a3ccd9a0268a Cheers, Wolfgang On Wed, Apr 20, 2016 at 1:25 PM Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > Hi Wolfgang, > > Just out of curiosity, can you provide an example of how to do this in > practice? > > Thanks, > Tom > > > > On 20 April 2016 at 10:38, Wolfgang Kerzendorf > wrote: > > You can just use the current WCS implementation and use one of the scipy > > fitters to tweak the parameters. > > > > Cheers, > > Wolfgang > > > > On Wed, 20 Apr 2016 at 11:17, Stuart Mumford wrote: > >> > >> Hello, > >> > >> I believe this will do what you wish, but it appears not to be finished: > >> https://github.com/spacetelescope/gwcs/pull/42 > >> > >> > >> Stuart > >> > >> _______________________________________________ > >> AstroPy mailing list > >> AstroPy at scipy.org > >> https://mail.scipy.org/mailman/listinfo/astropy > > > > -- > > Dr. Wolfgang E Kerzendorf > > ESO Fellow > > European Southern Observatory > > Karl-Schwarzschild Str. 2, 85748 > > Garching bei Muenchen, Germany > > > > _______________________________________________ > > 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 > -- Dr. Wolfgang E Kerzendorf ESO Fellow European Southern Observatory Karl-Schwarzschild Str. 2, 85748 Garching bei Muenchen, Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.p.singer at nasa.gov Thu Apr 28 10:00:42 2016 From: leo.p.singer at nasa.gov (Singer, Leo P. (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION]) Date: Thu, 28 Apr 2016 14:00:42 +0000 Subject: [AstroPy] Best practices for Python sample code in journal articles Message-ID: Hi, I am working on an ApJ submission that I would like to pair with a supplement paper that contains (among other things) some Astropy-based sample/tutorial Python code to acquaint the reader with an accompanying data release. Are there any established best practices for including Python in journal articles? Should code and output be presented docstring-style or should it look like an IPython session? Does anyone have nice examples of astronomy papers that include supplemental IPython notebooks? If anyone is interested, this is the article and data release: https://arxiv.org/abs/1603.07333 http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ Cheers, Leo Dr. Leo P. Singer NASA Postdoctoral Program Fellow Goddard Space Flight Center 8800 Greenbelt Rd., B34, Room S239 Greenbelt, MD 20771 From bovy at astro.utoronto.ca Thu Apr 28 10:12:39 2016 From: bovy at astro.utoronto.ca (Jo Bovy) Date: Thu, 28 Apr 2016 10:12:39 -0400 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: References: Message-ID: Hi Leo, I'm not sure this is exactly what you're looking for, but in my paper on galpy, I used minted to typeset Python code as figures (and some inline). The only downside is that arXiv doesn't allow this, because you need to run latex with -shell-escape (I got my paper on arXiv in a very hacky way). ApJS didn't have any problems with getting this in print. Best, Jo On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] wrote: > Hi, > > I am working on an ApJ submission that I would like to pair with a > supplement paper that contains (among other things) some Astropy-based > sample/tutorial Python code to acquaint the reader with an accompanying > data release. Are there any established best practices for including Python > in journal articles? Should code and output be presented docstring-style or > should it look like an IPython session? Does anyone have nice examples of > astronomy papers that include supplemental IPython notebooks? > > If anyone is interested, this is the article and data release: > https://arxiv.org/abs/1603.07333 > http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ > > Cheers, > Leo > > > Dr. Leo P. Singer > NASA Postdoctoral Program Fellow > Goddard Space Flight Center > 8800 Greenbelt Rd., B34, Room S239 > Greenbelt, MD 20771 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.gullikson at gmail.com Thu Apr 28 10:51:20 2016 From: kevin.gullikson at gmail.com (Kevin Gullikson) Date: Thu, 28 Apr 2016 14:51:20 +0000 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: References: Message-ID: Leo, I just submitted a paper that links to my github with a bunch of jupyter notebooks with the analysis. The journal people mentioned that they are actually working on some way to host the notebooks on their website or something, but for now I think linking to your github is probably the way to go. If you want to show code in the actual article, I've heard minted is a good option but never used it myself. On Thu, Apr 28, 2016 at 9:13 AM Jo Bovy wrote: > Hi Leo, > > I'm not sure this is exactly what you're looking for, but in my paper > on galpy, I used > minted to typeset Python code as > figures (and some inline). The only downside is that arXiv doesn't allow > this, because you need to run latex with -shell-escape (I got my paper on > arXiv in a very hacky way). ApJS didn't have any problems with getting this > in print. > > Best, > > Jo > > On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. (GSFC-661.0)[UNIVERSITIES > SPACE RESEARCH ASSOCIATION] wrote: > >> Hi, >> >> I am working on an ApJ submission that I would like to pair with a >> supplement paper that contains (among other things) some Astropy-based >> sample/tutorial Python code to acquaint the reader with an accompanying >> data release. Are there any established best practices for including Python >> in journal articles? Should code and output be presented docstring-style or >> should it look like an IPython session? Does anyone have nice examples of >> astronomy papers that include supplemental IPython notebooks? >> >> If anyone is interested, this is the article and data release: >> https://arxiv.org/abs/1603.07333 >> http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ >> >> Cheers, >> Leo >> >> >> Dr. Leo P. Singer >> NASA Postdoctoral Program Fellow >> Goddard Space Flight Center >> 8800 Greenbelt Rd., B34, Room S239 >> Greenbelt, MD 20771 >> _______________________________________________ >> 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 > -- Kevin Gullikson PhD Candidate University of Texas Astronomy -------------- next part -------------- An HTML attachment was scrubbed... URL: From august.fly at gmail.com Thu Apr 28 11:07:23 2016 From: august.fly at gmail.com (August (Gus) Muench) Date: Thu, 28 Apr 2016 11:07:23 -0400 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: References: Message-ID: As one of the ApJ/AJ journal data scientists, I just want to weigh in that our view is that notebooks should be presented in a narrative form and not just a supplementary file linked to the final articles. Until we can support that fully formed narrative form, which we are investigating, it seems like the best option is to host them in your github repo as Kevin suggested and does so well for his paper. Another example that I have to share is from Mingarelli et al. 2015: https://ui.adsabs.harvard.edu/#abs/2015ApJ...814L..20M/abstract and https://github.com/ChiaraMingarelli/blackHoleBatteryFRBs/blob/master/transient.ipynb - gus ---------- August (Gus) Muench august.fly at gmail.com @augustmuench On Thu, Apr 28, 2016 at 10:51 AM, Kevin Gullikson wrote: > Leo, > > I just submitted a paper that links to > my github with a bunch > of jupyter notebooks with the analysis. The journal people mentioned that > they are actually working on some way to host the notebooks on their > website or something, but for now I think linking to your github is > probably the way to go. If you want to show code in the actual article, > I've heard minted is a good option but never used it myself. > > On Thu, Apr 28, 2016 at 9:13 AM Jo Bovy wrote: > >> Hi Leo, >> >> I'm not sure this is exactly what you're looking for, but in my paper >> on galpy, I used >> minted to typeset Python code as >> figures (and some inline). The only downside is that arXiv doesn't allow >> this, because you need to run latex with -shell-escape (I got my paper >> on arXiv in a very hacky way). ApJS didn't have any problems with getting >> this in print. >> >> Best, >> >> Jo >> >> On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. >> (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] < >> leo.p.singer at nasa.gov> wrote: >> >>> Hi, >>> >>> I am working on an ApJ submission that I would like to pair with a >>> supplement paper that contains (among other things) some Astropy-based >>> sample/tutorial Python code to acquaint the reader with an accompanying >>> data release. Are there any established best practices for including Python >>> in journal articles? Should code and output be presented docstring-style or >>> should it look like an IPython session? Does anyone have nice examples of >>> astronomy papers that include supplemental IPython notebooks? >>> >>> If anyone is interested, this is the article and data release: >>> https://arxiv.org/abs/1603.07333 >>> http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ >>> >>> Cheers, >>> Leo >>> >>> >>> Dr. Leo P. Singer >>> NASA Postdoctoral Program Fellow >>> Goddard Space Flight Center >>> 8800 Greenbelt Rd., B34, Room S239 >>> Greenbelt, MD 20771 >>> _______________________________________________ >>> 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 >> > -- > Kevin Gullikson > PhD Candidate > University of Texas Astronomy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From micheleb at uvic.ca Thu Apr 28 11:17:52 2016 From: micheleb at uvic.ca (Michele Bannister) Date: Thu, 28 Apr 2016 15:17:52 +0000 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: References: Message-ID: <9F4012D7-F9FC-4A63-AF6D-CD9DB69E9619@uvic.ca> Wes Fraser put together a supplemental iPython notebook for our recent photometry-technique paper: http://arxiv.org/abs/1604.00031 https://github.com/fraserw/trippy https://github.com/fraserw/trippy/blob/master/tutorial/trippytutorial.ipynb Cheers, Michele. ------------------------------------------------------ Dr Michele Bannister Postdoctoral Fellow, Outer Solar System Origins Survey Dept. of Physics and Astronomy, University of Victoria Victoria BC, Canada http://www.astro.uvic.ca/~micheleb/ http://www.ossos-survey.org/ On Apr 28, 2016, at 7:00 AM, Singer, Leo P. (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] > wrote: Hi, I am working on an ApJ submission that I would like to pair with a supplement paper that contains (among other things) some Astropy-based sample/tutorial Python code to acquaint the reader with an accompanying data release. Are there any established best practices for including Python in journal articles? Should code and output be presented docstring-style or should it look like an IPython session? Does anyone have nice examples of astronomy papers that include supplemental IPython notebooks? If anyone is interested, this is the article and data release: https://arxiv.org/abs/1603.07333 http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ Cheers, Leo Dr. Leo P. Singer NASA Postdoctoral Program Fellow Goddard Space Flight Center 8800 Greenbelt Rd., B34, Room S239 Greenbelt, MD 20771 _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cadair.com Thu Apr 28 11:42:45 2016 From: stuart at cadair.com (Stuart Mumford) Date: Thu, 28 Apr 2016 16:42:45 +0100 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: References: Message-ID: <7c851dd5-c510-a918-0735-e412ab88fcea@cadair.com> Hi Jo, FWIW, I had this minted + Arxiv issue when I submitted the SunPy paper, what I did in the end was swap to the much more boring looking `listings` package for ArXiV and use minted for everything else. https://github.com/sunpy/sunpy-0.4-paper/commit/d91dd8809f469e7a4295c317feeded41aeca17c8 Stuart On 28/04/16 15:12, Jo Bovy wrote: > Hi Leo, > > I'm not sure this is exactly what you're looking for, but in my paper > on galpy, I used > minted to typeset Python code as > figures (and some inline). The only downside is that arXiv doesn't > allow this, because you need to run latex with -shell-escape (I got my > paper on arXiv in a very hacky way). ApJS didn't have any problems > with getting this in print. > > Best, > > Jo > > On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. > (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] > > wrote: > > Hi, > > I am working on an ApJ submission that I would like to pair with a > supplement paper that contains (among other things) some > Astropy-based sample/tutorial Python code to acquaint the reader > with an accompanying data release. Are there any established best > practices for including Python in journal articles? Should code > and output be presented docstring-style or should it look like an > IPython session? Does anyone have nice examples of astronomy > papers that include supplemental IPython notebooks? > > If anyone is interested, this is the article and data release: > https://arxiv.org/abs/1603.07333 > http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ > > Cheers, > Leo > > > Dr. Leo P. Singer > NASA Postdoctoral Program Fellow > Goddard Space Flight Center > 8800 Greenbelt Rd., B34, Room S239 > Greenbelt, MD 20771 > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trive at astro.su.se Thu Apr 28 12:01:29 2016 From: trive at astro.su.se (=?UTF-8?Q?Th=c3=b8ger_Emil_Rivera-Thorsen?=) Date: Thu, 28 Apr 2016 18:01:29 +0200 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: <7c851dd5-c510-a918-0735-e412ab88fcea@cadair.com> References: <7c851dd5-c510-a918-0735-e412ab88fcea@cadair.com> Message-ID: <572233D9.6010201@astro.su.se> PythonTeX uses the Fancyvrb package for syntax highlighting. The output is not as nice as minted, but nicer than listings. Og course, PythonTeX requires one more step in the production, as it is a filter that runs on your document and either evaluates, typesets or both to your inline code, then outputs it as a .tex file to be typeset the normal way. But it might be a good solution in a case like this, as I believe it doesn't require the special settings that minted does. On 04/28/2016 05:42 PM, Stuart Mumford wrote: > > Hi Jo, > > FWIW, I had this minted + Arxiv issue when I submitted the SunPy > paper, what I did in the end was swap to the much more boring looking > `listings` package for ArXiV and use minted for everything else. > > https://github.com/sunpy/sunpy-0.4-paper/commit/d91dd8809f469e7a4295c317feeded41aeca17c8 > > Stuart > > On 28/04/16 15:12, Jo Bovy wrote: >> Hi Leo, >> >> I'm not sure this is exactly what you're looking for, but in my paper >> on galpy, I used >> minted to typeset Python code as >> figures (and some inline). The only downside is that arXiv doesn't >> allow this, because you need to run latex with -shell-escape (I got >> my paper on arXiv in a very hacky way). ApJS didn't have any problems >> with getting this in print. >> >> Best, >> >> Jo >> >> On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. >> (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] >> > wrote: >> >> Hi, >> >> I am working on an ApJ submission that I would like to pair with >> a supplement paper that contains (among other things) some >> Astropy-based sample/tutorial Python code to acquaint the reader >> with an accompanying data release. Are there any established best >> practices for including Python in journal articles? Should code >> and output be presented docstring-style or should it look like an >> IPython session? Does anyone have nice examples of astronomy >> papers that include supplemental IPython notebooks? >> >> If anyone is interested, this is the article and data release: >> https://arxiv.org/abs/1603.07333 >> http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ >> >> Cheers, >> Leo >> >> >> Dr. Leo P. Singer >> NASA Postdoctoral Program Fellow >> Goddard Space Flight Center >> 8800 Greenbelt Rd., B34, Room S239 >> Greenbelt, MD 20771 >> _______________________________________________ >> 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 -- ---- Th?ger Emil Rivera-Thorsen Astrophysicist, Ph.D. candidate Stockholm University, dept. of Astronomy Sweden -------------- next part -------------- An HTML attachment was scrubbed... URL: From hack at stsci.edu Fri Apr 29 00:05:16 2016 From: hack at stsci.edu (Warren Hack) Date: Fri, 29 Apr 2016 04:05:16 +0000 Subject: [AstroPy] New Version of STScI Science Software Available Message-ID: <165F8DF56585A44E80F820D672C94FDC11C983A5@EXCHMAIL1.stsci.edu> ******************************************************** SSB Science Software NOW AVAILABLE ******************************************************** The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of AstroConda, a replacement for the previously released Ureka environment along with updates to many of the packages installed as part of the STScI_Python releases. Full details on the new software environment and how to install it can be found at: http://astroconda.readthedocs.io ----------- SSBX ----------- The transition to AstroConda had one unexpected consequence that only appeared the week of April 25; specifically, the Ureka-based SSBX environment can no longer be installed. We have two options available for those who have relied on the SSBX environment: * Start using the (less stable) Ureka SSBDEV environment - Instructions on how to install and use this environment can be found at: http://ssb.stsci.edu/ssb_software.shtml * Transition to using AstroConda, our Conda-based Python environment that replaces the Ureka environment - The equivalent of SSBX can be maintained by following the instructions for "Updating All Packages" as described on: http://astroconda.readthedocs.io/en/latest/updating.html We regret the problems this unexpectedly forced transition has caused for many in the STScI community, but all the lessons learned from providing and maintaining Ureka over the last few years have been applied to our new distribution. AstroConda is more stable, and will not disappear like Ureka's SSBX environment did; as problems with any package will simply result in a lack of updates for that package until the problems are resolved by the developer. ----------- IRAF ----------- We continue to provide IRAF as a component of this new AstroConda environment. However, more modern computer environments have placed increasing pressure on our ability to build IRAF for new operating systems. The current installation includes IRAF v2.16.1 built under OS X 10.6 (for the Mac install) and under Red Hat Enterprise Linux 5 (for the Linux install). Instructions are provided to allow you to install IRAF under the Python 2.7 environment: http://astroconda.readthedocs.io/en/latest/faq.html These binaries, however, are known to be incompatible with some newer systems based on reports from users; specific configurations that produce these problems are not clearly identified, but (as one example only) a Linux system with an XFS disk partition larger than 2Tb has been seen to be incompatible with IRAF. Should you find this version of IRAF (should you choose to install it) does not work, we have developed a Virtual Machine install for all the IRAF-related software (contact us for details should you need this solution). We plan to enhance the IRAF environment so it may be installed in a more modular fashion using Conda (under AstroConda). This enables Gemini and other contributors relying on IRAF to provide updates without requiring re-installation of the entire IRAF environment. Unfortunately, the non-VM/native installation of IRAF can only be supported for as long as we are able to build and run IRAF, which we anticipate will be possible for at least the next year or two barring any unforeseen OS/compiler changes. ----------- Python Support ----------- The AstroConda environment provides installations for Python 2.7, Python 3.4, and Python 3.5. Unfortunately, at this time, the IRAF installation can only be supported under Python 2.7. ----------- Installation ----------- Full installation instructions, and explanations, can be found on the AstroConda web page. However, should you wish to jump head-long into the new Conda-based environment, you can follow these simple steps: 1. Install Anaconda locally on your system 2. Start a BASH shell - the entire conda environment inextricably relies on BASH 3. Point to our AstroConda channel using: conda config --add channels http://ssb.stsci.edu/astroconda 3. Install the software from the AstroConda channel using: conda create -n astroconda stsci 4. Start it up (under the BASH command shell) with: source activate astroconda Please go the web page for full details on how to work best with this environment. ----------- Support ----------- Questions about this installation and the STScI-based and Gemini-based software included in this environment can be directed to: * EMAIL: help at stsci.edu * PHONE: 410-338-4400 * Web: # AstroConda: http://astroconda.readthedocs.io # For stsci_python documentation: http://ssb.stsci.edu/doc/stsci_python_dev/ ================ Updated Software ================ The full set of release notes for all the STScI software included in this installation can be found at: http://astroconda.readthedocs.io/en/latest/release_notes.html These notes provide expanded details for updates and bug fixes implemented for the following major packages. Please see the web page for the full set of release notes. ----------- Dependencies and SciPy ----------- An effort has been made to start replacing internal dependencies on stsci.* packages where equivalents are available through SciPy. One example would be stsci.convolve, which was an early fork of scipy's convolve package, with the stsci_python code being modified to use scipy instead. As a result, we will start deprecating some of these packages in future releases for eventual removal from our distribution. After all, who needs our version when a better scipy version exists? The names of those deprecated packages will be clearly noted when we start this transition, and we will not remove these packages for at least 6 months after we announce their deprecation. ----------- CALWF3 ----------- CALWF3 Version 3.3 applies instrument calibrations to HST/WFC3 data. This version includes the following updates and bug fixes (and more...): * Addition of a new processing step, FLUXCORR, to the UVIS pipeline * Addition of CTE correction for full-frame UVIS data * sink pixel detection is now performed in the UVIS pipeline for full-frame UVIS images * CRCORR processing turned off by default for IR SCAN data * assorted bug fixes (including memory leaks) ----------- CALACS ----------- CALACS Version v8.3.3 applies instrument calibrations to HST/ACS data. This version includes the following updates and bug fixes (and more): * Added support for 2K subarrays in PCTECORR * Improved temporary file handling. * Added support for very long input list for ACSREJ. ----------- CALCOS ----------- CALCOS Version 3.1.3 applies instrument calibrations to HST/COS data. This version includes the following updates: * Revisions needed to allow calcos to run under Python 3 * Allow flux extraction from 0 to 100% * Ignore DQ flag DQ_GAIN_SAG_HOLE in background regions in profile alignment step * Shift DQ data array the same as data array in TRCECORR and ALGNCORR steps of calcos * Fix up x1d output for boxcar option * CalCOS should print warnings for certain conditions of HOTSPOT calibration * Events in COS data should now be flagged using the SPOTTAB ----------- DrizzlePac ----------- The DrizzlePac package, a component of the STScI_Python environment, implements the distortion correction and image combination algorithm for HST data. This release of DrizzlePac Version 2 updates the software to provide a number of new capabilities and bug fixes; including, * support for automated mosaic building * improved sky matching * support for the simplified/improved ACS time-dependent distortion correction * allowing undistorted non-HST images to be used as references for aligning HST images * better capability for aligning images from different HST cameras * ability to run under Python 2.7 and Python 3.5 A full set of release notes can be found online at the DrizzlePac home page at: http://drizzlepac.stsci.edu ----------- PySynphot ----------- This release includes pysynphot v0.9.8.2. The following changes (and a little more) have been made since the last release of v0.9.7 (Oct 2015): * Updated spectra data including ACS wavecat and Vega reference spectrum. * Replaced PyFITS dependency with astropy.io.fits. * Added a lot of documentation and tutorials From stuart at cadair.com Fri Apr 29 05:45:40 2016 From: stuart at cadair.com (Stuart Mumford) Date: Fri, 29 Apr 2016 10:45:40 +0100 Subject: [AstroPy] Best practices for Python sample code in journal articles In-Reply-To: <572233D9.6010201@astro.su.se> References: <7c851dd5-c510-a918-0735-e412ab88fcea@cadair.com> <572233D9.6010201@astro.su.se> Message-ID: <89f2d5a1-5356-c999-7242-487f4d096158@cadair.com> Interesting, I had not considered using the PythonTex > DePythonTeX > Syntax highlighting approach for arxiv upload. I think that the maintainer of PythonTeX took over minted a while ago, so maybe it will start using minted in the future?! One the topic of PythonTeX, if you use it, you might find this library I wrote, while not writing my Thesis useful: http://texfigure.readthedocs.io/en/latest/ (There is not a lot of documentation yet). Stuart On 28/04/16 17:01, Th?ger Emil Rivera-Thorsen wrote: > PythonTeX uses the Fancyvrb package for syntax highlighting. The > output is not as nice as minted, but nicer than listings. > > Og course, PythonTeX requires one more step in the production, as it > is a filter that runs on your document and either evaluates, typesets > or both to your inline code, then outputs it as a .tex file to be > typeset the normal way. But it might be a good solution in a case like > this, as I believe it doesn't require the special settings that minted > does. > > > > On 04/28/2016 05:42 PM, Stuart Mumford wrote: >> >> Hi Jo, >> >> FWIW, I had this minted + Arxiv issue when I submitted the SunPy >> paper, what I did in the end was swap to the much more boring looking >> `listings` package for ArXiV and use minted for everything else. >> >> https://github.com/sunpy/sunpy-0.4-paper/commit/d91dd8809f469e7a4295c317feeded41aeca17c8 >> >> Stuart >> >> On 28/04/16 15:12, Jo Bovy wrote: >>> Hi Leo, >>> >>> I'm not sure this is exactly what you're looking for, but in my >>> paper on galpy, >>> I used minted to typeset Python >>> code as figures (and some inline). The only downside is that arXiv >>> doesn't allow this, because you need to run latex with -shell-escape >>> (I got my paper on arXiv in a very hacky way). ApJS didn't have any >>> problems with getting this in print. >>> >>> Best, >>> >>> Jo >>> >>> On Thu, Apr 28, 2016 at 10:00 AM, Singer, Leo P. >>> (GSFC-661.0)[UNIVERSITIES SPACE RESEARCH ASSOCIATION] >>> > wrote: >>> >>> Hi, >>> >>> I am working on an ApJ submission that I would like to pair with >>> a supplement paper that contains (among other things) some >>> Astropy-based sample/tutorial Python code to acquaint the reader >>> with an accompanying data release. Are there any established >>> best practices for including Python in journal articles? Should >>> code and output be presented docstring-style or should it look >>> like an IPython session? Does anyone have nice examples of >>> astronomy papers that include supplemental IPython notebooks? >>> >>> If anyone is interested, this is the article and data release: >>> https://arxiv.org/abs/1603.07333 >>> http://asd.gsfc.nasa.gov/Leo.Singer/going-the-distance/ >>> >>> Cheers, >>> Leo >>> >>> >>> Dr. Leo P. Singer >>> NASA Postdoctoral Program Fellow >>> Goddard Space Flight Center >>> 8800 Greenbelt Rd., B34, Room S239 >>> Greenbelt, MD 20771 >>> _______________________________________________ >>> 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 > > -- > ---- > > Th?ger Emil Rivera-Thorsen > Astrophysicist, Ph.D. candidate > Stockholm University, dept. of Astronomy > Sweden > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: