Reports until 11:41, Thursday 30 March 2023
H1 CAL (CAL, DetChar, ISC, OpsInfo, PEM)
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
jeffrey.kissel@LIGO.ORG - 15:16, Monday 10 April 2023 (68555)
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.
jenne.driggers@LIGO.ORG - 09:47, Wednesday 12 April 2023 (68618)

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).

jeffrey.kissel@LIGO.ORG - 12:12, Thursday 04 May 2023 (69320)DetChar, OpsInfo
The above list is now out of date as of 2023-05-03. See LHO:69303 for the latest list.