From thomas.robitaille at gmail.com Tue Feb 3 08:22:35 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 3 Feb 2015 14:22:35 +0100 Subject: [AstroPy] Astropy 1.0rc1 on conda Message-ID: Hi everyone, Erik sent an email last week regarding the Astropy 1.0 release candidate - if anyone is using conda and would like to try out the release candidate easily, you can now do: conda install -c astrofrog astropy=1.0rc1 and as a reminder, the list of major new features/changes is provided here: http://astropy.readthedocs.org/en/v1.0rc1/whatsnew/1.0.html If you have issues installing the release candidate, please contact me directly off-list. If you have issues using the release candidate, then please report all issues here: https://github.com/astropy/astropy/issues Thanks! Tom From duncan.macleod at ligo.org Tue Feb 3 16:09:26 2015 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Tue, 3 Feb 2015 15:09:26 -0600 Subject: [AstroPy] How can I add another name to a registered unit? Message-ID: <2B0BD1C2-CFB8-492A-BC04-55C0122B28DF@ligo.org> Hi all, I?m wondering how to add another name to an already registered unit. The example I have is a data file containing the unit string ?Degrees_F? - meaning Fahrenheit. I understand I can enable a new unit called ?Degrees_F? that represents the original ?deg_F/Fahrenheit' unit from units.imperial, but what I?d really like to do is just register the string ?Degrees_F? as another name for ?deg_F?, rather than an equivalent unit. In the end I?d like to see the following: >>> units.Unit(?Degrees_F?) Unit(?deg_F?) Is this possible? Thanks Duncan -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjswift at gmail.com Wed Feb 4 03:05:26 2015 From: bjswift at gmail.com (Brandon Swift) Date: Wed, 4 Feb 2015 01:05:26 -0700 Subject: [AstroPy] JointFitter help Message-ID: Hi all, I'm a pretty new user here, but I recognize a lot of names from throughout the years on the active developer lists I'm looking for help in the use of the JointFitter class (astropy v0.4.4 downloaded via pip), and I can't find an example of use anywhere online. Alternatively, if someone could please point me to a relevant thread in these mailing list archives, which I don't see how to search, that could also be helpful. What I'm trying to do is fit raw RGB pixel data from a digital camera to a gaussian. Because the pixels for each color are mixed together, but they should all share the same mean/stddev/theta and have different amplitudes (because of differing color response), I think the JointFitter class sounds like the way to go for what I'm trying to do. I'm looking at the source, and can't really tell precisely what it wants from me (and I think the docstring is lying a bit). Thanks, and cheers. Brandon Swift From dencheva at stsci.edu Wed Feb 4 09:38:44 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Wed, 4 Feb 2015 14:38:44 +0000 Subject: [AstroPy] JointFitter help In-Reply-To: References: Message-ID: <0153364C9F56D944B0A795780ECF88DF6775226F@EXCHMAIL2.stsci.edu> Hi Brandon, Can you explain a bit more how you are doing the fitting? It sounds like you are fitting a 2D Gaussian but I'm not sure what the data is? What are the inputs to each model? Cheers, Nadia ________________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Brandon Swift [bjswift at gmail.com] Sent: Wednesday, February 04, 2015 3:05 AM To: astropy at scipy.org Subject: [AstroPy] JointFitter help Hi all, I'm a pretty new user here, but I recognize a lot of names from throughout the years on the active developer lists I'm looking for help in the use of the JointFitter class (astropy v0.4.4 downloaded via pip), and I can't find an example of use anywhere online. Alternatively, if someone could please point me to a relevant thread in these mailing list archives, which I don't see how to search, that could also be helpful. What I'm trying to do is fit raw RGB pixel data from a digital camera to a gaussian. Because the pixels for each color are mixed together, but they should all share the same mean/stddev/theta and have different amplitudes (because of differing color response), I think the JointFitter class sounds like the way to go for what I'm trying to do. I'm looking at the source, and can't really tell precisely what it wants from me (and I think the docstring is lying a bit). Thanks, and cheers. Brandon Swift _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy From bjswift at gmail.com Wed Feb 4 14:22:00 2015 From: bjswift at gmail.com (Brandon Swift) Date: Wed, 4 Feb 2015 12:22:00 -0700 Subject: [AstroPy] JointFitter help Message-ID: Sure thing, Nadia. In case you/someone else doesn't know, a regular digital camera has an alternating color filter pattern over the CMOS detectors like this http://en.wikipedia.org/wiki/Bayer_filter. I am trying to take a picture of a point-like source that has contrast to the surrounding background, and nail down the centroid of that as well (and as fast) as I reasonably can. I figure that using the raw pixel data instead of using the demosaiced and otherwise-processed JPEG that normally comes out the back end of the camera will help. So, yes, I'm trying to fit a 2D gaussian to R, G, and B channels simultaneously, each of which has their own checkerboard-like mask, like in the attached image/below. ? When doing the gaussian fit, the x/y_mean should be tied together between the 3 channels, and the x/y_stddev and theta should also be tied (to within chromatic effects of the lens), but the amplitude of each channel should be allowed to be different. Which all sounds very much like the example use-case described in the docstring of the JointFitter class! I had moderate success with fitting individual channels (convergence was sometimes flaky) and was about to try writing a custom 'Gaussian2Dx3' model class when I ran across JointFItter and thought it seemed like it would do nicely. Right now, I'm doing something like this, which isn't working right because I don't know how the inputs need to go but I've been trying to guess from the source code and errors generated: -------------------------------------------------------------------------------------------------------- ## Define reasonable ranges for the fitting parameters (data centered at 0,0 pixel) gaussbounds = {'amplitude': [0.2, 0.8], 'x_mean': [-2.0, 2.0], 'y_mean': [-2.0, 2.0], 'x_stddev': [0.2, 1.5], 'y_stddev': [0.2, 1.5]} ## Create a model instance for each channel gaussR = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) gaussG = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) gaussB = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) ## Trying to get these other inputs structured correctly to make JointFitter.__init__() ## complete smoothly. jointpars = {'gaussR': [gaussR.x_mean, gaussR.y_mean, gaussR.x_stddev, gaussR.y_stddev, gaussR.theta], 'gaussG': [gaussG.x_mean, gaussG.y_mean, gaussG.x_stddev, gaussG.y_stddev, gaussG.theta], 'gaussB': [gaussB.x_mean, gaussB.y_mean, gaussB.x_stddev, gaussB.y_stddev, gaussB.theta] } initvals = [0.0, 0.0, 0.4, 0.4, 0.0] ## Here's what I'm feeding it, finally. I'm out of ideas! jointRGB = fitting.JointFitter({'gaussR':gaussR, 'gaussG':gaussG, 'gaussB':gaussB}, jointpars, initvals) -------------------------------------------------------------------------------------------------------- Anyway, many thanks in advance for the help! Cheers, Brandon > Date: Wed, 4 Feb 2015 14:38:44 +0000 > From: Nadezhda Dencheva > Subject: Re: [AstroPy] JointFitter help > > Hi Brandon, > > Can you explain a bit more how you are doing the fitting? > It sounds like you are fitting a 2D Gaussian but I'm not sure what the data is? > What are the inputs to each model? > > Cheers, > Nadia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rgbspot.png Type: image/png Size: 1980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rgbspot.png Type: image/png Size: 1980 bytes Desc: not available URL: From npkuin at gmail.com Wed Feb 4 16:21:42 2015 From: npkuin at gmail.com (Paul Kuin) Date: Wed, 4 Feb 2015 21:21:42 +0000 Subject: [AstroPy] JointFitter help In-Reply-To: References: Message-ID: to quickly get a centroid, you can also use a simple weighted mean I think it is like, say z(x,y) is the value of the pixel, posx = sum(x*z(x,y))/sum(x) posy = sum(y*z(x,y))/sum(y) On Wed, Feb 4, 2015 at 7:22 PM, Brandon Swift wrote: > Sure thing, Nadia. In case you/someone else doesn't know, a regular > digital camera has an alternating color filter pattern over the CMOS > detectors like this http://en.wikipedia.org/wiki/Bayer_filter. I am > trying to take a picture of a point-like source that has contrast to the > surrounding background, and nail down the centroid of that as well (and as > fast) as I reasonably can. I figure that using the raw pixel data instead > of using the demosaiced and otherwise-processed JPEG that normally comes > out the back end of the camera will help. > > So, yes, I'm trying to fit a 2D gaussian to R, G, and B channels > simultaneously, each of which has their own checkerboard-like mask, like in > the attached image/below. > > > ? > When doing the gaussian fit, the x/y_mean should be tied together between > the 3 channels, and the x/y_stddev and theta should also be tied (to within > chromatic effects of the lens), but the amplitude of each channel should be > allowed to be different. Which all sounds very much like the example > use-case described in the docstring of the JointFitter class! > > I had moderate success with fitting individual channels (convergence was > sometimes flaky) and was about to try writing a custom 'Gaussian2Dx3' model > class when I ran across JointFItter and thought it seemed like it would do > nicely. Right now, I'm doing something like this, which isn't working right > because I don't know how the inputs need to go but I've been trying to > guess from the source code and errors generated: > > > -------------------------------------------------------------------------------------------------------- > ## Define reasonable ranges for the fitting parameters (data centered at > 0,0 pixel) > gaussbounds = {'amplitude': [0.2, 0.8], 'x_mean': [-2.0, 2.0], > 'y_mean': [-2.0, 2.0], 'x_stddev': [0.2, 1.5], 'y_stddev': [0.2, 1.5]} > > ## Create a model instance for each channel > gaussR = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) > gaussG = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) > gaussB = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) > > ## Trying to get these other inputs structured correctly to make > JointFitter.__init__() > ## complete smoothly. > jointpars = {'gaussR': [gaussR.x_mean, gaussR.y_mean, gaussR.x_stddev, > gaussR.y_stddev, gaussR.theta], > 'gaussG': [gaussG.x_mean, gaussG.y_mean, gaussG.x_stddev, > gaussG.y_stddev, gaussG.theta], > 'gaussB': [gaussB.x_mean, gaussB.y_mean, gaussB.x_stddev, > gaussB.y_stddev, gaussB.theta] } > initvals = [0.0, 0.0, 0.4, 0.4, 0.0] > > ## Here's what I'm feeding it, finally. I'm out of ideas! > jointRGB = fitting.JointFitter({'gaussR':gaussR, 'gaussG':gaussG, > 'gaussB':gaussB}, jointpars, initvals) > > -------------------------------------------------------------------------------------------------------- > > Anyway, many thanks in advance for the help! Cheers, > Brandon > > > > > Date: Wed, 4 Feb 2015 14:38:44 +0000 > > From: Nadezhda Dencheva > > Subject: Re: [AstroPy] JointFitter help > > > > Hi Brandon, > > > > Can you explain a bit more how you are doing the fitting? > > It sounds like you are fitting a 2D Gaussian but I'm not sure what the > data is? > > What are the inputs to each model? > > > > Cheers, > > Nadia > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rgbspot.png Type: image/png Size: 1980 bytes Desc: not available URL: From dencheva at stsci.edu Thu Feb 5 08:45:13 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 5 Feb 2015 13:45:13 +0000 Subject: [AstroPy] JointFitter help In-Reply-To: References: , Message-ID: <0153364C9F56D944B0A795780ECF88DF677523A9@EXCHMAIL2.stsci.edu> Hi Brandon, Thanks for posting. You are right, this is a use case for the JointFitter but there's a bug. I'll see if this can be easily fixed. Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Paul Kuin [npkuin at gmail.com] Sent: Wednesday, February 04, 2015 4:21 PM To: Astronomical Python mailing list Subject: Re: [AstroPy] JointFitter help to quickly get a centroid, you can also use a simple weighted mean I think it is like, say z(x,y) is the value of the pixel, posx = sum(x*z(x,y))/sum(x) posy = sum(y*z(x,y))/sum(y) On Wed, Feb 4, 2015 at 7:22 PM, Brandon Swift > wrote: Sure thing, Nadia. In case you/someone else doesn't know, a regular digital camera has an alternating color filter pattern over the CMOS detectors like this http://en.wikipedia.org/wiki/Bayer_filter. I am trying to take a picture of a point-like source that has contrast to the surrounding background, and nail down the centroid of that as well (and as fast) as I reasonably can. I figure that using the raw pixel data instead of using the demosaiced and otherwise-processed JPEG that normally comes out the back end of the camera will help. So, yes, I'm trying to fit a 2D gaussian to R, G, and B channels simultaneously, each of which has their own checkerboard-like mask, like in the attached image/below. [cid:ii_i5r2nc7y1_14b55eefcafaac02] ? When doing the gaussian fit, the x/y_mean should be tied together between the 3 channels, and the x/y_stddev and theta should also be tied (to within chromatic effects of the lens), but the amplitude of each channel should be allowed to be different. Which all sounds very much like the example use-case described in the docstring of the JointFitter class! I had moderate success with fitting individual channels (convergence was sometimes flaky) and was about to try writing a custom 'Gaussian2Dx3' model class when I ran across JointFItter and thought it seemed like it would do nicely. Right now, I'm doing something like this, which isn't working right because I don't know how the inputs need to go but I've been trying to guess from the source code and errors generated: -------------------------------------------------------------------------------------------------------- ## Define reasonable ranges for the fitting parameters (data centered at 0,0 pixel) gaussbounds = {'amplitude': [0.2, 0.8], 'x_mean': [-2.0, 2.0], 'y_mean': [-2.0, 2.0], 'x_stddev': [0.2, 1.5], 'y_stddev': [0.2, 1.5]} ## Create a model instance for each channel gaussR = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) gaussG = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) gaussB = models.Gaussian2D(0.5, 0.0, 0.0, 0.4, 0.4, bounds=gaussbounds) ## Trying to get these other inputs structured correctly to make JointFitter.__init__() ## complete smoothly. jointpars = {'gaussR': [gaussR.x_mean, gaussR.y_mean, gaussR.x_stddev, gaussR.y_stddev, gaussR.theta], 'gaussG': [gaussG.x_mean, gaussG.y_mean, gaussG.x_stddev, gaussG.y_stddev, gaussG.theta], 'gaussB': [gaussB.x_mean, gaussB.y_mean, gaussB.x_stddev, gaussB.y_stddev, gaussB.theta] } initvals = [0.0, 0.0, 0.4, 0.4, 0.0] ## Here's what I'm feeding it, finally. I'm out of ideas! jointRGB = fitting.JointFitter({'gaussR':gaussR, 'gaussG':gaussG, 'gaussB':gaussB}, jointpars, initvals) -------------------------------------------------------------------------------------------------------- Anyway, many thanks in advance for the help! Cheers, Brandon > Date: Wed, 4 Feb 2015 14:38:44 +0000 > From: Nadezhda Dencheva > > Subject: Re: [AstroPy] JointFitter help > > Hi Brandon, > > Can you explain a bit more how you are doing the fitting? > It sounds like you are fitting a 2D Gaussian but I'm not sure what the data is? > What are the inputs to each model? > > Cheers, > Nadia _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rgbspot.png Type: image/png Size: 1980 bytes Desc: rgbspot.png URL: From erik.tollerud at gmail.com Thu Feb 12 01:55:51 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 12 Feb 2015 01:55:51 -0500 Subject: [AstroPy] Astropy v1.0rc2 ready for testing Message-ID: Hello all, The first Release Candidate for Astropy v1.0 led to enough fixes and minor adjustments that we have decided to issue a second release candidate for testing (v1.0rc2). Hopefully all will go well with this one and we can do the final v1.0 release very soon. Please help us test if you can! You can install it with pip by doing "pip install --pre astropy". If you're using an anaconda distribution, you'll either need to "conda remove astropy" or make a new environment before installing the rc from pip. Documentation is available at: http://astropy.readthedocs.org/en/v1.0rc2/ Of particular note is the what's new section for 1.0: http://astropy.readthedocs.org/en/v1.0rc2/whatsnew/1.0.html -- Erik Tollerud -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Thu Feb 12 11:52:58 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 12 Feb 2015 11:52:58 -0500 Subject: [AstroPy] Astropy v1.0rc2 ready for testing In-Reply-To: References: Message-ID: Hello all, At James Turner's suggestion, I've created a page on the astropy github wiki where you can report the results of trying the RC: https://github.com/astropy/astropy/wiki/v1.0-RC-testing If you can, please use that to report your results for installing and testing the RC (success *or* failures). Thanks! On Thu, Feb 12, 2015 at 1:55 AM, Erik Tollerud wrote: > Hello all, > > The first Release Candidate for Astropy v1.0 led to enough fixes and minor > adjustments that we have decided to issue a second release candidate for > testing (v1.0rc2). Hopefully all will go well with this one and we can do > the final v1.0 release very soon. > > Please help us test if you can! You can install it with pip by doing "pip > install --pre astropy". If you're using an anaconda distribution, you'll > either need to "conda remove astropy" or make a new environment before > installing the rc from pip. > > > Documentation is available at: > http://astropy.readthedocs.org/en/v1.0rc2/ > > Of particular note is the what's new section for 1.0: > http://astropy.readthedocs.org/en/v1.0rc2/whatsnew/1.0.html > > > -- > Erik Tollerud > -- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Fri Feb 13 18:28:52 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Fri, 13 Feb 2015 18:28:52 -0500 Subject: [AstroPy] Fwd: [Numpy-discussion] Nature says 'Pick up Python' In-Reply-To: References: Message-ID: Check out the Nature article below, awesome!! And note that Tom Robitaille's Python lecture notes are mentioned in the box on "Python Toolkit". - Tom ---------- Forwarded message ---------- From: Sturla Molden Date: Fri, Feb 13, 2015 at 5:36 PM Subject: [Numpy-discussion] Nature says 'Pick up Python' To: numpy-discussion at scipy.org Cc: scipy-user at scipy.org, cython-users at googlegroups.com A recent article in Nature advice scientists to use Python, Cython and the SciPy stack. http://www.nature.com/news/programming-pick-up-python-1.16833 Sturla _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Sun Feb 15 17:40:06 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sun, 15 Feb 2015 22:40:06 +0000 Subject: [AstroPy] APLpy 1.0 release candidate Message-ID: <54E12046.2070709@gmail.com> Hi everyone, This week I am planning on releasing APLpy 1.0, and I have created a release candidate (1.0rc1). The tar file can be found here: https://pypi.python.org/pypi/APLpy/1.0rc1 and you can install this version with: pip install aplpy --pre (the --pre stands for pre-release). If anyone has a chance to try out this new version, please let me know if you run into any issues! You can report issues in the issue tracker: https://github.com/aplpy/aplpy/issues and if some of you try this out and do not run into any issues, I would also appreciate if you could let me know privately by email. This release is only a bug fix release, so there are no new features to try - I just want to make sure that nothing breaks with this release. Thanks! Tom From erik.tollerud at gmail.com Wed Feb 18 05:59:30 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 18 Feb 2015 00:59:30 -1000 Subject: [AstroPy] How can I add another name to a registered unit? In-Reply-To: <2B0BD1C2-CFB8-492A-BC04-55C0122B28DF@ligo.org> References: <2B0BD1C2-CFB8-492A-BC04-55C0122B28DF@ligo.org> Message-ID: Hello Duncan, This isn't precisely supported behavior (because it uses a private variable), so I'm not sure I can promise it will work long-term, but at least in 0.4 and 1.0 it should do the trick: >>> from astropy import units as u >>> from astropy.units import imperial >>> imperial.enable() >>> imperial.deg_F Unit("deg_F") >>> u.Unit('deg_F') Unit("deg_F") >>> u.Unit('Degrees_F') ValueError: 'Degrees_F' did not parse as unit: At col 0, Degrees_F is not a valid unit. Did you mean degree? >>> imperial.deg_F._names.append('Degrees_F') # this is the tricky part that involves a private variable >>> u.add_enabled_units([imperial.deg_F]) # this registers the new names >>> u.Unit('Degrees_F') Unit("deg_F") Hope that helps! On Tue, Feb 3, 2015 at 11:09 AM, Duncan Macleod wrote: > Hi all, > > I?m wondering how to add another name to an already registered unit. The > example I have is a data file containing the unit string ?Degrees_F? - > meaning Fahrenheit. I understand I can enable a new unit called ?Degrees_F? > that represents the original ?deg_F/Fahrenheit' unit from units.imperial, > but what I?d really like to do is just register the string ?Degrees_F? as > another name for ?deg_F?, rather than an equivalent unit. > > In the end I?d like to see the following: > > >>> units.Unit(?Degrees_F?) > Unit(?deg_F?) > > Is this possible? > > > Thanks > Duncan > -- > Duncan Macleod > duncan.macleod at ligo.org > LIGO Data Grid systems development > Louisiana State University > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Wed Feb 18 08:18:30 2015 From: deil.christoph at googlemail.com (Christoph Deil) Date: Wed, 18 Feb 2015 14:18:30 +0100 Subject: [AstroPy] Stable parametrisation for fitting elongated models to images Message-ID: Hi, apologies if this is considered off-topic for this mailing list, I didn?t know where else to ask for advice. The question I have is how to best parametrise elongated 2D models so that model fits on images converge as much as possible, even in slightly crowded regions with overlapping sources? Concretely Astropy uses width and length and rotation angle [1, 2] and Sherpa uses width, ellipticity and rotation angle [3]. Looking at the SExtractor manual (section 10.1) there?s also the option to use the ?ellipse parameters? CXX, CYY, CXY [4]. I realise it?s a vague question, and there might be different "best parametrisations? for different data, fit statistic and optimiser, but still: Has someone had good results (i.e. converging fits) for crowded regions with some parametrisation? Or maybe there even exists a writeup or study comparing different parametrisations? Thanks! Christoph [1] http://astropy.readthedocs.org/en/latest/api/astropy.modeling.functional_models.Gaussian2D.html [2] http://astropy.readthedocs.org/en/latest/api/astropy.modeling.functional_models.Ellipse2D.html [3] http://cxc.harvard.edu/sherpa/ahelp/normgauss2d.html [4] https://www.astromatic.net/pubsvn/software/sextractor/trunk/doc/sextractor.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed Feb 18 10:32:36 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 18 Feb 2015 15:32:36 +0000 Subject: [AstroPy] APLpy 1.0 released Message-ID: Hi everyone, I am pleased to announce the release of APLpy 1.0! APLpy is a Python module that makes it easy to interactively produce publication-quality plots of astronomical images: http://aplpy.github.io This version fixes a bug that occurred when using the recenter method and RGB images, which could lead in some cases to the RGB image being incorrectly re-centered. In addition, this version includes a new method ``show_vectors`` that can be used to display for example polarization maps (thanks to Martin Hardcastle for the contribution). If you use pip, you should now be able to update using: pip install aplpy --upgrade Please let me know if you have any issues with this release! The best place to report any issues is via GitHub: https://github.com/aplpy/aplpy/issues As a side note, it has been almost 6 years since the first release of APLpy, and I felt that it is finally time to start using the 1.0 version number. The 1.x series of releases will be primarily concerned with bug fixes. Work on APLpy 2.0 has already started, and involves major internal refactoring to make use of the WCSAxes package (http://wcsaxes.readthedocs.org), and will also make use of new features being introduced in Astropy 1.0 in order to simplify the APLpy code. The aim will still be to maintain backward-compatibility with existing scripts, but the output will no longer be guaranteed to be strictly identical (because WCSAxes may choose default tick labels differently for example, and deals correctly with the rotation of tick marks). Cheers, Tom From duncan.macleod at ligo.org Wed Feb 18 10:33:13 2015 From: duncan.macleod at ligo.org (Duncan Macleod) Date: Wed, 18 Feb 2015 09:33:13 -0600 Subject: [AstroPy] How can I add another name to a registered unit? In-Reply-To: References: <2B0BD1C2-CFB8-492A-BC04-55C0122B28DF@ligo.org> Message-ID: Hi Erik, This looks easy enough, and isn't too hacky. Thanks Duncan On 18 February 2015 at 04:59, Erik Tollerud wrote: > Hello Duncan, > > This isn't precisely supported behavior (because it uses a private > variable), so I'm not sure I can promise it will work long-term, but at > least in 0.4 and 1.0 it should do the trick: > > >>> from astropy import units as u > >>> from astropy.units import imperial > >>> imperial.enable() > >>> imperial.deg_F > Unit("deg_F") > >>> u.Unit('deg_F') > Unit("deg_F") > >>> u.Unit('Degrees_F') > ValueError: 'Degrees_F' did not parse as unit: At col 0, Degrees_F is not > a valid unit. Did you mean degree? > >>> imperial.deg_F._names.append('Degrees_F') # this is the tricky part > that involves a private variable > >>> u.add_enabled_units([imperial.deg_F]) # this registers the new names > >>> u.Unit('Degrees_F') > Unit("deg_F") > > > Hope that helps! > > > On Tue, Feb 3, 2015 at 11:09 AM, Duncan Macleod > wrote: > >> Hi all, >> >> I?m wondering how to add another name to an already registered unit. The >> example I have is a data file containing the unit string ?Degrees_F? - >> meaning Fahrenheit. I understand I can enable a new unit called ?Degrees_F? >> that represents the original ?deg_F/Fahrenheit' unit from units.imperial, >> but what I?d really like to do is just register the string ?Degrees_F? as >> another name for ?deg_F?, rather than an equivalent unit. >> >> In the end I?d like to see the following: >> >> >>> units.Unit(?Degrees_F?) >> Unit(?deg_F?) >> >> Is this possible? >> >> >> Thanks >> Duncan >> -- >> Duncan Macleod >> duncan.macleod at ligo.org >> LIGO Data Grid systems development >> Louisiana State University >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > > > -- > Erik T > -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From raniere at ime.unicamp.br Thu Feb 19 06:58:38 2015 From: raniere at ime.unicamp.br (Raniere Silva) Date: Thu, 19 Feb 2015 09:58:38 -0200 Subject: [AstroPy] Google Summer of Code and NumFOCUS Message-ID: <20150219115838.GC15475@pupunha> Hi, NumFOCUS has promotes and supports the ongoing research and development of open-source computing tools including AstroPy. This year NumFOCUS want to try be a Google Summer of Code "umbrella" mentoring organization, Umbrella organizations are mentoring organizations accepted into the Google Summer of Code program that have other open source organizations working "under" them. Sometime organizations that work very closely or have very similar goals or communities may get put together under an "umbrella." Google stills expects all organizations under the umbrella, whether accepted into the program under their title or not, to adhere to all the rules and regulations of the program. From https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#umbrella_organization To help promote and support AstroPy. We encourage AstroPy to apply to Google Summer of Code under your own title and will be very happy if you can also do with us. If you are interested, please check https://github.com/swcarpentry/gsoc2015 and https://github.com/swcarpentry/gsoc2015/blob/master/CONTRIBUTING.md. If you have any question, please email me directly. Thanks in advance, Raniere -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mdroe at stsci.edu Thu Feb 19 08:03:31 2015 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 19 Feb 2015 13:03:31 +0000 Subject: [AstroPy] How can I add another name to a registered unit? In-Reply-To: References: <2B0BD1C2-CFB8-492A-BC04-55C0122B28DF@ligo.org> , Message-ID: <50B8371B1D275D42AE85E612144FFEB96827EE4A@EXCHMAIL2.stsci.edu> The method (using only public APIs) is: Degrees_F = u.def_unit(["Degrees_F"], imperial.deg_F) u.add_enabled_unit(Degrees_F) Mike ________________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Duncan Macleod [duncan.macleod at ligo.org] Sent: Wednesday, February 18, 2015 10:33 AM To: Erik Tollerud Cc: Astronomical Python mailing list Subject: Re: [AstroPy] How can I add another name to a registered unit? Hi Erik, This looks easy enough, and isn't too hacky. Thanks Duncan On 18 February 2015 at 04:59, Erik Tollerud > wrote: Hello Duncan, This isn't precisely supported behavior (because it uses a private variable), so I'm not sure I can promise it will work long-term, but at least in 0.4 and 1.0 it should do the trick: >>> from astropy import units as u >>> from astropy.units import imperial >>> imperial.enable() >>> imperial.deg_F Unit("deg_F") >>> u.Unit('deg_F') Unit("deg_F") >>> u.Unit('Degrees_F') ValueError: 'Degrees_F' did not parse as unit: At col 0, Degrees_F is not a valid unit. Did you mean degree? >>> imperial.deg_F._names.append('Degrees_F') # this is the tricky part that involves a private variable >>> u.add_enabled_units([imperial.deg_F]) # this registers the new names >>> u.Unit('Degrees_F') Unit("deg_F") Hope that helps! On Tue, Feb 3, 2015 at 11:09 AM, Duncan Macleod > wrote: Hi all, I?m wondering how to add another name to an already registered unit. The example I have is a data file containing the unit string ?Degrees_F? - meaning Fahrenheit. I understand I can enable a new unit called ?Degrees_F? that represents the original ?deg_F/Fahrenheit' unit from units.imperial, but what I?d really like to do is just register the string ?Degrees_F? as another name for ?deg_F?, rather than an equivalent unit. In the end I?d like to see the following: >>> units.Unit(?Degrees_F?) Unit(?deg_F?) Is this possible? Thanks Duncan -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- Erik T -- Duncan Macleod duncan.macleod at ligo.org LIGO Data Grid systems development Louisiana State University From thomas.robitaille at gmail.com Thu Feb 19 10:18:00 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 19 Feb 2015 15:18:00 +0000 Subject: [AstroPy] ANN: Astropy v1.0 released Message-ID: Dear colleagues, We are very happy to announce the fourth major public release (v1.0) of the astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. New and improved major functionality in this release includes: * Support for Altitude/Azimuth and Galactocentric coordinates in astropy.coordinates * A new astropy.visualization sub-package * A new astropy.analytic_functions sub-package * Compound models in astropy.modeling may now be created using arithmetic expressions, and the resulting models support fitting. * Significantly faster C-based readers/writers for astropy.io.ascii * Support for a new enhanced CSV ASCII table format * A refactored Table class with improved performance when adding/removing columns * Support for using Time, Quantity, or SkyCoord arrays as Table columns In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/1.0.html Astropy v1.0 is a special release that we are denoting a Long Term Support (LTS) release, which means that we will be supporting it with bug fixes for the next two years, rather than the usual six months. More information about this can be found at the link above. Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org In particular, if you use the Anaconda Python Distribution, you can update to v1.0 with: conda update astropy Whereas if you usually use pip, you can do: pip install astropy --upgrade Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 122 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html If you use Astropy directly for your work, or as a dependency to another package, please remember to include the following acknowledgment at the end of papers: """ This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013). """ where (Astropy Collaboration, 2013) is a reference to the Astropy paper: http://dx.doi.org/10.1051/0004-6361/201322068 Please feel free to forward this announcement to anyone you think might be interested in this release. We hope that you enjoy using Astropy as much as we enjoyed developing it! Thomas Robitaille, Erik Tollerud, and Perry Greenfield on behalf of The Astropy Collaboration From jzuhone at gmail.com Thu Feb 19 10:22:27 2015 From: jzuhone at gmail.com (John ZuHone) Date: Thu, 19 Feb 2015 10:22:27 -0500 Subject: [AstroPy] [astropy-dev] ANN: Astropy v1.0 released In-Reply-To: References: Message-ID: <952117FB-8967-4497-A940-25472E4D52F9@gmail.com> Congratulations to all of you developers! Great work! > On Feb 19, 2015, at 10:18 AM, Thomas Robitaille wrote: > > Dear colleagues, > > We are very happy to announce the fourth major public release (v1.0) > of the astropy package, a core Python package for Astronomy: > > http://www.astropy.org > > Astropy is a community-driven Python package intended to contain much > of the core functionality and common tools needed for astronomy and > astrophysics. > > New and improved major functionality in this release includes: > > * Support for Altitude/Azimuth and Galactocentric coordinates in > astropy.coordinates > * A new astropy.visualization sub-package > * A new astropy.analytic_functions sub-package > * Compound models in astropy.modeling may now be created using > arithmetic expressions, and the resulting models support fitting. > * Significantly faster C-based readers/writers for astropy.io.ascii > * Support for a new enhanced CSV ASCII table format > * A refactored Table class with improved performance when > adding/removing columns > * Support for using Time, Quantity, or SkyCoord arrays as Table columns > > In addition, hundreds of smaller improvements and fixes have been > made. An overview of the changes is provided at: > > http://docs.astropy.org/en/stable/whatsnew/1.0.html > > Astropy v1.0 is a special release that we are denoting a Long Term > Support (LTS) release, which means that we will be supporting it with > bug fixes for the next two years, rather than the usual six months. > More information about this can be found at the link above. > > Instructions for installing Astropy are provided on our website, and > extensive documentation can be found at: > > http://docs.astropy.org > > In particular, if you use the Anaconda Python Distribution, you can > update to v1.0 with: > > conda update astropy > > Whereas if you usually use pip, you can do: > > pip install astropy --upgrade > > Please report any issues, or request new features via our GitHub repository: > > https://github.com/astropy/astropy/issues > > Over 122 developers have contributed code to Astropy so far, and you > can find out more about the team behind Astropy here: > > http://www.astropy.org/team.html > > If you use Astropy directly for your work, or as a dependency to > another package, please remember to include the following > acknowledgment at the end of papers: > > """ > This research made use of Astropy, a community-developed core Python > package for Astronomy (Astropy Collaboration, 2013). > """ > > where (Astropy Collaboration, 2013) is a reference to the Astropy paper: > > http://dx.doi.org/10.1051/0004-6361/201322068 > > Please feel free to forward this announcement to anyone you think > might be interested in this release. > > We hope that you enjoy using Astropy as much as we enjoyed developing it! > > Thomas Robitaille, Erik Tollerud, and Perry Greenfield > on behalf of The Astropy Collaboration > > -- > You received this message because you are subscribed to the Google Groups "astropy-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From mjuric at lsst.org Thu Feb 19 17:56:54 2015 From: mjuric at lsst.org (Mario Juric) Date: Thu, 19 Feb 2015 14:56:54 -0800 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? Message-ID: <54E66A36.3070305@lsst.org> Hi everyone, Is there an efficient way to go from three ndarrays of year, month, day values to julian date? I.e., an equivalent of: jd = ymd_to_jd(yy, mm, dd) , where all variables are (potentially large) ndarrays? Cheers, -- Mario Juric, UW Astronomy Faculty | UW eScience | LSST DM Project Scientist Web : http://research.majuric.org Phone : +1 609 933 1033 From aldcroft at head.cfa.harvard.edu Fri Feb 20 06:44:51 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Fri, 20 Feb 2015 06:44:51 -0500 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? In-Reply-To: <54E66A36.3070305@lsst.org> References: <54E66A36.3070305@lsst.org> Message-ID: Hi Mario, Your best bet (right now) is probably to use the ERFA library directly. This is bundled in astropy.time. You can get an example of this here: https://github.com/astropy/astropy/blob/v1.0/astropy/time/core.py#L1427 Note that this example uses the name erfa_time.dtf_jd as an alias to the actual routine name dtf2d. See [1] for some words about the aliasing, but the short version is you should probably use dtf2d to be safe. An even better option would be to implement this as a new astropy Time format. I've opened an issue to provide some detail: https://github.com/astropy/astropy/issues/3527 Cheers, Tom On Thu, Feb 19, 2015 at 5:56 PM, Mario Juric wrote: > Hi everyone, > Is there an efficient way to go from three ndarrays of year, > month, day > values to julian date? I.e., an equivalent of: > > jd = ymd_to_jd(yy, mm, dd) > > , where all variables are (potentially large) ndarrays? > > Cheers, > -- > Mario Juric, > UW Astronomy Faculty | UW eScience | LSST DM Project Scientist > Web : http://research.majuric.org Phone : +1 609 933 1033 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Fri Feb 20 07:16:12 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Fri, 20 Feb 2015 07:16:12 -0500 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? In-Reply-To: References: <54E66A36.3070305@lsst.org> Message-ID: On Fri, Feb 20, 2015 at 6:44 AM, Aldcroft, Thomas < aldcroft at head.cfa.harvard.edu> wrote: > Hi Mario, > > Your best bet (right now) is probably to use the ERFA library directly. > This is bundled in astropy.time. You can get an example of this here: > > https://github.com/astropy/astropy/blob/v1.0/astropy/time/core.py#L1427 > > Note that this example uses the name erfa_time.dtf_jd as an alias to the > actual routine name dtf2d. See [1] for some words about the aliasing, > but the short version is you should probably use dtf2d to be safe. > > An even better option would be to implement this as a new astropy Time > format. I've opened an issue to provide some detail: > > https://github.com/astropy/astropy/issues/3527 > Just another note that you can implement this format class locally (within your codebase) and it gets automatically registered as a Time Format on import. In this way you can put in a patch to astropy but also use the new format in your code (with astropy 1.0) before the next astropy release. > > > Cheers, > Tom > > On Thu, Feb 19, 2015 at 5:56 PM, Mario Juric wrote: > >> Hi everyone, >> Is there an efficient way to go from three ndarrays of year, >> month, day >> values to julian date? I.e., an equivalent of: >> >> jd = ymd_to_jd(yy, mm, dd) >> >> , where all variables are (potentially large) ndarrays? >> >> Cheers, >> -- >> Mario Juric, >> UW Astronomy Faculty | UW eScience | LSST DM Project Scientist >> Web : http://research.majuric.org Phone : +1 609 933 1033 >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raniere at ime.unicamp.br Fri Feb 20 15:31:17 2015 From: raniere at ime.unicamp.br (Raniere Silva) Date: Fri, 20 Feb 2015 18:31:17 -0200 Subject: [AstroPy] =?utf-8?q?ANN=3A_SciPy_Latin_Am=C3=A9rica_2015_-_Call_f?= =?utf-8?q?or_Proposals?= Message-ID: <20150220203117.GL12853@pupunha> *Call for Proposals* *SciPy Latin Am?rica 2015*, the third annual Scientific Computing with Python Conference, will be held this *May 20-22* in *Posadas, Misiones, Argentina*. SciPy is a community dedicated to the advancement of scientific computing through open source Python software for mathematics, science, and engineering. The annual SciPy Conferences allows participants from academic, commercial, and governmental organizations to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. *Proposals are now being accepted for SciPy Latin Am?rica 2015*. Presentation content can be at a novice, intermediate or advanced level. Talks will run 30-40 min and hands-on tutorials will run 100-120 min. We also receive proposal for posters. For more information about the different types of proposal, see below the "*Different types of Communication*" section. *How to Submit?* 1. Register for an account on http://conf.scipyla.org/user/register 2. Submit your proposal at http://conf.scipyla.org/activity/propose *Important Dates* - *April 6th*: Talks, poster, tutorial submission deadline. - *April 20th*: Notification Talks / Posters / Tutorial accepted. - *May 20th-22nd*: SciPy Latin Am?rica 2015. *Different types of Communication* *Talks*: These are the traditional talk sessions given during the main conference days. They're mostly 30 minutes long with 5 min for questions. If you think you have a topic but aren't sure how to propose it, contact our program committee and we'll work with you. We'd love to help you come up with a great proposal. *Tutorials*: We are looking for tutorials that can grow this community at any level. We aim for tutorials that will advance Scientific Python, advance this community, and shape the future. They're are 100-120 minutes long, but if you think you need more than one slot, you can split the content and submit two self-contained proposals. *Posters*: The poster session provides a more interactive, attendee-driven presentation than the speaker-driven conference talks. Poster presentations have fostered extensive discussions on the topics, with many that have gone on much longer than the actual "session" called for. The idea is to present your topic on poster board and as attendees mingle through the rows, they find your topic, read through what you've written, then strike up a discussion on it. It's as simple as that. You could be doing Q&A in the first minute of the session with a group of 10 people. *Lightning Talks*: Want to give a talk, but do not have enough material for a full talk? These talks are, at max, 5 minute talks done in quick succession in the main hall. No need to fill the whole slot, though! -- *The SciPy LA 2015 Program **Committee* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mperrin at stsci.edu Fri Feb 20 17:05:35 2015 From: mperrin at stsci.edu (Marshall Perrin) Date: Fri, 20 Feb 2015 22:05:35 +0000 Subject: [AstroPy] ANN: Release of WebbPSF 0.3 and POPPY 0.3.4 Message-ID: <9CC0543D-1A2E-45FF-83A2-3329B6473E2D@stsci.edu> A smaller and more specialized milestone than the momentous release of Astropy 1.0, but still hopefully of interest to some in the community: We?re pleased to announce the release of: * Version 0.3 of WebbPSF, a package for generating simulated point spread functions for the James Webb Space Telescope, and also * Version 0.3.4 of POPPY (Physical Optics Propagation in Python), the optical simulation toolkit that provides the underlying foundation for WebbPSF. While WebbPSF is naturally more directly of interest to those working on preparation for JWST (for now - there are plans afoot to eventually expand simulation capabilities to additional telescopes as well), POPPY provides a fairly general purpose system for simulating diffraction, generating simulated PSFs, and evaluating PSF properties for a broad range of astronomical instruments and telescopes. Both packages are available from PYPI. Source is hosted on Github: https://github.com/mperrin/webbpsf https://github.com/mperrin/poppy And both are built on the foundation provided by Astropy - thanks in particular to all the Astropyers who?ve helped construct the affiliated package template infrastructure. Marshall Perrin, Joseph Long, Christine Slocum, and collaborators From embray at stsci.edu Fri Feb 20 18:46:32 2015 From: embray at stsci.edu (Erik Bray) Date: Fri, 20 Feb 2015 18:46:32 -0500 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? In-Reply-To: References: <54E66A36.3070305@lsst.org> Message-ID: <54E7C758.9060008@stsci.edu> On 02/20/2015 07:16 AM, Aldcroft, Thomas wrote: > On Fri, Feb 20, 2015 at 6:44 AM, Aldcroft, Thomas > wrote: > > Hi Mario, > > Your best bet (right now) is probably to use the ERFA library directly. > This is bundled in astropy.time. You can get an example of this here: > > https://github.com/astropy/astropy/blob/v1.0/astropy/time/core.py#L1427 > > Note that this example uses the name erfa_time.dtf_jd as an alias to the > actual routine name dtf2d. See [1] for some words about the aliasing, but > the short version is you should probably use dtf2d to be safe. > > An even better option would be to implement this as a new astropy Time > format. I've opened an issue to provide some detail: > > https://github.com/astropy/astropy/issues/3527 > > > Just another note that you can implement this format class locally (within your > codebase) and it gets automatically registered as a Time Format on import. In > this way you can put in a patch to astropy but also use the new format in your > code (with astropy 1.0) before the next astropy release. \o/ This is true. Thanks for remembering that--I forgot it even worked that way despite being the one who implemented that feature. Did we ever mention that anywhere in the documentation? If not I guess it should be somewhere... Erik > > > > Cheers, > Tom > > On Thu, Feb 19, 2015 at 5:56 PM, Mario Juric > wrote: > > Hi everyone, > Is there an efficient way to go from three ndarrays of year, > month, day > values to julian date? I.e., an equivalent of: > > jd = ymd_to_jd(yy, mm, dd) > > , where all variables are (potentially large) ndarrays? > > Cheers, > -- > Mario Juric, > UW Astronomy Faculty | UW eScience | LSST DM Project Scientist > Web : http://research.majuric.org Phone : +1 609 933 1033 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From mjuric at lsst.org Sat Feb 21 04:05:50 2015 From: mjuric at lsst.org (Mario Juric) Date: Sat, 21 Feb 2015 01:05:50 -0800 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? In-Reply-To: References: <54E66A36.3070305@lsst.org> Message-ID: <54E84A6E.4040706@lsst.org> On 2/20/15 3:44 , Aldcroft, Thomas wrote: > Hi Mario, > > Your best bet (right now) is probably to use the ERFA library directly. > This is bundled in astropy.time. You can get an example of this here: > > https://github.com/astropy/astropy/blob/v1.0/astropy/time/core.py#L1427 > > Note that this example uses the name erfa_time.dtf_jd as an alias to the > actual routine name dtf2d. See [1] for some words about the aliasing, > but the short version is you should probably use dtf2d to be safe. > > An even better option would be to implement this as a new astropy Time > format. I've opened an issue to provide some detail: > > https://github.com/astropy/astropy/issues/3527 > Hi Tom et al, Thanks for your help! I'll look into using ERFA directly for now (didn't know that was an option). Implementing a format looks like the way to go given the current APIs; I'll try coding it up if someone doesn't beat me to it (may take me a few weeks to find some free time). Thanks again, -- Mario Juric, UW Astronomy Faculty | UW eScience | LSST DM Project Scientist Web : http://research.majuric.org Phone : +1 609 933 1033 From aldcroft at head.cfa.harvard.edu Sat Feb 21 06:44:28 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Sat, 21 Feb 2015 06:44:28 -0500 Subject: [AstroPy] Converting ndarrays of year, month, days to JD? In-Reply-To: <54E7C758.9060008@stsci.edu> References: <54E66A36.3070305@lsst.org> <54E7C758.9060008@stsci.edu> Message-ID: On Fri, Feb 20, 2015 at 6:46 PM, Erik Bray wrote: > On 02/20/2015 07:16 AM, Aldcroft, Thomas wrote: > > On Fri, Feb 20, 2015 at 6:44 AM, Aldcroft, Thomas < > aldcroft at head.cfa.harvard.edu > > > wrote: > > > > Hi Mario, > > > > Your best bet (right now) is probably to use the ERFA library > directly. > > This is bundled in astropy.time. You can get an example of this > here: > > > > > https://github.com/astropy/astropy/blob/v1.0/astropy/time/core.py#L1427 > > > > Note that this example uses the name erfa_time.dtf_jd as an alias to > the > > actual routine name dtf2d. See [1] for some words about the > aliasing, but > > the short version is you should probably use dtf2d to be safe. > > > > An even better option would be to implement this as a new astropy > Time > > format. I've opened an issue to provide some detail: > > > > https://github.com/astropy/astropy/issues/3527 > > > > > > Just another note that you can implement this format class locally > (within your > > codebase) and it gets automatically registered as a Time Format on > import. In > > this way you can put in a patch to astropy but also use the new format > in your > > code (with astropy 1.0) before the next astropy release. > > \o/ This is true. Thanks for remembering that--I forgot it even worked > that > way despite being the one who implemented that feature. Did we ever > mention > that anywhere in the documentation? If not I guess it should be > somewhere... > Good point. I expanded the scope of your comment a bit with https://github.com/astropy/astropy/issues/3533 - Tom > Erik > > > > > > > > > Cheers, > > Tom > > > > On Thu, Feb 19, 2015 at 5:56 PM, Mario Juric > > wrote: > > > > Hi everyone, > > Is there an efficient way to go from three ndarrays of > year, > > month, day > > values to julian date? I.e., an equivalent of: > > > > jd = ymd_to_jd(yy, mm, dd) > > > > , where all variables are (potentially large) ndarrays? > > > > Cheers, > > -- > > Mario Juric, > > UW Astronomy Faculty | UW eScience | LSST DM Project Scientist > > Web : http://research.majuric.org Phone : +1 609 933 1033 > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kylebarbary at gmail.com Mon Feb 23 23:11:46 2015 From: kylebarbary at gmail.com (Kyle Barbary) Date: Mon, 23 Feb 2015 20:11:46 -0800 Subject: [AstroPy] [ANN] SNCosmo v1.0, SEP v0.3 Message-ID: Hi all, I?m happy to announce the release of SNCosmo v1.0 (website ). SNCosmo is a Python library for supernova cosmology, and an AstroPy affiliated package. The v1.0 designation is intended to convey backwards compatibility of the API for the v1.x series. While I?m at it, I?ll also announce a very minor release of SEP v0.3 ( website ). SEP is a fork of the Source Extractor C code base, wrapped in Python. SEP v0.3 adds a single flux_radius function (e.g., half-light radius). Best, Kyle ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eisenhamer at stsci.edu Tue Feb 24 18:06:35 2015 From: eisenhamer at stsci.edu (Jonathan Eisenhamer) Date: Tue, 24 Feb 2015 23:06:35 +0000 Subject: [AstroPy] Fits table creation: format repeats array: should I expect this? Message-ID: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu> Greetings, Basic FITS io question. I do the following, which comes basically from the example in the astropy docs: from astropy.io import fits import numpy as np a = np.arange(100.0) col = fits.Column(name='a100', format='4096E', array=a) coldefs = fits.ColDefs([col]) hdu = fits.BinTableHDU.from_columns(coldefs) The array association with the column is "correct", in that the shape of a is (100,). Except after it has been put into the HDU. Now the array for the column has shape (100, 4096): hdu.columns[0].array.shape -> (100, 4096) Clearly this is because of the format. And at some level this makes sense, but a couple questions: * Why does the format not affect the array until the HDU is created? I.e. The col has just the basic array in it. * Is this expected behavior? Thank you for your time, jde -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Wed Feb 25 10:36:08 2015 From: embray at stsci.edu (Erik Bray) Date: Wed, 25 Feb 2015 10:36:08 -0500 Subject: [AstroPy] Fits table creation: format repeats array: should I expect this? In-Reply-To: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu> References: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu> Message-ID: <54EDEBE8.7030702@stsci.edu> On 02/24/2015 06:06 PM, Jonathan Eisenhamer wrote: > Greetings, > > Basic FITS io question. I do the following, which comes basically from the > example in the astropy docs: > from astropy.io import fits > import numpy as np > > a = np.arange(100.0) > col = fits.Column(name='a100', format='4096E', array=a) > coldefs = fits.ColDefs([col]) > hdu = fits.BinTableHDU.from_columns(coldefs) > > The array association with the column is "correct", in that the shape of a is > (100,). > > Except after it has been put into the HDU. Now the array for the column has > shape (100, 4096): > > hdu.columns[0].array.shape > -> (100, 4096) > > Clearly this is because of the format. And at some level this makes sense, but a > couple questions: > > * Why does the format not affect the array until the HDU is created? I.e. The > col has just the basic array in it. > * Is this expected behavior? > > Thank you for your time, (FWIW since I'm the only one who actually works on the FITS module this is basically just a question for me, especially for something at this level.) Is this expected behavior? Yes and no. It's expected to me because I read the code. It may not be expected to a user (in your case it wasn't). There's nothing particularly deliberate or designed about that--it just has to do with where the code that does various manipulations live. The pyfits "Column" class is not as well designed as the astropy.table Column class, and shouldn't generally be used on its own outside the context of setting up a table. The fact that you can get to its .array attribute (or that that even exists at all) is a somewhat unfortunate misfeature I've had the "fun" of having to carry around. So I wouldn't worry about this. Erik From eisenhamer at stsci.edu Wed Feb 25 10:53:00 2015 From: eisenhamer at stsci.edu (Jonathan Eisenhamer) Date: Wed, 25 Feb 2015 15:53:00 +0000 Subject: [AstroPy] Fits table creation: format repeats array: should I expect this? In-Reply-To: <54EDEBE8.7030702@stsci.edu> References: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu>, <54EDEBE8.7030702@stsci.edu> Message-ID: Then worry I shall not. In anticipation of just this answer I have done the end-around. Thanks! jde -------- Original message -------- From: Erik Bray Date:2015/02/25 10:36 (GMT-05:00) To: astropy at scipy.org Subject: Re: [AstroPy] Fits table creation: format repeats array: should I expect this? On 02/24/2015 06:06 PM, Jonathan Eisenhamer wrote: > Greetings, > > Basic FITS io question. I do the following, which comes basically from the > example in the astropy docs: > from astropy.io import fits > import numpy as np > > a = np.arange(100.0) > col = fits.Column(name='a100', format='4096E', array=a) > coldefs = fits.ColDefs([col]) > hdu = fits.BinTableHDU.from_columns(coldefs) > > The array association with the column is "correct", in that the shape of a is > (100,). > > Except after it has been put into the HDU. Now the array for the column has > shape (100, 4096): > > hdu.columns[0].array.shape > -> (100, 4096) > > Clearly this is because of the format. And at some level this makes sense, but a > couple questions: > > * Why does the format not affect the array until the HDU is created? I.e. The > col has just the basic array in it. > * Is this expected behavior? > > Thank you for your time, (FWIW since I'm the only one who actually works on the FITS module this is basically just a question for me, especially for something at this level.) Is this expected behavior? Yes and no. It's expected to me because I read the code. It may not be expected to a user (in your case it wasn't). There's nothing particularly deliberate or designed about that--it just has to do with where the code that does various manipulations live. The pyfits "Column" class is not as well designed as the astropy.table Column class, and shouldn't generally be used on its own outside the context of setting up a table. The fact that you can get to its .array attribute (or that that even exists at all) is a somewhat unfortunate misfeature I've had the "fun" of having to carry around. So I wouldn't worry about this. Erik _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Wed Feb 25 10:56:36 2015 From: embray at stsci.edu (Erik Bray) Date: Wed, 25 Feb 2015 10:56:36 -0500 Subject: [AstroPy] Fits table creation: format repeats array: should I expect this? In-Reply-To: References: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu>, <54EDEBE8.7030702@stsci.edu> Message-ID: <54EDF0B4.6090705@stsci.edu> Out of curiosity, what was the end-around? Was there something specific you were trying to accomplish? I think in general if you want the Column's array to have the correct shape when the Column is created, then the array should just be given the correct shape in the first place. I think later when you add a Column to the table, it creates the recarray structure *first* based on the formats specified for the Columns. Then it takes the arrays already attached to those columns and fills the columns in the recarray with them (in the case of your example that's where the broadcasting kicks in, and it fills all 4096 elements in that column). On 02/25/2015 10:53 AM, Jonathan Eisenhamer wrote: > Then worry I shall not. In anticipation of just this answer I have done the > end-around. > > Thanks! > jde > > > -------- Original message -------- > From: Erik Bray > Date:2015/02/25 10:36 (GMT-05:00) > To: astropy at scipy.org > Subject: Re: [AstroPy] Fits table creation: format repeats array: should I > expect this? > > On 02/24/2015 06:06 PM, Jonathan Eisenhamer wrote: >> Greetings, >> >> Basic FITS io question. I do the following, which comes basically from the >> example in the astropy docs: >> from astropy.io import fits >> import numpy as np >> >> a = np.arange(100.0) >> col = fits.Column(name='a100', format='4096E', array=a) >> coldefs = fits.ColDefs([col]) >> hdu = fits.BinTableHDU.from_columns(coldefs) >> >> The array association with the column is "correct", in that the shape of a is >> (100,). >> >> Except after it has been put into the HDU. Now the array for the column has >> shape (100, 4096): >> >> hdu.columns[0].array.shape >> -> (100, 4096) >> >> Clearly this is because of the format. And at some level this makes sense, but a >> couple questions: >> >> * Why does the format not affect the array until the HDU is created? I.e. The >> col has just the basic array in it. >> * Is this expected behavior? >> >> Thank you for your time, > > (FWIW since I'm the only one who actually works on the FITS module this is > basically just a question for me, especially for something at this level.) > > Is this expected behavior? Yes and no. It's expected to me because I read the > code. It may not be expected to a user (in your case it wasn't). There's > nothing particularly deliberate or designed about that--it just has to do with > where the code that does various manipulations live. > > The pyfits "Column" class is not as well designed as the astropy.table Column > class, and shouldn't generally be used on its own outside the context of setting > up a table. The fact that you can get to its .array attribute (or that that > even exists at all) is a somewhat unfortunate misfeature I've had the "fun" of > having to carry around. So I wouldn't worry about this. > > Erik > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From eisenhamer at stsci.edu Wed Feb 25 11:17:39 2015 From: eisenhamer at stsci.edu (Jonathan Eisenhamer) Date: Wed, 25 Feb 2015 16:17:39 +0000 Subject: [AstroPy] Fits table creation: format repeats array: should I expect this? In-Reply-To: <54EDF0B4.6090705@stsci.edu> References: <6788A02107EA644693721D7DEF3F408B477D1316@EXCHMAIL1.stsci.edu>, <54EDEBE8.7030702@stsci.edu> , <54EDF0B4.6090705@stsci.edu> Message-ID: <46ebncm6fh2i8aw97rdecofr.1424881053209@email.android.com> The end around is basically what you describe: read out the table into an np.array, do the required rearrangement, then simply create a new table. Before I was trying to cheat by just just modifying the arrays directly. An admittedly bad approach. It just took me by surprise as to exactly where the cheat broke things. -------- Original message -------- From: Erik Bray Date:2015/02/25 10:56 (GMT-05:00) To: Astronomical Python mailing list Subject: Re: [AstroPy] Fits table creation: format repeats array: should I expect this? Out of curiosity, what was the end-around? Was there something specific you were trying to accomplish? I think in general if you want the Column's array to have the correct shape when the Column is created, then the array should just be given the correct shape in the first place. I think later when you add a Column to the table, it creates the recarray structure *first* based on the formats specified for the Columns. Then it takes the arrays already attached to those columns and fills the columns in the recarray with them (in the case of your example that's where the broadcasting kicks in, and it fills all 4096 elements in that column). On 02/25/2015 10:53 AM, Jonathan Eisenhamer wrote: > Then worry I shall not. In anticipation of just this answer I have done the > end-around. > > Thanks! > jde > > > -------- Original message -------- > From: Erik Bray > Date:2015/02/25 10:36 (GMT-05:00) > To: astropy at scipy.org > Subject: Re: [AstroPy] Fits table creation: format repeats array: should I > expect this? > > On 02/24/2015 06:06 PM, Jonathan Eisenhamer wrote: >> Greetings, >> >> Basic FITS io question. I do the following, which comes basically from the >> example in the astropy docs: >> from astropy.io import fits >> import numpy as np >> >> a = np.arange(100.0) >> col = fits.Column(name='a100', format='4096E', array=a) >> coldefs = fits.ColDefs([col]) >> hdu = fits.BinTableHDU.from_columns(coldefs) >> >> The array association with the column is "correct", in that the shape of a is >> (100,). >> >> Except after it has been put into the HDU. Now the array for the column has >> shape (100, 4096): >> >> hdu.columns[0].array.shape >> -> (100, 4096) >> >> Clearly this is because of the format. And at some level this makes sense, but a >> couple questions: >> >> * Why does the format not affect the array until the HDU is created? I.e. The >> col has just the basic array in it. >> * Is this expected behavior? >> >> Thank you for your time, > > (FWIW since I'm the only one who actually works on the FITS module this is > basically just a question for me, especially for something at this level.) > > Is this expected behavior? Yes and no. It's expected to me because I read the > code. It may not be expected to a user (in your case it wasn't). There's > nothing particularly deliberate or designed about that--it just has to do with > where the code that does various manipulations live. > > The pyfits "Column" class is not as well designed as the astropy.table Column > class, and shouldn't generally be used on its own outside the context of setting > up a table. The fact that you can get to its .array attribute (or that that > even exists at all) is a somewhat unfortunate misfeature I've had the "fun" of > having to carry around. So I wouldn't worry about this. > > Erik > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.figura at wartburg.edu Wed Feb 25 11:28:52 2015 From: charles.figura at wartburg.edu (Charles Figura) Date: Wed, 25 Feb 2015 10:28:52 -0600 Subject: [AstroPy] Font sizes in FITSFigure Message-ID: <1424881732.12376.7.camel@wartburg.edu> I'm making plots using aplpy's FITSFigure method. I'd like to change the font sizes for the axis labels, colourbar labels, titles - pretty much *everything*. I know that in most of these I can specify "size='medium', 'large', 'x-large', or 'xx-large' (for example). Is there any other graduation - or any way to specify intermediate sizes (i.e., by a numerical font size)? -Charlie -- Charles Figura charles.figura at wartburg.edu Professor of Physics and Astronomy http://mcsp.wartburg.edu/cfigura Director, Wartburg Platte Observatory http://mcsp.wartburg.edu/observatory (319) 352-8373 (319) 352-8606 (fax) "Ut visum notitia bona id temporis." From charles.figura at wartburg.edu Wed Feb 25 12:25:52 2015 From: charles.figura at wartburg.edu (Charles Figura) Date: Wed, 25 Feb 2015 11:25:52 -0600 Subject: [AstroPy] Font sizes in FITSFigure In-Reply-To: <1424881732.12376.7.camel@wartburg.edu> References: <1424881732.12376.7.camel@wartburg.edu> Message-ID: <1424885152.6309.1.camel@wartburg.edu> Let me make a correction - I have figured out how to change the label sizes using font sizes, that is all good. I'm having problems accessing the font sizes for the colorbar tick labels, however. If anyone has any pointers, that would be lovely. Thanks! On Wed, 2015-02-25 at 10:28 -0600, Charles Figura wrote: > I'm making plots using aplpy's FITSFigure method. I'd like to change > the font sizes for the axis labels, colourbar labels, titles - pretty > much *everything*. > > I know that in most of these I can specify "size='medium', 'large', > 'x-large', or 'xx-large' (for example). Is there any other graduation - > or any way to specify intermediate sizes (i.e., by a numerical font > size)? > > -Charlie > -- Charles Figura charles.figura at wartburg.edu Professor of Physics and Astronomy http://mcsp.wartburg.edu/cfigura Director, Wartburg Platte Observatory http://mcsp.wartburg.edu/observatory (319) 352-8373 (319) 352-8606 (fax) "Ut visum notitia bona id temporis."