J. Kissel, T. Shaffer

In the current O4 paradigm of SDF practice, we've minimized the number of .snap files to track by accepting the settings of some suspension whose setting don't change between "IFO down" and "Observing." That includes SUS RM1 and RM2, which live on the sushtts model -- that also now is home to PM1. RM1 and RM2 are ALIGNED at the moment, with damping loops and alignment offsets ON, and yet their settings do not show up as "different" from the safe.snap. This disagrees with the principle of "safe" but it's how we're doin it. 

As such, I've accepted PM1's settings in the ALIGNED state into the sushtts safe.snap.

TJ, Ryan C, Oli, Camilla. WP#12561

Randy had forklifted ISCT1 just outside of the cleanroom. We pushed ISCT1 back into place and checked it's location and height. Removed yellow VP covers and replaced bellows, then removed guillotines.

Oli, Edgard, Jeff, Brian

This post is meant to give a clearer explanation of the work in [LHO:84296] and its many comments. We are trying to find a new set of gains for the M1_OSEMINF filter banks for SR3 to calibrate the OSEMs to be in agreement with the HAM5 GS13s.

To do so, we drive the HAM5 ISI in { X , Y , Z } and record the response of the relevant OSEMs between 5 to 15 Hz.  At these frequencies, the M1 stage of the suspension should start to become inertial, and the M1_DAMP / SUSPOINT response of each individual OSEM should asymptote to -1, because the OSEMs would be measuring their support point on the cage [barring internal dynamics of the cage itself].

To increase the accuracy of the calibration, we use the MATLAB model of the HLTS and use the full extent of the 5-15 Hz data instead of only the asymptotic behavior.

I post here the code used to generate these results. The code requires the new Common/MatlabTools/ExportedModels folder from the SusSVN [LHO:84458]. The detailed results of the calibrations mentioned is shown below.

_____

• We took a series of transfer functions driving HAM5_ISO_{ X , Y , Z } to measure SR3_M1_DAMP_{L,T,V,R,P,Y}. The templates for this measurement are saved in the sus SVN under [HLTS/SR3/H1/Common/Data/]
  • We can see a lot of cross-coupling in some of these transfer functions. For example, the first attachment shows SUSPOINT V to M1 R cross-coupling that ends up being consistent with sensor miscalibration. This miscalibration is also seen in the large V-to-R and R-to-V couplings in the M1 to M1 transfer functions that Oli took in [LHO:83939].
• From the measurements, we reconstruct the following transfer functions:
  • SUSPOINT V to SR3_M1 T1, T2, and T3. Which are the OSEMs related to the V, R, and P degrees of freedom of SR3.
  • SUSPOINT L to SR3_M1 LF, and RT. Related to the L and Y degrees of freedom.
  • SUSPOINT T to SR3_M1 SD. Related to the T degree of freedom
• These transfer functions are shown in the second attachment. Two interesting things to note:
  • None of them asymptote to -1. In amplitude, they hover around 0.75 or so.
  • The Vertical sensors are backwards. This is not important for what we're doing, we will calibrate by using the absolute value.
• We can get the scaling factors needed to make them asymptote to one by fitting the individual OSEM transfer functions to the model.  We fit by using linear regression between 5 and 15 Hz. The scaling factors calculated from the figures in the second attachment are:
  • T1 needs to be multiplied by:   2.4539
  • T2 needs to be multiplied by:   1.4819
  • T3 needs to be multiplied by:   1.4125
  • LF needs to be multiplied by:   1.3206
  • RT needs to be multiplied by:   1.3705
  • SD needs to be multiplied by:   1.3806
• Therefore, after we multiply the OSEMINF gains that were in place at the time of measurement by these scaling factors, the new OSEMINF gains should be:   
  • T1: 3.627
  • T2: 1.396
  • T3: 1.345
  • LF: 1.719
  • RT: 1.490
  • SD:1.781
• The T1 gain is egregiously high, which makes all of us a bit nervous. Oli has been in the process of checking if these numbers actually make sense. These results will be posted in another log... This one is already too long.

Jeff, Oli

Looking into (1) from 84462.

Before this vent, although the cable pinouts were flipped for both RMs, the phase for the TFs were at 0. Now that the cables have been flipped (fixed), we are seeing that the closeout transfer functions that I took 84498 are showing that the phase for the RMs is now flipped, at 180. Additionally, both RMs are still needing the damping sign to be +1, instead of the usual -1.

Since there does still seem to be a sign issue somewhere in the sensor chain for RM2, we would have expected the 'after' transfer function phases to differ between RM1 and RM2, so it's strange that they both have switched over to 180.

I've attached the transfer functions for RM1 and RM2 comparing the after vent measurements to the last measurements we had done for them with damping loops off, which was in 2022.

Thu May 22 10:16:19 2025 INFO: Fill completed in 16min 15secs

Patrick, Jonathan, Dave:

MC2 camera went offline at 06:30 today, this was another instance of the new software eventually running into the 1024 limit for open files. This process is on h1digivideo4 and surprisingly had only been running for 8 days.

Jonathan increased the file limit on this machine to 40,000 and we restarted the process. MC2 h1cam07 did not need a power cycle.

