Inconsistent ranges for cropped frequencies for 60s segments/0.25 Hz df
When attempting to use 60s segments with df = 0.25Hz in pygwb_pipe, I found that it failed with an error due to trying to multiply different sized vectors when calculating var_fs in calculate_point_estimate_sigma_spectra. The overlap reduction function frequencies and the spectrum frequencies differed by one. After some digging I believe I have tracked down the error, which was in baseline.crop_frequencies_average_psd_csd. The method used there to trim self.frequencies is different to the method used in gwpy.crop_frequencies, and it appears it can sometimes give a different frequency range, possibly due to rounding. My proposed fix is to use the same method as crop_frequencies, but of course there might be a more elegant way that just always uses crop_frequencies in some way (that would guarantee that they are always consistent at least).
Here is my proposed fix - replace this:
indexes = (self.frequencies >= flow) * (self.frequencies <= fhigh)
# reset frequencies
self.frequencies = self.frequencies[indexes]
with something like this:
# Use same calculation as in crop_frequencies so that we get consistent
# frequency ranges
idx0 = int(float(flow - self.frequencies[0]) // deltaF)
idx1 = int(float(fhigh + deltaF - self.frequencies[0]) // deltaF)
self.frequencies = self.frequencies[idx0:idx1]
Note the use of floor division // as in crop_frequencies, and it also adds the + deltaF as is done for the other crops within the function.
I have tested this for both 60s/0.25Hz and 192s/0.03125Hz and both appear to work. At the very least, it will ensure that the frequency cropping is consistent between pygwb and gwpy, although it might be preferable if it were use gwpy's crop_frequencies directly in some fashion.
I am happy to commit this change if the team approves - ok with you @arianna.renzini or @shivaraj.kandhasamy ?