aLIGO LHO Logbook

LHO VE - Sat CP1 Fill

david.barker@ligo.org — Sat, 13 Dec 2025 10:41:11 -0800

Author: david.barker@ligo.org

Report ID: 88506

Sat Dec 13 10:01:33 2025 INFO: Fill completed in 1min 32secs

Quick fill, has been burping LN2 over past day.

Images attached to this report

H1 SQZ - Comment to HAM7 VOPO swap progress

keita.kawabe@ligo.org — Fri, 12 Dec 2025 17:38:39 -0800

Author: keita.kawabe@ligo.org

Report ID: 88505

I first tried to undo the screws for the PZT cable connector on the OPO without lifting the OPO, but managed to hit the SFI1 (the one close to the -Y door) with a steel allen key twice. The wrench is tiny but we didn't want to repeat it many times.

Initially the OPO posotion was VERY tightly constrained in all directions (like within 0.5mm range). In addition to the dog clamps installed as the position reference that restricted the motion in -X and +Y direction, there was no room to move in +X and -Y (end not much in +Z) either because the metal ferrule thing at the back of the PZT connector hit the SFI1. Lifting OPO means that the PZT cable will be badly kinked. That's why we changed the position references of the OPO from (one left, one back) to (one left, two front).

After that, I was able to push OPO in +Y direction and lift the entire thing (with the cables still attached). I thought about the second person undoing connectors while I'm holding the OPO mid-air, but Daniel came up with the idea that I will only lift the front edge of the OPO to tilt it just enough so the cable connectors and the allen key stay safely above the SFI1. I didn't have to bear the load of the OPO while undoing the connectors, it was much safer than my alternative.

H1 SQZ - Comment to HAM7 VOPO swap progress

daniel.desantis@ligo.org — Fri, 12 Dec 2025 16:46:01 -0800

Author: daniel.desantis@ligo.org

Report ID: 88504

The trick to disconnecting the OPO cables was to install one flat dog on the front-right side of the OPO base, then remove the flat dog we had placed on the rear-left side of the OPO assembly earlier this week. This allowed us to slide the OPO back a bit and angle it up slightly so that the connectors were accesible and could be removed. Keita was able to hold the OPO in this position with one hand and loosen the jacking screws with the other (we thought this would be safer than trying to hold the OPO vertically above the VIP). We have a photo of this that Kar Meng may post later.

H1 SQZ - HAM7 VOPO swap progress

karmeng.kwan@ligo.org — Fri, 12 Dec 2025 16:28:27 -0800

Author: karmeng.kwan@ligo.org

Report ID: 88503

[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.

SQZ

Images attached to this report

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Fri, 12 Dec 2025 16:22:52 -0800

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 88502

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:

Stop at 25W, touch SRM (counts on H1:LSC-POPAIR_B_RF90_I_NORM_MON good if under 12)
Manual to Lownoise Coil Drivers - Successful.
Auto until LOWNOISE_ESD_ETMX - Successful.
Manual to OMC Whitening, damp violins - Successful. Tony Damped violins.
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:

Lockloss due to SRC1 P/Y at Prep_ASC_FOR_FULL_IFO. SRM railed prior.
Lockloss due to Technical Cleaning at HAM2. HAM2 WD Tripped. Cleaning stopped after this.
Lockloss due to failed SRM adaptation (with ops acting as SRC1) at MOVE_SPOTS
Lockloss at Laser Noise Suppression upon activation of IMC_REFL Fast Gain at 25W
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:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:57	SAFETY	LASER HAZ STATUS	LVEA	N	LVEA is LASER SAFE \u0d26\u0d4d\u0d26\u0d3f (\u2022_\u2022)	10:51
15:38	FAC	Nellie and Kim	LVEA HAM7, HAM2, HAM1	N	Technical Cleaning	17:01
16:05	VAC	Jordan	LVEA	N	Purge Air Meas.	16:19
18:21	EE	Marc	CER	N	Hi-Voltage HAM7	18:29
18:53	SQZ	Kar Meng, Daniel, Keita	LVEA	N	HAM7 OPO	19:53
21:03	TCS	Matt	Optics, Vac Prep	N	CHETA work	23:18
21:51	VAC	Jordan	LVEA	N	Closing gate valves, turning on HAM1 cleanroom	23:19
22:21	ISC	Jennie	LVEA	N	Looking for camera mount	22:47
22:21	JAC	Daniel	LVEA	N	JAC cabling	00:21
22:25	SQZ	Keita, Kar Meng, Daniel D.	LVEA	N	HAM7 OPO swap	00:18
22:48	JAC	Marc	LVEA	N	JAC cabling	00:48
23:11	FIT	Masayuki	Arms	N	On a run	23:41
23:53	JAC	Jennie	Opt Lab	N	Looking for parts	00:53
00:04	JAC	Masayuki	Opt Lab	N	Joining Jennie	01:04

H1 General - The Final Day of H1 Locking for 2025

ryan.short@ligo.org — Fri, 12 Dec 2025 16:18:11 -0800

Author: ryan.short@ligo.org

Report ID: 88498

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.

ISC, OpsInfo

Images attached to this report

LHO General - HAM1 Cleanroom turned on in prep for vent

jordan.vanosky@ligo.org — Fri, 12 Dec 2025 15:19:43 -0800

Author: jordan.vanosky@ligo.org

Report ID: 88501

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

H1 CDS - GV5 and GV7 removed from alarms

david.barker@ligo.org — Fri, 12 Dec 2025 15:11:23 -0800

Author: david.barker@ligo.org

Report ID: 88500

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.

LHO VE - GV5 & GV7 Hard Closed

jordan.vanosky@ligo.org — Fri, 12 Dec 2025 15:09:09 -0800

Author: jordan.vanosky@ligo.org

Report ID: 88499

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.

Images attached to this report

H1 ISC - Turned off HV for HAM7

marc.pirello@ligo.org — Fri, 12 Dec 2025 10:36:35 -0800

Author: marc.pirello@ligo.org

Report ID: 88497

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

SQZ

LHO VE - Fri CP1 Fill

david.barker@ligo.org — Fri, 12 Dec 2025 10:30:09 -0800

Author: david.barker@ligo.org

Report ID: 88496

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

Images attached to this report

H1 SUS - Comment to ITMX Coil Driver State Binary Readback Issue

david.barker@ligo.org — Fri, 12 Dec 2025 10:07:11 -0800

Author: david.barker@ligo.org

Report ID: 88495

ITMX's BIO readback started deviating this Wed at 15:05. At this time we were restarting the DAQ for a second time to install a new h1ascimc model and add the new Beckhoff JAC channels to the EDC. If you trend H1:SUS-ITMX_BIO_M0_MON it was nominal going into the DAQ restart, and in deviation when the DAQ came back, presumably a coincidence.

By this time on Wednesday all hardware changes had been completed (asc0 upgrade, Beckhoff chassis work), hence the DAQ restart.

Trending back it looks like this happened in March/April this year just before the end of O4b (01apr2025). It started Sun30mar2025 and ended Wed02apr2025. I don't see any record of whether it was fixed on 02apr2024 or fixed itself.

H1 General - Yesterday reseting XARM

matthewrichard.todd@ligo.org — Fri, 12 Dec 2025 09:06:38 -0800

Author: matthewrichard.todd@ligo.org

Report ID: 88494

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.

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Fri, 12 Dec 2025 07:34:00 -0800

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 88493

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

H1 General - Comment to Morning Locking Attempts

ryan.short@ligo.org — Thu, 11 Dec 2025 18:35:42 -0800

Author: ryan.short@ligo.org

Report ID: 88492

Due to it giving Jenne trouble and pulling alignment away, I have commented out SRC1_Y from ENGAGE_ASC. This means the "human servo" will need to be in-use for now for SRM, especially during powerup and the spot move.

I've attached the ASC trends around where the ringup happened during the powerup. Looks like this is the known ~0.45 Hz instability and it's possible we were just unlucky.

The plan for tomorrow is to start locking just like we did this last time (fully auto with someone monitoring SRM alignment) and see how far we can get. If we're unable to fully reach low noise, there are ways we can check certain systems for functionality before we plan to close the arm gate valves mid-afternoon.

Images attached to this report

H1 DAQ - WP 12930, test an alternate configuration for ECR E2500314

jonathan.hanks@ligo.org — Thu, 11 Dec 2025 18:30:47 -0800

Author: jonathan.hanks@ligo.org

Report ID: 88490

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:

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
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.

Images attached to this report

H1 SUS - ITMX Coil Driver State Binary Readback Issue

ryan.short@ligo.org — Thu, 11 Dec 2025 18:29:28 -0800

Author: ryan.short@ligo.org

Report ID: 88491

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.

CDS

Images attached to this report

H1 SUS - SR3, PR3, LPY Estimator ON vs OFF times + LSC/ASC comparisons

oli.patane@ligo.org — Thu, 11 Dec 2025 18:25:22 -0800

Author: oli.patane@ligo.org

Report ID: 88429

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

ISC

Non-image files attached to this report

EstimatorCompare_LSC_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_LSC-Zoomed_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-REFLPit_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-ASPit_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-POPPit_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-REFLYaw_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-ASYaw_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

EstimatorCompare_ASC-POPYaw_SR3PR3-OnvOff_1448060052_1448063252_1448060469_1448063631-210.pdf

H1 General - Comment to Morning Locking Attempts

jenne.driggers@ligo.org — Thu, 11 Dec 2025 18:02:50 -0800

Author: jenne.driggers@ligo.org

Report ID: 88489

Re: Matt's alog this morning, I was worried that we had a sticky slider situation after the beckhoff work (which apparently isn't really a thing here, but was a thing at the 40m). We moved sliders and flipped switches on the IMC common mode board, the IFO REFL common mode board, and the summing node. Probably that wasn't the issue.

After a few other TR_Carm unsuccessful attempts, I trended and it turns out that the time we had been successful doing things by hand that Sheila mentions, we had forgotten to turn off the H1:ALS-C_COMM_PLL_BOOST, so we did the whole transition with the boost left on. I have now set in the guardian to leave the boost on, and we have now gotten through this several times without any intervention. I also added turning off the ALS COMM VCO by clicking the Ext button (and resetting it to Int in PrepForLocking), however it's possible that that wasn't necessary, since guardian already had changing the On/Off switch as part of these states. The real key seems to be leaving on the H1:ALS-C_COMM_PLL_BOOST.

As Sheila said, DC readout seems to just be working fine, no intervention needed. Total mystery why it hadn't been working on Tuesday.

We have now powered up to 25 W two times! Even if we're not able to get farther than this, there are very few items left that would need to be checked using the full IFO (eg, the ISS second loop can be checked using IMC-only).

SRC1 P is still out of the guardian. One time I was able to close it using the offset from lownoise ASC, at Elenna's suggestion. But, we still lost lock in MoveSpots. The other time I was by-hand watching SRM pitch. No need to move it up to 25W, and I think I picked the wrong direction during move spots, so we still lost lock.

We got up past 25W a third time. This time, rather than doing MOVE_SPOTS, I manual-ed and did RF9 and then RF45 modulation depth reduction. Both of those were fine, although the 45 MHz reduction did confuse my Jenne-in-the-loop SRM alignment loop. At some point, it became clear that SRC1 yaw was pulling us away, so we turned that off and I started dealing with SRM yaw alignment as well as SRM pit alignment. We then did move spots with both SRC1 pit and yaw open and me watching them. That seemed fine. We then started going to MAX_POWER. I think we got up to 50W, but then we got a nasty ASC ringup and lost lock.

The only analog things that we haven't tested yet are (I think) coil driver switching, ESD switching, and OMC whitening switching, and ISS Second loop engagement. Tony had checked PCals earlier in one of our locks, and they were fine.

It sounds like there will be some folks around to perhaps try locking again tomorrow. However, as Betsy pointed out, now we have a pretty small list of things that *haven't* been tested, so even if we aren't able to get to full NLN we have very few things to be suspicious of when relocking next calendar year after the vent. ISS second loop we can test using IMC-only. Anamaria and Jeff were thinking through how could we check (using, eg, the IMON channels) the sus actuator switching. I think that we could also try OMC whitening switching using a single-bounce OMC.

H1 General - Thursday Ops Shift Start

anthony.sanchez@ligo.org — Thu, 11 Dec 2025 18:01:06 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88488

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:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:57	SAFETY	LASER HAZ STATUS	LVEA	NO	LVEA is LASER SAFE \u0d26\u0d4d\u0d26\u0d3f (\u2022_\u2022)	10:51
15:57	FAC	Kim & Nellie	LVEA	Y	Technical Cleaning	16:33
17:23	JAC	Jennie W, & Co	JAC Lab	N	Working on JAC	19:23
17:39	FAC	Randy	X-arm	N	Clearing the path of tumbleweeds	19:39
17:48	Tours	Cassidy & tour	CTRL-Overpass	N	Giving a tour	18:48
17:52	LASER Saftey	Travis	LVEA, FCES, EY	n	Updating Laser status signs up around site	18:49
18:22	SQZ	Karmeng & Daniel	LVEA SQZt7	YES	Working on HAM7 upgrades	18:57
19:26	JAC/Cheta	Betsy	Optics lab	N	Dropping off parts.	19:56
19:27	CDS	Jonathan	MSR	N	Rebooting DC0 & making CDS_Overview angry	20:57
19:31	ISC	Jeff & Jennie D	LVEA	Y	Checking on status of PSL ISCT racks.	20:11
19:42	JAC	J.W.	JAC Lab	N	Jac Work	19:48
22:15	FAC	Tyler	OSB Receiving	N	Forklifting something quickly over to OSB Recieving.	22:35
22:27	LAser Trans	Sheila & Anamaria	LVEA	yes	Transitioning the LVEA to Laser Hazard.	22:57
22:53	VAC	Gerardo & Jordan	LVEA	N	Getting parts	23:13
23:46	PEM	RyanC	PCAL lab	N	Get data from dust monitor huddle test	00:01
00:10	CDS	Jonathan	MSR	N	Working on the DNS and DC0 servers	00:50

Images attached to this report

H1 SUS - Comment to Allegedly Stuck SRM M3 UL Low-pass Binary IO Switch

anamaria.effler@ligo.org — Thu, 11 Dec 2025 17:20:13 -0800

Author: anamaria.effler@ligo.org

Report ID: 88487

Seems this bit has been stuck on and off since Feb 21 (for state 1 of M3 0 is good and 1 is bad in the attached ndscope). Also attached I put the spectra of the FASTIMONs which are after the analog switches. The state 1 spectra look the same as before, and the state 3 spectra looked the same anyway, so more likely that the readback has gone bad.

I further checked that PRM/PR2/BS/ITMX/ITMY do the correct BIO switching from high noise to low noise, according to their readbacks. I have not double checked the spectra.

Images attached to this report

H1 SUS - Allegedly Stuck SRM M3 UL Low-pass Binary IO Switch

jeffrey.kissel@ligo.org — Thu, 11 Dec 2025 16:42:49 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88486

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...CDS

Images attached to this report

H1 CDS - SUS Violin mode EPICS IOC crashing on writes, fixed by moving to python2

david.barker@ligo.org — Thu, 11 Dec 2025 16:12:05 -0800

Author: david.barker@ligo.org

Report ID: 88485

RyanS, Jonathan, Dave:

The EPICS IOC cds_aux_ioc.py was crashing when Guardian started writing to its PVs this afternoon.

This IOC was discovered to not be running after the power outage, its channels were missing from EDC.

I took the opportunity to "do the right thing" and add cds_aux_ioc to cdsioc0's systemd using puppet earlier in the week. Everything looked to be working, for example EDC connected to all 160 channels.

As mentioned, as soon as guardian violin node attempted to write to a PV it crashed the IOC. Systemd then restarted the service 10 minutes later and the cycled repeated.

To further confuse us, attempting to read PVs from the guardian machine failed. If we set the CA_ADDR vars we could get a connection with cdsioc0, but these were not normally set. We then thought that an EPICS gateway must be missing, server on FELAN client on CDSLAN. Jonathan found and started the gateway and we got to the point where Guardian could read the PVs, but crashed the IOC on write.

I could not find any alog/wiki description of where cds_aux_ioc had been running, but on reflection the fact that it is python2 code hinted at an old script machine.

I tried running the code on h1fescript0 and success, it is not crashing on writes.

For now cds_aux_ioc.py is running in a TMUX session as user controls on h1fescript0

We then undid all the good work we did this week: stopped the gateway, stopped and disabled the systemd service on cdsioc0. I now need to take it out of puppet and delete it from cdsioc0.

TODO: convert script to python3, run on an updated FE script machine.

H1 General - Comment to Morning Locking Attempts

sheila.dwyer@ligo.org — Thu, 11 Dec 2025 14:01:41 -0800

Author: sheila.dwyer@ligo.org

Report ID: 88484

We eventually lock TR_CARM by going through the guardian steps slowly. We noticed that when we stepped through slowly, the ALS COMM VCO would pull the mode cleaner away causing the TR_CARM path to rail. We disabled the VCO internal servo that uses the frequency comparator to keep the VCO at a fixed frequency. This has been used in the past for our sucsesful transitions, but seemed to be railing each time this morning.

We left the ALS not shuttered, and ran the QPD servos while ASC and soft loops were engaged, with Tony acting as a SRC1 servo. After all the ASC had engaged, the camera set points still looked good, I set the QPD offsets back to their values from SDF, and the camera offsets still looked good. The guardain has been reset to shutter ALS as normal next time we relock. The POP A yaw offset was off slightly, I set it to -0.43 rather than -0.4.

We then transitioned to DC_READOUT using the guardian without any intervention, or known fixes for the problems we were having.

We are able to turn on the SRC1 yaw loop, but the SRC1 pitch loop pulls the side band build ups off. I've added the SRC1 yaw loop back into ENGAGE_ASC_FOR_FULL_IFO.

