J. Kissel (after consult with J. Driggers)

While poking around the front-end computed response function systematic error yesterday and today (LHO:72848 and LHO:72863), I was reminded that one of the calibration lines used to measure the response function systematic error has been showing completely bogus large numbers for "a long time."

It's the 102.13 or 104.23 Hz PCALX calibration line.

I realize the systematic error measured at this frequency is wrong because we never updated the frequency in the DARM loop model parameter file. 
(See details below as to why this matters for both GDS and CALCS computation of the response function systematic error at this frequency.)

For reasons I outline below, it's easier to fix the problem by changing the calibration line frequency *back* to 102.13 Hz, so I've done so as of 2023-09-13 20:17:45 UTC, and the error estimate has returned to functional values around unity magnitude and zero phase by 2023-09-13 20:19:45 UTC (i.e. after the 2-minute gating, medianing, averaging algorithm catches up.)

All of this was done while we're were *out* of observing during today's commissioning window, so the *next* observation ready segment will pick up this change around 2023-09-13 ~23:00 UTC.

%%%%%%%%%%
Details & Motivation
%%%%%%%%%%

2023-06-21 Calibration updates to reflect power down to 60W PSL input, 20230621T211522Z pydarm_H1.ini file correctly has 102.13 Hz in the list of cal_line_sys_pcalx_frequencies. LHO:70693

2023-08-04 Friday afternoon, SRCL Feed-forward filter re-tuned, informed by a measurement that mistakenly has all calibration lines still ON, including 102.13 Hz line. So, FF measurement fitter installs a super high Q zero:pole pair to "compensate" for it. The resulting filter is installed in the SRCL FF path, starting a period of huge interference between this high-Q zero:pole pair in the SRCL FF and the 102.13 Hz calibration line itself. LHO:71961

2023-08-08 Next week Tuesday, DetChar Team finds "some feature" at 102.12833 Hz, and folks blame the calibration line itself since it's originally identified as appearing Saturday morning. LHO:72064

2023-08-09 That same week Wednesday, out of panic and as well as starting a "grasping at straws" test, we moved the 102.13 Hz PCALX calibration line to 104.23 Hz LHO:72108 -- but in our rush, forgot/didn't realize we needed to update down-stream computation that is impacted by this change:
    (a) The front-end demodulator that turns this line into something useful in CAL-CS needs its local oscillator frequency to change to match,
    (b) The cal_line_sys_pcalx_frequencies list within pydarm_H1.ini needs updating as well -- or else the "DARM loop model transfer function values at calibration line frequencies" EPICs records are wrong for the new frequency, which means both GDS and CAL-CS are interpreting this line incorrectly.

2023-08-29 Problem with SRCL FF filters is finally identified and removed, and the story about what happened on 2023-08-04 finally becomes clear. LHO:72537

2023-08-31 Calibration updated in order to account for the past two month's worth of commissioning and ETMX ESD actuation strength drift, but the 20230830T213653Z pydarm_H1.ini file incorrectly still has 102.13 Hz in its cal_line_sys_pcalx_frequencies list. LHO:72594
    >> I didn't aLOG it explicitly, but on this day, I noticed the (a) mistake above, and changed the CAL-CS DEMOD local oscillator frequency to 104.23 Hz for the front-end demodulation and estimation of systematic error. Because (b) was still going on, it didn't fix the problem.

2023-09-13 TODAY Realized the issue with front-end systematic error calculation was still wrong because of (b); the cal_line_sys_pcalx_frequencies list in the pydarm_H1.ini file, and reasoned it would be way easier to change the PCAL OSC and DEMOD OSC frequency back to 102.13 Hz than to go through the entire rigamarole of updating the calibration and "pushing new EPICs records." So, I moved calibration line *back* to 102.13 Hz changing the PCALX OSC7 frequency, and remembered to update the LINE8 DEMOD LO frequency to match.

First attachment: The graphical MEDM interface of where I changed the EPICs records that define the PCAL OSC7 calibration line frequency, and the CALCS LINE8 DEMOD LO frequency.
Second attachment: The PCAL OSC7 frequency change has been saved in the H1CALEX SDF system. (Only the OBSERVE.snap is show, because the h1calex model's safe and OBSERVE.snaps are the same file soft-linked together.)
Third attachment: The CALCS LINE8 DEMOD LO frequency change to match has been saved in the H1CALCS SDF system. (Only the OBSERVE.snap is show, because the h1calcs model's safe and OBSERVE.snaps are the same file soft-linked together.)
Fourth attachment: A graphical representation of the above mentioned timeline

%%%%%%%%%%%%%%
Calibration Line List Update
%%%%%%%%%%%%%%

Freq (Hz)   Actuator                   Purpose                      Channel that defines Freq             Changes Since Last Update (LHO:72108)     
15.6        ETMX UIM (L1) SUS          \kappa_UIM excitation        H1:SUS-ETMY_L1_CAL_LINE_FREQ          No change
16.4        ETMX PUM (L2) SUS          \kappa_PUM excitation        H1:SUS-ETMY_L2_CAL_LINE_FREQ          No change
17.1        PCALY                      actuator kappa reference     H1:CAL-PCALY_PCALOSC1_OSC_FREQ        No change
17.6        ETMX TST (L3) SUS          \kappa_TST excitation        H1:SUS-ETMY_L3_CAL_LINE_FREQ          No change
33.43       PCALX                      Systematic error lines       H1:CAL-PCALX_PCALOSC4_OSC_FREQ        No change
53.67         |                            |                        H1:CAL-PCALX_PCALOSC5_OSC_FREQ        No change
77.73         |                            |                        H1:CAL-PCALX_PCALOSC6_OSC_FREQ        No change
102.13        |                            |                        H1:CAL-PCALX_PCALOSC7_OSC_FREQ        FREQUENCY CHANGE; THIS ALOG
283.91        V                            V                        H1:CAL-PCALX_PCALOSC8_OSC_FREQ        No change
284.01      PCALY                      PCALXY comparison            H1:CAL-PCALY_PCALOSC4_OSC_FREQ        No change
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
1153.2      PCALY                      Old "cancelling" line        H1:CAL-PCALY_PCALOSC9_OSC_FREQ        Added to the list, but has been on for all of O4.
n*500+1.3   PCALX                      Systematic error lines       H1:CAL-PCALX_PCALOSC1_OSC_FREQ        No change (n=[2,3,4,5,6,7,8])