From mcraig at mnstate.edu Wed Jun 2 10:13:42 2021 From: mcraig at mnstate.edu (Craig, Matthew W) Date: Wed, 2 Jun 2021 14:13:42 +0000 Subject: [AstroPy] ccdproc 2.2.0 releases Message-ID: Dear colleagues, I am delighted to announce the release of ccdproc 2.2. This release contains some modest improvements in image combination performance. For the best performance, install the [`bottleneck`](https://bottleneck.readthedocs.io/en/latest/) package. With bottleneck installed, `median_combine` is 2x faster. Changes in this version: + Image combination is faster for average and sum combine, and improves for all operations if the bottleneck package is installed. + Pixel-wise weighting can be done for sum and average combine. + When filtering an ImageFileCollection by keyword value, and not explicitly using a regex search pattern (`regex_match=True`), escape all special characters in the keyword value for a successful search. + Return mask and uncertainty from combine even if input images have no mask or uncertainty. Thanks to all of the people who contributed code, opened issues, and/or provided advice: + Timothy P. Ellsworth-Bowers (@tbowers7) and Pey Lian Lim (@pllim) wrote code for this release. + Yoonsoo Back (@ysBach) and Simon Conseil (@saimn) provided extensive input on image combination. + Issues opened by Yash Gondhalekar (@Yash-10), Michael Kelley (@mkelley), Jane Rigby (@janerigby), and Aayushi Verma (@awesomecosmos) were closed in this release. + Rieke Bohemann and Tim-Oliver Husser (@thusser) provided extensive details about issues with median combination which have been addressed in this release. Thanks, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.loveday at sussex.ac.uk Thu Jun 3 09:36:42 2021 From: j.loveday at sussex.ac.uk (Jonathan Loveday) Date: Thu, 3 Jun 2021 13:36:42 +0000 Subject: [AstroPy] Co-adding spectra Message-ID: Dear All I would like to co-add a number of spectra, which won?t all cover the same wavelength range. It seems that the spectrum.coadd_errorweighted() method (https://spectrum.readthedocs.io/en/latest/api/spectrum.coadd_errorweighted.html#spectrum.coadd_errorweighted) is ideal for this. However, I am unclear how one initiates a Spectrum with this package; the documentation is unclear on this point. I?m not sure if spectrum is still an affiliated astropy package, as it does not appear in the list on https://www.astropy.org/affiliated/, and the spectrum page above is >5 years old. The built-in help function doesn?t bear much resemblance to the spectrum web page, so I wonder if 'pip install spectrum' has installed a different package? >>> help(spectrum.Spectrum.__init__) Help on function __init__ in module spectrum.psd: __init__(self, data, data_y=None, sampling=1.0, detrend=None, scale_by_freq=True, NFFT=None) **Constructor** .. rubric:: Attributes: From the input parameters, the following attributes are set: * :attr:`data` (updates :attr:`N`, :attr:`df`, :attr:`datatype`) * :attr:`data_y` used for cross PSD only (correlogram) * :attr:`detrend` * :attr:`sampling` (updates :attr:`df`) * :attr:`scale_by_freq` * :attr:`NFFT` (reset :attr:`sides`, :attr:`df`) The following read-only attributes are set during the initialisation: * :attr:`datatype` * :attr:`df` * :attr:`N` And finally, additional read-write attributes are available: * :attr:`psd`: used to store the PSD data array, which size depends on :attr:`sides` i.e., one-sided for real data and two-sided for the complex data. * :attr:`sides`: if set, changed the :attr:`psd`. ???? I?ve tried using specutils to perform this task, but it is unclear to me how one would go about it. The only way I could think of was to use specutils to rebin the spectra to a common wavelength range, pull out all the fluxes and errors into 2d numpy arrays, and then use np.average. It seems like there should be an easier way though. Any advice gratefully received! Many thanks, Jon Jon Loveday Astronomy Centre, University of Sussex, Falmer, Brighton, BN1 9QH, UK J.Loveday at sussex.ac.uk +44 (0) 1273 877719 From pdzwig at summaventures.com Thu Jun 3 10:46:17 2021 From: pdzwig at summaventures.com (Peter Dzwig) Date: Thu, 3 Jun 2021 15:46:17 +0100 Subject: [AstroPy] Co-adding spectra In-Reply-To: References: Message-ID: <088aa160-0433-30ce-e749-c1b4f238226f@summaventures.com> Jonathan, you wrote: "I?ve tried using specutils to perform this task, but it is unclear to me how one would go about it. The only way I could think of was to use specutils to rebin the spectra to a common wavelength range, pull out all the fluxes and errors into 2d numpy arrays, and then use np.average. It seems like there should be an easier way though. " I had the same issue last year and I took the data from the (in my case) SDSS .fits files and basically added them to create a weighted compound spectrum (each spectrum was normalised over a given range before addition). What you suggest was pretty much what I did. You have to be very careful about the (wavelength, flux) pairs particularly if you are combining spectra from different redshifts. If you are going to use np.average care is needed that the averaging actually handles the physical situation, e.g. do all the spectra have the same weight and if not how do you weight it. With 200 - 1000 spectra at a time it wasn't that easy but it runs happily enough on a PC in a few minutes. As the "parent" of what turned out to be quite a bit of code, I would hate to see it wasted, but I sure wish that there was an Astropy alternative. In the end I couldn't find one to fit my scenario. However all the bits are there, it's just a question of gluing them together. I would be more than happy to discuss details off-group if you like. Regards, Peter On 03/06/2021 14:36, Jonathan Loveday wrote: > I?ve tried using specutils to perform this task, but it is unclear to me how one would go about it. The only way I could think of was to use specutils to rebin the spectra to a common wavelength range, pull out all the fluxes and errors into 2d numpy arrays, and then use np.average. It seems like there should be an easier way though. -- Dr. Peter Dzwig From dtucker at fnal.gov Thu Jun 3 14:08:30 2021 From: dtucker at fnal.gov (Douglas L Tucker) Date: Thu, 3 Jun 2021 18:08:30 +0000 Subject: [AstroPy] Co-adding spectra In-Reply-To: <088aa160-0433-30ce-e749-c1b4f238226f@summaventures.com> References: , <088aa160-0433-30ce-e749-c1b4f238226f@summaventures.com> Message-ID: I am afraid I haven?t migrated much just yet over to AstroPy and specutils for spectra, even though there are definitely some very nice tools there. Usually, I do something like this, making use of the scipy interpd1d function to place spectra onto the same wavelength array: import pandas as pd import numpy as np from scipy import interpolate df_obs = pd.read_csv(inputFile_obs) lambda_lo = df_obs.LAMBDA.min() lambda_hi = df_obs.LAMBDA.max() wavelength_array = np.arange(lambda_lo, lambda_hi, 10.) spec_flux_obs = interpolate.interp1d(df_obs.LAMBDA, df_obs.FLUX,bounds_error=False, fill_value=0.,kind='linear') spec_flux_obs_array = spec_flux_obs(wavelength_array) Best regards, Douglas From: AstroPy Date: Thursday, June 3, 2021 at 9:51 AM To: Astronomical Python mailing list , Jonathan Loveday Subject: Re: [AstroPy] Co-adding spectra Jonathan, you wrote: "I?ve tried using specutils to perform this task, but it is unclear to me how one would go about it. The only way I could think of was to use specutils to rebin the spectra to a common wavelength range, pull out all the fluxes and errors into 2d numpy arrays, and then use np.average. It seems like there should be an easier way though. " I had the same issue last year and I took the data from the (in my case) SDSS .fits files and basically added them to create a weighted compound spectrum (each spectrum was normalised over a given range before addition). What you suggest was pretty much what I did. You have to be very careful about the (wavelength, flux) pairs particularly if you are combining spectra from different redshifts. If you are going to use np.average care is needed that the averaging actually handles the physical situation, e.g. do all the spectra have the same weight and if not how do you weight it. With 200 - 1000 spectra at a time it wasn't that easy but it runs happily enough on a PC in a few minutes. As the "parent" of what turned out to be quite a bit of code, I would hate to see it wasted, but I sure wish that there was an Astropy alternative. In the end I couldn't find one to fit my scenario. However all the bits are there, it's just a question of gluing them together. I would be more than happy to discuss details off-group if you like. Regards, Peter On 03/06/2021 14:36, Jonathan Loveday wrote: > I?ve tried using specutils to perform this task, but it is unclear to me how one would go about it. The only way I could think of was to use specutils to rebin the spectra to a common wavelength range, pull out all the fluxes and errors into 2d numpy arrays, and then use np.average. It seems like there should be an easier way though. -- Dr. Peter Dzwig _______________________________________________ AstroPy mailing list AstroPy at python.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.python.org_mailman_listinfo_astropy&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=R-57Mm7OJX1IswbY4ezVTQ&m=tQUx-GZ_Ew_MICrRh8Pp85EM7tW-Yfw6iWvHI06mnlM&s=vthMzCmFaqGybYKXgaQl27x2OpFxCsnqHkWe39QhcSA&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmyboysingh at gmail.com Wed Jun 9 08:54:04 2021 From: jimmyboysingh at gmail.com (Jim Singh) Date: Wed, 9 Jun 2021 22:54:04 +1000 Subject: [AstroPy] Aggregate Magnitude of Multiple Star System? Message-ID: Hi, When I use astropy to retrieve fluxdata(V) from SIMBAD for 'Acrux', it returns values for the components alpha1 and alpha2 Crucis as follows: alf01 Cru: 1.28 alf02 Cru: 1.58 Now, using mathplotlib I am directly translating the fluxdata(V) value to a 'star size' for depicting the relative apparent magnitude of the stars. In the above case if I 'zoom in' enough such that the angular separation is sufficient to render two distinct disks, then I can size them according to the two values. But if I zoom out such that the disks are superimposed on each other and basically show as one, then I need to somehow translate the contribution from both components: 1.28 and 1.58, to 0.77 for the disk to be the correct size relative to other stars in the plot. Is there an astropy function that can do this, or alternatively an expression? I found this expression for example: https://www.astro.keele.ac.uk/jkt/pubs/JKTeq-fluxsum.pdf which plugging in m1=1.28 and m2=1.58 yields mTot=0.67, not too far from the Acrux apparent magnitude of 0.77 Regards, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From eduardo.ojero at sciops.esa.int Mon Jun 21 12:32:19 2021 From: eduardo.ojero at sciops.esa.int (Eduardo Ojero Pascual) Date: Mon, 21 Jun 2021 18:32:19 +0200 Subject: [AstroPy] Level ODF downloads using the astroquery.XMMNewton module do not progress when run from a docker container. Message-ID: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> Dear all, We are using the astroquery XMMNewton module to download ODF level data from a docker container running the latest Ubuntu 20.04 image. When invoking from within ipython the XMMNewton.download_data for any given ODF, as ??? In [x]: XMMNewton.download_data(odfid='nnnnnnnnnn', level='ODF', verbose=True) ??? INFO: http://nxsa.esac.esa.int/nxsa-sl/servlet/data-action-aio?obsno=nnnnnnnnnn&level=ODF [astroquery.esa.xmm_newton.core] the connection is effectively established but it does not progress. After a while, the connection is dropped but ipython does not return to its prompt. The same request used in a standard Ubuntu terminal, progresses apropriately and downloads the requested observation file. Is anyone having any idea on what is going on here? Best regards, Eduardo This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int). From adam.g.ginsburg at gmail.com Mon Jun 21 12:54:06 2021 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Mon, 21 Jun 2021 12:54:06 -0400 Subject: [AstroPy] Level ODF downloads using the astroquery.XMMNewton module do not progress when run from a docker container. In-Reply-To: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> References: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> Message-ID: Hi Eduardo, This appears related to https://github.com/astropy/astroquery/issues/2075 It may be a memory issue - how much memory does your docker instance have available, compared to the size of the downloaded file(s)? I have suggested a possible fix here: https://github.com/astropy/astroquery/pull/2087 that you could try out. I recommend we continue this conversation on the github issue tracker, though. On Mon, Jun 21, 2021 at 12:32 PM Eduardo Ojero Pascual < eduardo.ojero at sciops.esa.int> wrote: > Dear all, > > We are using the astroquery XMMNewton module to download ODF level data > from a docker container running the latest Ubuntu 20.04 image. > > When invoking from within ipython the XMMNewton.download_data for any > given ODF, as > > In [x]: XMMNewton.download_data(odfid='nnnnnnnnnn', level='ODF', > verbose=True) > > INFO: > > http://nxsa.esac.esa.int/nxsa-sl/servlet/data-action-aio?obsno=nnnnnnnnnn&level=ODF > [astroquery.esa.xmm_newton.core] > > the connection is effectively established but it does not progress. > After a while, the connection is dropped but ipython does not return to > its prompt. > > The same request used in a standard Ubuntu terminal, progresses > apropriately and downloads the requested observation file. > > Is anyone having any idea on what is going on here? > > Best regards, > > Eduardo > > > This message is intended only for the recipient(s) named above. It may > contain proprietary information and/or > protected content. Any unauthorised disclosure, use, retention or > dissemination is prohibited. If you have received > this e-mail in error, please notify the sender immediately. ESA applies > appropriate organisational measures to protect > personal data, in case of data privacy queries, please contact the ESA > Data Protection Officer (dpo at esa.int). > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adam Ginsburg Assistant Professor, Department of Astronomy University of Florida, Gainesville http://www.adamgginsburg.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdzwig at summaventures.com Mon Jun 21 15:32:00 2021 From: pdzwig at summaventures.com (Peter Dzwig) Date: Mon, 21 Jun 2021 20:32:00 +0100 Subject: [AstroPy] Level ODF downloads using the astroquery.XMMNewton module do not progress when run from a docker container. In-Reply-To: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> References: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> Message-ID: <886e4d09-fa32-e709-233f-1a83ff5e20a4@summaventures.com> Eduardo, another possibility is Jupyter notebook/ipython itself. I too had an issue after going to 20.04 LTS. In my case it turned out to be a timeout issue caused by an internal default message rate that was too low, principally with large (in my case SDSS) datasets and/or records. I now invoke jupyter notebook using: $ jupyter notebook --NotebookApp.iopub.msg_rate_limit = 100000 which resolved the issue for me. And, yes, I didn't get the issue in a terminal either. Hope that this helps. Regards, Peter PS I think the issue is highlighted somewhere on Ubuntu's own message boards, or possibly on stackexchange somewhere. If it was here I apologise to the community wholeheartedly ;-) On 21/06/2021 17:32, Eduardo Ojero Pascual wrote: > Dear all, > > We are using the astroquery XMMNewton module to download ODF level data > from a docker container running the latest Ubuntu 20.04 image. > > When invoking from within ipython the XMMNewton.download_data for any > given ODF, as > > ??? In [x]: XMMNewton.download_data(odfid='nnnnnnnnnn', level='ODF', > verbose=True) > > ??? INFO: > http://nxsa.esac.esa.int/nxsa-sl/servlet/data-action-aio?obsno=nnnnnnnnnn&level=ODF > [astroquery.esa.xmm_newton.core] > > the connection is effectively established but it does not progress. > After a while, the connection is dropped but ipython does not return to > its prompt. > > The same request used in a standard Ubuntu terminal, progresses > apropriately and downloads the requested observation file. > > Is anyone having any idea on what is going on here? > > Best regards, > > Eduardo > > > This message is intended only for the recipient(s) named above. It may > contain proprietary information and/or > protected content. Any unauthorised disclosure, use, retention or > dissemination is prohibited. If you have received > this e-mail in error, please notify the sender immediately. ESA applies > appropriate organisational measures to protect > personal data, in case of data privacy queries, please contact the ESA > Data Protection Officer (dpo at esa.int). > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy -- Dr. Peter Dzwig From eduardo.ojero at sciops.esa.int Tue Jun 22 05:43:41 2021 From: eduardo.ojero at sciops.esa.int (Eduardo Ojero Pascual) Date: Tue, 22 Jun 2021 11:43:41 +0200 Subject: [AstroPy] Level ODF downloads using the astroquery.XMMNewton module do not progress when run from a docker container. In-Reply-To: <886e4d09-fa32-e709-233f-1a83ff5e20a4@summaventures.com> References: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> <886e4d09-fa32-e709-233f-1a83ff5e20a4@summaventures.com> Message-ID: <3281_1624355022_60D1B0CE_3281_2591_1_9bf41022-7c44-1efd-6b60-545b333f9aa9@sciops.esa.int> Dear Peter, Thanks for your reply! Indeed, it could be what you suggest, some type of obscure time-out, applicable to ipython and/or Jup. Notebook. In our case we have used ipython for the tests. The XMM-Newton observation data files (ODFs) that I am attempting to download are small (~70 MB) compared to other data missions, e.g. SDSS or Gaia, etc. Thus, these files should not be so sensible to these time-outs as larger files. Besides, I have already tested it using the requests from ipython, using directly the URL and getting the response into a binary file. It worked fine. It seems that astroquery gets stuck where requests succeeds. Why? Anyhow, I am going to try your suggestion and will let you know. Thanks again! Regards, Eduardo On 21/06/2021 21:32, Peter Dzwig wrote: > Eduardo, > > another possibility is Jupyter notebook/ipython itself. > > I too had an issue after going to 20.04 LTS. > > In my case it turned out to be a timeout issue caused by an internal > default message rate that was too low, principally with large (in my > case SDSS) datasets and/or records. > > I now invoke jupyter notebook using: > > $ jupyter notebook --NotebookApp.iopub.msg_rate_limit = 100000 > > which resolved the issue for me. > > And, yes, I didn't get the issue in a terminal either. > > Hope that this helps. > > Regards, > > Peter > > PS I think the issue is highlighted somewhere on Ubuntu's own message > boards, or possibly on stackexchange somewhere. If it was here I > apologise to the community wholeheartedly ;-) > > On 21/06/2021 17:32, Eduardo Ojero Pascual wrote: >> Dear all, >> >> We are using the astroquery XMMNewton module to download ODF level data >> from a docker container running the latest Ubuntu 20.04 image. >> >> When invoking from within ipython the XMMNewton.download_data for any >> given ODF, as >> >> ??? In [x]: XMMNewton.download_data(odfid='nnnnnnnnnn', level='ODF', >> verbose=True) >> >> ??? INFO: >> http://nxsa.esac.esa.int/nxsa-sl/servlet/data-action-aio?obsno=nnnnnnnnnn&level=ODF >> [astroquery.esa.xmm_newton.core] >> >> the connection is effectively established but it does not progress. >> After a while, the connection is dropped but ipython does not return to >> its prompt. >> >> The same request used in a standard Ubuntu terminal, progresses >> apropriately and downloads the requested observation file. >> >> Is anyone having any idea on what is going on here? >> >> Best regards, >> >> Eduardo >> >> >> This message is intended only for the recipient(s) named above. It may >> contain proprietary information and/or >> protected content. Any unauthorised disclosure, use, retention or >> dissemination is prohibited. If you have received >> this e-mail in error, please notify the sender immediately. ESA applies >> appropriate organisational measures to protect >> personal data, in case of data privacy queries, please contact the ESA >> Data Protection Officer (dpo at esa.int). >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int). From pdzwig at summaventures.com Tue Jun 22 12:36:10 2021 From: pdzwig at summaventures.com (Peter Dzwig) Date: Tue, 22 Jun 2021 17:36:10 +0100 Subject: [AstroPy] Level ODF downloads using the astroquery.XMMNewton module do not progress when run from a docker container. In-Reply-To: <3281_1624355022_60D1B0CE_3281_2591_1_9bf41022-7c44-1efd-6b60-545b333f9aa9@sciops.esa.int> References: <13568_1624293140_60D0BF14_13568_760_1_1451677f-3b0a-3ef2-e9c7-a5d9150c97ae@sciops.esa.int> <886e4d09-fa32-e709-233f-1a83ff5e20a4@summaventures.com> <3281_1624355022_60D1B0CE_3281_2591_1_9bf41022-7c44-1efd-6b60-545b333f9aa9@sciops.esa.int> Message-ID: Try the obvious things as well if you haven't done so already. (I am sure that you will have) Run sudo apt-get update sudo apt-get upgrade or whatever you use for updating. Check that you have the newest version (or at least a recent version) of astropy. Peter On 22/06/2021 10:43, Eduardo Ojero Pascual wrote: > Dear Peter, > > Thanks for your reply! > > Indeed, it could be what you suggest, some type of obscure time-out, > applicable to ipython and/or Jup. Notebook. In our case we have used > ipython for the tests. > > The XMM-Newton observation data files (ODFs) that I am attempting to > download are small (~70 MB) compared to other data missions, e.g. SDSS > or Gaia, etc. Thus, these files should not be so sensible to these > time-outs as larger files. > > Besides, I have already tested it using the requests from ipython, using > directly the URL and getting the response into a binary file. It worked > fine. > > It seems that astroquery gets stuck where requests succeeds. Why? > > Anyhow, I am going to try your suggestion and will let you know. > > Thanks again! > > Regards, > > Eduardo > > On 21/06/2021 21:32, Peter Dzwig wrote: >> Eduardo, >> >> another possibility is Jupyter notebook/ipython itself. >> >> I too had an issue after going to 20.04 LTS. >> >> In my case it turned out to be a timeout issue caused by an internal >> default message rate that was too low, principally with large (in my >> case SDSS) datasets and/or records. >> >> I now invoke jupyter notebook using: >> >> $ jupyter notebook --NotebookApp.iopub.msg_rate_limit = 100000 >> >> which resolved the issue for me. >> >> And, yes, I didn't get the issue in a terminal either. >> >> Hope that this helps. >> >> Regards, >> >> Peter >> >> PS I think the issue is highlighted somewhere on Ubuntu's own message >> boards, or possibly on stackexchange somewhere. If it was here I >> apologise to the community wholeheartedly ;-) >> >> On 21/06/2021 17:32, Eduardo Ojero Pascual wrote: >>> Dear all, >>> >>> We are using the astroquery XMMNewton module to download ODF level data >>> from a docker container running the latest Ubuntu 20.04 image. >>> >>> When invoking from within ipython the XMMNewton.download_data for any >>> given ODF, as >>> >>> ???? In [x]: XMMNewton.download_data(odfid='nnnnnnnnnn', level='ODF', >>> verbose=True) >>> >>> ???? INFO: >>> http://nxsa.esac.esa.int/nxsa-sl/servlet/data-action-aio?obsno=nnnnnnnnnn&level=ODF >>> >>> [astroquery.esa.xmm_newton.core] >>> >>> the connection is effectively established but it does not progress. >>> After a while, the connection is dropped but ipython does not return to >>> its prompt. >>> >>> The same request used in a standard Ubuntu terminal, progresses >>> apropriately and downloads the requested observation file. >>> >>> Is anyone having any idea on what is going on here? >>> >>> Best regards, >>> >>> Eduardo >>> >>> >>> This message is intended only for the recipient(s) named above. It may >>> contain proprietary information and/or >>> protected content. Any unauthorised disclosure, use, retention or >>> dissemination is prohibited. If you have received >>> this e-mail in error, please notify the sender immediately. ESA applies >>> appropriate organisational measures to protect >>> personal data, in case of data privacy queries, please contact the ESA >>> Data Protection Officer (dpo at esa.int). >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at python.org >>> https://mail.python.org/mailman/listinfo/astropy > > This message is intended only for the recipient(s) named above. It may > contain proprietary information and/or > protected content. Any unauthorised disclosure, use, retention or > dissemination is prohibited. If you have received > this e-mail in error, please notify the sender immediately. ESA applies > appropriate organisational measures to protect > personal data, in case of data privacy queries, please contact the ESA > Data Protection Officer (dpo at esa.int). > > -- Dr. Peter Dzwig