[Keita, Daniel, Karmeng]

Particle counter acting up (black screen when we move the stand, and high particle count for the first three measurement). Picture for comparison with hand held counter.

We remove all three cables connected to the old OPO, the PZT cable is wrapped with a foil as a marker.

The old OPO is removed, wrapped and kept in the bag used to store the new OPO. New OPO is placed in the chamber, but not bolted on.

TITLE: 12/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is in IDLE for Planned Engineering

TLDR - Last few big remaining lock health checks were successfully done.

First, initial alignment was ran successfully and automatically. 

We then started our day with 5 lock steps we wanted to confirm as working in the case that we could not fully lock:

• ISS Second Loop
  • Confirmed working by misaligning PRM and taking LASER_POWER to 62W and then closing the ISS Second Loop. Ryan S and I did this successfully.
• Lownoise ESD Transition
• Lownnoise Coil Driver States
• OMC_Whitening
• Laser Noise Suppression

To get around SRC1 P/Y instability, that would take time we don't have to fix, we locked while manually touching SRM at different times, notably: DRMI_LOCKED_CHECK_ASC, PREP_ASC_FOR_FULL_IFO, MOVE_SPOTS. However, after not being able to get past MOVE_SPOTS - couldn't keep RFPOP90 low enough with SRM touches, we tried a different method to get over the remaining checks suggested by Jenne:

1. Stop at 25W, touch SRM (counts on H1:LSC-POPAIR_B_RF90_I_NORM_MON good if under 12)
2. Manual to Lownoise Coil Drivers - Successful.
3. Auto until LOWNOISE_ESD_ETMX - Successful.
4. Manual to OMC Whitening, damp violins - Successful. Tony Damped violins.
5. Manual to Laser Noise Suppression - Mostly successful - Ryan S took care of this with advice from Keita about the scaling of the IMC_REFL and LSC_REFL IN1/2 and Fast Gain Servo Gains.

For a very comprehensive summary of locking progress, check out Ryan S's Wonderful Alog 88498.

Lock Acquisitions:

1. Lockloss due to SRC1 P/Y at Prep_ASC_FOR_FULL_IFO. SRM railed prior.
2. Lockloss due to Technical Cleaning at HAM2. HAM2 WD Tripped. Cleaning stopped after this.
3. Lockloss due to failed SRM adaptation (with ops acting as SRC1) at MOVE_SPOTS
4. Lockloss at Laser Noise Suppression upon activation of IMC_REFL Fast Gain at 25W
5. Lockloss at Laser Noise Suppression upon activation of IMC_REFL Fast Gain at 25W - though this time we confirmed it was likely the fast gain since Keita and Ryan S stepped through the state with gains scaled to 25W.

Meanwhile,

• Technical cleaning was started at HAM1/HAM2 (but unknown if completed since after a WD trip, they stopped due to locking).
• HAM1 Cleanroom was turned on and prepped for Monday Vent (alog 88501)
• GV5 and 7 Hard-closed (alog 88499)
• HAM7 HV Turned off (alog 88497)
• HAM7 OPO work is way underway, with OPO in but not fully installed.

LOG:                                                                                                                                                                                                      

I. Abouelfettouh, T. Sanchez, K. Kawabe, M. Todd, R. Short

Ibrahim kicked off the locking attempts this morning after an initial alignment. It sounds like one lockloss was during PREP_ASC due to SRM alignment running away (before the "human servo" was implemented), and another was simply due to cleaning activities near HAM1/2. More details in his shift summary.

Matt set the X-arm ring heaters back to their nominal settings after having used inverse filters yesterday; see alog88494.

While relocking, we noticed that PRC1_P seemed to be pulling alignment in the wrong direction after engaging DRMI ASC, so I turned it off and aligned PRM by-hand. During ENGAGE_ASC, I noticed ADS PIT3 was taking a long time to converge, so after all ASC and soft loops had finished, I checked the POP_A offsets, and they indeed needed updating. Pitch was a bit different, so this explains why PRC1_P was misbehaving. I've accepted these in SDF, see screenshot. During this whole relocking stretch, Ibrahim had been keeping SRM well aligned as SRC1 ASC is still disabled, but that proved too difficult during MOVE_SPOTS and we lost lock.

