Brute Force coherence report is available here for last night lock:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1115716006/
Some highlights, which I find very interesting:
- What's going on with CARM, why is there coherence of basically 1 below 20 Hz? (fig. 1)
- There is coherence at the same peaks, and a bit at all frequencies with AS_A_DC_SUM: is it intensity noise? (fig. 2) This seems to be confirmed by the coherence with IM4_TRANS and ISS signals (fig. 6)
- SRCL is still a good channel to have coherence below 80 Hz. (fig. 3)
- AS_A_RF_45_Q_PIT has large coherence below 20-30 Hz, maybe we are limited by angular noise? Do we need a better balacing or centering of the ETMs? (fig. 4)
- At 17 Hz there is a small bump/line that is coherent with HPI-HAM1_BLND_L4C_HP_IN1 (fig. 5)
- Coherence with the PSL periscope is much smaller than in the past (fig. 7). However, there is still some significant coherence with IMC WFS at 200-400 Hz (fig. 8), so we're probably still suffering of some contamination due to beam jitter
Not much is happening at higher frequency, at least for broad band coherence. However there are a lot of single frequency bins with significant coherence, and I can't list all of them here (I'm too lazy). So look into the table at your favorite line frequency, you might be rewarded with some coherence.
After the time that Gabriele looked at, the coherence of CARM with DARM went up to nearly 1 above 500 Hz (and 0.5 at 100 Hz). This seemed to continue for the rest of the lock. All of the loudest glitches, which had peak frequencies at about 200 Hz, showed up in CARM as well as DARM. What is going on? The first plot is a reproduction of Gabriele's coherence plot. The second is about a half hour later, and the third near the end of the lock. The last is a coherence spectrogram of CARM with DARM during this very loud glitch near the end of the lock, which showed up as strong in CARM as DARM.
LSC-CARM is not used anymore for any feedback to the IFO; we use it sometimes to make an audio channel out of DARM so that we can listen to the IFO. Stefan was tuning the audio filters after we hit the intent bit last night.
The actual feedback to MC2 from the CARM slow loop goes through the LSC-MCL filter bank. If you want an out of loop CARM sensor you can look at LSC-REFL_A_9I, for the error and control signals you can look at the common mode board channels, eg LSC-REFL_SERVO_ERR_DQ or CTRL_DQ
By the way, instead of stealing the CARM filter bank to process audio, you can apply the filter directly in the audio player:
$ cdsutils audio H1:CHANNEL-NAME -f 'filterspec'
where 'filterspec' is a filter design string, as you would type into Foton. (This was requested in CDS bug 797 and added in cdsutils r444.)
It seems unneccesarily confusing to use a named channel with a very clear symantic meaning for something other than it's intended purpose. Can we not just make some separate filter banks just for filtering audio output? Either that or use the built-in cdsutils audio filtering that Chris mentioned.