Add BayesWaveCleanFrame pipe functionality

Closes #103 (closed)

Test cases:

• signal model + glitch model (separately)
• fullOnly

Example config file: fullOnly

Checkout the [bayeswave_clean_frame_options]

[bayeswave_clean_frame_options]
ifo='H1' #IFO which over which glitch cleaning needs to be done
clean-suffix='CLEAN_FRAME #suffix to add to the frame and channel names for the glitch-cleaned frames

and the path to the bayeswave_clean_frame path in the [engine] section.

All of the other options to BayesWaveCleanFrame are calculated in the pipe script.

The output frame gets written to trigtime_*/clean_frame

added bayeswave_pipe label

changed the description

WHy is the sampling rate hardcoded? That should be trivial to get from the config file or, ideally, from the input frame.

Using an existing DCC number for the default frame name is not a good plan. Please change that to something super obvious like YOUR_DCC_NUMBER_HERE or, ideally, make it a required input.

Just saw the structure of the pipe script and realized that the gw_data_find query gets run before the rest of dag produced is so your first point is very possible. I'll make the changes.

I was using the DCC number that @tyson-littenberg had hard-coded, and the code is at a stage where it will work the way he expects it to prior to my changes. I can make the changes to have a more generic default suffix or make it a required input. But I was wondering if @tyson-littenberg could weigh in on this.

The DCC number used will hopefully not change for O3b era stuff (the DCC document refers to the recipe behind deglitching, not any particular deglitched frame). My two cents that nobody asked for is that the current DCC number as default (i.e. you don't have to specify it in the config file) but have an option to user specify as well. Or is that too much of a hassle to implement?

@meg.millhouse thanks for the info, I hadn't realized the dcc number was for the recipe. In that case, the code does exactly what you mentioned anyway - you can specify clean-suffix in the config file which it will use, or you can leave it blank in which case it'll use the suffix T1700406_v4.

Certainly, if the people using this are happy with the hardcodings, no actual objection from me. Don't say i didn't warn y'all tho

I can put a large FIXME int the code and/or in the help output so that it is not forgotten.

added 1 commit

• 18e718c9 - Use lalframe to get input frame sampling rate and use that for glitch-cleaned frame

Compare with previous version

added 1 commit

• 557ab156 - Put caution message in help output and in the code about hard-coding the DCC number

Compare with previous version

added 1 commit

• af983e91 - Add link to the T1700406_v4 DCC entry which describes the glitch cleaning recipe

Compare with previous version

@james-clark the above 3 commits should address the comments from before.

1. I've used lalframe.frread to infer the input frame srate.
2. Put comments and output text that say FIXME about having the T1700406_v4 suffix as default.

mentioned in commit f3144e37

merged