H1 DetChar - Comment to Hunting down the source of the near-30 Hz combs with magnetometers

joan-rene.merou@ligo.org — Thu, 11 Dec 2025 11:44:26 -0800

Author: joan-rene.merou@ligo.org

Report ID: 88483

[Joan-Rene, Alicia] We tried yesterday disconnecting the PSL Environmental Sensor Concentrator where some of the suspicious white cables were going, but no change was seen in the comb amplitude. Continuing our search with the magnetometer in the same rack, we found out that the comb is quite strong when the magnetometer is put besides the power supply that is close to the top of the rack: So it may be that these lines may be transmitted elsewhere through this power supply. We connected a voltage divider and connected it to the same channel we were using for the magnetometer (H1:PEM-CS_ADC_5_23_2K_OUT_DQ): Out of this power supply, two dark green cables come out, the first one goes to the H1-PSL-R1 rack: However, the comb did not appear as strong when we put the magnetometer besides the chassis where the cable leads. On the other hand, the comb does appear strong if we follow the other dark green cable, that goes to this object Which Jason told us it may be related to the interlock system. Following the white cables that go from this object, it would appear that they go into the coil, where we saw that the comb was very strong. We think it would be interesting to see what here can be turned off and see if the comb does disappear.

Images attached to this report

H1 SQZ - Comment to HAM7 Work Wednesday 12/10

karmeng.kwan@ligo.org — Thu, 11 Dec 2025 11:23:23 -0800

Author: karmeng.kwan@ligo.org

Report ID: 88482

[Daniel, Karmeng]

We also placed an iris after the parascope on SQZT7 table to constraint the green reflected off the OPO.

Images attached to this report

H1 General - Morning Locking Attempts

matthewrichard.todd@ligo.org — Thu, 11 Dec 2025 11:17:54 -0800

Author: matthewrichard.todd@ligo.org

Report ID: 88480

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.

LHO VE - Thu CP1 Fill

david.barker@ligo.org — Thu, 11 Dec 2025 10:33:04 -0800

Author: david.barker@ligo.org

Report ID: 88481

Thu Dec 11 10:16:18 2025 INFO: Fill completed in 16min 14secs

Gerardo confirmed a good fill curbside.

Images attached to this report

H1 PEM - Comment to Added DAC calibration filters for PEM EX

oli.patane@ligo.org — Thu, 11 Dec 2025 10:22:28 -0800

Author: oli.patane@ligo.org

Report ID: 88479

Late update, but I put the channel names wrong. The new channels are called H1:PEM-EX_DACOUTF_{1,2,3,4}.

H1 DAQ - TwinCAT setup

daniel.sigg@ligo.org — Thu, 11 Dec 2025 10:15:57 -0800

Author: daniel.sigg@ligo.org

Report ID: 88478

A quick summary of the current TwinCAT setup:

OS: Windows 10 IoT Enterprise 2021 LTSC (64-bit),
Version: TwinCAT 3.1: Build 4026 (using the new packet manager),
Visual Studio version: 2022,
Altium workflow: SlowControls\Drawings\Interferometer\H1Interferometer.DsnWrk (D1800185-v4),
Altium script to generate a netlist: TwinCATList,
Script to generate box and map files: SlowControls\Drawings\Interferometer\ProcessTcNetList.ps1 (automatically launched from the Altium script),
Script to setup/generatte/compile/activate project: SlowControls\Scripts3\Common\install_tc3_target_vs22,
PLC projects in SlowControls\TwinCAT3\Source\Interferometer\ under AuxCorner, AuxEnd, IscCorner, IscEnd, SqzCorner, TcsCorner, and TcsEnd,
Generated system project: SlowControls\TwinCAT3\Source\Interferometer\H1EcatC1\H1EcatC1.sln.

Any change of hardware needs to be reflected in the Altium workflow which serves as the basis for the system project using the provided scripts.

The Altium script will generate H1EcatC1_NetList.xml. ProcessTcNetList.ps1 will then use the netlist as an input to generate H1EcatC1_BoxList.xml and H1EcatC1_Mapping.xml.
(All located in C:\SlowControls\TwinCAT3\Source\Interferometer\H1EcatC1\Configure).

We have updated the spare Beckhoff computer to this version. The upgrade of the main Beckhoff computer is pending.

LHO VE - Wed CP1 Fill

david.barker@ligo.org — Thu, 11 Dec 2025 09:41:44 -0800

Author: david.barker@ligo.org

Report ID: 88477

Wed Dec 10 10:11:15 2025 INFO: Fill completed in 11min 12secs

Late entry for yesterday's CP1 fill.

Images attached to this report

H1 ISC - Thanks DIAG_MAIN! Found ASC_REFL_9_I Analog Whitening Settings didn't match the Digital Compensation; From Beckhoff Restart

jeffrey.kissel@ligo.org — Thu, 11 Dec 2025 09:16:01 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88476

J. Kissel, S. Dwyer As we resume power-outage recovery lock acquisition now that the environment is more suitable than it's been in a week (LHO:88473), we (as in DIAG_MAIN) found this morning the ASC_REFL_9_I analog whitening state (whose setting is managed by Beckhoff) didn't match the digital compensation (whose setting is managed by h1asc SDF system). We suspect that this is a symptom of yesterday's beckhoff == twincat computer reboots that were necessary to support the beckhoff chassis upgrades for JAC (LHO:88463). Not sure where/if these analog whitening settings are in the Beckhoff SDFs, but I've trended - H1:ASC-REFL_A_RF9_I1_SWSTAT digital compensation setting status - H1:ASC-REFL_A_RF9_WHITEN_SET_1 analog setting status and have now reset them to "normal," with 2 stages of whitening ON, and FM1 and FM2 compensating them.

Images attached to this report

H1 PEM - Comment to It's been ... WINDY.

jeffrey.kissel@ligo.org — Thu, 11 Dec 2025 09:06:21 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88475

Oh right -- and also on Monday, even though the wind wasn't *that* bad, the Earth was mad from the after shocks of 7.0 mag Alaskan EQ, and there were end-station Software Watchdog trips related to it that -- because of an oversight in watchdog calibration -- scared everyone into thinking we should "stand down until we we figure out if this was because the hardware upgrades or power outage." See LHO:88399 and LHO:88415. So, Monday was a wash for environmental reasons too.

Images attached to this report

H1 SQZ - SQZ SHG locking

sheila.dwyer@ligo.org — Thu, 11 Dec 2025 08:57:23 -0800

Author: sheila.dwyer@ligo.org

Report ID: 88474

Yesterday we had trouble locking the SHG after the beckhoff restart. The scan range for the PZT was restored correctly after the restart to 45-100V, but it seems to no longer be the right range to find a resonance. This morning I changed the range to 0-100V, this allowed us to lock with the PZT voltage around 50. I've now set it to 20-100V and accepted this in SDF.

Images attached to this report

H1 PEM - It's been ... WINDY.

jeffrey.kissel@ligo.org — Thu, 11 Dec 2025 08:51:36 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88473

J. Kissel Post Dec 4th power outage, we've have an EPIC week of windstorms that have inhibited recovery effort, which has delayed upgrade progress. The summary pages (on their 24 hour cadence) and the OPS logs / environment summary don't really convey this well, so here's a citable link to show how bad last Friday (12/05), Monday (12/08), and Wednesday (12/10) were in terms of wind. Given the normal work weekend, it means that we really haven't had a conducive environment to recover from even a normal lockloss, let alone a 2-hour site-wide power outage. The attached screenshot is of the MAX minute trends (NOT the MEAN, to convey how bad it was) of wind speed at each station in UTC time. The 16:00 UTC hour mark is 08:00 PST -- the rough start of the human work day, so the vertical grid is marking the work days. The arrow (and period where there's red-dashed 0 MPH no data) shows the 12/04 power outage. The horizontal bar shows the weekend when we humans were trying to recover ourselves and not the IFO.DetChar, ISC, SEI, SUS

Images attached to this report

H1 CDS - Offload of raw minute trend files from TW0 complete

david.barker@ligo.org — Thu, 11 Dec 2025 08:02:32 -0800

Author: david.barker@ligo.org

Report ID: 88472

WP12916 TWO offload

Dave:

The archive and deletion of the past 6 months of raw minute trend files from h1daqtw0 is completed. The new post-O4 DAQ configuration we are testing on the 0-leg allowed the copy to be done by TW0 itself instead of using FW0 as a proxy. This sped up the copy, taking 17.5 hours instead of the previous 21 hours.

TW0 disk usage went from 95% to 2%

H1 General - Thursday Ops Shift Start

anthony.sanchez@ligo.org — Thu, 11 Dec 2025 07:33:37 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88471

TITLE: 12/11 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: USEISM
Wind: 15mph Gusts, 9mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.47 μm/s
QUICK SUMMARY:

Initial Alignment Started.
Locking will start as soon as IA finishes.

H1 General - Windy Wednesday Ops Shift Signing Off

anthony.sanchez@ligo.org — Wed, 10 Dec 2025 18:21:06 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88470

TITLE: 12/11 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: USEISM
Wind: 52mph Gusts, 37mph 3min avg
Primary useism: 0.13 μm/s
Secondary useism: 0.61 μm/s
SHIFT SUMMARY:
We had Planned to lock today to get proof of life out of H1, but then...
The tumbleweeds were trying to get in from the Roof during the 70 MPH Wind conditions we had today. We let the tumbleweeds win and didn't try to lock but did other things.
Y arm was clear enough for TJ to get to, but X arm is impassable due to a tumble-anche along the road there.

Beckhoff Upgrades were done for Corner5.
Faroing was started but not finished.
JAC work has started and we were able to recover the IMC.

CDS was able to make some progress today as well.

Random notes I took throuout the day:

Dave did a restart everything here.
Frame writer restart happened today.
The Wind only Looks like it reached 114 MPH as indicated by the wind speed, but it only hit 70 MPH.
Corner 5 beckhoff install starting at 23:00 UTC

FW1 rerstart @ 23:05 UTC
Might need to reboot ASCSQZIFO or ASCSQZ0 computer: Completed.

PSL enclosure temps alarm sounded off at 23:22 UTC during the DAQ restarts.

440 channels added to H1EDC for beckhoff.

IMC recovery :
I ended up Clearing history on IMC WFS...
Reverted MC and IMC PZTs back to GPS time: 1449411452 (the last time we had the IMC locked.)
I then moved MC2 until the we had a good lock on MC_Trans. IMC-WFS_GAIN was taken from 0.04 to 0.4 and then back again to allow the WFS to move IMC.
We then offloaded it.

Forcast for tomorrow: https://alog.ligo-wa.caltech.edu/aLOG/uploads/88470_20251210180643_2025-12-10_18-06.png

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:57	SAFETY	LASER HAZ STATUS	LVEA	YES	LVEA is LASER HAZARD \u0d26\u0d4d\u0d26\u0d3f (\u239a_\u239a)	10:31
15:42	FAC	Kim & Nellie	LVEA	y	Technical Cleaningq	17:05
16:42	TCS	Matt	Prep lab	n	Cheta table work	18:52
16:50	SEI	Randy	MY	N	Cleaning the Quad picker	19:14
17:24	Faro	Jason	LVEA	Y	Setting up Faro Equipment	17:43
17:40	PEM	Joan-Rene, Alicia	LVEA	y	Unplugging a cable	18:57
17:40	VAC	Jordan	Lvea	y	Purge air Dew point measurement.	17:52
17:46	SQZ	Sheila, Daniel, Kar Meng, Eric	LVEA	YES	HAM7 work	20:24
18:24	SEI	Jim	EY	N	Checking the Wind fence for damage	20:24
18:25	SQZ	Oli	HAM7	y	Running parts	18:29
18:42	IAS	Jason, Ryan C	LVEA	y	Faroing	20:46
18:52	SQZ	Betsy	LVEA	y	Running parts & Info	19:12
19:21	JACK	Jennie W	JOAT	N	Working on JACK	19:25
19:33	SEI	Randy	LVEA HAM1	y	Moving pallots near HAM1	21:33
20:43	CDS	Dave	CER	N	Installing Hardward for CDS ADC upgrade	21:43
21:40	IAS	Jason, RyanC	LVEA	Y	FAROing HAM2 area	22:27
22:18	FAC	Tyler	CER	N	Checking temp alarm	22:22
23:25	SQZ	Sheila, Eric, Daniel, Karmeng	LVEA HAM7	Yes	HAM7 OPO work	01:03
23:43	VAC	Betsy	Highbay	y	Leaving parts	00:13
00:18	OPS	RyanC	PCAL lab	N	Grab DM charger	00:24
00:32	JACK	Daniel	LVEA	y	Installing Jack Chassis	02:32
00:33	PEM	Ryan C	CER & LVEA	N	Setting up Dust monitor station	00:48
00:38	PEM	TJ	EY	N	Checking flow rate for dust pumps	00:48
01:00	IAS	Jason	LVEA	y	Turing off Faro	01:09

Images attached to this report

H1 IOO - JAC model upgrades 2 - LSC model

jennifer.wright@ligo.org — Wed, 10 Dec 2025 17:29:29 -0800

Author: jennifer.wright@ligo.org

Report ID: 88469

Jennie W, Daniel S, Jeff K,

I added a JAC top_names part to the h1lsc model. This should be pretty simply as the JAC only has one RF PD for length feedback and two feedback paths, one to an onboard PZT and one to temperature of the JAC spacer, this latter part is done in Beckhoff.

The PZT output to the DAC is shown here.

The lower level contains a standard library REFL PD part but I removed the RF9 path and renamed the RF45 path to RF43 as this is the frequency we are using for the JAC control sidebands. There is also a block for reading out the low frequency signal 'REFL_A_DC' and a block for feedback filters 'L_SERVO'.

CDS, OpsInfo

Images attached to this report

H1 IOO - JAC model upgrades 1 - ASCIMC model and SQZ model

jennifer.wright@ligo.org — Wed, 10 Dec 2025 17:22:21 -0800

Author: jennifer.wright@ligo.org

Report ID: 88465

Jennie W, Daniel S, Jeff K,

Human Readable Summary:

Today I finished doing the last round of changes to ascimc.mdl which adds a path to do ASC for the new jitter attenuation cavity, JAC. As part of this, the IMC will no longer be using the PSL periscope PZT as a feedback path to control input alignment and instead this path will be used to align to the JAC. We have implemented logic in the IMC ASC model to use the IMC as normal just now. We have also put in the infrastructure in this model for the JAC ASC in a JAC top_names block. The JAC has 2 WFS, 1 RF PD as input and feeds back to the PSL periscope and JM1 tip-tilt suspension for alignment. These changes were built and added to the re-locked revision in the svn.

Details for the IMC: We have added a line to the output matrices of the IMC (old P and Y in medm) where the final fifth line is used to send signals to the new JM3 tip-tilt which will be installed in HAM1 during the vent downstream of the JAC and upstream of the IMC, these currently contain zeros in the fifth line but I haven't updated the medm screen for IMC_WFS yet. The ASCIMC model now contains send PCIe modules whoch correspond to the recieve modules in the SUS-JM3 model.

There is also a switch H1:ASC-IMCJAC_PZTOUTSW in the top level of the ASC IMC model to switch between the JAC servo using the periscope PZT as a feedback path (switch OFF) and the IMC servo using the PZT as a feedback path (switch ON). This has been saved in safe SDF snap file in the ON state which means the IMC should work as expected until we have the JAC installed.

I have uploaded a pic here and here of the changes made to the top level in H1ascimc.

Details for the JAC ASC: In the JAC top_names block we have the attached architecture. This has standard library blocks for the A and B JAC in-air WFS and the DC readouts of each these.

The controls are copied from the IMC model but with 2 degrees of freedom instead of 5. I have also skipped the dither locking controls as we don't seem to currently use this in the IMC.

Details for h1sqz model:

Four squeezer channels were added to h1ascimc model and removed from the h1sqz model are:

H1:SQZ-OPO_SERVO_EXC

H1:SQZ-SHG_SERVO_EXC

H1:SQZ-LO_SERVO_EXC

H1:SQZ-CLF_SERVO_EXC

- two are sent from the SQZ model, H1:SQZ-OPO_DITHER_DRIVE and H1:SQZ-LO_DITHER_DRIVE, they go into a SQZ block.

This block contains these filter banks, which we transferred from the h1sqz model. SHG_SERVO_EXC and CLF_SERVO_EXC have grounded inputs like they did the h1sqz model. The outputs are sent to the DAC0 channels highlighted with a green dotted line in this image of the h1ascimc model.

CDS, OpsInfo

Images attached to this report

H1 SQZ - HAM7 Work Wednesday 12/10

daniel.desantis@ligo.org — Wed, 10 Dec 2025 17:22:18 -0800

Author: daniel.desantis@ligo.org

Report ID: 88461

[Sheila, Eric, Kar Meng, Daniel]

At the time of removing soft cover, the particle count was ~2. We begun with the OPO dither locked. We also updated the ramp time on the PSAM controllers to be 100ms (they were at 1ms). It seems like the PSAMS are reading back the correct value (matches setpoint/target).

Betsy provided us with the screws for locking down the VIP, they are a #10 button head screw but they seem to fit in the slot for the locking mechanism. We have no washers for the #10 screw, which is not ideal. The #10 button head is not sufficiently wide enough and only engaged on one side of the slot. As a compromise, a 1/4" washer was tried to buffer this. Unfortunately, this was thick enough to prevent the screw from engaging on the threads, so two of the other bolts were installed without washers. One of the bolts that was installed is the correct bolt/washer. Once all the screws were in, the thumb screws were tightened and the OSEMs were checked. Pitch yaw and roll are all less than 1urad different. Vertical displacement is 100um different.

After finishing locking down: particle count was ~ 60

We were thinking about moving the second iris on the sqz path from between ZM3 and FC1 to between ZM2 and ZM3 so that we could see the retroreflection from the FC, but we abandoned this idea because Sheila thinks it wont be that helpful considering how difficult it seems it would be to move it there. As far as irises go, all the irises we need to install in the HAM7 chamber have been placed. We have irises installed on the transmission path to the homodyne and the CLF path on T7. It looks like the homodyne/transmission path is slightly misaligned relative to the irises placed before the vent (see images attached). We also still need to install one final iris on the green pump REFL path on T7 before we remove the OPO. We could not install this today because we could not get the SHG to lock.

We were having quite a bit of trouble dither locking the OPO, so the seed/clf input alignment may be a bit off. TEM01 and TEM00 have very similar dip fractions. By adjusting the locking code, Sheila was able to get the OPO locked to the TEM00 mode.

At the end of the day, we adjusted the iris between ZM3 and FC1 for better centering and placed 2 dogs around the OPO.

SQZ

Images attached to this report

H1 IOO - JAC electronics chassis

daniel.sigg@ligo.org — Wed, 10 Dec 2025 17:17:27 -0800

Author: daniel.sigg@ligo.org

Report ID: 88468

Installed two 4-chn demod chassis and the in-vacuum interface chassis. This completes the chassis installation for JAC.

H1 CDS - Comment to CDS Upgrade Summary: Wed 10th December 2025

david.barker@ligo.org — Wed, 10 Dec 2025 17:11:42 -0800

Author: david.barker@ligo.org

Report ID: 88467

I'm running a temporary HWS-ETMX dummy IOC on cdsioc0 to "green up" the EDC.

cds_status_ioc was upgraded to expect +1 ADC in the site wide ADC count.

H1 CDS - CDS Upgrade Summary: Wed 10th December 2025

david.barker@ligo.org — Wed, 10 Dec 2025 17:10:39 -0800

Author: david.barker@ligo.org

Report ID: 88466

h1asc0 upgrade

Daniel, Jennie, Jeff, Fil, Jonathan, EJ, Dave:

An additional ADC was added to h1asc0's IO Chassis, Fil installed the corresponding AA chassis.

h1iopasc0 model was upgraded to add this ADC.

h1ascimc model was upgraded by Jennie and Jeff, this required a DAQ restart

h1lsc0 upgrade

Daniel, Jeff, Jennie, Dave:

New h1lsc and h1sqz models were installed. DAQ restart was required.

Beckhoff Upgrade

Daniel, Dave:

New ini files were installed for CSAUX, CSISC and CSTCS. DAQ+EDC restart was required

TW0 raw minute trends offload

offloading of raw trends from tw0 completed at 04:30 this morning. I reconfigured nds0 and started the file deletion at 16:50.

DAQ Restart

Jonathan, Dave:

DAQ was restarted twice, first for model changes, second for further model changes and EDC change (Beckhoff).

On first restart it was found that h1ascimc had removed two DQ channels used by GDS. There were returned for the second round of model/DAQ restarts.

H1 DAQ - Slow Controls Upgrade

daniel.sigg@ligo.org — Wed, 10 Dec 2025 15:30:45 -0800

Author: daniel.sigg@ligo.org

Report ID: 88463

Marc Daniel

We upgared the EtherCAT Corner Station Chassis 5 according to D1200132-v4 and E1200077-v4. The corresponding software changes were also comitted. This now includes all necessary upgrades to support JAC and most of the ones needed for BHD.

LHO General - Comment to POWER OUTAGE At LHO At 1225pm PDT!

jeffrey.kissel@ligo.org — Wed, 10 Dec 2025 13:35:56 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88462

The power was out from 2025-12-04 or Thursday Dec 04 2025 from 20:25 UTC until 22:02 UTC (12:25 PST to 14:02 PST)CDS

X1 DTS - Comment to SPI Pathfinder, Phase noise measurements for Keysight 33600A waveform generator

joshua.freed@ligo.org — Wed, 10 Dec 2025 11:36:44 -0800

Author: joshua.freed@ligo.org

Report ID: 88457

Edit to the other comment and the main post

After a discussion with Jeff, we figured the best course of action would be to have all the generators referenced to the same generator. In order to better compare all the results. As well as, redo the plot in the previous comment to better reflect SPIs requirements as the base standard rather than the other way around.

PhaseNoiseSetUp.png Is a picture of the set up, it is similar to the previous tests except everything is referenced to the SRS. One thing I failed to mention in the previous tests and is not listed in the diagram is that the divide-by-eight goes into another Distribution Amp. before heading into the Ext. 10MHz of the function generators. Also note that the Double Mixer (DM) does not have an Ext 10MHz port. Instead it takes the 80MHz signal from the first differential amp; and a sin and cos 4096Hz signal from a CDS DAC through an AI chassis. (see 81593). Also note that the OCXO measurement took a pickoff from the first Distribution Amp instead of some sort of extra DoT.

Keyrad2.png Is the graph of phase noise measurements of the Double Mixer (DM) D2400315, a LIGO 80 MHz OCXO D080702 (Which both DM and OCXO are used in the final SPI design), and a Keysight 33600A dual source waveform generator which will be used during the SPI build. The phase noise measurements were all referenced with a SRS SG382. Note that the BluePhase 1000 set up calculates values in dBc/Hz, to convert to a more directly useful value for SPI, rad/rtHz, I used the conversion:

[rad/rtHz] = sqrt(2) * 10^([dBc/Hz]/20)

The w/o. Ref. label is a separate reference from the SRS. In SPI, there is a reference interferometer that removes noise gained along each of the arms of the main SPI Mach-Zehnder. Mathematically speaking, this subtraction has an attinuation effect on our phase noise of:

Phase Noise = D/c * f * Phase noise(w/o. Ref.)

Where D is the length mismatch in the main arm between the reference and the main interferometers (or ~30m), c is the speed of light, and f is the frequency of the phase noise. Or put another way, the plots that have the label (w/o Ref.) are the direct measurements of the phase noise while plots without that label are the theoretical effect of the noise in our system. We will experimentally test this later once SPI is installed using injections; by altering the 4096Hz CDS filter bank for the DM.

P.S. I have no idea why the OCXO noise is worse than the DM. We expected it to be better. A possibility is that since the DM measurements were taken more than a half a year ago, one of the devices was "just having a bad day" today. Investigating this, while interesting, is a lower priority than other tasks as the main goal of investigating the Keysight noise performance was achieved.

Images attached to this report

H1 ISC - Comment to Locking progress today

jenne.driggers@ligo.org — Wed, 10 Dec 2025 11:24:10 -0800

Author: jenne.driggers@ligo.org

Report ID: 88460

Looking back at the locklosses at DC readout transition, Ryan and my lockloss at ~8:30pm seemed to be successful through the matrix ramp and beyond. However, we got a bit of a ringup at ~18.5 Hz in LSC DARM.

Sheila's lockloss around 1030pm is similar, although did lose lock right at the end of the matrix transition. This lockloss had a DARM oscillation a little lower, closer to 14 Hz.

There is some data-getting issue, but once that gets solved Oli plans to try re-running the lockloss tool so we can see if there is anything else suggestive of why we might have struggled.

Images attached to this report

H1 SUS - Comment to Estimators seemingly caused 0.6 Hz oscillations again

jeffrey.kissel@ligo.org — Wed, 10 Dec 2025 11:10:11 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88458

I'm pretty confident that the estimators aren't a problem, or at least a red herring. Just clarifying the language here -- "oscillation" is an overloaded term. And remember, we're in "recovery" mode from Last Thursday's power outage -- so literally *everything* is suspect and wild guesses are are being thrown on around like flour in a bakery, and we only get brief, but separated by 10s of minutes time, unrepeatable, evidence that something's wrong. The symptom was "we're trying 6 different things at once to get the IFO going. Huh -- the ndscope time-series IFO build ups as we're locking one time looked to exponentially grow to lock-loss in one lock stretch and in another it just got noisier halfway through this lock stretch. What happened? Looks like something at 0.6 Hz." We're getting to "that point" in the lock acquisition sequence maybe once every 10 minutes. There's an entire rack's worth of analog electronics that go dark in the middle of this, as one leg of its DC power failed. (LHO:88446) The microseism is higher than usual and we're between wind storms, so we're trying different ISI blend configurations (LHO:88444) We're changing around global alignment because we thing suspensions moved again during the "big" HAM2 ISI trip at the power outage (LHO:88450) There's a IFO-wide CDS crash after a while that requires all front-ends to be rebooted; with the suspicion that our settings configuration file track system might have been bad . (LHO:88448)... Everyone in the room thinks "the problem" *could* be the thing they're an expert in, when it's likely a convolution of many things. Hence, Oli trying to turn OFF the estimators. An near that time, we switch the configuration of the sensor correct / blend filters of all the ISIs (switching the blends from WINDY to MICROSEISM -- see LHO:88444). So -- there was - only one, *maybe* two where an "oscillation" is seen, in the sense of "positive feedback" or "exponential growth of control signal." - only one "oscillation" where it's "excess noise in the frequency region around 0.6 Hz," but they check if it actually *is* 0.6 Hz again isn't rigorous. That happens to be frequency of the lowest L and P modes of the HLTSs, PR3 and SR3. BUT -- Oli shows in their plots that: - Before vs. after the power outage, when looking at times when the ISI platforms are in the same blend state PR3 and SR3 control is the same. - The comparing the control request when the ISI platforms are in microseims vs. in windy show the expected change in control authority from ISI input, as the change in shape of the ASD of PR3 and SR3 between ~0.1 and ~0.5 Hz matches the change in shape of the blends. Attached is an ndscope of all the relevant signals -- our at least the signals in question, for verbal discussion later. SEI, SUS

Images attached to this report

H1 SEI - ISI CPS Noise Spectra Check Weekly FAMIS

ryan.crouch@ligo.org — Wed, 10 Dec 2025 09:50:38 -0800

Author: ryan.crouch@ligo.org

Report ID: 88411

Closes FAMIS27617, last checked in alog88307

HAM7 looks very noisy as expected due to it being vented.

ITMX_ST1_CPSINF_V3 has some more lines at high frequency.

ETMX_ST1_CPSINF_V3 lines are larger at high frequency, the line at 30HZ on ETMY_ST1 looks larger for mulitple sensors.

Non-image files attached to this report

CPS_spectra_09:40-12_10_2025.pdf

H1 SUS - Comment to Estimators seemingly caused 0.6 Hz oscillations again

edgard.bonilla@ligo.org — Wed, 10 Dec 2025 08:51:30 -0800

Author: edgard.bonilla@ligo.org

Report ID: 88456

This is possibly true. The estimator filters are designed/measured using a particular SEI environment, so it is expected that they would underperform when we change the SEI loops/blends.

Additionally, we use the GS13 signal for the ISI-->SUS transfer function .It might be the case that the different amount of in-loop/out-of-loop ness of the GS13 might do something to the transfer functions. I don't have any math conclusions from it yet, but Brian and I will think about it.

H1 General - Wednesday Ops Shift Signing On

anthony.sanchez@ligo.org — Wed, 10 Dec 2025 07:54:01 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88455

TITLE: 12/10 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: SEISMON_ALERT
Wind: 46mph Gusts, 34mph 3min avg
Primary useism: 0.14 μm/s
Secondary useism: 0.39 μm/s
QUICK SUMMARY:
Looks like someone woke up and ran an Initial_Alignment first think this morning.
When I got it H1 was in an Initial Alignment complete state. which is fantastic, but unfortunately the Wind is Howling on site right now.
I'm going to try to lock 3 times just to see if I can catch a lucky lock. But the Wind forcast look abysmal for locking today.

Images attached to this report

H1 ISC - Comment to Locking progress today

sheila.dwyer@ligo.org — Tue, 09 Dec 2025 22:40:08 -0800

Author: sheila.dwyer@ligo.org

Report ID: 88453

Next lock attempt we lost lock on during the CARM offset reduction.
Next time I stopped in DRMI_CHECK_ASC since the sideband build ups didn't look great, I struggled to fix them by moving SRM, then lost lock to some strange glitches (see screenshot). I think the reason I was having trouble adjusting the alignment by hand may have been that SRC2 was on (SR1 off as Jenne said above). I've set the useSRC2 flag to false in DRMI ASC now.
Had ALS locklosses for a little while, and DRMI was poorly aligned, so I ran initial alignment.
After that initial alignment locked well, like Jenne + Ryan's last comment above I had to turn off the SRC1 loop in engage ASC for full IFO. I've commented these out of ENGAGE_ASC_FOR_FULL IFO for now, so we don't need to be manually turning it off to avoid locklosses. Then as the soft loops came on I adjusted SRM by hand to keep the sideband powers OK. The guardian ran through OMC locking and tune offsets without issue, so I let it try DC readout without looking into the issues that Jenne and Ryan had with the OMC, this did not work. One thing that could be an issue is that we recently moved teh DARM offset step (which also requests the OMC guardian to lock and do tune_offsets) 88346. A few weeks ago this was aparently happening after engage ASC but before the soft loops, SVN diff. I've now set the DARM_OFFSET step back to it's older place, after the first round of ASC is engaged, so that TUNE_OFFSETS should be happening at the same place in the sequence that it's been at since shortly before the OFI break.
Because of the manual stepping of the SRM, I'm asking it to run initial alignment now so that in the morning the IFO will be well aligned.
Made one last attempt. This time I tried stepping through DC_READOUT state, we lost it as soon as we ramped the matrix, although that looked to be stable in the previous attempt.

Images attached to this report

H1 SQZ - Comment to HAM7 VOPO replacement activity (iris setup)

eric.oelker@ligo.org — Tue, 09 Dec 2025 21:02:33 -0800

Author: eric.oelker@ligo.org

Report ID: 88454

We took some photos to help us determine where to place the irises and how to route the new in-vacuum cabling. Linking them here since they might be useful when planning for future vents:

https://photos.app.goo.gl/xYCUhbqwxzZVwe7c6

H1 ISC - Comment to Locking progress today

jenne.driggers@ligo.org — Tue, 09 Dec 2025 20:31:17 -0800

Author: jenne.driggers@ligo.org

Report ID: 88452

Okay, we tried *one* more time, this time doing the same skip-over-tune_offsets thing, but having remembered to do the critical first few lines in the main state. We seemed to successfully get onto DC readout, the ISC_LOCK state DC_READOUT finished, and we started to see the DARM trace on the wall come down. However, we lost lock pretty suddenly. Ryan and I are giving up for the night.

Also, during engage ASC for full IFO, as part of getting up to attempting DC readout, we turned SRC1 off by hand since it was starting to pull things away. Ryan by-hand aligned SRM to get us back to good alignment. Ryan tried turning on SRC1 pit after the SOFT loops were converged, but that immediately started pulling us away, so we turned it back off and re-touched up SRM.

H1 ISC - Comment to Locking progress today

ryan.short@ligo.org — Tue, 09 Dec 2025 20:30:31 -0800

Author: ryan.short@ligo.org

Report ID: 88451

Screenshot attached of newly SDF accepted POP A offset values.

Images attached to this report

H1 ISC - Locking progress today

jenne.driggers@ligo.org — Tue, 09 Dec 2025 20:06:10 -0800

Author: jenne.driggers@ligo.org

Report ID: 88450

[RyanS, Jenne, all the other control room people, of whom there were many]

Summary: We can get to PREP_DC_READOUT_TRANSITION (at least once), but had trouble with OMC locking.

We tried some locking earlier in the day, first starting with doing the same trick as yesterday (alog 88432) and moving ITMX while ETM and TMS were controlled by green WFS to improve the COMM beatnote. However, I only ended up moving ITMX 0.3 urad in yaw. Because this was a small change and Sheila reminded me that we can lock (when the wind is low) with comm down at -10 dBm-ish, so I decided that next lock we'd just use the camera setpoints (which we did and was successful). During this time, we had to disable SRC1 and PRC1 in DRMI ASC because they were pulling the alignment away, and we weren't really on the POP QPDs at all. Anyhow, we got to PREP_ASC_FOR_FULL_IFO twice, but the alignment never looked excellent. We tried ENGAGE_ASC_FOR_FULL_IFO once, and it was really bad and killed the lock. The other time, we think that the seismic state changing from useism to windy caused us trouble (but, in retrospect, likely was only troublesome because the alignment was so poor).

We then realized that, after the big earthquakes from this weekend, our input pointing wasn't good. RyanS then set the IMs 1, 2, and 3 such that they matched their top mass osems (not necessarily their sliders). We then moved IM3 a little bit to get back to where we had been on IM4 Trans QPD before the power outage (pit of 0.239, yaw of -0.071). We were able to quite easily run through an initial alignment with this. During this and all subsequent initial alignments, we used the pre-power outage green setpoints (including cameras). The COMM beatnote was around -9 dBm, so that's pretty good.

Some time around here we had the -18 V failure, see alog 88446 for details.

Then, we did another initial alignment.

Then, the CDS team let us know that they needed to reboot all the models, see alog 88448 for details. After all the models were back, Ryan restarted the ALS_[X,Y]ARM guardians using "guardctrl restart NODE", so they would know how to start their AWGs in case SCAN_ALIGNMENT needs to be run.

We then restored sliders to just after one of our recent inital alignments, and Ryan then reset the IMs 1-3 to their top mass osems again, and again moved IM3 to get us back to the pre-power outage spot on IM4. ....And did yet another initial alignment.

After this, we finally were able to try to lock for the first time in several hours! And things went really, really quite well. We basically didn't touch anything at all (PRC1 and SRC1 still disabled in DRMI ASC), and were able to lock to PREP_FOR_DC_READOUT! Yes, you read that right, ENGAGE_ASC_FOR_FULL_IFO did just fine on its own. The buildups went down then came back again, so we were a bit scared, but it kept hold of everything and was able to converge. The PRM's ADS alignment took a loooonng time to converge, which we've seen before after a power outage (eg, alog 86944), so after all of the ASC was on (including SOFT_LOOPS) and converged, I reset the POP_A offsets, and Ryan accepted them in safe.snap.

(Later, after some relocks, we're able to use PRC1 in DRMI ASC now that its offsets have been set. But, still SRC1 is left out since it's pulling things away).

The violin modes are quite high, but not so bad that it's impossible to get 2W locked.

We went to PREP_DC_READOUT_TRANSITION, and noticed that we were having trouble locking the OMC. We're still not sure what's going on here, and we're going to leave it for the night. We're hoping to leave it at PREP_DC_READOUT_TRANSITION, however the second time that we did ENGAGE_ASC_FOR_FULL_IFO, something pulled us away and we lost lock. We'll let it try one more time.

OMC locking troubles and symptoms:

In TUNE_OFFSETS, the first time it tried to measure the transfer function, the magnitude would be way wonky (like, 40k rather than ~1), but it wouldn't go past there because the phase was more than 30 deg from 0 or 180. It would then try again to measure the TF.
The second time, it would often get a sensible number, and the phase was fine. However, since ErrorFlag had been set to True the first time around and it never got set back to False on the next try, it would just fail again and cycle through DOWN. I added lines to set ErrorFlag to False if the phase measured okay.
We then started having troubles even getting it to lock on the carrier, although it looked like it found the carrier just fine, and had 16 mA on the DCPDs. It keeps saying "wrong mode?", even though the DCPDs were 16 mA.
One time, I found the carrier by hand and manual-ed over FIND_CARRIER. However, the TUNE_OFFSETS kept giving phases of ~145 deg (which is more than 30 deg away from 180, and thus a failure). I copied in the scale_offset value that the guardian calculated though, and then manual-ed over TUNE_OFFSETS. We lost lock when I tried to have ISC_LOCK take us to DC_READOUT, but in retrospect that's probably due to not having done the prep items in the main state of TUNE_OFFSETS that set up the OMC-READOUT path.

H1 General - Final Maintenance Tuesday Ops Update.

anthony.sanchez@ligo.org — Tue, 09 Dec 2025 18:22:36 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88449

All planned CDS Work : Status Postponed in favor of Locking.
~~DEC 8 - FAC - annual fire system checks around site~~ : Status "Completed.... For now." ~ Tyler
~~MON~~ TUES - RELOCKING IFO : " In Progress "
~~TUES AM - HAM7 Pull -Y Door~~ : STATUS Completed
FARO work at BSC2 (Jason, Ryan C) Post poned in favor for locking. : Status postponed infavor of Locking.
HAM7 - in-chamber work to swap OPO assembly : Status " In progress"
Notes:
Fire Pump 1 is on 23:01 UTC

-18V power supply SUSC1 power supply dead, Fil C. is replacing it.
Dave took down corresponding AA & AI chassis and brought them back up.

Fire pump 1 back on 23:16 UTC
Fire pump 2 on at 23:19 UTC
Fire Pump 1 is back on again 23:21 UTC

High Voltage for HAM6 was accidentally shut off , which is why the Fast shutter no longer works....Turned back on at 23:53 UTC.

16:17 All SEI ALL SUS at Corner Station taken to safe to prepair for restarting ALL CS Models.
Waiting for HAM7 OPO team to give Green Light for model restarts on HAM7.
... Oops... ZM4 & ZM5 models were accidentally restarted with H1SUSSQZOUT before we heard from OPO team.

TSC X&Y CO2 TRIP Imminent !? Verbals scrolled too fast to get a time.... Dave was restarting those models at the time.

Ends Stations and Mid stations were also restarted since the X & Y ES both tripped due to a dolphin issue. ES were not taken to Safe.
"Might as well restart them all" ~ Dave B.

SUS ETMX was shook hard enough to trip the watchdog. Probably because they were not taken to safe befroe the reboots.

H1 CDS - Restarted all models

jonathan.hanks@ligo.org — Tue, 09 Dec 2025 18:06:49 -0800

Author: jonathan.hanks@ligo.org

Report ID: 88448

Dave, Jonathan,

We restarted all the tonight starting at 16:30-17:40. This was due to unexpected model behavior where epics outputs did not match daqd data. We are working to understand the mechanism. Our supposition is that it was due to a slow /opt/rtcds on model startup. We did not need to restart any daqd processes, which points to this issue being internal to the models. Dave will fill in a few more details in a comment.

LHO VE - Comment to HAM7 is vented

gerardo.moreno@ligo.org — Tue, 09 Dec 2025 17:37:56 -0800

Author: gerardo.moreno@ligo.org

Report ID: 88447

(Randy, Travis, Jordan, Gerardo)

-Y door was removed, no major issues removing it, but the usual O-ring sticking to flat flange, they stuck around the bottom part of the door, 5-8 O'clock. Other than that no other issues. Both blanks were removed and the ports were covered with an aluminum sheet.

Note, the soft cover will rub against ZM3 if the external jig to pull the cover is not used.

H1 SQZ - HAM7 VOPO replacement activity (iris setup)

karmeng.kwan@ligo.org — Tue, 09 Dec 2025 17:26:37 -0800

Author: karmeng.kwan@ligo.org

Report ID: 88443

[Sheila, Betsy, Anamaria, Eric, Daniel, Karmeng]

First time opening HAM7.

Removed the contamination control horizontal wafer.
Tools and iris are setup next to the chamber.
Dust count in the chamber and in the clean room are good/low.
4 irises placed at: after ZM1, and CLF REFL. ZM3 and ZM4 are roughly placed, need to realign after CDS are power on. Pump reflection hard to place, and we will not place an iris there.

SQZ

H1 SUS - Estimators seemingly caused 0.6 Hz oscillations again

oli.patane@ligo.org — Tue, 09 Dec 2025 17:00:36 -0800

Author: oli.patane@ligo.org

Report ID: 88445

Jeff, Oli

Earlier, while trying to relock, we were seeing locklosses preceded by a 0.6 Hz oscillation seen in the PRG. Back in October we had a time where the estimator filters were installed incorrectly and caused a 0.6 Hz lock-stopping oscillation (87689). Even though we haven't made any changes to the estimators in over a month now, I decided to try turning them all off (PR3 L/P/Y, SR3 L/P/Y). During the next lock attempt, there were no 0.6 Hz oscillations seen. I checked the filters and settings and everything looks normal, so I'm not sure why this was happening.

I took spectra of the H1:SUS-{PR3,SR3}_M1_ADD_{L,P,Y}_TOTAL_MON_DQ channels for each suspension and each DOF during two similar times before and after the power outage. I wanted the After time to be while we were in MICROSEISM, since it maybe seems like maybe the ifo isn't liking the normal WINDY SEI_ENV right now, so I wanted both the Before and After times to be in a SEI_ENV of MICROSEISM and the same ISC_LOCK states. I chose the After time to be 2025/12/09 18:54:30 UTC, when we were in an initial alignment, and then found a Before time of 2025/11/22 23:07:21 UTC.

Here are the sprectra for PR3 and SR3 for those times. PR3 looks fine for all DOF, and SR3 P looks to be a bit elevated between 0.6 - 0.75 Hz, but it doesn't look like it should be enough of a difference to cause oscillations.

Then, while talking to Jeff, we discovered the difference in overall noise in the total damping for L and P changed depending on the seismic state we were in, so I made a comparison between MICROSEISM and CALM SEI_ENV states (PR3, SR3). USEISM time was 2025/12/09 12:45:26 UTC and CALM was 2025/12/09 08:54:08 UTC with a BW of 0.02. The only difference in the total drive is seen in L and P, where it's higher below 0.6 Hz when we are in CALM.

So during those 0.6 Hz locklosses earlier today, we were in USEISM. Is it possible that the combination of the estimators in the USEISM state create an unstable combination?

Images attached to this report

H1 SUS - H1 SUS-C1's -18V_DC Power Fails (MC2, PR2, SR2's Coil Drivers, AAs, AIs, and BI/BO Chassis)

