From evert.rol at gmail.com Tue Nov 3 20:34:22 2015 From: evert.rol at gmail.com (Evert Rol) Date: Wed, 4 Nov 2015 12:34:22 +1100 Subject: [AstroPy] search_around_sky In-Reply-To: <8CA53308-1B62-4E95-B3D0-74024042B944@brera.inaf.it> References: <8CA53308-1B62-4E95-B3D0-74024042B944@brera.inaf.it> Message-ID: Stefano, if I understand you correctly, you have: index2, index1, d2d, d3d = coord1.search_around_sky(coord2, maxsep) and you want to find "~index2" and "~index1" (which, of course, don't exist like that). I actually assume you want to find the *coordinates* of the non-matched sources, not the indices. But both can be done. There's no simple one-liner that I know of, but creating a boolean mask is simple and useful to have around anyway (since a boolean mask can be simply inverted, unlike a array of indices). ind1 = np.unique(index1) mask = np.ones(len(coord1), dtype=np.bool) mask[ind1] = False nonmatched_coord1 = coord1[mask] nonmatched_ind1 = np.arange(len(coord1))[mask] and similar for coord2. I'm using np.unique to filter multiple matched objects. It's not really necessary here, but more as an ease of mind. (Otherwise you'd just be setting some values in the mask to False twice.) The last line is to get the indices, and essentially coord1[nonmatched_ind1] == nonmatched_coord1 . Evert > Hello everybody, > > I am using "search_around_sky" to match two list of sources, and it works fine. > > Is there, however, a simple way to have the indices in the two input coordinate lists of the non-matched objects? > > Thanks, and my apologies if the issue has already been discussed in the past. > > Stefano > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From stefano.covino at brera.inaf.it Wed Nov 4 05:37:26 2015 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Wed, 4 Nov 2015 11:37:26 +0100 Subject: [AstroPy] search_around_sky In-Reply-To: References: <8CA53308-1B62-4E95-B3D0-74024042B944@brera.inaf.it> Message-ID: <225AB5FD-7187-4A49-849E-EAF137899511@brera.inaf.it> > > Stefano, if I understand you correctly, you have: > > index2, index1, d2d, d3d = coord1.search_around_sky(coord2, maxsep) > > and you want to find "~index2" and "~index1" (which, of course, don't exist like that). > > I actually assume you want to find the *coordinates* of the non-matched sources, not the indices. But both can be done. > There's no simple one-liner that I know of, but creating a boolean mask is simple and useful to have around anyway (since a boolean mask can be simply inverted, unlike a array of indices). > > ind1 = np.unique(index1) > mask = np.ones(len(coord1), dtype=np.bool) > mask[ind1] = False > nonmatched_coord1 = coord1[mask] > nonmatched_ind1 = np.arange(len(coord1))[mask] > > and similar for coord2. > > I'm using np.unique to filter multiple matched objects. It's not really necessary here, but more as an ease of mind. (Otherwise you'd just be setting some values in the mask to False twice.) > The last line is to get the indices, and essentially coord1[nonmatched_ind1] == nonmatched_coord1 . > > > Evert > Thanks a lot, Evert. It is indeed what I was looking for. Bye, Stefano From parejkoj at uw.edu Tue Nov 10 18:11:17 2015 From: parejkoj at uw.edu (John K. Parejko) Date: Tue, 10 Nov 2015 15:11:17 -0800 Subject: [AstroPy] SDSS Survey Operations Software Developer Message-ID: <94D76649-5492-4483-B577-25771026B243@uw.edu> SDSS is advertising a Survey Operations Software Developer position at the University of Virginia. I'm advertising this position on the astropy lists because most of our ops software is in python. The job posting is on the AAS job register: https://jobregister.aas.org/job_view?JobID=52622 A more detailed description, including some of the job requirements, is given here: http://people.virginia.edu/~jss7qg/SDSS_IV_Software_Developer.html Inquiries regarding this position should be directed to Jennifer Sobeck (jsobeck at virginia.edu) and Connie Rockosi (crockosi at ucolick.org), though I can also answer short questions about it as most of the work will be taking over from me. Thank you, John -- ************************* John Parejko parejkoj at uw.edu http://www.astro.yale.edu/~jp727/ Department of Physics and Astronomy University of Washington Seattle, WA ************************** From susmitadas130 at gmail.com Mon Nov 16 02:56:48 2015 From: susmitadas130 at gmail.com (Susmita Das) Date: Mon, 16 Nov 2015 13:26:48 +0530 Subject: [AstroPy] Module for outliers Message-ID: Hello Below is a plot of Magnitude vs Phase made in IDL using "goodpoly.pro" where it takes magnitude, phase and sigma to remove outliers. I am now trying to shift to Python and would like to know: * If there exists a Module which would remove the outliers in magnitudes as a function of phase, i.e. for a smaller phase bins, remove N*sigma outliers in the magnitude. And perform it recursively until all outliers are removed. * I guess If I use the sigma_clip module on magnitude array only, it will remove all points beyond abs(mean - 3.0*sigma), not necessarily removing the outliers. Thank you for your help in advance Regards Susmita Das -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: outliers.eps Type: application/postscript Size: 66710 bytes Desc: not available URL: From erik.tollerud at gmail.com Tue Nov 24 14:46:55 2015 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 24 Nov 2015 14:46:55 -0500 Subject: [AstroPy] Astropy v1.0rc1 ready for testing Message-ID: Hello all, The astropy v1.1 release candidate is available for testing on pypi: https://pypi.python.org/pypi/astropy/1.1rc1 Please help us test if you can! You can install it with pip by doing "pip install astropy==1.1rc1". If you're using an anaconda distribution, you'll either need to "conda remove astropy" or make a new environment before installing the RC from pip. Documentation is available at: http://astropy.readthedocs.org/en/v1.1rc1/ Of particular note is the what's new section for 1.1: http://astropy.readthedocs.org/en/v1.1rc1/whatsnew/1.1.html Assuming no major blocking bugs are found in the RC, we will aim to do the final 1.1 release in about a week. --- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From trive at astro.su.se Tue Nov 24 15:25:58 2015 From: trive at astro.su.se (=?UTF-8?Q?Th=c3=b8ger_Emil_Rivera-Thorsen?=) Date: Tue, 24 Nov 2015 21:25:58 +0100 Subject: [AstroPy] Astropy v1.0rc1 ready for testing In-Reply-To: References: Message-ID: <5654C7D6.6010902@astro.su.se> Looks very, very interesting, I am really excited about many of the new features. Astropy is rapidly maturing. Good work! On 11/24/2015 08:46 PM, Erik Tollerud wrote: > Hello all, > > The astropy v1.1 release candidate is available for testing on pypi: > https://pypi.python.org/pypi/astropy/1.1rc1 > > Please help us test if you can! You can install it with pip by doing > "pip install astropy==1.1rc1". If you're using an anaconda > distribution, you'll either need to "conda remove astropy" or make a > new environment before installing the RC from pip. > > Documentation is available at: > http://astropy.readthedocs.org/en/v1.1rc1/ > > Of particular note is the what's new section for 1.1: > http://astropy.readthedocs.org/en/v1.1rc1/whatsnew/1.1.html > > Assuming no major blocking bugs are found in the RC, we will aim to do > the final 1.1 release in about a week. > > --- > Erik T > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Nov 25 13:31:44 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 25 Nov 2015 10:31:44 -0800 Subject: [AstroPy] [astropy-dev] Astropy v1.0rc1 ready for testing In-Reply-To: References: Message-ID: Hi, On Tue, Nov 24, 2015 at 11:46 AM, Erik Tollerud wrote: > Hello all, > > The astropy v1.1 release candidate is available for testing on pypi: > https://pypi.python.org/pypi/astropy/1.1rc1 > > Please help us test if you can! You can install it with pip by doing "pip > install astropy==1.1rc1". If you're using an anaconda distribution, you'll > either need to "conda remove astropy" or make a new environment before > installing the RC from pip. I built OSX wheels for the rc1. To test: pip install --pre --trusted-host wheels.scipy.org -f http://wheels.scipy.org astropy To get the wheel on Python 3.5, you'll need the latest pip (``pip install -U pip``). Cheers, Matthew From npkuin at gmail.com Thu Nov 26 16:28:46 2015 From: npkuin at gmail.com (Paul Kuin) Date: Thu, 26 Nov 2015 21:28:46 +0000 Subject: [AstroPy] astropy.io.fits Message-ID: I was reading in a fits binary table. Some fields have defined TNULL??=-2147483648, while TFORM?? = 'J ' If I display the variable, it shows -2147483648, while it should be set to Nan, or blank, I think. Is that a bug or a feature? -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 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 s.r.walker101 at googlemail.com Fri Nov 27 13:07:29 2015 From: s.r.walker101 at googlemail.com (Simon Walker) Date: Fri, 27 Nov 2015 18:07:29 +0000 Subject: [AstroPy] WCS solutions from table HDUs Message-ID: Hi, When I try to read the wcs header from a table HDU, the returned wcs object is not valid (i.e. it maps pixel coordinates to pixel coordinates.) My understanding is that `astropy.wcs` uses `wcslib` under the hood to handle most of the implementation, and `wcslib` supports table HDUs just fine. An example astrometric solution is given below: TCTYP3 = 'RA---ZPN' / WCS projection TCTYP6 = 'DEC--ZPN' / WCS projection TCRVL3 = 307.241977403642 / RA at reference pixel TCRVL6 = 25.3168420637255 / Dec at reference pixel TCRPX3 = 1024.4417725 TCRPX6 = 1023.831605 TC3_3 = -0.00140653080291281 TC6_6 = -0.00140646456957538 TC3_6 = 1.3189450212842E-05 TC6_3 = -1.3038301062367E-05 TV6_1 = 1. TV6_3 = 9.26153828229481 TV6_5 = -938.934425623138 TV6_7 = 688883.879115836 I?ve seen these keywords mentioned in the Paper I description, and I believe they are valid. The solution creates a valid astrometric solution when using the equivalent image wcs keywords (CD1_1, CRPIX etc.). If this is not supported I?d be happy to attempt an implementation - I am relatively familiar with `wcslib`. My knowledge of the standard however is a little shaky. Thanks, Simon Walker From s.r.walker101 at googlemail.com Sat Nov 28 15:51:23 2015 From: s.r.walker101 at googlemail.com (Simon Walker) Date: Sat, 28 Nov 2015 20:51:23 +0000 Subject: [AstroPy] WCS solutions from table HDUs In-Reply-To: References: Message-ID: I feel I?ve just answered my own question, by finding the `keysel` argument to `WCS.__init__`. In my case, the following gives a valid wcs solution object: ``` from astropy.io import fits from astropy.wcs import WCS header = fits.getheader(filename, tablename) wcs = WCS(header, keysel=[?pixel?]) ``` Thanks, Simon > On 27 Nov 2015, at 18:07, Simon Walker wrote: > > Hi, > > When I try to read the wcs header from a table HDU, the returned wcs object is not valid (i.e. it maps pixel coordinates to pixel coordinates.) > > My understanding is that `astropy.wcs` uses `wcslib` under the hood to handle most of the implementation, and `wcslib` supports table HDUs just fine. An example astrometric solution is given below: > > TCTYP3 = 'RA---ZPN' / WCS projection > TCTYP6 = 'DEC--ZPN' / WCS projection > TCRVL3 = 307.241977403642 / RA at reference pixel > TCRVL6 = 25.3168420637255 / Dec at reference pixel > TCRPX3 = 1024.4417725 > TCRPX6 = 1023.831605 > TC3_3 = -0.00140653080291281 > TC6_6 = -0.00140646456957538 > TC3_6 = 1.3189450212842E-05 > TC6_3 = -1.3038301062367E-05 > TV6_1 = 1. > TV6_3 = 9.26153828229481 > TV6_5 = -938.934425623138 > TV6_7 = 688883.879115836 > > I?ve seen these keywords mentioned in the Paper I description, and I believe they are valid. The solution creates a valid astrometric solution when using the equivalent image wcs keywords (CD1_1, CRPIX etc.). > > If this is not supported I?d be happy to attempt an implementation - I am relatively familiar with `wcslib`. My knowledge of the standard however is a little shaky. > > Thanks, > Simon Walker From embray at stsci.edu Mon Nov 30 09:00:33 2015 From: embray at stsci.edu (Erik Bray) Date: Mon, 30 Nov 2015 09:00:33 -0500 Subject: [AstroPy] astropy.io.fits In-Reply-To: References: Message-ID: <565C5681.4030109@stsci.edu> On 11/26/2015 04:28 PM, Paul Kuin wrote: > I was reading in a fits binary table. > > Some fields have defined TNULL??=-2147483648, while TFORM?? = 'J ' > > If I display the variable, it shows -2147483648, while it should be set to Nan, > or blank, I think. > > Is that a bug or a feature? Looks to be a bug, more or less. I only recently implemented working(?) support for the BLANK keyword in image arrays [1]. Proper support for TNULL would involve applying the same work to table columns, which should be straightforward. I think just nobody's ever asked. Erik [1] https://github.com/astropy/astropy/pull/3865 From yannick.roehlly at gmail.com Mon Nov 30 09:14:04 2015 From: yannick.roehlly at gmail.com (Yannick Roehlly) Date: Mon, 30 Nov 2015 15:14:04 +0100 Subject: [AstroPy] wcs.all_pix2world answering negative RA Message-ID: Hi all, I have a WCS for which asking for the coordinates at a pixel position leads to a negative right ascension. I attach a sample script exhibiting the behavior. Is it expected? Am I missing something? Yannick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pix2world_neg_RA.py Type: text/x-python Size: 1321 bytes Desc: not available URL: From eglez at ast.cam.ac.uk Mon Nov 30 09:36:24 2015 From: eglez at ast.cam.ac.uk (Eduardo Gonzalez) Date: Mon, 30 Nov 2015 14:36:24 +0000 Subject: [AstroPy] [IoA] wcs.all_pix2world answering negative RA In-Reply-To: References: Message-ID: On Mon, Nov 30, 2015 at 2:14 PM, Yannick Roehlly wrote: > > Is it expected? Am I missing something? > > CRVAL1 = -8.13584423065 / [deg] Coordinate value at reference point The R.A. at the reference point is negative in your WCS. Cheers, Eduardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannick.roehlly at gmail.com Mon Nov 30 10:03:02 2015 From: yannick.roehlly at gmail.com (Yannick Roehlly) Date: Mon, 30 Nov 2015 16:03:02 +0100 Subject: [AstroPy] [IoA] wcs.all_pix2world answering negative RA In-Reply-To: References: Message-ID: Oh yes you're right. I didn't notice. The strange thing is that both Aladin and DS9 manage to display the image from which this WCS comes with the correct coordinates. Is there something they are correcting? Yannick 2015-11-30 15:36 GMT+01:00 Eduardo Gonzalez : > > > On Mon, Nov 30, 2015 at 2:14 PM, Yannick Roehlly < > yannick.roehlly at gmail.com> wrote: > >> >> Is it expected? Am I missing something? >> >> > CRVAL1 = -8.13584423065 / [deg] Coordinate value at reference point > > The R.A. at the reference point is negative in your WCS. > > Cheers, > > Eduardo > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Mon Nov 30 10:42:59 2015 From: npkuin at gmail.com (Paul Kuin) Date: Mon, 30 Nov 2015 15:42:59 +0000 Subject: [AstroPy] astropy.io.fits In-Reply-To: <565C5681.4030109@stsci.edu> References: <565C5681.4030109@stsci.edu> Message-ID: Well, I did work around it, NP. It would be good to have that done some time. I was creating an ascii table from the FITS version and for consistency I changed all the NaN and -2147483648 to blanks. It was one shot thing. Keep up the good work! Cheers, Paul On Mon, Nov 30, 2015 at 2:00 PM, Erik Bray wrote: > On 11/26/2015 04:28 PM, Paul Kuin wrote: > >> I was reading in a fits binary table. >> >> Some fields have defined TNULL??=-2147483648, while TFORM?? = 'J ' >> >> If I display the variable, it shows -2147483648, while it should be set >> to Nan, >> or blank, I think. >> >> Is that a bug or a feature? >> > > Looks to be a bug, more or less. I only recently implemented working(?) > support for the BLANK keyword in image arrays [1]. Proper support for > TNULL would involve applying the same work to table columns, which should > be straightforward. I think just nobody's ever asked. > > Erik > > > [1] https://github.com/astropy/astropy/pull/3865 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.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) -204927 (work) mobile +44(0)7806985366 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 embray at stsci.edu Mon Nov 30 10:49:36 2015 From: embray at stsci.edu (Erik Bray) Date: Mon, 30 Nov 2015 10:49:36 -0500 Subject: [AstroPy] astropy.io.fits In-Reply-To: References: <565C5681.4030109@stsci.edu> Message-ID: <565C7010.70200@stsci.edu> On 11/30/2015 10:42 AM, Paul Kuin wrote: > Well, I did work around it, NP. It would be good to have that done some time. I > was creating an ascii table from the FITS version and for consistency I changed > all the NaN and -2147483648 to blanks. It was one shot thing. > Keep up the good work! Thanks for understanding. Part of the problem with this is that in order to interpret the TNULL keyword as NaNs you have no choice but to take existing integer data and convert it to floating point. And yeah, for the record a simple workaround is to do something like col = hdu.data['colname'].astype(float) col[col == hdu.header['TNULL1']] = np.nan If you don't convert the column from int to float, the default behavior of Numpy when assigning np.nan to that array is to write -2147483648 to the array as a "null" value. It won't automatically re-cast the array to floats, I believe. Erik > On Mon, Nov 30, 2015 at 2:00 PM, Erik Bray > wrote: > > On 11/26/2015 04:28 PM, Paul Kuin wrote: > > I was reading in a fits binary table. > > Some fields have defined TNULL??=-2147483648 , while > TFORM?? = 'J ' > > If I display the variable, it shows -2147483648 , while > it should be set to Nan, > or blank, I think. > > Is that a bug or a feature? > > > Looks to be a bug, more or less. I only recently implemented working(?) > support for the BLANK keyword in image arrays [1]. Proper support for TNULL > would involve applying the same work to table columns, which should be > straightforward. I think just nobody's ever asked. > > Erik > > > [1] https://github.com/astropy/astropy/pull/3865 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.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) -204927 (work) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > From eebanado at uc.cl Mon Nov 30 11:46:52 2015 From: eebanado at uc.cl (=?UTF-8?Q?Eduardo_Ba=C3=B1ados_Torres?=) Date: Mon, 30 Nov 2015 08:46:52 -0800 Subject: [AstroPy] [IoA] wcs.all_pix2world answering negative RA In-Reply-To: References: Message-ID: usually ra%=360. does the trick Eduardo On Mon, Nov 30, 2015 at 7:03 AM, Yannick Roehlly wrote: > Oh yes you're right. I didn't notice. The strange thing is that both > Aladin and DS9 manage to display the image from which this WCS comes with > the correct coordinates. Is there something they are correcting? > > Yannick > > 2015-11-30 15:36 GMT+01:00 Eduardo Gonzalez : > >> >> >> On Mon, Nov 30, 2015 at 2:14 PM, Yannick Roehlly < >> yannick.roehlly at gmail.com> wrote: >> >>> >>> Is it expected? Am I missing something? >>> >>> >> CRVAL1 = -8.13584423065 / [deg] Coordinate value at reference point >> >> The R.A. at the reference point is negative in your WCS. >> >> Cheers, >> >> Eduardo >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -- Eduardo Ba?ados Torres -------------- next part -------------- An HTML attachment was scrubbed... URL: