Following the restart of any vacuum Beckhoff controller it is necessary to burt-restore the settings back to what they were prior to the restart (e.g. CP PID settings). We are using the slow controls Vacuum SDF to display which settings need to be restored, but the SDF cannot do the revert itself since it runs on a non-authorized server (h1ecatmon0) which does not have write access to the vacuum system.

Previously I had written a script in user vacuum's home directory on zotvac0 to do this restore for h0vaclx, today I made the script generic, taking the system to be restored as an argument.

The restoration process following a restart of a vacuum system is now:

On any CDS workstation open the vacuum SDF window showing the differences list, we will use this to verifty the restore worked correctly

As user vacuum on zotvac0 (restricted access to vacuum team, CDS and OPS) run the ./burt_restore_vac.bsh script with no arguments to get the usage:

vacuum@zotvac0:~$ ./burt_restore_vac.bsh 
Incorrect arguments given
 
Usage:
    burt_restore_vac.bsh SYS
    where SYS is one of:
    lx ly ex ey mx my mr
 
This morning I ran the script with argument = ly which correctly restored the h0vacly settings to those in h1vacuumsdf's safe.snap file***

Sheila, Camilla, WP#12632.

Moved OPO Crystal Spot using instructions in 80451, last done in January 2025 82134.

• Starting Position: forth spot from the left. 0.830V is the height of green 00 mode. 41% of green power in 01 mode
  • Alignment looked very bad, photos attached. 
• Ending Position: second spot from the left. 2.23V is the height of green 00 mode. 36% of green power in 01 mode
  • Note that we have used this spot before but LLO found that it was okay to go back to old spots and this spot looked better than the edge spot

For all of the used spots we moved through, to the left of the co-resonance, the loss suddenly increased as in the spot to the side of the current co-resonance was in the past used. This made us think that we are set to a different temperature to other times we have moved the spot. 

Measured NLG to be 10 with the OPO TRANS setpoint set to 95uW, the NLG was very low 7 with 80uW, hence staying at 95uW, the NLG's seemed to have dropped this week 85252, we don't know why. 

Tagging OpsInfo: This change will mean that for the next week or so we'll need to more regularly adjust the OPO TEC temperature, instructions are in 80461. Should be done pro-actively when relocking and if range is low in observing. Pop out of observing to adjust while in Observing. 

Today's h1asc model change was a good opportunity to consolidate the new model build procedure now that H1 models are rev-locked (source code locked to specific subversion revision numbers).

1) build the model as normal to verify that it builds (user controls on h1build)

> rtcds build h1asc

2) run model through check_model_changes to check if DAQ changes are pending (user myself on opslogin0)

> check_model_changes h1asc

In this case 4 fast channels are to be added to the DAQ

3) run rev-update on model to check subversion status (user controls on h1build)

> rtcds rev-update h1asc

This showed that the h1asc.mdl model has local mods pending commit.

4) commit local mods to subversion (user myself on opslogin0)

Using the DAQ change information from 2) I committed h1asc.mdl to subversion

> svn ci -m "Elenna 23jun2025 add 4 DQ chans DC6_[P,Y]_[IN1,OUT]" h1asc.mdl

5) run rev-update again (user controls on h1build)

> rtcds rev-update h1asc

At this point I was able to accept svn HEAD as the rev-lock versions for h1asc's source files

6) do a rev-locked build of h1asc (user controls on h1build)

> rtcds build --rev-locked h1asc

7) install the model (user controls on h1build)

> rtcds install h1asc

J. Kissel

In order to prepare for implementing ECR ECR E2400330 which improves the whitening within the UK sat amps to improve the OSEM signal chain's total sensor noise between 0.05 and 10 Hz (see CSWG:11249 for a model of the noise improvement), I want to be sure we have a up-to-date measurement of the damping loop's suppression. This is so it can be divided out from the estimate of sensor noise before vs. after the change. Also, in general, it's good it we have pre-tuned templates for open loop gain transfer functions, as they use a markedly different excitation than "standard" "health check" transfer functions because the excitation must go through the damping loop controller filter.

Note: if we compensate for the change in satamp frequency response well (with the anti-whitening filters in the OSEMINF banks), then the open loop gain / loop suppression / close loop gain should remain unchanged across the whitening filter change, so one we have these we shouldn't need to take them again (unless commissioning demands more changes to the filters). 

Since this kind of inventory is best done digitally for other folks reference and in case I have to delegate, I share it here. 
The following is a table of available and believed "should be the same as now" open loop gain TF templates and aLOGs for all suspensions with UK satellite amplifiers (and the Filter Cavity HSTSs FC1 and FC2 for good measure).
Where there isn't templates that are "still valid," I give a brief note as to why. 

Optic    aLOG             Templates                                                                                         Still Valid?        If not, why not?
ETMX M0  (n/a)            none                                                                                              NO                  *Never measured
ETMX R0  (n/a)            none                                                                                              NO                  *Never measured

ETMY M0  LHO:6933         2013-07-??_????_H1SUSETMY_M0_*_WhiteNoise_OLGTF.xml                                               NO                  *Way old, not enough DOFs
ETMY R0  LHO:68405        2023-04-04_1731_H1SUSETMY_R0_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml                           Yes                 *But would be good to remeasure w/ and w/o R0 tracking

ITMX M0  LHO:7720         2013-09-10_2306_H1SUSITMY_M0_[R,V]_WhiteNoise_OLGTF.xml                                           NO                  *Way old, not enough DOFs
ITMX R0  (n/a)            none                                                                                              NO                  *Never measured

ITMY M0  (n/a)            none                                                                                              NO                  *Never measured
ITMY R0  (n/a)            none                                                                                              NO                  *Never measured

TMSX     (n/a)            none                                                                                              NO                  *Never measured

TMSY     LHO:6654         2013-06-06_1511_H1SUSTMSY_M1_[L,P]_WhiteNoise_OLGTF.xml                                           NO                  *Only L and P measured
 
BS       LHO:71269        2023-07-12_2000_H1SUSBS_M1_CDBIOState_1_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml                Yes                 *Oplev Damping OFF
         LHO:71465        2023-07-18_1740_H1SUSBS_M1_CDBIOState_1_OLDampingON_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml    Yes                 *Oplev Damping ON

MC1      LHO:85291        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

MC2      LHO:85291        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

MC3      (n/a)            none                                                                                              NO

PRM      LHO:85292        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

PR2      LHO:85292        2022-10-12_2020_H1SUSPR2_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

PR3      LHO:64152        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGainTF.xml                            Yes

SRM      LHO:85285        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF.xml                           NO                  *EPICs gains changed since

SR2      LHO:65314        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

SR3      LHO:85255        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGainTF.xml                            Yes

FC1      LHO:85290        2022-10-14_2330_H1SUSFC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

FC2      (n/a)             none                                                                                             NO

OMC      LHO:60054        2021-09-28_1640_H1SUSOMC_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGain_2014vs2021Designs.xml            Yes

IM1      LHO:64039        2022-07-19_H1SUSIM1_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM2      LHO:64039        2022-07-19_H1SUSIM2_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM3      LHO:64039        2022-07-19_H1SUSIM3_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM4      LHO:64039        2022-07-19_H1SUSIM4_M1_WhiteNoise_*_OLG.xml                                                       Yes 

So -- to we really need to focus our measurement energy on the QUADs which have really never been characterized and the recycling cavity HSTS which have their EPICs gains changed in 2023.
The good news is that 2023 me tuned a full set of QUAD R0 open loop gain TF templates using ETMY, so these templates should be viable for both the rest of the R0 chains as well as the main chain with little-to-no tuning (assuming alignment biases are not eating up a different amount of DAC range).
That leaves on the TMTS not having tuned templates, so that's where we'll have to spend our tuning time.
We obviously have templates that will work for the missing / out-of-date HSTSs.

I'll begin the campaign during upcoming Tuesdays, in advance of making the ECR E2400330 change.

WP12623 h1asc add fast channels to DAQ

Elenna, Dave:

A new h1asc model was rev-locked and installed. Four new fast DQ channels were added to the DAQ (channel, rate):

> H1:ASC-DC6_P_IN1_DQ, 256
> H1:ASC-DC6_P_OUT_DQ, 512
> H1:ASC-DC6_Y_IN1_DQ, 256
> H1:ASC-DC6_Y_OUT_DQ, 512

DAQ restart needed.

WP12570 Restart Digivideo Cameras with latest pylon

Patrick, Jonathan, Dave:

Jonathan updated pylon on h1digivideo[4,5,6] and restarted all the camera servers on these machines. This should fix the bug of stuck open files accumulating when the camera connection is interrupted.

No DAQ restart needed.

Add PID SMOO channels to vacuum SDF

Dave:

Prior to today's h0vacly restart I added the missing CP PID-control SMOO channels to the vacuum SDF monitor.req and safe.snap files. SDF was restarted 08:29. No DAQ restart needed.

WP12577, 12608, 12615 Upgrade LY Vacuum Controls

Janos, Gerardo, Patrick, Jonathan, Erik, Dave:

Patrick installed a new h0vacly system this morning. Main items are:

• Renaming of FCES Ion pump channels
• Removal of old PT100 channels

Pleae see Patrick's alog for details.

A extended DAQ restart was required, renaming Ion Pump raw minute trend files for uninterrupted lookback and construcing new PT100 (HAM1) raw minute trends following the upgrade of h0vaclx last Tuesday (17th June 2025).

DAQ Restart

Jonathan, Erik, Patrick, Dave:

Immediately following the restart of h1asc at 11:52, the DAQ was restarted using the following procedure:

1. both trend writers were turned off, allowing raw minute trend file changes on a static system
2. ip_copy_scripts.bsh was ran on both TWs, for each Ion Pump channel which is being renamed, this copied the old file into the correct directory for the new file, preserving recent lookbacks.
3. Erik ran his script to merge the previous HAM1 PT100 data sets into the new channel name.
4. A new H0EPICS_VACLY.ini was generated
5. 0-leg was restarted, followed by a EDC restart on h1susauxb123
6. 1-leg was restarted, requiring a second restart of GDS1.

It was at this late point that I remembered that the temporary H1 version of PT100B is no longer needed, and indeed this channel has no data following the removal of the PT100B Volts channel from h0vacly. However since it is still in the EDC, we need to continue running the temporary IOC until the next DAQ restart. I've removed it from edcumaster.txt as a reminder.

GPS Leap Seconds Updates

Jonathan, Erik, Dave:

Erik's FAMIS task reminded us that the leapseonds files expiration date of 30 June 2025 is rapidly approaching. Although no leap seconds are to be applied, the files need to be updated to reset their expiration dates. Please see Erik and Jonathan's alog for more details.

DNS testing 

Erik:

ns1 (backup DNS server) was used by Erik to see if we can reproduce the error whereby loss of connection to GC caused internal CDS name resolution issues. It did not.

Kiet, Evan, Anamaria 

We noticed that since August 24th, 2024—following the detector maintenance break in O4b—NonSENS has been consistently injecting noise into the 58–60 Hz band.

The ratio of strain after/before cleaning has been tracked via the DetChar summary pages. Attached to this alog are three examples, taken on August 24th, 2024; December 23rd, 2024; and March 31st, 2025. The peak around 58–60 Hz appears to grow over this period, and and remains present after the O4c commissioning break. 

We’ve also attached the NonSENS noise budget for March 31st, 2025. It shows a peak in the jitter noise at 58–60 Hz, which aligns with the band NonSENS has been injecting noise into, so perhaps it is not subtracting jitter correctly? 
 

Closes WP 12577.

The running code is now at commit 0faf5c4aeb5c61116a5abf0573cb3d09ffdc9e7c in https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum.

This completes the remaining part of the work permit:
"Update the PLC code on h0vacly to pull and use the following changes from git: "Changed the names of the IP23, IP24, and IP25 filter cavity ion pump controllers. Added IPFCC6 and IPFCC8 filter cavity ion pump controllers. Commented out IPFCC6 and IPFCC8. Commented out PT100 as a Pirani and Cold Cathode gauge pair."

After regenerating the TwinCAT 3 solution and running a scan for devices it showed that Box 1, Box 4, PT154 and PT157 had different hardware revisions than they were configured for in the solution. I changed the PowerShell script to make them match, but when I ran it I found that the device driver installed for these gauges did not match the new revision number. I looked on the MKS website for updated drivers, but could not find any drivers at all. I looked back through my emails and found that Chandra had given me the one I currently have, and remembered that she had probably gotten it from the manufacturer directly. The most feasible solution I could think of to do in the time remaining was to revert the revision numbers in the software and run with the mismatch. I don't see any issues at present, and apparently PT154 has been running with the mismatch since it was replaced a while back.

Leo Schrader, Camilla Compton, Sheila Dwyer, Jennie Wright

I am trying to build up a mode-matching model for the SQZ to OMC path. Measured the height of periscope closest to -X Side in SQZT7.
Height of periscope base plate measured 5/8 in. D1201011 front plate reported 25 in tall in design documentation.
Top of D1201011 to center of upper periscope mirror measured approx. 63/64 in.

Vertical beam travel in periscope thus computed as 22.61 in (574.3 mm).

Images of ruler measurements are attached.

There were some cleanroom curtains on HEPI HAM1 that I moved, and there were several ladders that I put away all around, HAM1, 5, 7 and the biergarten.

J. Kissel

I'm reviewing the state of suspensions' collection of damping loop open loop gain / loop suppression / closed loop gain TF measurements, because we'd like to use the loop suppression to accurately estimate the OSEM sensor noise left over after regressing out the ISI input displacement (much like Valera has done for PR3 in LHO:84277, but he didn't invert the loop suppression). We're doing this so we have "the best we can" metric for when we start to implement ECR E2400330 and improve the whitening within the sat amps to improve the sensor noise between 0.05 and 10 Hz (see CSWG:11249 for a model of the noise improvement). 

I've found that SRM's collection (taken back in 2022 during the upgrade to Level 2.0 filters; LHO:65310 ) had not been updated after the Aug 2023 commissioning efforts that reduced the gain in all DOFs by half, from -1.0 to -0.5 (LHO:72106).

So, I've gathered a new set of open loop gain TFs this morning (from which the loop suppression and closed loop gain TFs come "for free" if you gather the right channels).

The data set has been committed to 
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_L_0p01to100Hz_OpenLoopGainTF.xml
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_P_0p01to100Hz_OpenLoopGainTF.xml
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_R_0p01to100Hz_OpenLoopGainTF.xml
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_T_0p01to100Hz_OpenLoopGainTF.xml
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_V_0p01to100Hz_OpenLoopGainTF.xml
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_Y_0p01to100Hz_OpenLoopGainTF.xml

The references in these templates were updated before each new measurement was taken, so it's a direct comparison between "before" vs. "after" gain reduction on the level 2.0 filters.
It's not terribly surprising that the magnitude of the the open loop gain dropped, but due to the complexity of the unity gain crossings, phase evolution beneath it and the confirmed MIMO nature of the loops, it's never obvious what effect this has on the loop suppression or closed loop gain in the 0.1 to 10 Hz region, thus the remeasure.
For comparison of the loop suppressed plant, P / (1 + G), before vs. after the gain reduction -- see LHO:85277 (note: technically that data also has a switch of basis for transverse, but the consequence on the loop is nil; per that aLOG). 

And for the ease of use, I've exported the loop suppression (A: EXC, B: IN2, to show IN2/EXC = 1 / (1 + G) ), and committed to 
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_L_0p01to100Hz_OLGTF_LoopSuppression_tf.txt
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_P_0p01to100Hz_OLGTF_LoopSuppression_tf.txt
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_R_0p01to100Hz_OLGTF_LoopSuppression_tf.txt
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_T_0p01to100Hz_OLGTF_LoopSuppression_tf.txt
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_V_0p01to100Hz_OLGTF_LoopSuppression_tf.txt
        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_Y_0p01to100Hz_OLGTF_LoopSuppression_tf.txt

J. Kissel

Following LHO:85273, I realize I've lost track of which 6-OSEM top-mass suspensions have had their damping loop gains augmented through commissioning efforts. All of the below suspensions have had their loop control filters updated with a "Level 2.0" design which, during the upgrade from Level 1.0 to Level 2.0, have their EPICs gains reset to -1.0 (and any tuning of gains is built into filter banks). However, because it's far easier to check, revert, and set without knowing details of the frequency dependence of the loop shaping, it is typical to adjust the overall loop gain by increasing or decreasing the EPICs gain in the [M0/R0/M1]_DAMP_[DOF] banks, and then check the impact on ISC loops, including the DARM noise performance and ASC or ISC loop stability. 

Here's a list of the current status of all top mass DAMP gains for QUADs, Triples, and Doubles that have a 6-OSEM sensor/actuator array:
    {'ETMX M0': [-1.0, -1.0, -1.0, -1.0, -1.0, -0.5],      # Aug 2023 commissioning LHO:71927
     'ETMX R0': [1.0, 1.0, 1.0, 1.0, 1.0, 1.0],            # "Gain" filters have the feedback sign in it, rather than the EPICs gain
     'ETMY M0': [-1.0, -1.0, -1.0, -1.0, -1.0, -0.5],
     'ETMY R0': [1.0, 1.0, 1.0, 1.0, 1.0, 1.0],            # "Gain" filters have the feedback sign in it, rather than the EPICs gain
     'ITMX M0': [-1.0, -1.0, -1.0, -1.0, -1.0, -0.5],
     'ITMX R0': [1.0, 1.0, 1.0, 1.0, 1.0, 1.0],            # "Gain" filters have the feedback sign in it, rather than the EPICs gain
     'ITMY M0': [-1.0, -1.0, -1.0, -1.0, -1.0, -0.5],
     'ITMY R0': [-10.0, -10.0, -2.0, -0.3, -0.1, -0.1]}    # "Gain" filters are OFF, these are taking the place of those filters

    {'BS': [-1.0, -1.0, -1.0, -1.0, -3.0, -3.0],           # P and Y gains have been this way since 2015 at least
     'MC1': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'MC2': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'MC3': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'PRM': [-0.5, -0.5, -0.5, -0.5, -0.5, -0.5],          # Aug 2023 commissioning, LHO:72130, LHO:72106
     'PR2': [-0.5, -0.5, -0.5, -0.5, -0.5, -0.5],          #   | 
     'SR2': [-0.2, -0.2, -0.2, -0.2, -0.2, -0.2],          #   |
     'SRM': [-0.5, -0.5, -0.5, -0.5, -0.5, -0.5],          #   V
     'FC1': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'FC2': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'PR3': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'SR3': [-0.5, -0.5, -0.5, -0.5, -0.5, -0.5],          # Aug 2023 commissioning
     'TMSX': [-3.0, -1.0, -1.0, -1.0, -3.0, -1.0],         # L and P gains have been this way since 2015 at least
     'TMSY': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
     'OMC': [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0]}

Even though the gains seem to be quite scattered and inconsistent at first, most have either been that way through all observing runs to date or were adjusted during a concerted Aug 2023 commissioning effort by Gabriele and Elenna.

There were some light end station VAC pump checks/disassemblies but they didn't seem to affect the measurements, the error bars are much better/smaller than the last time when it was windy out.

ETMY's charge is high (>50V) on half of the quadrants, it appears stable if we discount the previous bad measurement.

ETMX's charge is hovering within +/-10V of 50V except for LR_P, it also appears stable ignoring the previous measurement.

J. Kissel

Following LHO:85198, I've changed the sign the OSEM2EUL and EUL2OSEM matrix elements that transform from "SD" to "T" and vice versa, as SRM is one of the few HSTSs that have their "SD" OSEM mounted on the "Opposite Side," (again see G2402388 and E1100109).
    Matrix Element                  Was     In now
    H1:SUS-SRM_M1_OSEM2EUL_2_6      -1.0    +1.0
    H1:SUS-SRM_M1_EUL2OSEM_6_2      -1.0    +1.0