jeffrey.kissel@ligo.org — Tue, 09 Dec 2025 15:54:54 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 88446

J. Driggers, R. Short, D. Barker, J. Kissel, R. McCarthy, M. Pirello, F. Clara WP 12925 FRS 36300 The power supply for the negative rail (-18V) of the SUS-C1 rack in the CER -- the right power supply in VDC-C1, U3-U1 failed on 2025-12-09 22:55:40 UTC. This rack houses the coil drivers, AAs, AIs, and BI/BO chassis -- all the analog electronics for SUS-MC2, SUS-PR2, SUS-SR2. We found the issue via DIAG_MAIN, which said "OSEMs in Fault" calling out MC2, PR2, and SR2. We confirmed that the IMC wasn't locking, and MC2 couldn't push the IMC through fringes. Also, the OSEM PD inputs on all stages of these suspensions were digital zero (not even ADC noise). Marc/Fil/Richard were quick on the scene and with the replacement. We brought the HAM3 and HAM4 ISI -- ISI_DAMPED_HEPI_OFFLINE -- in prep for a front-end model / IO chassis restart if necessary. Un-managed the MC2, PR2, and SR2 guardians, by bringing their MODE to AUTO. Used those gaurdians to bring those SUS to SAFE. - Richard/Marc/Fil replaced the failed -18V power supply. - While there, the +18 V supply had already been flagged in Marc's notes for replacement, so we replaced that as well (see D2300167). Replaced failed +18V power supply S1201909 with new power supply S1201944 Replaced failed -18V power supply S1201909 with new power supply S1201957. The rack was powered back up, suspensions, and seismic restored by 2025-12-09 23:31 UTC. The suspensions appear fully functional. Awesome work team!CDS, SUS

