Oli, Elenna

Oli and I combed through some of the recent locklosses by hand, and noticed that there are at least two that have a 13 Hz oscillation in the LSC channels just before the lockloss.

1434317297

1434276630

This is reminiscent to us of PRCL losing gain due to thermalization which has caused 11 Hz ring ups before. We should keep an eye out. Note that one of the above locklosses has the "earthquake" tag, but it's very clear that the ring up caused the lockloss.

Oli and I went back about 1 week and checked the NLN locklosses by eye and only found these two so far.

To start, we can periodically check PRCL OLG or other LSC OLGs during thermalization to make sure we aren't losing significant optical gain. Or we can inject a line during commissioning.

TITLE: 06/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is LOCKING in OMC_WHITENING

Productive shift in which we had commissioning until 2PM. We were locked for the majority of commissioning, only losing lock in the morning (lockloss alog 85151). We reached NLN after doing an initial alignment (manual as is the case until PRX can be automated) at 16:49 UTC.

Relevant alogs from commissioning:

• A2L Script Alog 85155
• SQZ ASC Comissioning: Alog 85149
• Guardian Reboot (fixing AWG issue): Alog 85152
• DC6 P Noise Budget Injection: Alog 85156
• Elenna SDF Diff Reversions: Alog 85158
• HAM1 ISI FF: Alog 85162

After commissioning, there was another lockloss (a few minutes into observing) where a mysterious length kick on the Y arm seems to have been the cause - Lockloss alog 85160.

Relocking was somewhat difficult (and is still in progress) primarily due to ALSX losing lock. Firstly, scan-align failed to lock ALSY despite counts over 1. A manual movement of 3 taps in EY P immediately fixed the problem. Secondly, scan-align engaged immediately after ALSX lost lock despite counts being ~1 (very good for ALSX). After this, ALSX stalled in “crystal frequency” locking for 20 minutes. If this keeps happening, we can change the threshold for the crystal frequency sweep since it seems to be only 1% away from threshold. After we got past this, DC0 had an error and Erik and Dave fixed it within 10 mins with no disruptions. Alog 85164

Otherwise, locking has been automatic and reliable. This just in: EQ incoming - velocity over 1 um/s means we’ll probably lose lock.

LOG:

During the commissioning window this morning, I worked on the St0 to St1 feedforward for the HAM1 ISI. This time I borrowed some code from Huyen to try the RIFF frequency domain fitting package from Nikhil. This required using matlab 2023b which seems to have a lot of computationally heavy stuff like code suggestions added so it was kind of clunky to use and I'm not sure what all of the different fitting options do, so each dof took multiple rounds of fitting to get working. I also had to add an ac-coupling high pass after the fact to the filters because they all went to 1 at 0hz. Still the results I got for HAM1 seem to work pretty well. Attached spectra are the on-off data I collected for the X,Y and Z dofs. Refs are the ff off, live traces ff on spectra. Top of each image are the asds for the ff on & off, bottom is the magnitude of the st0 l4c to st1 gs13 tf. The improvement is broad ~10x less motion from 5 hz up to ~50hz. I'm looking at the rotational dofs still, but there is less coherence there, so not as much to win.

Elenna has said this seemed to have improved chard asc, maybe she has some plots to add.

At 16:14:31 PDT h1daqdc0 crashed. Its EPICS IOC stopped running resulting in white boxes on MEDM. Last log was 15:56.

I connected a monitor to its VGA port, its console was showing the login prompt. The cursor was not flashing and an attached keyboard was unresponsive.

Erik and I rebooted the machine by pressing the front panel RESET button. It booted and started with no problems.

Currently we don't know why dc0 froze this way.

TITLE: 06/18 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 27mph Gusts, 14mph 3min avg
    Primary useism: 0.11 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

Currently relocking and in MOVE_SPOTS. Wind and ground motion are still a bit high.

Unknown cause lockloss. Could be attributed to the wind, since it is on the rise and expected to continue tonight. Gusts were over 30mph at the time of the lockloss.

It seems that there was a length kick in EY that was first seen causing the lockloss. Lockloss report.

