Reports until 15:58, Wednesday 27 October 2021
H1 SUS (SQZ)
jeffrey.kissel@LIGO.ORG - posted 15:58, Wednesday 27 October 2021 (60422)
Flaw in OPOS OSEM2EUL / EUL2OSEM Matrices
J. Kissel, B. Lantz

Continuing our adventure with trying to understand the amount of cross-coupling we measure in the SUS OPO suspensions at both H1 and L1, (see beginnings of commentary in 60203), Brian and I continue to stare that the Vertical to Yaw and Yaw to Vertical cross-coupled transfer functions.

First, I'll catch you up to speed with the atteched the plots. 
    - The .pdf attached plot shows all of the transfer functions for one translational and one rotational DOF -- V to V, V to Y, Y to V, and Y to Y -- on one plot. Note: even though the label claims they're all in [rad/N.m], they're not. They're in the units you would expect for the given transfer function: V exc to V resp = [m/N], V exc to Y resp = [rad/N], Y exc to V resp = [m/N.m], and Y exc to Y resp [rad/N.m]. But importantly for the discussion below -- the supposition it's that it's all SI units and there's no funny business going on with "order-of-magnitude" unit conversion trickery, like [mm/N.m], or [urad / N].
    - To confirm that we have the legend assignment of which measurement is V to Y and which is Y to V, I attach the two image attachments (for H1SUSOPO and L1SUSOPO) which are screenshots of the raw DTT template, the raw data from which is used to create the matlab produced .pdf. There, in the template, the excitation channel is clearly and unambiguously different than the response channel in each Vertical drive or Yaw drive templates. With these, you can match the *shape* of the transfer function magnitude to the .pdf, and indeed confirm that the .pdf legend is correct.
    - The *image* attachments are *not* calibrated. These are in *uncalibrated* units of [um] or [urad] of calibrated LTV or RPY euler-basis response to euler-basis DAC counts (driven from the test bank). The .pdf attachment *is* calibrated into physical units (and each DOF to DOF in their respective SI units) with the factor of 0.090527, which comes from

    TF [(m or rad) / (N or N.m)]  = TF [(um or urad) / [DAC ct]] 
                                    * EUL2OSEM_digital
                                    *  (1 blah / 1e6 microblah ) 
                                    * (2^16 ct_DAC / 20 V_DAC) 
                                    * (1 V_DAC / 0.0096 A_CD) 
				    * (1 A_CD / 0.0309 N_OSEM) 
                                    * OSEM2EUL_real
                                  = TF [(um or urad) / [DAC ct]] * 11.0464
                        OR
                                  = TF [(um or urad) / [DAC ct]] / 0.090527

as it's shown represented in the legend. Note: the strikethrough of the OSEM2EUL_real "matrix" (i.e. the positions of the real OSEMs impart forces and torques based on their physical lever arms) indicates the cancelation of supposedly correct EUL2OSEM_digital matrix.
    - But, back to the .pdf attachment now -- here's where we lie stuck: The V to Y and Y to V transfer functions are wildly different at low frequencies. At low-frequencies, any suspension's transfer function asymptotes to a representation of that DOF's stiffness, or in the case of comparing two DOFs a 2 x 2 stiffness matrix. While a full transfer function matrix as a whole can have its off-diagonal elements be asymmetric for all sorts of "fun" real life reasons, the off-diagonal elements of a stiffness matrix are always, unequivocally symmetric. Why? Because the stiffness matrix is the double partial derivative of the potential energy matrix (see e.g. section 3 of T020205), the order of the derivates shouldn't matter.

So -- why are are these V to Y and Y to V transfer functions so different at low frequency?
Brian and I think it's because the OSEM2EUL and EUL2OSEM projection matrices for the OPOS have had a flaw in them since "Day 1." when they were installed prior to O3.

    Following my own breadcrumbs in the aLOGs (LHO:40801, LHO:40749, LHO:40427, TST:11396): The make_susopos_projections.m function was a copy of Alvaro's AOSEM_Basis_2.m just to name it like every other SUS's projection script. AOSEM_Basis_2.m has its DOFS re-ordered from his original version AOSEM_Basis.m because we craved matching the seismic team's channel ordering of H1 H2 H3, V1, V2, V3 rather than how the electronics are wired with [H1, V1, H2, V2, H3, V3]. All of these versions of the basis transformation script use the same excel spreadsheet of coordinates AOSEM_positions.xlsx, and those positions, locations, and orientations of sensors are recorded in [micrometers].