H1 SEI - Blend filters used for H1 ISI Stage 1

jim.warner@ligo.org — Tue, 09 Dec 2025 14:05:41 -0800

Author: jim.warner@ligo.org

Report ID: 88444

Because we are back into the time of year when the ground motion can change a lot, I'm posting a quick reminder of what the blend filter low passes look like for the main two blends we use for horizontal dofs on the St1 of the ISI. Attached figure shows bode plots of the BSC St1 lowpasses on the right and the HAM St1 low passes on the left. Blue lines are the ~100mhz blends we use for the microseism states, red lines are the 250mhz blends we use for the "windy" states. The blends are the main component that changes between calm/windy and useism, I think we use the same sensor correction for both states. I won't go into detail about what these plots mean, this a iykyk kind of post. Sorry.

Images attached to this report

H1 DetChar - Comment to Hunting down the source of the near-30 Hz combs with magnetometers

jason.oberling@ligo.org — Tue, 09 Dec 2025 13:51:18 -0800

Author: jason.oberling@ligo.org

Report ID: 88442

The white cables in question are mostly for the PSL enclosure environmental monitoring system, see D1201172 for a wiring diagram (page 1 is the LVEA, page 2 is the Diode Room). After talking with Alicia and Joan-Rene there are 11 total cables in question: 3 cables that route down from the roof of the PSL enclosure and 8 cables bundled together that route out of the northern-most wall penetration on the western side of the enclosure (these are the 8 pointed out in the last picture of the main alog). The 3 that route from the roof and 5 of those from the enclosure bundle are all routed to the PSL Environmental Sensor Concentrator chassis shown on page 1 of D1201172, which lives near the top of PSL-R2. This leaves 3 of the white cables that route out of the enclosure unaccounted for. I was able to trace one of them to a coiled up cable that sits beneath PSL-R2; this particular cable is not wired to anything and the end isn't even terminated, it's been cleanly cut and left exposed to air. I haven't had a chance to fully trace the other 2 unaccounted cables yet, so I'm not sure where they go. They do go up to the set of coiled cables that sits about half-way up the rack, in between PSL-R1 and PSL-R2 (shown in the next-to-last picture in the main alog), but their path from there hasn't been traced yet.

