From pweilbacher at aip.de Wed Nov 1 05:58:16 2017 From: pweilbacher at aip.de (Peter Weilbacher) Date: Wed, 1 Nov 2017 10:58:16 +0100 (CET) Subject: [AstroPy] (Table) unit formatting In-Reply-To: References: Message-ID: Hmm, was my problem not clearly stated? Or does really nobody have a hint? P. On Wed, 25 Oct 2017, Peter Weilbacher wrote: > Dear all, > > I'm trying to add units to table columns with AstroPy (v2.0.1) and save > the resulting table as FITS (for now). So I enter unit strings like this > table['colname'].unit = 'erg/s/cm**2' > and write the table to disk. Unfortunately, I not only get the annoying > units warning about the multiple slashes (any way to turn that off?) but > also discover that the strong got converted to 'cm-2 erg s-1' which > while correct is really ugly -- nobody would write it like that in a > paper! And actually, when I use print to look at the table before > saving, I see that units as 'erg / (cm2 s)' which is not nice, either, > but that I can live with. > > Can I adjust this behavior of do I have to edit the TUNITn manually > after saving the file? > > By the way, I was also looking for a way to influence the display of the > columns, i.e. the TDISPn keywords. If I set a format using > t['colname'].format = '%4.2f' > this is used when printing the table, but does not end up in the > corresponding TDISPn after writing to FITS. Am I missing something? > > Finally, I'd like to give potential users of my file a longer > description, and hoped there was a way to write something to the FITS > comment part (after the slash of the TTYPEn keywords). Setting > t['colname'].description = 'a descriptive message' > works, but influences neither printing of the table nor writing to FITS. > > Any hints? > Peter. -- Dr. Peter M. Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From thomas.robitaille at gmail.com Wed Nov 1 11:15:15 2017 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 1 Nov 2017 15:15:15 +0000 Subject: [AstroPy] (Table) unit formatting In-Reply-To: References: Message-ID: Hi Peter, The issue is that the FITS standard includes a prescription about how units should be formatted, and we follow the standard strictly when writing files to make sure the files we produce are standard-compliant. I would therefore advise against trying to modify TUNIT to make it more 'human-friendly' since it will result in it being non-standard-compliant and could cause issues when other people try and read it in. When the table is loaded into a Table object in Python you can of course convert units to various string representations including latex - but we should stick to the standard when writing FITS files. The fact that the format on Table columns is not propagated to TDISP sounds like an oversight. Can you open an issue in the astropy repository? https://github.com/astropy/astropy/issues/new We indeed don't currently print descriptions when showing a Table object in Python and also don't write them to FITS. Feel free to open feature requests for these in the issue tracker above too. Keep that issue separate from the TDISP issue which I think is an actual bug/oversight - whereas I think there is no 'standard' way to write descriptions for columns to FITS so this is more of a possible feature request. I hope this helps! Cheers, Tom On 25 October 2017 at 14:28, Peter Weilbacher wrote: > Dear all, > > I'm trying to add units to table columns with AstroPy (v2.0.1) and save > the resulting table as FITS (for now). So I enter unit strings like this > table['colname'].unit = 'erg/s/cm**2' > and write the table to disk. Unfortunately, I not only get the annoying > units warning about the multiple slashes (any way to turn that off?) but > also discover that the strong got converted to 'cm-2 erg s-1' which > while correct is really ugly -- nobody would write it like that in a > paper! And actually, when I use print to look at the table before > saving, I see that units as 'erg / (cm2 s)' which is not nice, either, > but that I can live with. > > Can I adjust this behavior of do I have to edit the TUNITn manually > after saving the file? > > By the way, I was also looking for a way to influence the display of the > columns, i.e. the TDISPn keywords. If I set a format using > t['colname'].format = '%4.2f' > this is used when printing the table, but does not end up in the > corresponding TDISPn after writing to FITS. Am I missing something? > > Finally, I'd like to give potential users of my file a longer > description, and hoped there was a way to write something to the FITS > comment part (after the slash of the TTYPEn keywords). Setting > t['colname'].description = 'a descriptive message' > works, but influences neither printing of the table nor writing to FITS. > > Any hints? > Peter. > -- > Dr. Peter M. Weilbacher http://www.aip.de/People/PWeilbacher > Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 > ------------------------------------------------------------------------ > Leibniz-Institut f?r Astrophysik Potsdam (AIP) > An der Sternwarte 16, D-14482 Potsdam > > Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker > Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannick.roehlly at gmail.com Wed Nov 1 11:31:07 2017 From: yannick.roehlly at gmail.com (Yannick Roehlly) Date: Wed, 01 Nov 2017 15:31:07 +0000 Subject: [AstroPy] (Table) unit formatting In-Reply-To: References: Message-ID: <2539108.XOUksWGyRD@galactica> On mercredi 1 novembre 2017 15:15:15 GMT Thomas Robitaille wrote: > I think there is no 'standard' way to write descriptions for columns to FITS Hi, In fact, there is a Topcat way to store the description TCOMMnn, nn being the column number. But as it is not in the standard, it is not taken into accound by astropy. The problem is that when you open a table with astropy and add a column, when you save the table an open it again with Topcat the column descriptions are wrong from the inserted column on, because astropy kept the TCOMM keywords. Strictly speaking, it is not a bug in astropy as it deals with the TCOMM keywords as any other keyword. What people think about this? Cheers, Yannick -- I need another lawyer like I need another hole in my head. -- Fratianno From pweilbacher at aip.de Wed Nov 1 12:52:13 2017 From: pweilbacher at aip.de (Peter Weilbacher) Date: Wed, 1 Nov 2017 17:52:13 +0100 (CET) Subject: [AstroPy] (Table) unit formatting In-Reply-To: References: Message-ID: Hi Tom, On Wed, 1 Nov 2017, Thomas Robitaille wrote: > The issue is that the FITS standard includes a prescription about how units > should be formatted, and we follow the standard strictly when writing files > to make sure the files we produce are standard-compliant. I would therefore > advise against trying to modify TUNIT to make it more 'human-friendly' > since it will result in it being non-standard-compliant and could cause > issues when other people try and read it in. When the table is loaded into > a Table object in Python you can of course convert units to various string > representations including latex - but we should stick to the standard when > writing FITS files. 'erg/s/cm**2' /is/ a valid FITS unit string, I see no reason that it gets mangled to 'cm-2 erg s-1'. I could agree it getting changed to 'erg/(s cm**2)' but removing all slashes and sorting the individual units in ascending alphabetical order is not required by the standard AFAICT. And actually, since the standard says that multiple slashes /may/ be used (despite them being discouraged), FITS readers have to be capable to handle such files anyway. (Couldn't find the sentence in the IAU style manual that forbids multiple slashes.) > The fact that the format on Table columns is not propagated to TDISP sounds > like an oversight. Can you open an issue in the astropy repository? Done, https://github.com/astropy/astropy/issues/6806 > We indeed don't currently print descriptions when showing a Table object in > Python and also don't write them to FITS. Feel free to open feature > requests for these in the issue tracker above too. Keep that issue separate > from the TDISP issue which I think is an actual bug/oversight - whereas I > think there is no 'standard' way to write descriptions for columns to FITS > so this is more of a possible feature request. Right, anyway, I opened https://github.com/astropy/astropy/issues/6807 I didn't see a way to make it a feature request over a bug, but someone else may be able to tag it accordingly. But thanks for the answers, so I know that for now I'll have to do these things "by hand". Peter. -- Dr. Peter M. Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From npkuin at gmail.com Wed Nov 1 13:41:34 2017 From: npkuin at gmail.com (Paul Kuin) Date: Wed, 1 Nov 2017 17:41:34 +0000 Subject: [AstroPy] (Table) unit formatting In-Reply-To: References: Message-ID: During the 1990's we had some discussions on standardization of units. Unfortunately, CDS and Heasarc were using different standardizations, and as far as I know that is still the case. That's the 'Flexible' in FITS, I suppose. On Wed, Nov 1, 2017 at 4:52 PM, Peter Weilbacher wrote: > Hi Tom, > > On Wed, 1 Nov 2017, Thomas Robitaille wrote: > > > The issue is that the FITS standard includes a prescription about how > units > > should be formatted, and we follow the standard strictly when writing > files > > to make sure the files we produce are standard-compliant. I would > therefore > > advise against trying to modify TUNIT to make it more 'human-friendly' > > since it will result in it being non-standard-compliant and could cause > > issues when other people try and read it in. When the table is loaded > into > > a Table object in Python you can of course convert units to various > string > > representations including latex - but we should stick to the standard > when > > writing FITS files. > > 'erg/s/cm**2' /is/ a valid FITS unit string, I see no reason that it > gets mangled to 'cm-2 erg s-1'. I could agree it getting changed to > 'erg/(s cm**2)' but removing all slashes and sorting the individual > units in ascending alphabetical order is not required by the standard > AFAICT. > > And actually, since the standard says that multiple slashes /may/ be > used (despite them being discouraged), FITS readers have to be capable > to handle such files anyway. (Couldn't find the sentence in the IAU > style manual that forbids multiple slashes.) > > > The fact that the format on Table columns is not propagated to TDISP > sounds > > like an oversight. Can you open an issue in the astropy repository? > > Done, https://github.com/astropy/astropy/issues/6806 > > > We indeed don't currently print descriptions when showing a Table object > in > > Python and also don't write them to FITS. Feel free to open feature > > requests for these in the issue tracker above too. Keep that issue > separate > > from the TDISP issue which I think is an actual bug/oversight - whereas I > > think there is no 'standard' way to write descriptions for columns to > FITS > > so this is more of a possible feature request. > > Right, anyway, I opened https://github.com/astropy/astropy/issues/6807 > I didn't see a way to make it a feature request over a bug, but someone > else may be able to tag it accordingly. > > But thanks for the answers, so I know that for now I'll have to do these > things "by hand". > > Peter. > -- > Dr. Peter M. Weilbacher http://www.aip.de/People/PWeilbacher > Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 > ------------------------------------------------------------------------ > Leibniz-Institut f?r Astrophysik Potsdam (AIP) > An der Sternwarte 16, D-14482 Potsdam > > Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker > Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204111 (work) mobile +44(0)7908715953 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cadair.com Thu Nov 2 06:22:25 2017 From: stuart at cadair.com (Stuart Mumford) Date: Thu, 2 Nov 2017 10:22:25 +0000 Subject: [AstroPy] OpenAstronomy Committee Message-ID: <324cce54-3d1e-dac0-a34f-f1556de84368@cadair.com> Hello all, OpenAstronomy is a collection of open source astronomy-related projects (http://openastronomy.org/members/), initially founded as an umbrella organisation for Google Summer of Code. Over the last two years more projects have joined and the Python in Astronomy conference series has affiliated itself with OpenAstronomy. Due to the fact that GSOC provides money to OpenAstronomy (both for mentors working on member projects and directly to OpenAstronomy as an org) there is general agreement between the GSOC admins that some kind of decision making group for this money would be beneficial. In addition to this the idea was floated at pyastro17 that an advisory group for the different pyastro SOCs (along the lines of a similar group for dotastro) would be beneficial to the future of pyastro. To this end I am recruiting people to serve on the OpenAstronomy committee. The idea of this committee is to be advisory, not to require its members to actually organise or implement the work of OpenAstronomy, and to make decisions regarding allocation of (GSOC) money that is sent to "OpenAstronomy". If you are interested in serving on this committee, and you are actively involved in one the member projects or in the Python in Astronomy conference series, or you wish to nominate someone who is please email the OpenAstronomy mailing list (openastronomy at googlegroups.com ) by the 16th November. We are particularly interested in participation or nominations of people who may not have served in a leadership role in our community before. Thanks, Stuart Mumford -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelseifert04 at yahoo.de Fri Nov 3 10:23:29 2017 From: michaelseifert04 at yahoo.de (Michael Seifert) Date: Fri, 3 Nov 2017 14:23:29 +0000 (UTC) Subject: [AstroPy] ANN: Release of ccdproc 1.3.0 References: <1554238875.2944735.1509719009517.ref@mail.yahoo.com> Message-ID: <1554238875.2944735.1509719009517@mail.yahoo.com> Dear colleagues, We are pleased to announce the release of ccdproc v1.3.0. 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: - Several new options for ImageFileCollection, including specifying the extension, using glob to include/exclude files and a new representation. - A function to convert a bitfield array (an array containing bitflags) to a boolean array that can be used as mask. - A sum-combine method for Combiner. The new release also includes many additional changes and bug fixes. Special thanks to all the contributors since the last major release, especially first-time contributors Jiyong Youn, JVSN Reddy, Yoonsoo P. Bach, and Benjamin Weiner. 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 pawel at pmkozlowski.com Wed Nov 8 16:35:27 2017 From: pawel at pmkozlowski.com (Pawel Kozlowski) Date: Wed, 8 Nov 2017 14:35:27 -0700 Subject: [AstroPy] SpectroscoPy package overlaps Message-ID: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> Hi all, We're setting up a spectroscopy package called SpectroscoPy for the PlasmaPy project and we are looking for overlaps/synergies with spectroscopic packages under AstroPy. SpectroscoPy: https://github.com/PlasmaPy/SpectroscoPy One of the main goals is to create a syntax which uniquely describes atomic energy levels and configurations that can then be used with querying tools (e.g. astroquery) to query various line databases (e.g. NIST, CHIANTI). This generalized querying tool can then be interfaced to a simulation suite (starting with simple LTE spectra and expanding from there) with a simple switch for choosing which database to use. This way one can quickly compare spectra produced from different databases. We would also like to find/create a method for uniquely identifying databases and their versions for reproducibility. A separate arm of the project would focus on tools relevant to design and analysis of experiments. This would include stuff like commonly used Bragg crystals and their interlattice spacings, a query tool for fetching and comparing cold filter transmissions from Henke (http://henke.lbl.gov/optical_constants/filter2.html), a tool for applying whitelight and dispersion calibrations to a measured spectrum. What are the astropy community's thoughts on such a project? Would it be of value to you? Is there significant overlap with any current projects on astropy? Cheers, Pawel Kozlowski (lemmatum) https://github.com/lemmatum From xavier at ucolick.org Wed Nov 8 18:00:43 2017 From: xavier at ucolick.org (Jason Prochaska) Date: Wed, 8 Nov 2017 15:00:43 -0800 Subject: [AstroPy] SpectroscoPy package overlaps In-Reply-To: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> References: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> Message-ID: Yup, I see quite a bit of potential overlap with the astropy affiliated package named linetools: https://github.com/linetools/linetools But the examples described in your email also appear to be nicely complementary. Sincerely, X On Wed, Nov 8, 2017 at 1:35 PM, Pawel Kozlowski wrote: > Hi all, > > We're setting up a spectroscopy package called SpectroscoPy for the > PlasmaPy project and we are looking for overlaps/synergies with > spectroscopic packages under AstroPy. > > SpectroscoPy: https://github.com/PlasmaPy/SpectroscoPy > > One of the main goals is to create a syntax which uniquely describes > atomic energy levels and configurations that can then be used with > querying tools (e.g. astroquery) to query various line databases (e.g. > NIST, CHIANTI). This generalized querying tool can then be interfaced to > a simulation suite (starting with simple LTE spectra and expanding from > there) with a simple switch for choosing which database to use. This way > one can quickly compare spectra produced from different databases. We > would also like to find/create a method for uniquely identifying > databases and their versions for reproducibility. > > > A separate arm of the project would focus on tools relevant to design > and analysis of experiments. This would include stuff like commonly used > Bragg crystals and their interlattice spacings, a query tool for > fetching and comparing cold filter transmissions from Henke > (http://henke.lbl.gov/optical_constants/filter2.html), a tool for > applying whitelight and dispersion calibrations to a measured spectrum. > > > What are the astropy community's thoughts on such a project? Would it be > of value to you? Is there significant overlap with any current projects > on astropy? > > > Cheers, > > Pawel Kozlowski (lemmatum) > > https://github.com/lemmatum > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy -- -- ---------------------------------------------- J. Xavier Prochaska UCO/Lick Observatory 1156 High St. UC Santa Cruz Santa Cruz, CA 95064 Affiliate of IPMU Affiliate of LBNL http://www.ucolick.org/~xavier/ http://imps.ucolick.org/ http://k1dm3.ucolick.org/ https://github.com/linetools/linetools https://github.com/pyigm/pyigm https://github.com/specdb/specdb 831-459-2135 (Direct) 831-459-2991 (UCO/Lick Main) 831-459-5244 (Fax) From pawel at pmkozlowski.com Wed Nov 8 18:11:34 2017 From: pawel at pmkozlowski.com (Pawel Kozlowski) Date: Wed, 8 Nov 2017 16:11:34 -0700 Subject: [AstroPy] SpectroscoPy package overlaps In-Reply-To: References: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> Message-ID: Thanks for the suggestion! I've added it to our discussion on "working smart" on SpectroscoPy (https://github.com/PlasmaPy/SpectroscoPy/issues/11). Cheers, Pawel On 11/08/2017 04:00 PM, Jason Prochaska wrote: > Yup, I see quite a bit of potential overlap with > the astropy affiliated package named linetools: > > https://github.com/linetools/linetools > > But the examples described in your email also > appear to be nicely complementary. > > Sincerely, > > X > > > On Wed, Nov 8, 2017 at 1:35 PM, Pawel Kozlowski wrote: >> Hi all, >> >> We're setting up a spectroscopy package called SpectroscoPy for the >> PlasmaPy project and we are looking for overlaps/synergies with >> spectroscopic packages under AstroPy. >> >> SpectroscoPy: https://github.com/PlasmaPy/SpectroscoPy >> >> One of the main goals is to create a syntax which uniquely describes >> atomic energy levels and configurations that can then be used with >> querying tools (e.g. astroquery) to query various line databases (e.g. >> NIST, CHIANTI). This generalized querying tool can then be interfaced to >> a simulation suite (starting with simple LTE spectra and expanding from >> there) with a simple switch for choosing which database to use. This way >> one can quickly compare spectra produced from different databases. We >> would also like to find/create a method for uniquely identifying >> databases and their versions for reproducibility. >> >> >> A separate arm of the project would focus on tools relevant to design >> and analysis of experiments. This would include stuff like commonly used >> Bragg crystals and their interlattice spacings, a query tool for >> fetching and comparing cold filter transmissions from Henke >> (http://henke.lbl.gov/optical_constants/filter2.html), a tool for >> applying whitelight and dispersion calibrations to a measured spectrum. >> >> >> What are the astropy community's thoughts on such a project? Would it be >> of value to you? Is there significant overlap with any current projects >> on astropy? >> >> >> Cheers, >> >> Pawel Kozlowski (lemmatum) >> >> https://github.com/lemmatum >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy > > From crawfordsm at gmail.com Thu Nov 9 03:04:29 2017 From: crawfordsm at gmail.com (Steve Crawford) Date: Thu, 9 Nov 2017 10:04:29 +0200 Subject: [AstroPy] SpectroscoPy package overlaps In-Reply-To: References: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> Message-ID: Hi Pawel-- Definitely looks like an interested project! You may want to check out https://github.com/astropy/astropy-APEs/pull/28, which outlines a Spectrum1D object and also highlights some of our planned work on astronomical spectroscopy. Any feedback would be appreciated there and collaboration is definitely welcome! Cheers Steve On Thu, Nov 9, 2017 at 1:11 AM, Pawel Kozlowski wrote: > Thanks for the suggestion! I've added it to our discussion on "working > smart" on SpectroscoPy (https://github.com/PlasmaPy/SpectroscoPy/issues/11). > > Cheers, > > Pawel > > > On 11/08/2017 04:00 PM, Jason Prochaska wrote: >> Yup, I see quite a bit of potential overlap with >> the astropy affiliated package named linetools: >> >> https://github.com/linetools/linetools >> >> But the examples described in your email also >> appear to be nicely complementary. >> >> Sincerely, >> >> X >> >> >> On Wed, Nov 8, 2017 at 1:35 PM, Pawel Kozlowski wrote: >>> Hi all, >>> >>> We're setting up a spectroscopy package called SpectroscoPy for the >>> PlasmaPy project and we are looking for overlaps/synergies with >>> spectroscopic packages under AstroPy. >>> >>> SpectroscoPy: https://github.com/PlasmaPy/SpectroscoPy >>> >>> One of the main goals is to create a syntax which uniquely describes >>> atomic energy levels and configurations that can then be used with >>> querying tools (e.g. astroquery) to query various line databases (e.g. >>> NIST, CHIANTI). This generalized querying tool can then be interfaced to >>> a simulation suite (starting with simple LTE spectra and expanding from >>> there) with a simple switch for choosing which database to use. This way >>> one can quickly compare spectra produced from different databases. We >>> would also like to find/create a method for uniquely identifying >>> databases and their versions for reproducibility. >>> >>> >>> A separate arm of the project would focus on tools relevant to design >>> and analysis of experiments. This would include stuff like commonly used >>> Bragg crystals and their interlattice spacings, a query tool for >>> fetching and comparing cold filter transmissions from Henke >>> (http://henke.lbl.gov/optical_constants/filter2.html), a tool for >>> applying whitelight and dispersion calibrations to a measured spectrum. >>> >>> >>> What are the astropy community's thoughts on such a project? Would it be >>> of value to you? Is there significant overlap with any current projects >>> on astropy? >>> >>> >>> Cheers, >>> >>> Pawel Kozlowski (lemmatum) >>> >>> https://github.com/lemmatum >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at python.org >>> https://mail.python.org/mailman/listinfo/astropy >> >> > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy From trive at astro.su.se Thu Nov 9 05:55:16 2017 From: trive at astro.su.se (Emil Rivera-Thorsen) Date: Thu, 9 Nov 2017 11:55:16 +0100 Subject: [AstroPy] SpectroscoPy package overlaps In-Reply-To: References: <4ea40369-558f-2165-72f3-a659929dc125@pmkozlowski.com> Message-ID: From the description, it also sounds like there might be potential overlap of effort with ChiantiPy (https://github.com/chianti-atomic/ChiantiPy) and PyNeb (http://www.iac.es/proyecto/PyNeb/). On 2017-11-09 09:04, Steve Crawford wrote: > Hi Pawel-- > > Definitely looks like an interested project! You may want to check > out https://github.com/astropy/astropy-APEs/pull/28, which outlines a > Spectrum1D object and also highlights some of our planned work on > astronomical spectroscopy. Any feedback would be appreciated there > and collaboration is definitely welcome! > > Cheers > Steve > > On Thu, Nov 9, 2017 at 1:11 AM, Pawel Kozlowski wrote: >> Thanks for the suggestion! I've added it to our discussion on "working >> smart" on SpectroscoPy (https://github.com/PlasmaPy/SpectroscoPy/issues/11). >> >> Cheers, >> >> Pawel >> >> >> On 11/08/2017 04:00 PM, Jason Prochaska wrote: >>> Yup, I see quite a bit of potential overlap with >>> the astropy affiliated package named linetools: >>> >>> https://github.com/linetools/linetools >>> >>> But the examples described in your email also >>> appear to be nicely complementary. >>> >>> Sincerely, >>> >>> X >>> >>> >>> On Wed, Nov 8, 2017 at 1:35 PM, Pawel Kozlowski wrote: >>>> Hi all, >>>> >>>> We're setting up a spectroscopy package called SpectroscoPy for the >>>> PlasmaPy project and we are looking for overlaps/synergies with >>>> spectroscopic packages under AstroPy. >>>> >>>> SpectroscoPy: https://github.com/PlasmaPy/SpectroscoPy >>>> >>>> One of the main goals is to create a syntax which uniquely describes >>>> atomic energy levels and configurations that can then be used with >>>> querying tools (e.g. astroquery) to query various line databases (e.g. >>>> NIST, CHIANTI). This generalized querying tool can then be interfaced to >>>> a simulation suite (starting with simple LTE spectra and expanding from >>>> there) with a simple switch for choosing which database to use. This way >>>> one can quickly compare spectra produced from different databases. We >>>> would also like to find/create a method for uniquely identifying >>>> databases and their versions for reproducibility. >>>> >>>> >>>> A separate arm of the project would focus on tools relevant to design >>>> and analysis of experiments. This would include stuff like commonly used >>>> Bragg crystals and their interlattice spacings, a query tool for >>>> fetching and comparing cold filter transmissions from Henke >>>> (http://henke.lbl.gov/optical_constants/filter2.html), a tool for >>>> applying whitelight and dispersion calibrations to a measured spectrum. >>>> >>>> >>>> What are the astropy community's thoughts on such a project? Would it be >>>> of value to you? Is there significant overlap with any current projects >>>> on astropy? >>>> >>>> >>>> Cheers, >>>> >>>> Pawel Kozlowski (lemmatum) >>>> >>>> https://github.com/lemmatum >>>> >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at python.org >>>> https://mail.python.org/mailman/listinfo/astropy >>> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy From deil.christoph at googlemail.com Sun Nov 12 11:52:08 2017 From: deil.christoph at googlemail.com (Christoph Deil) Date: Sun, 12 Nov 2017 17:52:08 +0100 Subject: [AstroPy] Compute approximate WCS for a given wide-field photo Message-ID: <904F71A5-25CD-4307-B61E-388B21461A3D@googlemail.com> Hi, I?d like to make some images that combine a normal photo with an astronomical survey image, as in this example: https://de.wikipedia.org/wiki/High_Energy_Stereoscopic_System#/media/File:HESS-Gammastrahlungsquellen_Montage.jpg I know about http://reproject.readthedocs.io , but to use it I need a WCS for the photo. Let?s assume I know the sky position of a few pixels in the photo already (from star finding or by hand). How can I get an approximate WCS for the photo? Is there some projection that roughly matches what wide-field (non-astronomical, hand-held, covering ~ 50 deg on the sky) photo cameras do? I presume the projection reference point should always be at the centre of the image? Can the pixel scale parameters can be computed from EXIF meta information in the photo? Is there a good web page with a description, or even a Python package that will help me compute the WCS? Or is the whole approach of trying to go via a WCS transform for the photo not a great idea, and some other transform should be used? Any tips would be appreciated! ? Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From parejkoj at uw.edu Sun Nov 12 13:20:41 2017 From: parejkoj at uw.edu (John K. Parejko) Date: Sun, 12 Nov 2017 10:20:41 -0800 Subject: [AstroPy] Compute approximate WCS for a given wide-field photo In-Reply-To: <904F71A5-25CD-4307-B61E-388B21461A3D@googlemail.com> References: <904F71A5-25CD-4307-B61E-388B21461A3D@googlemail.com> Message-ID: http://astrometry.net/ You can use the web interface, or download the package and run it locally. You don?t even need to know the field location by hand: it?s pretty good at figuring it out, so long as there are a reasonable number of stars. John > On 12Nov 2017, at 08:52, Christoph Deil wrote: > > Hi, > > I?d like to make some images that combine a normal photo with an astronomical survey image, as in this example: > https://de.wikipedia.org/wiki/High_Energy_Stereoscopic_System#/media/File:HESS-Gammastrahlungsquellen_Montage.jpg > > I know about http://reproject.readthedocs.io, but to use it I need a WCS for the photo. > > Let?s assume I know the sky position of a few pixels in the photo already (from star finding or by hand). > > How can I get an approximate WCS for the photo? > > Is there some projection that roughly matches what wide-field (non-astronomical, hand-held, covering ~ 50 deg on the sky) photo cameras do? > I presume the projection reference point should always be at the centre of the image? > Can the pixel scale parameters can be computed from EXIF meta information in the photo? > > Is there a good web page with a description, or even a Python package that will help me compute the WCS? > > Or is the whole approach of trying to go via a WCS transform for the photo not a great idea, and some other transform should be used? > > Any tips would be appreciated! > > ? Christoph > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy From eric at naoj.org Mon Nov 13 01:42:02 2017 From: eric at naoj.org (Eric Jeschke) Date: Sun, 12 Nov 2017 20:42:02 -1000 Subject: [AstroPy] AstroPy Digest, Vol 134, Issue 6 In-Reply-To: References: Message-ID: > From: Christoph Deil > > Is there a good web page with a description, or even a Python package that > will help me compute the WCS? > > Hi Christoph, Perhaps I don't understand the particular kind of photo that you have, but depending on the resolution I believe you can use the astrometry.net python package to solve for the field and produce a reasonable WCS. Best Regards, ~Eric -- Eric Jeschke | eric at naoj.org | ????,???? Software Engineer | 808-934-5908 | ??????????? Subaru Telescope | | ?????? National Astronomical Observatory of Japan http://naoj.org/staff/eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From astropy at liska.ath.cx Mon Nov 13 02:22:37 2017 From: astropy at liska.ath.cx (Ole Streicher) Date: Mon, 13 Nov 2017 08:22:37 +0100 Subject: [AstroPy] AstroPy Digest, Vol 134, Issue 6 References: Message-ID: <87shdiod6q.fsf@liska.ath.cx> Eric Jeschke writes: > From: Christoph Deil >> Is there a good web page with a description, or even a Python >> package that will help me compute the WCS? > > Perhaps I don't understand the particular kind of photo that you have, > but depending on the resolution I believe you can use the > astrometry.net python package to solve for the field and produce a > reasonable WCS. They also have a mailing list, , and the author (Dustin Lang) is extraordinarily responsive and helpful. The github repo: https://github.com/dstndstn/astrometry.net BTW, the astrometry.net Python package is still Python-2 only; I think that PRs to get Python-3 compatibility would be welcome ;-) Cheers Ole From thomas.robitaille at gmail.com Mon Nov 13 06:43:03 2017 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 13 Nov 2017 11:43:03 +0000 Subject: [AstroPy] glue v0.12 released! Message-ID: Hi everyone, We are happy to announce the release of *glue v0.12*! For anyone not familiar with this package, glue is a Python library and application for multidimensional linked data exploration, which you can read up more about at http://glueviz.org *Changes in this release* An overview of the main changes in this release is available here: http://glueviz.org/en/stable/whatsnew/whatsnew.html The most significant changes are as follows: - An improved scatter viewer, which now includes support for showing arrows/vectors, and makes it easier to combine different kinds of visualization (e.g. lines, points, errorbars, and so on) - We now provide a clearer explanation when a layer in a visualization cannot be enabled, for example because it is a subset based on components that are not present in the selected dataset. - It is now possible to define arbitrary actions that are available when control-clicking on datasets, subsets, or subset groups in the data collection (in the top left) - The performance of the 3D volume rendering viewer has been significantly improved - We now have experimental support for creating fixed layouts/dashboards You can read about these changes in more detail at the link above. In addition, this release includes many bug fixes and improvements in usability, as well as improvements to the code under-the-hood to make the code more accessible and easier to modify in future. In parallel with this release of glue we have also released an experimental version of a SAMP plugin that may be of interest to astronomers - this allows glue to exchange datasets and subsets with other SAMP-enabled applications such as TOPCAT, DS9, Aladin, and more. See the above link for more details. *Installing/updating g**lue* As usual, we recommend installing glue using the Anaconda Python Distribution . To get the latest version of glue (v0.12), you will need to make sure you use the glueviz conda channel. If you are using the conda command, this means that you need to do: conda install -c glueviz glueviz *Note that this has changed from previous versions, for which glue was installed from the conda-forge channel.* If you use the Anaconda launcher or navigator to install glue graphically, take a look at the instructions on our website to find out how to get the latest version. We also provide instructions for other installation methods, including pip. Please let us know if you run into any issues installing or using glue - you can either let us know by email, by opening GitHub issues, or you can join the glue slack channel and chat with us there. Thanks to everyone who contributed to this release! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtylergee at gmail.com Mon Nov 13 17:23:04 2017 From: wtylergee at gmail.com (Wilfred Tyler Gee) Date: Tue, 14 Nov 2017 09:23:04 +1100 Subject: [AstroPy] AstroPy Digest, Vol 134, Issue 6 In-Reply-To: <87shdiod6q.fsf@liska.ath.cx> References: <87shdiod6q.fsf@liska.ath.cx> Message-ID: For the record, astrometry.net does now work with Python 3 thanks to all the work Dustin Lang has put into it lately. On Mon, Nov 13, 2017 at 6:22 PM, Ole Streicher wrote: > Eric Jeschke writes: > > From: Christoph Deil > >> Is there a good web page with a description, or even a Python > >> package that will help me compute the WCS? > > > > Perhaps I don't understand the particular kind of photo that you have, > > but depending on the resolution I believe you can use the > > astrometry.net python package to solve for the field and produce a > > reasonable WCS. > > They also have a mailing list, , and the > author (Dustin Lang) is extraordinarily responsive and helpful. > > The github repo: > > https://github.com/dstndstn/astrometry.net > > BTW, the astrometry.net Python package is still Python-2 only; I think > that PRs to get Python-3 compatibility would be welcome ;-) > > Cheers > > Ole > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- ~Wilfred Tyler Gee -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eloise.Vitte at etu.unige.ch Mon Nov 20 09:19:54 2017 From: Eloise.Vitte at etu.unige.ch (=?iso-8859-1?Q?Elo=EFse_Aur=E9lie_B=E9n=E9dicte_Vitte?=) Date: Mon, 20 Nov 2017 14:19:54 +0000 Subject: [AstroPy] How to remove specific rows from an existing FITS file ? Message-ID: Hello, I'm encountering a problem with a FITS file. I want to delete some rows that have certain values with a FOR loop in which I put IF conditions. It doesn't work when I use the function remove_row(). So, do you have any idea of the mistake I'm commiting ? Kind regards, Vitte Elo?se -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Mon Nov 20 09:37:56 2017 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Mon, 20 Nov 2017 09:37:56 -0500 Subject: [AstroPy] How to remove specific rows from an existing FITS file ? In-Reply-To: References: Message-ID: Hi Vitte, Do you want to remove the rows from the original FITS file on disk or just from the table data that you are working with in memory? For the second option you need to generate a specification of the table indices for the rows you want to remove. For instance, to remove row 0, or rows [2:5], or rows 1 and 3, the following examples (respectively) will work: >>> t.remove_row(0) >>> t.remove_rows(slice(2, 5)) >>> t.remove_rows([1, 3]) So a simple way to do this might be : data = Table.read('data.fits') bad_rows = [] for i_row, row in enumerate(data): if (some condition of row): bad_rows.append(i_row) data.remove_rows(bad_rows) This isn't necessarily the fastest way but gets the job done. If you can express the condition as an array comparison then it can be much faster. Cheers, Tom On Mon, Nov 20, 2017 at 9:19 AM, Elo?se Aur?lie B?n?dicte Vitte < Eloise.Vitte at etu.unige.ch> wrote: > Hello, > > > I'm encountering a problem with a FITS file. I want to delete some rows > that have certain values with a FOR loop in which I put IF conditions. It > doesn't work when I use the function remove_row(). > > > So, do you have any idea of the mistake I'm commiting ? > > > Kind regards, > > Vitte Elo?se > > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejensen1 at swarthmore.edu Mon Nov 20 09:41:20 2017 From: ejensen1 at swarthmore.edu (Eric L. N. Jensen) Date: Mon, 20 Nov 2017 09:41:20 -0500 Subject: [AstroPy] How to remove specific rows from an existing FITS file ? In-Reply-To: References: Message-ID: <28D4B2B7-1F8A-4785-A8A3-2F690A83D59B@swarthmore.edu> Hi, Can you show the code you?re using, and the error you?re getting (or unexpected output, if there?s no error)? That will make it easier for people to see where the problem is. Eric > On Nov 20, 2017, at 9:19 AM, Elo?se Aur?lie B?n?dicte Vitte > wrote: > > Hello, > > I'm encountering a problem with a FITS file. I want to delete some rows that have certain values with a FOR loop in which I put IF conditions. It doesn't work when I use the function remove_row(). > > So, do you have any idea of the mistake I'm commiting ? > > Kind regards, > Vitte Elo?se > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: