Displaying report 1-1 of 1.
Reports until 17:54, Wednesday 27 March 2019
H1 CAL (DetChar, ISC, Lockloss)
jeffrey.kissel@LIGO.ORG - posted 17:54, Wednesday 27 March 2019 - last comment - 15:36, Thursday 28 March 2019(47941)
Full Calibration Measurement Suite Complete; Measurements Processed, Reference Updated, Ready to Update CAL-CS
J. Driggers, S. Dwyer, J. Kissel, L. Sun

We have measured the full suite of calibration measurements today. After processing, they look of excellent quality, and we believe we understand all of the systematic error that we see. This systematic error is small enough, and impacting the overall response function uncertainty in various frequency regions in such a way that we are comfortable pushing this results to the front-end and updating the calibration.

Said again in less words: we are ready to update the front-end calibration (CAL-CS, CAL_DELTAL_EXTERNAL, etc.) with the results quoted below.

Status of systematic error
   - We have a prominent detuning below 20 Hz, and it's pro-spring. The fit to and implementation of compensation for a pro-spring is still in it's infancy, so it is under-reporting the frequency -- it's measured to be about 6.5 Hz, but the fit claims 3.7 Hz. The systematic error induced by this flaw is small above 20 Hz. 
   - The TST actuator stage is modeled quite perfectly. Little to no systematic error.
   - The PUM actuator systematic error remains below 20 Hz. We've identified that it's parasitic length drive not accounted for through L2A / A2L. This is prominent because the IFO spot positions on ETMX are -18 +/- 0.2 mm in pitch (-vertical) and 18 mm +/- 0.2 in yaw (+transverse) off from the center. (note for PCAL team -- ETMY spot positions: -17 +/- 0.2 mm (-vertical) and 7.5 +/- 0.2 mm (+transverse))
   - The UIM actuator systematic error starts to creep in around 50 Hz. This is understood to be the high frequency dynamics of the UIM BOSEM actuators, and we have measurements in the can to fix this, we just haven't yet had the time. As it stands, the impact of this error is smaller than other things, so it remains low on the priority list.

Lilli is working on estimating the overall uncertainty and systematic error that would result from these residual systematic errors from each stage -- see the start of this in LHO aLOG 47926. 

Here're the values we will use to update CAL-CS today.
Sensing Function
Optical Plant:
    Optical gain, H_c (ct/m)                 | 3.254e+06 (+3253,-2286)         or (+0.09994%,-0.07023%)
    Optical gain, H_c (mA/pm)                | 4.345     (+0.004343,-0.003052) or (+0.09994%,-0.07023%)
    Cavity pole, f_cc (Hz)                   | 410.5     (+1.156,-1.314)       or (+0.2816%,-0.3202%)
    Detuned SRC spring frequency, f_s (Hz)   | 3.744     (+0.0717,-0.07096)    or (+1.915%,-1.895%)
    Detuned SRC spring quality factor, Q_s   | 45.57     (+77.6,-123.2)        or (+58.72%,-36.99%)
    Residual time delay, tau_c (usec)        | 1.434     (+0.8076,-0.9042)     or (+56.32%,-63.06%)


The code spits out (filters for go in the H1:CAL-CS_DARM_ERR_Name08):
Inverse Sensing FOTON values: [NB: SRCD2N zpk gain based on sensing sign in parameters file]
    SRCD2N: zpk([410.6047;0.0000+3.7096j;0.0000-3.7887j],[0.1;0.1;7000],1,"n")gain(1405.76)
    Gain: gain(3.073e-07)

Inverse Sensing without cavity pole FOTON values for CFTD path: [NB: SRCD2N zpk gain based on sensing sign in parameters file]
    SRCD2N: zpk([0.0000+3.7096j;0.0000-3.7887j],[0.1;0.1],1,"n")gain(1405.76)
    Gain: gain(3.073e-07)

But these values (a) are unphysical, (b) incorrectly calculating the zeros for an anti-spring (a la LHO aLOG 31693), and (c) normalizing the gain of the filter at 500 Hz instead of 100 Hz. We'll fix this later. For now, we've just manually crafted the filter in foton, which has a complex zero at 3.744 Hz with a Q of 45.57,
    Normal Path -- SRCD2N: zpk([410.6047;0.0411+i*3.7438;0.0411-i*3.7438],[0.1;0.1;7000],1,"n")gain(1364.02)

    CFTD Path   -- SRCD2N: zpk([0.0411+i*3.7438;0.0411-i*3.7438],[0.1;0.1],1,"n")gain(1364.02)
