Jenne, Sheila

After a long talk with Keita and Joe B on the phone we have updated the calibration epics records that are used to calculate the kappas.  

Joe walked us through how to update the epics records.  We made a new copy of the paramter file in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/modelparams_H1_20190316.py

We updated the validity time, modelDate, Optical gain, cavity pole, spring frequency and Q based on Craig's fit here. We measured a transfer function from DARM_IN1 to the OMCDCPD sum during last nights lock and used that to update omcdcpdout2darmin1tf  There is a parameter for changing the sensing sign in this parameter file, but we have not changed that.  It looks like last night's sign flip in the inverse sensing function (47574) didn't have an impact on the kappa calculation here, but we would like to double check with the calibration group that this is OK.  

We then followed Joe's instructions to create /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE/createEPICS_for_20190316.py  the only changes we made to this from earlier versions were to point to the new parameter file and to add a new argument to the computeEPICS function for the third pcal frequency (1083).

epics = computeEPICS(pars, f_pcal1, f_uim, f_pum, f_tst, f_pcal2, f_pcal4, f_pcal3)

The resulting change to the calcaulted paramters is shown in the attached screenshot, the kappas all seem more reasonable than before, the spring frequency and Q have gone to zero. 

Joe B had told us that we would need to adjust the demod phase for the calibration lines in the front end to get the real time cavity pole (and maybe other factors) correct, related to LLO log 44005 I've added changed the demod phases, setting the demod phase to -360*freq/16384 for each of the pcal demods eg.  H1:CAL-CS_TDEP_PCAL_LINE1_PCAL_DEMOD_PHASE 

With these phase shifts, the cavity pole is now reading 429 Hz, so this seems good.  (To clarify, I didn't mean to say the cavity pole is at it's best possible value, as Peter points out, but that the time depedent factor is reporting a value close to the measured value that Craig posted 47493)