Reports until 12:33, Tuesday 12 November 2019
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 12:33, Tuesday 12 November 2019 - last comment - 13:48, Wednesday 19 February 2020(53188)
Pcal Simulink model/MEDM updates with new Pcal calibration Coefficients

Vlad, S.Karki, D. Barker

We pushed the Pcal Simulink model and MEDM screen that Shivaraj generated at LLO (LLO alog 49839). The updated suspension filter files (LHO alog 53155) have been loaded into the corrponding Pcal filter banks as well. 

The new calibration coefficients have been uploaded to the appropriate EPICS variable using the txt files linked below:

aligocalibration/trunk/Runs/O3/H1/Results/CALCS_FE/lho_yend_pcal_epics_created-20191111.txt

aligocalibration/trunk/Runs/O3/H1/Results/CALCS_FE/lho_xend_pcal_epics_created-20191111.txt

While quacking the susmodel we encounted a number of issues:

1) The filterfile had to be copied to a local directory and qucked there, as the quacking script would give errors concerining the new SOS coefficients (reason unknown)

2) The quack script only updates gains and SOS coeffcients of the respective filter modules. It does NOT update the desgng strings (the commented out lines that describe what the filter is). Attemting to run "foton -c" (something that needs to be done to parse the foton filters correctly) on the filter file would result in foton detecting a difference between the design string and the real filter, and would take the design string and overwrite your brand new filters.

The workaround to the second problem (thanks to Shivaraj) was to delete the design string before running "foton -c", forcing foton to regenerate it.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:52, Monday 13 January 2020 (54471)
Link 

The first observation ready segment that had these updates included started on Nov 12 2019 at 22:58:33 UTC, i.e. 1257634731.

Thus, prior to these updates, in O3 (i.e. from April 1 2019 to Nov 12 2019) the LHO PCAL Y RX PD (the PCAL PD we use for our absolute displacement reference) had a systematic error of +0.43% -- see the "change" field for LHO Y_end of the RXPD table pg 9 of G1902259. In those slides, the +0.43% is defined as 
    
    xi = [ (after - before) / before ]*100 = [(after/before) - 1]*100.                                    (1) 

*** Note that this definition has been defined previously in Eq. (1) of LHO aLOG 52837.
Which means that the previous relationship between xi and eps still holds,

                          AFTER          NOW           TRUTH            dL_pcal'
           (1 + xi/100) = -----     = ---------   =  ---------   =    --------    = eps.                  (3)
                          BEFORE       EARLIER        APPARENT          dL_pcal
(and I've used the same equation numbering from that aLOG)

This means, for PCAL data prior to Nov 12 2019, should be corrected by 
   PCAL_nosyserror = eps * PCAL_withsyserror = (1.0043) * PCAL_withsyserror                               (2) 
where I've again used the same equation numbering scheme as in LHO aLOG 52837, for consistency.

That means for all measurements taken and processed before Nov 12, they need the following action taken (assuming that I've already applied the necessary 1/f^2 "anti-whitening" filter and AA filter corrections to PCAL_RXPD):

             PCAL_RXPD    DARM_IN1
    A_i  ==  --------- * ----------
              DARM_IN1    i_SUSEXC

                 PCAL_RXPD(TRUTH)    DARM_IN1      eps * PCAL_RXPD(APPARENT)    DARM_IN1
>> A_i(TRUTH) =  ---------------- * ---------- =   ------------------------- * ---------- = eps * A_i(APPRARENT)
                     DARM_IN1        i_SUSEXC                DARM_IN1           i_SUSEXC      

  or
   A_i(NO PCAL SYS ERR) = eps * A_i(W/ PCAL SYS ERR)

      DARM_IN1    DARM_EXC
C ==  --------- * --------
      PCAL_RXPD   DARM_IN2

                    DARM_IN1       DARM_EXC     1           DARM_IN1        DARM_EXC       1
>> C(TRUTH) ==  ---------------- * -------- = ----- * ------------------- * --------   = ----- * C(APPARENT)
                PCAL_RXPD(TRUTH)   DARM_IN2    eps    PCAL_RXPD(APPARENT)   DARM_IN2      eps

  or
   C(NO PCAL SYS ERR) =  (1/eps) * C(W/ PCAL SYS ERR)

The reason I call this out explicitly, is because in O3A (i.e. for LHO aLOG 52837), *ALL* sensing and actuation measurements used to produce the uncertainty budget were "corrupted" by this PCAL systematic error.
This is why, in that aLOG, we could "get away" with just multiplying the *entire response function* and/or h(t) by eps (as shown in Eqs. 6-8 of that aLOG).
 
With the new 2020-01-03 model that's to be installed today we cannot. We've *re*processed data from O3A, and some of the measurements from O3B which are prior to Nov 12 are being used as well -- in the same estimate of A_i and C systematic error as those measured *after* the PCAL fix on Nov 12. 

So, before feeding the A_i and C's from each measurement before Nov 12 in to the measurement collection pool that informs the GPR fitting, I need to correct for eps.
ling.sun@LIGO.ORG - 13:48, Wednesday 19 February 2020 (55183)
Link

I'm not sure I agree with the following eqn:
                 PCAL_RXPD(TRUTH)    DARM_IN1      eps * PCAL_RXPD(APPARENT)    DARM_IN1
>> A_i(TRUTH) =  ---------------- * ---------- =   ------------------------- * ---------- = eps * A_i(APPRARENT)
                     DARM_IN1        i_SUSEXC                DARM_IN1           i_SUSEXC
--> A_i(NO PCAL SYS ERR) = eps * A_i(W/ PCAL SYS ERR)
 
It seems to me that it should be the other way around. And so does sensing C(truth).
 
Since eps >1, PCAL_RXPD(truth) is higher than we thought during measurement. And hence the A_i(apparent) is higher than it should be. Hence A_i(truth) should be A_i(apparent)/eps. Or if we regard "eps" as a PCAL "clipping factor" but larger than 1, the A_i  measurement should be corrected by 1/eps (see eqn 17 in https://arxiv.org/pdf/1708.03023.pdf).
 
i.e., A_i(NO PCAL SYS ERR) = 1/eps * A_i(W/ PCAL SYS ERR)
 
In that case, the kappa_T and kappa_P might have been over estimated (seems that the hard coded kappas before 2019-11-12 are generally >1, while the last three are <1). Then when stacking them together in GPR, because of the higher kappas, the data points before 2019-11-12 are pulled below unity. And 1.0043*1.0043 happen to produce an error about 1%. (e.g., GPR TST, GPR PUM from alog 54907)