Regarding tutorial 1.3, how do we know or gain intuition for which range of Q to use? I don’t quite understand why we used large values of Q for GW170817 and much smaller values for GW170814 in the Q-scan challenge
1 Like
Regarding tutorial 1.4, how would we know the best value of f_lower to use when working with get_td_waveform or get_fd_waveform? What exactly does it mean to indicate a starting GW frequency?
Hi, is there something wrong with this section of the tutorial 1.2?
I can’t open what is in that section but it says that there are 12 cells hidden
Should I ignore it?
While using q_transform function, we define a parameter known as qrange. I played around with that value and I see that the plots change drastically.
Question is I don’t know what is the physical meaning of this parameter. It would be helpful if someone can give me an idea about it or give me some reference to look into
Hi @Arun_KG! There are some cells hidden in your notebook. Click on the arrow on the left of “Handling” to show them
Hi @lua, this question have been answered in other topics, see e.g. Lecture Questions - Day 2 (2023) - #11 by simone-mastrogiovann . In general you can search for q transform in the upper part (magnification lens icon) to see all the discussions about it.
1 Like
Hi @lua, the point is that the detector is not really sensible at low frequencies (see PSD or ASD plots), that’s why we are not considering anything below 20 Hz.
1 Like
Hi @Tonzui, here is a reference: [gr-qc/0412119] Multiresolution techniques for the detection of gravitational-wave bursts
Hi @m.tagliazucchi, in general the power spectral density of a time series describes the power present in the time series as a function of frequency, per unit frequency. Since the strain that we detect is largely dominated by the noise, the PSD describe in practice the frequency distribution of the noise. For the purpose of the tutorial the interval of time you are considering is quite short, but in general, you are right, we tend to use long periods of time to calculate the PSD in order to reduce the fluctuations since you are “integrating” over a longer period.
1 Like
Hi, guys. I’m trying to locally run the tutorials on macOS Catalina. I’ve installed the igwn-py39-lw enviroment, followed all the steps carefully. Tutorial 1.2 runs fine up to the code ‘TimeSeries.fetch_open_data(‘L1’, int(gps)-512, int(gps)+512, cache=True, verbose=True)’, which hangs for a long time and then gives an error. The code works for a time segment of at most 30 seconds, i.e., if I put from -15 to +15. Longer times give an error. Does anybody know where the problem might be?
2 Likes
Hi @FabioNovaes , ±512 is very expensive computationally speaking, not 100% sure about this but maybe to remove cache=True could help (default is None TimeSeries - GWpy 3.0.1.dev133+geca77515 documentation)
1 Like
Hi, @virtuoso, thanks for the reply! Unfortunately, not using cache didn’t help. The code hangs even if I put from -16 to +16. Anything above a window of 30 seconds hangs. Maybe this is related to the different files it needs to download (32 seconds vs. 4096 seconds)? Anyway, this seems a very specific problem of my system, so I will post an issue at the gwpy github page to see if they can help me. I will continue the tutorials in Google Colab. Thank you!
@FabioNovaes That’s interesting!
I’m not sure what’s happening. But, you are right that the fetch_open_data command decides if it will download a 32 second file or a 4096 second file, with no choices in-between. Maybe the code is encountering either memory limits or band-width limits of your set-up?
In any case, an option is to try using NDS2 instead to access data. Instructions are linked below. For example, for O3 data, you could request channel names like L1:DCS-CALIB_STRAIN_CLEAN_SUB60HZ_C01_AR
chan = L1:DCS-CALIB_STRAIN_CLEAN_SUB60HZ_C01_AR
from gwpy.timeseries import TimeSeries
data = TimeSeries.fetch(chan, start=1240559616, end=1240559626, host='losc-nds.ligo.org')
1 Like
Thanks, @jonah, that worked for a time larger than 30 seconds! You’re probably right, it is either memory or bandwith limits. The 1024 window gives an error “timeout: The read operation timed out”. However, I have a 1TB SSD, 12 GB RAM and a 200 Mbps internet connection. So, it’s quite strange. I’m doing some tests to try to figure it out what’s the issue. Thank you for the help!
from gwosc.datasets import event_gps
from gwpy.timeseries import TimeSeries
gps=event_gps('GW170814')
detectors=['L1','H1','V1']
for place in detectors:
ldata=TimeSeries.fetch_open_data(place, int(gps)-512, int(gps)+512,cache=True)
lq=ldata.q_transform(frange=(30,500),qrange=(4,12),outseg=(gps-0.1,gps+0.1))
lq=lq**0.5
plot=lq.plot()
ax=plot.gca()
ax.set_epoch(gps)
ax.set_yscale('log')
This was my code for Tutorial 1.4. There are certain white patches on my plot that look like this:
What is the explanation for this?
Hi @AmbicaG , really strange plot, the only thing I suspect is that some spectrogram values could be out of range or (more likely) invalid numbers, can you try to plot the power spectrogram only, i.e. without doing lq=lq^0.5? Or also, can you check something like numpy.isnan(lq).any() and also numpy.isnan(lq^0.5).any()?
1 Like
Hi, Jonah,
I couldn’t figure it out what’s the problem with TimeSeries.fetch_open_data. I’m not having the “read timeout error” as before. However, the 512 sec window data takes around 28 minutes to download, too long for files with at most 0.4 GB in my internet connection, but okay. I’ve just considered it a fact of life and moved on.
Now, in tutorial 1.4, when I use the igwn-py39 kernel, I only get the following waveforms:
Time domain waveforms: ['TaylorF2NL', 'PreTaylorF2', 'SpinTaylorF2_SWAPPER']
Frequency domain waveforms: ['SpinTaylorF2_SWAPPER', 'TaylorF2NL', 'PreTaylorF2', 'multiband', 'TaylorF2NL_INTERP', 'PreTaylorF2_INTERP', 'SpinTaylorF2_SWAPPER_INTERP']
However, using the igwn-py39-lw kernel, it loads all waveforms. It might be some kind of problem of my (old) Mac OS system with the packages listed in the full environment. I believe this is related to the lalsuite package. I noticed that the lightweight enviroment file has lalsuite=7.11, while the full env file has lalsuite=7.15=pyhd8ed1ab_0. This can be found out using conda compare enviroment.yml with the full environment active. The pip package is also a mismatch, but I don’t think it should be a problem. For the moment, the lightweight enviroment is working for me. I’m just reporting for you guys to check for the consistency of the enviroment files.
Thank you! I’m not sure why that’s happening, but I appreciate you letting us know.
@AmbicaG @virtuoso This is because some data in ‘’‘lq=ldata.q_transform’‘’ are negative. So when you do the square root of a negative it counts as a NAN (not a number) and is represented by the white area in the plot. To solve this problem one needs to square root lq’s absolute value instead of square rooting them directly. Use ‘‘lq=lq.abs()**0.5’’’ to do it. One can also plot the power spectrogram only without doing lq^0.5 as lq has no NAN value. Thanks.