jeffrey.kissel@LIGO.ORG - posted 11:41, Thursday 30 March 2023 - last comment - 12:12, Thursday 04 May 2023(68289)
Calibration Line Changes -- 15-17 Hz Heights Reduced by 3x to 4x; Changed frequency of 56.39 Hz line to 53.67 Hz
J. Kissel As a result of our improved sensitivity below 30 Hz since O3, and recently exposed deleterious bi-linear coupling between these calibration lines and excess QUAD reaction chain motion at 3.4 Hz (LHO:68003), I've reduced the amplitude of the 15-17 Hz calibration lines. Channel that defines the amplitude Former Now Reduction Factor H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN 75.0 20.0 3.75x H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN 120.0 35.0 3.42x H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN 1.0 0.3 3.33x H1:CAL-PCALY_PCALOSC1_OSC_SINGAIN 1000.0 250.0 4.00x The metric I used to judge by how much I could decrease the amplitude is the front-end computed coherence-based uncertainty in the transfer function between each line excitation and DARM_ERR. Prior to this change, the uncertainty had been hovering around 0.001 or below, i.e. 0.1% or below. We don't need *that* amazing of uncertainty. Recall, when we set the line heights during O3, we were shooting for a compromise between "the uncertainty on the time dependent correction factors derived from the calibration lines should be around 0.2% such that their uncertainty is negligible w.r.t. the uncertainty in the rest of the full response function systematic error budget" and "don't drive any harder than you need to; these loud lines cause bilinear coupling that degrades the sensitivity." The first attachment shows a trend of the coherence, individual line uncertainty, TDCF uncertainty, and calibration line amplitude during the tuning. Note that as I began to close out my tuning, we began experiencing a mild earthquake, which is also useful information. Indeed, during that earthquake, the uncertainty didn't really get worse that 0.4%, which is fine. Also, as a result of recent review of the frequencies of the new PCALX calibration lines which constantly monitor the systematic error (LHO:68139), I've changed the frequency of the 56.39 Hz line to 53.67 Hz, squarely in the middle of the non-vetoed region between [51.59, 54.69) Hz. All of these changes have been in place since Mar 30 2023 18:00:00 UTC (GPS 1364234418, Mar 30 2023 11:00:00 PDT). Here's the new list of calibration lines: Freq (Hz) Actuator Purpose Channel that defines Freq Since O3 15.6 ETMX UIM (L1) SUS \kappa_UIM excitation H1:SUS-ETMY_L1_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 16.4 ETMX PUM (L2) SUS \kappa_PUM excitation H1:SUS-ETMY_L2_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 17.1 PCALY actuator kappa reference H1:CAL-PCALY_PCALOSC1_OSC_FREQ No Frequency Change, Reduced Amplitude 17.6 ETMX TST (L3) SUS \kappa_TST excitation H1:SUS-ETMY_L3_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 33.43 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC4_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 53.67 | | H1:CAL-PCALX_PCALOSC5_OSC_FREQ Updated as of this aLOG 77.73 | | H1:CAL-PCALX_PCALOSC6_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 102.13 | | H1:CAL-PCALX_PCALOSC7_OSC_FREQ | 283.91 V V H1:CAL-PCALX_PCALOSC8_OSC_FREQ V 410.2 PCALX PCALXY comparison H1:CAL-PCALX_PCALOSC2_OSC_FREQ New since Jan 2023 (LHO:66967) 410.3 PCALY f_cc and kappa_C H1:CAL-PCALY_PCALOSC2_OSC_FREQ No Change 1083.7 PCALY f_cc and kappa_C monitor H1:CAL-PCALY_PCALOSC3_OSC_FREQ No Change n*500+1.3 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC1_OSC_FREQ No Change (n=[2,3,4,5,6,7,8])
Images attached to this report
Comments related to this report
E. Capote, J. Kissel
We discovered today that the ETMX SUS calibration lines were at their old loud amplitudes. Tracing down the issue, we found, and were reminded that, the ISC_LOCK guardian forces these values to be some amplitude upon entering the NOMINAL_LOW_NOISE state. It's a lovely challenge to find, but the values at which they get set to happens in
/opt/rtcds/userapps/release/isc/h1/guardian/ISC_GEN_STATES.py
lines 260 thjough 263,
for g in ['CLK','SIN','COS']:
ezca['SUS-ETMX_L3_CAL_LINE_%sGAIN'%(g)] = [value]
ezca['SUS-ETMX_L2_CAL_LINE_%sGAIN'%(g)] = [value]
ezca['SUS-ETMX_L1_CAL_LINE_%sGAIN'%(g)] = [value]
These have now been changed to be the new lower amplitude values
for g in ['CLK','SIN','COS']:
ezca['SUS-ETMX_L3_CAL_LINE_%sGAIN'%(g)] = 0.3
ezca['SUS-ETMX_L2_CAL_LINE_%sGAIN'%(g)] = 35
ezca['SUS-ETMX_L1_CAL_LINE_%sGAIN'%(g)] = 20
Sorry team.
While watching the locking, I noted that the L3 line was higher than the others for a time. ISC_LOCK, in Transition_from_etmx turns that line off, then back on later. When it turns it back on, it comes on at the old value of 1.0. Then, as Jeff fixed the other day, in NomLowNoise it gets turned down to the new nominal value of 0.3.
I have set the val in Lownoise_esd_etmx to the new value of 0.3. The better thing that someone (from Cal?) should do is move these values to lscparams so that one doesn't have to ctrl-F to find them all.
Another thing that I have just left alone for now, but also needs fixing: In the main part of Prep_for_locking, all 3 sus cal lines are turned off with a comment indicating that they are supposed to be off for the whole locking sequence. Then in the run state, they are all turned back on. This is additional to the L3 line being turned off then back on later. This logic should be cleaned up (although it's not urgent, since clearly we're able to lock nicely even with this spaghetti code).
The above list is now out of date as of 2023-05-03. See LHO:69303 for the latest list.