These will be installed into H1:CAL-CS_DARM_ERR and H1:CAL-CS_DARM_CFTD_ERR filter banks in modules titled "O3_D2N" and "O3Gain".

Actuator
UIM
    Actuator gain, H_c (N/ct)              | 7.699e-08 (+2.588e-11,-2.585e-11) or (+0.03362%,-0.03357%)
    Residual time delay, tau_A (usec)      | 64.69     (+1.52,-1.513)          or (+2.35%,-2.339%)

PUM
    Actuator gain, H_c (N/ct)              | 6.118e-10 (+1.677e-13,-1.686e-13) or (+0.02742%,-0.02756%)
    Residual time delay, tau_A (usec)      | 2.088     (+0.9309,-0.9287)       or (+44.57%,-44.47%)

TST
    Actuator gain, H_c (N/ct)              | 4.739e-12 (+1.36e-15,-1.368e-15) or (+0.02869%,-0.02886%)
    Residual time delay, tau_A (usec)      | 7.474     (+0.542,-0.5453)       or (+7.252%,-7.297%)

These gains will be installed into the H1:CAL-CS_DARM_ANALOG_ETMX_[L1, L2, L3] banks, in modules titled "Npct_O3"

The pyDARM model parameters for this data set live here:
    ^/trunk/Runs/O3/H1/params/modelparams_H1_20190327.py

I'll post more details about processing scripts and where the data lives in a comment below.

Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 18:35, Wednesday 27 March 2019 (47948)
I've exported the above inverse sensing function (the CAL-CS_DARM_ERR filter bank, module FM9 "O3_D2N") for the GDS pipeline to correct for foton's IIR warping of the 7000 Hz, high-frequency roll-off pole.

It now lives in 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/Foton/2019-03-27_H1CALCS_InverseSensingFunction_Foton_SRCD-2N_Gain_tf.txt

I've updated and commited the 20190327 model file to read in this new export.
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/modelparams_H1_20190327.py

Because we always ask ourselves how these are exported:
    (1) Open the H1CALCS.txt file in foton
    (2) On the "design" tab, select the appropriate D2N filter (in this case "O3_D2N")
    (3) Under "plotting" make fStart = 0.01, and fStop = 10000 and Number of Points = 1001. Leave all other parameters as their default.
    (4) Hit Bode Plot
    (5) Either "File > Export" or hit the "Export" button.
    (6) Select data type Transfer Function, select Column 0, and export A: current_in and B: current_out, with Conv. "as is."

Then save the file to the above mentioned Measurements/Foton/ directory with an appropriate date.

This should produce a 1000 line text file, with three columns: frequency, real part, imaginary part.

On the to-do list: automate this.

Remember -- we actually have to have *foton* process the transfer function coefficients because (of course) it has a different pre-warping algorithm than matlab or python. See G1801581.
Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 18:42, Wednesday 27 March 2019 (47950)
Data templates taken to support this entry
Sensing Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
    2019-03-27_H1DARM_OLGTF_5to1100Hz_30min.xml
    2019-03-27_H1_PCAL2DARM_TF_5t1100Hz_15min.xml

    2019-03-27_H1_OMCDCPDSUM_to_DARMIN1.xml

    2019-03-27_H1DARM_OLGTF_BB.xml
    2019-03-27_H1_PCAL2DARMTF_BB.xml

Actuation Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/
    2019-03-27_H1SUSETMX_L1_iEXC2DARM_25min.xml
    2019-03-27_H1SUSETMX_L1_PCAL2DARM_8min.xml
    2019-03-27_H1SUSETMX_L2_iEXC2DARM_17min.xml
    2019-03-27_H1SUSETMX_L2_PCAL2DARM_8min.xml
    2019-03-27_H1SUSETMX_L3_iEXC2DARM_8min.xml
    2019-03-27_H1SUSETMX_L3_PCAL2DARM_8min.xml

Scripts that process the data
Sensing Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs
    process_sensingmeas_20190327.py