I attach a comparison two sets of new health check TFs, one UNDAMPED and the other DAMPED against a previous 2024 measurement. This metric (and any other metric we have) shows no change, as expected (see "Shouldn't we have discovered this with the 'health check TFs?'" section of LHO:85198).

The SUS was in the new "HEALTH CHECK" guardian state, but with the alignment offsets ON*** and all DOF's worth of damping loop gains set to -0.5 per nonimal since 2023 (see LHO:85273). 
The ISI/HEPI system was isolated, but with sensor correction OFF because it's maintenance day.
*** "It is known" that in the current mechanical alignment vs. OSEM position, that with the alignment offsets OFF, the LF and RT OSEMs aren't far above ADC 0 counts, and thus the magnitude of the TFs drops by almost a factor of two, and coherence gets worse even with twice the excitation amplitude.

I also attach SDF screenshots of me accepting these new values in the safe and OBSERVE .snap files.

The data sets are committed to
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_L_0p02to50Hz.xml
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_P_0p02to50Hz.xml
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_R_0p02to50Hz.xml
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_T_0p02to50Hz.xml
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_V_0p02to50Hz.xml
        2025-06-24_1558_H1SUSSRM_M1_WhiteNoise_Y_0p02to50Hz.xml

        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_L_0p02to50Hz.xml
        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_P_0p02to50Hz.xml
        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_R_0p02to50Hz.xml
        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_T_0p02to50Hz.xml
        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_V_0p02to50Hz.xml
        2025-06-24_1629_H1SUSSRM_M1_WhiteNoise_Y_0p02to50Hz.xml

J. Kissel

I'm building up some controls design documentation for the derivations of the OSEM2EUL / EUL2OSEM matrices for existing suspension types (see G2402388), in prep for deriving new ones for e.g. the HRTS and if we upgrade any SUS to use the 2-DOF AuSEMs.

In doing so, I re-remembered that the HLTS, HSTS, OMC controls arrangement poster (E1100109), defining the now-called "6HT" OSEM arrangement in T2400265 calls out two possible positions for the transverse sensor, the "side" and "opposite side," which I'll abbreviate as SD and OS, respectively from here on.

If the transverse sensor is mounted in the SD position, then as the suspension moves in +T, the OSEM further occults the LED beam, creating a more negative ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be -1.0.
If the transverse sensor is mounted in the OS position, then as the suspension moves in +T, the OSEM opens up revealing more LED beam, creating a more positive ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be +1.0.

Not *actually* remembering that the HLTSs PR3, SR3, and two of the 9 HSTSs, SR2 and SRM use OS as their transverse sensor yesterday, and missing the note from Betsy in the abstract of E1100109 to look at the each SUS' Systems Level SolidWorks assembly for transverse sensor location assignment (prior to this morning it was not in red, nor did it call which suspension explicitly have their transverse sensor mounted in the OS position), I was worried that we'd missed this when defining the sign of *all* HLTS / HSTS / OMCS OSEM2EUL / EUL2OSEM matrices, and assumed they were all installed as SD OSEMs with -1.0 OSEM2EUL and EUL2OSEM matrix elements.

Below, I inventory the status with 
    - suspension name, 
    - a reference to picture of the transverse OSEM (or the corresponding flag w/o the OSEM), 
    - confirming SW drawing does match the picture, 
    - the current value / sign of the OSEM2EUL / EUL2OSEM matrix element (H1:SUS-${OPTIC}_M1_OSEM2EUL_2_6 or H1:SUS-${OPTIC}_M1_EUL2OSEM_6_2)
    - a conclusion of "all good" or what's wrong.


Optic	T Sensor	aLOG pic	SW check	OSEM2EUL	Conclusion
	Mount				value		/EUL2OSEM
MC1     SD              LHO:6014        D0901088 g      -1.0            all good
MC3     SD              LHO:39098       D0901089 g      -1.0            all good
PRM     SD              LHO:39682       D0901090 g      -1.0            all good
PR3     OS              LHO:39682       D0901086 g      +1.0            all good

MC2     SD              LHO:85195       D0901099 g      -1.0            all good
PR2     SD              LHO:85195       D0901098 g      -1.0            all good

