Displaying report 1-1 of 1.
Reports until 11:04, Thursday 10 March 2022
H1 SUS (ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 11:04, Thursday 10 March 2022 (62152)
Nothing New Under the Sun: 'New,' supposedly 'Needed' SUS QUAD PUM Stage AOSEM Compensation turned OFF
J. Kissel (R. Abbott, J. Betzwieser, E. Goetz, B. Ratto)

Over the past few days, following Brad and my recent work in updating the QUAD's PUM (aka L2) stage coil driver response (see installation LHO aLOGs 61927, 61970, 62050, and modeling LHO aLOGs 61729, 61985), we've reviewed the work with an external audience (see G2200310), which identified some fundamental confusion and apparently contradictory results.

After mathing it out (see long version details below) -- we now understand "our" (my) fundamental confusion, and I've reverted my mistake: 
I've turned OFF and removed any an all evidence of the "antiAOSEM" filter that was in FM9 of the COILOUTF banks, and accepted FM9 being OFF in each SUS's SDF systems.

A note of comfort before you read about me eating crow: all of that the *other* compensation of the new and old driver response is still valid and still better than before this whole exercise.

------------------------
LONG VERSION DETAILS
------------------------
After the review, in conversation with Rich and following a Brad/Joe/Evan/Jeff trip to the whiteboard (see attached and G2200332), we've identified that we should NOT be "newly" compensating for the AOSEM response. 

In my original modeling aLOG for the systematic error in compensating the ETMX PUM driver, LHO:61729, one of the main conclusions is "we must compensate for the AOSEM response [...] I don't know how we've gotten away with *not* compensating it before." 

Alas, my basic electronics failed me:
    - The raw measurement that we take is measuring the differential voltage across either a dummy OSEM 40 Ohm resistor or across the full AOSEM chain, a.k.a. across the "load" of the the driver, "V_load," under the face of a differential drive in, V_in:
        V_load / V_in (w/ load of Z_40Ohm or Z_AOSEM)                                                               (1) 
    - To derive the current across either the 40 Ohm OSEM, or the AOSEM coil -- which fundamentally *must* be the same -- we divide either measurement by the *correct* load,
        I_AOSEM = I_40Ohm = (V_load / V_in)_40Ohm *  ( 1 / Z_40Ohm ) = (V_load / V_in)_AOSEM * ( 1 / Z_AOSEM )      (2) 
    - While the Z_40Ohm is a flat resistance, the Z_AOSEM as we know, has both a DC resistance, R_AOSEM, and an inductance, L_AOSEM, which results in a 1/(2*pi*L_AOSEM/R_AOSEM) ~850 Hz zero.
    - The mistake I made -- I only divided out resistance of the coil, R_AOSEM, from (V_load / V_in)_AOSEM, rather than the full, Z_AOSEM, thinking that any and all frequency-dependence -- including the ~850 Hz zero -- is seen in the current the coil. IT DOES NOT: this is an artifact of the measurement, and it gets divided out as in eq. (2).
    - Further, while the current *does* go through the coil, the analytic expression for the current across any coil driven by any LIGO coil driver, I_coil, is
        I_coil / V_in = G_driver / (2*Z_out + Z_coil)                                                               (3)
      where G_driver is whatever *voltage* transfer function from V_in to just before the impedance loop (2*Zout + Z_coil), i.e. the differential output voltage, V_out, and Z_out is the impedance of one leg of whatever differential (and maybe switchable) R, C, or L network is between V_out and the coil.
    - In the case of this PUM driver (see schematic in D070483), Z_out is a complex network of Rs and Cs, but most of the current is going to flow through the -- only real, but -- large impedance of R22 = R27 = 2.2 kOhms, which is (yes, smaller than the R31 + R33 = 370 [kOhm], but) much larger than any part of the Z_coil which has 22 Ohm + i* 2*pi*f[Hz] * 4.3e-3 [Ohm.s]. Said mathematically, we can plug in values for equation (3) and convert to zero:pole notation, 
        (I_coil / V_in)_PUM+AOSEM = G_driver / ( Re(2*Z_out + Z_coil) + Im(2*Zout+Z_coil) )                         (4)
                                  = G_driver / ( [2*2.2e3+22] + i * w * [4.3e-3]) 
                                  = G_driver / ( [2*2.2e3+22] ) * [ 1 / (1 + i * w * 4.3e-3 / 4.422e3) ]
        (I_coil / V_in)_PUM+AOSEM = (G_driver/4.422e3) * (1 / (1 + i * w * 4.3e-3/4.422e3)                          (5) 
    which means there's a pole at
        f_pole = 1 / (2*pi* 4.3e-3 / 4.422e3) = 1.636e5 = 164 kHz                                                   (6) 
So, yes, there is a response impact of the AOSEM, but it's at 164 kHz, not at ~850 Hz. 

So what do we do about a 164 kHz pole?
    (a) The front-end, running at 16 kHz, can't install any compensation above ~5 kHz, let along 164 kHz, and even worse,
    (b) the (V_coil / V_in) measurement is taken with an SR785, whose upper frequency limit is 102.4 kHz, so even if we *wanted* to compensate for the exact measured "164 kHz" frequency, we'd be asking out fitting algorithm to extract a 164 kHz pole from data that only goes up to 102.4 kHz, which is unreasonable.

Why did the modeling aLOGs LHO:61729 and LHO:61985) show so much systematic error "if we don't compensate for the AOSEM" you ask?
Because I made another fundamental mistake in the modeling scripts (again based on the assumption that "any and all frequency-dependence -- including the ~850 Hz zero -- is seen in the current the coil."): the *measurement* that I multiplied all of the various compensation schemes was a falsely constructed measurement.
    - I first created a normalized version of the AOSEM's 850 Hz zero, 
         " [[ (V_load / V_in)_AOSEM / (V_load / V_in)_40Ohm ]] * (R_40Ohm/R_AOSEM) = Z_AOSEM(f)_normalized << the ~850 Hz zero "
    - Then I in correctly multiplied that measured 850 Hz into the 40 Ohm load data (pre-divided by 40 Ohms to be I_coil / V_in),
         "I_coil / V_in = (V_load / V_in)_40Ohm * (1/R_40Ohm) * Z_AOSEM(f)_normalized << totally wrong"
         "I_coil / V_in = G_driver/(2*Z_out+Z_load) * Z_AOSEM(f)_normalized << totally, (now) obviously wrong" 
where everything is in quotes, and the equations aren't numbered because that was WRONG WRONG WRONG BAD BAD BAD.

Brad's going to work through correcting my mistake in the modeling scripts and redo the conclusions from LHO aLOGs 61729 and 61985. Stay tuned for an update on that.

I'll also turn this aLOG into a "how to measure a coil driver" DCC document, i.e. flesh out G2200332 in the fullness of time.

HOWEVER: Because we fit / extracted / used the zeros and poles of G_driver and 1 / (2*Zout + Z_load) in various states from the 
    I_coil / V_in = (V_coil / V_in)_40Ohm * (1/R_40Ohm)                                     Eqs. (2) and (3) repeated
                  = G_driver / (2*Z_out+Z_load) , 
data all of that the *other* compensation of the response of G_driver and Z_out is still valid and still better than before this whole exercise, so all of the *rest* of the work we've done is still valid and good.

Non-image files attached to this report
Displaying report 1-1 of 1.