Actuation Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOActuationTFs
    process_actuationmeas_20190327.py
jenne.driggers@LIGO.ORG - 18:43, Wednesday 27 March 2019 (47951)

These parameters are now in the filter modules that Jeff quotes, and I have accepted in both the safe.snap and OBSERVE.snap to be using the filter modules with "O3" in the name.  For the last while (days?weeks?) we've been putting things in the filter modules with "ER14" in the name.  Those still exist, but aren't in use anymore. 

Also, the gain of H1:CAL-CS_DARM_ERR_GAIN had been reverted (likely on Tuesday?) to the value of 1.03.  I have again put it to the nominal value of 1.00 and accepted this in SDF.

jeffrey.kissel@LIGO.ORG - 19:00, Wednesday 27 March 2019 (47952)
I've processed the DARM open loop gain transfer function, and computed the relative delay between the Actuation and Sensing Paths. 

The systematic error in the DARM open loop gain transfer function below 30 Hz is understood based on the results discussed above, and for now, we must tolerate them.

However, for the first time, we appear to have an appreciable, non-integer 16 kHz clock-cycle delay between the Actuation and Sensing paths: 7.653 clock cycles.
Sounds like it's finally time for me to import the thiran filter delay technology from LLO.

Scripts to produce these plots:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/DARMOLGTFs/
    process_darmolg_20190327.py

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE/
    compute_relativedelay_AvsC_20190327.py
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 19:29, Wednesday 27 March 2019 (47953)
I've used the above mentioned model to write new reference model parameters for the computation of time dependent correction factors, a.k.a. "the" EPICs records.


Script to create the records:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE
     createEPICS_for_20190327.py

Location of generated EPICs records:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/CALCS_FE/
     epicsrecords_model-H1_20190327_created-20190327.txt

Model file used:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params
     modelparams_H1_20190327.py

Attached are screenshots of the corresponding MEDM screen and SDF acceptance *after* the EPICs records were pushed.
Images attached to this comment
Non-image files attached to this comment
keita.kawabe@LIGO.ORG - 15:36, Thursday 28 March 2019 (48008)

H1 control room matlab (matlab2015b) was too old to be able to use autoquack, but joeb was able to do that for us using matlab2018.

cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PostO2/L1/Scripts/CAL_FE_DELAY

fs=2^14

ts=1/fs

td=7.653*ts

populate_cal_fe_delay('H1', td)

Took the diff with the original filter in the control room and it only has one filter "delay" defined in CS_DARM_CTRL_DELAY, everything else is the same.

diff /opt/rtcds/lho/h1/chans/H1CALCS.txt ~/H1CALCS.txt

780a781,787
> # DESIGN   CS_DARM_CTRL_DELAY 0 zpk([-3495.762131159507+i*542.3606112515328;-3495.762131159507-i*542.3606112515328;
> #                               -3679.520087768798+i*1130.184746679708;-3679.520087768798-i*1130.184746679708;
> #                               -4186.607279464874-i*1784.0262722568;-4186.607279464874+i*1784.0262722568;-3445.944679249666;
> #                               -6825.617444279973],[3495.762131159505+i*542.3606112515323;3495.762131159505-i*542.3606112515323;
> #                               3679.520087768799+i*1130.184746679708;3679.520087768799-i*1130.184746679708;
> #                               4186.607279464874+i*1784.0262722568;4186.607279464874-i*1784.026272256801;3445.944679249668;
> #                               6825.617444279969],-1.000000000000004,"n")
781a789,792
> CS_DARM_CTRL_DELAY 0 21 4      0      0 delay      -1.546135588596514307051190e-06  -0.2162350800222442   0.0174983720374032   3.6925487491949833  20.2756341393376971
>                                                                  -0.0968548102303960   0.0247770268878642  -3.9090569933487744  40.3599675023881517
>                                                                   0.1821175467962750   0.0493202823215208 -12.3574398555497709  57.1481734336473011
>                                                                   0.4517859341185633  -0.0723061411729160  -6.2482373805309441 -13.8300839151207331

The delay filter has about the right delay (attached, -168.729deg @ 1kHz ~7.68 clock cycles for 2^14Hz sampling).

The new file was installed, the new filter loaded.

Images attached to this comment
Displaying report 1-1 of 1.