J. Driggers, J. Kissel, L. Sun

We've made several advances in knowledge with today's collection of bi-weekly sensing function measurements:
    (1) I was able to successfully complete PCAL to DARM IN1 transfer functions out to 5 kHz with and extra template. It takes an extra 20 minutes. This data is still of poor quality, so it doesn't improve the estimate of response function systematic error *much* but it does a little. Pep and I continue to work on analyzing the roaming PCALX calibration line so we have better data quality up there and confirm our supposition that the error / uncertainty is not as large as is falsely reported by the Guassian Process Regression. Lilli will comment more on how much this high frequency data improves the uncertainty (spoiler: it's not much).

    (2) We've been continuing to suffer from ~2 minute period oscillations in ASC that result in reported arm power fluctuations at the peak-to-peak of 2 kW (!!). A first attempt at re-phasing AS 38 (i.e. MICH ASC sensors) "fixed" it on Monday for the overnight long lock stretch (LHO aLOG 48857), but that phase change was reverted after failing at to re-acuire lock after Tuesday maintenance (LHO aLOG 48878). Jenne adjusted the phase just before I began measuring today, but (unknowingly at the time) was using the wrong metric. Thus, these sensing function measurements may be corrupted by the oddball phasing of AS36, because the oscillations would come and go during my sweeps. 
        Evidence points toward us needing to dynamically change the WFS phase, having one setting for lock-acquisition, and another after the IFO has thermalized. Jenne has written m,ore on this in LHO aLOG 48948.

    (3) In that semi-stable, some-times oscillating configuration, with the oddball phasing, apparently, the DARM optical plant changed. The most significant change is that the SRC optical spring frequency changed from the reference 4.5 Hz to a lower 2.3 Hz. The DARM coupled cavity pole reduced from 410 to 405 Hz, and the optical gain increased by 1%. Jenne has re-rephased the AS36 WFS *after* I've taken this data, so I want to re-confirm with more measurements in this new-new AS36 WFS phase configuration before I set off the "we need to change the reference model" alarm bells.

    (4) Unfortunately, even though it's dreadfully obvious that an arm power fluctuation at the 2 / 170 = 0.011 = 1% level should be reported in the time-dependent correction factor for the optical gain, kappa_C, we see no such reported fluctuation in these TDCFs. We also see no such fluctuation reported in the DARM coupled cavity pole, f_cc. This is likely because the fluctuation is faster than the integration / average time of the calibration lines (currently 13 averages of 10 sec FFTs, i.e. effectively only giving an update every 2 minutes, and thus this two minute period oscillation is averaged away)

Below are details about the data, and how we've processed it in order to come to these conclusions.

Attached are three plots:
     (a) 2019-05-02_H1IFO_OpticalPlant_Fluctuations.png A trend showing the supposed time-dependent correction factors for the optical plant against arm powers and various ASC control / error signals that show the same behavior. (Remember, because the optical spring still has unphysical phase rotation at low frequency, the tracking of the optical spring parameters are bogus, and thus have been turned off in the real time system).

     (b) 2019-05-02_H1_sensingFunction_noMCMCTDCFcorr.pdf A collection of plots of the processed sensing function *if the measurement is not corrected for any time dependence* where the time dependence is measured by the ratio of MCMC fit values (i.e. not from estimates of those values from calibration lines).

     (c) 2019-05-02_H1_sensingFunction_withMCMCTDCFcorr.pdf The same collection of plots, but now correcting the measurement for the MCMC values from (b), and thus "propagating it back in time" to the reference values.

One can see from (b), and specifically page 5, that today's data set is definitely an outlier -- all other days have not been corrected for anything. Similarly, looking at pages 3 and 4, comparing the reference model against today's measurement leaves a large residual, and "screws up" the Gaussian Process Regression, or rather, the GPR is accurately reporting large systematic error.

Once we correct the measurement for the difference in MCMC parameters, the results in (c) show things clean up better.

Again, we should not create a new model, nor update any of the low-latency data stream yet. We should gather more data, as we continue to settle on a ASC configuration to combat this oscillation issue.
 
%%%%%%%%%%% Details %%%%%%%%%%%%

2019-04-04 Reference Model Parameters are from LHO aLOG 48378.

The detailed answers from the MCMC fit of the *uncorrected* data are as follows:
                                             2019-04-04      2019-05-02 
                                             Reference       New Values
Overall gain, H_c                   (ct/m) | 3.250e+06       3.281e+06    (+1490,-1382)         or (+0.0454%,-0.04213%)
Cavity pole, f_cc                     (Hz) | 410.6           404.3        (+0.4895,-0.5211)     or (+0.1211%,-0.1289%)
Detuned SRC spring frequency, f_s     (Hz) | 4.468j          2.269        (+0.1046,-0.1181)     or (+4.611%,-5.205%)
Detuned SRC spring quality factor, Q_s  () | 52.14           94.15        (+902.2,-2156)        or (+10.44%,-4.368%)
Residual time delay, tau_c          (usec) | 1.0             0.9597       (+0.2495,-0.2655)     or (+  26%,-27.66%)

The resulting TDCFs from the comparing the above new MCMC results against the reference model:
kappa_c = 1.009538    (New Value / Reference Value)
   f_cc = 405.1       (New Value)
    f_s = 2.292j      (New Value, entered as complex)
      Q = 94.18       (New Value)

Because we've yet to figure out a good system for correcting sweep measurements for time dependence, these have been added to the list of hard-coded corrections in 
     ^/trunk/Common/pyDARM/src/sensing.py
and we chose to either invoke them, or not invoke them in the following analysis scripts, used to process today's data:
     ^/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/process_sensingmeas_20190502.py
     ^/trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_20190502.py
and those scripts have been committed to the repo.

The data from today lives here:
     ^/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
          2019-05-02_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml
          2019-05-02_H1_PCAL2DARMTF_BB_aftersweeps.xml
          2019-05-02_H1_PCAL2DARMTF_BB.xml
          2019-05-02_H1_PCAL2DARMTF_HF_SS_600to5000Hz_15min.xml
          2019-05-02_H1_PCAL2DARMTF_LF_SS_5t1100Hz_10min.xml

There are broad band sweeps "in the can" before the measurements started (though after Jenne phased the AS36 WFS), and after the measurements were complete (but before Jenne re-re-phased the WFS with a better metric). They show no evidence time dependence during the measurement, so I've not processed them in any more detail.

You'll note there are LF and HF templates for the PCAL2DARMTF. That data was exported and *by hand* stitched together to create the data shown in the attached plots. Those stitched together .txt files are 
     ^/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
          2019-05-02_H1_DARM_OLGTF_Stitch_SS_A_DARMIN2_B_DARMEXC_coh.txt
          2019-05-02_H1_DARM_OLGTF_Stitch_SS_A_DARMIN2_B_DARMEXC_tf.txt
          2019-05-02_H1_PCAL2DARMTF_Stitch_SS_A_PCALYRX_B_DARMIN1_coh.txt
          2019-05-02_H1_PCAL2DARMTF_Stitch_SS_A_PCALYRX_B_DARMIN1_tf.txt
We should figure out a better way to merge this data.