I've added a PSL tag to this alog, since evidence points to this involving the PSL.

PSL

H1 General - Maintenance Tuesday Update.

anthony.sanchez@ligo.org — Tue, 09 Dec 2025 13:10:40 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88441

TITLE: 12/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 21mph Gusts, 17mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.45 μm/s
QUICK SUMMARY:

DEC 8 - FAC - annual fire system checks around site : In Progress
~~MON~~ Tues - RELOCKING IFO : In Progress
~~TUES AM - HAM7 Pull -Y Door~~ : Completed
FARO work at BSC2 (Jason, Ryan C) : Post poned in favor of Locking?
HAM7 - in-chamber work to swap OPO assembly : In Progress.

All other work Status is currently unknown.
---------------------------------------------------------------------------------------------------

Notes:

Fire Alarm went off at 16:58 UTC
HVAC system down Temperature will climb everywhere says Tyler @ 17:15 UTC
HVAC Fans turn back on @ 17:18 UTC Tyler says Air handlers are back on line , should be just a little Blip in temp.

Tumbleweeds at EY piled up too high to access EY. Chris has since cleared this.

Fire alarm in MSR going off @ 18:07 UTC

Initial Alignment process:
Held ISC_LOCK in Idle
Forced X arm to get locked, Moved ITMX to increase the Comm beat note, then Offloaded it.
When we tried for an initial Alignment we skipped.Green arms in Initial alignment.
Pushed PRM to get locked while we were in PRC align.
Pushed BS when Mich_bright aligning.
Pushed SRM to help SRC alignment.

