Displaying report 1-1 of 1.
Reports until 18:11, Tuesday 31 May 2022
H1 CAL (ISC)
jeffrey.kissel@LIGO.ORG - posted 18:11, Tuesday 31 May 2022 (63405)
2022-05-25 Sensing Function Processed w/ New pyDARM Infrastructure; Results Typical of a IFO Mid-Commissioning: Confusing
J. Kissel, [w/ help from E. Goetz]

I've processed the sensing function measurement from LHO:63391, and the results are confusing. 

Executive Summary -- To move towards a better calibration, I think we need to change the sensing function's optical gain, but not the cavity pole, and there's stuff below 80 Hz that cannot be explained by the simplistic physical model of the sensing function we typically use.

Namely, this sensing function result is in no way flat below ~80 Hz, and my guess is that the story is more complicated than any one thing. 
My current favorite suspects:
   - [Below 20 Hz] Because this measurement was taken while DARM was control with EY's PUM and UIM, and the story is unclear about an L2A decoupling. I see Sheila records in LHO:63394 that, although we thought some L2A decoupling filters might have been on with some old/bad filter, it was in fact all the way OFF. One half of the L2A2L equation may be being exacerbated by excess angle because we haven't yet balanced the EY PUM coils after we've changed out the electronics for a newly shaped analog low-pass and updated the compensation for it because the EY optical lever performance has been intermittent.
   - [10 to 100 Hz] The OMC whitening / transimpedance amplifier compensation. From this plot from LHO:62653 where I record the details of Daniel's installation of Dripta's fits to  February measurements, but alas, the electronics have changed their response since -- see this plot from LHO:62916. With that "easy" measurement, one can't tell if it's the transimpedance amplifier changing or the whitening changing, but the current best guess is that we took the February data while the Transimpedance Amplifier was cold -- see G2200688.
   - [Below 5 Hz] There is still probably some SRCL cavity detuning buried in the mix with the L2A2L confusion, like we've seen in O3, but I *really* hope that now that we have a point absorber free ITMY (since the 2020-2021 replacement), that it's at way low-frequency.  
   - [10 to 100 Hz] I know that Evan has done a super careful job at reproducing old O3 results when build up the new pydarm infrastructure. However, there are some paths / upgrades that were not used in O3, and have been installed since in prep for the O4 OMC sensing electronics, and for scenario in which we start to observe, don't have an updated front-end filter compensation installed, but are armed with improved compensation to be installed / corrected for offline. 
   - [Somewhere...] We have not yet balanced OMCA and B path digitally. The same above measurements of the analog electronics show that the chains are actually remarkably well balanced in terms of gain *ratio*, but we've not yet changed the balance matrix a la LHO:47217, in fact the balance matrix still has the old values in place. Thus the *sum* of the two chains, which is what comprises the error signal for DARM may be imbalanced by a few percent, causing the frequency dependent wiggles in each chain to be added and create a new frequency-dependent wiggle.
   
But, regardless -- buried in this mess of a measurement somewhere is an optical gain and a DARM coupled cavity pole frequency that has changed.

As such, I used the upgraded pyDARM infrastructure (pydarm) to build a model of the current DARM loop system, using the same interferometrically measured parameters from the Spring 2021 time when we last had a good calibration of the IFO. 

What really means I've just created a new parameter file, updating the syntax, recording the digital settings of the loop at the time, without changing any of the interferometrically measured results. This is fine -- in this case we're looking to *find out* what the interferometrically measured results are.
For an MCMC of the interferometrically measured sensing function, all I need from the model is the stuff that's well known that we've been using since O3: 
   - the digital and analog AA filters
   - the arm cavity light travel time
   - the product the difference between a simple cavity pole and the full Fabry Perot response
and 
   - the super-Nyquist poles and zeros of the new OMC electronics
that we know from Dripta's fits, G2200551 and aren't from the part of the circuit we expect to be unstable in time.

