Mailman 3 অক্টোবর 2017 - AstroPy

Aplpy FITSFigure does not open any window
by Vittorio_Roma2 23 মার্চ, 2019

23 মার্চ, 2019

Dear all I am having a problem with aplpy. I am using Python 3.5.2 under ubuntu 16.04 and installed aplpy version 1.1.1 through pip3 install aplpy The first problem arises when importing aplpy: import/home/vittorio/.local/lib/python3.5/site-packages/matplotlib/cbook/deprecation.py:106: MatplotlibDeprecationWarning: The mpl_toolkits.axes_grid module was deprecated in version 2.1. Use mpl_toolkits.axes_grid1 and mpl_toolkits.axisartist provies the same functionality instead. warnings.warn(message, mplDeprecation, stacklevel=1) I have tried to substitute mpl_toolkits.axes_grid1 with mpl_toolkits.axes_grid in core.py but then I got an error (and not a warning) saying that axes_grid1 does not have some method. This will just return a failure and stop everything. Anyways, when I do >>> fitsfile='somefile.fits' >>> F=aplpy.FITSFigure(fitsfile) WARNING: Cannot determine equinox. Assuming J2000. [aplpy.wcs_util] WARNING: Cannot determine equinox. Assuming J2000. [aplpy.wcs_util] >>> F.show_grayscale() INFO: Auto-setting vmin to 3.416e+03 [aplpy.core] INFO: Auto-setting vmax to 2.212e+04 [aplpy.core] No window at all is opening. I have also tried giving as input of FITSFIgure astropy.io.fits.open objects but again, no graphical window shows up. I have found some workaround, that is, after the above instructions, to give >>>hdu_list=fits.open(fitsfile) >>>image_data=hdu_list[0].data >>>plt.imshow(image_data,'gray',clim=[4500,9000]) >>>plt.show(block=False) This does open an astrometrized image, with the labels of the X and Y axis in the right place. However, this does not allow me to use any of the FITSFigure methods. Neither I can add subplots to put annotations. Finally, to add markers, I am forced to do another workaround: to give pixel coordinates like this >>>plt.scatter(pixcoords[:,0],pixcoords[:,1]) where pixcoords comes from WCS transformations. I have also tried a workaround, giving,e.g. >>>F.add_label(0.5,0.5,'ssss',relative=True) and do the plt.imshow and plt.show later, but this still does not work. To sum up, while it is true that I can live with the workarounds for some very basic figures, all of this is slowing down the script and I can't call any of the FITSFigure methods Any help would really be appreciated Best regards, Vittorio

2 1

Revert to astropy 1.3 constants (for testing) in astropy 2.0
by Duncan Macleod 28 জানুয়ারি, 2018

28 জানুয়ারি, 2018

Hi all, Is there a way to tell astropy.constants to use the version 1.3 constants (from astropy.constants.astropyconst13) when using the v2.0 package? i.e. have astropy.constants.M_sun come from iau2012 and not iau2015? I have a bunch of unit tests are now failing because of the relatively large changes in some constants.* Thanks Duncan *I understand I could 'just update the tests', but in principle that would be nice to avoid, I have my reasons. -- Duncan Macleod duncan.macleod(a)ligo.org Sêr Cymru Cofund Fellow School of Physics and Astronomy Cardiff University

3 3

(Table) unit formatting
by Peter Weilbacher 1 নভেম্বর, 2017

1 নভেম্বর, 2017

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

4 5

importing astropy without reading the config file
by Stephen Bailey 31 অক্টোবর, 2017

31 অক্টোবর, 2017

