jeffrey.kissel@LIGO.ORG - posted 17:19, Friday 23 April 2021 - last comment - 18:03, Friday 23 April 2021(58729)
Processed 2021-04-16 H1 ETMX Actuation Coefficient Measurements; 2% and 5% scale error in PUM and TST stages.
J. Driggers, C. Compton, J. Kissel Continuing along the process to reduce the current systematic error in the calibration, I've processed the data that Camilla and Jenne captured on 2021-04-16 (see LHO aLOG 58624) in order to obtain a new estimate for the over-all scale factor of actuation strength for each stage of the H1 SUS ETMX involved in DARM actuation these days (i.e. the UIM or L1, the PUM or L2, and the TST or L3). Here's what I expected going in: UIM: No expected change, since nothin has physically changed in any part of the UIM drive chain. PUM: I expect some sub-10%-level change in strength because these 2021-04-16 measurements were taken with the PUM driver in state 1 (acquire filter OFF, and low-pass filter OFF) instead of the O3 nominal State 3. Not only can the overall gain change, but so can the frequency dependence, since the PUM coils were compensated with a fit to the analog frequency response of State 3. TST: I wouldn't be surprised if there were some sub-10%-level change in strength because it's been many months since we last measured the TST stage actuation strength, and charge drift has been known to change the actuation strength on the time-scale of months (even though we didn't find this to be true during O3, see LHO aLOG 50032 for discussion, supporting data, and statements.) Also: after improving the systematic error in the sensing function on Wednesday (see LHO aLOG 58691), what remained of the response function systematic error (see red trace in 2021-04-21_PCAL_2_DELTALEXT_TF.png) looked to be at the ~8% level, right where we expect the PUM and TST stage to contribute to the response function (see 2021-04-21_PostO3_H1_DARMLoopCritique_ContributionsToR_mag.pdf) Here's what I get: 2021-04-16 Summary UIM [Fit Range: 30 to 100 Hz] --------------------------- kappa_UIM = 0.995366 = 1.62203/1.62958 (TDCF = Value = MAP / REF) Actuation Strength = 7.615e-08 [+0.121%,-0.1213%] (N/ct) Actuation Strength = 1.622 (N/A) 2021-04-16 Summary PUM [Fit Range: 30 to 500 Hz] --------------------------- kappa_PUM = 1.01574 = 0.0300251/0.02956 (TDCF = Value = MAP / REF) Actuation Strength = 6.15e-10 [+0.09933%,-0.09802%] (N/ct) Actuation Strength = 0.03003 (N/A) 2021-04-16 Summary TST [Fit Range: 30 to 800 Hz] --------------------------- kappa_TST = 1.04924 = 4.66918e-11/4.45007e-11 (TDCF = Value = MAP / REF) Actuation Strength = 4.985e-12 [+0.07037%,-0.07019%] (N/ct) Actuation Strength = 4.669e-11 (N/V**2) where the REF values used to determine the \kappa_{iStage} values -- i.e. how much systematic error we have currently in the actuator strengths of each stage -- are from the O3 values for the actuator strength coefficients which are still installed in the CAL-CS front-end portion of the calibration pipeline (i.e. they're the the modelparams_20200103 values that have been copied in to the modelparams_20210417 parameter set made for the sensing function update). So -- with an overall actuator strength scale error of ~2% in the PUM, and ~5% in the TST, I can believe easily that this adds up to the ~8% error we're seeing in the 40-80 Hz region shown in 2021-04-21_PCAL_2_DELTALEXT_TF.png after propagating through the frequency-dependent actuator contribution to the response function . Unfortunately, because of the on-going battles with ASC noise contributions to DARM, the calibration lines don't have enough SNR to corroborate that this is indeed the level of \kappa_TST and \kappa_PUM we expect (see darm_chard_18_CUTOFF.png from early today's LHO aLOG 58722). But, we can always update the coefficients in the CAL-CS DELTAL_EXTERNAL calibration pipeline and see if the response function error gets reduced! For another day.
Non-image files attached to this report
Comments related to this report
Some measurement processing details: (1) Unfortunately, through all fault of my own I'm sure, when Jenne and Camilla did the reasonable thing of grabbing "the most recent template," and hitting "go" with the template for the UIM iEXC2DARM measurement, they unknowingly propagated a flaw in the frequency vector that had crept in from a template two-times-ago (see LHO aLOG 56810). This doesn't render the data useless, but we would otherwise loos 4 data points in the ~15-20 Hz region because the frequency points didn't match up between the PCAL2DARM and the L1_iEXC2DARM templates. So, I took some time and (a) fixed the frequency vector in the template, such that the error doesn't propagate further when the next person does the reasonable thing, and (b) I used some command-line ipython to make a quick interpolation of the data at the 3 wrong frequency points on to data at the 4 frequencies (adding in 2 surrounding data points already at good frequency points to the interpolation to make sure the interpolation smoothly integrated with the rest of the data). I think hand stitched in the interpolated data on the correct frequency points in to _tf and _coh .txt exports. Since the UIM to TST transfer function is very smooth in this frequency region, I see no harm in rescuing this data set in this way. (c) Over wrote the files /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/ 2021-04-16_H1SUSETMX_L1_iEXC2DARM_A_L1CALEXC_B_DARMIN1_coh.txt 2021-04-16_H1SUSETMX_L1_iEXC2DARM_A_L1CALEXC_B_DARMIN1_tf.txt and for historical record, I kept the data with the bad frequency vector here in the same place, but with the following names: 2021-04-16_H1SUSETMX_L1_iEXC2DARM_A_L1CALEXC_B_DARMIN1_Orig_BadFreqVector_coh.txt 2021-04-16_H1SUSETMX_L1_iEXC2DARM_A_L1CALEXC_B_DARMIN1_Orig_BadFreqVector_tf.txt (2) Having sorted that out (and solving a few other text-file-exporting file-name error issues, along with some actuation.py modifications and fixes to deprecated matplotlib keyword updates), I was able to run the standard O3 -like processing script, ^/trunk/Runs/O3/H1/Scripts/FullIFOActuationTFs/process_actuation_MCMC_model20210417_meas20210416.py These produce the above attached plots, as well as an .hdf5 file of the MCMC posteriors, ^/trunk/Runs/O3/H1/Results/Uncertainty/2021-04-23_H1_20210417Model_PCALSYSERR_None_meas2021-04-16_actuationFunction_allstages_MCMC_posteriors.hdf5 just in case we need to make a systematic error budget. Of particular note, I've changed the frequency region of fitting to be [30, 100], [30,100], and [30 to 800] Hz for the UIM, PUM, and TST stages. (a) The lower limit for all stages has been increased because the noise in the DARM spectra prohibits sensible date below 30 Hz. (b) I increased the upper limit to the UIM fitting range from 50 to 100 Hz, because I believe Vlad's good work with the dynamical model of the UIM stage (see LHO aLOG 54519) means that now we trust the there's pretty accurate removal of frequency dependence out to at least 100 Hz. (c) I increased the upper limit to the TST fitting range from 300 to 800 Hz because when previous MCMC was run for O3B measurements in early 2020, we didn't yet understand why the phase of the TST data changed above 300 Hz on 2020-02-24. We now understand this to be a missing 15 kHz pole from a supposedly innocuous electronics clean up, see LHO aLOG 56346 and T2000584 section 4.2.2. That change *only* effects the MCMC estimate of the residual actuator delay, \tau_A_TST, which doesn't matter for the estimate of the actuation strength. Indeed, one see from the bottom right corner of 2021-04-16_H1_20210417Model_PCALSYSERR_None_TST_actuationMeasurement.pdf, the phase residual is nicely flattened by a delay of 6.6 usec, which has the same phase response of ~2-3 degs at ~1 kHz as the missing ~16 kHz pole. (3) With these results, I created a new DARM model parameter set, which lives here: ^/trunk/Runs/O3/H1/params/modelparams_H1_20210423.py This has both the 2021-04-17 sensing function parameter updates from LHO aLOG 58656 and the new actuator strength coefficients from the main aLOG here.