Displaying report 1-1 of 1.
Reports until 16:56, Friday 03 January 2020
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 16:56, Friday 03 January 2020 (54269)
Calibration Measurements: Analysis of O3B Thus Far, Sweep TDCFs vs. CAL Line TDCFs
J. Kissel

I've processed the most recent sensing function data from this morning (see LHO aLOG 54260), but now that I've finally obtained the ability to retrieve GDS computed time-dependent correction factors derived from the calibration lines, I want to compare these long term trends against the parameters derived from the occasional sweep that we do.

It's still an open task to process the data from the comb of calibration lines during thermalization (i.e. the data from LHO aLOG 53951), so we won't address the low frequency end of the sensing function too much (where we believe the detuned spring frequency of the SRC is mixing with parasitic L2A2L). 

In this aLOG, I fit all of the O3B sensing function measurements via MCMC, limiting the MCMC fit frequency range to only be able 20 Hz (i..e above where the low-frequency nonsense is occuring). These are with individual scripts, like 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    process_sensingmeas_20200103.py

Then, I enter those MCMC results for the relative optical gain change, \kappa_C, and the darm coupled cavity pole frequency, f_cc, in to 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/src/
        readHardcodedTDCFs.py
(Note, I intentionally set f_s and Q_s to be 0 Hz and 1e-2, identical to the reference model, because -- even if the MCMC thinks there's a spring, I want to ignore it, and just leave it as an open systematic error.)
Doing so, now, when I call the processing of the sensing functions indicating that it is *not* a reference measurement, then the data will be corrected for these TDCFs.

The first two attachments show the difference between the uncorrected vs. corrected sensing function collection, showing how the collection of data clean up with the application of TDCFs.

The third attachment shows how the sweep-computed TDCFs compare against the GDS computed, CAL-line-derived TDCFs of the course of O3B.
Several interesting things in this collection of plots:
    (1) The Sweep TDCFs *roughly* track the CAL Line TDCFs, but disappointingly miss quite a few of the trends. I'm not sure I know what this means yet. As a check to make sure the MCMC fits were doing sensible things, I also looked at the collection of MCMC fits and parameter corner plots, which I attach 4th and 5th. *At least*, both TDCF calculations track the time period between 2019-12-04 to 2019-12-11 when we had trouble with the PSL rotation stage and we were sending less power in the the IMC (about 36W instead of 38W), and thus \kappa_C became closer to 1.0, because this was the power we were sending in on 2019-09-09 -- the reference model we're still using (and hope to update next week).

    (2) I still cannot trend PSL power channels, though, so I still don't have any clues as to what the ~1 month long hump between 2019-11-19 and 2019-12-13 of both f_cc and "f_s^2" (insert all the usual caveats that the GDS derived f_s^2 does not consider the parastic L2A2L coupling, so this number doesn't correspond to the model of a spring only thing, but it's all we've got for now). I haven't tried trending other things like IFO alignment (expect for times when we've performed an initial alignment, which don't appear to have any correlation), or thermal things.

So -- no mysteries solved here, but a bunch of data has been processed, and we're starting to get all information on the same plot finally in order to form a game plan for how we'll handle all of this systematic error in the sensing function.

The script that produces the TDCF trend is
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    plot_H1_GDS_TDCF_MinuteTrends_20200103.py
Non-image files attached to this report
Displaying report 1-1 of 1.