J. Kissel, L. Sun

Remaining confused by yesterday's realization that the IFO needs a right-half-plane complex pair of a poles to represent its low-frequency sensing function detuning (see LHO aLOG 48083), in the interest of forward progress toward the observing run, we decided to try to cut our losses and attempted to install a sensing function compensation filter that minimizes the magnitude and phase error between model and measurement above 10 Hz, regardless of whether it matches measurement below 10 Hz.

This attempted failed, resulting in a broadband PCAL2DELTAL systematic error rolling up to 5% / 5 deg between 10 and 40 Hz -- much worse that the poorly-understood, but does-the-right-thing configuration we've been observing in since Friday (see LHO aLOG 48040), which *still* doesn't exceed 1% / 5 deg above 20 Hz (and the phase error cleans up to 2 degs by 40 Hz) -- see discussion of it's stability this morning (LHO aLOG48098).

We've reverted to this "ER14" configuration with systematic error at the 1% level, and will continue to think on all this.

The plan d'jour in light of this is to generate a pyDARM model that re-creates what's in the front-end regardless from whence it came (LHO aLOG 48012) and how many spring sign bugs there were in the code that generated it (see LHO aLOGs  and 48080).
This way -- even though we won't be able to reproduce the posterior distributions on these numbers and quantify an uncertainty -- we can at least create a self-consistent CAL-CS, pyDARM world, from which we can generate 
    - reference model values (aka "EPICs records") to compute sensible time-dependent correction factors, and
    - generate FIR filters for GDS-CALIB_STRAIN.

Many more details about our failure today below.

DETAILS

Picking up where the entry starts -- we want a inverse sensing function filter that reproduces the data above 10 Hz. So, to do this, we ran the *fixed* MCMC code inside,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/src/
    sensing.py
    Revision: 7085

over both the 2019-03-29 data and the 2019-03-31 data, limiting the MCMC fit region to above 10 Hz. This results are the following:

2019-03-29 Data 
    Optical gain, H_c (ct/m)                 | 3.245e+06 (+1287,-1276) or (+0.03966%,-0.03933%)
    Optical gain, H_c (mA/pm)                | 4.333 (+0.001718,-0.001704) or (+0.03966%,-0.03933%)
    Cavity pole, f_cc (Hz)                   | 410.3 (+0.8639,-0.8516) or (+0.2105%,-0.2075%)
    Detuned SRC spring frequency, f_s (Hz)   | 4.026 (+0.03837,-0.03817) or (+0.9529%,-0.9481%)
    Detuned SRC spring quality factor, Q_s   | 92.61 (+910.3,-1710) or (+10.17%,-5.416%)
    Residual time delay, tau_c (usec)        | -0.2354 (+0.6043,-0.5969) or (+-256.7%,--253.6%)
processing script:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    process_sensingmeas_20190329.py

2019-03-31 Data
    Optical gain, H_c (ct/m)                 | 3.256e+06 (+1256,-1263) or (+0.03856%,-0.03879%)
    Optical gain, H_c (mA/pm)                | 4.348 (+0.001676,-0.001686) or (+0.03856%,-0.03879%)
    Cavity pole, f_cc (Hz)                   | 419.5 (+1.261,-1.286) or (+0.3007%,-0.3066%)
    Detuned SRC spring frequency, f_s (Hz)   | 3.561 (+0.01374,-0.01384) or (+0.3857%,-0.3887%)
    Detuned SRC spring quality factor, Q_s   | 12.75 (+297.8,- 307) or (+4.282%,-4.153%)
    Residual time delay, tau_c (usec)        | 2.031 (+0.8938,-0.8984) or (+44.01%,-44.24%)
processing script:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    process_sensingmeas_20190331.py

Notice that, as expected, the uncertainty on the Q is quite large. The first two .pdf attachments 
    2019-03-29_H1_sensingFunction_mcmcModel_vs_measurement.pdf
    2019-03-31_H1_sensingFunction_mcmcModel_vs_measurement.pdf
show the the goodness of fit for each data set against a model created with the maximum a posteriori values from the MCMC fit.

With these two values, we created two model files, 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/
    modelparams_H1_20190328springfix.py  # this model is informed by the 2019-03-29 data
    modelparams_H1_20190331.py           # this model is informed by the 2019-03-31 data 
and ran a Gaussian process regression on the stacked 2019-03-29 and 2019-03-31 data, given the two models, using 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    process_sensingmeas_collection_GPR_model20190328springfix.py    # this uses the model informed by the 2019-03-29 data
    process_sensingmeas_collection_GPR_model20190331.py             # this uses the model informed by the 2019-03-31 data

and we see, in the 3rd and 4th attachments,
    2019-03-28-springfix_ref_model_H1_sensingFunction_GPR_on_AllSensingMeasurements.pdf
    2019-03-31_ref_model_H1_sensingFunction_GPR_on_AllSensingMeasurements.pdf
that the 2019-03-29 data produces a model with less systematic error (I mean, just barely) for both measurement sets.

So -- we installed a filter that had the following parameters:
    Optical gain, H_c (ct/m)                 | 3.238e+06 
    Cavity pole, f_cc (Hz)                   | 412.448 
    Detuned SRC spring frequency, f_s (Hz)   | 4.308 
    Detuned SRC spring quality factor, Q_s   | 80.1019 

Turned it on, increase the gain of the actuator stages from 0.95 to 1.00, and measured the standard PCAL2DELTAL transfer function hoping for resounding success.
Instead we find that while
    (a) The high frequency asymptote is a little better, and the systematic error is nil all the way down 45 Hz, 
we saw that
    (b) The phase systematic was worse at all frequencies, and
    (c) There was now a much larger systematic error below 45 Hz, swelling up to 5% between 15 and 45 Hz.
#facepalm

So, in desperation, we began exploring the hand-tune-able parameter space:
    (A) Changing the overall actuator gain again -- see first image attachment,
    (B) Changing the relative gain of the PUM to other stages, thinking that maybe there could still be a systematic there -- see second image attachment, and
    (C) Even creating a few other sensing filter options with differing phase and magnitudes -- see third image attachment
    (D) For posterity, we checked the relative path delay -- this had no effect as before, no image shown

While all of these are a wonderful exercise in understanding how each parameter impacts the DELTAL systematic error, we conclude that there is still something dreadfully wrong with the magnitude *and* phase of some or multiple paths, and this really needs a hard think.

I conclude with the same plan as above, since we're clearly lost in our ability to translate measurement to filters, so I suggest we recreate what works online in the offline world so we can at least have a world that is self-consistent.
This will wreak havoc on how we propagate statistical uncertainty, but that's a problem for another day, for now it is more important to have our systematic error small.