Summary: adding a digital offset to get a flat sensing function does not correspond to SRM detuning phase of 90, as modeled in FINESSE.

recap: I have modeled the SRCL DOF detuning due to mode mismatch. Nominally, we want the detuning phase of the SRM to be ø = 90˚ for resonant  sideband extraction conditions, where there are no optical spring effects. However, mode mismatches affect this phase, and consequently we can see optical spring effects showing up in the DARM sensing function.

On site, after locking we can add a digital offset to the SRM phase to flatten the sensing function, but then the question is “does the digital offset that flattens the DARM sensing function correspond to  ø = 90˚?”

And the answer is “no”, at least as modeled in FINESSE. 

I have added an offset to SRCL and looked at the corresponding sensing function, and it is clear that a ø = 90 is not necessarily a flat response (starting from 5 Hz), as the plot attached shows. 

In this case I’m looking at the RF readout (from DARM to AS45_Q), and where the average mismatch between all cavities is 0.01% (the start locking point is ø = 90.03˚). This also demonstrates that even a tiny mismatch can show optical spring effects.

TITLE: 05/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 11mph Gusts, 6mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: HAM1 pumping continued overnight, but starting about 1.5 hours ago the pressure started rapidly climbing. No cause determined as of yet. VAC team has been contacted.

EDIT: Had the wrong channel trended, corrected in current attachment.

Starting around 6am today the vacuum pressure in HAM1, which had dropped to 6e-06 Torr, started rising rapidly. At time of typing it is up to 9.8e-04.

Richard is heading to the LVEA to investigate.

Jordan, Travis, Janos

HAM1 pumpdown continued. The new Agilent leak checker is backing the turbo pump. We are waiting for the He-signal to be at least <5E-9 Torr, so we could start leak checking. After evaluating the trends, it is likely that tomorrow morning this happens. Also, regardless this happens, the Ion-pump (IP13) will be possible to be opened up. Also, an interesting note, that after achieving molecular flow in HAM1, the corner pressure suddenly decreased by ~5-6E-9 Torr, that suggests a E-3 Torrl/s gas load through the HAM1/HAM2 septum viewport O-rings, so there is indeed some communication between HAM1 and the rest of the corner.
The overall pressure in HAM1 in the end of the day is ~9E-6 Torr, which aligns well with fully gutted HAM chamber pumpdown speeds in the past.

The large Gate Valves, first GV7, then GV5 was opened. The fully open position was achieved at ~45 and ~47 psi, respectively. No issues were encountered during the process. The corner pressure went down quickly to ~3.5E-8 Torr. RGA scans are continuously being taken.

FRS34149

Camilla and I removed the broken Model#VS35S2T0 Serial#3179 shutter and replaced it with Model#VS14S2T0 Serial#8796. The replacement unit had a slightly smaller outer diameter so we traded some posts with beam dumps that were on the side of the table not in use to get the correct height.

 Y-End TX Module Maintenance was performed today.
Everything went fairly well while following the instructions laid out in T1600436 -V12 Except the AOM Rejected Power measurement. This measurement inbetween PBSC2 and beam dump 2  is measuring the AOM power that we were dumping on to the beam dump. It didn't ever give us a static value like all the rest of the measurements. The max was a 18.5 mW  jump right after the we opened the shutter. Then the power would decay down to a lower value of 13.6 mw but over several minutes. The decay rate seemed to get longer after a while. The excitations were indeed turned off. We had zeroed the low power sensor with a shuttered background measurement. I'm not sure why that seemed to not be a steady number. We ended up taking the number that seemed like it had initially asymptote to before we saw the slow fall off.

The Beam Spots all look great. TX Sphere might be very slightly  to the right of perfectly center, but I think it's fine.
 

OLTF went well, Setup was well documented.

TITLE: 05/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Busy day today! Arm gate valves are open, all HAM HEPI's are unlocked, and HAM1 continues to pump down. More activities below:

• After h1susb123 crashed (alog84500), all 18-bit DACs were upgraded to 20-bit: alog84508
  • 4x gain added to COILOUTFs on upgraded DACs: alog84509
  • MEDM screens updated: alog84514
• PSL PMC/FSS alignment: alog84512
• ALS-X beam profiling: alog84513
• h1sush7 crash and recovery: alog84521
• HAM1 cabling: alog84525

LOG:

13:25:11 Wed 21 May 2025 PDT all models on h1sush7 stopped running. The SWWD to h1iopseih7 started its countdown with 100% IPC receive errors.

I set a bypass time of 999999 on h1iopseih7 to interrupt the countdown.

We first restarted all the models. This did not clear the error, and we found a PCI bus issue whereby only one of the four ADCs could be found.

As a precautionary measure we fenced h1sush7 from the Dolphin fabric.

Next we power cycled the computer. This fixed the PCI bus issues, all cards are visible and all models starting running.

I cleared the SWWDs and handed the system over to the control room.

Note, there were TIMING error flashes during this recovery time which we have not traced down.

[Wed May 21 13:25:11 2025] h1iopsush7: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Wed May 21 13:25:11 2025] h1susauxh7: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Wed May 21 13:25:11 2025] h1sussqzin: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Wed May 21 13:25:11 2025] h1susfc1: ERROR - An ADC timeout error has been detected, waiting for an exit signal.