From thomas.robitaille at gmail.com Wed Jul 3 12:51:39 2019 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 3 Jul 2019 17:51:39 +0100 Subject: [AstroPy] glue v0.15 released Message-ID: Hi everyone, We are happy to announce the release of *glue v0.15*! For anyone not familiar with this package, *glue* is a Python library and application for multidimensional and linked data exploration, which you can find out about at http://glueviz.org *Changes in this release* An overview of the main changes in this release is available here: http://docs.glueviz.org/en/stable/whatsnew/whatsnew.html The most significant changes are as follows: - The link editor interface has been improved, and it is now possible to go back and edit existing links - The table viewer has been improved to make it possible to show only rows in certain subsets - The rendering of the image viewer is now improved when showing multiple datasets together - The 3D volume rendering viewers can now show together datasets that are linked but not on the same pixel grid - It is now possible to define functions to automatically identify links of interest in your datasets and have glue suggest them 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. *Installing/updating glue* As usual, we recommend installing glue using the Anaconda Python Distribution. To get the latest version of glue (v0.15), 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=0.15 If you want to use the Anaconda launcher or navigator to install glue without using the command-line, 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 replying to this email off-list), by opening a GitHub issue , or you can join the glue slack channel and chat with us there. Thanks to everyone who contributed to this release! - Thomas Robitaille, on behalf of the glue team -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Tue Jul 9 12:36:16 2019 From: demitri.muna at gmail.com (Demitri Muna) Date: Tue, 9 Jul 2019 12:36:16 -0400 Subject: [AstroPy] SciCoder Workshop, 9-13 September, Keck Observatory Message-ID: <599B300A-6DC9-48D3-BC9C-981EA4D447DD@gmail.com> Hello, I am happy to announce the 14th SciCoder Workshop, being held at and hosted by the W. M. Keck Observatory in Kamuela, Hawai?i. This workshop may be of interest to young researchers (graduate students and postdocs), and it is designed to introduce modern programming practices, languages, and tools as specifically applicable to scientific research. The workshop includes hands-on coding and data analysis. (Feel free to insert the words ?big data?, ?data science?, and/or ?astroinformatics? to taste.) A limited number of seats are available to ensure a personalized experience. This program has been very successful over the past ten years and we've received a lot of positive feedback; we look forward to seeing this year's participants! This year the workshop is being held from 9-13 September 2019. Applications are now being accepted through 29 July (with early acceptance if needed). Further details about the workshop can be found here: http://scicoder.org Please note that there are fewer seats available this year compared to previous years, so apply early if you are interested! A poster is available from the web site for download and would make a great addition on that blank bulletin board by your office. You know the one. If your institution is interested in hosting a future SciCoder workshop, please don't hesitate to contact me. I have particular demand for the workshop on the US west coast and in Europe. Cheers, Demitri _________________________________________ Demitri Muna Department of Physics & Astronomy University of Texas, San Antonio http://muna.com My Projects: http://nightlightapp.io http://trillianverse.org http://scicoder.org From npross at roe.ac.uk Mon Jul 22 20:11:57 2019 From: npross at roe.ac.uk (Nicholas Ross) Date: Tue, 23 Jul 2019 00:11:57 +0000 Subject: [AstroPy] Redshift vs. Luminosity Distance In-Reply-To: References: Message-ID: Apologies for additional email, but DLs_for_axis = np.array([0.01, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc redshift_ticks = [z_at_value(cosmo.luminosity_distance, DLs) for DLs in DLs_for_axis] seems to solve this one. Thanks, Nic > On Jul 22, 2019, at 4:54 PM, Nicholas Ross wrote: > > Hi, > > Been struggling with this one:: > > import astropy.units as u > from astropy.cosmology import FlatLambdaCDM > from astropy.cosmology import z_at_value > > cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) > luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc > z_at_value(cosmo.luminosity_distance, luminosity_distances) > > --------------------------------------------------------------------------- > ValueError Traceback (most recent call last) > in () > 5 cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) #Banados thesis > 6 luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc > ----> 7 z_at_value(cosmo.luminosity_distance, luminosity_distances) > ~/anaconda3/lib/python3.6/site-packages/astropy/cosmology/funcs.py in z_at_value(func, fval, zmin, zmax, ztol, maxfun) > 116 fval_zmin = func(zmin) > 117 fval_zmax = func(zmax) > --> 118 if np.sign(fval - fval_zmin) != np.sign(fval_zmax - fval): > 119 warnings.warn("""\ > 120 fval is not bracketed by func(zmin) and func(zmax). This means either? > > > Is this because astropy.cosmology returns the luminosity distance ? which is monotonic with > redshift in a flat/open cosmology, as > dL = dA*(1+z)^2 > where dA is the non-monotonic angular diameter distance?? > > Thanks, > Nic > > From npross at roe.ac.uk Mon Jul 22 19:54:58 2019 From: npross at roe.ac.uk (Nicholas Ross) Date: Mon, 22 Jul 2019 23:54:58 +0000 Subject: [AstroPy] Redshift vs. Luminosity Distance In-Reply-To: References: Message-ID: Hi, Been struggling with this one:: import astropy.units as u from astropy.cosmology import FlatLambdaCDM from astropy.cosmology import z_at_value cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc z_at_value(cosmo.luminosity_distance, luminosity_distances) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in () 5 cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) #Banados thesis 6 luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc ----> 7 z_at_value(cosmo.luminosity_distance, luminosity_distances) ~/anaconda3/lib/python3.6/site-packages/astropy/cosmology/funcs.py in z_at_value(func, fval, zmin, zmax, ztol, maxfun) 116 fval_zmin = func(zmin) 117 fval_zmax = func(zmax) --> 118 if np.sign(fval - fval_zmin) != np.sign(fval_zmax - fval): 119 warnings.warn("""\ 120 fval is not bracketed by func(zmin) and func(zmax). This means either? Is this because astropy.cosmology returns the luminosity distance ? which is monotonic with redshift in a flat/open cosmology, as dL = dA*(1+z)^2 where dA is the non-monotonic angular diameter distance?? Thanks, Nic From mcraig at mnstate.edu Tue Jul 23 10:31:02 2019 From: mcraig at mnstate.edu (Craig, Matthew W) Date: Tue, 23 Jul 2019 14:31:02 +0000 Subject: [AstroPy] Redshift vs. Luminosity Distance In-Reply-To: References: Message-ID: Hi Nic, Thanks for posting the solution you got ? it is useful to see both the question and answer, and awesome when users are able to provide the answer :) Matt Craig schedule: http://physics.mnstate.edu/craig ?? Professor Department of Physics and Astronomy Minnesota State University Moorhead 1104 7th Ave S, Moorhead MN 56563 office: Hagen 307F phone: (218) 477-2439 fax: (218) 477-2290 On Jul 22, 2019, at 7:11 PM, Nicholas Ross > wrote: Apologies for additional email, but DLs_for_axis = np.array([0.01, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc redshift_ticks = [z_at_value(cosmo.luminosity_distance, DLs) for DLs in DLs_for_axis] seems to solve this one. Thanks, Nic On Jul 22, 2019, at 4:54 PM, Nicholas Ross > wrote: Hi, Been struggling with this one:: import astropy.units as u from astropy.cosmology import FlatLambdaCDM from astropy.cosmology import z_at_value cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc z_at_value(cosmo.luminosity_distance, luminosity_distances) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in () 5 cosmo = FlatLambdaCDM(H0=67.7, Om0=0.307) #Banados thesis 6 luminosity_distances = np.array([0.0, 500., 1000., 2000., 3000., 5000., 6000.]) * u.Mpc ----> 7 z_at_value(cosmo.luminosity_distance, luminosity_distances) ~/anaconda3/lib/python3.6/site-packages/astropy/cosmology/funcs.py in z_at_value(func, fval, zmin, zmax, ztol, maxfun) 116 fval_zmin = func(zmin) 117 fval_zmax = func(zmax) --> 118 if np.sign(fval - fval_zmin) != np.sign(fval_zmax - fval): 119 warnings.warn("""\ 120 fval is not bracketed by func(zmin) and func(zmax). This means either? Is this because astropy.cosmology returns the luminosity distance ? which is monotonic with redshift in a flat/open cosmology, as dL = dA*(1+z)^2 where dA is the non-monotonic angular diameter distance?? Thanks, Nic _______________________________________________ AstroPy mailing list AstroPy at python.org https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fastropy&data=02%7C01%7Cmcraig%40mnstate.edu%7C2b7678df2460404e68d208d70f05a965%7C5011c7c60ab446ab9ef4fae74a921a7f%7C0%7C0%7C636994389340198526&sdata=EB4BsmXwJ2wCipIYi6whCNRCwwd0320yGtWz4pRoxkA%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From antonino.cucchiara at uvi.edu Tue Jul 23 10:45:04 2019 From: antonino.cucchiara at uvi.edu (Antonino Cucchiara) Date: Tue, 23 Jul 2019 14:45:04 +0000 Subject: [AstroPy] using wcs_reproject to coadd images Message-ID: <1FF105F4-1290-413F-8C09-0A0970BAFE9F@live.uvi.edu> Hello all, I am trying to coadd some images where the WCS was produced by astrometry.net. I am using ccdproc and wcs_reproject as shown here (https://ccdproc.readthedocs.io/en/latest/ccdproc/image_combination.html) I see in the headers that WCS keywords are there, but when I parse the images I get the following error: 'HDUList' object has no attribute 'wcs' as input and target I am passing a fits.open(?my image.fits?) object. Thanks a lot, Nino Antonino Cucchiara, PhD Assistant Professor Physics and Astronomy University of the Virgin Islands Phone: 340-693-1256 College of Science and Mathematics #2 Brewers Bay road St. Thomas, USVI 00802 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdzwig at summaventures.com Fri Jul 26 18:20:14 2019 From: pdzwig at summaventures.com (Peter Dzwig) Date: Fri, 26 Jul 2019 23:20:14 +0100 Subject: [AstroPy] Issues in DR14/DR15 headers read using astropy.io.fits Message-ID: I am looking for some general help with FITS Headers I have two (SDSS) files: (1) remote_filename = 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=0425&mjd=51898&fiberid=0440' (2)remote_filename = 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=7512&mjd=56777&fiberid=0396' I wrote some Python code using astropy which extracted the spectrum of an object from the second HDU of the appropriate .fits file. In particular I wanted to extract certain fields For example: f = fits.open(remote_filename) specdata2 = f[2].data RA = specdata2[0][59] Dec = specdata2[0][60] # Classification Class = specdata2[0][61] # Redshift and error redshift = specdata2[0][63] redshift_error = specdata2[0][64] used to work fine. In the case of (1) above, it does. In the case of (2) it just produces junk. I used the formulation for a large number of files from DR12 FWIW I am running Python 3.7 over Ubuntu 18.04. I think that is probably irrelevant as a colleague who is running in another configuration has the same sort of problem Any ideas why? It seems that there might be the following reasons: (i) there is a change in the formats (somewhere) in DR15 (ii) something has changed in the way io.fits treats some HDUs that I have missed. Is there perhaps a cleaner way of getting this info? I have posted this to the Skyserver Helpdesk without any response. Am happy to take this offline if people want. Thanks for any help, Peter -- Dr. Peter Dzwig From baweaver at lbl.gov Fri Jul 26 18:38:10 2019 From: baweaver at lbl.gov (Benjamin Alan Weaver) Date: Fri, 26 Jul 2019 15:38:10 -0700 Subject: [AstroPy] Issues in DR14/DR15 headers read using astropy.io.fits In-Reply-To: References: Message-ID: Hello Peter, The files you are using come from two separate reductions of the SDSS spectroscopic data, separated by roughly 10 years. Plate 7512 comes from the BOSS/eBOSS survey. The 3rd HDU contains data from the BOSS/eBOSS spAll file ( https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spAll.html). However, plate 0425 comes from the SDSS-I/II surveys, so the 3rd HDU contains data from the specObj file instead ( https://data.sdss.org/datamodel/files/SPECTRO_REDUX/specObj.html) . See also the full description of spec files: https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spectra/PLATE4/spec.html . This is a copy of a response from the SkyServer helpdesk that was sent on 17 July. Kia ora koe, Benjamin Alan Weaver On Fri, Jul 26, 2019 at 3:27 PM Peter Dzwig wrote: > I am looking for some general help with FITS Headers > > > > I have two (SDSS) files: > > (1) remote_filename = > ' > https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=0425&mjd=51898&fiberid=0440 > ' > > (2)remote_filename = > ' > https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=7512&mjd=56777&fiberid=0396 > ' > > I wrote some Python code using astropy which extracted the spectrum of > an object from the second HDU of the appropriate .fits file. In > particular I wanted to extract certain fields > > For example: > > f = fits.open(remote_filename) > > specdata2 = f[2].data > > RA = specdata2[0][59] > Dec = specdata2[0][60] > > # Classification > > Class = specdata2[0][61] > > # Redshift and error > > redshift = specdata2[0][63] > redshift_error = specdata2[0][64] > > used to work fine. In the case of (1) above, it does. In the case of (2) > it just produces junk. I used the formulation for a large number of > files from DR12 > > FWIW I am running Python 3.7 over Ubuntu 18.04. I think that is probably > irrelevant as a colleague who is running in another configuration has > the same sort of problem > > Any ideas why? > > It seems that there might be the following reasons: > > (i) there is a change in the formats (somewhere) in DR15 > > (ii) something has changed in the way io.fits treats some HDUs that I > have missed. > > Is there perhaps a cleaner way of getting this info? > > I have posted this to the Skyserver Helpdesk without any response. Am > happy to take this offline if people want. > > Thanks for any help, > > Peter > > > > -- > > Dr. Peter Dzwig > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- With great responsibility seldom comes great power. -------------- next part -------------- An HTML attachment was scrubbed... URL: From parejkoj at uw.edu Fri Jul 26 18:39:45 2019 From: parejkoj at uw.edu (John K. Parejko) Date: Fri, 26 Jul 2019 15:39:45 -0700 Subject: [AstroPy] Issues in DR14/DR15 headers read using astropy.io.fits In-Reply-To: References: Message-ID: <67d73607-9de1-5011-0dc7-bc35b46e8987@uw.edu> It looks like you're looking at BOSS/eBOSS data? If so, the datamodel for that data is available here: https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spectra/lite/PLATE4/spec.html The fields in HDU2 (extracted from the spAll database) are named, so you should use those names instead of column indexes, to make it clearer what you are trying to extract: https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spAll.html Which of the spAll values are you having trouble with, when you say it "produces junk"? The SAS shows a spectrum for your example 2, though it's noisy: https://dr15.sdss.org/optical/spectrum/view?id=189090&plate=7512&mjd=56777&fiberid=396 John On 26/07/2019 15:20, Peter Dzwig wrote: > I am looking for some general help with FITS Headers > > > > I have two (SDSS) files: > > (1) remote_filename = > 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=0425&mjd=51898&fiberid=0440' > > (2)remote_filename = > 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=7512&mjd=56777&fiberid=0396' > > I wrote some Python code using astropy which extracted the spectrum of > an object from the second HDU of the appropriate .fits file. In > particular I wanted to extract certain fields > > For example: > > f = fits.open(remote_filename) > > specdata2 = f[2].data > > RA = specdata2[0][59] > Dec = specdata2[0][60] > > # Classification > > Class = specdata2[0][61] > > # Redshift and error > > redshift = specdata2[0][63] > redshift_error = specdata2[0][64] > > used to work fine. In the case of (1) above, it does. In the case of (2) > it just produces junk. I used the formulation for a large number of > files from DR12 > > FWIW I am running Python 3.7 over Ubuntu 18.04. I think that is probably > irrelevant as a colleague who is running in another configuration has > the same sort of problem > > Any ideas why? > > It seems that there might be the following reasons: > > (i) there is a change in the formats (somewhere) in DR15 > > (ii) something has changed in the way io.fits treats some HDUs that I > have missed. > > Is there perhaps a cleaner way of getting this info? > > I have posted this to the Skyserver Helpdesk without any response. Am > happy to take this offline if people want. > > Thanks for any help, > > Peter > > > -- ************************* John Parejko parejkoj at uw.edu http://staff.washington.edu/parejkoj/ Department of Physics and Astronomy University of Washington Seattle, WA ************************** From pdzwig at summaventures.com Sat Jul 27 03:54:02 2019 From: pdzwig at summaventures.com (Peter Dzwig) Date: Sat, 27 Jul 2019 08:54:02 +0100 Subject: [AstroPy] Issues in DR14/DR15 headers read using astropy.io.fits Message-ID: <07c075f0-5d45-d8bb-8add-39244dc3887f@summaventures.com> John, On 26/07/2019 23:39, John K. Parejko wrote: > It looks like you're looking at BOSS/eBOSS data? If so, the datamodel > for that data is available here: actually I am looking across the QSOs in the SDSS database. .... > Which of the spAll values are you having trouble with, when you say it > "produces junk"? I was trying to create a simple way to access (in this case) redshift and redshift error, but it is the intention to look at other characteristics so this is a test case. I had assumed (clearly wrongly) that the reductions put everything in the same format (it seemed to work well in DR12) Peter > > On 26/07/2019 15:20, Peter Dzwig wrote: >> I am looking for some general help with FITS Headers >> >> >> >> I have two (SDSS) files: >> >> (1) remote_filename = >> 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=0425&mjd=51898&fiberid=0440' >> >> >> (2)remote_filename = >> 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=7512&mjd=56777&fiberid=0396' >> >> >> I wrote some Python code using astropy which extracted the spectrum of >> an object from the second HDU of the appropriate .fits file. In >> particular I wanted to extract certain fields >> >> For example: >> >> f = fits.open(remote_filename) >> >> specdata2 = f[2].data >> >> RA = specdata2[0][59] >> Dec = specdata2[0][60] >> >> # Classification >> >> Class = specdata2[0][61] >> >> # Redshift and error >> >> redshift = specdata2[0][63] >> redshift_error = specdata2[0][64] >> >> used to work fine. In the case of (1) above, it does. In the case of (2) >> it just produces junk. I used the formulation for a large number of >> files from DR12 >> >> FWIW I am running Python 3.7 over Ubuntu 18.04. I think that is probably >> irrelevant as a colleague who is running in another configuration has >> the same sort of problem >> >> Any ideas why? >> >> It seems that there might be the following reasons: >> >> (i) there is a change in the formats (somewhere) in DR15 >> >> (ii) something has changed in the way io.fits treats some HDUs that I >> have missed. >> >> Is there perhaps a cleaner way of getting this info? >> >> I have posted this to the Skyserver Helpdesk without any response. Am >> happy to take this offline if people want. >> >> Thanks for any help, >> >> Peter >> >> >> > -- Dr. Peter Dzwig -- Dr. Peter Dzwig From pdzwig at summaventures.com Sat Jul 27 03:57:02 2019 From: pdzwig at summaventures.com (Peter Dzwig) Date: Sat, 27 Jul 2019 08:57:02 +0100 Subject: [AstroPy] Issues in DR14/DR15 headers read using astropy.io.fits Message-ID: Benajamin, thanks. I will go through this. The reply from Helpdesk didn't arrive. Thanks for your time Peter On 26/07/2019 23:38, Benjamin Alan Weaver wrote: > Hello Peter, > > The files you are using come from two separate reductions of the SDSS > spectroscopic data, separated by roughly 10 years. Plate 7512 comes > from the BOSS/eBOSS survey. The 3rd HDU contains data from the > BOSS/eBOSS spAll file > (https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spAll.html). > However, plate 0425 comes from the SDSS-I/II surveys, so the 3rd HDU > contains data from the specObj file instead > (https://data.sdss.org/datamodel/files/SPECTRO_REDUX/specObj.html) . > See also the full description of spec files: > https://data.sdss.org/datamodel/files/BOSS_SPECTRO_REDUX/RUN2D/spectra/PLATE4/spec.html. > > This is a copy of a response from the SkyServer helpdesk that was sent > on 17 July. > > Kia ora koe, > Benjamin Alan Weaver > > On Fri, Jul 26, 2019 at 3:27 PM Peter Dzwig > wrote: > > I am looking for some general help with FITS Headers > > > > I have two (SDSS) files: > > (1) remote_filename = > 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=0425&mjd=51898&fiberid=0440' > > (2)remote_filename = > 'https://dr15.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=7512&mjd=56777&fiberid=0396' > > I wrote some Python code using astropy which extracted the spectrum of > an object from the second HDU of the appropriate .fits file. In > particular I wanted to extract certain fields > > For example: > > f = fits.open(remote_filename) > > specdata2 = f[2].data > > RA = specdata2[0][59] > Dec = specdata2[0][60] > > # Classification > > Class = specdata2[0][61] > > # Redshift and error > > redshift = specdata2[0][63] > redshift_error = specdata2[0][64] > > used to work fine. In the case of (1) above, it does. In the case of (2) > it just produces junk. I used the formulation for a large number of > files from DR12 > > FWIW I am running Python 3.7 over Ubuntu 18.04. I think that is probably > irrelevant as a colleague who is running in another configuration has > the same sort of problem > > Any ideas why? > > It seems that there might be the following reasons: > > (i) there is a change in the formats (somewhere) in DR15 > > (ii) something has changed in the way io.fits treats some HDUs that I > have missed. > > Is there perhaps a cleaner way of getting this info? > > I have posted this to the Skyserver Helpdesk without any response. Am > happy to take this offline if people want. > > Thanks for any help, > > Peter > > > > -- > > Dr. Peter Dzwig > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > > > > -- > With great responsibility seldom comes great power. -- Dr. Peter Dzwig -- Dr. Peter Dzwig From kawinwanichakij at gmail.com Sun Jul 28 19:22:38 2019 From: kawinwanichakij at gmail.com (Lalitawadee Kawinwanichakij) Date: Mon, 29 Jul 2019 08:22:38 +0900 Subject: [AstroPy] astropy.extern.configobj.configobj.ConfigObjError Message-ID: Dear all, I import the astropy package in Python 3. I got the error message below. I've already tried to remove Anaconda and re-install it, but the problem still remains. Could you please provide me with any suggestions? Thank you in advance, Nancy >>> import astropy Traceback (most recent call last): File "", line 1, in File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/__init__.py", line 288, in log = _init_log() File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/logger.py", line 97, in _init_log log._set_defaults() File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/logger.py", line 473, in _set_defaults self.setLevel(conf.log_level) File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/config/configuration.py", line 273, in __get__ return self() File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/config/configuration.py", line 396, in __call__ sec = get_config(self.module) File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/config/configuration.py", line 530, in get_config cobj = configobj.ConfigObj(cfgfn, interpolation=False) File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/extern/configobj/configobj.py", line 1227, in __init__ self._load(infile, configspec) File "/home/lalitawadee/anaconda3/lib/python3.7/site-packages/astropy/extern/configobj/configobj.py", line 1316, in _load raise error astropy.extern.configobj.configobj.ConfigObjError: Parsing failed with several errors. First error at line 142. -------------- next part -------------- An HTML attachment was scrubbed... URL: