Reports until 13:21, Friday 18 October 2019
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 13:21, Friday 18 October 2019 - last comment - 10:45, Monday 11 October 2021(52567)
H1 SUS in HAM6 Freely Suspended at 2e-6 Torr
J. Kissel, R. Kumar

Rahul and I are performing the standard follow-up with the dynamical assessment of the suspensions now that HAM6 is sufficiently pumped down to count as "in vacuum" (the current pressure is 2e-6 Torr, standard "has been pumped down for months" level is ~2e-7 Torr). I've tested the H1SUSOMC (an OMCS) and H1SUSOPO (an OPOS), and can confirm that they remain free after pump down. Plots comparing the results against the previous time that they were at vacuum and a corresponding L1 suspension are attached!

As the actuation strength and the cross coupling of DOFs of the OPOS suspension continues to be problematic during characterization, I took some DOFs with the non-diagonal damping loops ON and some with them OFF. This is why you may see that some "major" resonances in some tranfer functions have different Qs that in previous measurements. 

Templates for each SUS live here:
/ligo/svncommon/SusSVN/sus/trunk/OMCS/H1/OMC/SAGM1/Data/
    2019-10-18_1839_H1SUSOMC_M1_WhiteNoise_*_0p02to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/OPOS/H1/OPO/SAGM1/Data/
    2019-10-18_1840_H1SUSOPO_M1_WhiteNoise_L_0p02to50Hz.xml

Rahul will attach OM3 and ZM1 data shortly. We still need to gather data for OM1 and OM2; they're currently in use.
Non-image files attached to this report
Comments related to this report
rahul.kumar@LIGO.ORG - 15:45, Friday 18 October 2019 (52571)

Attached below are the transfer function results  for the following four (in addition to what Jeff. Kissel posted in his alog) suspensions in HAM6,

OM1, OM2, OM3, ZM1

The results show that the suspensions are doing fine under vacuum and are consistent with previous measurements.

The files (four in total) with names (2019.-10-18...) gives a comparison between the current measurement and sus model. The other four files (OM1, OM2...) gives a comparison between sus model and measurement data taken at different times (example in vacuum/air etc).

The transfer function templates (.xml file for running the diaggui and .txt file for matlab plotting), matlab tools and the result files are stored at the following locations,

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Data/

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Results/

 

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM1/SAGM1/Data/

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM1/SAGM1/Results/

 

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM2/SAGM1/Data/

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM2/SAGM1/Results/

 

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM3/SAGM1/Data/

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM3/SAGM1/Results/

 

/ligo/svncommon/SusSVN/sus/trunk/HTTS/Common/MatlabTools/           (plotHTTS_dtttfs_M1.m and plotallhtts_tfs_M1.m)

Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 10:45, Monday 11 October 2021 (60203)SEI, SUS
I attach a few more plots from this data set (the last data set the H1 SUS OPO has had without faults in the measurement): 
There has been interest / curiosity in the V to L, and T, as well as V to Y coupling, given the OPOS's blades are flat when unloaded and curved when loaded (rather than the typical design of flat when loaded). The only other "suspension" for which this blade design is true, in LIGO, are the BSC-ISIs, where there is non-negligible V to RZ (Yaw) cross-coupling.

I've also updated the
    /ligo/svncommon/SusSVN/sus/trunk/OPOS/Common/MatlabTools/
        plotOPOS_dtttfs_M1.m

for several reasons:
    - The legend in the cross-coupled euler basis degrees of freedom have been incorrectly legended for *years*. The *plot* was showing, for example, the V to R transfer function but it was labeled as the R to V transfer function and vice versa. Whoops and Yikes! This is *definitely* my fault. 
    - to show these new vertical to all Euler basis DOF plots every time an individual measurement is processed.
    - Fixed the call to pdfmerge so that it references the copy of the merging function in the SusSVN rather than relying on it being in the operating system path.
Non-image files attached to this comment