We're using astropy in a massively parallel mpi4py program where 4800 ranks wake up simultaneously and try to import astropy. The code itself is installed to a filesystem optimized for the millions (literally!) of tiny file accesses that this causes. But we're having trouble with all 4800 ranks trying to read the astropy config file under our home directory, which is not optimized for such a load. This intermittently produces the traceback below when one of them gets a corrupted read. Although one could blame the filesystem for not being able to handle an arbitrarily large load, is there any way to mitigate this, e.g. * some environment variable to tell astropy not to load the config file upon import, plus some way of setting the config by hand * some environment variable to tell astropy to load it from a different location than $HOME * other ideas? For those less familiar with MPI, this is a "feature" of MPI that all ranks need to independently load the modules that they need, and they all start nearly simultaneously. Unlike other parallel programming paradigms, it isn't an option with MPI itself to have one process wake up and import stuff, and then fork other processes that inherit the same environment. (For those who are MPI experts, I'm aware of MPI_Comm_spawn, but that isn't widely implemented/deployed yet.) Our full scale option is to use docker with astropy installed into the image, but even there we have to create a fake $HOME in the docker image so that astropy will get its config files from there instead of reaching out of the container to get them from the real $HOME directory. It works, but yuck, because it means that nothing else in the program can access $HOME because we've hidden that from the container just to keep astropy imports from abusing it. Thanks for the help, Stephen File "/global/common/software/desi/users/jguy/desispec/py/desispec/io/brick.py", line 21, in <module> import astropy.io.fits File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/__init__.py", line 287, in <module> log = _init_log() File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/logger.py", line 100, in _init_log log._set_defaults() File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/logger.py", line 493, in _set_defaults self.setLevel(conf.log_level) File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/config/configuration.py", line 278, in __get__ return self() File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/config/configuration.py", line 401, in __call__ sec = get_config(self.module) File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/config/configuration.py", line 535, in get_config cobj = configobj.ConfigObj(cfgfn, interpolation=False) File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/extern/configobj/configobj.py", line 1231, in __init__ self._load(infile, configspec) File "/global/common/software/desi/edison/desiconda/20170920-1.2. 0-spec/conda/lib/python3.6/site-packages/astropy/extern/configobj/configobj.py", line 1320, in _load raise error astropy.extern.configobj.configobj.ParseError: Invalid line ('\x00\x00

3 6

verify behavior
by Joe Harrington 31 অক্টোবর, 2017

31 অক্টোবর, 2017

I have some non-compliant FITS images from an old instrument that I use in my class (why? because the data are perfect for an example of median combination, and the strange format and non-compliance help me teach writing wrapper functions). I had thought that doing hdulist.verify('silentfix') would silently fix the broken cards. However, it doesn't. It only seems to set the option for how to do it later, should the need arise. For example, the cards get fixed if printed. Otherwise, when trying to write the file, it errors out. It's not a solution to write with 'silentfix', because I want to fix the data on read so the user doesn't know it was ever bad. So, my goal is to hide the weirdness of this instrument's data inside a wrapper script, which means I need to print the header for each image as it's read, which is not desired. So, my hack is to open /dev/null (portably) and print it to that. Is this the best option, or is it a bug and hdulist.verify() should actually DO the fix, or is there something else I can run to make it do the fix on or right after the read that is cleaner? The example script is below, set up to comment in and out various lines to try stuff. An example FITS(ish) file is here: https://physics.ucf.edu/~jh/dark_13s_5.fits --jh-- #! /usr/bin/env python3 # Astropy verify bug test case. # Joseph Harrington <jh(a)physics.ucf.edu> 31 October 2017 # Note that floats header entries have lowercase 'e' in file, but they # have uppercase 'E' in astropy FITS header object. It gets fixed # automatically. However, it isn't really fixed. # Note: CDELT1, CDELT2, RA_OFFS, DEC_OFFS, RA_RATE, DEC_RATE. # Comment in and out the lines below. # BAD cases: # Simple read and write: prints errors, nothing written. # read, silentfix, write: prints errors, nothing written. # read, fix, write: prints warnings, prints errors, nothing written. # NOT GREAT cases (can't hide fixes in reader function): # read, print, write: prints warnings, writes good data. # read and write with 'silentfix': writes good data # GOOD cases: # use hdulist.verify('silentfix') to set the kind of fixing option # print the header to /dev/null or equivalent to fix the header # write import numpy as np import astropy.io.fits as fits import os infile = 'dark_13s_5.fits' outfile = 'writefix.fits' hdulist = fits.open(infile) hdulist.verify('silentfix') header = hdulist[0].header data = hdulist[0].data #print("Printing header to /dev/null or OS equivalent") with open(os.devnull, 'w') as null: print(header, file=null) print("Writing file "+outfile) fits.writeto(outfile, data, header, overwrite=True) # This is NOT a solution, as user shouldn't know about problem. #fits.writeto(outfile, data, header, overwrite=True, output_verify='silentfix')

