Reports until 14:36, Monday 17 January 2022
H1 CAL (DetChar, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 14:36, Monday 17 January 2022 - last comment - 15:16, Tuesday 22 February 2022(61313)
Measured and Fit PUM Driver Response for ETMX and ETMY
J. Kissel
WP 10150
ECR E2100204
IIET Ticket 21642 21642

Continuing along on the campaign to make actuator electronics response compensation truly negligible, I've now measured and fit ETMX and ETMY's PUM drivers (S1000343 and S1102652, respectively) after Fil modified the circuits as per ECR E2100204 in Early Dec 2021 (see LHO:60972).

Following the techniques and lessons (re-)learned from my experience with the ITMs (see LHO:61280), I'm happy to report the I've also achieved *very* low noise data of the ETM PUM drivers over 0.2 Hz to 10 kHz, from which I was able to extract low-order, sub-Nyquist frequency, (almost all) real zero:pole pair fits that leave a residual (ratio of measurement / fit) better than magnitude and phase of 0.001 and 0.1 deg between 1 Hz and 2 kHz. This should allow for compensation in the COILOUTF banks to be equally exquisite.

%%%% Data, Fitting, Results %%%

Most of the details of the procedure is documented in the ITMs' aLOG (again, LHO:61280). However, since the measurement setup I used wasn't hashed out until the comments (LHO:61289) after looking at my own data and talking with Joe Betzwieser, I highlight D1900027-v3_CoilDriverChassisSetup.pdf under -v3 of D1900027 as the collection of measurement setups. Also, unlike the ITMs, the measurement setup's transfer function (the SR785 and Accessory box alone; page 3 of D1900027-v3_CoilDriverChassisSetup.pdf) has been divided out of all transfer functions.

Raw data:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/SUSElectronics/ITMX/PUM/2022-01-10/
and
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/SUSElectronics/ITMY/PUM/2022-01-11/

Processing / Fitting / Plotting script:
     /ligo/gitcommon/suspensions/ligo/electronics/fits/
        fit_ETMX_PUM_driver_20220114.py
        fit_ETMY_PUM_driver_20220117.py
where again IIRrational is the work horse for the fitting.

All relevant result summaries are attached. For the list of zeros and poles, see the "*FitResults.txt" text files. "*ResidualSummary.pdf"s show the data, fit, and residuals (ratios of meas / fit). All 

%%%% Commentary %%%% 
(1) As with the ITMs, there are a few oddball states of a few channels -- ETMY State 2 LL, ETMY State 3 LL, and ETMX State 3/State 1 ratio UR -- but otherwise I'm quite happy with the results, as even these oddballs just have a *little* bit of phase between a complex pole pair, or an extra set of nearly canceling (real) z:p pairs. IIRrational already has built in "fitting order" reduction into it, but I also get it a relatively low upper bound on the order as a seed -- namely 2, 4, 4, 3, for fitting State 1, 2, 3, and the 3/1 ratio, respectively, and for each of these, the order was reduced further to 1, 2, 2, and 2.

(2) As before, in State 2, the fit suggests a nearly cancelling z:p = [43 kHz]:[33 kHz]. The suspicion that this pair was a result of the measurement setup appears to be debunked, as the measurement setup is now divided out of all data. Ah well -- we have to throw it away because we can't compensated for it, and again, not compensating for this z:p pair only results in a systematic error of only 1.7e-4 % / 0.0385 deg at 100 Hz and 0.017% / 0.384 deg at 1 kHz.

(3) Also for State 2, I haven't yet settled on whether I'll be throwing away the nearly canceling z:p pair that are *not* the expected, 1st-order-only, [1.35 Hz]:[75 Hz] pair. I'll be writing a separate script that down-selects the zeros and poles to what either makes sense from a human perspective (we probably can ignore complex pair of poles whom are related only by a 0.006j imaginary part) and/or to what can actually be compensated for in the front end (i.e. the > 10 kHz z:p pair). The script will also convert these individual channel residuals in to overall systematic error impact on the DARM response function to show how good these fits really are at reducing the error to negligible.

All-in-all a good few days work.

Stay tuned for two more aLOGs documenting future work:
    (A) Fits to the AOSEM response (taking the ratio of State 1's response with a 40 Ohm load vs. with the full AOSEM load), and (hopefully) understanding of why we don't need to include that response in our model of the actuator
    (B) The Installation aLOG (the down-select of what z:p collections were actually installed, and plot showing the residual impact on the DARM systematic error budget)
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:40, Monday 14 February 2022 (61726)ISC, SUS
I've completed the fit of the ETMX AOSEM response, by taking the ratio of measurements of State 1 with a 40 Ohm load, and State 1 with the full long cable run + AOSEM. 

In addition to transfer function measurements, I also quickly measured the resistance of each AOSEM signal chain with a hand-held fluke DVM by disconnecting the DB15 breakout board from the "back" of the chassis (see, again, D1900027-v3_CoilDriverChassisSetup.pdf), and measured the resistance across the + and - legs of the coil pins (breakout-to-clip-doodle-to-short-BNC-to-fluke). I found that the resistance values for the 4 coils on ETMX were 24.05 +/- 0.05 Ohm. Quite a bit more than the "canonical" value of 19.7 Ohm we typically use!

%%%% Commentary %%%% 
(1) Though I didn't properly calibrate it in the plots, the DC gain of the transfer function is as expected -- the ratio of the ~40 Ohm dummy load (actually measured to be 39.0 +/- 0.5 Ohm) to the 24.05 AOSEM load, i.e. 24.05 / 39.0 = 0.61 [ (A/V) / (A/V) ]. Where the units, [ (A/V) / (A/V) ] = [ Ohm / Ohm ] = ["dimensionless"]. Of course, if they were the same resistance load, the magnitude would be unity.

(2) I've given a 4th order fit seed to IIRrational to start. It claims during the fitting that it reduces the order to 2nd, but when I give it a seed for 2nd order, the fitting algorithm barfs. Thus, where one might naively expect their to be only one zero at f_z = R_coil / (2*pi*L_coil), the collection of z:p's found in 2022-01-14_H1SUSETMX_PUMDriver_S1000343_FitResults.txt clearly and obviously indicates there's more going on. That being said, all fits have *nearly* canceling z:p pairs at ~125 Hz, and ~1800 Hz, which -- if one didn't care so much about precision of frequency response -- could drop and find only the zero at ~855 Hz, and then a super Nyquist pole at 17.1 kHz, that is poorly constrained by the data. So, it all makes sense, but I'll have to include the "extra" nearly cancel z:p's in order to achieve the 0.1% / 0.1 degree level compensation for which the calibration group is looking. 

(3) There is clear and obvious response from the AOSEM impedance that starts well below 1 kHz. This checks out: even if we been use R_coil = 19.7 [Ohm] and L = 3.2 [mH] as our model parameters for the AOSEM that we've been using since the down of time (i.e. these numbers are sourced from a 2012 LLO aLOG 3340), and treat it as a simple RL circuit, we would expect  a zero at f_z = R_coil / (2*pi*L_coil) = 1.196 kHz. However, we have always assumed that this response was too high frequency matter, and therefore have never compensated for it. In fact, before careful post-O3 analysis of UIM data (see G2000527 Part I), I never even considered independently measuring the OSEM response separately as I've done here. But, now we have, and we've even found that there's more inductance than expected, given that the fit reveals the zero is actually at f_z = ~855Hz rather than ~1.2 kHz. If we use the measured 24.05 Ohm resistance, this implies a coil inductance of L-coil = R_coil / (2*pi*f_z) = 4.47 [mH].

As such, moving forward, I'm 
    (a) Going to include an extra filter module in the compensation COILOUTF scheme (see current scheme represented in T1100507) to account for this response. Note: one *can* install this compensation, because one *can* have more poles and than zeros in a foton filter.
    (b) Because (regretfully) I didn't measure the full coil driver & AOSEM system response of any other State besides State 1, I'm going to use this *measurement* as representative of the AOSEM response to create all the coil driver & AOSEM system response measurements by assuming a linear system and taking the following to be accurate:
        coil driver & AOSEM system response = coil driver response (with 40 Ohm load) * AOSEM response (from the ratio of State 1 under the two different loads).

In an upcoming aLOG, I'll better demonstrate the levels of
    - individual coil transfer function systematic error,
    - overall pum stage PUM actuation transfer function systematic error, and 
    - entire DARM loop response function systematic error
that are incurred at various levels of compensation.

%%%% Data, Fitting, Results %%%
- The raw data for these transfer functions live in 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/SUSElectronics/ETMX/PUM/2022-01-14/
        2022-01-14_H1SUSETMX_PUMDriver_S1000343_AOSEM_CH?_??_State1_[mag,pha].TXT.

- I attach a single .pdf of the concatenated results for the 4 coils, 2022-01-14_H1SUSETMX_PUMDriver_S1000343_40OhmbyAOSEM_State1_FitResults.pdf, showing fits that have residuals (meas tf/ fit tf), below a few kHz, better than 0.1% / 0.1 deg. Sweet.

- The list of poles and zeros may be found as an addendum to fit results; the amended, addended, results re-attached here 2022-01-14_H1SUSETMX_PUMDriver_S1000343_FitResults.txt

Both of these results were produced by an updated version of 
    /ligo/gitcommon/suspensions/ligo/electronics/fits/
        fit_ETMX_PUM_driver_20220114.py

and the results have been committed to 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Results/SUSElectronics/ETMX/PUM/2022-01-14/

(the location referenced in the main aLOG above has a copy-and-paste error, referencing the ITMX data & results folders, sorry.)

Fits to AOSEM data to come, but it's less imperative that I get it immediately, and I want to share the modeling I've done of systematic error on ETMX first.
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 15:16, Tuesday 22 February 2022 (61828)ISC, SUS
I've completed the fit to the ETMY AOSEM response in the exact same manor as ETMX above.

Also similarly to ETMX, I've measured the resistance between legs of the AOSEM + cable system, and got 22.65 +/- 0.05 Ohm. Again, more than the canonical value, but interestingly different than ETMX!

All commentary from ETMX AOSEM frequency response applies to the ETMY data here, so I won't repeat it. 

Indeed, even further, I generalized the ETMX script from above, and made it such that it only depends on a few input parameters defining the IFO, OPTIC, measDate, and chassis Serial Number (essentially, just all the information needed to find the file path and file name), so, literally, everything about the process is the same even down to the fit order seed I gave IIRrational.

%%%% Data, Fitting, Results %%%
- The raw data for these transfer functions live in 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/SUSElectronics/ETMY/PUM/2022-01-17/
        2022-01-17_H1SUSETMY_PUMDriver_S1102652_AOSEM_CH?_??_State1_[mag,pha].TXT.

- I attach a single .pdf of the concatenated results for the 4 coils, 2022-01-17_H1SUSETMY_PUMDriver_S1102652_40OhmbyAOSEM_State1_FitResults.pdf, showing the fits that have residuals (meas tf / fit tf), below a few kHz, better than 0.1% / 0.1 deg. Sweet.

- The list of poles and zeros may be found as an addendum to fit results; the amended, addended, results re-attached here: 2022-01-17_H1SUSETMY_PUMDriver_S1102652_FitResults.txt.

Both of these results were produced by an updated version of 
    /ligo/gitcommon/suspensions/ligo/electronics/fits/fit_ETMY_PUM_driver_20220117.py

and the results have been committed to 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Results/SUSElectronics/ETMY/PUM/2022-01-17/

This will be incorporated into modeling of any contributions ETMY makes to the response function error (if ETMY PUM is ever used for DARM control).
Non-image files attached to this comment