From brad.p.holden at gmail.com Sat Dec 3 12:31:14 2016 From: brad.p.holden at gmail.com (Brad Holden) Date: Sat, 03 Dec 2016 17:31:14 +0000 Subject: [AstroPy] Astronomer / Data Pipeline Developer Position Message-ID: Hi Everyone, We would like to let you know about a new position opening at the University of California Observatories (UCO). We would appreciate if you could forward this to potentially interested candidates. Please don?t hesitate to contact me with questions about the position. Thank you, Brad Holden (on behalf of the committee) ---- The University of California Observatories (UCO) invites applications for a Project Scientist position for data pipeline development and data analysis support for UCO under the supervision of the UCO Director. The selected candidate will participate in research or creative programs and the development of modern data reduction pipelines and analysis for UCO in close collaboration with faculty, staff, and students at University of California astronomy campuses. Responsibilities include: identifying shortcomings with existing data reduction pipelines; suggest new projects at the interface of research, software development and data analysis; assist in project management; and contribute to publications. The selected candidate will be able to apply for observing time on the W. M. Keck Observatory's telescopes, and on those at Lick Observatory where the Shane 3-meter telescope is outfitted with the new "ShaneAO" laser guide star adaptive optics system. Review of applications will begin on January 3, 2017. Applications are accepted via the UCSC Academic Recruit online system, and must include: 1) An application letter containing a statement of interest and qualifications, including discussion of how the candidate fits the above-described requirements for this position; 2) A current CV and publication list; and 3) three letters of reference. Documents must be submitted as PDF files. Apply at https://recruit.ucsc.edu/apply/JPF00405 Refer to Position #JPF00405-17T in all correspondence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From knoxlong at gmail.com Sat Dec 3 16:37:45 2016 From: knoxlong at gmail.com (Knox Long) Date: Sat, 3 Dec 2016 15:37:45 -0600 Subject: [AstroPy] Table Join Behavior Message-ID: Can someone tell me why the join carried in the little .py script with the data indicated, is returning this number of rows. I would have though that joining a table on itself would always return the same number of rows (but this is not happening for me in the astroconda environment) I start out with 49 rows, but end up with 97, even though I have joined the table on itself. Thanks Knox P. S. It makes no difference whether I used the Python2.7 version or the Python3.4 version of astroconda -- Knox S. Long 410-338-4862 (office) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Dataset ProgID ExpStart Proc-Date Proc-Time Proc-Stat --------- ------ ------------- ---------- --------- ----------- ib6v19csq 11677 55221.3353991 2016-12-03 20:39:07 Unprocessed ib6v19csq 11677 55221.3353991 2016-12-03 20:39:07 Unprocessed ib6v19czq 11677 55221.3383735 2016-12-03 20:39:07 Unprocessed ib6v19czq 11677 55221.3383735 2016-12-03 20:39:07 Unprocessed ib6v19d2q 11677 55221.3548087 2016-12-03 20:39:07 Unprocessed ib6v19d2q 11677 55221.3548087 2016-12-03 20:39:07 Unprocessed ib6v19d4q 11677 55221.3854916 2016-12-03 20:39:07 Unprocessed ib6v19d4q 11677 55221.3854916 2016-12-03 20:39:07 Unprocessed ib6v19d7q 11677 55221.399612 2016-12-03 20:39:07 Unprocessed ib6v19d7q 11677 55221.399612 2016-12-03 20:39:07 Unprocessed ib6v19d9q 11677 55221.4049013 2016-12-03 20:39:07 Unprocessed ib6v19d9q 11677 55221.4049013 2016-12-03 20:39:07 Unprocessed ib6v19dcq 11677 55221.4190216 2016-12-03 20:39:07 Unprocessed ib6v19dcq 11677 55221.4190216 2016-12-03 20:39:07 Unprocessed ib6v19deq 11677 55221.4520194 2016-12-03 20:39:07 Unprocessed ib6v19deq 11677 55221.4520194 2016-12-03 20:39:07 Unprocessed ib6v19dhq 11677 55221.4661398 2016-12-03 20:39:07 Unprocessed ib6v19dhq 11677 55221.4661398 2016-12-03 20:39:07 Unprocessed ib6v19djq 11677 55221.4709431 2016-12-03 20:39:07 Unprocessed ib6v19djq 11677 55221.4709431 2016-12-03 20:39:07 Unprocessed ib6v19dmq 11677 55221.4850635 2016-12-03 20:39:07 Unprocessed ib6v19dmq 11677 55221.4850635 2016-12-03 20:39:07 Unprocessed ib0lajdyq 11548 55221.5348087 2016-12-03 20:39:07 Unprocessed ib0lajdyq 11548 55221.5348087 2016-12-03 20:39:07 Unprocessed ib0lajdzq 11548 55221.541325 2016-12-03 20:39:07 Unprocessed ib0lajdzq 11548 55221.541325 2016-12-03 20:39:07 Unprocessed ib0laje1q 11548 55221.5478413 2016-12-03 20:39:07 Unprocessed ib0laje1q 11548 55221.5478413 2016-12-03 20:39:07 Unprocessed ib0laje4q 11548 55221.5543572 2016-12-03 20:39:07 Unprocessed ib0laje4q 11548 55221.5543572 2016-12-03 20:39:07 Unprocessed ib0laje6q 11548 55221.5608735 2016-12-03 20:39:07 Unprocessed ib0laje6q 11548 55221.5608735 2016-12-03 20:39:07 Unprocessed ia21h2e9q 11189 55221.6139061 2016-12-03 20:39:07 Unprocessed ia21h2e9q 11189 55221.6139061 2016-12-03 20:39:07 Unprocessed ia21h2eaq 11189 55221.6297046 2016-12-03 20:39:07 Unprocessed ia21h2eaq 11189 55221.6297046 2016-12-03 20:39:07 Unprocessed ia21h2ecq 11189 55221.6782231 2016-12-03 20:39:07 Unprocessed ia21h2ecq 11189 55221.6782231 2016-12-03 20:39:07 Unprocessed ia21h2edq 11189 55221.6940216 2016-12-03 20:39:07 Unprocessed ia21h2edq 11189 55221.6940216 2016-12-03 20:39:07 Unprocessed ia21h2efq 11189 55221.7447972 2016-12-03 20:39:07 Unprocessed ia21h2efq 11189 55221.7447972 2016-12-03 20:39:07 Unprocessed ia21h2egq 11189 55221.7605957 2016-12-03 20:39:07 Unprocessed ia21h2egq 11189 55221.7605957 2016-12-03 20:39:07 Unprocessed ia21h2eiq 11189 55221.8115331 2016-12-03 20:39:07 Unprocessed ia21h2eiq 11189 55221.8115331 2016-12-03 20:39:07 Unprocessed ia21h2ejq 11189 55221.827332 2016-12-03 20:39:07 Unprocessed ia21h2ejq 11189 55221.827332 2016-12-03 20:39:07 Unprocessed ia21h2elq 11189 55221.8809894 2016-12-03 20:39:07 Unprocessed -------------- next part -------------- A non-text attachment was scrubbed... Name: Join_Behavior.py Type: text/x-python Size: 276 bytes Desc: not available URL: From knoxlong at gmail.com Sat Dec 3 17:18:38 2016 From: knoxlong at gmail.com (Knox Long) Date: Sat, 3 Dec 2016 16:18:38 -0600 Subject: [AstroPy] Table Join Behavior In-Reply-To: References: Message-ID: Sigh. Never mind. I understand now On Sat, Dec 3, 2016 at 3:37 PM, Knox Long wrote: > Can someone tell me why the join carried in the little .py script with the > data indicated, is returning this number of rows. I would have though that > joining a table on itself would always return the same number of rows (but > this is not happening for me in the astroconda environment) > > I start out with 49 rows, but end up with 97, even though I have joined > the table on itself. > > > Thanks > Knox > > P. S. It makes no difference whether I used the Python2.7 version or the > Python3.4 version of astroconda > -- > Knox S. Long > 410-338-4862 <(410)%20338-4862> (office) > > -- Knox S. Long 410-338-4862 (office) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cadair.com Mon Dec 5 05:49:42 2016 From: stuart at cadair.com (Stuart Mumford) Date: Mon, 5 Dec 2016 10:49:42 +0000 Subject: [AstroPy] Last Week to Apply for Python in Astronomy 2017 Message-ID: <8df52895-5be6-5a75-b77c-8c7ade380471@cadair.com> Hello all, This a quick (and final) reminder that the deadline for applications to Python in Astronomy 2017 is this *Friday 9th December*. The conference will be held on 8th - 12th May 2017 at the Lorentz Center in Leiden, the Netherlands. Please fill out this form to apply. The Python in Astronomy conferences aim to bring together a wide variety of people who currently use, develop or teach people about Python packages in the context of all forms of Astronomy. Participant selection will be made with the goal of growing the Python in Astronomy community and we particularly encourage requests to attend from junior astronomers and people who are new to contributing to open source software. This conference is neither intended to be an introduction to Python bootcamp nor only for expert-level Python developers, but we do expect all participants to have at least a basic familiarity with Python. Please fill out the application and indicate the level of financial support you will likely require in order to attend. Once the participants have been selected, we?ll get back in touch with everyone about their specific financial support requirements. See http://openastronomy.org/pyastro/2017/ for more information. Stuart Mumford, SOC Chair Matt Craig Kelle Cruz Daniela Huppenkothen Abigail Stevens Erik Tollerud -------------- next part -------------- An HTML attachment was scrubbed... URL: From baweaver at lbl.gov Mon Dec 5 12:20:46 2016 From: baweaver at lbl.gov (Benjamin Alan Weaver) Date: Mon, 5 Dec 2016 10:20:46 -0700 Subject: [AstroPy] PyDL v0.5.3 released Message-ID: Hello y'all, PyDL v0.5.3 has been released. This is primarily a bug fix release. See http://pydl.readthedocs.io/en/stable/pydl/changes.html for details. PyDL is available at https://pypi.python.org/pypi/pydl Kia ora koutou, Benjamin Alan 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 -------------- An HTML attachment was scrubbed... URL: From erwin at mpe.mpg.de Tue Dec 6 05:46:56 2016 From: erwin at mpe.mpg.de (Peter Erwin) Date: Tue, 6 Dec 2016 11:46:56 +0100 Subject: [AstroPy] Updated version of telarchive (1.8.3) Message-ID: Hi, This is just a brief announcement about a bug-fix release of telarchive, my quick-and-dirty Python-based command-line tool for searching telescope archives: http://www.mpe.mpg.de/~erwin/code/ The new version (1.8.3) includes fixes to restore access to the Gemini Observatory Archive [*] and SMOKA (Subaru, etc.), and also to restore proper reporting of results from the ESO archive. The new version can be downloaded from the URL above, and is also available from PyPi ? e.g., ?pip install telarchive? (or ?pip install --upgrade telarchive? if you?ve already installed it that way). [*] kudos to said archive for making an API available! (Hopefully much nicer than having to keep track of minor changes in HTML output?) cheers, Peter ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)176 2481 7713 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From mcraig at mnstate.edu Thu Dec 15 02:29:47 2016 From: mcraig at mnstate.edu (Matthew Craig) Date: Thu, 15 Dec 2016 07:29:47 +0000 Subject: [AstroPy] ANN: Release of ccdproc 1.2.0 Message-ID: <0379958D-C907-4C79-A3CF-E8B62EBB492E@mnstate.edu> Dear colleagues, We are pleased to announce the release of ccdproc v1.2. Ccdproc is is an Astropy affiliated package for basic data reduction of CCD images. Besides basic data reduction, useful features in ccdproc include propagation of uncertainties, tools for working easily with folders of images, image combination and support for building pipelines. New features in this release include: - A function called ccdmask that provides functionality similar to that in IRAF?s ccdmask. - More flexibility in setting up an ImageFileCollection to work with a collection of FITS files. - Added a median_filter, no block_replicate, block_reduce and block_average functions The new release also includes many bug fixes. Special thanks to all the contributors since the last major release, especially first-time contributor Z? Vinicius. We are also pleased to announce that Michael Seifert has been added to the core ccdproc development team. We would also like to thank the contributors to astropy, especially the NDData package, astroscrappy, reproject, numpy, scipy, and the astropy-helpers package. Feedback, contributions, and comments are welcome. We would especially be interested in contributions of examples of using ccdproc and comparisons to other reduction methods. Installation http://ccdproc.readthedocs.org/en/latest/ccdproc/install.html Documentation http://ccdproc.readthedocs.org/en/latest/ More Information, repository, and issue tracker https://github.com/astropy/ccdproc Cheers, Steve Crawford, Matt Craig and Michael Seifert -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Thu Dec 15 06:34:14 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Thu, 15 Dec 2016 11:34:14 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy Message-ID: Hi, I?m trying to use oblique projections in astropy for the SIN (Slant Orthographic) projection. This is well-defined in the Greisen/Calabretta papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer not to have to build CASA for this purpose (a reference library of calibration and imaging algorithms). In astropy, I can see two different approaches: - Use the reproject package - Use astropy.modelling.projections package I?m struggling with the former. The results do not seem correct. Before diving deeper (which would require building casacore for some comparisons), I?d like to know if trying the second approach is likely to work. What is the relationship between the two packages?? Thanks, Tim Cornwell --? Tim Cornwell Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Thu Dec 15 11:54:21 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Thu, 15 Dec 2016 16:54:21 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi, A more specific question about the reproject package. I?m assuming that the WCSLIB projection parameters should be inserted into the was via the set_pv function. i.e. if the obliqueness parameters are p, q then something like: p, q = fit_uvwplane(visslice) pv = [(1, 0, -p), (1, 1, -q)] w.wcs.set_pv(pv) Is this correct? Thanks, Tim --? Tim Cornwell Sent with Airmail On 15 December 2016 at 11:34:15 am, Tim Cornwell (realtimcornwell at gmail.com) wrote: Hi, I?m trying to use oblique projections in astropy for the SIN (Slant Orthographic) projection. This is well-defined in the Greisen/Calabretta papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer not to have to build CASA for this purpose (a reference library of calibration and imaging algorithms). In astropy, I can see two different approaches: - Use the reproject package - Use astropy.modelling.projections package I?m struggling with the former. The results do not seem correct. Before diving deeper (which would require building casacore for some comparisons), I?d like to know if trying the second approach is likely to work. What is the relationship between the two packages?? Thanks, Tim Cornwell --? Tim Cornwell Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Thu Dec 15 12:00:36 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 15 Dec 2016 17:00:36 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tim, Just to make sure I understand, you are trying to reproject an image to the -SIN projection? What projection is the image originally in? Cheers, Tom On 15 December 2016 at 11:34, Tim Cornwell wrote: > Hi, > > I?m trying to use oblique projections in astropy for the SIN (Slant > Orthographic) projection. This is well-defined in the Greisen/Calabretta > papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer > not to have to build CASA for this purpose (a reference library of > calibration and imaging algorithms). > > In astropy, I can see two different approaches: > > - Use the reproject package > - Use astropy.modelling.projections package > > I?m struggling with the former. The results do not seem correct. Before > diving deeper (which would require building casacore for some comparisons), > I?d like to know if trying the second approach is likely to work. What is > the relationship between the two packages? > > Thanks, > Tim Cornwell > > -- > Tim Cornwell > Sent with Airmail > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Thu Dec 15 12:48:05 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Thu, 15 Dec 2016 09:48:05 -0800 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tom, It?s from an oblique SIN projection to a non-oblique SIN projection. It?s a standard use case for dealing with large fields in radio interferometry. The obliquity varies with time so we reproject a series of snapshot images and add them in non-oblique coordinates. -- Tim Cornwell Sent with Airmail On 15 December 2016 at 5:01:01 pm, Thomas Robitaille ( thomas.robitaille at gmail.com) wrote: Hi Tim, Just to make sure I understand, you are trying to reproject an image to the -SIN projection? What projection is the image originally in? Cheers, Tom On 15 December 2016 at 11:34, Tim Cornwell wrote: > Hi, > > I?m trying to use oblique projections in astropy for the SIN (Slant > Orthographic) projection. This is well-defined in the Greisen/Calabretta > papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer > not to have to build CASA for this purpose (a reference library of > calibration and imaging algorithms). > > In astropy, I can see two different approaches: > > - Use the reproject package > - Use astropy.modelling.projections package > > I?m struggling with the former. The results do not seem correct. Before > diving deeper (which would require building casacore for some comparisons), > I?d like to know if trying the second approach is likely to work. What is > the relationship between the two packages? > > Thanks, > Tim Cornwell > > -- > Tim Cornwell > Sent with Airmail > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Thu Dec 15 14:57:15 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 15 Dec 2016 19:57:15 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tim, Could you share a minimal example script showing what you have tried, just so that we can reproduce the issue? The correct package to use here is reproject, so it should just be a matter of setting the output WCS correctly. If you can provide an example, I can investigate why it may not be working. Thanks, Tom On 15 December 2016 at 17:48, Tim Cornwell wrote: > Hi Tom, > > It?s from an oblique SIN projection to a non-oblique SIN projection. It?s > a standard use case for dealing with large fields in radio interferometry. > The obliquity varies with time so we reproject a series of snapshot images > and add them in non-oblique coordinates. > > -- > Tim Cornwell > Sent with Airmail > > On 15 December 2016 at 5:01:01 pm, Thomas Robitaille ( > thomas.robitaille at gmail.com) wrote: > > Hi Tim, > > Just to make sure I understand, you are trying to reproject an image to > the -SIN projection? What projection is the image originally in? > > Cheers, > Tom > > > On 15 December 2016 at 11:34, Tim Cornwell > wrote: > >> Hi, >> >> I?m trying to use oblique projections in astropy for the SIN (Slant >> Orthographic) projection. This is well-defined in the Greisen/Calabretta >> papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer >> not to have to build CASA for this purpose (a reference library of >> calibration and imaging algorithms). >> >> In astropy, I can see two different approaches: >> >> - Use the reproject package >> - Use astropy.modelling.projections package >> >> I?m struggling with the former. The results do not seem correct. Before >> diving deeper (which would require building casacore for some comparisons), >> I?d like to know if trying the second approach is likely to work. What is >> the relationship between the two packages? >> >> Thanks, >> Tim Cornwell >> >> -- >> Tim Cornwell >> Sent with Airmail >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Thu Dec 15 15:00:52 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Thu, 15 Dec 2016 20:00:52 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tom, Yes, I will do. It?ll take a little time. Thanks for the help, Tim --? Tim Cornwell Sent with Airmail On 15 December 2016 at 7:57:36 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Could you share a minimal example script showing what you have tried, just so that we can reproduce the issue? The correct package to use here is reproject, so it should just be a matter of setting the output WCS correctly. If you can provide an example, I can investigate why it may not be working. Thanks, Tom On 15 December 2016 at 17:48, Tim Cornwell wrote: Hi Tom, It?s from an oblique SIN projection to a non-oblique SIN projection. It?s a standard use case for dealing with large fields in radio interferometry. The obliquity varies with time so we reproject a series of snapshot images and add them in non-oblique coordinates. --? Tim Cornwell Sent with Airmail On 15 December 2016 at 5:01:01 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Just to make sure I understand, you are trying to reproject an image to the -SIN projection? What projection is the image originally in? Cheers, Tom On 15 December 2016 at 11:34, Tim Cornwell wrote: Hi, I?m trying to use oblique projections in astropy for the SIN (Slant Orthographic) projection. This is well-defined in the Greisen/Calabretta papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer not to have to build CASA for this purpose (a reference library of calibration and imaging algorithms). In astropy, I can see two different approaches: - Use the reproject package - Use astropy.modelling.projections package I?m struggling with the former. The results do not seem correct. Before diving deeper (which would require building casacore for some comparisons), I?d like to know if trying the second approach is likely to work. What is the relationship between the two packages?? Thanks, Tim Cornwell --? Tim Cornwell Sent with Airmail _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Fri Dec 16 05:32:10 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Fri, 16 Dec 2016 10:32:10 +0000 Subject: [AstroPy] Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tom, Here?s a simple script showing that setting the pv parameters on the WCS does nothing. I?ve just used wcs for this so reproject is not implicated. Thanks, Tim --? Tim Cornwell Sent with Airmail On 15 December 2016 at 7:57:36 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Could you share a minimal example script showing what you have tried, just so that we can reproduce the issue? The correct package to use here is reproject, so it should just be a matter of setting the output WCS correctly. If you can provide an example, I can investigate why it may not be working. Thanks, Tom On 15 December 2016 at 17:48, Tim Cornwell wrote: Hi Tom, It?s from an oblique SIN projection to a non-oblique SIN projection. It?s a standard use case for dealing with large fields in radio interferometry. The obliquity varies with time so we reproject a series of snapshot images and add them in non-oblique coordinates. --? Tim Cornwell Sent with Airmail On 15 December 2016 at 5:01:01 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Just to make sure I understand, you are trying to reproject an image to the -SIN projection? What projection is the image originally in? Cheers, Tom On 15 December 2016 at 11:34, Tim Cornwell wrote: Hi, I?m trying to use oblique projections in astropy for the SIN (Slant Orthographic) projection. This is well-defined in the Greisen/Calabretta papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer not to have to build CASA for this purpose (a reference library of calibration and imaging algorithms). In astropy, I can see two different approaches: - Use the reproject package - Use astropy.modelling.projections package I?m struggling with the former. The results do not seem correct. Before diving deeper (which would require building casacore for some comparisons), I?d like to know if trying the second approach is likely to work. What is the relationship between the two packages?? Thanks, Tim Cornwell --? Tim Cornwell Sent with Airmail _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SINProjection.py Type: application/octet-stream Size: 1667 bytes Desc: not available URL: From realtimcornwell at gmail.com Fri Dec 16 13:18:49 2016 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Fri, 16 Dec 2016 18:18:49 +0000 Subject: [AstroPy] SOLVED: Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tom, I fixed the problem. I was using pv = [(1, 0, -p), (1, 1, -q)] workimage.wcs.wcs.set_pv(pv) The actual usage should evidently be: pv = [(0, 0, q), (0, 1, p)] workimage.wcs.wcs.set_pv(pv) So the sign and the order of the obliquity factors are changed from CASA. Using 0 for the axis should probably be documented! With this change, project_interp works as needed. Thanks, Tim --? Tim Cornwell Sent with Airmail --? Tim Cornwell Sent with Airmail On 16 December 2016 at 10:32:12 am, Tim Cornwell (realtimcornwell at gmail.com) wrote: Hi Tom, Here?s a simple script showing that setting the pv parameters on the WCS does nothing. I?ve just used wcs for this so reproject is not implicated. Thanks, Tim --? Tim Cornwell Sent with Airmail On 15 December 2016 at 7:57:36 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Could you share a minimal example script showing what you have tried, just so that we can reproduce the issue? The correct package to use here is reproject, so it should just be a matter of setting the output WCS correctly. If you can provide an example, I can investigate why it may not be working. Thanks, Tom On 15 December 2016 at 17:48, Tim Cornwell wrote: Hi Tom, It?s from an oblique SIN projection to a non-oblique SIN projection. It?s a standard use case for dealing with large fields in radio interferometry. The obliquity varies with time so we reproject a series of snapshot images and add them in non-oblique coordinates. --? Tim Cornwell Sent with Airmail On 15 December 2016 at 5:01:01 pm, Thomas Robitaille (thomas.robitaille at gmail.com) wrote: Hi Tim, Just to make sure I understand, you are trying to reproject an image to the -SIN projection? What projection is the image originally in? Cheers, Tom On 15 December 2016 at 11:34, Tim Cornwell wrote: Hi, I?m trying to use oblique projections in astropy for the SIN (Slant Orthographic) projection. This is well-defined in the Greisen/Calabretta papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer not to have to build CASA for this purpose (a reference library of calibration and imaging algorithms). In astropy, I can see two different approaches: - Use the reproject package - Use astropy.modelling.projections package I?m struggling with the former. The results do not seem correct. Before diving deeper (which would require building casacore for some comparisons), I?d like to know if trying the second approach is likely to work. What is the relationship between the two packages?? Thanks, Tim Cornwell --? Tim Cornwell Sent with Airmail _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Fri Dec 16 19:18:26 2016 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 17 Dec 2016 00:18:26 +0000 Subject: [AstroPy] SOLVED: Using oblique SIN projections in astropy In-Reply-To: References: Message-ID: Hi Tim, Good to hear that you fixed it - could you open an issue in the Astropy issue tracker with suggestions on how to improve the documentation? https://github.com/astropy/astropy/issues Thanks, Tom On 16 December 2016 at 18:18, Tim Cornwell wrote: > Hi Tom, > > I fixed the problem. I was using > > pv = [(1, 0, -p), (1, 1, -q)] > workimage.wcs.wcs.set_pv(pv) > > The actual usage should evidently be: > > pv = [(0, 0, q), (0, 1, p)] > workimage.wcs.wcs.set_pv(pv) > > So the sign and the order of the obliquity factors are changed from CASA. > > Using 0 for the axis should probably be documented! > > With this change, project_interp works as needed. > > Thanks, > > Tim > > > -- > Tim Cornwell > Sent with Airmail > > -- > Tim Cornwell > Sent with Airmail > > On 16 December 2016 at 10:32:12 am, Tim Cornwell ( > realtimcornwell at gmail.com) wrote: > > Hi Tom, > > Here?s a simple script showing that setting the pv parameters on the WCS > does nothing. I?ve just used wcs for this so reproject is not implicated. > > Thanks, > > Tim > > -- > Tim Cornwell > Sent with Airmail > > On 15 December 2016 at 7:57:36 pm, Thomas Robitaille ( > thomas.robitaille at gmail.com) wrote: > > Hi Tim, > > Could you share a minimal example script showing what you have tried, just > so that we can reproduce the issue? > > The correct package to use here is reproject, so it should just be a > matter of setting the output WCS correctly. If you can provide an example, > I can investigate why it may not be working. > > Thanks, > Tom > > > On 15 December 2016 at 17:48, Tim Cornwell > wrote: > >> Hi Tom, >> >> It?s from an oblique SIN projection to a non-oblique SIN projection. It?s >> a standard use case for dealing with large fields in radio interferometry. >> The obliquity varies with time so we reproject a series of snapshot images >> and add them in non-oblique coordinates. >> >> -- >> Tim Cornwell >> Sent with Airmail >> >> On 15 December 2016 at 5:01:01 pm, Thomas Robitaille ( >> thomas.robitaille at gmail.com) wrote: >> >> Hi Tim, >> >> Just to make sure I understand, you are trying to reproject an image to >> the -SIN projection? What projection is the image originally in? >> >> Cheers, >> Tom >> >> >> On 15 December 2016 at 11:34, Tim Cornwell >> wrote: >> >>> Hi, >>> >>> I?m trying to use oblique projections in astropy for the SIN (Slant >>> Orthographic) projection. This is well-defined in the Greisen/Calabretta >>> papers and in WCSLIB. I?m confident that casacore can do it but I?d prefer >>> not to have to build CASA for this purpose (a reference library of >>> calibration and imaging algorithms). >>> >>> In astropy, I can see two different approaches: >>> >>> - Use the reproject package >>> - Use astropy.modelling.projections package >>> >>> I?m struggling with the former. The results do not seem correct. Before >>> diving deeper (which would require building casacore for some comparisons), >>> I?d like to know if trying the second approach is likely to work. What is >>> the relationship between the two packages? >>> >>> Thanks, >>> Tim Cornwell >>> >>> -- >>> Tim Cornwell >>> Sent with Airmail >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at physics.uwa.edu.au Sun Dec 18 23:20:24 2016 From: andrew at physics.uwa.edu.au (Andrew Williams) Date: Mon, 19 Dec 2016 12:20:24 +0800 Subject: [AstroPy] upcoming leap second Message-ID: <57042bc9-6e57-aafe-68df-81b8dac71ccb@physics.uwa.edu.au> There's a new leap second coming up in a couple of weeks, and the latest IERS data downloaded by astropy 1.2.1 (http://maia.usno.navy.mil/ser7/finals2000A.all) doesn't seem to include it - either that, or leap second calculations don't use that downloaded data. According to this thread: https://github.com/astropy/astropy/issues/5532 Astropy 1.3 should include the new leap second - is it still due out today? Also, we've got a few machines running Python 2.6.6, and astropy 1.0.3, and upgrading to a Python 2.7 variant so we can use the latest astropy will take a lot of work (and won't happen before the end of the year). How and where can I find the relevant data table in 1.0.3 to update the leap second data? Will I need to download astropy 1.0.3 source, edit cextern/erfa/dat.c and compile and install manually, or can I tweak some other data file in the copy I have installed using 'pip'? Andrew From aldcroft at head.cfa.harvard.edu Mon Dec 19 16:07:57 2016 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 19 Dec 2016 16:07:57 -0500 Subject: [AstroPy] upcoming leap second In-Reply-To: <57042bc9-6e57-aafe-68df-81b8dac71ccb@physics.uwa.edu.au> References: <57042bc9-6e57-aafe-68df-81b8dac71ccb@physics.uwa.edu.au> Message-ID: On Sun, Dec 18, 2016 at 11:20 PM, Andrew Williams wrote: > > There's a new leap second coming up in a couple of weeks, and the latest > IERS data downloaded by astropy 1.2.1 (http://maia.usno.navy.mil/ser > 7/finals2000A.all) doesn't seem to include it - either that, or leap > second calculations don't use that downloaded data. > That's correct, currently leap seconds are handled entirely within ERFA using static data. > > According to this thread: > > https://github.com/astropy/astropy/issues/5532 > > Astropy 1.3 should include the new leap second - is it still due out today? > > Also, we've got a few machines running Python 2.6.6, and astropy 1.0.3, > and upgrading to a Python 2.7 variant so we can use the latest astropy > will take a lot of work (and won't happen before the end of the year). > How and where can I find the relevant data table in 1.0.3 to update the > leap second data? Will I need to download astropy 1.0.3 source, edit > cextern/erfa/dat.c and compile and install manually, or can I tweak some > other data file in the copy I have installed using 'pip'? > For your Python 2.6 installation doing the source tweak you mentioned should work and be something you can do right now. See for example this (unmerged) PR: https://github.com/astropy/astropy/pull/5395/files The updated ERFA library with the leap second will be included in 1.0.11, which will be released before Dec. 31 according to Erik T. - Tom > > Andrew > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrianmpw at gmail.com Thu Dec 22 15:10:25 2016 From: adrianmpw at gmail.com (Adrian Price-Whelan) Date: Thu, 22 Dec 2016 15:10:25 -0500 Subject: [AstroPy] Call for volunteers: Astropy workshop at AAS 229 Message-ID: Hi all, Megan Sosey is leading a workshop at the AAS winter meeting (with a number of other Astropy developers) on "Using Python for Astronomical Data Analysis". The workshop is all day (8:30AM-5PM) on Tuesday, 3 January 2017 and will involve quite a bit of hands-on exercises and development. Many people have registered for the event (awesome!), so it would be great to have a team of volunteers to help wander the room and answer questions. If you are planning to be in Grapevine on Tuesday, are familiar with Python, Astropy, Conda environments, or even if you just use Python in your everyday workflow and are willing to volunteer for the day, please let us know! Megan is CC'd on this email. Thanks! - Adrian (Astropy community engagement coordinator for conferences) -- Adrian M. Price-Whelan Lyman Spitzer, Jr. Postdoctoral Fellow Princeton University http://adrian.pw From erik.tollerud at gmail.com Fri Dec 23 18:55:48 2016 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 23 Dec 2016 17:55:48 -0600 Subject: [AstroPy] ANN: Astropy v1.3 released Message-ID: Dear colleagues, We are very happy to announce the v1.3 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. New and improved major functionality in this release includes: * The WCSAxes framework for plotting points or images on celestial coordinates in matplotlib. * A new function in astropy.visualization to generate 3-color images from astronomy images in different bands. * Astropy coordinate representations now combine like vectors, with useful mathematical operations that can be performed on them. * Astropy coordinates and time objects now behave much more consistently like arrays when they are reshaped. * Earth locations can now be created from a postal address. * JPL Ephemerides can now be used in the coordinates sub-package to improve the accuracy of coordinate transformations and barycentric time corrections. * FORTRAN-style extended floating precision files like 1.495D+238 can now be read using astropy.io.ascii or Table.read. * Astropy objects can now be serialized to (or re-loaded from) a standard YAML representation. * FITS HDUs can now be lazy loaded, improving performance in files with many HDUs. * The default cosmology is now Planck 2015. In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/1.3.html Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you make use of the Anaconda Python Distribution, you can update to Astropy v1.3 with: conda update astropy If you normally use pip, you can upgrade with: pip install astropy --upgrade Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 210 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html Astropy v1.0 (our long term support release) will continue to be supported with bug fixes until the v2.0 release in June 2017, so if you need to use Astropy in a very stable environment, you may want to consider staying on the v1.0.x set of releases (for which we are simultaneously releasing v1.0.11). While we typically do not support non-LTS releases, we are also simultaneously releasing an Astropy v1.2.2, the last in that series. This update is primarily to include a leap second at the end of 2016 (but also contains other bug fixes). If you use Astropy directly for your work, or as a dependency to another package, please remember to include the following acknowledgment at the end of papers: ?This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013).? where (Astropy Collaboration, 2013) is a reference to the Astropy paper: http://dx.doi.org/10.1051/0004-6361/201322068 Please feel free to forward this announcement to anyone you think might be interested in this release! The announcement can also be found online at http://www.astropy.org/announcements/release-1.3.html. Erik Tollerud, Tom Robitaille, Kelle Cruz, and Tom Aldcroft on behalf of The Astropy Collaboration -------------- next part -------------- An HTML attachment was scrubbed... URL: From long at stsci.edu Mon Dec 26 12:12:14 2016 From: long at stsci.edu (Knox Long) Date: Mon, 26 Dec 2016 17:12:14 +0000 Subject: [AstroPy] Writing out meta data in ascii tables Message-ID: Astropy tables have the concept of meta data for a table. I would like to be able to write and read this information in an ascii table, ideally one formatted as ascii.fixed_width_two_line Does anyone know how to do this? Thanks, Knox -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Mon Dec 26 13:45:02 2016 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 26 Dec 2016 13:45:02 -0500 Subject: [AstroPy] Writing out meta data in ascii tables In-Reply-To: References: Message-ID: On Mon, Dec 26, 2016 at 12:12 PM, Knox Long wrote: > Astropy tables have the concept of meta data for a table. > > I would like to be able to write and read this information in an ascii > table, ideally one formatted as ascii.fixed_width_two_line > > Does anyone know how to do this? > The ASCII ECSV format supports doing round-tripping of meta data, and as of version 1.3 that meta data can contain astropy objects like SkyCoord, Time, Quantity and numpy arrays. ECSV is formatted as comma or space-delimited, and there is currently no built-in way in astropy to get round-trip meta-data support with fixed_width_two_line. Note that you can *write* your meta-data out in most formats by serializing it into lines (by your favorite method), and then set t.meta['comments'] = lines. - Tom > > Thanks, > Knox > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: