From thomas.robitaille at gmail.com Mon Jun 2 02:14:49 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 02 Jun 2014 08:14:49 +0200 Subject: [AstroPy] Numerical issues with rotation_matrix In-Reply-To: <5380C2FE.5050708@arcor.de> References: <5380C2FE.5050708@arcor.de> Message-ID: <538C1659.20908@gmail.com> Hi Maik, Maik Riechert wrote: > Hi, > > I discovered today that astropy has a rotation_matrix function (in > coordinates.angles) and wanted to use it instead of the one from > Christoph Gohlke: > http://www.lfd.uci.edu/~gohlke/code/transformations.py.html > > While doing some testing, I noticed that the values differ between > > rotation_matrix(angle, [1,0,0]) > and > rotation_matrix(angle, 'x') > > The latter version agrees with Gohlke's function. The difference between > both versions in astropy is around the order of e-13 in my case, which > leads to severe differences in further processing. > > Looking at the source code it seems as if the general array version uses > sqrt and other things which may introduce numerical issues. > > I think a test case should be added which checks that 'x'/'y'/'z' > produces the same values as [1,0,0] etc. > > My test case: > >>>> import numpy as np >>>> from astropy.coordinates.angles import rotation_matrix as rot_astro >>>> from gohlke.transformations import rotation_matrix as rot_gohlke >>>> m1 = rot_astro(-0.07687069267192707, [1,0,0]) >>>> m2 = rot_astro(-0.07687069267192707, 'x') >>>> m2-m1 > matrix([[ 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], > [ 0.00000000e+00, 2.22044605e-16, 1.30859299e-13], > [ 0.00000000e+00, -1.30859299e-13, 2.22044605e-16]]) These differences are close to what might be expected for machine precision. However, I don't see why we couldn't try and recognize special cases (for example [1,0,0] -> x). In your case, why not simply use 'x' since it gives the expected result? Cheers, Tom > >>>> m3 = rot_gohlke(np.deg2rad(-0.07687069267192707), [-1,0,0])[:3,:3] >>>> m3-m2 > matrix([[ 0., 0., 0.], > [ 0., 0., 0.], > [ 0., 0., 0.]]) > > I'm not completely sure which one is the more accurate one. This has to > be validated. But if I should take a guess, it's m2/m3. > > Cheers > Maik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From triccare at gmail.com Thu Jun 5 15:22:53 2014 From: triccare at gmail.com (triccare triccare) Date: Thu, 5 Jun 2014 15:22:53 -0400 Subject: [AstroPy] Printing a whole table Message-ID: Greetings, A basic question: For astropy.tables, is there an options somewhere so that the call print an_astropy_table does not summarize the table? I know of the more() and show_in_browser() methods, but these have a hard time in ipython notebooks, and often just want to see the table. Thank you for your time! -------------- next part -------------- An HTML attachment was scrubbed... URL: From maik.riechert at arcor.de Thu Jun 5 17:13:41 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Thu, 05 Jun 2014 23:13:41 +0200 Subject: [AstroPy] Numerical issues with rotation_matrix In-Reply-To: <538C1659.20908@gmail.com> References: <5380C2FE.5050708@arcor.de> <538C1659.20908@gmail.com> Message-ID: <5390DD85.1040003@arcor.de> Hi Thomas, >>>>> import numpy as np >>>>> from astropy.coordinates.angles import rotation_matrix as rot_astro >>>>> from gohlke.transformations import rotation_matrix as rot_gohlke >>>>> m1 = rot_astro(-0.07687069267192707, [1,0,0]) >>>>> m2 = rot_astro(-0.07687069267192707, 'x') >>>>> m2-m1 >> matrix([[ 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], >> [ 0.00000000e+00, 2.22044605e-16, 1.30859299e-13], >> [ 0.00000000e+00, -1.30859299e-13, 2.22044605e-16]]) > > These differences are close to what might be expected for machine > precision. However, I don't see why we couldn't try and recognize > special cases (for example [1,0,0] -> x). In your case, why not simply > use 'x' since it gives the expected result? I did some more testing and used sympy (symbolic execution/arbitrary precision floats) to give me the "ground truth". For example, using an angle of 0.000004deg the difference between sympy and gohlke/astropy's special cases is at most e-18. When an array is used with astropy, the difference is e-7, which I think is significant as it may add up when multiple rotations are combined. Tell me if you like to see the test code, then I prettify it a bit. Cheers Maik From eebanado at uc.cl Thu Jun 5 18:09:19 2014 From: eebanado at uc.cl (=?UTF-8?Q?Eduardo_Ba=C3=B1ados_Torres?=) Date: Fri, 6 Jun 2014 00:09:19 +0200 Subject: [AstroPy] Printing a whole table In-Reply-To: References: Message-ID: Hi, reading the docs I think this is what you want: t.pprint(max_lines=-1, max_width=-1) # Print full table no matter how long / wide it is where t is an_astropy_table in your example. I hope it helps. Cheers On Thu, Jun 5, 2014 at 9:22 PM, triccare triccare wrote: > Greetings, > > A basic question: For astropy.tables, is there an options somewhere so > that the call > > print an_astropy_table > > does not summarize the table? > > I know of the more() and show_in_browser() methods, but these have a hard > time in ipython notebooks, and often just want to see the table. > > Thank you for your time! > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Eduardo Ba?ados -------------- next part -------------- An HTML attachment was scrubbed... URL: From triccare at gmail.com Thu Jun 5 21:02:23 2014 From: triccare at gmail.com (triccare triccare) Date: Thu, 5 Jun 2014 21:02:23 -0400 Subject: [AstroPy] Printing a whole table In-Reply-To: References: Message-ID: And that would be it! Thanks! On Thursday, June 5, 2014, Eduardo Ba?ados Torres wrote: > Hi, > > reading the docs I think this is what you want: > > t.pprint(max_lines=-1, max_width=-1) # Print full table no matter how long / wide it is > > where t is an_astropy_table in your example. > > I hope it helps. > > > Cheers > > On Thu, Jun 5, 2014 at 9:22 PM, triccare triccare > wrote: > >> Greetings, >> >> A basic question: For astropy.tables, is there an options somewhere so >> that the call >> >> print an_astropy_table >> >> does not summarize the table? >> >> I know of the more() and show_in_browser() methods, but these have a hard >> time in ipython notebooks, and often just want to see the table. >> >> Thank you for your time! >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > > > -- > Eduardo Ba?ados > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Sat Jun 7 17:03:40 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sat, 7 Jun 2014 15:03:40 -0600 Subject: [AstroPy] astropy.org domain temporarily down Message-ID: Hello all, Our astropy.org domain name is currently out of service. This seems to be due to a new ICANN registration process that was not completed when we transferred the domain to NumFOCUS. It requires someone at NumFOCUS to fully fix, so it's possible it will be down all weekend if the relevant parties aren't available until Monday. In the meantime, you can use the below links to reach the main astropy site, the docs for the latest stable version, and the dev docs. http://astropy.github.io http://astropy.readthedocs.org/en/stable/ http://astropy.readthedocs.org/en/latest/ Sorry for the inconvenience! Also note that, because of this, and some modeling subpackage items that need to be finalized, we may have to push the release of 0.4 back another week. -- Erik T From erik.tollerud at gmail.com Sat Jun 7 19:38:13 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sat, 7 Jun 2014 17:38:13 -0600 Subject: [AstroPy] Numerical issues with rotation_matrix In-Reply-To: <5390DD85.1040003@arcor.de> References: <5380C2FE.5050708@arcor.de> <538C1659.20908@gmail.com> <5390DD85.1040003@arcor.de> Message-ID: Hello Maik, Just to clarify something: `rotation_matrix` is technically not part of the public API for astropy. It's mainly used internally in coordinates. Furthermore, it's not actually used internally for anything other than the 'x', 'y', and 'z' use cases. So just be aware that this function comes with no "guarantees" like we do for the public API. If you actually look at the code, you'll see the matricies for the 'x', 'y', and 'z' cases are constructed quite differently from the generic angle, such that we do *not* expect them to come out exactly the same to machine precision. So I think special-casing [1,0,0], [0,1,0], and [0,0,1] to be the same as 'x', 'y', and 'z' is bad, because it would cause discontinuous jumps when you're using the axis-specified form. So I would say the fact that they are not the same to machine precision is a feature, not a bug (because the 'x'/'y'/'z' cases are quite a bit faster to run). I am concerned about the "When an array is used with astropy, the difference is e-7" bit, though: can you clarify a bit more what you mean by "when an array is used with astropy"? On Thu, Jun 5, 2014 at 3:13 PM, Maik Riechert wrote: > Hi Thomas, > >>>>>> import numpy as np >>>>>> from astropy.coordinates.angles import rotation_matrix as rot_astro >>>>>> from gohlke.transformations import rotation_matrix as rot_gohlke >>>>>> m1 = rot_astro(-0.07687069267192707, [1,0,0]) >>>>>> m2 = rot_astro(-0.07687069267192707, 'x') >>>>>> m2-m1 >>> matrix([[ 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], >>> [ 0.00000000e+00, 2.22044605e-16, 1.30859299e-13], >>> [ 0.00000000e+00, -1.30859299e-13, 2.22044605e-16]]) >> >> These differences are close to what might be expected for machine >> precision. However, I don't see why we couldn't try and recognize >> special cases (for example [1,0,0] -> x). In your case, why not simply >> use 'x' since it gives the expected result? > > I did some more testing and used sympy (symbolic execution/arbitrary > precision floats) to give me the "ground truth". For example, using an > angle of 0.000004deg the difference between sympy and gohlke/astropy's > special cases is at most e-18. When an array is used with astropy, the > difference is e-7, which I think is significant as it may add up when > multiple rotations are combined. > > Tell me if you like to see the test code, then I prettify it a bit. > > Cheers > Maik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Erik T From rays at blue-cove.com Sat Jun 7 22:57:37 2014 From: rays at blue-cove.com (RayS) Date: Sat, 07 Jun 2014 19:57:37 -0700 Subject: [AstroPy] astropy.org domain temporarily down In-Reply-To: References: Message-ID: <201406080257.s582veFt020333@blue-cove.com> You may want to make an edit in the wikipedia page - I'm afraid I'd forget to un-edit if I did. - Ray S At 02:03 PM 6/7/2014, you wrote: >Hello all, > >Our astropy.org domain name is currently out of service. This seems >to be due to a new ICANN registration process that was not completed >when we transferred the domain to NumFOCUS. It requires someone at >NumFOCUS to fully fix, so it's possible it will be down all weekend if the >relevant parties aren't available until Monday. > >In the meantime, you can use the below links to reach the main astropy >site, the docs for the latest stable version, and the dev docs. > >http://astropy.github.io >http://astropy.readthedocs.org/en/stable/ >http://astropy.readthedocs.org/en/latest/ > > >Sorry for the inconvenience! Also note that, because of this, and >some modeling subpackage items that need to be finalized, we may have >to push the release of 0.4 back another week. > > > >-- >Erik T >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Sun Jun 8 01:32:09 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sat, 7 Jun 2014 23:32:09 -0600 Subject: [AstroPy] astropy.org domain temporarily down In-Reply-To: References: Message-ID: It looks like we have managed to get the domain and subdomains back up an running again (fingers crossed it stays that way!) It may be 24-48 hrs before everything gets propagated through the DNS, so it's possible some places will have trouble accessing the various astropy.org subdomains until then. On Sat, Jun 7, 2014 at 3:03 PM, Erik Tollerud wrote: > Hello all, > > Our astropy.org domain name is currently out of service. This seems > to be due to a new ICANN registration process that was not completed > when we transferred the domain to NumFOCUS. It requires someone at > NumFOCUS to fully fix, so it's possible it will be down all weekend if the > relevant parties aren't available until Monday. > > In the meantime, you can use the below links to reach the main astropy > site, the docs for the latest stable version, and the dev docs. > > http://astropy.github.io > http://astropy.readthedocs.org/en/stable/ > http://astropy.readthedocs.org/en/latest/ > > > Sorry for the inconvenience! Also note that, because of this, and > some modeling subpackage items that need to be finalized, we may have > to push the release of 0.4 back another week. > > > > -- > Erik T -- Erik T From maik.riechert at arcor.de Sun Jun 8 13:41:21 2014 From: maik.riechert at arcor.de (Maik Riechert) Date: Sun, 08 Jun 2014 19:41:21 +0200 Subject: [AstroPy] Numerical issues with rotation_matrix In-Reply-To: References: <5380C2FE.5050708@arcor.de> <538C1659.20908@gmail.com> <5390DD85.1040003@arcor.de> Message-ID: <5394A041.7070401@arcor.de> Hi Erik, Ok, thanks for the clarification. Let me rephrase the last sentences: For example, using an angle of 0.000004deg the difference between sympy (=ground truth) and using either Gohlke's rotation_matrix or astropy's 'x','y','z' special cases is in both cases identical and at most e-18. So that's fine. When I use the general form of astropy's rotation_matrix though (meaning the second argument is [1,0,0] instead of 'x' etc.) the difference is e-7 (for the same angle as above), which I think is significant as it may add up when multiple rotations are combined by matrix multiplications. Even if it's not strictly part of the public API, people will find it and it may not be clear that it's internal and should not be used (as the internal API may change). Also, it is contained in a more advanced example, though again just using the special string cases as axis: https://astropy.readthedocs.org/en/stable/coordinates/sgr-example.html Let me shortly explain why I don't use 'x','y','z'. Basically I ported some C code for coordinate transformations (cxform) and there the axes of a rotation matrix are defined differently. So, without changing any of the formulas (as I didn't want to introduce bugs accidently) I had to define the axis for astropy's rotation_matrix as X = [-1,0,0] Y = [0,1,0] and Z = [0,0,-1]. My point is: Gohlke's version is more accurate for arbitrary axis definitions. I don't exactly know why but the numbers seem right. So, being a semi-public API function, I would either: use Gohlke's (or equivalent) version to get rid of the accuracy degradation, or: remove support for arbitrary axes in the meanwhile and just raise an exception. Anything else I think is not up to the standard of astropy. If both ways are not what you want, then at least add a warning into the doc string saying that using an array as axis may degrade accuracy especially for small angles. Cheers Maik Am 08.06.2014 01:38, schrieb Erik Tollerud: > Hello Maik, > > Just to clarify something: `rotation_matrix` is technically not part > of the public API for astropy. It's mainly used internally in > coordinates. Furthermore, it's not actually used internally for > anything other than the 'x', 'y', and 'z' use cases. So just be aware > that this function comes with no "guarantees" like we do for the > public API. > > If you actually look at the code, you'll see the matricies for the > 'x', 'y', and 'z' cases are constructed quite differently from the > generic angle, such that we do *not* expect them to come out exactly > the same to machine precision. So I think special-casing [1,0,0], > [0,1,0], and [0,0,1] to be the same as 'x', 'y', and 'z' is bad, > because it would cause discontinuous jumps when you're using the > axis-specified form. So I would say the fact that they are not the > same to machine precision is a feature, not a bug (because the > 'x'/'y'/'z' cases are quite a bit faster to run). > > I am concerned about the "When an array is used with astropy, the > difference is e-7" bit, though: can you clarify a bit more what you > mean by "when an array is used with astropy"? > > > > > On Thu, Jun 5, 2014 at 3:13 PM, Maik Riechert wrote: >> Hi Thomas, >> >>>>>>> import numpy as np >>>>>>> from astropy.coordinates.angles import rotation_matrix as rot_astro >>>>>>> from gohlke.transformations import rotation_matrix as rot_gohlke >>>>>>> m1 = rot_astro(-0.07687069267192707, [1,0,0]) >>>>>>> m2 = rot_astro(-0.07687069267192707, 'x') >>>>>>> m2-m1 >>>> matrix([[ 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], >>>> [ 0.00000000e+00, 2.22044605e-16, 1.30859299e-13], >>>> [ 0.00000000e+00, -1.30859299e-13, 2.22044605e-16]]) >>> >>> These differences are close to what might be expected for machine >>> precision. However, I don't see why we couldn't try and recognize >>> special cases (for example [1,0,0] -> x). In your case, why not simply >>> use 'x' since it gives the expected result? >> >> I did some more testing and used sympy (symbolic execution/arbitrary >> precision floats) to give me the "ground truth". For example, using an >> angle of 0.000004deg the difference between sympy and gohlke/astropy's >> special cases is at most e-18. When an array is used with astropy, the >> difference is e-7, which I think is significant as it may add up when >> multiple rotations are combined. >> >> Tell me if you like to see the test code, then I prettify it a bit. >> >> Cheers >> Maik >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > From aldcroft at head.cfa.harvard.edu Mon Jun 9 17:56:33 2014 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 9 Jun 2014 17:56:33 -0400 Subject: [AstroPy] Talk on Python and the LSST data processing system Message-ID: Last week at the Center for Astrophysics we had a talk in our Code Coffee series by Mario Juric, who is the LSST Data Management Project Scientist. In addition to discussion of the mind blowing computing requirements, he showed that the Data Processing System is being built in Python wherever possible, and in an open development environment. This is all really awesome stuff and I wanted to share the talk abstract and slides from Mario's site: http://research.majuric.org/wp/talk-cfa-jun-4-2014/ Cheers, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From cslocum at stsci.edu Wed Jun 11 12:05:48 2014 From: cslocum at stsci.edu (Christine Slocum) Date: Wed, 11 Jun 2014 16:05:48 +0000 Subject: [AstroPy] STScI Software Release Announcement Message-ID: <70621912E37CB34F855F6EA387CF0202222FD861@EXCHMAIL2.stsci.edu> STScI and Gemini are announcing the release of Ureka 1.4. This release includes the latest releases of the following major packages: * HSTCAL: * Major change: CALSTIS now part of HSTCAL and no longer supported as part of STSDAS. * ?Release Notes * This package can also be installed on its own outside of Ureka using these ?instructions for stand-alone installation. * STSDAS and Tables v3.17: * Development Note: No more new development is planned for STSDAS or Tables. * ?Release Notes * This package can also be installed under a separate version of IRAF outside of Ureka using these ?instructions for stand-alone installation. * STScI_Python v2.15.1: * ?Release Notes * Full set of API documentation ?can be accessed online. * This package can also be installed on its own outside of Ureka using these ?instructions for stand-alone installation. Improvements (with respect to 1.0): * Support for Ubuntu 14.04 and Fedora 20 * Compatibility with Scisoft environment * Added Astromatic Source Extractor (SExtractor) * Added FFTW * Added fitsverify * Upgraded to DS9 7.2 New Python packages: astroid 1.0.1 pyFFTW 0.9.2 MarkupSafe 0.19 distribute 0.7.3 Updated Python packages: Pygments 1.6 wheel 0.23.0 py 1.4.20 Pillow 2.4.0 stistools 1.0.2 wfc3tools 1.3 jsonschema 2.3.0 acstools 1.7.3 calcos 2.21 sympy 0.7.5 costools 1.2 virtualenv 1.11.4 Cython 0.20.1 pyfits 3.2.4 numpy 1.8.1 basemap 1.0.7 matplotlib 1.3.1 pexpect 3.1 logilab-common 0.61.0 six 1.6.1 ipython 2.0.0 stwcs 1.1.2 pandokia 1.3.3 nictools 1.1.1 pytest 2.5.2 multidrizzle 3.4.2 pywcs 1.12 pydrizzle 6.4.3 PyYAML 3.11 stsci.convolve 2.2.0 tornado 3.2 pylint 1.1.0 fitsblender 0.2.3 pandas 0.13.1 pip 1.5.4 stsci.tools 3.2.2 drizzlepac 1.1.16 stsci.distutils 0.3.7 pytz 2014.2 psycopg2 2.5.2 reftools 1.6.5 setuptools 3.4.2 astrolib.coords 0.39.5 Pmw 2.0.0 scipy 0.14.0 pyraf 2.1.6 Sphinx 1.2.2 urwid 1.2.1 astropy 0.3.2 wfpc2tools 1.0.2 Jinja2 2.7.2 logilab-astng 0.24.3 Ureka is a binary packaging installer for common astronomical software (primarily for the UV/Optical/IR community). The goals of the Ureka installer are to: 1) minimize the number of actions needed to install all the different software components. We are seeking a "one button install" (it's not quite one button, but not far from it). 2) permit installation without requiring system privileges. 3) make installs as problem-free as possible for the great majority of users. 4) allow users to install their own software (particularly Python-based) within this framework, or update versions of software within the framework. 5) permit different Ureka installations to coexist and to easily switch between them. 6) enable installing different versions of the same software package under a particular Ureka installation. 7) support Macs and most popular Linux variants. Ureka does not use LD_LIBRARY_PATH (or its Mac equivalent), nor require PYTHONPATH, minimizing the possibility of affecting existing software after installation or use. Should conflicts nevertheless arise, Ureka can easily be disabled temporarily or enabled only in specific terminal windows. Keep in mind that no installation system is completely foolproof (that's very nearly impossible to achieve). In particular, when users update or add software to the Ureka framework, they increase the risk of breaking something, but we feel that is an option that users should have as long as they understand the possible risks. This release includes IRAF 2.16 and associated packages for IRAF, DS9, and a fairly full suite of Python scientific software packages (e.g., numpy, scipy, and matplotlib). The full listing of included software can be found at this link: ?http://ssb.stsci.edu/ureka/1.4/docs/components.html Ureka can be downloaded from: ?http://ssb.stsci.edu/ureka/ (choose "1.4"). Installation and usage instructions can be found on the same web page. Please send questions or feedback to ?help at stsci.edu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at mumford.me.uk Wed Jun 11 14:10:13 2014 From: stuart at mumford.me.uk (Stuart Mumford) Date: Wed, 11 Jun 2014 19:10:13 +0100 Subject: [AstroPy] WCS reprojection Message-ID: Hello, I am looking for a way to change the projection of my solar image data. Specifically to re-project my TAN projected helioprojective Cartesian data array into a CAR Plate carree projected heliographic map. The only thing that I could find that looks like it might be able to do this is Kapteyn's coord_map function ( https://www.astro.rug.nl/software/kapteyn/wcs.html#function-coordmap). Are there other options? Is this possible using astropy.wcs? Any suggestions are welcome. Thanks Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Wed Jun 11 14:30:34 2014 From: d.berry at jach.hawaii.edu (David Berry) Date: Wed, 11 Jun 2014 19:30:34 +0100 Subject: [AstroPy] WCS reprojection In-Reply-To: References: Message-ID: On 11 June 2014 19:10, Stuart Mumford wrote: > Hello, > > I am looking for a way to change the projection of my solar image data. > Specifically to re-project my TAN projected helioprojective Cartesian data > array into a CAR Plate carree projected heliographic map. pyast can do that sort of thing. The attached script will re-project a given input image so that it aligned with a given reference image. So if your input image is in TAN projection and you can create a reference image in CAR projection, it should do the job. If you do not have a CAR image, the script could be modified to create a suitable header for you from scratch. David > The only thing that I could find that looks like it might be able to do this > is Kapteyn's coord_map function > (https://www.astro.rug.nl/software/kapteyn/wcs.html#function-coordmap). Are > there other options? Is this possible using astropy.wcs? > > Any suggestions are welcome. > > Thanks > Stuart > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- A non-text attachment was scrubbed... Name: wcsalign_starlink.py Type: text/x-python Size: 7426 bytes Desc: not available URL: From lsinger at caltech.edu Wed Jun 11 17:44:03 2014 From: lsinger at caltech.edu (Leo Singer) Date: Wed, 11 Jun 2014 14:44:03 -0700 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 Message-ID: Hi, What are the current options for generating plots in Python from FITS/WCS data? I know of at least two Matplotlib-based projects: APLpy, http://aplpy.github.io Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ Both generate very nice looking output. APLpy is under active development, but Pywcsgrid2 hasn't seen new patches in about a year. These two projects have rather different designs. APLpy provides high-level operations built out of Matplotlib calls. On the other hand, Pywcsgrid2 is an Axes subclass that lets you use any Matplotlib plotting command, but in world or pixel coordinates. I see the advantages of both approaches. The latter works better for me, because I often find that my plots involve delving into what I consider relatively esoteric Matplotlib techniques, such as insets, z-order, and annotation styles. For me, Pywcsgrid2 works well because in almost every respect I am dealing with an ordinary Matplotlib figure. Pywcsgrid2 needs some patches to work with the latest version of Astropy. I am working on getting them upstream, but I am considering forking the project if it is not being maintained. It looks like APLpy and Astropy have many of the same committers, so I thought I would ask here: would there be any interest in incorporating a Pywcsgrid2-like axes subclass into APLpy, to support either paradigm? Are there other Python-based astronomical plotting projects should I be aware of? Leo From tim.jenness at gmail.com Wed Jun 11 17:45:24 2014 From: tim.jenness at gmail.com (Tim Jenness) Date: Wed, 11 Jun 2014 14:45:24 -0700 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: References: Message-ID: pyast also plots WCS grids and can use matplotlib (but the plotting backend is pluggable so you can put your own in as well). -- Tim Jenness On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer wrote: > Hi, > > What are the current options for generating plots in Python from FITS/WCS > data? I know of at least two Matplotlib-based projects: > > APLpy, http://aplpy.github.io > Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ > > Both generate very nice looking output. APLpy is under active development, > but Pywcsgrid2 hasn't seen new patches in about a year. > > These two projects have rather different designs. APLpy provides > high-level operations built out of Matplotlib calls. On the other hand, > Pywcsgrid2 is an Axes subclass that lets you use any Matplotlib plotting > command, but in world or pixel coordinates. > > I see the advantages of both approaches. The latter works better for me, > because I often find that my plots involve delving into what I consider > relatively esoteric Matplotlib techniques, such as insets, z-order, and > annotation styles. For me, Pywcsgrid2 works well because in almost every > respect I am dealing with an ordinary Matplotlib figure. > > Pywcsgrid2 needs some patches to work with the latest version of Astropy. > I am working on getting them upstream, but I am considering forking the > project if it is not being maintained. It looks like APLpy and Astropy have > many of the same committers, so I thought I would ask here: would there be > any interest in incorporating a Pywcsgrid2-like axes subclass into APLpy, > to support either paradigm? > > Are there other Python-based astronomical plotting projects should I be > aware of? > > Leo > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Wed Jun 11 17:48:35 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 11 Jun 2014 17:48:35 -0400 Subject: [AstroPy] Numerical issues with rotation_matrix In-Reply-To: <5394A041.7070401@arcor.de> References: <5380C2FE.5050708@arcor.de> <538C1659.20908@gmail.com> <5390DD85.1040003@arcor.de> <5394A041.7070401@arcor.de> Message-ID: Hello Maik, Your suggestion here makes sense, so I went ahead and made https://github.com/astropy/astropy/pull/2619 , which fixes the arbitrary-axis case to be consistent in sign convention and uses an algorithm that *should* be equivalent to Gohlke's. Feel free to check that out and comment on github if that addresses the accuracy issues (or, if you feel up to it, suggest some test code that I can add there to ensure the higher accuracy) On Sun, Jun 8, 2014 at 1:41 PM, Maik Riechert wrote: > Hi Erik, > > Ok, thanks for the clarification. > > Let me rephrase the last sentences: > > For example, using an angle of 0.000004deg the difference between sympy > (=ground truth) and using either Gohlke's rotation_matrix or astropy's > 'x','y','z' special cases is in both cases identical and at most e-18. > So that's fine. When I use the general form of astropy's rotation_matrix > though (meaning the second argument is [1,0,0] instead of 'x' etc.) the > difference is e-7 (for the same angle as above), which I think is > significant as it may add up when multiple rotations are combined by > matrix multiplications. > > Even if it's not strictly part of the public API, people will find it > and it may not be clear that it's internal and should not be used (as > the internal API may change). Also, it is contained in a more advanced > example, though again just using the special string cases as axis: > > https://astropy.readthedocs.org/en/stable/coordinates/sgr-example.html > > Let me shortly explain why I don't use 'x','y','z'. Basically I ported > some C code for coordinate transformations (cxform) and there the axes > of a rotation matrix are defined differently. So, without changing any > of the formulas (as I didn't want to introduce bugs accidently) I had to > define the axis for astropy's rotation_matrix as X = [-1,0,0] Y = > [0,1,0] and Z = [0,0,-1]. > > My point is: Gohlke's version is more accurate for arbitrary axis > definitions. I don't exactly know why but the numbers seem right. So, > being a semi-public API function, I would either: use Gohlke's (or > equivalent) version to get rid of the accuracy degradation, or: remove > support for arbitrary axes in the meanwhile and just raise an exception. > Anything else I think is not up to the standard of astropy. If both ways > are not what you want, then at least add a warning into the doc string > saying that using an array as axis may degrade accuracy especially for > small angles. > > Cheers > Maik > > Am 08.06.2014 01:38, schrieb Erik Tollerud: >> Hello Maik, >> >> Just to clarify something: `rotation_matrix` is technically not part >> of the public API for astropy. It's mainly used internally in >> coordinates. Furthermore, it's not actually used internally for >> anything other than the 'x', 'y', and 'z' use cases. So just be aware >> that this function comes with no "guarantees" like we do for the >> public API. >> >> If you actually look at the code, you'll see the matricies for the >> 'x', 'y', and 'z' cases are constructed quite differently from the >> generic angle, such that we do *not* expect them to come out exactly >> the same to machine precision. So I think special-casing [1,0,0], >> [0,1,0], and [0,0,1] to be the same as 'x', 'y', and 'z' is bad, >> because it would cause discontinuous jumps when you're using the >> axis-specified form. So I would say the fact that they are not the >> same to machine precision is a feature, not a bug (because the >> 'x'/'y'/'z' cases are quite a bit faster to run). >> >> I am concerned about the "When an array is used with astropy, the >> difference is e-7" bit, though: can you clarify a bit more what you >> mean by "when an array is used with astropy"? >> >> >> >> >> On Thu, Jun 5, 2014 at 3:13 PM, Maik Riechert wrote: >>> Hi Thomas, >>> >>>>>>>> import numpy as np >>>>>>>> from astropy.coordinates.angles import rotation_matrix as rot_astro >>>>>>>> from gohlke.transformations import rotation_matrix as rot_gohlke >>>>>>>> m1 = rot_astro(-0.07687069267192707, [1,0,0]) >>>>>>>> m2 = rot_astro(-0.07687069267192707, 'x') >>>>>>>> m2-m1 >>>>> matrix([[ 0.00000000e+00, 0.00000000e+00, 0.00000000e+00], >>>>> [ 0.00000000e+00, 2.22044605e-16, 1.30859299e-13], >>>>> [ 0.00000000e+00, -1.30859299e-13, 2.22044605e-16]]) >>>> >>>> These differences are close to what might be expected for machine >>>> precision. However, I don't see why we couldn't try and recognize >>>> special cases (for example [1,0,0] -> x). In your case, why not simply >>>> use 'x' since it gives the expected result? >>> >>> I did some more testing and used sympy (symbolic execution/arbitrary >>> precision floats) to give me the "ground truth". For example, using an >>> angle of 0.000004deg the difference between sympy and gohlke/astropy's >>> special cases is at most e-18. When an array is used with astropy, the >>> difference is e-7, which I think is significant as it may add up when >>> multiple rotations are combined. >>> >>> Tell me if you like to see the test code, then I prettify it a bit. >>> >>> Cheers >>> Maik >>> _______________________________________________ >>> 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 -- Erik T From jzuhone at gmail.com Wed Jun 11 17:50:13 2014 From: jzuhone at gmail.com (John ZuHone) Date: Wed, 11 Jun 2014 17:50:13 -0400 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: References: Message-ID: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> The development version (v. 3.0, which is due for release within the next month or so) of yt (http://yt-project.org) supports FITS images: http://yt-project.org/docs/dev-3.0/examining/loading_data.html#fits-data These IPython notebooks show how to do plotting, which makes use of the (also in development) wcsaxes (http://wcsaxes.readthedocs.org) library for overplotting coordinates: http://yt-project.org/docs/dev-3.0/cookbook/fits_radio_cubes.html#radio-cubes http://yt-project.org/docs/dev-3.0/cookbook/fits_xray_images.html#xray-fits On Jun 11, 2014, at 5:45 PM, Tim Jenness wrote: > pyast also plots WCS grids and can use matplotlib (but the plotting backend is pluggable so you can put your own in as well). > > -- > Tim Jenness > > > On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer wrote: > Hi, > > What are the current options for generating plots in Python from FITS/WCS data? I know of at least two Matplotlib-based projects: > > APLpy, http://aplpy.github.io > Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ > > Both generate very nice looking output. APLpy is under active development, but Pywcsgrid2 hasn't seen new patches in about a year. > > These two projects have rather different designs. APLpy provides high-level operations built out of Matplotlib calls. On the other hand, Pywcsgrid2 is an Axes subclass that lets you use any Matplotlib plotting command, but in world or pixel coordinates. > > I see the advantages of both approaches. The latter works better for me, because I often find that my plots involve delving into what I consider relatively esoteric Matplotlib techniques, such as insets, z-order, and annotation styles. For me, Pywcsgrid2 works well because in almost every respect I am dealing with an ordinary Matplotlib figure. > > Pywcsgrid2 needs some patches to work with the latest version of Astropy. I am working on getting them upstream, but I am considering forking the project if it is not being maintained. It looks like APLpy and Astropy have many of the same committers, so I thought I would ask here: would there be any interest in incorporating a Pywcsgrid2-like axes subclass into APLpy, to support either paradigm? > > Are there other Python-based astronomical plotting projects should I be aware of? > > Leo > _______________________________________________ > 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 lsinger at caltech.edu Wed Jun 11 17:57:54 2014 From: lsinger at caltech.edu (Leo Singer) Date: Wed, 11 Jun 2014 14:57:54 -0700 Subject: [AstroPy] WCS reprojection In-Reply-To: References: Message-ID: > On Jun 11, 2014, at 11:10, Stuart Mumford wrote: > > Hello, > > I am looking for a way to change the projection of my solar image data. Specifically to re-project my TAN projected helioprojective Cartesian data array into a CAR Plate carree projected heliographic map. > > The only thing that I could find that looks like it might be able to do this is Kapteyn's coord_map function (https://www.astro.rug.nl/software/kapteyn/wcs.html#function-coordmap). Are there other options? Is this possible using astropy.wcs? > > Any suggestions are welcome. > > Thanks > Stuart Hi Stuart, If you were to do this in Astropy, the basic algorithm for nearest-neighbor mapping between the two projections would be: Construct new WCS object representing target projection Create array of pixels in target projection For each pixel, convert to world coordinates with WCS.wcs_pix2world Convert to pixel index in original projection with WCS.wcs_world2pix Retrieve value from original array, store in target array Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: From trive at astro.su.se Wed Jun 11 18:30:41 2014 From: trive at astro.su.se (=?UTF-8?B?VGjDuGdlciBFbWlsIFJpdmVyYS1UaG9yc2Vu?=) Date: Thu, 12 Jun 2014 00:30:41 +0200 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> References: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> Message-ID: <5398D891.5010209@astro.su.se> The Kapteyn package also has some quite nifty looking plotting capabilities (built on matplotlib). Have not actually used it though. http://www.astro.rug.nl/software/kapteyn/maputilstutorial.html#image-objects On Wed 11 Jun 2014 11:50:13 PM CEST, John ZuHone wrote: > The development version (v. 3.0, which is due for release within the > next month or so) of yt (http://yt-project.org) supports FITS images: > > http://yt-project.org/docs/dev-3.0/examining/loading_data.html#fits-data > > These IPython notebooks show how to do plotting, which makes use of > the (also in development) wcsaxes (http://wcsaxes.readthedocs.org) > library for overplotting coordinates: > > http://yt-project.org/docs/dev-3.0/cookbook/fits_radio_cubes.html#radio-cubes > http://yt-project.org/docs/dev-3.0/cookbook/fits_xray_images.html#xray-fits > > On Jun 11, 2014, at 5:45 PM, Tim Jenness > wrote: > >> pyast also plots WCS grids and can use matplotlib (but the plotting >> backend is pluggable so you can put your own in as well). >> >> -- >> Tim Jenness >> >> >> On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer > > wrote: >> >> Hi, >> >> What are the current options for generating plots in Python from >> FITS/WCS data? I know of at least two Matplotlib-based projects: >> >> APLpy, http://aplpy.github.io >> Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ >> >> Both generate very nice looking output. APLpy is under active >> development, but Pywcsgrid2 hasn't seen new patches in about a year. >> >> These two projects have rather different designs. APLpy provides >> high-level operations built out of Matplotlib calls. On the other >> hand, Pywcsgrid2 is an Axes subclass that lets you use any >> Matplotlib plotting command, but in world or pixel coordinates. >> >> I see the advantages of both approaches. The latter works better >> for me, because I often find that my plots involve delving into >> what I consider relatively esoteric Matplotlib techniques, such >> as insets, z-order, and annotation styles. For me, Pywcsgrid2 >> works well because in almost every respect I am dealing with an >> ordinary Matplotlib figure. >> >> Pywcsgrid2 needs some patches to work with the latest version of >> Astropy. I am working on getting them upstream, but I am >> considering forking the project if it is not being maintained. It >> looks like APLpy and Astropy have many of the same committers, so >> I thought I would ask here: would there be any interest in >> incorporating a Pywcsgrid2-like axes subclass into APLpy, to >> support either paradigm? >> >> Are there other Python-based astronomical plotting projects >> should I be aware of? >> >> Leo >> _______________________________________________ >> 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 From stuart at mumford.me.uk Wed Jun 11 19:03:49 2014 From: stuart at mumford.me.uk (Stuart Mumford) Date: Thu, 12 Jun 2014 00:03:49 +0100 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: <5398D891.5010209@astro.su.se> References: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> <5398D891.5010209@astro.su.se> Message-ID: Hi, There is also the WIP WCSAxes pacakge that sounds like it would be close to what you are after, http://wcsaxes.readthedocs.org/en/latest/, https://github.com/astrofrog/wcsaxes Stuart On 11 June 2014 23:30, Th?ger Emil Rivera-Thorsen wrote: > The Kapteyn package also has some quite nifty looking plotting > capabilities (built on matplotlib). Have not actually used it though. > > > http://www.astro.rug.nl/software/kapteyn/maputilstutorial.html#image-objects > > > > On Wed 11 Jun 2014 11:50:13 PM CEST, John ZuHone wrote: > > The development version (v. 3.0, which is due for release within the > > next month or so) of yt (http://yt-project.org) supports FITS images: > > > > http://yt-project.org/docs/dev-3.0/examining/loading_data.html#fits-data > > > > These IPython notebooks show how to do plotting, which makes use of > > the (also in development) wcsaxes (http://wcsaxes.readthedocs.org) > > library for overplotting coordinates: > > > > > http://yt-project.org/docs/dev-3.0/cookbook/fits_radio_cubes.html#radio-cubes > > > http://yt-project.org/docs/dev-3.0/cookbook/fits_xray_images.html#xray-fits > > > > On Jun 11, 2014, at 5:45 PM, Tim Jenness > > wrote: > > > >> pyast also plots WCS grids and can use matplotlib (but the plotting > >> backend is pluggable so you can put your own in as well). > >> > >> -- > >> Tim Jenness > >> > >> > >> On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer >> > wrote: > >> > >> Hi, > >> > >> What are the current options for generating plots in Python from > >> FITS/WCS data? I know of at least two Matplotlib-based projects: > >> > >> APLpy, http://aplpy.github.io > >> Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ > >> > >> Both generate very nice looking output. APLpy is under active > >> development, but Pywcsgrid2 hasn't seen new patches in about a year. > >> > >> These two projects have rather different designs. APLpy provides > >> high-level operations built out of Matplotlib calls. On the other > >> hand, Pywcsgrid2 is an Axes subclass that lets you use any > >> Matplotlib plotting command, but in world or pixel coordinates. > >> > >> I see the advantages of both approaches. The latter works better > >> for me, because I often find that my plots involve delving into > >> what I consider relatively esoteric Matplotlib techniques, such > >> as insets, z-order, and annotation styles. For me, Pywcsgrid2 > >> works well because in almost every respect I am dealing with an > >> ordinary Matplotlib figure. > >> > >> Pywcsgrid2 needs some patches to work with the latest version of > >> Astropy. I am working on getting them upstream, but I am > >> considering forking the project if it is not being maintained. It > >> looks like APLpy and Astropy have many of the same committers, so > >> I thought I would ask here: would there be any interest in > >> incorporating a Pywcsgrid2-like axes subclass into APLpy, to > >> support either paradigm? > >> > >> Are there other Python-based astronomical plotting projects > >> should I be aware of? > >> > >> Leo > >> _______________________________________________ > >> 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 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.weaver at nyu.edu Wed Jun 11 22:29:13 2014 From: benjamin.weaver at nyu.edu (Benjamin Alan Weaver) Date: Wed, 11 Jun 2014 22:29:13 -0400 Subject: [AstroPy] FITS_rec objects retain references to 'parent' objects, even when copied Message-ID: Hello y'all, Apologies if this is a well known, documented problem. You can just send me the URL if that's the case. Let's say I create a large numpy array: def foo(): import numpy as np from numpy.random import random a = random((100000,100)) index = np.arange(0,100000,5) b = a[index,:] # Use a complex index to force copy-on-slice assert not np.may_share_memory(a,b) # b is a copy, not a view. return b b = foo() After the call to foo(), only the memory associated with b remains. a goes out of scope, its memory is garbage-collected, everything is fine. Now suppose I do something similar with astropy.io.fits (assume that large_fits_file is a ~GB FITS file containing a FITS binary table in HDU 1): def bar(large_fits_file): import numpy as np import astropy.io.fits as pyfits f = pyfits.open(large_fits_file) index = np.arange(0,100000,5) bb = f[1].data[index] assert not np.may_share_memory(f[1].data,bb) # bb is a copy, not a view. return bb bb = bar(large_fits_file) After the call to bar, all the memory associated with f[1].data remains in memory, even though it has gone out of scope. Only when bb goes out of scope (or del bb) does the memory get released, even though we have shown that bb is a copy of the data not a view. Somehow bb is retaining a reference to the original data. The attached script uses the memory_profiler package (https://pypi.python.org/pypi/memory_profiler) to demonstrate this. So, what's going on here? Kia ora koutou, Benjamin Alan Weaver -- a.k.a. The Dream Weaver Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read. --Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: fits_memory.py Type: text/x-python-script Size: 891 bytes Desc: not available URL: From d.berry at jach.hawaii.edu Thu Jun 12 02:41:25 2014 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 12 Jun 2014 07:41:25 +0100 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: References: Message-ID: On 11 June 2014 22:45, Tim Jenness wrote: > pyast also plots WCS grids and can use matplotlib (but the plotting backend > is pluggable so you can put your own in as well). There is example plotting code in the section "...Display a Graphical Coordinate Grid" at http://dsberry.github.io/starlink/node4.html with some sample plots at the top of http://dsberry.github.io/starlink/pyast.html David > -- > Tim Jenness > > > On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer wrote: >> >> Hi, >> >> What are the current options for generating plots in Python from FITS/WCS >> data? I know of at least two Matplotlib-based projects: >> >> APLpy, http://aplpy.github.io >> Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ >> >> Both generate very nice looking output. APLpy is under active development, >> but Pywcsgrid2 hasn't seen new patches in about a year. >> >> These two projects have rather different designs. APLpy provides >> high-level operations built out of Matplotlib calls. On the other hand, >> Pywcsgrid2 is an Axes subclass that lets you use any Matplotlib plotting >> command, but in world or pixel coordinates. >> >> I see the advantages of both approaches. The latter works better for me, >> because I often find that my plots involve delving into what I consider >> relatively esoteric Matplotlib techniques, such as insets, z-order, and >> annotation styles. For me, Pywcsgrid2 works well because in almost every >> respect I am dealing with an ordinary Matplotlib figure. >> >> Pywcsgrid2 needs some patches to work with the latest version of Astropy. >> I am working on getting them upstream, but I am considering forking the >> project if it is not being maintained. It looks like APLpy and Astropy have >> many of the same committers, so I thought I would ask here: would there be >> any interest in incorporating a Pywcsgrid2-like axes subclass into APLpy, to >> support either paradigm? >> >> Are there other Python-based astronomical plotting projects should I be >> aware of? >> >> Leo >> _______________________________________________ >> 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 thomas.robitaille at gmail.com Thu Jun 12 02:47:45 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 12 Jun 2014 08:47:45 +0200 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: References: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> <5398D891.5010209@astro.su.se> Message-ID: <53994D11.7040507@gmail.com> Just to add some more details on WCSAxes - it is the main Astropy-related effort to develop this kind of functionality. The API document that was agreed on is here: https://github.com/astropy/astropy-api/blob/master/wcs_axes/wcs_api.md This was an effort by Jae-Joon Lee (author of pywcsgrid2) and myself to try and write a package as close as possible to Matplotlib while retaining some of the nice elements from pywcsgrid2 and APLpy. One of the Astropy GSoC students, Asra Nizami, is working on improving functionality, tests, and performance, and I anticipate that we will be able to have a first release of the package later during the summer. The plan is then to refactor APLpy (which provides a higher-level interface) to use WCSAxes internally. In the mean time, let us know if you try it out, and if you run into any issues! The docs are here: http://wcsaxes.readthedocs.org/en/latest/ Cheers, Tom Stuart Mumford wrote: > Hi, > > There is also the WIP WCSAxes pacakge that sounds like it would be close > to what you are after, http://wcsaxes.readthedocs.org/en/latest/, > https://github.com/astrofrog/wcsaxes > > Stuart > > > On 11 June 2014 23:30, Th?ger Emil Rivera-Thorsen > wrote: > > The Kapteyn package also has some quite nifty looking plotting > capabilities (built on matplotlib). Have not actually used it though. > > http://www.astro.rug.nl/software/kapteyn/maputilstutorial.html#image-objects > > > > On Wed 11 Jun 2014 11:50:13 PM CEST, John ZuHone wrote: > > The development version (v. 3.0, which is due for release within the > > next month or so) of yt (http://yt-project.org) supports FITS images: > > > > > http://yt-project.org/docs/dev-3.0/examining/loading_data.html#fits-data > > > > These IPython notebooks show how to do plotting, which makes use of > > the (also in development) wcsaxes (http://wcsaxes.readthedocs.org) > > library for overplotting coordinates: > > > > > http://yt-project.org/docs/dev-3.0/cookbook/fits_radio_cubes.html#radio-cubes > > > http://yt-project.org/docs/dev-3.0/cookbook/fits_xray_images.html#xray-fits > > > > On Jun 11, 2014, at 5:45 PM, Tim Jenness > > >> wrote: > > > >> pyast also plots WCS grids and can use matplotlib (but the plotting > >> backend is pluggable so you can put your own in as well). > >> > >> -- > >> Tim Jenness > >> > >> > >> On Wed, Jun 11, 2014 at 2:44 PM, Leo Singer > >> >> wrote: > >> > >> Hi, > >> > >> What are the current options for generating plots in Python from > >> FITS/WCS data? I know of at least two Matplotlib-based projects: > >> > >> APLpy, http://aplpy.github.io > >> Pywcsgrid2, http://leejjoon.github.io/pywcsgrid2/ > >> > >> Both generate very nice looking output. APLpy is under active > >> development, but Pywcsgrid2 hasn't seen new patches in about > a year. > >> > >> These two projects have rather different designs. APLpy provides > >> high-level operations built out of Matplotlib calls. On the other > >> hand, Pywcsgrid2 is an Axes subclass that lets you use any > >> Matplotlib plotting command, but in world or pixel coordinates. > >> > >> I see the advantages of both approaches. The latter works better > >> for me, because I often find that my plots involve delving into > >> what I consider relatively esoteric Matplotlib techniques, such > >> as insets, z-order, and annotation styles. For me, Pywcsgrid2 > >> works well because in almost every respect I am dealing with an > >> ordinary Matplotlib figure. > >> > >> Pywcsgrid2 needs some patches to work with the latest version of > >> Astropy. I am working on getting them upstream, but I am > >> considering forking the project if it is not being maintained. It > >> looks like APLpy and Astropy have many of the same committers, so > >> I thought I would ask here: would there be any interest in > >> incorporating a Pywcsgrid2-like axes subclass into APLpy, to > >> support either paradigm? > >> > >> Are there other Python-based astronomical plotting projects > >> should I be aware of? > >> > >> Leo > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 d.berry at jach.hawaii.edu Thu Jun 12 02:52:15 2014 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 12 Jun 2014 07:52:15 +0100 Subject: [AstroPy] WCS reprojection In-Reply-To: References: Message-ID: On 11 June 2014 19:30, David Berry wrote: > On 11 June 2014 19:10, Stuart Mumford wrote: >> Hello, >> >> I am looking for a way to change the projection of my solar image data. >> Specifically to re-project my TAN projected helioprojective Cartesian data >> array into a CAR Plate carree projected heliographic map. > > pyast can do that sort of thing. The attached script will re-project a > given input image so that it aligned with a given reference image. So > if your input image is in TAN projection and you can create a > reference image in CAR projection, it should do the job. If you do not > have a CAR image, the script could be modified to create a suitable > header for you from scratch. As it stands, the script uses bi-linear interpolation within the input pixel values to determine each output pixel value. But this can be changed easily, by changing the "Ast.LINEAR" constant passed to the resample method to one of the other interpolation methods supported by AST (see the section "Sub-Pixel Interpolation Schemes" at http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node385.html). Available methods include nearest neighbour, Gaussian, various forms of sinc interpolation, etc. David > David > > >> The only thing that I could find that looks like it might be able to do this >> is Kapteyn's coord_map function >> (https://www.astro.rug.nl/software/kapteyn/wcs.html#function-coordmap). Are >> there other options? Is this possible using astropy.wcs? >> >> Any suggestions are welcome. >> >> Thanks >> Stuart >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> From adam.g.ginsburg at gmail.com Thu Jun 12 03:27:34 2014 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Thu, 12 Jun 2014 09:27:34 +0200 Subject: [AstroPy] WCS reprojection In-Reply-To: References: Message-ID: I've implemented wrappers of both the process Leo outlined and the pyAST version (with help from Tim & David) as part of FITS_tools: https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py The latter tool, "wcsalign", is just a copy of the script David sent, but with a different docstring format. On Thu, Jun 12, 2014 at 8:52 AM, David Berry wrote: > On 11 June 2014 19:30, David Berry wrote: >> On 11 June 2014 19:10, Stuart Mumford wrote: >>> Hello, >>> >>> I am looking for a way to change the projection of my solar image data. >>> Specifically to re-project my TAN projected helioprojective Cartesian data >>> array into a CAR Plate carree projected heliographic map. >> >> pyast can do that sort of thing. The attached script will re-project a >> given input image so that it aligned with a given reference image. So >> if your input image is in TAN projection and you can create a >> reference image in CAR projection, it should do the job. If you do not >> have a CAR image, the script could be modified to create a suitable >> header for you from scratch. > > As it stands, the script uses bi-linear interpolation within the input > pixel values to determine each output pixel value. But this can be > changed easily, by changing the "Ast.LINEAR" constant passed to the > resample method to one of the other interpolation methods supported by > AST (see the section "Sub-Pixel Interpolation Schemes" at > http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node385.html). > Available methods include nearest neighbour, Gaussian, various forms > of sinc interpolation, etc. > > David > > > >> David >> >> >>> The only thing that I could find that looks like it might be able to do this >>> is Kapteyn's coord_map function >>> (https://www.astro.rug.nl/software/kapteyn/wcs.html#function-coordmap). Are >>> there other options? Is this possible using astropy.wcs? >>> >>> Any suggestions are welcome. >>> >>> Thanks >>> Stuart >>> >>> _______________________________________________ >>> 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 -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From lsinger at caltech.edu Thu Jun 12 13:46:43 2014 From: lsinger at caltech.edu (Leo Singer) Date: Thu, 12 Jun 2014 10:46:43 -0700 Subject: [AstroPy] plotting FITS/WCS in Python: APLpy, Pywcsgrid2 In-Reply-To: <53994D11.7040507@gmail.com> References: <9C10DE10-51E1-4B8C-A6E4-6A49BC06DDED@gmail.com> <5398D891.5010209@astro.su.se> <53994D11.7040507@gmail.com> Message-ID: <41EF996C-4315-4CB7-8717-13151C295BE0@caltech.edu> > On Jun 11, 2014, at 23:47, Thomas Robitaille wrote: > > Just to add some more details on WCSAxes - it is the main > Astropy-related effort to develop this kind of functionality. The API > document that was agreed on is here: > > https://github.com/astropy/astropy-api/blob/master/wcs_axes/wcs_api.md > > This was an effort by Jae-Joon Lee (author of pywcsgrid2) and myself to > try and write a package as close as possible to Matplotlib while > retaining some of the nice elements from pywcsgrid2 and APLpy. > > One of the Astropy GSoC students, Asra Nizami, is working on improving > functionality, tests, and performance, and I anticipate that we will be > able to have a first release of the package later during the summer. The > plan is then to refactor APLpy (which provides a higher-level interface) > to use WCSAxes internally. > > In the mean time, let us know if you try it out, and if you run into any > issues! The docs are here: > > http://wcsaxes.readthedocs.org/en/latest/ Hi Tom, This is just what I was looking for. I'm glad I asked! I have already started using it and I am quite happy with it. My only critique so far is that because the grid and tick lines are reimplemented rather than inherited from the base axes class, the default plotting style for those elements is not carried over... I've just sent two PRs on this topic. Thanks for developing this. Best, Leo From streetomon at gmail.com Fri Jun 13 08:59:56 2014 From: streetomon at gmail.com (=?UTF-8?Q?Andr=C3=A9_Luiz_de_Amorim?=) Date: Fri, 13 Jun 2014 09:59:56 -0300 Subject: [AstroPy] FITS_rec objects retain references to 'parent' objects, even when copied In-Reply-To: References: Message-ID: I had similar problems, the file descriptor of the fits file did not get freed after getting out of scope. As I was loading data from tons of files, I got "too many files open" exceptions. I did not investigate memory allocation, but it probably had the same problem you described. The cause, I suppose, is that pyfits uses memory mapped files, so that while the memory is still referenced, the fits object does not get collected. In my code, making the equivalent of bb = f[1].data[index].copy() solved the issue. Cheers, Andr?. On Wed, Jun 11, 2014 at 11:29 PM, Benjamin Alan Weaver < benjamin.weaver at nyu.edu> wrote: > Hello y'all, > > Apologies if this is a well known, documented problem. You can just > send me the URL if that's the case. > > Let's say I create a large numpy array: > > def foo(): > import numpy as np > from numpy.random import random > a = random((100000,100)) > index = np.arange(0,100000,5) > b = a[index,:] # Use a complex index to force copy-on-slice > assert not np.may_share_memory(a,b) # b is a copy, not a view. > return b > > b = foo() > > After the call to foo(), only the memory associated with b remains. a > goes out of scope, its memory is garbage-collected, everything is > fine. > > Now suppose I do something similar with astropy.io.fits (assume that > large_fits_file is a ~GB FITS file containing a FITS binary table in > HDU 1): > > def bar(large_fits_file): > import numpy as np > import astropy.io.fits as pyfits > f = pyfits.open(large_fits_file) > index = np.arange(0,100000,5) > bb = f[1].data[index] > assert not np.may_share_memory(f[1].data,bb) # bb is a copy, not a view. > return bb > > bb = bar(large_fits_file) > > After the call to bar, all the memory associated with f[1].data > remains in memory, even though it has gone out of scope. Only when bb > goes out of scope (or del bb) does the memory get released, even > though we have shown that bb is a copy of the data not a view. > Somehow bb is retaining a reference to the original data. > > The attached script uses the memory_profiler package > (https://pypi.python.org/pypi/memory_profiler) to demonstrate this. > > So, what's going on here? > > Kia ora koutou, > Benjamin Alan Weaver > > -- > a.k.a. The Dream Weaver > > Outside of a dog, a book is man's best friend. Inside of a dog it's > too dark to read. > --Groucho Marx > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Fri Jun 13 10:37:00 2014 From: embray at stsci.edu (Erik Bray) Date: Fri, 13 Jun 2014 10:37:00 -0400 Subject: [AstroPy] FITS_rec objects retain references to 'parent' objects, even when copied In-Reply-To: References: Message-ID: <539B0C8C.3060407@stsci.edu> On 06/11/2014 10:29 PM, Benjamin Alan Weaver wrote: > Hello y'all, > > Apologies if this is a well known, documented problem. You can just > send me the URL if that's the case. > > Let's say I create a large numpy array: > > def foo(): > import numpy as np > from numpy.random import random > a = random((100000,100)) > index = np.arange(0,100000,5) > b = a[index,:] # Use a complex index to force copy-on-slice > assert not np.may_share_memory(a,b) # b is a copy, not a view. > return b > > b = foo() > > After the call to foo(), only the memory associated with b remains. a > goes out of scope, its memory is garbage-collected, everything is > fine. > > Now suppose I do something similar with astropy.io.fits (assume that > large_fits_file is a ~GB FITS file containing a FITS binary table in > HDU 1): > > def bar(large_fits_file): > import numpy as np > import astropy.io.fits as pyfits > f = pyfits.open(large_fits_file) > index = np.arange(0,100000,5) > bb = f[1].data[index] > assert not np.may_share_memory(f[1].data,bb) # bb is a copy, not a view. > return bb > > bb = bar(large_fits_file) > > After the call to bar, all the memory associated with f[1].data > remains in memory, even though it has gone out of scope. Only when bb > goes out of scope (or del bb) does the memory get released, even > though we have shown that bb is a copy of the data not a view. > Somehow bb is retaining a reference to the original data. > > The attached script uses the memory_profiler package > (https://pypi.python.org/pypi/memory_profiler) to demonstrate this. > > So, what's going on here? Hi, this sort of issue might be better directed to the astropy-dev mailing list o'er here: https://groups.google.com/forum/#!forum/astropy-dev Since I think this mailing list is more for general discussion and questions. It's possible this is a known issue. The FITS_rec class is a mess, and there are a few known cases where it can result in a memory leak. See for example: https://github.com/astropy/astropy/pull/520 Some tables have this issue, some don't. In particular, I know that if your table contains large string columns this can happen. I'd be interested to see what the format of your particular table is--a dump of the header would do. My general response to this is that I would love to fix it, but I would love even more to spend that time on rewriting the FITS table interface altogether around Astropy's Table class. It's just one thing that keeps slipping behind, and is especially challenging due to the nature of how FITS natively stores some types of data. To that end I've been experimenting with implementing some new Numpy dtypes that are specifically for handling FITS table data. Erik From embray at stsci.edu Fri Jun 13 10:46:25 2014 From: embray at stsci.edu (Erik Bray) Date: Fri, 13 Jun 2014 10:46:25 -0400 Subject: [AstroPy] FITS_rec objects retain references to 'parent' objects, even when copied In-Reply-To: References: Message-ID: <539B0EC1.6010409@stsci.edu> On 06/13/2014 08:59 AM, Andr? Luiz de Amorim wrote: > I had similar problems, the file descriptor of the fits file did not get freed > after getting out of scope. As I was loading data from tons of files, I got "too > many files open" exceptions. I did not investigate memory allocation, but > it probably had the same problem you described. The cause, I suppose, is that > pyfits uses memory mapped files, so that while the memory is still referenced, > the fits object does not get collected. This is a somewhat orthogonal issue, I think, though not entirely unrelated. The use of mmap to read the data requires an open file handle as long a reference to the data is kept in the program. In general, as long as there are no more references to the data array the mmap is unmapped and the file descriptor it uses is freed. This is generally not a problem for normal data arrays, but in the case of a reference leak for FITS_rec that could lead to a problem. > In my code, making the equivalent of bb f[1].data[index].copy() solved the issue. Another workaround if necessary is to just disable the use of mmap, for example, by passing the memmap=False argument to fits.open(). In most cases the use of mmap is hugely beneficial. But there are cases where the benefit is lost, such as when the data needs to be transformed from the raw bytes on disk (on my "favorite" examples is how FITS represents boolean columns using the actual ASCII byte codes for 'T' and 'F'--this goes back to the need for specialized Numpy dtypes that know how to interpret FITS data natively...). Erik > On Wed, Jun 11, 2014 at 11:29 PM, Benjamin Alan Weaver > wrote: > > Hello y'all, > > Apologies if this is a well known, documented problem. You can just > send me the URL if that's the case. > > Let's say I create a large numpy array: > > def foo(): > import numpy as np > from numpy.random import random > a = random((100000,100)) > index = np.arange(0,100000,5) > b = a[index,:] # Use a complex index to force copy-on-slice > assert not np.may_share_memory(a,b) # b is a copy, not a view. > return b > > b = foo() > > After the call to foo(), only the memory associated with b remains. a > goes out of scope, its memory is garbage-collected, everything is > fine. > > Now suppose I do something similar with astropy.io.fits (assume that > large_fits_file is a ~GB FITS file containing a FITS binary table in > HDU 1): > > def bar(large_fits_file): > import numpy as np > import astropy.io.fits as pyfits > f = pyfits.open(large_fits_file) > index = np.arange(0,100000,5) > bb = f[1].data[index] > assert not np.may_share_memory(f[1].data,bb) # bb is a copy, not a view. > return bb > > bb = bar(large_fits_file) > > After the call to bar, all the memory associated with f[1].data > remains in memory, even though it has gone out of scope. Only when bb > goes out of scope (or del bb) does the memory get released, even > though we have shown that bb is a copy of the data not a view. > Somehow bb is retaining a reference to the original data. > > The attached script uses the memory_profiler package > (https://pypi.python.org/pypi/memory_profiler) to demonstrate this. > > So, what's going on here? > > Kia ora koutou, > Benjamin Alan Weaver > > -- > a.k.a. The Dream Weaver > > Outside of a dog, a book is man's best friend. Inside of a dog it's > too dark to read. > --Groucho Marx > > _______________________________________________ > 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 stuart at mumford.me.uk Fri Jun 13 15:17:59 2014 From: stuart at mumford.me.uk (Stuart Mumford) Date: Fri, 13 Jun 2014 20:17:59 +0100 Subject: [AstroPy] SunPy 0.5.0 Released! Message-ID: Hello, The SunPy project is happy to announce the release of the next major version of SunPy, version 0.5.0. This release consists of 772 commits from 21 people including 9 new contributors. This release includes the ability to co-align map cubes via template matching using scikit image; massive improvements to Map.rotate() which now utilises scikit image's transform submodule and includes an implementation of the aiaprep calibration routine for SDO/AIA data; as well as the ability to calculate GOES temperature and emission measure from GOES fluxes. Special mentions to Daniel Ryan and Andrew Leonard who have both contributed their first major features to SunPy for this release. They contributed the GOES temperature and rotation/aiaprep code respectively. This version of SunPy can be downloaded in the usual fashion from PyPI or http://sunpy.org. The full release announcement can be found here . Happy Pythoning! Stuart Mumford for the SunPy Project -------------- next part -------------- An HTML attachment was scrubbed... URL: From gr.maravelias at gmail.com Wed Jun 18 09:52:43 2014 From: gr.maravelias at gmail.com (Grigoris Maravelias) Date: Wed, 18 Jun 2014 16:52:43 +0300 Subject: [AstroPy] aplpy.FITSFigure combined with mpl subplots ? Message-ID: <53A199AB.50706@gmail.com> Hello all! How can we combine the aplpy.FITSFigure within the matplotlib subplots? I am using this: f, ax = plt.subplots(rows,columns) #, sharex='col', sharey='row') index_list = [ind for ind in np.ndindex(rows,columns)] ii = 0 for obj in list_of_images: plot_index = index_list[ii] ax[plot_index].plot(x,y) ii += 1 which works perfectly (iterating over all indeces, as we do not know their number beforehand and may change from one object to another). and we want now to add the the aplpy.FITSFigure of a fits file. What is the best way to pass this ? On the other hand I could take advantage of the subplot of aplpy.FITSFigure(obj,figure=fir,subplot=[...]) but I would like to automatically assign the positions of the subplots. Is there an easy way to use the indexing that I show previously (i.e. ax[plot_index])? Best Grigoris From joe at neoturbine.net Wed Jun 18 10:09:41 2014 From: joe at neoturbine.net (Joseph Booker) Date: Wed, 18 Jun 2014 10:09:41 -0400 Subject: [AstroPy] aplpy.FITSFigure combined with mpl subplots ? In-Reply-To: <53A199AB.50706@gmail.com> References: <53A199AB.50706@gmail.com> Message-ID: Grigoris, The problem with your code is that the plt.subplots() command creates normal Axes objects, while FITSFigure creates a new axes every time you create a FITSFigure(). If you did add a FITSFigure using subplot=[..], then you'd simply overlap the regular axes with a HostAxes from FITSFigure, instead of reusing the Axes. I think this can be solved elegantly using the tuple notation to iterate over the images: f = plt.figure() for i, obj in enumerate(list_of_images): aplpy.FITSFigure(obj, subplot=(rows,columns,i), figure=f) This has the advantage of not creating extra axes if you don't have enough images. Good luck, Joseph On Wed, Jun 18, 2014 at 9:52 AM, Grigoris Maravelias < gr.maravelias at gmail.com> wrote: > Hello all! > > How can we combine the aplpy.FITSFigure within the matplotlib subplots? > > I am using this: > f, ax = plt.subplots(rows,columns) #, sharex='col', sharey='row') > index_list = [ind for ind in np.ndindex(rows,columns)] > ii = 0 > > for obj in list_of_images: > plot_index = index_list[ii] > ax[plot_index].plot(x,y) > ii += 1 > > which works perfectly (iterating over all indeces, as we do not know > their number beforehand and may change from one object to another). > and we want now to add the the aplpy.FITSFigure of a fits file. > > What is the best way to pass this ? > > On the other hand I could take advantage of the subplot of > aplpy.FITSFigure(obj,figure=fir,subplot=[...]) but I would like to > automatically assign the positions of the subplots. > Is there an easy way to use the indexing that I show previously (i.e. > ax[plot_index])? > > Best > Grigoris > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From indiajoe at gmail.com Wed Jun 18 13:33:12 2014 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Wed, 18 Jun 2014 23:03:12 +0530 Subject: [AstroPy] Loading daophot .mag file with multiple aperture magnitudes Message-ID: Hi, Astropy.io.ascii loads daophot's .mag file into a table without any issue. But when daophot contains magnitudes for different photometric apertures, it seems to be loading only the first aperture value for each star. Is there any way to load the complete content of .mag file of daophot into an ascii table? I am attaching a sample daophot 's .mag file which fails to load completely into a table. I guess the issue is because of the lack of unique column header for different aperture data. -cheers joe -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- My GnuPG Public Key: https://sites.google.com/site/jpninan/index-html/aboutmehtml/JPN_public.key?attredirects=0&d=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SampleImageDaophot.fits.mag.1 Type: application/octet-stream Size: 7515 bytes Desc: not available URL: From aldcroft at head.cfa.harvard.edu Wed Jun 18 22:10:05 2014 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Wed, 18 Jun 2014 22:10:05 -0400 Subject: [AstroPy] JS9 - DS9 in the browser Message-ID: Hi all - People on this list might be interested in JS9, which is a javascript implementation of DS9 which runs in the browser. Currently this is in beta but it's worth checking out the demo at: http://js9.si.edu/ (In case your DS9 skills are rusty, in the default view you can change the color stretch by left-clicking and dragging). The lead developer is Eric Mandel at CfA and he is interested in getting a feel for the level of interest in making hooks for a Python connection. This seems like an obvious and exciting candidate for IPython integration, but feedback would be helpful. Cheers, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazmin.berlanga at gmail.com Tue Jun 24 17:48:55 2014 From: jazmin.berlanga at gmail.com (Jazmin Berlanga Medina) Date: Tue, 24 Jun 2014 16:48:55 -0500 Subject: [AstroPy] aplpy.FITSFigure only works from ipython --pylab Message-ID: Hi all, I've tried posting this topic to the APLpy users group on Google, but the posting has failed (and I see no threads at all on their page, so the group may be inactive or having issues with their page). Is there a reason why aplpy.FITSFigure's display would work only from ipython called with the --pylab option, but not from the python interpreter or from a script called at the command line (or ipython not called with --pylab)? I can get the commands in my script to show me a display when I invoke Python with ipython --pylab, but not in any other circumstance. I've tried combing through APLpy's documentation and googling for a connection between pylab/aplpy, but I can't find anything. I need to be able to call this function from a script or otherwise be able to script plots on top of FITS files, and a simple addition of import pylab does not work. Contents of program: #!/usr/bin/env python import aplpy fig = aplpy.FITSFigure('2.100Gyr_crop.fit') fig.show_grayscale() Thanks! Jazmin -- Jazmin Berlanga M. M.S. Student Department of Physics University of Arkansas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Conley at Colorado.EDU Tue Jun 24 18:09:29 2014 From: Alexander.Conley at Colorado.EDU (Alexander Joseph Conley) Date: Tue, 24 Jun 2014 16:09:29 -0600 Subject: [AstroPy] aplpy.FITSFigure only works from ipython --pylab In-Reply-To: References: Message-ID: <9A2E23F4-C85B-41FC-B1E8-4D7B5F6D93E9@colorado.edu> Try fig.show() On Jun 24, 2014, at 3:48 PM, Jazmin Berlanga Medina wrote: > Hi all, > > I've tried posting this topic to the APLpy users group on Google, but the posting has failed (and I see no threads at all on their page, so the group may be inactive or having issues with their page). > > Is there a reason why aplpy.FITSFigure's display would work only from ipython called with the --pylab option, but not from the python interpreter or from a script called at the command line (or ipython not called with --pylab)? > > I can get the commands in my script to show me a display when I invoke Python with ipython --pylab, but not in any other circumstance. I've tried combing through APLpy's documentation and googling for a connection between pylab/aplpy, but I can't find anything. I need to be able to call this function from a script or otherwise be able to script plots on top of FITS files, and a simple addition of import pylab does not work. > > Contents of program: > > #!/usr/bin/env python > > import aplpy > > fig = aplpy.FITSFigure('2.100Gyr_crop.fit') > > fig.show_grayscale() > > > Thanks! > Jazmin > > -- > > Jazmin Berlanga M. > M.S. Student > Department of Physics > University of Arkansas > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From stephenbailey at lbl.gov Tue Jun 24 20:11:15 2014 From: stephenbailey at lbl.gov (Stephen Bailey) Date: Tue, 24 Jun 2014 17:11:15 -0700 Subject: [AstroPy] installation problems on a mac Message-ID: Hello. I'm having difficulty installing astropy on a Mac (10.9.3, Xcode 5.1.1, EPD 7.3-1 python 2.7.3). The failure is rather basic: when installing via pip it can't find math.h; when installing from git source it can't find stdio.h (see details below). It suspiciously includes the gcc option: -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk which looks like it is trying to find a very old (and perhaps no-longer-existent?) XCode installation. That might be the original Xcode that was installed on this Mac 3 years ago, but has been upgraded multiple times since then. I'm not using macports. It should be looking in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/math.h A simple hello.c program is able to find without any special gcc options. Any ideas for why astropy is trying to use the wrong sysroot or whatever else might be wrong? Thanks for the help. Stephen Bailey FF:temp $ pip install --no-deps astropy ... Downloading/unpacking astropy Downloading astropy-0.3.2.tar.gz (6.4MB): 6.4MB downloaded Running setup.py egg_info for package astropy Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Installing collected packages: astropy Running setup.py install for astropy Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 building 'astropy.io.fits.compression' extension gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include -Icextern/cfitsio -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c astropy/io/fits/src/compressionmodule.c -o build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch -Wno-declaration-after-statement astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' file not found #include ^ 1 error generated. error: command 'gcc' failed with exit status 1 Complete output from command /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt --single-version-externally-managed: Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 running install ... creating build/temp.macosx-10.5-x86_64-2.7/cextern/cfitsio gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include -Icextern/cfitsio -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c astropy/io/fits/src/compressionmodule.c -o build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch -Wno-declaration-after-statement astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' file not found #include ^ 1 error generated. error: command 'gcc' failed with exit status 1 ---------------------------------------- Cleaning up... Command /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt --single-version-externally-managed failed with error code 1 in /private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy Storing complete log in /Users/sbailey/.pip/pip.log FF:astropy $ python setup.py build Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 running build running build_py running build_ext building 'astropy._compiler' extension gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c astropy/_compiler.c -o build/temp.macosx-10.5-x86_64-2.7/astropy/_compiler.o In file included from astropy/_compiler.c:1: /Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7/Python.h:33:10: fatal error: 'stdio.h' file not found #include ^ 1 error generated. error: command 'gcc' failed with exit status 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Wed Jun 25 10:35:59 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Wed, 25 Jun 2014 10:35:59 -0400 Subject: [AstroPy] installation problems on a mac In-Reply-To: References: Message-ID: <53AADE4F.3020701@stsci.edu> Many of the gcc compiler flags that astropy uses come directly from the Python being used. (This is how distutils, the standard Python tool that astropy uses to build itself, works). The idea is that the compiler flags for the extensions should match the compiler flags that were used to build the Python interpreter they will be used with. If you're using EPD python, that's probably the old SDK they used to build their Python (and it makes sense they would use an old one if they are trying to be as portable as possible). Never being an EPD user, I don't know what the usual solution to this is. You may try upgrading to Enthought Canopy or Anaconda, as I don't think EPD is being actively supported anymore. Mike On 06/24/2014 08:11 PM, Stephen Bailey wrote: > Hello. I'm having difficulty installing astropy on a Mac (10.9.3, > Xcode 5.1.1, EPD 7.3-1 python 2.7.3). > > The failure is rather basic: when installing via pip it can't find > math.h; when installing from git source it can't find stdio.h (see > details below). It suspiciously includes the gcc option: > > -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk > > which looks like it is trying to find a very old (and perhaps > no-longer-existent?) XCode installation. That might be the original > Xcode that was installed on this Mac 3 years ago, but has been > upgraded multiple times since then. I'm not using macports. > > It should be looking in > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/math.h > > A simple hello.c program is able to find without any special > gcc options. > > Any ideas for why astropy is trying to use the wrong sysroot or > whatever else might be wrong? > > Thanks for the help. > > Stephen Bailey > > > > > FF:temp $ pip install --no-deps astropy > ... > Downloading/unpacking astropy > Downloading astropy-0.3.2.tar.gz (6.4MB): 6.4MB downloaded > Running setup.py egg_info for package astropy > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Installing collected packages: astropy > Running setup.py install for astropy > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > building 'astropy.io.fits.compression' extension > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 > -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch > x86_64 -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include > -Icextern/cfitsio > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 > -c astropy/io/fits/src/compressionmodule.c -o > build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o > -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format > -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch > -Wno-declaration-after-statement > astropy/io/fits/src/compressionmodule.c:93:10: fatal error: > 'math.h' file not found > #include > ^ > 1 error generated. > error: command 'gcc' failed with exit status 1 > Complete output from command > /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import > setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', > '\n'), __file__, 'exec'))" install --record > /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt > --single-version-externally-managed: > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > running install > ... > creating build/temp.macosx-10.5-x86_64-2.7/cextern/cfitsio > > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 > -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include > -Icextern/cfitsio > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 > -c astropy/io/fits/src/compressionmodule.c -o > build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o > -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format > -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch > -Wno-declaration-after-statement > > astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' > file not found > > #include > > ^ > > 1 error generated. > > error: command 'gcc' failed with exit status 1 > > ---------------------------------------- > Cleaning up... > Command /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c > "import > setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', > '\n'), __file__, 'exec'))" install --record > /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt > --single-version-externally-managed failed with error code 1 in > /private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy > Storing complete log in /Users/sbailey/.pip/pip.log > > > > > > > FF:astropy $ python setup.py build > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > running build > running build_py > running build_ext > building 'astropy._compiler' extension > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 > -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 > -c astropy/_compiler.c -o > build/temp.macosx-10.5-x86_64-2.7/astropy/_compiler.o > In file included from astropy/_compiler.c:1: > /Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7/Python.h:33:10: > fatal error: > 'stdio.h' file not found > #include > ^ > 1 error generated. > error: command 'gcc' failed with exit status 1 > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejensen1 at swarthmore.edu Wed Jun 25 10:58:39 2014 From: ejensen1 at swarthmore.edu (Eric L. N. Jensen) Date: Wed, 25 Jun 2014 10:58:39 -0400 Subject: [AstroPy] installation problems on a mac In-Reply-To: <53AADE4F.3020701@stsci.edu> References: <53AADE4F.3020701@stsci.edu> Message-ID: <29F2032F-4D1A-4B30-B2A8-C1663C7954F0@swarthmore.edu> Hi Stephen, For what it?s worth, I?ve had good luck on the Mac (using OS X 10.7 up to 10.9) with both anaconda and Ureka. Both of them come with astropy already installed, but I?ve also had no problems updating astropy within those environments using the standard tools. I know this doesn?t answer your original question, and no one likes being told to ditch their installed distribution and get another, but I just thought I?d share this in case you?re considering a different distro. Eric On Jun 25, 2014, at 10:35 AM, Michael Droettboom wrote: > Many of the gcc compiler flags that astropy uses come directly from the Python being used. (This is how distutils, the standard Python tool that astropy uses to build itself, works). The idea is that the compiler flags for the extensions should match the compiler flags that were used to build the Python interpreter they will be used with. > > If you're using EPD python, that's probably the old SDK they used to build their Python (and it makes sense they would use an old one if they are trying to be as portable as possible). > > Never being an EPD user, I don't know what the usual solution to this is. You may try upgrading to Enthought Canopy or Anaconda, as I don't think EPD is being actively supported anymore. > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlj.ovelar at gmail.com Wed Jun 25 12:10:56 2014 From: mlj.ovelar at gmail.com (Maria de Juan Ovelar) Date: Wed, 25 Jun 2014 17:10:56 +0100 Subject: [AstroPy] Transforming an image into polar coordinates and back to cartesian Message-ID: <17423714-A683-41BD-B4F9-90C1D14BF07F@gmail.com> Dear all, I want to transform an image (array) into polar coordinates, operate on it and transform it back to cartesian. I found an entry on the stackoverflow forum with some ideas but I can't manage to recover the image in cartesian properly using those recipes...Is there any scipy or astropy function that can help? Thanks! Maria From embray at stsci.edu Wed Jun 25 12:15:18 2014 From: embray at stsci.edu (Erik Bray) Date: Wed, 25 Jun 2014 12:15:18 -0400 Subject: [AstroPy] installation problems on a mac In-Reply-To: <53AADE4F.3020701@stsci.edu> References: <53AADE4F.3020701@stsci.edu> Message-ID: <53AAF596.2060103@stsci.edu> On 06/25/2014 10:35 AM, Michael Droettboom wrote: > Never being an EPD user, I don't know what the usual solution to this is. You > may try upgrading to Enthought Canopy or Anaconda, as I don't think EPD is being > actively supported anymore. I do sometimes use Canopy and I second this. If you're still using EPD you should look into trying to upgrade. Canopy *is* EPD they just gave it a new name (though it does represent a significant evolution over the last release that was named "EPD"). Erik > On 06/24/2014 08:11 PM, Stephen Bailey wrote: >> Hello. I'm having difficulty installing astropy on a Mac (10.9.3, Xcode >> 5.1.1, EPD 7.3-1 python 2.7.3). >> >> The failure is rather basic: when installing via pip it can't find math.h; >> when installing from git source it can't find stdio.h (see details below). It >> suspiciously includes the gcc option: >> >> -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk >> >> which looks like it is trying to find a very old (and perhaps >> no-longer-existent?) XCode installation. That might be the original Xcode >> that was installed on this Mac 3 years ago, but has been upgraded multiple >> times since then. I'm not using macports. >> >> It should be looking in >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/math.h >> >> A simple hello.c program is able to find without any special gcc >> options. >> >> Any ideas for why astropy is trying to use the wrong sysroot or whatever else >> might be wrong? >> >> Thanks for the help. >> >> Stephen Bailey >> >> >> >> >> FF:temp $ pip install --no-deps astropy >> ... >> Downloading/unpacking astropy >> Downloading astropy-0.3.2.tar.gz (6.4MB): 6.4MB downloaded >> Running setup.py egg_info for package astropy >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Installing collected packages: astropy >> Running setup.py install for astropy >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> building 'astropy.io.fits.compression' extension >> gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk >> -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include >> -Icextern/cfitsio >> -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c >> astropy/io/fits/src/compressionmodule.c -o >> build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o >> -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format >> -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch >> -Wno-declaration-after-statement >> astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' file >> not found >> #include >> ^ >> 1 error generated. >> error: command 'gcc' failed with exit status 1 >> Complete output from command >> /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import >> setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', >> '\n'), __file__, 'exec'))" install --record >> /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt >> --single-version-externally-managed: >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> >> running install >> ... >> creating build/temp.macosx-10.5-x86_64-2.7/cextern/cfitsio >> >> gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk >> -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include >> -Icextern/cfitsio >> -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c >> astropy/io/fits/src/compressionmodule.c -o >> build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o >> -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format >> -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch >> -Wno-declaration-after-statement >> >> astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' file not >> found >> >> #include >> >> ^ >> >> 1 error generated. >> >> error: command 'gcc' failed with exit status 1 >> >> ---------------------------------------- >> Cleaning up... >> Command /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import >> setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', >> '\n'), __file__, 'exec'))" install --record >> /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt >> --single-version-externally-managed failed with error code 1 in >> /private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy >> Storing complete log in /Users/sbailey/.pip/pip.log >> >> >> >> >> >> >> FF:astropy $ python setup.py build >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> running build >> running build_py >> running build_ext >> building 'astropy._compiler' extension >> gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot >> /Developer-3.2.6/SDKs/MacOSX10.6.sdk >> -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c >> astropy/_compiler.c -o build/temp.macosx-10.5-x86_64-2.7/astropy/_compiler.o >> In file included from astropy/_compiler.c:1: >> /Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7/Python.h:33:10: >> fatal error: >> 'stdio.h' file not found >> #include >> ^ >> 1 error generated. >> error: command 'gcc' failed with exit status 1 >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > > http://www.droettboom.com > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From jazmin.berlanga at gmail.com Wed Jun 25 12:57:00 2014 From: jazmin.berlanga at gmail.com (Jazmin Berlanga Medina) Date: Wed, 25 Jun 2014 11:57:00 -0500 Subject: [AstroPy] aplpy.FITSFigure only works from ipython --pylab Message-ID: Unfortunately, show() is not a function defined within FITSFigure. I took a look at the source code, dug around for what makes graph displays work in ipython with --pylab enabled, and I found the following pages. The information I read about matplotlib there implies that you can't use both the MATLAB-esque syntax of pylab outside of ipython --pylab and still have ipython's gui front-end behavior--you would have to use the matplotlib syntax along with some interactive on & off switches. I still could not find information specific to APLpy, and what you need to do to get it to work outside of ipython --pylab--surely not everyone with scripts that call this function is running them by copying/pasting into ipython or runs all their codes as ipython notebooks. http://python4astronomers.github.io/plotting/matplotlib.html#appendix-pylab-and-pyplot-and-numpy http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related http://aplpy.readthedocs.org/en/v0.9.11/_modules/aplpy/aplpy.html#FITSFigure Since, at the moment, I'm not worried about finely-tuned graphs drawing from the FITS file's data (the same file I want to overlay plots on), I decided to look for an alternate to APLpy. You can get a simple plot on top of a FITS image using astropy.io.fits and matplotlib or pylab. For instance, the following code will plot a FITS image, then some x,y values, then finally display that image. ------------------ from pylab import * from astropy.io import fits galaxy_image = fits.getdata('my_image.fits') imshow(galaxy_image,cmap='gray',origin='lower') # My image was originally flipped upside down, thus the origin argument. plot(x_values_list,y_values_list) show() ------------------ If anyone has some info on running APLpy functions outside of ipython --pylab, I'd still like to know for future use--I hate to reinvent the wheel when this module already has so many great tools. Thanks, Jazmin ------------------------------ > > Message: 2 > Date: Tue, 24 Jun 2014 16:09:29 -0600 > From: Alexander Joseph Conley > Subject: Re: [AstroPy] aplpy.FITSFigure only works from ipython > --pylab > To: Astronomical Python mailing list > Message-ID: <9A2E23F4-C85B-41FC-B1E8-4D7B5F6D93E9 at colorado.edu> > Content-Type: text/plain; charset="us-ascii" > > Try fig.show() > On Jun 24, 2014, at 3:48 PM, Jazmin Berlanga Medina < > jazmin.berlanga at gmail.com> wrote: > > > Hi all, > > > > I've tried posting this topic to the APLpy users group on Google, but > the posting has failed (and I see no threads at all on their page, so the > group may be inactive or having issues with their page). > > > > Is there a reason why aplpy.FITSFigure's display would work only from > ipython called with the --pylab option, but not from the python interpreter > or from a script called at the command line (or ipython not called with > --pylab)? > > > > I can get the commands in my script to show me a display when I invoke > Python with ipython --pylab, but not in any other circumstance. I've tried > combing through APLpy's documentation and googling for a connection between > pylab/aplpy, but I can't find anything. I need to be able to call this > function from a script or otherwise be able to script plots on top of FITS > files, and a simple addition of import pylab does not work. > > > > Contents of program: > > > > #!/usr/bin/env python > > > > import aplpy > > > > fig = aplpy.FITSFigure('2.100Gyr_crop.fit') > > > > fig.show_grayscale() > > > > > > Thanks! > > Jazmin > > > > -- > > > > Jazmin Berlanga M. > > M.S. Student > > Department of Physics > > University of Arkansas > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > -- Jazmin Berlanga M. M.S. Student Department of Physics University of Arkansas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazmin.berlanga at gmail.com Wed Jun 25 13:08:56 2014 From: jazmin.berlanga at gmail.com (Jazmin Berlanga Medina) Date: Wed, 25 Jun 2014 12:08:56 -0500 Subject: [AstroPy] aplpy.FITSFigure only works from ipython Message-ID: I realize that the code snippet (which uses pylab outside of ipython --pylab just fine) I just sent out seems to contradict what I said about pylab not having the same functionality outside of ipython. I'd like to clarify that for non-FITSFigure plot commands, the display seems to work, but if I make the same import statements and then try to use aplpy.FITSFigure, the display does not show. I don't understand what's going on, I can only speculate that aplpy may be configured to use some settings that are easily accessible from ipython --pylab but not from the python interpreter or programs run from the command line, even after importing all the pylab functions. ------------------------------ Message: 4 Date: Wed, 25 Jun 2014 11:57:00 -0500 From: Jazmin Berlanga Medina Subject: Re: [AstroPy] aplpy.FITSFigure only works from ipython --pylab To: astropy at scipy.org Message-ID: Content-Type: text/plain; charset="utf-8" Unfortunately, show() is not a function defined within FITSFigure. I took a look at the source code, dug around for what makes graph displays work in ipython with --pylab enabled, and I found the following pages. The information I read about matplotlib there implies that you can't use both the MATLAB-esque syntax of pylab outside of ipython --pylab and still have ipython's gui front-end behavior--you would have to use the matplotlib syntax along with some interactive on & off switches. I still could not find information specific to APLpy, and what you need to do to get it to work outside of ipython --pylab--surely not everyone with scripts that call this function is running them by copying/pasting into ipython or runs all their codes as ipython notebooks. http://python4astronomers.github.io/plotting/matplotlib.html#appendix-pylab-and-pyplot-and-numpy http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related http://aplpy.readthedocs.org/en/v0.9.11/_modules/aplpy/aplpy.html#FITSFigure Since, at the moment, I'm not worried about finely-tuned graphs drawing from the FITS file's data (the same file I want to overlay plots on), I decided to look for an alternate to APLpy. You can get a simple plot on top of a FITS image using astropy.io.fits and matplotlib or pylab. For instance, the following code will plot a FITS image, then some x,y values, then finally display that image. ------------------ from pylab import * from astropy.io import fits galaxy_image = fits.getdata('my_image.fits') imshow(galaxy_image,cmap=' gray',origin='lower') # My image was originally flipped upside down, thus the origin argument. plot(x_values_list,y_values_list) show() ------------------ If anyone has some info on running APLpy functions outside of ipython --pylab, I'd still like to know for future use--I hate to reinvent the wheel when this module already has so many great tools. Thanks, Jazmin -- Jazmin Berlanga M. M.S. Student Department of Physics University of Arkansas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Conley at Colorado.EDU Wed Jun 25 13:10:01 2014 From: Alexander.Conley at Colorado.EDU (Alexander Joseph Conley) Date: Wed, 25 Jun 2014 11:10:01 -0600 Subject: [AstroPy] aplpy.FITSFigure only works from ipython --pylab In-Reply-To: References: Message-ID: <4A24ADD0-4C32-4E89-9B38-094D9B69D9E8@colorado.edu> Sorry, that should have been matplotlib.pyplot.show(), not fig.show(). I was grabbing too quickly from something where I made FITSFigure plot in an already defined window. I never use pylab, and this works for me: import aplpy import matplotlib.pyplot as plt f = aplpy.FITSFigure(image_name) f.show_grayscale() plt.show() What I really usually do is something more like: f, ax = plt.subplots(1) fig = aplpy.FITSFigure(name_of_image, figure=f) fig.show_grayscale() f.show() You can see where my previous message went wrong? sorry about that. Alex On 25-Jun-2014, at 10:57 AM, Jazmin Berlanga Medina wrote: > > Unfortunately, show() is not a function defined within FITSFigure. From benjamin.weaver at nyu.edu Wed Jun 25 13:47:17 2014 From: benjamin.weaver at nyu.edu (Benjamin Alan Weaver) Date: Wed, 25 Jun 2014 13:47:17 -0400 Subject: [AstroPy] installation problems on a mac In-Reply-To: References: Message-ID: Hello Stephen, I use the version of astropy in Macports, & it just works. Kia ora koe, Benjamin Alan Weaver On Tue, Jun 24, 2014 at 8:11 PM, Stephen Bailey wrote: > Hello. I'm having difficulty installing astropy on a Mac (10.9.3, Xcode > 5.1.1, EPD 7.3-1 python 2.7.3). > > The failure is rather basic: when installing via pip it can't find math.h; > when installing from git source it can't find stdio.h (see details below). > It suspiciously includes the gcc option: > > -isysroot /Developer-3.2.6/SDKs/MacOSX10.6.sdk > > which looks like it is trying to find a very old (and perhaps > no-longer-existent?) XCode installation. That might be the original Xcode > that was installed on this Mac 3 years ago, but has been upgraded multiple > times since then. I'm not using macports. > > It should be looking in > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/math.h > > A simple hello.c program is able to find without any special gcc > options. > > Any ideas for why astropy is trying to use the wrong sysroot or whatever > else might be wrong? > > Thanks for the help. > > Stephen Bailey > > > > > FF:temp $ pip install --no-deps astropy > ... > Downloading/unpacking astropy > Downloading astropy-0.3.2.tar.gz (6.4MB): 6.4MB downloaded > Running setup.py egg_info for package astropy > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Installing collected packages: astropy > Running setup.py install for astropy > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > building 'astropy.io.fits.compression' extension > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include > -Icextern/cfitsio > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c > astropy/io/fits/src/compressionmodule.c -o > build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o > -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format > -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch > -Wno-declaration-after-statement > astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' > file not found > #include > ^ > 1 error generated. > error: command 'gcc' failed with exit status 1 > Complete output from command > /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c "import > setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', > '\n'), __file__, 'exec'))" install --record > /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt > --single-version-externally-managed: > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > running install > ... > creating build/temp.macosx-10.5-x86_64-2.7/cextern/cfitsio > > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include > -Icextern/cfitsio > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c > astropy/io/fits/src/compressionmodule.c -o > build/temp.macosx-10.5-x86_64-2.7/astropy/io/fits/src/compressionmodule.o > -Wno-unused-variable -Wno-parentheses -Wno-uninitialized -Wno-format > -Wno-strict-prototypes -Wno-unused -Wno-comments -Wno-switch > -Wno-declaration-after-statement > > astropy/io/fits/src/compressionmodule.c:93:10: fatal error: 'math.h' file > not found > > #include > > ^ > > 1 error generated. > > error: command 'gcc' failed with exit status 1 > > ---------------------------------------- > Cleaning up... > Command /Library/Frameworks/EPD64.framework/Versions/7.3/bin/python -c > "import > setuptools;__file__='/private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy/setup.py';exec(compile(open(__file__).read().replace('\r\n', > '\n'), __file__, 'exec'))" install --record > /var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip-Sv1zUF-record/install-record.txt > --single-version-externally-managed failed with error code 1 in > /private/var/folders/lt/w2k_kx011kd7s2g9rk27xgzc0000gn/T/pip_build_sbailey/astropy > Storing complete log in /Users/sbailey/.pip/pip.log > > > > > > > FF:astropy $ python setup.py build > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > running build > running build_py > running build_ext > building 'astropy._compiler' extension > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot > /Developer-3.2.6/SDKs/MacOSX10.6.sdk > -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c > astropy/_compiler.c -o build/temp.macosx-10.5-x86_64-2.7/astropy/_compiler.o > In file included from astropy/_compiler.c:1: > /Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7/Python.h:33:10: > fatal error: > 'stdio.h' file not found > #include > ^ > 1 error generated. > error: command 'gcc' failed with exit status 1 > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- a.k.a. The Dream Weaver Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read. --Groucho Marx