gwastro / PyCBC-Tutorials

Learn how to use PyCBC to analyze gravitational-wave data and do parameter inference.
116 stars 49 forks source link

Files including read_frame() do not work #5

Closed kderakhshani closed 4 years ago

kderakhshani commented 4 years ago

All PyCBC-Tutorial files that include read_frame() do NOT work, with such an error:

File "/home/master/miniconda3/envs/py27/lib/python2.7/site-packages/pycbc/frame/frame.py", line 135, in locations_to_cache cache = lalframe.FrOpen(str(dir_name), str(file_name)).cache

RuntimeError: RETURN: untrapped XLAL error

My system: Ubuntu 14.04 LTS Python 2.7 (under Spyder in miniconda3) PyCBC 1.14.4 LALFrame 1.4.5

Thank you.

ahnitz commented 4 years ago

@kderakhshani Which cell actually failed and in which notebook? In the first tutorial, were you able to run the first cell in section 1.2 (which should have also made a plot) ?

If that worked, the frame library is successfully reading frame files with the same code. That would point to an issue with how your system is downloading the frame file. There should be a file produced by this command

curl -O -J -L https://losc.ligo.org/s/events/LVT151012/H-H1_LOSC_4_V2-1128678884-32.gwf

Can you check the md5sum hash? Does it agree with -> 280ee72b0e4850b81747e72ec9c49acd H-H1_LOSC_4_V2-1128678884-32.gwf

kderakhshani commented 4 years ago

@ahnitz Dear Alex, Thank you for your fast reply. The following notebooks result in error when they reach to read_frame() function: gw150914_audio.ipynb gw170817_mass_estimate.ipynb 1_CatalogData.ipynb 2_VisualizationSignalProcessing.ipynb

The first one outputs the error: File "/home/master/miniconda3/envs/py27/lib/python2.7/site-packages/pycbc/frame/frame.py", line 194, in read_frame stream = lalframe.FrStreamCacheOpen(cum_cache) RuntimeError: Internal function call failed: Invalid argument right after execution of the third (last) cell. The other three files report the error mentioned in my previous msg.

For example, gw170817_mass_estimate.ipynb comes up with that error when the third cell is run. To localize the reason, I ran the file line by line, in the editor of Spyder. The error emerges exactly when I ran this line:
ts = read_frame("{}-{}_LOSC_CLN_4_V1-1187007040-2048.gwf".format(ifo[0], ifo), '{}:LOSC-STRAIN'.format(ifo), start_time=merger.time - 224, end_time=merger.time + 32, check_integrity=False)

To ensure that the read_frame() function is the culprit, I ran the following little script: from pycbc.frame import read_frame fname = 'H-H1_LOSC_4_V1-1126256640-4096.gwf' ts = read_frame(fname, 'H1:LOSC-STRAIN') (with the .gwf file in the same directory) with exactly the same error. So the problem should be something somewhere in the lalframe.

In the first tutorial, were you able to run the first cell in section 1.2 (which should have also made a plot) > ?

Yes, and I do have the plot. However, in the next cell when the line: ts = query_and_read_frame('LOSC', 'H1:LOSC-STRAIN', start, end) is executed the same error comes out. As you know, this function calls read_frame() to read the downloaded .gwf file. Also in the last cell (when I ran it independently), again I have the same (RuntimeError: RETURN: untrapped XLAL error) error.

Can you check the md5sum hash? Does it agree with -> 280ee72b0e4850b81747e72ec9c49acd H-H1_LOSC_4_V2-1128678884-32.gwf

I checked the hash value of H-H1_LOSC_4_V2-1128678884-32.gwf in Ubuntu: $ md5sum H-H1_LOSC_4_V2-1128678884-32.gwf 280ee72b0e4850b81747e72ec9c49acd H-H1_LOSC_4_V2-1128678884-32.gwf

Sorry for the lengthy msg.

Kamran

kderakhshani commented 4 years ago

Today, I found that I had saved the data gwf file (to be read by lalframe) in a folder whose name(PyCBC 1.14.1) included a blank! When I changed it to PyCBC_1.14.1, the problem was fixed! And now, all notebooks (of the PyCBC Tutorials) that include _pycbc.frame.readframe() work fine. The moral (for beginners like me): Do NOT use blanks in names of folders and files! Apologies for any inconvenience it caused. @ahnitz You may want to consider it for future versions of PyCBC.

ahnitz commented 4 years ago

@kderakhshani Oh, wow! Thanks for figuring that out. I may need to report that upstream. My guess is that it's an issue in the frame library handling of file paths.