J. Kissel

I'm continuing the investigation as to why transfer functions between PCAL drive and H1:CAL-DELTAL_EXTERNAL_DQ response indicate that there's still systematic error (see DTT template reports of it in LHO:63506, and "supposedly correct" offline corrections to that template LHO:63520), and following the lead that the clock cycle delay used to approximate computer delays and the super-Nyquist, high-frequency corrections to A and C that the front end can't re-create H1:CAL-DELTAL_EXTERNAL_DQ is probably wrong.

Here, I re-break down the process for deriving that delay. Again, while the math is outlined in Eq. 40 of T1900169, my visual learning skills demand the diagram from LHO:22117, which shows that we mean when we say "the front-end can't approximate computer delays and the super-Nyquist, high-frequency corrections to A and C."
    - The calibrated data stream is ideally 
        \Delta L = (1/C) * darm_err + A * darm_ctrl
                 = \Delta L_res + \Delta L_ctrl
    - but we have to divide and A into the product of sub-Nyquist, causal stuff that the front end can do (below indicated with a prime, ' ), and the super-nyquist, acausal stuff (below indicated with a 'd') 
        C = dC * C' and A = dA * A'
    - which means that the front-end can only do the primed stuff, 
        \Delta L_res' = (1/C') * darm_err
        \Delta L_ctrl' = A' * darm_ctrl
    - That leaves the missing high frequency corrections to consider, dC and dA, which are both delays and super-Nyquist poles
        dA = dA_U + dA_P + dA_T
           = (OMC model to SUS model 16kHz delay) * (16k to 65k digital AI) * (DAC sample & hold delay) * (analog AI) * (1 + 1 + HF TST Driver poles)

        dC = (2L/c light travel time delay) * (simple Michelson approx correction advance) * (TIA HF poles) * (whitening HF poles) * (analog AA) * (65k 50 16k digital AA) 
    all of which are outlined graphically in the subway map, G1501518, if that helps. You'll notice that all of these components have unity gain out to quite high in frequency.
    - While dA and dC are the product of the above listed many delays and transfer functions, we can *approximate* the phase loss of these total transfer function as a delay, 
        dC ~ exp(-2*pi*f*\tau_C)
        dA ~ exp(-2*pi*f*\tau_A)
    - BUT -- to create \Delta L_res, we need 1/dC which would mean that delay, exp(-2*pi*f*\tau_C), would turn into an advance, exp(+2*pi*f*\tau_C), which is unphysical, or acausal. 
    - So, we accept a delay, exp(-2*pi*f*\tau_C), in CAL-DELTAL_EXTERNAL, and add it to \Delta L_ctrl' before summing together to form \Delta L, 
        \Delta L = (1/(dC * C')) * darm_err + dA * A' * darm_ctrl
        dC \Delta L = (1/C') * darm_err + dC * dA * A' * darm_ctrl
        \Delta L' ~ (1/C') * darm_err + exp(-2*pi*f*\tau_C) * exp(-2*pi*f*\tau_A) * A' * darm_ctrl
        \Delta L' ~ (1/C') * darm_err + exp(-2*pi*f*[\tau_C + \tau_A]) * A' * darm_ctrl

    - The final point to make, is that it's most important to get this approximation right at the DARM UGF, the frequency region where A and 1/C are contributing equally in magnitude, and thus getting the phase right is critical.

What has change over the years since O3 for dA and dC?
The only thing that should have changed are the new collection of high, super-Nyquist frequency poles for the OMC DCPD signal chain
Namely, there are five ~10 kHz poles in the chain, where there used to only be three poles at ~13, ~17 and ~18 kHz. So, there's much more phase *loss* because the poles are at lower frequency, and there are two more of them than before.
Thus, we expect dC to have *more* phase loss, and the approximate *delay* to be larger.

So ... let's make some plots. In doing so, I'm going to compare old pyDARM -- with the old OMC DCPD sensing chain -- to new pyDARM -- with the new OMC DCPD sensing chain. 

Attachment 1: shows the difference between dC (on the left) and dA (on the right). Don't ask questions about the 2022-05-27 dA magnitude -- I don't yet understand it, and need to work with Evan.

Attachment 2: Here, I compare the two different methods (top and bottom) of converting the phase of dA and dC into the total "relative" phase of 1/dC + dA. This is a technical plot that's really me figuring things out, and to aide my discussion with Evan. Don't read into it too much more that "the final answer" -- the combined phase loss that we'll convert to a delay is in the lower left.

Attachment 3: These are the same left plots in attachment 2, now on the right, and one the left the phase is converted to a frequency dependent delay.

In conclusion: where we needed 7.5 clock cycles before (which agrees with the needs in the past, see LHO:48620), we now only need 1.5 clock cycles of delay.

There're TONS of grains of salt to all of this, and I really need to talk to Evan Goetz to confirm all this, but I wanted to write down the status of the investigations -- and really, show the plots -- so that we could have a conversation over it.

Stay tuned for updates.

The script that made these plots lives in git.ligo.org/Calibration/ifo/scripts/compute_relativedelay_AvsC_20220527.py.