1 0

Re: [AstroPy] BSCALE/BZERO
by Diego Farias 28 অক্টোবর, 2017

28 অক্টোবর, 2017

Hi Matt and everyone: I did the same 'experiments'! and I realized that I 'loose' information if I scale to 'uint16' . That's why I don't understand the problem because I have been told that the *PIXEL VALUES *should remain the same it's just that the dynamic range with the BITPIX=16,BZERO=32767 should be from 0 to 65535. As I'm not clever enough I'm stuck in this step.. I'm guessing that later we need to use another astronomical tool that requires the images with BITPIX = 16. In my despair, I found this: https://github.com/varenius/salsa/blob/master/Control_program/spectrum.py where the important step is #Since using int16 as datatype we use bscale and bzero to keep dynamic range. #SalsaJ cannot read bitpix correctly except 16 bit. If SalsaJ could read bitpix #we could just have BITPIX -64 and skip Bscale, Bzero, i.e. just remove #astype above. datamin = np.min(self.data) datamax = np.max(self.data) bscale = (datamax-datamin)/65534.0 #shouldn't be 65535.0? bzero = datamin+bscale*32767.0 scaledata = (self.data - bzero)/bscale hdu.data = scaledata.reshape(1, 1, self.nchans).*astype(np.int16)* Shouldn't this *also changes *the values? (in this case, spectrum values). Also, bscale ~ 1., bzero ~ 326767. Thanks a lot, Diego

2 1

BSCALE/BZERO
by Diego Farias 28 অক্টোবর, 2017

28 অক্টোবর, 2017

Hi everyone, I have posted this message wrongly in the 'issue' of astropy github, but it is better doing it by the mailing list. I've been struggling with a problem that I quite don't understand and a possible solution by scale function of astropy.io (that's why I'm asking advice). I have images with BITPIX -32,(max pixel values ~ 70000, min ~0) and I was instructed to 'change' them to - *BITPIX=16, BSCALE=1, and BZERO=32767 (or whatever value is needed to make the dynamic range from 0 to 65535)* That's why I thought I could use scale('uint16') in order to do this. But I'm pretty lost on whether I'm doing it good or wrong with this method. It was told me that a pixel value of e.g. 66030.2 in -32 image will be int(66030.2 - 65535) because an integer image (BITPIX=16) can only have 65536 distinct values. I get that, but what I don't understand is this: *BITPIX etc does not change the value, it only changes how that value is saved* What do you think about this problem? Thanks, Diego

2 1

astropy.io.fits won't allow me to modify the NAXIS keywords
by Sébastien Bardeau 23 অক্টোবর, 2017

23 অক্টোবর, 2017

