From tgrav at me.com  Fri Jun  3 13:16:39 2016
From: tgrav at me.com (Tommy Grav)
Date: Fri, 03 Jun 2016 13:16:39 -0400
Subject: [AstroPy] problem reading IPAC table
Message-ID: <BC079384-E605-4501-B317-B63D48C835AF@me.com>

I am trying to read an IPAC table with astropy (after having used atpy that has 
stopped being updated). However the reading of the table fails. Can anyone help?

Cheers
  Tommy

The code is:
from math import *
from astropy.table import Table
t = Table.read(?IPAC.tbl?,format=?ipac")
print len(t)

The error is:
> python -u plot_observed_fluxes.py 
Traceback (most recent call last):
  File "plot_observed_fluxes.py", line 5, in <module>
    t = Table.read("IPAC_C51_LPC_cryo.tbl",format="ipac")
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/table/table.py", line 2332, in read
    return io_registry.read(cls, *args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/registry.py", line 351, in read
    data = reader(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/ascii/connect.py", line 37, in io_read
    return read(filename, format=format, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/ascii/ui.py", line 341, in read
    dat = reader.read(table)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/ascii/core.py", line 1180, in read
    table = self.outputter(cols, self.meta)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/ascii/core.py", line 972, in __call__
    self._convert_vals(cols)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/astropy-1.2.dev15585-py2.7-macosx-10.5-x86_64.egg/astropy/io/ascii/core.py", line 959, in _convert_vals
    raise ValueError('Column {} failed to convert: {}'.format(col.name, last_err))
ValueError: Column cntr_01 failed to convert: invalid literal for long() with base 10: '\\'


The table is:
`\                                                                               
\fixlen = T
\RowsRetrieved =               520
\ORIGIN  = 'IPAC Infrared Science Archive (IRSA), Caltech/JPL'
\DATETIME= '2016-06-03 08:14:41'
\DATABASE= 'WISE All-Sky Single Exposure (L1b) Source Table (allsky_4band_p1bs_psd)'
\EQUINOX = 'J2000'
\ One to One Match 
\NOTE    = 'Column names with suffix _01 are from the input file UC51_LPC_gator.tbl.'
\NOTE    = 'Column cntr_01 is a sequential counter added to ID each row in the user input file UC51_LPC_gator.tbl.'
\NOTE    = 'dist_x is the distance in arcsec between each input source and its potential match in the WISE All-Sky Single Exposure (L1b) Source Table.'
\NOTE    = 'pang_x is position angle, measured eastward from north, between the input source and potential match in the WISE All-Sky Single Exposure (L1b) Source Table. 
\NOTE    = 'Output rows are ordered by increasing cntr_01, and for each cntr_01 by increasing dist_x.'
\StatusFile = '/workspace/TMP_9TwuEY_18921/Gator/irsa/21410/log.21410.html'
\SQL     = 'WHERE (no constraints) 
\SQL     = 'SELECT (52 column names follow in next row.)'
\Upload   = 'file=UC51_LPC_gator.tbl radius=10 unit=arcsec'
\ 
\ 
|              cntr_01|       dist_x|       pang_x|     name_01|            jd_01|            ra_01|           dec_01|      sun2sc_x_01|      sun2sc_y_01|      sun2sc_z_01|   w1flag_01|   w2flag_01|   w3flag_01|   w4flag_01|          ra|        dec|    sigra|   sigdec| sigradec| w1mpro| w1sigmpro|   w1snr|          w1rchi2| w2mpro| w2sigmpro|   w2snr|          w2rchi2| w3mpro| w3sigmpro|   w3snr|          w3rchi2| w4mpro| w4sigmpro|   w4snr|          w4rchi2|          nb|          na| w1sat| w2sat| w3sat| w4sat| cc_flags| ph_qual|     sso_flg|          mjd|   tmass_key| j_m_2mass| j_msig_2mass| h_m_2mass| h_msig_2mass| k_m_2mass| k_msig_2mass|
|                 long|       double|       double|        char|           double|           double|           double|           double|           double|           double|         int|         int|         int|         int|      double|     double|   double|   double|   double| double|    double|  double|           double| double|    double|  double|           double| double|    double|  double|           double| double|    double|  double|           double|         int|         int|double|double|double|double|     char|    char|         int|       double|         int|    double|       double|    double|       double|    double|       double|
|                     |       arcsec|          deg|            |                 |                 |                 |                 |                 |                 |            |            |            |            |            |           |         |         |         |       |          |        |                 |       |          |        |                 |       |          |        |                 |       |          |        |                 |            |            |      |      |      |      |         |        |            |             |            |          |             |          |             |          |             |
|                 null|         null|         null|        null|             null|             null|             null|             null|             null|             null|        null|        null|        null|        null|        null|       null|     null|     null|     null|   null|      null|    null|             null|   null|      null|    null|             null|   null|      null|    null|             null|   null|      null|    null|             null|        null|        null|  null|  null|  null|  null|     null|    null|        null|         null|        null|      null|         null|      null|         null|      null|         null|
                     1      0.702542   -110.190660     CK05L030       55340.27985      176.47433333      41.888555556    -0.46183044709    -0.90117641217  2.5475567468e-05            1            1            1            1  176.4740873  41.8884882    0.3075    0.3074    0.0289  17.001       null     null       0.425599992  15.314       null      0.9       0.763000011  11.113      0.430      2.5        1.14699996   5.214      0.050     21.9        10.3500004            1            0  0.000  0.000  0.000  0.000      0000     UUCA            1  55340.279850         null       null          null       null          null       null          null 
                     2      1.191349     23.956278     CK05L030       55340.27998        176.474125      41.889027778    -0.46182849332    -0.90117743975  2.5475581701e-05            1            1            1            1  176.4743055  41.8893302    0.3526    0.3778   -0.0571  16.171      0.331      3.3       0.512700021  15.203      0.349      3.1        0.83950001  10.918      0.330      3.3        1.15400004   5.216      0.064     16.9        6.14099979            2            0  0.000  0.000  0.000  0.000      0000     BBBA            1  55340.279977         null       null          null       null          null       null          null 
                     3      1.120613    -83.712704     CK05L030       55340.54446      176.44183333      41.874611111    -0.45784908896    -0.90325902498  2.5498792038e-05            1            1            1            1  176.4414178  41.8746452    0.4234    0.3977   -0.1026  16.230      0.280      3.9        1.11500001  14.885       null      2.0        0.77609998  10.533      0.236      4.6        1.13399994   5.437      0.071     15.2        5.10500002            2            0  0.000  0.000  0.000  0.000      0000     BUBA            1  55340.544458         null       null          null       null          null       null          null 
                     4      0.223009   -111.374916     CK05L030       55340.61067      176.43429167      41.870527778    -0.45685147037    -0.90377731968  2.5502811749e-05            1            1            1            1  176.4342142  41.8705052    0.3501    0.3841   -0.0698  16.776      0.424      2.6       0.891900003  14.975       null      1.7       0.822600007  10.741      0.266      4.1        1.04900002   4.971      0.063     17.2        5.37400007            1            0  0.000  0.000  0.000  0.000      0000     CUBA            1  55340.610673         null       null          null       null          null       null          null 
                     5      1.207195     35.906233     CK05L030       55340.74298      176.41870833      41.863638889    -0.45485620361    -0.90480967358   2.550870983e-05            1            1            1            1  176.4189724  41.8639105    0.3727    0.4275    0.1199  16.414       null      1.8       0.702499986  15.185      0.388      2.8        1.37800002  10.616      0.263      4.1       0.875899971   5.454      0.067     16.1        4.88100004            2            0  0.000  0.000  0.000  0.000      0000     UCBA            1  55340.742977         null       null          null       null          null       null          null 
                     6      0.481288    172.637939     CK05L030       55340.87528        176.402375      41.855888889    -0.45285884729    -0.90583744873  2.5511778069e-05            1            1            1            1  176.4023980  41.8557563    0.3294    0.3328    0.0508  16.340      0.327      3.3             1.352  15.207      0.405      2.7        1.40900004  10.320      0.198      5.5        1.49100006   5.244      0.053     20.4        8.58199978            1            0  0.000  0.000  0.000  0.000      0000     BCBA            1  55340.875281         null       null          null       null          null       null          null 
                     7      2.082220     27.859527     CK05L030       55341.13989         176.37025      41.840194444    -0.44885730109    -0.90787955846  2.5509514597e-05            1            1            1            1  176.3706128  41.8407058    0.3210    0.3526   -0.0271  16.122      0.259      4.2             1.245  15.334      0.397      2.7        1.83399999  10.874      0.304      3.6        1.50999999   5.195      0.056     19.4        8.17099953            1            0  0.000  0.000  0.000  0.000      0000     BCBA            1  55341.139889         null       null          null       null          null       null          null 
                     8      0.525329     61.035402     CK05L030        55341.4045      176.33916667      41.826333333    -0.44484690905    -0.90990361741  2.5496225689e-05            1            1            1            1  176.3393380  41.8264040    0.3373    0.3749   -0.0211  16.255      0.297      3.7        1.33000004  15.188       null      1.4       0.569700003  10.437      0.202      5.4       0.719600022   5.293      0.062     17.4        3.80599999            2            0  0.000  0.000  0.000  0.000      0000     BUBA            1  55341.404497         null       null          null       null          null       null          null 
                     9      0.619262     16.487107     CK06O02F       55326.64427      144.64866667      3.9275555556    -0.65281988044    -0.77043313523  1.7439960916e-05            1            1            1            1  144.6487156   3.9277205    0.7296    0.7649   -0.0687  16.711       null      1.0       0.629700005  15.445       null      0.4       0.832700014  11.010      0.374      2.9       0.876800001   5.989      0.117      9.3        2.50600004            1            0  0.000  0.000  0.000  0.000      0000     UUCB            1  55326.644270         null       null          null       null          null       null          null 
                    10      7.549195     28.419721     CK06O02F       55326.77657      144.65333333      3.9249722222    -0.65111848055    -0.77191209637  1.7468061883e-05            1            1            1            1  144.6543337   3.9268165    0.7286    0.7791    0.2262  15.442      0.151      7.2       0.423700005  14.897      0.288      3.8       0.842599988  11.225       null      0.3        1.29499996   7.178      0.290      3.7        1.16700006            2            0  0.000  0.000  0.000  0.000      0000     BBUB            0  55327.239575    776676111     16.976         0.209     15.976         0.153     15.345         0.188 
                    11      2.513670    169.398129     CK06O02F       55326.90888      144.65845833      3.9239722222    -0.64941365029    -0.77338728158  1.7498504206e-05            1            1            1            1  144.6585871   3.9232859    2.0312    2.2606    0.6757  16.895       null     null        1.29200006  14.964       null      1.6        1.12699997  10.727      0.301      3.6        1.25300002   7.456       null      0.6        1.26400006            1            0  0.000  0.000  0.000  0.000      0000     UUBU            0  55327.107271         null       null          null       null          null       null          null 
                    12      0.027311   -152.027596     CK06O02F       55327.04118      144.66416667           3.92175    -0.64770565631    -0.77485846001  1.7531291511e-05            1            1            1            1  144.6641631   3.9217433    0.6009    0.6194   -0.0479  16.831      0.454      2.4       0.667599976  15.637       null     null        1.23899996  11.248      0.500      2.2        1.01400006   5.966      0.099     10.9        2.63499999            1            0  0.000  0.000  0.000  0.000      0000     CUCA            1  55327.041183         null       null          null       null          null       null          null 
                    13      3.175762    179.933042     CK06O02F       55327.17349      144.66879167      3.9195555556     -0.6459942494    -0.77632584623   1.756643507e-05            1            1            1            1  144.6687927   3.9186734    0.5491    0.5627    0.0434  16.296       null      1.8        1.47800004  14.891      0.313      3.5       0.554700017  10.633      0.279      3.9        1.28100002   5.874      0.092     11.9        1.75300002            1            0  0.000  0.000  0.000  0.000      0000     UBBA            1  55327.173487         null       null          null       null          null       null          null 
                    14      0.389513    124.104207     CK06O02F       55327.23958          144.6725      3.9181666667    -0.64513815967     -0.7770573541  1.7584872566e-05            1            1            1            1  144.6725898   3.9181060    0.6065    0.6402    0.1156  17.093       null     null        1.27499998  15.512       null     null              1.13  10.969      0.381      2.8        1.09899998   5.983      0.101     10.7        1.80499995            1            0  0.000  0.000  0.000  0.000      0000     UUCA            1  55327.239575         null       null          null       null          null       null          null 
                    15      0.577296   -163.457123     CK06O02F       55327.30579      144.67391667      3.9172222222    -0.64427969731    -0.77778921063  1.7603933933e-05            1            1            1            1  144.6738709   3.9170685    0.6675    0.6392   -0.0464  16.456       null      1.1             1.074  15.474       null      0.1        1.10399997  10.768      0.302      3.6       0.969099998   5.694      0.109     10.0        2.33599997            1            0  0.000  0.000  0.000  0.000      0000     UUBA            1  55327.305791         null       null          null       null          null       null          null 
                    16      0.667582   -101.040166     CK06O02F       55327.37188      144.67695833      3.9158611111    -0.64342197524    -0.77851876198   1.762355031e-05            1            1            1            1  144.6767759   3.9158256    0.5525    0.5875    0.1269  16.550      0.490      2.2        1.07500005  15.640       null      0.2       0.758700013  10.396      0.232      4.7       0.834200025   5.907      0.094     11.5        2.45600009            1            0  0.000  0.000  0.000  0.000      0000     CUBA            1  55327.371880         null       null          null       null          null       null          null 






From parejkoj at uw.edu  Fri Jun  3 17:38:40 2016
From: parejkoj at uw.edu (John K. Parejko)
Date: Fri, 3 Jun 2016 14:38:40 -0700
Subject: [AstroPy] n-way cross matching?
Message-ID: <840F4766-E98A-4AF3-B79C-83803E760096@uw.edu>

Is see that astropy.coordinates has a catalog cross-matching system for pairs of points, but is there an n-way cross match (e.g. put in 10 catalogs and get the list of things that match across all of them)?

Thanks,
John

--
*************************
John Parejko
parejkoj at uw.edu
http://staff.washington.edu/parejkoj/
Department of Physics and Astronomy
University of Washington
Seattle, WA
**************************













From mr.alex.hagen at gmail.com  Fri Jun  3 20:58:34 2016
From: mr.alex.hagen at gmail.com (Alex Hagen)
Date: Fri, 3 Jun 2016 20:58:34 -0400
Subject: [AstroPy] n-way cross matching?
In-Reply-To: <840F4766-E98A-4AF3-B79C-83803E760096@uw.edu>
References: <840F4766-E98A-4AF3-B79C-83803E760096@uw.edu>
Message-ID: <CANS2AxJzqs=5kbwjTy8KM-usNiuxAUfA7-M0H43Ns_r3L-1N4A@mail.gmail.com>

Hi John,

There's currently not a function to do cross-matching on n catalogs. As I
imagine you've considered, you could match catalog 1 to catalog 2, match
that output to catalog 3 and so on.

Best of luck,

--alex

On Fri, Jun 3, 2016 at 5:38 PM, John K. Parejko <parejkoj at uw.edu> wrote:

> Is see that astropy.coordinates has a catalog cross-matching system for
> pairs of points, but is there an n-way cross match (e.g. put in 10 catalogs
> and get the list of things that match across all of them)?
>
> Thanks,
> John
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Alex Hagen
Ph.D. Candidate
Dept. of Astronomy and Astrophysics
& the Institute for Gravitation and the Cosmos
The Pennsylvania State University

https://astronomeralex.github.io/

Mailing Address:
525 Davey Lab
University Park, PA 16802-6305

Office:
313 Davey Lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160603/6387441d/attachment.html>

From burtscher at mpe.mpg.de  Thu Jun  9 09:39:59 2016
From: burtscher at mpe.mpg.de (Leonard Burtscher)
Date: Thu, 9 Jun 2016 15:39:59 +0200
Subject: [AstroPy] Error when reading binary table with scaled integers
Message-ID: <6688A424-5217-4A6B-BD50-FFA513218FA6@mpe.mpg.de>

Hi,

I am trying to read an image cube with scaled integers that is contained in the binary table of a FITS file. I read the file with

hdu=fits.open(file)

and hdu.info() looks like this:

...
7    IMAGING_DATA  BinTableHDU    107   1000R x 17C   ['1J', '1D', '1E', '2I', '2I', '1I', '2D', '2D', '2E', '1E', '1I', '1I', '2A', '1I', '2A', '4278I', '4278I']   
...

And hdu[7].data.columns looks like this:

ColDefs(
    [...other tables...]
    name = 'DATA1'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero = 32768.0; dim = '(62,69)'
    name = 'DATA2'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero = 32768.0; dim = '(62,69)'
)

When trying to access these image cubes I get the following error:


In [32]: img=hdu[7].data["DATA1"]
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-32-426539ce5f7e> in <module>()
----> 1 img=hdu[7].data["DATA1"]

/usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in __getitem__(self, key)
    482     def __getitem__(self, key):
    483         if isinstance(key, string_types):
--> 484             return self.field(key)
    485         elif isinstance(key, (slice, np.ndarray, tuple, list)):
    486             # Have to view as a recarray then back as a FITS_rec, otherwise the

/usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in field(self, key)
    656                 # Handle all other column data types which are fixed-width
    657                 # fields
--> 658                 converted = self._convert_other(column, field, recformat)
    659 
    660             self._converted[name] = converted

/usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in _convert_other(self, column, field, recformat)
    875                         field = test_overflow
    876                 else:
--> 877                     field += bzero
    878         elif _bool and field.dtype != bool:
    879             field = np.equal(field, ord('T'))

TypeError: Cannot cast ufunc add output from dtype('float64') to dtype('uint16') with casting rule 'same_kind'


Can someone help me out?

Thanks,
Leonard

--
http://www.mpe.mpg.de/~burtscher/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4709 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20160609/fe1fb70b/attachment.bin>

From p3y1i4n at gmail.com  Fri Jun 10 08:54:04 2016
From: p3y1i4n at gmail.com (Pey Lian Lim)
Date: Fri, 10 Jun 2016 08:54:04 -0400
Subject: [AstroPy] AstroPy Digest, Vol 117, Issue 3
In-Reply-To: <mailman.3.1465560001.20698.astropy@scipy.org>
References: <mailman.3.1465560001.20698.astropy@scipy.org>
Message-ID: <CAJt49iQdMwz8bGYDrUsu8VgRi=05q_yhTN0dCFiMOyVb=_kifg@mail.gmail.com>

Hi Leonard,

Perhaps your issue has been reported at
https://github.com/astropy/astropy/issues/4588 by someone else.

Sincerely,
Pey-Lian


On Fri, Jun 10, 2016 at 8:00 AM, <astropy-request at scipy.org> wrote:

> Send AstroPy mailing list submissions to
>         astropy at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
>         astropy-request at scipy.org
>
> You can reach the person managing the list at
>         astropy-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
>
>
> Today's Topics:
>
>    1. Error when reading binary table with scaled integers
>       (Leonard Burtscher)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 9 Jun 2016 15:39:59 +0200
> From: Leonard Burtscher <burtscher at mpe.mpg.de>
> To: Astronomical Python mailing list <astropy at scipy.org>
> Subject: [AstroPy] Error when reading binary table with scaled
>         integers
> Message-ID: <6688A424-5217-4A6B-BD50-FFA513218FA6 at mpe.mpg.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I am trying to read an image cube with scaled integers that is contained
> in the binary table of a FITS file. I read the file with
>
> hdu=fits.open(file)
>
> and hdu.info() looks like this:
>
> ...
> 7    IMAGING_DATA  BinTableHDU    107   1000R x 17C   ['1J', '1D', '1E',
> '2I', '2I', '1I', '2D', '2D', '2E', '1E', '1I', '1I', '2A', '1I', '2A',
> '4278I', '4278I']
> ...
>
> And hdu[7].data.columns looks like this:
>
> ColDefs(
>     [...other tables...]
>     name = 'DATA1'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero =
> 32768.0; dim = '(62,69)'
>     name = 'DATA2'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero =
> 32768.0; dim = '(62,69)'
> )
>
> When trying to access these image cubes I get the following error:
>
>
> In [32]: img=hdu[7].data["DATA1"]
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)
> <ipython-input-32-426539ce5f7e> in <module>()
> ----> 1 img=hdu[7].data["DATA1"]
>
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in
> __getitem__(self, key)
>     482     def __getitem__(self, key):
>     483         if isinstance(key, string_types):
> --> 484             return self.field(key)
>     485         elif isinstance(key, (slice, np.ndarray, tuple, list)):
>     486             # Have to view as a recarray then back as a FITS_rec,
> otherwise the
>
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in
> field(self, key)
>     656                 # Handle all other column data types which are
> fixed-width
>     657                 # fields
> --> 658                 converted = self._convert_other(column, field,
> recformat)
>     659
>     660             self._converted[name] = converted
>
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in
> _convert_other(self, column, field, recformat)
>     875                         field = test_overflow
>     876                 else:
> --> 877                     field += bzero
>     878         elif _bool and field.dtype != bool:
>     879             field = np.equal(field, ord('T'))
>
> TypeError: Cannot cast ufunc add output from dtype('float64') to
> dtype('uint16') with casting rule 'same_kind'
>
>
> Can someone help me out?
>
> Thanks,
> Leonard
>
> --
> http://www.mpe.mpg.de/~burtscher/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4709 bytes
> Desc: not available
> URL: <
> https://mail.scipy.org/pipermail/astropy/attachments/20160609/fe1fb70b/attachment-0001.p7s
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
> ------------------------------
>
> End of AstroPy Digest, Vol 117, Issue 3
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160610/fb4a39c8/attachment.html>

From burtscher at mpe.mpg.de  Fri Jun 10 09:40:55 2016
From: burtscher at mpe.mpg.de (Leonard Burtscher)
Date: Fri, 10 Jun 2016 15:40:55 +0200
Subject: [AstroPy] AstroPy Digest, Vol 117, Issue 3
In-Reply-To: <CAJt49iQdMwz8bGYDrUsu8VgRi=05q_yhTN0dCFiMOyVb=_kifg@mail.gmail.com>
References: <mailman.3.1465560001.20698.astropy@scipy.org>
 <CAJt49iQdMwz8bGYDrUsu8VgRi=05q_yhTN0dCFiMOyVb=_kifg@mail.gmail.com>
Message-ID: <E4DD68CC-4A35-49E9-BCB5-C3AC7FAB2B35@mpe.mpg.de>

Hi Pey-Lian,

Indeed this bug is similar to what I described, but not the same. I have added to this bug report.

Regards,
Leonard


> Am 10.06.2016 um 14:54 schrieb Pey Lian Lim <p3y1i4n at gmail.com>:
> 
> Hi Leonard,
> 
> Perhaps your issue has been reported at https://github.com/astropy/astropy/issues/4588 by someone else.
> 
> Sincerely,
> Pey-Lian
> 
> 
> On Fri, Jun 10, 2016 at 8:00 AM, <astropy-request at scipy.org> wrote:
> Send AstroPy mailing list submissions to
>         astropy at scipy.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
>         astropy-request at scipy.org
> 
> You can reach the person managing the list at
>         astropy-owner at scipy.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
> 
> 
> Today's Topics:
> 
>    1. Error when reading binary table with scaled integers
>       (Leonard Burtscher)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 9 Jun 2016 15:39:59 +0200
> From: Leonard Burtscher <burtscher at mpe.mpg.de>
> To: Astronomical Python mailing list <astropy at scipy.org>
> Subject: [AstroPy] Error when reading binary table with scaled
>         integers
> Message-ID: <6688A424-5217-4A6B-BD50-FFA513218FA6 at mpe.mpg.de>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> I am trying to read an image cube with scaled integers that is contained in the binary table of a FITS file. I read the file with
> 
> hdu=fits.open(file)
> 
> and hdu.info() looks like this:
> 
> ...
> 7    IMAGING_DATA  BinTableHDU    107   1000R x 17C   ['1J', '1D', '1E', '2I', '2I', '1I', '2D', '2D', '2E', '1E', '1I', '1I', '2A', '1I', '2A', '4278I', '4278I']
> ...
> 
> And hdu[7].data.columns looks like this:
> 
> ColDefs(
>     [...other tables...]
>     name = 'DATA1'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero = 32768.0; dim = '(62,69)'
>     name = 'DATA2'; format = '4278I'; unit = 'ADU'; bscale = 1.0; bzero = 32768.0; dim = '(62,69)'
> )
> 
> When trying to access these image cubes I get the following error:
> 
> 
> In [32]: img=hdu[7].data["DATA1"]
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)
> <ipython-input-32-426539ce5f7e> in <module>()
> ----> 1 img=hdu[7].data["DATA1"]
> 
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in __getitem__(self, key)
>     482     def __getitem__(self, key):
>     483         if isinstance(key, string_types):
> --> 484             return self.field(key)
>     485         elif isinstance(key, (slice, np.ndarray, tuple, list)):
>     486             # Have to view as a recarray then back as a FITS_rec, otherwise the
> 
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in field(self, key)
>     656                 # Handle all other column data types which are fixed-width
>     657                 # fields
> --> 658                 converted = self._convert_other(column, field, recformat)
>     659
>     660             self._converted[name] = converted
> 
> /usr/local/lib/python3.5/site-packages/astropy/io/fits/fitsrec.py in _convert_other(self, column, field, recformat)
>     875                         field = test_overflow
>     876                 else:
> --> 877                     field += bzero
>     878         elif _bool and field.dtype != bool:
>     879             field = np.equal(field, ord('T'))
> 
> TypeError: Cannot cast ufunc add output from dtype('float64') to dtype('uint16') with casting rule 'same_kind'
> 
> 
> Can someone help me out?
> 
> Thanks,
> Leonard
> 
> --
> http://www.mpe.mpg.de/~burtscher/
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4709 bytes
> Desc: not available
> URL: <https://mail.scipy.org/pipermail/astropy/attachments/20160609/fe1fb70b/attachment-0001.p7s>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> ------------------------------
> 
> End of AstroPy Digest, Vol 117, Issue 3
> ***************************************
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

--
http://www.mpe.mpg.de/~burtscher/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4709 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20160610/05367139/attachment.bin>

From demitri.muna at gmail.com  Wed Jun 15 21:39:04 2016
From: demitri.muna at gmail.com (Demitri Muna)
Date: Wed, 15 Jun 2016 21:39:04 -0400
Subject: [AstroPy] SciCoder Workshop, 1-5 Aug 2016 in New Haven.
Message-ID: <52ADFFD5-6566-4867-8CDC-9D9F17119647@gmail.com>

Hello,

I am happy to announce the eighth SciCoder workshop, being held at Yale in New Haven, Connecticut. This workshop may be of interest to young researchers (graduate students and postdocs), and it is designed to introduce modern programming practices, Python, 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 six 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 1-5 August in New Haven, hosted at Yale University. Applications are now being accepted through 15 July 2016. Further details about the workshop can be found here:

http://scicoder.org

A poster is be available from the web site for download and is highly suitable for posting, say, in your departments.

Cheers,
Demitri



From parejkoj at uw.edu  Thu Jun 16 23:48:29 2016
From: parejkoj at uw.edu (John K. Parejko)
Date: Thu, 16 Jun 2016 20:48:29 -0700
Subject: [AstroPy] Producing tile compressed FITS files
Message-ID: <F29A2BBB-1490-40A1-998C-9634FB9D3702@uw.edu>

cc:ing William Pence, as this may be an odd interaction between astropy.io.fits and cfitsio.

In an effort to reduce the size of some LSST test data, I converted the three image HDUs in a file to compressed image HDUs like so:

from astropy.io import fits
data = fits.open('somefile.fits')
for i in [1,2,3]:
    data[i] = fits.CompImageHDU(data=data[i].data,header=data[i].header)
data.writeto(f, clobber=True)

If I open the new file with pyfits, all of the HDUs seem fine, but now cfitsio doesn't appear to like the files. Erin Sheldon's fitsio only sees the first 2 HDUs. So does the online FITS tester webpage:

http://fits.gsfc.nasa.gov/fits_verify.html

DS9 seems to read it ok: I can specify "-mecube" and see all three image planes.

Is what I did above not allowed for some reason, or did I do something wrong?

I've put up the original file, the file with 3 HDUs tile-compressed, and (the original goal of this) a file with the 3 image HDUs zeroed out and then compressed (I wanted a file with the structure of the original, but taking minimal space):

http://staff.washington.edu/parejkoj/lsst/

Ideas and suggestions welcome!

Thanks in advance,
John

--
*************************
John Parejko
parejkoj at uw.edu
http://staff.washington.edu/parejkoj/
Department of Physics and Astronomy
University of Washington
Seattle, WA
**************************













From stephenbailey at lbl.gov  Fri Jun 17 01:24:40 2016
From: stephenbailey at lbl.gov (Stephen Bailey)
Date: Thu, 16 Jun 2016 22:24:40 -0700
Subject: [AstroPy] Producing tile compressed FITS files
In-Reply-To: <F29A2BBB-1490-40A1-998C-9634FB9D3702@uw.edu>
References: <F29A2BBB-1490-40A1-998C-9634FB9D3702@uw.edu>
Message-ID: <CAMCHcTorLC6+L_94Yfr0na+2bofoYteJS5yLTGgVb2PZ2C-JMg@mail.gmail.com>

+1 on this topic.  DESI has had the same problem, but we have not succeeded
in boiling it down to a simple test case for a bug report.  It seems
related to the compressed image HDU, but we have other files using
CompImageHDU that do not have this problem and we don't know what the
difference is.

Stephen

On Thu, Jun 16, 2016 at 8:48 PM, John K. Parejko <parejkoj at uw.edu> wrote:

> cc:ing William Pence, as this may be an odd interaction between
> astropy.io.fits and cfitsio.
>
> In an effort to reduce the size of some LSST test data, I converted the
> three image HDUs in a file to compressed image HDUs like so:
>
> from astropy.io import fits
> data = fits.open('somefile.fits')
> for i in [1,2,3]:
>     data[i] = fits.CompImageHDU(data=data[i].data,header=data[i].header)
> data.writeto(f, clobber=True)
>
> If I open the new file with pyfits, all of the HDUs seem fine, but now
> cfitsio doesn't appear to like the files. Erin Sheldon's fitsio only sees
> the first 2 HDUs. So does the online FITS tester webpage:
>
> http://fits.gsfc.nasa.gov/fits_verify.html
>
> DS9 seems to read it ok: I can specify "-mecube" and see all three image
> planes.
>
> Is what I did above not allowed for some reason, or did I do something
> wrong?
>
> I've put up the original file, the file with 3 HDUs tile-compressed, and
> (the original goal of this) a file with the 3 image HDUs zeroed out and
> then compressed (I wanted a file with the structure of the original, but
> taking minimal space):
>
> http://staff.washington.edu/parejkoj/lsst/
>
> Ideas and suggestions welcome!
>
> Thanks in advance,
> John
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160616/c9b38fb8/attachment.html>

From parejkoj at uw.edu  Fri Jun 17 12:44:13 2016
From: parejkoj at uw.edu (John Parejko)
Date: Fri, 17 Jun 2016 09:44:13 -0700
Subject: [AstroPy] Producing tile compressed FITS files
In-Reply-To: <CA+wd1PZTqUq0qfp0Xt68xtrOutTer7jB=G+Fearrdfg6SBuiuQ@mail.gmail.com>
References: <F29A2BBB-1490-40A1-998C-9634FB9D3702@uw.edu>
 <79ddd5ac-cd37-6ca4-7ce1-451e75b50d67@nasa.gov>
 <CA+wd1Pbthvs=V6JgJLXbNPRmVQUigBqrGCxwkdZfrHiDHWW_Uw@mail.gmail.com>
 <CA+wd1PZTqUq0qfp0Xt68xtrOutTer7jB=G+Fearrdfg6SBuiuQ@mail.gmail.com>
Message-ID: <CA+wd1PbGOakhtU6qxBZtBLXYqoWGQnzm6cS3f+HbFJ3uXQAKJg@mail.gmail.com>

Bill Pence gave this reply, but he's not on the astropy list.

By the looks of it, this is an astropy bug when it writes the CompImageHDUs.

John
On Jun 17, 2016 8:21 AM, "William Pence" <William.Pence at nasa.gov> wrote:

The error message produced by fits_verify when testing the compressed file
indicates that the header keywords in the 3rd HDU are not present in the
required order.  The 8th keyword of the binary table extension (the
compressed image) must be TFIELDS, but in this file the 8th keyword is
BSCALE.  CFITSIO strictly enforces this requirement, so won't read that HDU
(or any following HDUs). Here is the error message:

*** Error:   Bad HDU? (from CFITSIO error stack:)
             ffgtkn found unexpected keyword or value for keyword no. 8.
              Expected positive integer keyword TFIELDS, but instead
              found keyword BSCALE with value 1
             Failed to move to HDU number 3 (ffmahd).

-Bill


On 6/16/2016 11:48 PM, John K. Parejko wrote:

cc:ing William Pence, as this may be an odd interaction between
> astropy.io.fits and cfitsio.
>
> In an effort to reduce the size of some LSST test data, I converted the
> three image HDUs in a file to compressed image HDUs like so:
>
> from astropy.io import fits
> data = fits.open('somefile.fits')
> for i in [1,2,3]:
>      data[i] = fits.CompImageHDU(data=data[i].data,header=data[i].header)
> data.writeto(f, clobber=True)
>
> If I open the new file with pyfits, all of the HDUs seem fine, but now
> cfitsio doesn't appear to like the files. Erin Sheldon's fitsio only sees
> the first 2 HDUs. So does the online FITS tester webpage:
>
> http://fits.gsfc.nasa.gov/fits_verify.html
>
> DS9 seems to read it ok: I can specify "-mecube" and see all three image
> planes.
>
> Is what I did above not allowed for some reason, or did I do something
> wrong?
>
> I've put up the original file, the file with 3 HDUs tile-compressed, and
> (the original goal of this) a file with the 3 image HDUs zeroed out and
> then compressed (I wanted a file with the structure of the original, but
> taking minimal space):
>
> http://staff.washington.edu/parejkoj/lsst/
>
> Ideas and suggestions welcome!
>
> Thanks in advance,
> John
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160617/7609c9a0/attachment.html>

From realtimcornwell at gmail.com  Wed Jun 22 05:36:54 2016
From: realtimcornwell at gmail.com (Tim Cornwell)
Date: Wed, 22 Jun 2016 10:36:54 +0100
Subject: [AstroPy] astropy EarthLocation needs local coordinates
Message-ID: <etPan.576a5c36.708a169c.85e0@airmail.rr>


Hi,

I?ve just started using Astropy for some SKA simulation work. I?m loving it. High quality code with lots of well documented functionality.

I hav a small feature request. Unless I?m missing something, there is no way to convert a set of local positions (antennas or stations) at a known site to geodetic or geocentric. This is often needed in radio interferometry to convert putative telescope array layouts into true geocentric so that the array reference point can be added.

The input local coordinates are usually in a tangent plane touching the geoid at the reference point.

Best,

Tim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160622/d1e9e514/attachment.html>

From thomas.robitaille at gmail.com  Thu Jun 23 08:32:55 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 23 Jun 2016 13:32:55 +0100
Subject: [AstroPy] ANN: Astropy v1.2 released
Message-ID: <CAGMHX_2kz_9zTyVhsGhEwgfiUKw9ATWCWKTz=TomdHc_rwNj4Q@mail.gmail.com>

Dear colleagues,

We are very happy to announce the v1.2 release of the Astropy package,
a core Python package for Astronomy:

  http://www.astropy.org

Astropy is a community-driven Python package intended to contain much
of the core functionality and common tools needed for astronomy and
astrophysics.

New and improved major functionality in this release includes:

* A new class to compute Lomb-Scargle periodograms efficiently using
different methods.
* A number of new statistics functions including those for Jackknife
resampling, circular statistics, and the Akaike and Bayesian
information criteria.
* Support for getting the positions of solar system bodies in the
coordinates sub-package.
* The ability to compute Barycentric and Heliocentric light-travel
time corrections.
* Support for offset coordinate frames, which can be used to define a
coordinate system relative to a known position and rotation.
* An implementation of the zscale algorithm to determine image limits
automatically.
* Support for bolometric magnitudes in the units package.
* Improvements to the NDData class and subclasses.
* Auto-downloading of IERS tables as needed, which gives information
about Earth orientation parameters necessary for high precision
coordinate calculations and conversions to/from the UT1 scale.

In addition, hundreds of smaller improvements and fixes have been
made. An overview of the changes is provided at:

  http://docs.astropy.org/en/stable/whatsnew/1.2.html

Instructions for installing Astropy are provided on our website, and
extensive documentation can be found at:

  http://docs.astropy.org

If you make use of the Anaconda Python Distribution, you can update to
Astropy v1.2 with:

  conda update astropy

If you normally use pip, you can upgrade with:

  pip install astropy --upgrade

Note that if you install now you should get Astropy v1.2.1, as some
last-minute bug fixes were found and fixed after the v1.2 release was
created but before this announcement.

Please report any issues, or request new features via our GitHub repository:

  https://github.com/astropy/astropy/issues

Over 190 developers have contributed code to Astropy so far, and you
can find out more about the team behind Astropy here:

  http://www.astropy.org/team.html

As a reminder, Astropy v1.0 (our long term support release) will
continue to be supported with bug fixes until Feb 19th 2017, so if you
need to use Astropy in a very stable environment, you may want to
consider staying on the v1.0.x set of releases (for which we have
recently released v1.0.10).

If you use Astropy directly for your work, or as a dependency to
another package, please remember to include the following
acknowledgment at the end of papers:

?This research made use of Astropy, a community-developed core Python
package for Astronomy (Astropy Collaboration, 2013).?

where (Astropy Collaboration, 2013) is a reference to the Astropy paper:

  http://dx.doi.org/10.1051/0004-6361/201322068

Please feel free to forward this announcement to anyone you think
might be interested in this release!

Erik Tollerud, Tom Robitaille, Kelle Cruz, and Tom Aldcroft
on behalf of The Astropy Collaboration


From bruno.sanchez.63 at gmail.com  Fri Jun 24 11:17:22 2016
From: bruno.sanchez.63 at gmail.com (=?UTF-8?Q?Bruno_O=2E_S=C3=A1nchez?=)
Date: Fri, 24 Jun 2016 15:17:22 +0000
Subject: [AstroPy] fftw3
Message-ID: <CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ@mail.gmail.com>

Hello guys,

I am an astronomer from C?rdoba Argentina, and I work a lot with astropy. I
have been working on proper coaddition of images with spatially variant
PSF, and I am currently using the convolution from astropy and scipy.

I've encountered some perfomance issues, and noticed that there is some
previous discussion on the settings of astropy.convolution.convolve fft
engines.

I wonder if any of you have succeded in setting a fftw3 engine for
convolution, and if you have a snippet for using it. The fftw3 planning
stage confuses me, and I can't find a documentation on pyfftw3.

Any clues you can give me for this would be greatly appreciated!

Bruno SANCHEZ
Observatorio Astron?mico de C?rdoba



-- 
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160624/7c13e811/attachment.html>

From mperrin at stsci.edu  Fri Jun 24 13:07:14 2016
From: mperrin at stsci.edu (Marshall Perrin)
Date: Fri, 24 Jun 2016 17:07:14 +0000
Subject: [AstroPy] fftw3
In-Reply-To: <CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ@mail.gmail.com>
References: <CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ@mail.gmail.com>
Message-ID: <6C0C14D7-D52F-4E6C-B19C-28C94C4802FA@stsci.edu>

Dear Bruno,

We use pyfftw as an optional dependency in our poppy physical optics library.  Our application is for complex wavefront propagation rather than convolutions but it still shows how to use the library, including the planning setup which I agree is not that well explained. For example code you can look here:
https://github.com/mperrin/poppy/blob/master/poppy/poppy_core.py
https://github.com/mperrin/poppy/blob/master/poppy/utils.py

Cheers,

 - Marshall


On Jun 24, 2016, at 11:17 AM, Bruno O. S?nchez <bruno.sanchez.63 at gmail.com<mailto:bruno.sanchez.63 at gmail.com>> wrote:

Hello guys,

I am an astronomer from C?rdoba Argentina, and I work a lot with astropy. I have been working on proper coaddition of images with spatially variant PSF, and I am currently using the convolution from astropy and scipy.

I've encountered some perfomance issues, and noticed that there is some previous discussion on the settings of astropy.convolution.convolve fft engines.

I wonder if any of you have succeded in setting a fftw3 engine for convolution, and if you have a snippet for using it. The fftw3 planning stage confuses me, and I can't find a documentation on pyfftw3.

Any clues you can give me for this would be greatly appreciated!

Bruno SANCHEZ
Observatorio Astron?mico de C?rdoba



--
Bruno
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org<mailto:AstroPy at scipy.org>
https://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160624/b20b0da9/attachment.html>

From jens at astro.su.se  Fri Jun 24 13:21:09 2016
From: jens at astro.su.se (Jens Melinder)
Date: Fri, 24 Jun 2016 19:21:09 +0200
Subject: [AstroPy] fftw3
In-Reply-To: <CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ@mail.gmail.com>
References: <CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ@mail.gmail.com>
Message-ID: <72822D4A-C97C-4D3E-AAC1-AAF3A8196EF9@astro.su.se>

Hi Bruno,

I?m using this version of pyfftw:
https://github.com/pyFFTW/pyFFTW <https://github.com/pyFFTW/pyFFTW>
(There is another wrapper around as well, but that did not work for me). There are some problems building this inside a Ureka environment, but seems to be working fine in conda.

This is well documented and works really well for me. In my testing I found this wrapper something like 3-4 times faster than the scipy/numpy fftw implementations (running on a single core, I?ve never gotten the hyperthreading to work with any of the FFTW implementations).

The package also has a interfaces module that lets you use the pyfftw fftws inside a an astropy.convolution function call. Here is a code snippet from my code:

import pyfftw
from astropy.convolution import convolve_fft
fftn=pyfftw.interfaces.numpy_fft.fftn
ifftn=pyfftw.interfaces.numpy_fft.ifftn

def fftwn(*dat):
	return fftn(*dat,threads=1)

def ifftwn(*dat):
	return ifftn(*dat,threads=1)

def conv(ima,kernel):
    return convolve_fft(ima,kernel,boundary='wrap',fftn=fftwn,ifftn=ifftwn)

You may not need the fftwn and ifftwn functions, if I remember correctly I only created those to be able to test the hyperthreading.

Good luck!

Cheers,
Jens




> 24 jun 2016 kl. 17:17 skrev Bruno O. S?nchez <bruno.sanchez.63 at gmail.com>:
> 
> Hello guys,
> 
> I am an astronomer from C?rdoba Argentina, and I work a lot with astropy. I have been working on proper coaddition of images with spatially variant PSF, and I am currently using the convolution from astropy and scipy.
> 
> I've encountered some perfomance issues, and noticed that there is some previous discussion on the settings of astropy.convolution.convolve fft engines.
> 
> I wonder if any of you have succeded in setting a fftw3 engine for convolution, and if you have a snippet for using it. The fftw3 planning stage confuses me, and I can't find a documentation on pyfftw3.
> 
> Any clues you can give me for this would be greatly appreciated!
> 
> Bruno SANCHEZ
> Observatorio Astron?mico de C?rdoba
> 
> 
> 
> -- 
> Bruno
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy



-----------------------------------
Jens Melinder
Department of Astronomy
Stockholm University
jens at astro.su.se
+46 706471856




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160624/df02cb70/attachment.html>

From thomas.robitaille at gmail.com  Fri Jun 24 13:31:14 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 24 Jun 2016 18:31:14 +0100
Subject: [AstroPy] n-way cross matching?
In-Reply-To: <840F4766-E98A-4AF3-B79C-83803E760096@uw.edu>
References: <840F4766-E98A-4AF3-B79C-83803E760096@uw.edu>
Message-ID: <CAGMHX_3xRVWgN+X4jd3HKosjqp_kp3_O-_X8Hc95_K+VLPGfkA@mail.gmail.com>

Hi John,

Could you open a feature request for this in the astropy repository?
(and of course, let us know if you are interested in helping implement
this!)

Cheers,
Tom


On 3 June 2016 at 22:38, John K. Parejko <parejkoj at uw.edu> wrote:
> Is see that astropy.coordinates has a catalog cross-matching system for pairs of points, but is there an n-way cross match (e.g. put in 10 catalogs and get the list of things that match across all of them)?
>
> Thanks,
> John
>
> --
> *************************
> John Parejko
> parejkoj at uw.edu
> http://staff.washington.edu/parejkoj/
> Department of Physics and Astronomy
> University of Washington
> Seattle, WA
> **************************
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From thomas.robitaille at gmail.com  Fri Jun 24 13:32:19 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 24 Jun 2016 18:32:19 +0100
Subject: [AstroPy] Error when opening Vizier FITS table with astropy
	Table.read
In-Reply-To: <574DEF4B.4030501@stsci.edu>
References: <19D3B5C6-5437-467C-A41E-631A85F51181@swarthmore.edu>
 <CANoQ6N3A-zZnmxomj6uKpoLdk5ea4_hcSbSUBw_Oi57C_2_OpA@mail.gmail.com>
 <E52841A5-B2F8-4B4F-9181-12408647A644@swarthmore.edu>
 <574DE930.6090902@stsci.edu> <574DEF4B.4030501@stsci.edu>
Message-ID: <CAGMHX_3hQBNAPmReh01dCz-Rvs+EL=WEmSuJBgAu8sef19dwqw@mail.gmail.com>

Hi Phil,

Could you open an issue in the GitHub repository to make sure we don't
lose track of this problem?

Thanks!
Tom


On 31 May 2016 at 21:08, Phil Hodge <hodge at stsci.edu> wrote:
> It looks as if astropy.io.fits still doesn't accept an empty (or null)
> string as a value for an integer column in an ASCII table.  If you just need
> to see the data values, you can use the tables package in IRAF as a
> workaround:
>
> --> tprint J_ApJS_186_111_table4_mod.fits[1] row=1-3
> #  Table J_ApJS_186_111_table4_mod.fits[1]  Tue 15:57:58 31-May-2016
>
> # row 2MASS             Name                     Ap 3.6mag e_3.6mag f_3.6mag
> #                                               pix    mag mag
>
>     1 J04034930+2610520 HBC 358 A+B+C         INDEF   9.15 0.02
>     2 J04034997+2620382 XEST 06-006           INDEF  INDEF INDEF o
>     3 J04035084+2610531 HBC 359               INDEF   9.33 0.02
>
> # row 4.5mag e_4.5mag f_4.5mag 5.8mag e_5.8mag f_5.8mag 8.0mag e_8.0mag
> f_8.0mag
> #        mag      mag             mag      mag mag      mag
>
>     1   9.11     0.02            9.05     0.03 9.05     0.03
>     2  INDEF    INDEF o         INDEF    INDEF o INDEF    INDEF o
>     3   9.26     0.02            9.23     0.03 9.23     0.03
>
> # row Date
> #     "Y/M/D"
>
>     1 2005 Feb 20
>     2
>     3 2005 Feb 20
>
> A printed value of INDEF means the table value was not defined.
>
> Phil
>
>
>
> On 05/31/2016 03:42 PM, Phil Hodge wrote:
>>
>> The keyword (and ones like it) should be TNULL3, not TBNUL3.  You can fix
>> this by downloading the FITS file and then opening the file as follows:
>>
>> import astropy.io.fits as fits
>> fd = fits.open("J_ApJS_186_111_table4.dat.fits")
>>
>> Then modify the table header:
>>
>> hdr = fd[1].header
>> hdr.rename_keyword("tbnul3", "tnull3")
>> hdr.rename_keyword("tbnul4", "tnull4")
>> hdr.rename_keyword("tbnul5", "tnull5")
>> hdr.rename_keyword("tbnul7", "tnull7")
>> hdr.rename_keyword("tbnul8", "tnull8")
>> hdr.rename_keyword("tbnul10", "tnull10")
>> hdr.rename_keyword("tbnul13", "tnull13")
>> hdr.rename_keyword("tbnul14", "tnull14")
>>
>> And save it to a new file:
>>
>> fd.writeto("J_ApJS_186_111_table4_mod.fits")  # or some other name
>>
>> Phil
>>
>>
>>
>> On 05/31/2016 03:25 PM, Eric Jensen wrote:
>>>
>>>
>>> On May 31, 2016, at 2:56 PM, Paul Kuin <npkuin at gmail.com
>>> <mailto:npkuin at gmail.com>> wrote:
>>>
>>>> Have you tried to read the fits file with astropy.io.fits ? What do you
>>>> get then for the table?
>>>
>>>
>>> It opens the file without error, and I can examine the header. But as
>>> soon as I try to access any part of the data structure, I get the same
>>> ValueError about TNULL3 shown below.
>>>
>>>
>>>
>>>>
>>>> On Tue, May 31, 2016 at 7:07 PM, Eric Jensen <ejensen1 at swarthmore.edu
>>>> <mailto:ejensen1 at swarthmore.edu>> wrote:
>>>>
>>>>     Hi all,
>>>>
>>>>     I?m trying to read a FITS table associated with an ApJ paper, and
>>>>     getting an error I don?t understand.  The table in question
>>>>     doesn?t have a standard ASCII/CDS version with the full header
>>>>     that astropy handles very well (in my experience) with
>>>>     format=?ascii.cds?, so I was trying to use the FITS version
>>>>     linked here:
>>>>
>>>>
>>>> http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/fits?J%2FApJS%2F186%2F111/table4.dat
>>>>
>>>>     Looking at that URL, it would appear that Vizier may be doing an
>>>>     on-the-fly conversion to FITS?  But my hope was that using that
>>>>     would take into account the information in the Vizier README, and
>>>>     thus generate a nice table structure in Python without my having
>>>>     to identify columns by hand.  The plain-text version
>>>> (http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/ApJS/186/111/table4.dat)
>>>>     doesn?t have header info, though such info is present in the
>>>>     separate README file.
>>>>
>>>>     However, when I read the FITS file like this:
>>>>
>>>>     from astropy.table import Table
>>>>     datafile = 'J_ApJS_186_111_table4.dat.fits'
>>>>     t2 = Table.read(datafile, format='fits')
>>>>
>>>>     I get this error:
>>>>
>>>>     ValueError: invalid literal for int() with base 10: ' '; the
>>>>     header may be missing the necessary TNULL3 keyword or the table
>>>>     contains invalid data
>>>>
>>>>     Looking at the FITS header, there is indeed no TNULL3 keyword,
>>>>     but there is a TBNUL3 keyword:
>>>>
>>>>     TBNUL3 = '        '           / NULL (undefined) value
>>>>
>>>>     So presumably that keyword has the needed info, but not in the
>>>>     field astropy is expecting.  Is there any way to work around this?
>>>>
>>>>     Possibly related - reading in that file in its text version,
>>>>     specifying format=?cds? and readme=?ReadMe? doesn?t work
>>>>     correctly either, because the ReadMe has a combined entry for
>>>>     Tables 4 and 5, and says in a note that the third field only
>>>>     applies to Table 5.  So this could just be a pathological case
>>>>     for this particular file, but I?m curious to know if anyone has
>>>>     encountered anything like this or has any recommendations.
>>>>
>>>>     Thanks in advance for your help with this,
>>>>
>>>>     Eric
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy


From thomas.robitaille at gmail.com  Fri Jun 24 13:56:26 2016
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 24 Jun 2016 18:56:26 +0100
Subject: [AstroPy] get_sun got wrong position ?
In-Reply-To: <CACVX7WT1b1v2ZMw_qFVuvz=KTk3ZHEq+msLPdOBMDF8guVRJtg@mail.gmail.com>
References: <CACVX7WT1b1v2ZMw_qFVuvz=KTk3ZHEq+msLPdOBMDF8guVRJtg@mail.gmail.com>
Message-ID: <CAGMHX_3aUe9HJXkJGDSAxSYHmT=p_k80vZesrA_3t1rdTLCeKA@mail.gmail.com>

I have created an issue to keep track of this problem:

https://github.com/astropy/astropy/issues/5130

Feel free to add more details in comments in this issue!

Cheers,
Tom


On 25 May 2016 at 15:14, Yang Hon-Jang <hjyanghj at gmail.com> wrote:
> Phil,
>
> Thanks for your attachment.py
>
>
> hjyanghj
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From erwin at mpe.mpg.de  Fri Jun 24 14:31:43 2016
From: erwin at mpe.mpg.de (Peter Erwin)
Date: Fri, 24 Jun 2016 20:31:43 +0200
Subject: [AstroPy] Updated versions of telarchive and fetchsdss
Message-ID: <757E5032-9BB4-41CF-B052-E9DEC592C1AB@mpe.mpg.de>

This is an announcement of an updated version (1.8.1) of my quick-and- 
dirty, Python-based telescope archive search tool, available here:

http://www.mpe.mpg.de/~erwin/code/

(A short summary of what it does is appended below.)

Recent fixes:
- Restored coordinate lookup for object names via SIMBAD (broken due to 
changes in SIMBAD output HTML)

- Ancillary package fetchsdss now correctly retrieves all available imaging fields 
associated with a search, instead of just the first field

Changes/updates during the past year:
- Added the new, La Palma-based Isaac Newton Group archive, replacing the old 
ING archive server which didn't include new data (and wasn't really working anymore).
Also restored proper access for both CFHT and UKIRT (now using CADC searches
for both).

- Removed NOAO archive due to its switching to JavaScript (instead of HTML)

- SDSS DR12 searches also include optical spectra



[previous summary, updated:]

"Telarchive" is a command-line program which simplifies searching
various public telescope archives to see if they might have data on a
particular astronomical object or part of the sky.  This includes the
HST and general MAST archive (and Spitzer), as well as the ESO, UKIRT,
CFHT, ING, Gemini, SMOKA (Subaru), and AAT ground-based archives, and
both imaging and spectroscopic data from Data Releases 7 (DR7) and DR12
of the Sloan Digital Sky Survey.

The program won't *get* the data for you, of course (but see "fetchsdss"
for SDSS images and spectra), or even tell you very much about it -- for that, you
still need to visit the individual archive web pages.  But it will save you
lots of clicking and typing in web-page forms if you just want to find out
if there is *any* data available.

An example (searching within a 2-arcminute box centered on the planetary
nebula NGC 7027; searching on coordinates directly is also possible):

$ telarchive "ngc 7027" 2.0
	SIMBAD (Simbad 4, France): Found object coordinates: RA = 21 07 01.8, Dec = +42 14 10

Searching archives for ngc 7027 (RA = 21 07 01.8, dec = +42 14 10), with search box =  2.0 arcmin...
	AAT Archive: No data found.
	ESO Archive: Data exists! (2 observations found)
		2 spectra
	HST archive: Data exists! (109 records found)
		13 FOS, 3 FOC, 25 WFPC, 18 WFPC2, 26 NICMOS, 24 STIS
	Multimission Archive at STScI (MAST): Data exists! (37 observations found)
		COPERNICUS (1); FUSE (2); IUE (34)
	Spitzer archive: Data exists! (13 records found)
		1 mipssed, 2 iracmap, 3 mipsphot, 7 irsstare
	Sloan Digital Sky Survey (DR7+DR12): No data found.
	Gemini Science Archive: No data found.
	CFHT Archive: Data exists! (419 observations found)
		GECKO (4), GRIF (48), BEAR (361), aobir (6)
	UKIRT Archive: Data exists! (259 observations found)
		UFTI (51), Michelle (208)
	SMOKA (Subaru Mitaka Okayama Kiso Archive): No data found.
	ING Archive (La Palma): Data exists! (893 observations found)
		595 images, 298 spectra
		WHT -- ISIS (217), WHIRCAM (6), TAURUS (5), LIRIS (573), LDSS (4), UES (69); INT -- WFC (13), IDS (5); JKT -- JAG (1)


It's available as a gzipped tar file here:
http://www.mpe.mpg.de/~erwin/code/

There are installation instructions/suggestions in the README file.
(The code is currently Python-2 only, though I?m working on upgrading it for
Python 3.)

(And feel free to email with questions or suggestions about it!)

cheers,

Peter

=============================================================
Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
erwin at mpe.mpg.de              Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713     85748 Garching, Germany
fax  +49 (0)89 30000 3495     http://www.mpe.mpg.de/~erwin





From Elie.Bouffard at USherbrooke.ca  Mon Jun 27 15:27:06 2016
From: Elie.Bouffard at USherbrooke.ca (=?iso-8859-1?Q?=C9lie_Bouffard?=)
Date: Mon, 27 Jun 2016 19:27:06 +0000
Subject: [AstroPy] Lomb-Scargle False-alarm probability
Message-ID: <SN1PR0201MB1488386F1C70E268084D53F095210@SN1PR0201MB1488.namprd02.prod.outlook.com>

Hi everyone,

I'm presently working with the newly included Lomb-Scargle periodogram in Astropy. It is very good, but I have a question. Is it possible to compute the false-alarm probability? If so, how exactly?

Thanks!

-?lie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160627/1d04e2fe/attachment.html>

From bruno.sanchez.63 at gmail.com  Mon Jun 27 15:58:55 2016
From: bruno.sanchez.63 at gmail.com (=?UTF-8?Q?Bruno_O=2E_S=C3=A1nchez?=)
Date: Mon, 27 Jun 2016 19:58:55 +0000
Subject: [AstroPy] AstroPy Digest, Vol 117, Issue 10
In-Reply-To: <mailman.80575.1466788884.2321.astropy@scipy.org>
References: <mailman.80575.1466788884.2321.astropy@scipy.org>
Message-ID: <CACJJhJxp1STT0bcUe6tetg1Cs5wEf5=v40Bq2TKA-ecYiSwcOA@mail.gmail.com>

Thanks!

You helped me a lot!

cheers,
Bruno

El vie., 24 jun. 2016 a las 14:21, <astropy-request at scipy.org> escribi?:

> Send AstroPy mailing list submissions to
>         astropy at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
>         astropy-request at scipy.org
>
> You can reach the person managing the list at
>         astropy-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
>
>
> Today's Topics:
>
>    1. fftw3 (Bruno O. S?nchez)
>    2. Re: fftw3 (Marshall Perrin)
>    3. Re: fftw3 (Jens Melinder)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 24 Jun 2016 15:17:22 +0000
> From: Bruno O. S?nchez <bruno.sanchez.63 at gmail.com>
> To: astropy at scipy.org
> Subject: [AstroPy] fftw3
> Message-ID:
>         <
> CACJJhJxNM_0n_iVYU2yERq6HaJn8HKtaiBcp4KgNW+V6HQ8fcQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello guys,
>
> I am an astronomer from C?rdoba Argentina, and I work a lot with astropy. I
> have been working on proper coaddition of images with spatially variant
> PSF, and I am currently using the convolution from astropy and scipy.
>
> I've encountered some perfomance issues, and noticed that there is some
> previous discussion on the settings of astropy.convolution.convolve fft
> engines.
>
> I wonder if any of you have succeded in setting a fftw3 engine for
> convolution, and if you have a snippet for using it. The fftw3 planning
> stage confuses me, and I can't find a documentation on pyfftw3.
>
> Any clues you can give me for this would be greatly appreciated!
>
> Bruno SANCHEZ
> Observatorio Astron?mico de C?rdoba
>
>
>
> --
> Bruno
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/astropy/attachments/20160624/7c13e811/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 24 Jun 2016 17:07:14 +0000
> From: Marshall Perrin <mperrin at stsci.edu>
> To: Astronomical Python mailing list <astropy at scipy.org>
> Subject: Re: [AstroPy] fftw3
> Message-ID: <6C0C14D7-D52F-4E6C-B19C-28C94C4802FA at stsci.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Bruno,
>
> We use pyfftw as an optional dependency in our poppy physical optics
> library.  Our application is for complex wavefront propagation rather than
> convolutions but it still shows how to use the library, including the
> planning setup which I agree is not that well explained. For example code
> you can look here:
> https://github.com/mperrin/poppy/blob/master/poppy/poppy_core.py
> https://github.com/mperrin/poppy/blob/master/poppy/utils.py
>
> Cheers,
>
>  - Marshall
>
>
> On Jun 24, 2016, at 11:17 AM, Bruno O. S?nchez <bruno.sanchez.63 at gmail.com
> <mailto:bruno.sanchez.63 at gmail.com>> wrote:
>
> Hello guys,
>
> I am an astronomer from C?rdoba Argentina, and I work a lot with astropy.
> I have been working on proper coaddition of images with spatially variant
> PSF, and I am currently using the convolution from astropy and scipy.
>
> I've encountered some perfomance issues, and noticed that there is some
> previous discussion on the settings of astropy.convolution.convolve fft
> engines.
>
> I wonder if any of you have succeded in setting a fftw3 engine for
> convolution, and if you have a snippet for using it. The fftw3 planning
> stage confuses me, and I can't find a documentation on pyfftw3.
>
> Any clues you can give me for this would be greatly appreciated!
>
> Bruno SANCHEZ
> Observatorio Astron?mico de C?rdoba
>
>
>
> --
> Bruno
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org<mailto:AstroPy at scipy.org>
> https://mail.scipy.org/mailman/listinfo/astropy
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/astropy/attachments/20160624/b20b0da9/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 24 Jun 2016 19:21:09 +0200
> From: Jens Melinder <jens at astro.su.se>
> To: Astronomical Python mailing list <astropy at scipy.org>
> Subject: Re: [AstroPy] fftw3
> Message-ID: <72822D4A-C97C-4D3E-AAC1-AAF3A8196EF9 at astro.su.se>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Bruno,
>
> I?m using this version of pyfftw:
> https://github.com/pyFFTW/pyFFTW <https://github.com/pyFFTW/pyFFTW>
> (There is another wrapper around as well, but that did not work for me).
> There are some problems building this inside a Ureka environment, but seems
> to be working fine in conda.
>
> This is well documented and works really well for me. In my testing I
> found this wrapper something like 3-4 times faster than the scipy/numpy
> fftw implementations (running on a single core, I?ve never gotten the
> hyperthreading to work with any of the FFTW implementations).
>
> The package also has a interfaces module that lets you use the pyfftw
> fftws inside a an astropy.convolution function call. Here is a code snippet
> from my code:
>
> import pyfftw
> from astropy.convolution import convolve_fft
> fftn=pyfftw.interfaces.numpy_fft.fftn
> ifftn=pyfftw.interfaces.numpy_fft.ifftn
>
> def fftwn(*dat):
>         return fftn(*dat,threads=1)
>
> def ifftwn(*dat):
>         return ifftn(*dat,threads=1)
>
> def conv(ima,kernel):
>     return convolve_fft(ima,kernel,boundary='wrap',fftn=fftwn,ifftn=ifftwn)
>
> You may not need the fftwn and ifftwn functions, if I remember correctly I
> only created those to be able to test the hyperthreading.
>
> Good luck!
>
> Cheers,
> Jens
>
>
>
>
> > 24 jun 2016 kl. 17:17 skrev Bruno O. S?nchez <bruno.sanchez.63 at gmail.com
> >:
> >
> > Hello guys,
> >
> > I am an astronomer from C?rdoba Argentina, and I work a lot with
> astropy. I have been working on proper coaddition of images with spatially
> variant PSF, and I am currently using the convolution from astropy and
> scipy.
> >
> > I've encountered some perfomance issues, and noticed that there is some
> previous discussion on the settings of astropy.convolution.convolve fft
> engines.
> >
> > I wonder if any of you have succeded in setting a fftw3 engine for
> convolution, and if you have a snippet for using it. The fftw3 planning
> stage confuses me, and I can't find a documentation on pyfftw3.
> >
> > Any clues you can give me for this would be greatly appreciated!
> >
> > Bruno SANCHEZ
> > Observatorio Astron?mico de C?rdoba
> >
> >
> >
> > --
> > Bruno
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> -----------------------------------
> Jens Melinder
> Department of Astronomy
> Stockholm University
> jens at astro.su.se
> +46 706471856
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/astropy/attachments/20160624/df02cb70/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
> ------------------------------
>
> End of AstroPy Digest, Vol 117, Issue 10
> ****************************************
>
-- 
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160627/abc8f9bc/attachment.html>

From jakevdp at cs.washington.edu  Mon Jun 27 17:02:37 2016
From: jakevdp at cs.washington.edu (Jacob Vanderplas)
Date: Mon, 27 Jun 2016 14:02:37 -0700
Subject: [AstroPy] Lomb-Scargle False-alarm probability
In-Reply-To: <SN1PR0201MB1488386F1C70E268084D53F095210@SN1PR0201MB1488.namprd02.prod.outlook.com>
References: <SN1PR0201MB1488386F1C70E268084D53F095210@SN1PR0201MB1488.namprd02.prod.outlook.com>
Message-ID: <CACpqBg0dmooGL-cPDxZojUXU3xCd_mzOKEy3h_UX48fBbY8e+w@mail.gmail.com>

Hi ?lie,
There's no built-in code to compute the False Alarm Probability. I left
that out mainly because I don't trust the FAP as it's normally used in
Lomb-Scargle analyses. The simplest FAP (i.e. z-score) that often appears
in the literature is actually only applicable if you choose a frequency at
random. Once you ask for the FAP of the peak of the periodogram, the
assumptions behind the simple z-score are no longer met (it's essentially a
case of inadvertent p-hacking). This multiple-hypothesis issue is partially
addressed in, e.g. Baluev (2007), but even that analysis ignores the fact
that in practice, heights of different peaks are correlated in a
non-trivial way, related to the fingerprint the survey window leaves on the
periodogram. In the end, I don't believe there is any analytic expression
that captures correct FAPs the way astronomers would generally like to use
them. The only way I've encountered to do this robustly is via Monte
Carlo/bootstrap sampling; if you want ideas on that, we discuss it in
chapter 10 of our book (Ivezic 2014).
Hope that helps,
    Jake

 Jake VanderPlas
 Senior Data Science Fellow
 Director of Research in Physical Sciences
 University of Washington eScience Institute

On Mon, Jun 27, 2016 at 12:27 PM, ?lie Bouffard <
Elie.Bouffard at usherbrooke.ca> wrote:

> Hi everyone,
>
> I'm presently working with the newly included Lomb-Scargle periodogram in
> Astropy. It is very good, but I have a question. Is it possible to compute
> the false-alarm probability? If so, how exactly?
>
> Thanks!
>
> -?lie
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160627/d6d1ccaf/attachment.html>