jeffrey.kissel@LIGO.ORG - posted 12:59, Wednesday 21 April 2021 - last comment - 16:52, Friday 23 April 2021(58691)
CAL-CS / DELTAL_EXTERNAL Calibration Updated; Systematic Error Improved
J. Kissel I installed new filters and values of the DARM model to the CAL-CS aka DELTAL_EXTERNAL calibration (whose parameters are discussed in LHO aLOG 58656, and based on measurements from 2021-04-17 from LHO aLOG 58629). The only major change is that the new model accounts for the newly high cavity pole frequency (450.8 Hz instead of 410.3 Hz) and optical gain (10% more than typical O3). As such, this improves the DELTAL_EXTERNAL systematic error above ~100 Hz dramatically -- see change from BLUE to RED. See 2021-04-21_PCAL_2_DELTALEXT_TF.png for a comparison of response function systematic error (equivalent to DELTAL_EXTERNAL systematic error) over the past week vs. O3B. I note that because we're not yet as awesome in sensitivity as we were in O3 (see 2021-04-21_H1_DARM_FOM.png; no squeezer, still tuning ISC control system noises with new ITMs), we don't have nearly as good SNR on measurement below 30-40 Hz. As such, when I looked at the front-end produced TDCFs to start to update those, the info was garbage because the calibration lines were not above O3B-level-noise uncertainty. After increasing the uncertainty thresholds from 0.2% to 5%, I was able to start to see front-end TDCFs being computed, so then I updated the "EPICs records" (the realized values of various transfer functions and TF ratios from the DARM model at calibration line frequencies). Check out 2021-04-21_H1_CAL-CS_TDEP_PostSensingChange_EPICSRecordUpdate_MEDMOVERVIEW.png for these new settings (and also, these settings are more legible in the text file mentioned in HO aLOG 58656). As expected after these fixes the sensing function TDCFs (the relative optical gain, \kappa_C, and the cavity pole frequency) became reasonable. See 2021-04-21_H1_CAL-CS_TDEP_PostSensingChange_EPICSRecordUpdate_NoRawData.png. Note we also see no change in actuator TDCFs across the update, which is to be expected, but these do show (noisy) signs of them being off a bit, which I surmise is some of what's left of the systematic error. I do note, though, that both the broad-band injections, (the to-be-posted full-frequency-band-PCAL2DELTAL-sweep), and these newly fixed TDCFs all point to that the optical gain and cavity pole are lower than they were on Monday. This is also consistent with the change from the difference between the 2021-04-17 broad band measurements and today's 2021-04-21 pre CAL change curve. More details to follow.
Images attached to this report
Comments related to this report
When actually installing the EPICS records using the "-p" flag of
^/trunk/Runs/O3/H1/Scripts/CALCS_FE/createEPICS_for_20210417.py
I get several errors that are related (I think) to trying to write old EPICs records to non-existent channels.
@Aaron, @Maddie, and @Evan -- can confirm that the channels in the attached text file are no longer needed, and we should update the "computeEPICS" and "writeEPICS" functions in
^/trunk/Common/pyDARM/src/computeDARM.py
either to:
(a) remove the unused EPICs records from the "out" dictionary definition starting on line 507 of computeDARM.py that defines the epics records used by createEPICS_for_20210417.py -like scripts, or
(b) in writeEPICs, filter out channels that are not used by the front-end in when the "push to epics" flag is invoked.
Also -- in terms of the scripts like createEPICS_for_20210417, when we request the "--pushtofe" option (which calls computeDARM.py's writeEPICS function with pushToEPICs=False), it'd be nice if we can read in a pre-generated epicsrecords*.txt file, rather than having to generate a new one (i.e over-write a pre-generated one). It'll require a bit of re-ordering of the conditionals in writeEPICs.
Non-image files attached to this comment
Reconciling SDF to make sure this new improved calibration sticks: Attachments of SDF DIFFs I've just now accepted show the changes: (1) The change of old 410.3 Hz and 10% lower gain filters to the new 450.8 Hz and 10% higher optical gain in the CAL-CS_DARM_ERR bank. (2) The increase of uncertainty threshold on the calibration lines to allow for TDCF computation needed because the < 40 Hz DARM noise is much higher than O3. (3) The update to the timing advance needed to account for the 61 us, one 16kHz clock-cycle, computer jump, delay on the PCAL and ETMX calibration lines as they appear in the corner station (no actual change, because we haven't yet updated the 410.3 Hz calibration line frequency to match the new 450.8 Hz cavity pole frequency). (4) The update to all of the DARM loop model transfer function values at calibration line frequencies (actually changed, because the sensing function has changed).
Images attached to this comment
A. Viets, J. Kissel
Aaron fixed the above bug in which
^/trunk/Common/pyDARM/src/computeDARM.py
functions createEPICS computes *several* more epics records that are needed for his recent efforts in calculating an exact solution to computing the TDCFs (see details in P2100107). These methods have not yet been implemented in the front-end, so the channels the *other* computeDARM function, writeEPICS, was trying write do not yet exist, and hence errors were thrown by caput and ezca.
I've confirmed that no more errors are thrown.
I modified
^/trunk/Runs/O3/H1/Scripts/CALCS_FE/createEPICS_for_20210417.py
and wrote a new epicsrecords file,
^/trunk/Runs/O3/H1/Results/CALCS_FE/epicsrecords_model-H1_20210417_created-20210422.txt
and pushed the epics records to the needed *existing* channels.
Since I accepted the yesterday installed epicsrecords into SDF jus before doing this, I confirm that the values of what's now installed from the "created-20210422.txt" are no different than the "created-20210419.txt," because I see no SDF differences.
Thanks Aaron!
Since I haven't seen one in a while, here are plots of the magnitude of relative contribution of each major part of the response function in the calibration, using - the 2021-04-17 DARM model parameter set with the updated sensing function: [...]PostO3[...].pdf - the same plot using the O3B, 2020-01-03, model parameter set for comparison: [...]O3B[...].pdf The most obvious change, and it's not obvious at all, is that the (inverse) sensing function contributes just a wee bit more than before, because of the overall gain and cavity pole frequency changes. There're no changes in the actuator portion of model parameters, so the only change in their contribution seen is due to the relatively larger contribution of the sensing function. I post this merely to remind folks that even scalar systematic error in an overall gain of one of these components results in a frequency dependent contribution to the response function's systematic error, i.e. plots like 2021-04-21_PCAL_2_DELTALEXT_TF.png shown above. These plots were produced with the function /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/plotAuthorityContribution.py in the following fashion: python plotAuthorityContribution.py --IFO 'LHO' --modelPath /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename modelparams_H1_20210417 --IFOmodel modelPars --plotFile /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Critique/2021-04-21_PostO3_H1_DARMLoopCritique_ContributionsToR_mag.pdf --plotType 'Cont'
Non-image files attached to this comment
