Operator Was trying to lock in LOCKING_ARMS_GREEN[12] and ALS_YARM Faulted when It was trying to do SCAN_ALIGNMENT[57].

We Manual'd ALS_YARM back to UNLOCKED[-28]  then reloaded ALS_YARM.
Operator then took ISC_LOCK to GREEN_ARM_MANUAL[13]


Error Log:

 ALS_YARM W: RELOADING @ SCAN_ALIGNMENT.run
2025-06-17_21:15:15.740544Z ALS_YARM [SCAN_ALIGNMENT.run] Generating waveforms
2025-06-17_21:15:16.229352Z ALS_YARM [SCAN_ALIGNMENT.run] Start time is 1434230144
2025-06-17_21:15:16.229580Z ALS_YARM [SCAN_ALIGNMENT.run] Opening awg streams
2025-06-17_21:15:16.232982Z awgSetChannel: failed awgnewchannel_1(chntype = 1, arg1 = 0, arg2 = 0, awg_clnt[99][0] = 31370384) H1:SUS-TMSY_M1_TEST_P_EXC
2025-06-17_21:15:16.232982Z Error code from awgSetChannel: -5
2025-06-17_21:15:16.233280Z ALS_YARM W: Traceback (most recent call last):
2025-06-17_21:15:16.233280Z   File "/usr/lib/python3/dist-packages/guardian/worker.py", line 494, in run
2025-06-17_21:15:16.233280Z     retval = statefunc()
2025-06-17_21:15:16.233280Z   File "/opt/rtcds/userapps/release/als/common/guardian/ALS_ARM.py", line 1525, in run
2025-06-17_21:15:16.233280Z     ex.open()
2025-06-17_21:15:16.233280Z   File "/usr/lib/python3/dist-packages/awg.py", line 595, in open
2025-06-17_21:15:16.233280Z     raise AWGStreamError("can't open stream to " + self.chan \
2025-06-17_21:15:16.233280Z awg.AWGStreamError: can't open stream to H1:SUS-TMSY_M1_TEST_P_EXC: Error setting up an awg slot for the channel (-120)
2025-06-17_21:15:16.256804Z ALS_YARM ERROR in state SCAN_ALIGNMENT: see log for more info (LOAD to reset)
2025-06-17_21:15:35.011679Z ALS_YARM MODE: MANUAL
2025-06-17_21:15:35.017804Z ALS_YARM MANAGER: removed
2025-06-17_21:15:41.635373Z ALS_YARM MODE: AUTO

The LVEA has been swept.
The Vac team still has a pump on HAM1 that can be heard throughout the VEA.

Since we plan to do some TCS tests on the IFO in the near future, I recommend we make use of the AWGLines guardian, which injects a variety of lines that can be used to monitor things like noise couplings and optical gain changes.

Taking a quick survey of the guardian, I don't see any immediate issues. The guardian injects these lines: intensity noise (47.3 Hz, 222 Hz, 4222 Hz), frequency noise (25.2, 203, 4500 Hz), jitter (111.3, 167.1, 387.4 Hz), and MICH (40.7 Hz), PRCL (35.3 Hz) and SRCL (38.1 Hz). There is an additional state that engages the 8.125 Hz notches in the ASC and then injects one ASC line. The guardian is currently set up to inject in CHARD Y (8.125 Hz), but that can be adjusted to any ASC loop. The amplitude for the CHARD Y injection looks good, but that will need to be adjusted for other ASC loops. I have no idea if the laser noise and LSC noise line amplitudes are "good", but we ran this guardian regularly before O4 started so they are probably ok.

It does not appear that any notches or bandstops are engaged for the laser noise or LSC injections. Not sure if we want to change that. The cable for frequency noise will need to be plugged in to ensure the frequency noise gets injected.

The way the states are currently written, you will need to manual to "SET UP ASC INJECTIONS" to ensure the ASC line gets injected before going to "INJECTING". The "STOP INJECTING" state will stop all the injections, including the ASC injections and revert all changes such as switches and filters.

Sheila, Matt, Camilla

We replaced the laser curtains around ISCT1/IOT2L that were removed fro the HAM1 vent, so now this area can be taken to local laser hazard. 

Tue Jun 17 10:10:11 2025 INFO: Fill completed in 10min 7secs

Late entry from last week. Roger's Machinery completed the new Kobelco installation and startup last Tuesday.  Our last task before acceptance testing of the system was to replace the filter elements in the filter tree.  When we opened the housings, we discovered that one of the elements was mangled and had evidence of rough tool use on it.  When we removed the element, we could see that there was some evidence of galling in the threads where the element screws into the filter housing (see pics).  We will order a new housing and replace it before continuing with testing the system.  

We have completed the upgrade of H1 frontends to RCG5.5.0 at 09:51.

Detailed alog will be written but surprises found/re-remembered:

EX dolphin frontends need to enable an unused port on the EY switch because the EX switch has no port control (damaged in Apr power outage)

PSL DBB model had an obsolete Dolphin IPC sender back when it used to have a dolphin card. New RCG doesn't allow senders with no cards. Removed the sender from the model, a DAQ restart is pending for this model

We had upgraded h1omc0 to 5.5.0 some time ago, but the H1.ipc file had changed so it needed a restart. Prior to restart it was clobbering the SWWD IPCs between sush34 and seih23, seih45.

As Kevin and Vicky found a couple of weeks ago, the SQZ HD PD A seems to be loose, it stopped working and Vicky re-seated it and it worked again. It again had stopped working so I poked it (it started pitched down) to make it work, now it will need realigning before the HD is functional again.

TITLE: 06/17 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 4mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

IFO is in DOWN for PLANNED MAINTENANCE

H1 had just gotten to NLN as I arrived. I then put it in DOWN for today's maintenance. Activities slated for today:

• RCG Upgrade and CDS Model work  - will require reboots. alog 85092 contains the SDF Safe screenshots.
• VAC drill work, FC enclosure guague replacement, CP7 fill level troubleshooting
• ALS beatnote adjustment
• ISCT7 Homodyne Work
• HAM ISI measurements
• Bee removal

WP12536 RCG5.5.0 Upgrade

WP12624 SWWD variable bypass time h1iopsush2a

WP12625 Fix broken ADC selector h1hpiham4

WP12626 Fix partial ADC MEDM by adding named parts

Jonathan, Erik, EJ, Dave:

Yesterday, Mon 16jun2025, we did the final round of builds and installs of all the models against RCG5.5.0

h1build was rebooted against the new boot server (h1vmboot5-5) and was used to do the builds/installs.

After the builds, I ran each model through check_model_changes and then wrote an output files parser:

check_rcg550_daq_changes.py

All the INI changes were expected, most had the RCG additional channels expected from going from 5.1.4 to 5.5.0.

Exceptions were:

h1iopsusex had 1 less because it was upgrading from 5.3.0 so already had timing card temp chan

The following had additional ADC naming parts:

isibs, isiham3, isiham4, isietmx, isietmy, alsex, alsey, ascimc

Build took about 2 hours. Install took 2hrs 13mins, backing up targets to target_archive took 45GB of disk space, /opt/rtcds is at 89%

TITLE: 06/17 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: We stayed locked the entire shift, high frequency SQZing hasn't been the best.
LOG: No Log.

00:01 UTC Observing

Jennie W, Keita, Rahul

Today the three of us went into the optics lab to upgrade unit S1202965 with the c'bore washer and qpd clamp plate that give a ~ 2 degree tilt between the QPD plane and the mount plate. See detail D in D1300720.

Looking at the assy solidworks file, LIGO-D1101059, if the back face of the photodiode array is facing to the back, the longer clamp leg points towards the front, and the notch on the tilt washer should be approx at the 4o'clock position.

We first checked the alignment into the array photodiodes currently and realised the beam was off by a large amount in yaw from the entrance aperture.

Keita had to change the mounts for the PZT mirror and lens as these were slightly tilted on the translation stage and it seemed like we needed some more robust alignment setup.

We then tried aligning with the upstream steering mirror and PZT mirror but can see multiple beams on each array PD. To check that the beam is not too large at the input aperture we want to re-profile the beam size on the way into the ISS assembly.

We left the set-up with the M2MS beam prolfer set up at the corner of the table and rough alignment of the beam into it, more fine adjustment needs to be done.

Ryan S., Elenna

Thge MOVE_SPOTS state is taking 13 minutes (!) to complete, because the YAW3 ADS DOF is very far off and taking a significant time to converge. Both Jenne and I have found that bumping up the YAW3 gain (PRM yaw) slowly helps converge the loops much faster.

Ryan kindly helped me update the state code to slowly increase the gain if the convergence is taking too long. We added a new timer 'ADS', that waits for one minute after the new A2L gains are ramped (so an additional minute after the 2 minute ramp time of the A2L gains). If, after that first minute, there is still no convergence, then the YAW3 gain is doubled. After that, the 'ADS' timer waits 2 minutes, and again doubles the gain. This process can happen up to three times, which should increase the YAW3 gain to a maximum value of 8. Jenne and I have found that the gain can go as high as 10 in this state. The two minute waits give the other ASC, like SRC1 and INP1 Y time to converge as the ADS pulls the PRM in faster. Once the convergence checker returns true, the YAW3 gain is set back to 1.

We will monitor how this proceeds on this locking attempt. I updated the guardian notify statements so it states when the gain is increased.

All looks well, aside from the known issue with LAB2 and LVEA5 seems frozen, I'll investigate that tomorrow during maintenance.

Oli, Camilla, Sheila, RyanS

It was pointed out (84972) that our new SRCL offset is too big at the beginning of the lock, affecting the calibration and how well we are squeezing. Camilla had the idea of taking the unused-but-already-set-up THERMALIZATION guardian and repurposing the main state so it steps LSC-SRCL1_OFFSET from the LSC-SRCL1_OFFSET value at the end of MAX_POWER to the official offset value given in lscparams (offset['SRCL_RETUNE']). This stepping starts at the end of MAX_POWER and goes for 90 minutes. Here is a screenshot of the code.

To go with this new stepping, we've commented out the line (~5641) in ISC_LOCK's LOWNOISE_LENGTH_CONTROL (ezca['LSC-SRCL1_OFFSET'] = lscparams.offset['SRCL_RETUNE']) so that the offset doesn't get set to that constant and instead keeps stepping.

To get this to run properly while observing, we did have to unmonitor the LSC_SRCL1_OFFSET value in the Observe sdf (sdf).

Kiet and Sheila,

Following up on the investigation posted in aLOG 84136, we examined the impact of higher-order violin mode harmonics on the contamination region.

We found that subtracting the violin peaks near 1000 Hz (1st harmonic) from those near 1500 Hz (2nd harmonic) results in frequency differences that align with many of the narrow lines observed in the contamination region around 500 Hz.

Violin peaks that we used (using O4a+b run average spectra)

F_n1 = {1008.69472,1008.81764, 1007.99944,1005.10319,1005.40083} Hz 
F_n2 = {1472.77958,1466.18903,1465.59417,1468.58861, 1465.02333, 1486.36153, 1485.76708} Hz 

Out of the 35 possible difference pairs (one from each set), 27 matched known lines in the contamination region to within 1/1800 Hz (~0.56 mHz)—most within 0.1 mHz. Considering that each region actually contains >30 peaks, the number of matching pairs likely increases significantly, helping explain the dense forest of lines in the comtaimination region.

Next steps:

• Testing all the peaks in the 1st and 2nd harmonic region.
• We propose to identify lines with highest power in the contamination region, trace them back their source modes and discuss the feasibility of target damping them. 

The Fscan run average data are available here (interactive plots): 

Fundamental region (500 Hz): 

• 400–500 Hz
• 500–600 Hz

1st harmonic region (1000 Hz): 

• 900–1000 Hz
• 1000–1100 Hz

2nd harmonic region (1500 Hz): 

• 1400–1500 Hz
• 1500–1600 Hz