Locking:
Jumped straight to Green Arms Manual and aimed for Offload_DRMI_ASC.

Jenne D. by hand Offloaded a "PR2 osem Equivelent", during one of out locks that got DRMI locked but locklossed at Turn_On_BS_Stage2.
another LL at Turn_On_BS_Stage2.

We made it past Turn_On_BS_Stage2 when Jenne D. Told PRC1 & SRC1 to not run in ASC.
H1 has been losing lock at a number of places before power up.

H1 SEI - HAM7 ISI is locked

jim.warner@ligo.org — Tue, 09 Dec 2025 10:48:58 -0800

Author: jim.warner@ligo.org

Report ID: 88440

Vac finished pulling the -Y door and the 2 access ports on the +Y side, I went out and locked the ISI. A,B and C lockers were fine, the D locker couldn't be fully engaged, which I think is a known issue for this ISI. I just turned until I started feeling uncomfortable resistance, so D is partially engaged.

OpsInfo

LHO VE - Tue CP1 Fill

david.barker@ligo.org — Tue, 09 Dec 2025 10:17:01 -0800

Author: david.barker@ligo.org

Report ID: 88439

Tue Dec 09 10:13:17 2025 INFO: Fill completed in 13min 13secs

Images attached to this report

H1 ISC - Comment to Locked as far as DRMI

ryan.short@ligo.org — Tue, 09 Dec 2025 09:46:41 -0800

Author: ryan.short@ligo.org

Report ID: 88438

During this process, I also flipped the "manual_control" flag in lscparams so that ALS will not scan alignment on its own and ISC_LOCK won't automatically jump to PRMI from DRMI or MICH from PRMI.

H1 CDS - Comment to CDS Power-outage Recovery Update

david.barker@ligo.org — Tue, 09 Dec 2025 09:41:49 -0800

Author: david.barker@ligo.org

Report ID: 88437

CDS Overview.

Note there is a bug in the H1 Range LED display, a negative range is showing as 9MPc.

GDS still needs to be fully recovered.

Images attached to this report

H1 CDS - Comment to CDS Power-outage Recovery Update

david.barker@ligo.org — Tue, 09 Dec 2025 09:35:48 -0800

Author: david.barker@ligo.org

Report ID: 88436

I took the opportunity to move several IOCs from hand-running to systemd control on cdsioc0 configured by puppet. As mentioned, some needed hard-coding IFO=H1 due to cdscfg issues.

H1 CDS - CDS Power-outage Recovery Update

david.barker@ligo.org — Tue, 09 Dec 2025 09:34:09 -0800

Author: david.barker@ligo.org

Report ID: 88435

CDS is almost recovered from last Thrusday's power outage. Yesterday Patrick and I started the IOCs for:

picket_fence, ex_mains, cs_mains, ncalx, h1_observatory_mode, range LED, cds_aux, ext_alert, HWS ETMY dummy

I had to modify the picket fence code to hard-code IFO=H1, the python cdscfg module was not working on cdsioc0.

We are keeping h1hwsey offline, so I restarted the h1hwsetmy_dummy_ioc service.

The EDC disconnection list is now down to just the HWS ETMX machine (84 channels), we are waiting for access to EX to reboot.

Jonathan replaced the failed 2TB disk in cdsfs0.

Jonathan recovered the DAQ for the SUS Triple test stand in the staging building.

I swapped the power supplies for env monitors between MY and EY, EY has been stable since.

H1 General - Maintenance Tuesday Start

anthony.sanchez@ligo.org — Tue, 09 Dec 2025 07:55:41 -0800

Author: anthony.sanchez@ligo.org

Report ID: 88434

TITLE: 12/09 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: 11mph Gusts, 6mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.54 μm/s
QUICK SUMMARY:
SUS in-lock charge measurements did not run due to being unlocked.
HAM7 Door Bolts have been loosened & door is ready to come off.

Potential Tuesday Maintenance Items:
CDS - Log in and check on vacuum system computer (Patrick)
18-bit DACs in iscey should be replaced with 20-bit DACs???
Beckhoff upgrades
installing SUS front-end model infrastructure for JM1 and JM3, and renaming the h1sushtts.mdl to h1sush1.mdl
RELOCK CHECKPOINT IMC
18-bit DACs in h1oaf should be replaced with 20-bit DACs
h1sush2a/h1sush2b >> sush12 consolidation
Upgrade susb123 to LIGO DACs
Add sush6 chassis
DEC 8 - FAC - annual fire system checks around site
~~MON - RELOCKING IFO~~ Reached DRMI last night
TUES AM - HAM7 Pull -Y Door
FARO work at BSC2 (Jason, Ryan C)