On the next attempt, we were able to get all the way to 25W automatically (with Ibrahim again acting as the human SRC1 servo). Instead trying to keep up with the spot move, we jumped to LOWNOISE_COIL_DRIVERS, where I watched the coil driver states successfully change for all optics (PRM, PR2, SRM, SR2, BS, ETMY, ETMX, ITMY, and ITMX). Then, we were able to simply return ISC_LOCK to auto and request LOWNOISE_ESD_ETMX, which exercised the lownoise ESD transitions for both ETMs. This worked without issue. We then planned to test OMC whitening, so we jumped to the OMC_WHITENING state where Tony and Ibrahim began damping violin modes, which were very rung up. Before the violins were able to damp low enough to turn on OMC whitening, we decided rather than waiting, we should try the REFL B transition done in LASER_NOISE_SUPPRESSION first. We turned off violin damping, I commented out the step of engaging the ISS secondloop in LASER_NOISE_SUPPRESSION (we would test this later, but couldn't at this point since we only has 25W of input power), and jumped down to LASER_NOISE_SUPPRESSION. The state ran without issue until the very end when the IMC REFL servo fast gain is stepped up as the IMC REFL input gains are stepped down, which is the last step of the state and only there to potentially survive earthquakes better, and caused a lockloss.

The final locking attempt of the day began the same as the one before, with 25W being achieved automatically, jumping to LOWNOISE_COIL_DRIVERS, going through the lownoise ESD states, and jumping up to OMC_WHITENING. Contrary to before, we waited here while damping violins until the OMC whitening was turned on. I'd argue Guardian turned this on a bit prematurely as the OMC DCPDs immediately saturated, but the IFO did not lose lock. Violin modes damped quickly and soon the saturation warnings subsided. Our plan after confirming the OMC whitening was working was to try LASER_NOISE_SUPPRESSION again, but after talking through it and looking at Guardian code with Keita, we decided we should use some different gain settings to compensate for the fact we were again only at 25W. We eventually decided on the figure of 8 dB more gain was needed on the input to the IMC and LSC REFL common mode boards, which Guardian adjusts during this state. I started going through the steps of LASER_NOISE_SUPPRESSION by-hand, but raising the IMC REFL servo IN1 gain to 17 dB instead of 9 dB and the LSC REFL servo IN1 and IN2 gains to 14 db instead of 6 dB. I didn't get all the way to 14 dB for LSC REFL as we started hearing test mass saturation warnings, so I stopped at 10 dB instead. The last step of the state is to lower each of the IMC REFL input gains as you increase the IMC REFL fast gain, but on the fourth iteration of the step, we lost lock. It's possible the fast gain should have been scaled also due to the lower input power, but at least this was confirmed to be the problem step as it's the same place we lost lock on the previous attempt.

After this last lockloss, we tested functionality of the ISS secondloop by ensuring PRM was misaligned, raising the input power to 62W, and using the IMC_LOCK Guardian to close the secondloop. This worked without issue and everything was returned to normal.

Even though we were not able to fully recover H1 to low noise today, overall we believe we have confirmed the functionality of the main systems in question following the power outage last week and various CDS/Beckhoff changes this week. Arm gate valves are now closed in preparation for the HAM1 vent on Monday, and we plan to see H1 again in its full glory roughly mid-February 2026.

I powered on the HAM1 cleanroom at ~3:10 PST in prep for next week's HAM1 vent.

To prevent the alarms system from being permantly RED I have removed the GV5 and GV7 channels while we are vented.

Current alarm is for PT114B cold cathode (CP1) which was tripped during the closing, we expect it to "catch" soon.

Per WP 12926

GV-7 & GV-5 hard closed at 14:16 PST and 14:34 PST respectively. Metal valve to gate annulus opened as well.

PT-114 and PT-134 pirani interlocks tripped while I was nearby opening the annulus valves. I have re-renabled them from the control room.

FC-V3 (BSC3) and FC-V4 closed as well to isolate the FCT.

Plot of PT-120B (BSC2), PT-124B (CP-1) and PT-144B (CP-2) during valve closure attached.

We turned off the HV bypass for upcoming HAM7 work.  The power is located in the racks on the Mezannine in the Mechanical Room.

I followed Fil's instruction by first turning off the 24V for the interlock chassis, followed by removal of the bypass from the interlock chassis and then switching off the SQZ_PZT power.  Finally I switched off the SQZ_TTFSS power, so that all high voltage is off.

Marc, Keita

Fri Dec 12 10:08:13 2025 INFO: Fill completed in 8min 10secs

Yesterday morning during locking attempts I noticed the ring heaters in the XARM were set incorrectly, and ETMX was completely off. I'm not completely sure why this happened, but my guess at this point is that after using the inverse filters last week, someone accepted SDFs or reverted to the safe values and these inverse filters were turned off but the set values were not restored in the nominal state. I'll try and understand if we can add this check to the TCS_RH_PWR guardian.

Anyway, I reused the inverse filters last night for ETMX and set them back to nominal this morning with the same set power.

TITLE: 12/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.30 μm/s 
QUICK SUMMARY:

IFO is LOCKING

Plan for the morning is to continue locking attempts until ~2PM

We have been seeing a low rate of data drops with the frame writer serving as both the frame writer and the data concentrator for the DAQD 0 systems.  This work is to try an alternate configuration.  Moving the gds broadcaster to be a data concentrator and making the frame writer single purpose again.

The data drops are due to messages from teh front end arriving too late and being discarded.  We are not seeing them on the DAQD 1 leg, only the 0.  This leads us to tend towards the issue be the load (and thus responsivness to input messages) of the FW machine.

Today I adjusted the system such that GDS0 became the data concentrator and the broadcaster.

I've attached a diagram of the current layout.

The main changes:

1. Link TW0 to GDS0, this was done first to ensure the data link worked well and TW0 keeps functioning.
   1. Add a 10G card into gds0 and two
   2. Moved TW0 to read data from gds0
2. Move the FE input into the gds machine and reconfigure the FW machine to just be a receiver

The final migration followed this rough order

• stop cps_xmit, cps_recv, dix_xmit on fw0
• stop dix_recv on gds0
• move the fiber to gds0
• configure the interfaces on gds0 and start
  • cps_recv
  • cps_xmit
  • dix_xmit
• configure fw0 to use dix_recv

The control room monitoring and medm screens still expect a DC, FW, TW, NDS, and GDS.  So gds0 as the DC is exporting DAQ-DC0 variables, and we are running a epics proxy ioc which maps DAQ-GDS0 channels to DAQ-DC0 for now.  This will change in the future.  Most of the DC0 variables will probably be taken over by the cps_recv process (this is in testing on the large test stand in LLO).

There were a few daqd restarts to make sure everything was working.  Data is flowing and fw0 and fw1 are producing identical frames.

The plan is to let this run though til January and evaluate the error rate.

A. Effler, R. Short

People had noticed earlier an issue with SRM's coil driver binary IO state (see alog88486) so other optics were checked. ITMX's monitors showed some concerning colors (see first screenshot), but after taking a spectra of the quad's top-mass OSEMs comparing similar lock states before and after the power outage last week (see second screenshot), I am confident in saying the actual behavior of ITMX is unchanged and this boils down to a readback issue on the binary IO. This evidence is backed up by the fact that ITMX has been correctly aligned in our locking attempts, and Anamaria and I cycled the state requests a few times and saw expected behavior from the suspension. Dave says he and others will be looking into this.

Overall: The main change we are seeing in the LSC and ASC signals with the PR3 and SR3 estimators ON is the lowering of the 1 Hz resonance in ASC, which is known to be a bit of a problem peak.

We've been wanting times within the same lock where we take quiet times with the SR3 and PR3 estimators in various ON/OFF configurations so we can get a better look at possible differences in ISC signals, since the difference we are looking for, if any, is very small and the frequency response changes from lock to lock. We finally were able to get some time on November 24th. I made sure to get two sets of ALL ON times, one at the beginning and one at the end, and then also two sets of ALL OFF times, similarly one at the beginning and one at the end, to get a better idea of what changes between the two are really due to the estimator configurations.

Times:

SR3, PR3 Est ALL ON (one set before & one set after other sets)
start: 1448060052
end: 1448060452

start: 1448063252
end: 1448063616

SR3, PR3 Est ALL OFF (one set before & one set after other sets)
start: 1448060469
end: 1448060977

start: 1448063631
end: 1448063846

SR3, PR3 Est JUST L
start: 1448060995
end: 1448061621

SR3, PR3 Est JUST P
start: 1448061643
end: 1448062049

SR3, PR3 Est JUST Y
start: 1448062067
end: 1448062407

SR3, PR3 Est LP
start: 1448062846
end: 1448063239

SR3, PR3 Est PY
start: 1448062423
end: 1448062828

I used my script /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/estimator_ISC/estimator_isc_comparison.m, to plot ASDs for LSC (CTRL) and ASC (ERR) channels, as well as the LSC CAL channels and ASC diode channels when an ASC channel was made up of more than one diode (ex. INP1 uses REFL A 45I and REFL B 45I). I very quickly realized that the difference between each individual dof and LP or PY ON vs OFF is not enough of a change to be able to accurately say whether there is a difference. So we're just going to look at all estimator dofs ON vs all OFF. These result plots can be found in /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/estimator_ISC/H1/Results/ as revision r12809. On the plots, Light Green 'ON' is next to Dark Green 'OFF' in time, and Light Blue 'ON' is next to Dark Blue 'OFF' in time, so Light vs Dark Green and Light vs Dark Blue are useful for proving drops in noise when the estimator is turned on.

LSC
LSC, LSC-CAL (Length, Length Zoomed in)
- Don't show much improvement
    - Maybe MICH at 1 Hz has improved a bit with the estimators ON
    - PRCL shows slight decrease in noise between 3.5-6 Hz with the estimators ON
ASC
PITCH
REFL Diodes ASC - INP1, CHARD Pitch (would be affected by PR3):
- Don't show much improvement
- INP1 P shows slightly lower noise between 2.5-3.5 Hz
    - Similar to what was seen in INP1 P OUT in August: 86640
- Very small decrease in 1 Hz peak in CHARD
    - ASC-REFL_A_RF45_I_PIT sees a small decrease at 1 Hz while ASC-REFL_B_RF45_I_PIT does not see anything
AS Diodes ASC - MICH, SRC1, SRC2, DHARD Pitch (would be affected by SR3):
- Improvement seen in the 1 Hz resonance by 1.5-2x (except SRC1)
POP Diodes ASC - PRC1, PRC2 Pitch (would be affected by PR3):
- PRC1 P sees slight improvement seen in the 1 Hz resonance

YAW
REFL Diodes ASC - INP1, CHARD Yaw (would be affected by PR3):
- Don't show much improvement
- CHARD Y sees slight decrease betweeen 4-6 Hz with the estimators ON
AS Diodes ASC - MICH, SRC1, SRC2, DHARD Yaw (would be affected by SR3):
- Don't show much improvement
POP Diodes ASC - PRC1, PRC2 Yaw (would be affected by PR3)
- PRC2 Y sees slight decrease betweeen 4-6 Hz with the estimators ON
    - Similar to what was seen in PRC2 Y OUT in August: 86640

TITLE: 12/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.41 μm/s 
SHIFT SUMMARY:

Initial_Alignment completed quickly thismornign with no intervention.
LL @ Start_TR_CARM

NO_IR found message when at CARM_TO_TR
Manualed back to Start_TR_CARM
LL @ Start TR CARM again

Matt noticed that ETMX Ring Heater has not been on for 36 hours. 

Reconfig of DAQ 0 leg, trying to pull a machine out. See Alog by Jonathan ***pending****
DC0 Status indicators may blink red on CDS Overview. 

TR_CARM Issue update: 
There is a perception that Beckhoff maybe have a "sticky slider" issue, So Dr. Driggers has pushed all buttons asscoitated with Corner 5 Beckhoff ~ 18:15 UTC. 
Sticky Slider Idea has been ruled out @ 20:03 UTC  
Many Hours Later...apparently there was a the PLL Boost that was stopping us from getting past Start_TR_CARM That Dr. Driggers found.

error with GS0 @ 20:54 UTC was Jonathan doing DC0 reboots.

Violin Damping Guadian node restart ~ 21:25 UTC
Manually setting Violin damping settings. Lost losk when applying Damping to EYmode8
The Guardian gate way needed to be restarted to solve this issue. Thank you Jonathan!
Pshyc! Violin Guardian issue is back! Turns out its a Python2.7 -> Python 3+ issue. Thanks Dave!
 
LHO's IFO Made it to Move spots before Lockloss.

error with GS0 @ 00:29 UTC  & 01:09 UTC was Jonathan doing DC0 reboots again and finding an Error.
Jonathan is doing another "Zero leg" Restart @ 1:20 UTC Alog still pending, but here is a work permit.

It is currently 02:00 UTC and the Locking team has called it for the night after losing lock at Max Power.
Lockloss was from an ASC ring up around 275 kW of recirculating power in the arms. 


LOG:                          

J. Kissel, J. Driggers, A. Effler

Trying to figure out why SRC1 loop, which is the fast AS_A_RF72 loop that drives controls SRM is being finicky, I pulled open the H1 SUS SRM coil driver binary IO state request screen (see attached) and found that the UL low pass (LP) bit on the M3 stage stage is allegedly stuck -- it doesn't change when I go from state 1 (LP OFF, ACQ OFF), to state 3 (LP ON, ACQ OFF). The rest of the coils on the M3 stage change when receiving the same request.

I say "allegedly" because it can be either the actual switch is stuck (the BO chassis) or the readback has failed / is stuck (the BI chassis).

To be investigated...

M. Todd, J. Driggers, J. Kissel, S. Dwyer, T. Sanchez, D. Sigg

For posterity's sake, I thought it would be nice to record some of the actions and efforts the locking team was doing this morning.

Sheila noticed we were losing lock at START_TR_CARM, and so we relocked DRMI and tried again but going back to PREP_TR_CARM and making sure things were reset. Upon trying to advance to START_TR_CARM, the ALS-C_REFL_DC_BIAS_GAIN was set before losing lock again.

This raised suspicion about the IMC_COMM_CARM path, and it was thought that the changes to Bekhoff over the last few days could have caused some of these problems. To double check everything in this path is set to the values that are being "reported", Jenne went through and toggled every button and slider in the path as a "sticky slider" approach to solving this. The chassis work involved corner 4 and 5, but Jeff narrowed these issues down to corner 5 chassis -- here is a wiring diagram of the chassis: D1100683.

We called in Daniel to see what his thoughts were on these issues.