SR2     OS              LHO:41768       D0901128 g      +1.0            all good

SRM     OS              LHO:60515       D0901133 g      -1.0		OSEM2EUL/EUL2OSEM wrong!
SR3     OS              LHO:60515       D0901132 g      +1.0            all good

FC1     SD              LHO:61710       D1900364 g      -1.0            all good
FC2     SD              LHO:65530       D1900368 g      -1.0            all good

OMC     SD              LHO:75529       D1300240 g      -1.0            all good (see also G1300086)


So, as the title of this aLOG states, we've got the sign wrong on SRM.

Shouldn't we have discovered this with the "health check TFs?"
Why doesn't this show as a difference in the "plant" ("health check") transfer functions when comparing against other SUS that have the sign right?
Why *don't* we need a different sign on SRM's transverse damping loop? 

Because the sign in the EUL2OSEM drive and OSEM2EUL sensed motion is self consistent:

When SRM EUL2OSEM matrix requests to drive in +T as though it had an OSEM coil in the "SD" position, it's actually driving in -T because the OSEM coil is in the OS position. 
On the other side, the OSEM2EUL matrix corrects for a "SD" OSEM, with "more negative when moves in +T", and and has the (incorrect) -1.0 in the OSEM2EUL matrix. But since the SUS is actually moving in -T, making the flag occult more of the OS OSEM LED beam, yielding a more negative ADC signal, the -T is reported +T in the DAMP bank because of minus sign in "SD" OSEM2EUL matrix. 
So the phase between DAMP OUT and DAMP IN at DC is still zero, as though "everything was normal," because requested physical drive +T is sensed as +T.

Thus the Sensor / Drive phase is zero at DC like every other HSTS, we can use the same feedback -1.0 sign like every other DOF and every other HSTS.

Does this matter for the IFO?
No. This sensor is only used to damp transverse, i.e. transverse to the main IFO beam. If there're no defects on the SRM optic HR surface, and the transverse displacement doesn't span a large fraction of the beam width, then there should be no coupling into L, P or Y which are the DOFs to which the IFO should be sensitive. 
This is corroborated by Josh recent work where he measured the coupling of the "SD" OSEM drive (actually in the OS position, driving -T) and found it to be negligible; see LHO:83277, specifically this SRM plot.
Not only is the IFO not sensitive to the transverse drive from the OSEM, but also the absolute sign of whether it's +T or -T doesn't matter since there's no *other* sensors that measure this DOF that we'd have to worry about comparing signs against.

Should we fix it?
I vote yes, but with a low priority, perhaps during maintenance when we have the time to gather a "post transverse sensor sign change fix" set of transfer functions.

I have installed the level 2.0 HSTS damping filters into the FC1 damping bank. I also accepted the changes in SDF.

Today I installed Jeff's Level 2 HSTS damping filters on MC1 2 and 3. See alog 65310 as a reference for installation and rearrangement of the filters. I measured the new OLG for all dofs of MC1, and measured both the old and new OLG for all dofs of MC2. See the SusSVN for the OLG measurements.

The new and old filters are set up following the same scheme as we did for the recycling cavity mirrors. The SDFs have been updated for the new locations of the old filters (see attached screenshots).

Once I finished the measurements, I took all three MC damping filters to the new filters, and confirmed the IMC still locks with the new damping filters (yay). After, I reset the MC damping filters to the old filters for the time being. I am leaving the IMC locked overnight (with old damping filters).

Following work on other HSTS damping loops, see alog 65310, I updated the PR2 and PRM filter banks with the new damping filters, following the same scheme as SR2 and SRM (new filts in FM1-5 and 10, old filts in FM6-8, BR stays in 9). After making measurements of the OLGTF of PR2 and PRM (saved in SusSVN), I reverted the damping filters back to the old filters and SDFed the change. Reminder: we have rolled the EPICS gains into the "old_gain" filter so now all the dof damping gains should be set to -1. I also reverted the CDBIO State back to 2. I had it switched to 1 for the measurements.

Attached is a screenshot of the PRM SDFs accepted. I forgot to screenshot PR2 before confirming, so you will have to take my word for it :)