However, 
   (1) you'll see make_susopos_projections.m the excel data is parsed into variables [V1T, V2T, ..., H3T] and divided by a factor of x1000, which turns the OSEM positions from AOSEM_positions.xlsx into [millimeters]. BAD.
   (2) Then, a bit further down, when the height of the center of the Euler Basis coordinate system is adjusted by "CoM_H = 7.7 / 1000," we're confident that's an adjustment that's subtracted in [meters] (7 centimeters is too large, 7 meters is WAY too large, and correcting by 7 micrometers is just silly), and thus 0.007 [meters] are subtracted from the Z (third) coordinate of the [V1T, V2T, ..., H3T] vectors which are in [millimeters]. BAD.

As a result, when the sensor lever arms (which in the code are [millimeters]) are included in the transformation vectors in the rotational degrees of freedom (the last three columns of each row of the "Q matrices" in the code), and these Q matrices are propagated through to create the basis transform matrix, W -- which eventually become the OSEM2EUL and EUL2OSEM matrices -- the matrices no longer preserve units as desired. BAD. I.e. in every other suspension type, regardless of what the order of magnitude of the sensor signals entering the matrix -- the order of magnitude is preserved across the matrix. Said one more way: if all the 6 OSEMs are calibrated into [micrometers] of displacement in their OSEM basis, we want the EUL output of the matrix to be in [micrometers] or [microradians]. As created with this code, these matrices are not order-of-magnitude preserving. BAD.

If we fix these unit, order-of-magnitude, errors in the make_susopos_projections.m function the matrices become as follows:
    BEFORE FIX:
    OSEM2EUL_1000.M1
      H1 in         H2 in        H3 in       V1 in         V2 in        V3 in
     -0.79391      0.27259      0.23655    -0.024876     0.056163    -0.031287    L out
       0.1521     -0.55346       0.5755    -0.066825     0.010576     0.056249    T out
            0            0            0     -0.39181     -0.28169      -0.3265    V out
            0            0            0     -0.00277     0.000438     0.002332    R out
            0            0            0     0.001031    -0.002328     0.001297    P out
     0.001037     0.001074     0.001322            0            0            0    Y out

    EUL2OSEM_1000.M1
       L in          T in          V in       R in         P in         Y in
     -0.99692    -0.078459            0       1.8926      -24.048       212.53    H1 out
      0.29237      -0.9563            0       23.068       7.0527       363.97    H2 out
      0.54464      0.83867            0      -20.231       13.138       293.86    H3 out
            0            0           -1      -187.66        85.65            0    V1 out
            0            0           -1        28.59      -303.13            0    V2 out
            0            0           -1       200.53       158.75            0    V3 out
 
    AFTER FIX:
    OSEM2EUL_1e6.M1
      H1 in         H2 in        H3 in       V1 in         V2 in        V3 in
     -0.79391      0.27259      0.23655    -0.016944     0.038254     -0.02131    L out
       0.1521     -0.55346       0.5755    -0.045515     0.007204     0.038312    T out
            0            0            0     -0.39181     -0.28169      -0.3265    V out
            0            0            0      -2.7703      0.43844       2.3318    R out
            0            0            0       1.0313      -2.3283        1.297    P out
       1.0374       1.0743       1.3221            0            0            0    Y out

    EUL2OSEM_1e6.M1
       L in          T in          V in       R in         P in         Y in
     -0.99692    -0.078459            0     0.001893    -0.024048      0.21253    H1 out
      0.29237      -0.9563            0     0.023068     0.007053      0.36397    H2 out
      0.54464      0.83867            0    -0.020231     0.013138      0.29386    H3 out
            0            0           -1     -0.18766      0.08565            0    V1 out
            0            0           -1      0.02859     -0.30313            0    V2 out
            0            0           -1      0.20053      0.15875            0    V3 out

where on can see that 
   - the elements of the projection to the translation DOFs have not changed much at all. GOOD. (and where they have, it's because of the change in vertical coordinate of OSEM of 7.7 [mm] is more significant a change to the position of the OSEM, which had been falsely subtracted as 7.7 [micrometers] in the previous version of the code).
   - the elements of the projection to/from rotation DOFs have changed by 3 orders of magnitude, as expected from fixing the millimeters to meters bug. 

I intend to confirm all of this is legit with measurement by installing this corrected matrices in the OPOS and taking new transfer functions some convenient time, and seeing if this resolves the incredible discrepancy between the low frequency "stiffness representing" response of off diagonal elements of the transfer function matrix.
Hopefully, the proof will be in the pudding, and all of the low frequency parts of transfer functions between cross-coupled translation and rotation DOFs will be more symmetric, and we'll no longer be defying physics. 

Stay tuned!
Images attached to this report
Non-image files attached to this report