J. Kissel

Much like I've done in LHO:63405 and LHO:63429 for the sensing function, I've now rescued the plotting infrastructure from the O3 era pydarm for processing actuation measurements, and modernized it to be used with the new pydarm infrastructure. 

Executive Summary: I'm running out of reasons as to why I would think the calibration is very inaccurate. Said more straight forward, I think the systematic error in the calibration might be at tolerable levels. [Intentionally not yet quoting numbers though.]

This aLOG comes in sections:
    - Methods
    - Results and discussion from each actuator stage
    - What these actuator results mean for the greater, total response function

Methods
I've used the same base model parameter set from LHO:63429, not changing any of the interferometrically measured parameters since 2021, but where we're driving on all EX actuators, and we've accounted for the new OMC DCPD electronics chain.
That model parameter set lives in 
    git.ligo.org/Calibration/ifo/pydarmparams/pydarm_modelparams_PostO3_H1_20220527.ini

Then, I've used the modern methods in the ProcessActuationMeasurement class, get_processed_measurement_response, and run_mcmc, to do in a few lines what we typically do:
    For each actuator stage:
    - bring in the DARM_IN1 / iEXC2DARM and DARM_IN1 / PCAL transfer functions, and take the ratio
    - divide out all the frequency-dependence we think we know from the actuator, mostly the force-to-length transfer function but there're some other details like AA filters and such
    - divide out *most* of the known dimension-full gains and scale factors, leaving (hopefully) only a scalar actuator strength in the physical units of the actuator, be it [N/A] for the coils, or [N/V^2] for the ESD
    - Fit the measured residual transfer function to (for better or worse *only*) a scale factor and a delay 

From there I plot the measured residual against the MCMC fit, and the 2021 values and see what I get.
If there're regions that still have lots of frequency dependence, I excise the data from the fit, since we want to fit in regions where the residual data is behaving like "we expect" i.e. like our model.
The leftover frequency dependence (supposedly) is entirely covered by a GPR fit, and comes in later.

The scripts to do this live here:
    git.ligo.org/Calibration/ifo/scripts/fullifoactuationtfs/process_fullifoactuationtf_L3_MCMC_20220527.py
    git.ligo.org/Calibration/ifo/scripts/fullifoactuationtfs/process_fullifoactuationtf_L3_MCMC_20220527.py
    git.ligo.org/Calibration/ifo/scripts/fullifoactuationtfs/process_fullifoactuationtf_L3_MCMC_20220527.py

There's very little difference between the scripts but the input at the top defining the stage and the fit frequency range, as I've tried to keep things as generic and agnostic as possible. This should lend itself well for the plotting portions to be integrated into fully pythonic methods of future classes of plots in plot.py.

OK -- SCIENCE.

TST or L3 Stage
Results:
    Fit range: 20 to 1.2e3 Hz
    The Force Coefficient "answer" in terms of ... 
        Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
           Gain = 4.941e-12 [N/ct]
        Force per amount of actuator signal in its physical units (current or voltage):
           Gain = 4.627e-11 [N/V**2]
    ------------------------------- OR ----------------------------------
    Actuation Strength, H_A [N/V**2], L3              | 4.627e-11 (+5.539e-14,-5.521e-14) or (+0.1197%,-0.1193%)
    Actuation Strength, H_A L3, [N/ct]                | 4.941e-12 (+5.914e-15,-5.894e-15) or (+0.1197%,-0.1193%)
    Residual Time Delay, \Delta \tau_A [usec], L3     | -8.133 (+0.8089,-0.8088) or (+9.946%,-9.944%)

    TDCF Parameter | Value
    ---------------------------
    kappa_A_L3 = MCMC_MAP_[N/V**2]/Model_[N/V**2] = 4.62731e-11/4.669e-11 = 0.991071

Discussion:
The TST stage continues to be delightfully well behaved and simple. And indeed, according to the MCMC fit, the actuation strength appear to be with 1% of what it used to be, and the plots actuationFunction_H1_ETMX_L3_proc20220603_model20220527_meas20220527_MCMCfitfreqrange20p0-1200p0Hz.pdf show that there's very little residual frequency dependence.

What little we do see is only few degrees of phase lead, and my guess is that has to do with in-accurate high frequency poles from the ESD driver, and the in-late-O3-removed 10k current limiting resistor box (see breadcrumbs of the story starting in LHO:56346)

