J. Kissel
As a part of the review of the DARM loop model and the real-time / low-latency calibration pipeline, we've begun to make plots that assess the impact of various systematic errors as they creep in from step to step on the way to producing the astrophysically consumed h(t). The places where systematic error can be incurred are:
(1) Measurement to pyDARM model reproduction -- we fail to model what we've measured in the DARM loop (e.g. the L2A2L PUM problem, or the acausal phase rotation with SRC optical spring)
(2) pyDARM model to CAL-CS / Front-end reproduction (real-time IIR filters) -- due to limitations of foton and any real-time digital system, we fail to reproduce pyDARM in the front end
(3) pyDARM model to GDS reproduction (low-latency FIR filters) -- due to the limitations if FIR filtering and limits of low-latency, we fail to reproduce pyDARM
(4) pyDARM model to time-dependent correction factor production -- due to errors in producing pyDARM at the calibration line frequencies, or limitations of averaging over long time-scales, we fail to properly correct for real time-dependence.
This aLOG quantifies (2) for H1.
In summary,
- the reproduction of (the inverse of) the sensing function, C, has been done very well, and thus incurs very very little systematic error.
- the reproduction of the various stages of the actuation function, A, are good but not awesome, and thus incur a frequency-dependent systematic error "wiggle" at the 0.5% / 0.5 deg level between 5 and 100 Hz, with some sharp features at ~100 Hz that arise from poor modeling and lack of implementation of the UIM high frequency dynamics.
These are sufficiently small, and within current uncertainty estimates, so we won't do anything about it in the near term.
But, you read that right: the UIM is the biggest contributor to influencing the systematic error in the overall response function (OK, at the 0.5% / 0.5 deg level) up to ~200 Hz. This is understandable -- because the other two actuator stages, PUM and TST, are "in-band" and have had more pressing, larger systematic errors to-date -- we've not used any person power on improving it since O2. Thus, it remains essentially an O2 reproduction of an O2 loop model that did not have any high-frequency dynamics included, which also are known to have changed since O2 anyways. But, alas, I get ahead of myself.
For all the below comparisons, I've measured the transfer function of the real CAL-CS system (driving where DARM_ERR and DARM_CTRL enter in to the system, and measuring the response just before all stages are combined), and then multiplied it by the same correction factors from pyDARM that produce the GDS FIR filters (and thus I do not incur error for step 3 listed above). This is a repeat of LHO aLOG 48215, but needed because we'd not re-measured after installing the now-running O3 parameters/filters (installed on 2019-04-04, LHO aLOG 48378). I'll add a comment that documents the DTT templates and processing scripts for this data set.
Check out the attached plots.
- 2019-05-01_H1_C_pyDARM_vs_CALCS.pdf
This is the comparison between the installed, measured CAL-CS (inverse) sensing function -- multiplied by pyDARM produced GDS corrections -- and the full pyDARM model of (inverse) C. One can see there is MUCH less than 0.1% / 0.1 deg systematic error between these two. Nice!
- 2019-05-01_H1_CALCSvspyDARM_actuation.pdf
Page 1: This is a "big picture", side-by-side comparison between the pyDARM model and CAL-CS measurement (* GDS Corrections) of each actuator stage and total to give you a feel for the complexity of the functions, and to show where the broadband measurement was limited and turns in to noise -- i.e. above ~200 Hz.
Page 2: Here we show the standard comparison and residual (i.e. ratio of) between "quad bode plot" of the CALCS (* GDS corrections) measurement and pyDARM model for the overall actuation function. One can see there is residual between the measurement and model, i.e. CAL-CS (* GDS corrections) has not accurately reproduced the pyDARM model and thus the CALCS real-time system has error at the 0.5% / 0.5 deg level between 5 and 200 Hz.
Page 3: How this systematic error impact the overall response function, of course, depends on the DARM loop shaping, so here, we plot the ratio of two response functions, R = (1 + C*D*A) / C; one with the systematic error, and one without,
from modelparams_H1_20190416 import modelPars
[D, C, A, G, CLG, R, sensProd, actProd] = computeDARM(modelPars(), freq)
delA = actProd.calcs2gdsResidActFiltOut_NoDAQDownSample
R_pyDARM = R
R_CALCSGDS = (1.0 + C * D * (calcs_A_tf*delA) ) / C
sysErr_R = R_CALCSGDS / R_pyDARM
In this plot you see a response function systematic error, sysErr_R, that roughly follows the shape of the actuator systematic error below the DARM UGF (at ~60 Hz), and then -- because of the phase flaws and not-so fast roll-off of the actuator -- there is further influence and sharp features above the DARM UGF up to 200 Hz.
Since I measured the individual stages, I can compare each stage against model, to understand from where the dominant frequency dependent systematic error arises.
Page 4: The TST stage. Looks great, very little systematic error incurred. Flat, less than 0.1%/0.4 deg error between 5 and 200 Hz. Odds are that the phase error that's increasing with frequency is a result of the GDS corrections in pyDARM errantly excluding the super-Nyquist poles from the ESD driver electronics; a known bug that's on the to-do list: LHO aLOG 12689.
Page 5: The PUM stage. Looks great, very little systematic error incurred. Flat, less than 0.1%/0.2 deg error between 5 and 200 Hz.
Page 6: The UIM stage -- with its magnitude residual zoomed out to show the large amount of error -- 10 % by 40 Hz, a factor of 2 by 90 Hz, leading up to the high-Q resonance just down-right missing the from the CAL-CS reproduction of the pyDARM model. These high Q features are the source of the high Q features that make their way all the qay in to the systematic error in the response function.
Page 7: The UIM stage -- with its magnitude residual zoomed in to what should be a reasonable range of 5%. No bueno.
One should note, that in addition to this type (2), pyDARM model to CAL-CS implementation, systematic error, there is already some type (1), measurement to pyDARM model, systematic error in the pyDARM model of the UIM that is not shown.
Remember -- all QUADs have UIM to TST force-to-length transfer functions that don't fall as 1/f^6 as one might naively expect (see LHO aLOG 38295).
The current dynamical model that is the source of all the high Q features in pages 6 & 7 was updated in O3 with the fit informed by measurement of the O2 high frequency dynamics of the ETMY UIM stage just to get *something* functional to use in the estimate of the UIM actuator strength.
Though there are measurements in-the-can of the O3, they've not yet been fit or used to update the dynamical model.
Anyways -- again -- we won't DO anything about this, at least in the short term, but we can now safely say that this particular systematic error is well-characterized, and is sufficiently within our uncertainty estimate.
When locking DRMI, I couldn't improve POP18 more than 55 or so. I decided to move on, and there was no dip in this signal even after engaging the ASC, but it broke lock at the DARM_TO_RF state. I'm going to run and initial alignment and see what it looks like after. If this works well, then I've had to run an initial alignment after every lock loss this week...