J. Driggers, J. Kissel, L. Sun
Today, during the calibration measurement time, we've done the following:
(1) Tuned the calibration line heights such that the uncertainty of each line is now roughly 0.2%.
2019-04-17_TuningCalibrationLineAmplitudes_Uncertainty.png shows the time series of the uncertainty for all calibration lines over many hours before and after the line amplitude change -- the middle section is where they were turned off for the standard suite of calibration sweeps; before they were at their former value, after they were at their current value.
(2) We realized the discrepancy between GDS production of kappa_C (the relative optical gain correction) and f_cc (the cavity pole frequency) and CAL-CS was because in the heat of battle yesterday, we neglected to update the value of the necessary one clock-cycle delay to 410.3 Hz in the PCAL DEMOD -- i.e. it errantly remained as the delay value at the former calibration line frequency at ~331 Hz. Fixing this error returned the time-dependent correction factors to the expected values from the reference model: kappa_C = 1.00 +/- 0.01, and f_cc = 410.6 +/- a few Hz (as opposed to the brief period yesterday between after the calibration line frequencies and now, where the cavity pole was reporting in the 425 Hz region, and the optical gain correction was reporting 0.97).
2019-04-17_FixingPCALDEMODPhase_410Hz_Fixes_TDCFs.png shows a screenshot of the current values.
(3) We gather a collection of broad-band PCAL injections, as well as the standard sensing function sweeps.
Times of broad-band PCAL injections: 2019-04-17 20:13:20 UTC for ~2 minutes, and again at Apr 17 2019 20:15:31 UTC.
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
2019-04-17_H1_DARM_OLGTF_SS_5to1100Hz_15min.xml
2019-04-17_H1_PCAL2DARMTF_BB.xml
2019-04-17_H1_PCAL2DARMTF_SS_5t1100Hz_10min.xml
The data remains remarkably consistent with the reference model (see 2019-04-17_H1_sensingFunction_mcmcModel_vs_measurement.pdf ).
We've stacked all the recent sensing function measurements without correcting for time dependence to form an estimate of the frequency dependent, time-independent systematic erro with a Gaussian process regression, and it shows the same consistency (see 20190416_ref_model_H1_sensingFunction_GPR_on_AllSensingMeasurements.pdf)
More details to come.
Here is a look at one of the excursion that happened in the front-end estimation of kappa_tst (first one seen in this summary page). The attached plot show various estimations of kappa_tst that happens in the front-end. It also show uncertainty estimation in the calculation of calibration line ratios. We see that when the uncertainty in the estimation of calibration line ratios exceeds set threshold of 0.02, it triggers the gating function. Since the glitch happened to be in the DARM_ERR (IFO) both PCAL_LINE1/DARM_ERR and TST/DARM_ERR ratios get uncertainties higher than 0.02 as in this case. The KAPPA_TST_GATE_UNC_INPUT which is finally used, according to model, supposed to be maximum of the two uncertainties but in this case it is the minimum of the two (KAPPA_TST_GATE_UNC_INPUT is on top of SUS_LINE3_UNCERTAINTY). Since it is still larger than 0.02, gating is triggered. However the gated kappa_tst values don't make any sense. It supposed to be avoid the excursion in the raw kappa_tst but it seems to change the level values of kappa_tst. This function need to checked (this is a user defined c function block). The signals after that make sense.
Similar plot for LLO which also show similar problem with gating function block.
Turns out the switch blocks used were defaulting to a logic comparison of >= 0 instead of > 0. Which means the first input was always being passed. I'll update this in the common CAL_CS_MASTER.mdl file and we should be able to push that next Tuesday. The gating issue is a bit trickier. As far as I can tell the gate is doing what its supposed to do. At the time the uncertainty rises above threshold, it freezes then and there as shown in Shivaraj's plots. The problem is, since the uncertainty calculation is basically on a cadence of 10 seconds, there's a 10 second gap between the demodulated low pass starting to respond to a large excursion and the I think this means we need to put 10 seconds (or maybe a touch longer) buffer between the kappa value input to the gate, so that the coherence corresponds represents the data coming in instead of data that came in during the last 10 seconds. A 163840 or so sample ring buffer is doable, but I'll have to modify a C code user block to do so.