Dear astropy community, I am facing a FITS image which contains the following keywords in its primary header: NAXIS = 4 / NAXIS1 = 256 / NAXIS2 = 256 / NAXIS3 = 1 / NAXIS4 = 1 / As you can see it provides a 2D image, but there are 2 trailing degenerate dimensions. Tools like ds9 have no problem understanding this is a 2D image, but another user reports that matplotlib returns an error. As an intermediate solution, I wanted to patch the header by setting NAXIS to 2 and removing NAXIS3 and NAXIS4. You will find the script below. Unfortunately, none of the modifications I will do on the NAXIS* keywords will be saved in the result file, even if I keep these keywords perfectly consistent with the actual binary image. On the other hand, modifying, deleting, or adding other keywords works correctly. I remember having the same problem with pyfits in the past. I can also add that I can perfectly imaging doing the opposite transformation, i.e. adding extra degenerate dimensions to transform an image into a cube or more. Is this a bug or a feature? I believe this is a kind of protection against inconsistent modifications of the header, but can't we imagine to relax a bit this protection, by e.g. checking "only" that the total number of elements are preserved? I can provide a test file if needed. Thanks, Sebastien #!/bin/env python import astropy.io.fits import sys a = astropy.io.fits.open(sys.argv[1],mode='update') print "Before: ",a[0].header['NAXIS'] a[0].header['NAXIS'] = 2 # Won't be saved print "After: ",a[0].header['NAXIS'] del a[0].header['NAXIS3'] # Won't be deleted del a[0].header['NAXIS4'] # Won't be deleted a[0].header['OBJECT'] = 'ANOTHERONE' # Will be changed del a[0].header['ORIGIN'] # Will be deleted a[0].header['MYKEYWOR'] = 'Some string' # Will be added a.close() # Save changes del a # Check a = astropy.io.fits.open(sys.argv[1],mode='readonly') print "Current:",a[0].header['NAXIS'] # Shows unmodified value a.close() del a -- Sebastien BARDEAU IRAM 300 rue de la Piscine F - 38406 Saint Martin d'Heres Tel: (+33) 4 76 82 49 86 www.iram.fr/IRAMFR/GILDAS/

6 8

Fitting in 3 dimensions
by Daniel Evans 18 অক্টোবর, 2017

18 অক্টোবর, 2017

Dear all, I have a cube of images derived from an integral field spectrograph, with axes (x, y, wavelen), with a size of something like (32, 32, 39). In these images is a star which I would like to use astropy.modelling to fit an AiryDisk2D to, doing so simultaneously in my N wavelength slices. I'd like to do it simultaneously in order to better constrain the PSF position and size using data from all wavelength slices simultaneously - I don't have any obvious "correct" answer to fix the inputs to. I envision doing this by fitting N Airy disk models, with x_0 and y_0 fixed between them, the radius dependent on the wavelength in slice N, and the amplitude being free to vary. A semi-psudocode version is of what I imagine the custom model's evaluate() function to be is: #### def evaluate(x, y, wavelength, x_cen, y_cen, radius_0, amplitude_0...): z = numpy.empty_like(x) global wavelengthValues for N in range(len(wavelengthValues)): radius = radius_0 * wavelengthValues[N] / wavelengthValues[0] amplitude = amplitude_N wavelengthMask = wavelength == N z[wavelengthMask] = models.AiryDisk2D.evaluate( x[wavelengthMask], y[wavelengthMask], amplitude, x_cen, y_cen, radius) return z #### 1. This requires fitting in 3D, which I can't see any simple way to do in astropy - everything seems to support x,y as input and z as output. Have I missed something, or would I have to really go back to basics? 2. My suggested model is also relatively clunky due to having to define N amplitude parameters. I glossed over this in the code above, but in reality the only way I've thought of to do it is to define N input parameters, make a list from those N input parameters, and then select the correct one from the list. That's a lot of typing! Is there a more elegant way to do this? 3. Alternatively, can I attack this problem in 2D? Could I easily tile my N wavelength slices together into a single image, and then called a series of AiryDisk2D() models that generate data only for the relevant (x, y) of each tile? Regards, Daniel

1 0

ANN: pyregion 2.0 released
by Christoph Deil 18 অক্টোবর, 2017

18 অক্টোবর, 2017

Hi everyone, We are happy to announce the release of pyregion version 2.0. pyregion is a Python package to work with DS9 region files. * Docs: http://pyregion.readthedocs.io * Code: https://github.com/astropy/pyregion * PyPI: https://pypi.python.org/pypi/pyregion Detailed information about changes in this release is here: http://pyregion.readthedocs.io/en/latest/changelog.html#oct-14-2017 To try it out, you can easily install it with pip: pip install pyregion --upgrade Or with conda: conda install -c conda-forge pyregion Please do report any issues you find with pyregion at: https://github.com/astropy/pyregion/issues Cheers, Jae-Joon Lee, Joseph Booker, Adam Ginsburg, Brigitta Sipocz, Tom Robitaille and Christoph Deil

2 1