Displaying report 1-1 of 1.
Reports until 19:28, Thursday 10 September 2015
H1 CAL (CAL, DetChar, INJ, ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 19:28, Thursday 10 September 2015 - last comment - 16:15, Sunday 13 September 2015(21386)
CAL-CS Calibration Parameters Updated; Info on DARM Loop Parameters for which GDS Pipeline will Compensate
J. Kissel, for the LHO CAL Team

Spoiler Alert: Kiwamu has updated the sensing side of front-end calibration, and has tuned the CAL-CS model to match a fit to the current optical gain of this lock stretch. 
This means the CAL-CS calibration has been updated, and is now complete for O1.

He has analyzed the results, and created the cannonical parameter set for O1. That parameter set is:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1125963332.m

This should be run with the now canonical model:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m

To push things forward while he gets a final super-long integration time comparison between PCAL and the CAL-CS model, we give this parameter set to Maddie such that she can you it to inform the parameters of the high-frequency corrections to the output of the CAL-CS model.

In summary, those corrections are 
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains
(2) The compensation for the average of the uncompensated, high-frequency poles in the OMC DCPD's readout chain.

%% Details:
Note that, though there are uncompensated, 24e3 [Hz] poles in the ESD response portion of the actuation chain, we have chosen in ER8/O1 to ignore these poles. Preliminary results from craig indicate that we're sitting at ~3 or 4 degrees strain uncertainty at 30 [Hz] (right where the PUM / TST cross-over lies, as expected)  and ignoring this pole corresponds to a 0.07 [deg] systematic error, i.e. negligible. So, the above two items should be the only difference between the CAL-CS front-end model (the relative time-delay between the paths, which affects ERR and CTRL crossover, and the uncompensated poles, which means there's a 15 [deg] phase loss at 1 [kHz]).

To obtain these values from code in the SVN, run
[openloop,par] = H1DARMOLGTFmodel_ER8(H1DARMparams_1125963332);
and the values you (Maddie) need(s) are
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains:
    - Sensing Delay (or Inverse sensing advance): par.t.sensing + par.t.armDelay =  8.9618e-05 [s]
    - Actuation Delay: par.t.actuation = 1.4496e-04 [s]

(2) The high-frequency poles in the OMC DCPD's readout chain:
    - par.C.uncompensatedomcpoles_Hz = 13700       17800       14570       18525       98650 [Hz]
    or you can use the preformulated LTI object,
    - par.C.uncompensatedomcdcpd.c
           ans =
                                    6.3585e+25
         ----------------------------------------------------------------
         (s+8.608e04) (s+9.155e04) (s+1.118e05) (s+1.164e05) (s+6.198e05)


Stay tuned for aLOGs from Maddie over the next day or so, as she compares the output of the CAL-CS model with the output of the GDS pipeline.

Thanks to everyone for all the hard work!!
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:15, Sunday 13 September 2015 (21472)
M. Wade, J. Kissel

In the above list of for what the GDS pipeline must correct, I've neglected several pieces of both chains -- the anti-aliasing and anti-imaging filters of the sensing and actuation chains, respectively. I've slept a little more, and I repeat the list that is now complete:

In summary, those corrections are 
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains
(2) The compensation for the average of the uncompensated, high-frequency poles in the OMC DCPD's readout chain.
(3) The digital and analog anti-aliasing filters in the sensing chain
(4) The digital and analog anti-imaging filters in the actuation chain

In more detail,

Actuation: 
(1) Actuation Delay
   -- par.t.actuation = 1.4496e-04 [s]

     
(3) The digital and analog anti-imaging filters (now separated, due their export as LTI objects; they cannot be combined (without squeezing on to a frequency vector) because one is a discrete zpk, the other is a continuous) 
Digital Anti-Imaging Filter (a.k.a. IOP up-sampling filter) 
   -- par.A.antiimaging.digital.response.ssd
Analog Anti-Imaging Filter 
   -- par.A.antiimaging.analog.c

Sensing
(1) Sensing Delay (or Inverse sensing advance): 
   -- par.t.sensing + par.t.armDelay =  8.9618e-05 [s]

(2) The high-frequency poles in the OMC DCPD's readout chain:
   -- par.C.uncompensatedomcpoles_Hz

(4) The digital and analog anti aliasing filter 
Digital Anti-Aliasing Filter (a.k.a. IOP down-sampling filter)
   -- par.C.antialiasing.digital.response.ssd
Analog Anti- Aliasing Filter 
   -- par.C.antialiasing.analog.c
Displaying report 1-1 of 1.