This new parameter file lives here: pydarm_modelparams_PostO3_H1_20220525.ini
   
Then, while calling and creating parts of the model, and calculating MCMCs are super easy in the new infrastructure, extracting information from them and plotting is just not there yet, so I wrote a script to really process, plot, and understand the data copying a lot of the old pydarm infrastructure we had from O3 (sensing.py).
That script lives here: process_fullifosensingtf_MCMC_20220525.py

From this fit -- and exploring the data frequency range over which I give the MCMC fitter, as well as comparing it to the April 2021 sensing function model, which ignored detuning effects, and really is just comprised of an optical gain and DARM coupled cavity pole -- I suggest the following:
    (1) The optical gain has indeed has dropped by ~10% +/-2%, so we should update that in the calibration. This is consistent with what we're seeing when we measure the overall response function, say, in LHO:63285. In order words (because it's always confusing because C, the sensing function, is in the denominator when contributing to R), 
        \kappa_C ~ 0.9, 
        where 
        C_better = \kappa_C * C_now, 
        and 
        R_better / R_now = [[ (1 + \kappa_C *A*D*C) / \kappa_C * C ]] /  [[(1 + A*D*C) / C]]
                         = (1/kappa_C)*(1 + \kappa_C *A*D*C) / (1 + A*D*C)
                         ~ (1/kappa_C) at high frequency, and
        R_now / R_PCAL = R_now / R_better
                         ~ \kappa_C at high frequency
        What *exact* value we should use depends on which fit you trust better. For the optical gain, I trust the MCMC fit where I limit it to fitting the data only above 80 Hz. (see page 3 of sensingFunction_H1_proc20220531_model20220525_meas20220525_fitexploration.pdf). That fit yields 

     Optical gain, H_c (ct/m)                 | 3.206e+06 (+9119,-6500)
     Optical gain, H_c (mA/pm)                | 5.107 (+0.01453,-0.01035) or (+0.2844%,-0.2027%)
     Cavity pole, f_cc (Hz)                   |  450 (+1.843,-2.47) or (+0.4095%,-0.5489%)
     kappa_c = 0.923215

Notice that that 80Hz-and-above fit also suggests that the cavity pole is exactly what it used to be at 450 (+1.86, - 2.62) Hz. 

As such, I suggest installing a gain of 1 / 3.206e+06 = 3.119e-7 [m/ct] in the CS_DARM_ERR bank. I can do this tomorrow, if folks are game.

     (2) The coupled cavity pole has not changed by much, if at all. I don't suggest we change it.  Craig's gut feeling was that it might be a bit lower that 2021-times, based on power build-ups during PSL input power up -- but maybe that's when we go to higher than the 50 W that this lock stretch was. Comparing whether I include data down to 20 Hz in the fit against the 80Hz-and-above fit, the frequency dependent residual from all the other confusing things happening mentioned above, starts to get worse. That 20Hz-and-above fit claims 

    Optical gain, H_c (ct/m)                 | 3.186e+06 (+2406,-2385) or (+0.07551%,-0.07488%)
    Optical gain, H_c (mA/pm)                | 5.075 (+0.003832,-0.0038) or (+0.07551%,-0.07488%)
    Cavity pole, f_cc (Hz)                   |  459 (+1.074,-1.075) or (+0.2339%,-0.2343%)
    kappa_c = 0.917279

so, a little bit lower optical gain, and a little bit higher cavity pole frequency (with the same ~1ish Hz claimed precision). But, given the frequency dependent residual is more frequency dependent above 80 Hz in this fit, I'm less inclined to trust it. And that's because, as I include *all* the data, down to 5 Hz, then the cavity pole becomes unbelievable at 518 Hz. 

I'd be interested in another measurement of this now that we've switched back to an All EX, O3 like drive to see if / how it's different.
Non-image files attached to this report
Displaying report 1-1 of 1.