bayeswave issueshttps://git.ligo.org/lscsoft/bayeswave/-/issues2023-08-10T21:32:25Zhttps://git.ligo.org/lscsoft/bayeswave/-/issues/141Print out more frequency digits2023-08-10T21:32:25ZCarl-Johan HasterPrint out more frequency digitsIn the PSDs saved to file (for example in `glitch_median_PSD_forLI_L1.dat`) the current string format of `%g` isn't sufficient to print out the actual frequency series for long-duration PSDs. For example, for a 512s PSD I made the file s...In the PSDs saved to file (for example in `glitch_median_PSD_forLI_L1.dat`) the current string format of `%g` isn't sufficient to print out the actual frequency series for long-duration PSDs. For example, for a 512s PSD I made the file starts with
```
0 0.00390625
0.00195312 0.00390625
0.00390625 0.00390625
0.00585938 0.00390625
0.0078125 0.00390625
0.00976562 0.00390625
0.0117188 0.00390625
0.0136719 0.00390625
```
which almost good enough (the first entry is missing the last `5` in `0.001953125` for it to be an actual `deltaF=1/512`.
At the end of the file though it reads
```
1023.97 6.07368e-48
1023.97 5.99066e-48
1023.97 5.90889e-48
1023.97 5.82836e-48
1023.97 5.74905e-48
1023.98 5.67092e-48
1023.98 5.59397e-48
1023.98 5.51817e-48
1023.98 5.4435e-48
1023.98 5.36994e-48
1023.99 5.29748e-48
1023.99 5.22609e-48
1023.99 5.15576e-48
1023.99 5.08646e-48
1023.99 5.01819e-48
```
where clearly the saved frequencies have been rounded down to something not super relevant...
Fortunately, just defaulting to saving a (significantly) larger number of digits past the decimal point should be enough, or switching to `%e` formatting instead of `%g`, but I think that you'd need to increase the number of significant digits anyways.https://git.ligo.org/lscsoft/bayeswave/-/issues/139The value of PSD corresponding to the f_max is infinite2023-07-21T15:49:56ZNarola BharatbhaiThe value of PSD corresponding to the f_max is infiniteI have noticed the following issue when running the Bayeswave version v1.1.0.
The value of the PSD reported in the glitch_median_PSD_forLI_L1.dat becomes inf for the f_max. This causes the rest of the jobs to fail.
- 1022.75 7.84294...I have noticed the following issue when running the Bayeswave version v1.1.0.
The value of the PSD reported in the glitch_median_PSD_forLI_L1.dat becomes inf for the f_max. This causes the rest of the jobs to fail.
- 1022.75 7.84294e-47
- 1023 1.50881e-46
- 1023.25 2.08989e-45
- 1023.5 3.95747e-46
- 1023.75 inf
It happens only for the L1 PSD. For the rest of the detectors, the jobs run successfully. It doesn't happen for all events, only for some of the events from O3b (S191204r for example), which I have analyzed.
The bug disappears if I increase the sampling frequency to 4096 Hz from 2048 Hz.
The run directory with the bug is here: `LHO:/home/narola.bharatbhai/echoes_O4/trial_runs/foreground/bw_utils_main_run/S191204r`
The run directory without bug (high sampling frequency):`LHO:/home/narola.bharatbhai/echoes_O4/trial_runs/foreground/bw_utils_main_run/dw_config_S191204/`
For context, this was discovered when I was reviewing the Unmodelled Echoes pipeline for O4.
The bug appears even when I turn off the Echoes modifications.https://git.ligo.org/lscsoft/bayeswave/-/issues/134Error in evidence estimation in stdout2023-02-17T22:14:44ZMeg MillhouseError in evidence estimation in stdoutIn the error bars on the evidence estimation printed to stdout are sometimes nan. Doesn't appear in the actual evidence files so I think it's just stdout thing -- not urgent but putting this here so we rememberIn the error bars on the evidence estimation printed to stdout are sometimes nan. Doesn't appear in the actual evidence files so I think it's just stdout thing -- not urgent but putting this here so we rememberhttps://git.ligo.org/lscsoft/bayeswave/-/issues/128Zero amplitude wavelets2022-10-26T16:23:08ZMeg MillhouseZero amplitude waveletsIn `--fullOnly` runs, signal param chains are occasionally printing wavelet amplitudes that are out of the prior range -- specifically an amplitude of `0` which causes issues with BWPost and megaplot.In `--fullOnly` runs, signal param chains are occasionally printing wavelet amplitudes that are out of the prior range -- specifically an amplitude of `0` which causes issues with BWPost and megaplot.https://git.ligo.org/lscsoft/bayeswave/-/issues/127Use absolute paths for executables in condor submit files2022-09-27T13:38:41ZDuncan Macleodduncan.macleod@ligo.orgUse absolute paths for executables in condor submit filesWhen @sophie.hourihane posted https://git.ligo.org/computing/sccb/-/issues/993#note_593814 that lead me to [bayeswave.sub](https://ldas-jobs.ligo.caltech.edu/~sophie.hourihane/BAYESWAVE_REVIEW/IGWN_TESTING/GW150914_default/bayeswave.sub)...When @sophie.hourihane posted https://git.ligo.org/computing/sccb/-/issues/993#note_593814 that lead me to [bayeswave.sub](https://ldas-jobs.ligo.caltech.edu/~sophie.hourihane/BAYESWAVE_REVIEW/IGWN_TESTING/GW150914_default/bayeswave.sub) which starts:
```ini
universe = vanilla
executable = BayesWave
```
@james-clark would it be an improvement to use the absolute paths of executables in condor submit? This should mean that the execute environment is slightly less implicitly dependent on the submission environment.https://git.ligo.org/lscsoft/bayeswave/-/issues/126Fix plot grids in megaplot2022-09-16T20:30:51ZMeg MillhouseFix plot grids in megaplotSomehow all of the plots that used to have grid lines no longer do, and all of the plots that didn't originally have gridlines do now.Somehow all of the plots that used to have grid lines no longer do, and all of the plots that didn't originally have gridlines do now.https://git.ligo.org/lscsoft/bayeswave/-/issues/125BayesWaveUtils Python metadata is (nearly) empty2022-09-12T15:57:20ZDuncan Macleodduncan.macleod@ligo.orgBayesWaveUtils Python metadata is (nearly) emptyThe metadata for the installed BayesWaveUtils Python package is basically empty:
```console
$ python -m pip show BayesWaveUtils
Name: BayesWaveUtils
Version: 0.1.dev0
Summary: UNKNOWN
Home-page:
Author:
Author-email:
License: GPL
Locati...The metadata for the installed BayesWaveUtils Python package is basically empty:
```console
$ python -m pip show BayesWaveUtils
Name: BayesWaveUtils
Version: 0.1.dev0
Summary: UNKNOWN
Home-page:
Author:
Author-email:
License: GPL
Location: /home/duncan/opt/mambaforge/envs/py310/lib/python3.10/site-packages
Requires:
Required-by:
```
The `Version` at least should match what is in the top-level `CMakeLists.txt` file.https://git.ligo.org/lscsoft/bayeswave/-/issues/124BayesWaveUtils doesn't declare any dependencies2022-09-12T15:47:07ZDuncan Macleodduncan.macleod@ligo.orgBayesWaveUtils doesn't declare any dependenciesThe `BayesWaveUtils/setup.py` file doesn't include any statement of `install_requires` to encode its Python dependencies. Ideally it would include every third-party package that is required (that is also available from pypi.org). This wo...The `BayesWaveUtils/setup.py` file doesn't include any statement of `install_requires` to encode its Python dependencies. Ideally it would include every third-party package that is required (that is also available from pypi.org). This would be something like:
- astropy
- gwpy
- healpy
- lalsuite
- ligo-gracedb
- ligo.segments
- matplotlib
- numpy
- scipy
- setuptoolshttps://git.ligo.org/lscsoft/bayeswave/-/issues/122Specifying --inj-fref != 100 creates non-coherent posteriors2022-06-07T02:02:18ZSophie HourihaneSpecifying --inj-fref != 100 creates non-coherent posteriors
When we specify `--inj-fref = 20` our posteriors look like this:
![image](/uploads/8c11129b994ac126d0fd2b5a53e308df/image.png)
When we do not specify `--inj-fref` (or set `--inj-fref 100` as is the default) our posteriors look like t...
When we specify `--inj-fref = 20` our posteriors look like this:
![image](/uploads/8c11129b994ac126d0fd2b5a53e308df/image.png)
When we do not specify `--inj-fref` (or set `--inj-fref 100` as is the default) our posteriors look like this
![image](/uploads/2d0795432dc9925e68da5fc9a1382c1c/image.png)
See runs:
inj-fref 20: [`/home/sophie.hourihane/public_html/glitch_events/realEvent/GW200129/GW200129_injections_cbctriglist_nosmartrestart_IMR/`](https://ldas-jobs.ligo.caltech.edu/~sophie.hourihane/glitch_events/realEvent/GW200129/GW200129_injections_cbctriglist_nosmartrestart_IMR/trigtime_1264316116.417596102_0.0_0.0_0/)
inj-fref 100: [`/home/sophie.hourihane/public_html/glitch_events/realEvent/GW200129/GW200129_injections_injfref100/trigtime_1264316116.417596102_0.0_0.0_0/`](https://ldas-jobs.ligo.caltech.edu/~sophie.hourihane/glitch_events/realEvent/GW200129/GW200129_injections_injfref100/trigtime_1264316116.417596102_0.0_0.0_0/)
The only difference between their configs is the number of iterations and `--inj-fref`
```
[sophie.hourihane@ldas-pcdev1 ~]$ diff /home/sophie.hourihane/public_html/glitch_events/realEvent/GW200129/GW200129_injections_cbctriglist_nosmartrestart_IMR/config.ini /home/sophie.hourihane/public_html/glitch_events/realEvent/GW200129/GW200129_injections_injfref100/config.ini
80c80
< Niter=4000000
---
> Niter=1000000
82c82
< inj-fref=20
---
> inj-fref=100
```Katerina ChatziioannouSophie HourihaneKaterina Chatziioannouhttps://git.ligo.org/lscsoft/bayeswave/-/issues/118megaplot.py incompatible with setuptools >= v58.32022-03-15T00:36:21ZNikolaos Stergioulasmegaplot.py incompatible with setuptools >= v58.3In the installation process, the easy_install command (for installed python eggs) was removed in
setuptools v58.3 (year 2021), so eggs can no longer be used after this version. In my installation, I had to downgrade to setuptools==57 fo...In the installation process, the easy_install command (for installed python eggs) was removed in
setuptools v58.3 (year 2021), so eggs can no longer be used after this version. In my installation, I had to downgrade to setuptools==57 for the installation of megaplot.py to work. I guess that python eggs will need to be replaced by e.g. pip, so that bayeswave will not remain bound to setuptools<=57.https://git.ligo.org/lscsoft/bayeswave/-/issues/116Glitch model does not recover prior when --noWaveletPrior is on for srate != ...2022-02-16T04:14:38ZSophie HourihaneGlitch model does not recover prior when --noWaveletPrior is on for srate != 2048When running with `--noWaveletPrior` we do not recover the flat prior in glitch dimension. This issue becomes more noticeable when runs have higher dimensions and when runs have a sampling rate that is not 2048.
Note: These runs were c...When running with `--noWaveletPrior` we do not recover the flat prior in glitch dimension. This issue becomes more noticeable when runs have higher dimensions and when runs have a sampling rate that is not 2048.
Note: These runs were completed without BayesLine, without pointing towards an actual PSD. This means that the PSDs used for these runs look like:
![image](/uploads/530211f2132c8c99cd7520e8f1caa47b/image.png)
## For N = 6
This issue is not immediately obvious. The grey bars are the 1, 2, and 3stdev markers assuming Poisson error in each bin.
```
expected count = N_samples / (Dmax + 1) # +1 since we can have 0 wavelets
stdev = np.sqrt(expected_count)
```
![image](/uploads/bec974f62fec43167471a2b524cdda15/image.png)
My run
We see that there is definitely more of a slope with srate = 4096, but it does not look too concerning.
<details><summary>Run settings</summary>
`Dmax6_srate2048`
```
Command line: --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 6 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 1024.0 --seglen 4 --window 1 --prior --noWaveletPrior
```
`Dmax6_srate4096`
```
Command line: --H1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_H1.cache --H1-channel H1:GWOSC-4KHZ_R1_STRAIN --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 6 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 4096 --seglen 4 --window 1 --prior --noWaveletPrior
```
</details>
## For N = 40
I then attempted to see if it was perhaps an issue with the --clusterWeight, so I tried with both 0 and 1: Again, 2048 is the only sampling rate that remains within a reasonable range for the entirety. (Although `40_srate1024_noCluster` is almost close)
![image](/uploads/1659e469b25a252f2caabf248e60bf5c/image.png)
<details><summary>Run settings N = 40</summary>
`40_srate4096_clusterweight0`
```
Command line: --H1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_H1.cache --H1-channel H1:GWOSC-4KHZ_R1_STRAIN --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 4096 --seglen 4 --window 1 --prior --noWaveletPrior --clusterWeight 0
```
`40_srate4096_clusterweight1`
```
Command line: --H1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_H1.cache --H1-channel H1:GWOSC-4KHZ_R1_STRAIN --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 4096 --seglen 4 --window 1 --prior --noWaveletPrior --clusterWeight 1
```
`40_srate2048_clusterweight1`
```
Command line: --H1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_H1.cache --H1-channel H1:GWOSC-4KHZ_R1_STRAIN --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 2048 --seglen 4 --window 1 --prior --noWaveletPrior --clusterWeight 1
```
`40_srate1024_nocluster`
```
Command line: --H1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_H1.cache --H1-channel H1:GWOSC-4KHZ_R1_STRAIN --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --psdlength 4 --noClean --glitchOnly --Dmax 40 --noClusterProposal --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 1024 --seglen 4 --window 1 --prior --noWaveletPrior
```
</details>
## N = 40 on Simulated data
I then tried to see if perhaps the fact that I am using very ugly PSDs (autogenerated by BW) was perhaps affecting the runs. So I tried running with simulated data, and the results were quite nice:
(No fisher no cluster is referencing that I went into the code and manually turned off these samplers, and is so not reflected in the run settings below)
![image](/uploads/200271f81f7772409d5b50f167501edf/image.png)
<details><summary>Run Settings N = 40 Simulated</summary>
## N = 40 with fixed PSDs
```
Command line: --ifo L1 --L1-cache LALSimAdLIGO --L1-channel LALSimAdLIGO --dataseed 1234 --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 4096 --seglen 4 --window 1 --prior --noWaveletPrior
```
`40_srate_4096_simulate`
```
Command line: --ifo L1 --L1-cache LALSimAdLIGO --L1-channel LALSimAdLIGO --dataseed 1234 --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --srate 4096 --seglen 4 --window 1 --prior --noWaveletPrior
```
</details>
## N = 40, fixed PSD
I then came to the conclusion that this nasty PSD was the issue. However, running on the same data as before except this time using a fixed PSD, I got these results:
![image](/uploads/e8f8ab79856557f52df0c0fdddddef88/image.png)
![image](/uploads/4fd65287de15a3536a9f1ef4af19ffef/image.png)
The 4096 result obviously being troubling. This is as far as I have been able to get on this issue. I would point to runs but I have been doing them all locally for speed / convenience.
<details><summary> Run Settings N = 40, fixed PSD </summary>
`40_srate_2048_withPSD`
```
Command line: --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --L1-psd /Users/sophie/LIGO/DEBUG/glitch_model/psds/psd_2048.dat --srate 2048 --dataseed 1234 --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --seglen 4 --window 1 --noWaveletPrior --prior
```
`40_srate_4096_withPSD`
```
Command line: --ifo L1 --L1-cache /Users/sophie/LIGO/glitch_events/Frames/Blip2_L1.cache --L1-channel L1:GWOSC-4KHZ_R1_STRAIN --L1-psd /Users/sophie/LIGO/DEBUG/glitch_model/psds/psd_4096.dat --srate 4096 --dataseed 1234 --psdlength 4 --noClean --glitchOnly --Dmax 40 --Nchain 5 --Niter 4000000 --trigtime 1165578635.450000048 --segment-start 1165578633.450000048 --psdstart 1165578638.450000048 --seglen 4 --window 1 --noWaveletPrior --prior
```
</details>James Alexander Clark PhDTyson LittenbergMeg MillhouseKaterina ChatziioannouSophie HourihaneJames Alexander Clark PhDhttps://git.ligo.org/lscsoft/bayeswave/-/issues/114BayesWave gives different results for the same data with same seed2021-10-23T18:08:44ZSudarshan GhongeBayesWave gives different results for the same data with same seedWhen run on the same data, BayesWave converges to different results. For example: all of [these](https://ldas-jobs.ligo.caltech.edu/~sudarshan.ghonge/Projects/glitchClean/for_Jessica_E/blip/blip-glitch-2-diffseed/) runs have the same dat...When run on the same data, BayesWave converges to different results. For example: all of [these](https://ldas-jobs.ligo.caltech.edu/~sudarshan.ghonge/Projects/glitchClean/for_Jessica_E/blip/blip-glitch-2-diffseed/) runs have the same data. The chain seed (`--chainseed`) is not set so it defaults to `1234`. Going by this, all the results should look the same but they don't. This suggests there's some place in the code that a seed is set that is not in the control of the user.
Note that there is a `--dataseed` cmd option but that seems to only affect simulated data generation, which for this case is needed after Sophie's recent merge that makes the dataread operation skip the frame read to avoid the signal 255 crashes. Basically, `--dataseed` shouldn't affect the result in this case.https://git.ligo.org/lscsoft/bayeswave/-/issues/113Supply BayesWave with a dataseed regardless of whether there is simulated dat...2021-09-23T15:30:11ZSudarshan GhongeSupply BayesWave with a dataseed regardless of whether there is simulated data or not.Regardless of the type of data (real frames or simulated), BW generates a simulated datastream during its setup (it makes a sim data stream during the checkpoint resume step of real data runs). LAL complains if dataseed isn't provided wh...Regardless of the type of data (real frames or simulated), BW generates a simulated datastream during its setup (it makes a sim data stream during the checkpoint resume step of real data runs). LAL complains if dataseed isn't provided when generating simulated data: https://git.ligo.org/lscsoft/lalsuite/-/blob/master/lalinference/lib/LALInferenceReadData.c#L829
bayeswave_pipe needs to set up BW jobs such that dataseed is always passed as an argument.https://git.ligo.org/lscsoft/bayeswave/-/issues/109Typo in Q-q in BWPost2021-03-01T19:08:53ZSophie HourihaneTypo in Q-q in BWPostIn anderson_darling_test in BayesWavePost, the section that makes `MODELNAME_residual_P-p_IFO.dat`, 'samples' is being indexed from [0, Nsamp), but samples holds complex data (of length 2 * Nsamp) where the even numbers index the reals, ...In anderson_darling_test in BayesWavePost, the section that makes `MODELNAME_residual_P-p_IFO.dat`, 'samples' is being indexed from [0, Nsamp), but samples holds complex data (of length 2 * Nsamp) where the even numbers index the reals, and odds the imaginary. gsl_cdf_ugaussian_P(samples[n]) is thus making a unit gaussian cdf of some mixture of the 1st half of the real and imaginary FFT data, which I do not believe is meant. Link to problem line here:
[Link to problem line](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWavePost.c#L3500)Tyson LittenbergKaterina ChatziioannouTyson Littenberghttps://git.ligo.org/lscsoft/bayeswave/-/issues/107Make additional checks before deciding run uses simulated data upon seeing '0...2020-12-17T18:46:35ZSudarshan GhongeMake additional checks before deciding run uses simulated data upon seeing '0noise'When bayeswave_pipe sees a `0noise` option in `[bayeswave_options]`, it automatically sets the `sim-data` flag. This can sometimes lead to problems where the intention was to run on frames but the `0noise` option was accidentally left in...When bayeswave_pipe sees a `0noise` option in `[bayeswave_options]`, it automatically sets the `sim-data` flag. This can sometimes lead to problems where the intention was to run on frames but the `0noise` option was accidentally left in. Need to make an additional check, perhaps of the frame-type and channel-type before deciding the run is indeed `sim-data`Sudarshan GhongeSudarshan Ghongehttps://git.ligo.org/lscsoft/bayeswave/-/issues/106Pipeline Virgo time slide datafind issue2020-12-10T19:45:37ZBence BecsyPipeline Virgo time slide datafind issueIt looks like the datafind call from the pipeline sometimes misses to take time slides properly into account when Virgo is involved. This results in frame read errors.
For example, in a run I've seen the following time slide:
`Slid PSD ...It looks like the datafind call from the pipeline sometimes misses to take time slides properly into account when Virgo is involved. This results in frame read errors.
For example, in a run I've seen the following time slide:
`Slid PSD estimation of V1 by -188717.000000 s from 1257292021.2765998840 to 1257103304.2765998840`
And the Virgo datafind call was this:
`gw_data_find --observatory V --type V1Online -s 1257177929 -e 1269349198 --lal-cache -u file > datafind/V1.cache`
So the start time of datafind is later than the new time where Virgo was shifted to.
One example run is in this batch on CIT: `/home/bence.becsy/O3/offline_bg/LV/O3b/clean_bin_60Hzsub_v1.0.6/bin2_a/`
The one that failed with this error is this one: `/home/bence.becsy/O3/offline_bg/LV/O3b/clean_bin_60Hzsub_v1.0.6/bin2_a/trigtime_1257292023.276599884_0.0_0.0_357/`
The corresponding err file with time slide info and frame read error is here: `/home/bence.becsy/O3/offline_bg/LV/O3b/clean_bin_60Hzsub_v1.0.6/bin2_a/logs/BayesWave_trigtime_1257292023.276599884_0.0_0.0_357-63438825-0.err`
I was able to get these runs done by rerunning datafind by hand, but it would be good to fix this in the pipeline.
Maybe @meg.millhouse can add something to this, as I think she was the one to code up Virgo time slides.https://git.ligo.org/lscsoft/bayeswave/-/issues/104Use fhigh option to limit bandwidth2020-10-26T14:58:54ZColm Talbotcolm.talbot@ligo.orgUse fhigh option to limit bandwidthI recently learned that `BayesWave` doesn't use the `fhigh` option available through `LALInferenceReadData` to reduce the number of frequency bins that need to be iterated over.
The parameter is used in a few places, e.g., [here](https:...I recently learned that `BayesWave` doesn't use the `fhigh` option available through `LALInferenceReadData` to reduce the number of frequency bins that need to be iterated over.
The parameter is used in a few places, e.g., [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWave.c#L176), [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWave.c#L189), and most importantly in the [likelihood](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWaveLikelihood.c#L855).
There are a bunch of other places where for loops are run directly over the whole frequency range which slow things down when using a higher sampling rate for the same maximum frequency. I've started testing out a branch where the content above fmax is ignored and the speedups look promising.
Is there general interest in adding this functionality? And if so, where is best place to get tips on running a custom install on LDG clusters?
cc @tyson-littenberghttps://git.ligo.org/lscsoft/bayeswave/-/issues/99snr.dat file for BW internal injections2020-09-01T04:10:17ZMeg Millhousesnr.dat file for BW internal injectionsWhen doing internal injections with the signal model, the `snr.dat` file prints: max(H1_SNR,L1_SNR), network_SNR. (see [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWaveIO.c#L438)).
Is it ok to change this to prin...When doing internal injections with the signal model, the `snr.dat` file prints: max(H1_SNR,L1_SNR), network_SNR. (see [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/src/BayesWaveIO.c#L438)).
Is it ok to change this to print the SNR of all detectors (and network SNR maybe)? Or would this mess up all your review script stuff @tyson-littenberghttps://git.ligo.org/lscsoft/bayeswave/-/issues/98Bug in reading in BW internal injections from glitch model2021-03-04T00:14:05ZMeg MillhouseBug in reading in BW internal injections from glitch modelWhen doing a BW internal injection using the glitch model (i.e. BW reads in a glitch model chain), bw_pipe tries to read in a old filename format. The `glitch_params_ifo0.dat.0` [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master...When doing a BW internal injection using the glitch model (i.e. BW reads in a glitch model chain), bw_pipe tries to read in a old filename format. The `glitch_params_ifo0.dat.0` [here](https://git.ligo.org/lscsoft/bayeswave/-/blob/master/BayesWaveUtils/bayeswave_pipe/bayeswave_pipe_utils.py#L521) should be `glitch_params_H1.dat.0` (or H1->L1/V1).James Alexander Clark PhDJames Alexander Clark PhDhttps://git.ligo.org/lscsoft/bayeswave/-/issues/97Override datafind server for OSG jobs2020-08-13T15:56:04ZJames Alexander Clark PhDOverride datafind server for OSG jobs`bayeswave_pipe` has a hardcoded datafind server (`datafind.ligo.org:443`) whenever the `--osg-deploy` flag is issued. Make this optional.
For that matter, the `--osg-deploy` option should probably be deprecated or just cause the dataf...`bayeswave_pipe` has a hardcoded datafind server (`datafind.ligo.org:443`) whenever the `--osg-deploy` flag is issued. Make this optional.
For that matter, the `--osg-deploy` option should probably be deprecated or just cause the datafind server to default to the one above: there aren't really any functional differences in the submit files any more.James Alexander Clark PhDJames Alexander Clark PhD