There were a few SDF diffs before observing in ramp times that I think came from running various scripts like the A2L and the DARM offset step. I reverted all of the changes so we (hopefully) don't get another SDF diff next time we lock.

I ran a noise budget injection into DC6 (centering loop for POP WFS), using a broadband excitation from 10-100 Hz. Based on the results in the DTT template (attached), there is not any measureable contribution to noise in DARM when injecting about 100x above ambient in the DC6 P control (bottom left plot, ref trace shows quiet time, live trace shows injection). We can include this channel in the ASC noise budget, but our code won't even generate a trace since the reference DARM and injection DARM shown here are exactly the same (top left plot, blue reference trace shows quiet time, red live trace shows injection time).

At a later time I will check DC6 Y.

Ran A2L script for all sus during comissioning today. Screenshot attached.

Wed Jun 18 10:11:15 2025 INFO: Fill completed in 11min 11secs

H1 ISI CPS Noise Spectra Check - FAMIS 26048

NEW and IMPROVED H1 ISI CPS Noise Spectra check Now includes HAM1 !

HAM1 currently have some very loud VAC equipment attached to it which is running and may be why HAM1 looks so terible relative to the rest of the othe HAMs.

Sheila, Camilla

We can see large SQZ changes dependent on the OPO PZT value, we;vee seen this before, some alignment changes from this PZT should be adjusted for by FC AS and FC beamspot control. The FC beamspot control has been off since the vent, but we're turned FC beamspot control on again in the hope to reduce this dependency.

Yesterday we needed to turn the ASC on to improve high freq sqz 85147 and since we've started using the THERMALIZATION guardian 85083 to slowly adjust SRCL Offset, our squeezing and ASC error signals are reduced slightly (see below). We have turned back on the SQZ ASC as expect this new guardian will stop the ASC running away.

Now we have the THERMALIZATION guardian working, the ADF measured sqz ang change has reduced (see below), we want to try turning back on SQZ_ANG_SERVO which will take a little tuning of settings. You can see in this plot that when the OPo PZT changed, the servo would have adjusted the sqz angle too.

• THERMILIZATION GRD on, SQZ ASC off plot: ASC error 0.35, ADF sqz ang change 7.
• THERMILIZATION GRD off, SQZ ASC off plot: ASC error 0.4, ADF sqz ang change 18.
• THERMILIZATION GRD off, SQZ ASC on plot: ASC error N/A, ADF sqz ang change 11.

Also touched the SHG launch waveplates to decrease the rejected power in H1:SQZ-SHG_FIBR_REJECTED_DC_POWER.

Jonathan, Erik, Dave, Ibrahim, Tony:

Following the front end restarts yesterday there has been a spate of Guardian AWG connection issues e.g. alog85130

Erik recommended that we reboot h1guardian1 at the next opportunity to force new front end connections for all Guardian nodes, rather than restart each node as the problem arises.

Following a lock loss this morning, the control room gave us the go ahead to reboot h1guardian1 at 08:49 Wed18jun2025PDT. Like TJs last reboot 12 days ago, h1guardian came back and restarted all of its nodes quickly and without any problems.

Unknown cause lockloss

However our two guesses are:

• Abrupt start/stop of a bee forklift
• Glitch at EY (which saw the lockloss first

Reminder that for the past month HAM1 pressure was being reported by a temporary "H1" version of the old cold-cathode PT100A (called H1:VAC-LY_X0_PT100B_PRESS_TORR) which uses an ADC in h0vacly and calcuates the pressure from the raw voltage signal.

Yesterday Patrick installed the h0vaclx full Beckhoff readout of this gauge via an ethernet connection. The channel name for this gauge from now onwards is H0:VAC-LX_X0_PT100_MOD2_PRESS_TORR

For now I'm showing both channels on the Vacuum MEDM and FOMs, H1:VAC-LY_X0_PT100B_PRESS_TORR upper, H0:VAC-LX_X0_PT100_MOD2_PRESS_TORR lower.

Note the H1 channel is a bigger number, the voltage signal increased slightly when Gerardo plugged the ethernet cable into h0vaclx yesterday.