PUM or L2 Stage
Results: 
    Fit range: 20 to 400 Hz
    The Force Coefficient "answer" in terms of ... 
        Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
            Gain = 6.244e-10 [N/ct]
        Force per amount of actuator signal in its physical units (current or voltage):
            Gain = 0.03048 [N/A]
    ------------------------------- OR ----------------------------------
    Actuation Strength, H_A [N/A], L2              | 0.03048 (+5.593e-05,-5.576e-05) or (+0.1835%,-0.1829%)
    Actuation Strength, H_A L2, [N/ct]                | 6.244e-10 (+1.146e-12,-1.142e-12) or (+0.1835%,-0.1829%)
    Residual Time Delay, \Delta \tau_A [usec], L2     | -18.47 (+4.157,-4.189) or (+22.51%,-22.68%)

    TDCF Parameter | Value
    ---------------------------
    kappa_A_L2 = MCMC_MAP_[N/A]/Model_[N/A] = 0.0304848/0.03003 = 1.01515

Discussion: The PUM continues to be a bear. While at the surface level, we can be delight that the MCMC fit reports a change in actuation strength is similarly at the 1-2%, we have to look at the plots: actuationFunction_H1_ETMX_L2_proc20220603_model20220527_meas20220527_MCMCfitfreqrange20p0-400p0Hz.pdf.

Here're my thoughts on what I see:
    (1) There is a frequency dependent "trend" increasing with frequency across the entire measurement band by about 5% per frequency decade and spanning 15%. So, there're no "good" region where the PUM is behaving like we expect. 
    But as always, we can't think that it's one physical effect:
    (2) Below 20 Hz, if you squint your eyes, you can imagine its some L2A2L ASC cross-coupling like what Jenne's modeled in LHO:48738.
    (3) Above 400 Hz, tharr be the same violin mode dragons we've always battled, where we've modeled unintuitive-yet-confirmed-by-measurement-to-be-present wide "Q-ee" L2L transfer function surrounding the 500 Hz (and all harmonics really) violin modes as a single low Q thing, rather than getting the details of the effect from all 8 modes. 
    (4) In the middle, recall that we've replaced the analog electronics State 3 of the PUM driver, and made our best attempt to compensate for the new frequency dependence and gain balance. But -- maybe there's some systematic error left. Modeling from LHO:62191 suggests that this error is quite small, but ... who knows.

So we've got some work to do on understanding the PUM.

UIM or L1 Stage
Results: 
    Fit Region: 11 to 90 Hz
    The Force Coefficient "answer" in terms of ... 
        Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
            Gain = 7.552e-08 [N/ct]
        Force per amount of actuator signal in its physical units (current or voltage):
            Gain = 1.609 [N/A]
    ------------------------------- OR ----------------------------------
    Actuation Strength, H_A [N/A], L1              | 1.609 (+0.001762,-0.00178) or (+0.1095%,-0.1106%)
    Actuation Strength, H_A L1, [N/ct]                | 7.552e-08 (+8.273e-11,-8.356e-11) or (+0.1095%,-0.1106%)
    Residual Time Delay, \Delta \tau_A [usec], L1     | -37.49 (+6.031,-6.02) or (+16.09%,-16.06%)

    TDCF Parameter | Value
    ---------------------------
    kappa_A_L1 = MCMC_MAP_[N/A]/Model_[N/A] = 1.6087/1.6222 = 0.991679

Discussion: Here, like the PUM we see plenty of residual systematic error. BUT -- 
    (1) it's not new, (think about how much work Vlad did to get it better for O3B; see e.g. LHO:54519),
    (2) there is still a small region in between 11 and 90 Hz that actually *is* flat, 
    (3) any error in the UIM actuation strength doesn't matter that much to the systematic error in the response function in the gravitational wave band, and
    (4) before O4, we hope to change the contribution of the UIM (by changing the UIM / PUM crossover shape, and UIM roll-off, so that it doesn't contribute *at all* in the GW band.

So, I'm not nearly as mad about this, and it's "situation normal."

The PUM on the other hand... we've got some work to do!

Greater discussion of what these results mean for the current accuracy of the calibration:
Honestly, things are looking quite good. Given the current status of how each of the four major components contributes to the DARM loop response function (for a reminder of the situation as it stood in 2021, see 2021-04-23_H1_PostO3_pydarm_modelparams_ResponseFunctionContributions.pdf) and how little systematic error apparently remains based on the analysis of the 2022-05-27 actuator and 2022-06-02 sensing data, I think the calibration might be already pretty good.

Now I'm more suspicious that my DTT templates are errantly reporting more systematic error than there really is, because the've not been properly corrected for high frequency effects on the phase near the sensing / actuation crossover at the DARM UGF -- see the story in Figure 1 and surrounding math of T1900169.

There is a new method for this in the new pyDARM, so that's next on my list is to produce a new correction "calibration" for the DTT template, and/or do the opposite and export the uncalibrated PCAL to DELTAL transfer functions, correct and plot offline.