aLIGO LHO Logbook

H1 ISC - Comment to PRMI locking summary

jeffrey.kissel@ligo.org — Wed, 26 Aug 2026 09:22:51 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 91687

Commenting with Primary Task as ISC and Tagging ISC just in case Elenna doesn't get the chance to change the main entry. Also tagging SEI, GRD, and SYS -- to make sure they "hear" the statement "we can have the BS ISI ST2 boost ON when locking PRMI/DRMI," -- very encouraging improvement to the beam splitter's interactions with the ISI BS during lock-acquisition as a result of a larger beam splitter and lower-stage actuation. Now the ISI BS should no longer need to have to use a special state that's different that the other BSC ISIs that we've had to use for all observing runs to-date. Let's a get a few more weeks of locking under our belt, but then *consider* simplifying the SEI guardian if the cost / benefit ratio is low.GRD, ISC, SEI, SYS

LHO General - Ops Day Shift Start

thomas.shaffer@ligo.org — Wed, 26 Aug 2026 07:36:50 -0700

Author: thomas.shaffer@ligo.org

Report ID: 91686

TITLE: 08/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 6mph Gusts, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY: At 0412UTC the SEI_ENV state was transitioned to Maintenance, but I see no alog mentioning this. Dust at EX gone up near 1000 a few times overnight, we will need to check on that.

No other alarms, we will continue locking commissioning today.

H1 AOS - PRMI locking summary

elenna.capote@ligo.org — Tue, 25 Aug 2026 18:32:14 -0700

Author: elenna.capote@ligo.org

Report ID: 91685

[Keita, Louis, Elenna, with input from others]

We locked PRMI again with the stronger BS top mass damping and no oplev damping. I also raised the damping gains of PRM, PR2, SR2 to -1. They have been set to -0.5 for a while now. I have SDFed these gains to -1 to help with locking.

I had some initial trouble locking MICH, and realized that the M3 drivealign gain was incorrectly set. Once I fixed that, it was much better. We need to check the guardian to make sure this gets set correctly.

Using a beamsplitter damping gain of -3 for most DOFs works well. We had some excess 1 Hz motion which I tracked down to having too high gain on BS T, so I've left that dof at -1 gain. SDF 1 2

PRMI locks quickly, and it appears by camera that the BS moves a lot less in this state during locking. However, the buildups were very shaky as we sat in PRMI locked for more than 30 minutes. I looked at the signals and it appears that the largest motion in POPAIR RF18 was around 0.2 and 0.3 Hz. Jim put the beamsplitter ISI in the fully isolated state, and this help reduce the motion.

The rest of the movement occurring while we sit in PRMI seems to be that the BS moves a lot at 0.45 Hz. However this signal is not visible in the top mass osems, so it would probably be better if we could engage MICH ASC.

I had some trouble engaging the BS ASC, which should drive to M2 and M1. I checked the error signals (AS RF45 B Q), and realized it didn't make sense. So I then checked the phasing by driving a MICH length line at 88 Hz. The phasing was very bad, and I fixed it by adjusting the phase by 70 degrees for all four segments. One segment moved the opposite direction of the other three segments, which Keita found was because the relative phase of Q3 compared to Q1, 2, and 4 was off by 180. By flipping the demod phase on Q3, all of th relative phases between the segments was zero. I SDFed these phases.

For good measure I rephased AS A RF45, although I would want to recheck the AS RF45 phasing when we have a DARM signal.

With the rephasing, the MICH ASC error signals looked much more reasonable. I can engage the loops, but the pitch loop runs off after a minute or two, so I might have the gain sign wrong. The guardian is still set to engage MICH ASC FALSE, so it has to be done by hand.

Conclusions from today:

- we can keep locking PRMI/DRMI with no oplev damping

- we can keep locking with high BS damping

- we can have the BS ISI ST2 boost ON when locking PRMI/DRMI

***

Right after posting this alog I tried again with MICH ASC.

I feel confident that MICH yaw works with a gain of 0.5. This is flipped sign and slightly larger than the gain setting in the guardian for this state.

I think MICH P works ok with -0.5 gain. I was testing it and all was well until the JAC unlocked itself for a separate reason. It can take MICH P a few minutes to fall over though, so I won't change the guardian setting yet.
However, if you run the MICH ASC, the buildups are much quieter in PRMI.

Images attached to this report

H1 SUS - ETMX L1 LL OSEM investigation continuation explanation

oli.patane@ligo.org — Tue, 25 Aug 2026 18:21:37 -0700

Author: oli.patane@ligo.org

Report ID: 91684

Betsy, Sheila, Camilla, Fil, Oli

The biggest conclusion from today is the concern that we might not be able to really move ETMX without creating the rubbing that seems to be the cause of our L1 LL issues.

Partway through troubleshooting today we changed the EUL2OSEM for ETMX L1 to be the tripod (coil driver switching) version. I only changed this one and not the L1 OSEM2EUL, and have purposely not SDF'd it since we don't know if this is correctly working or if we'll even be able to utilize it. We only did a quick check on whether it was working and it seemed to be super cross coupled, but we didn't look too far into it. I got this matrix from /opt/rtcds/userapps/release/isc/h1/scripts/sus/etmx_l1_out_ll.snap, which is meant to be used when needing to actuate at L1 while swapping the coil driver state for LL.

M0 L2L Transfer function
I took an ETMX M0 L2L transfer function and found that it is seeing rubbing. June 5, 2026 was the last time an M0 L2L TF was taken, and it looks perfect with no rubbing(black trace). This narrows our scope of when we believe something happened to L1 LL osem from between March 5 and August 20, 2026 to sometime between June 5 and August 20, 2026. When I first started the transfer function, LL didn't seem to really be reacting to the excitation even though the other osems on L1 were moving by at least a few hundred counts(L1 OSEMINF). Then 1.5 minutes into the measurement, the LL OSEMINF IN suddenly saw a DC change of 300 counts. At this same time, LR also dropped by ~300 counts, the upper osems saw maybe a bit of motion, and some of the osems on the M0 stage saw movement of up to a few microns as well (OSEMINF_IN, OSEMINF_OUT).
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2030_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz.xml

R0 L2L Transfer function
We took a transfer function for R0 L2L and found that it also looks like it sees the rubbing. This should rule out rubbing coming from an earthquake stop on M0.
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2125_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_noVoffset.xml

M0 and R0 height adjustments
The LF and RT (Vertical) OSEMs for both M0 and R0 are reading lower than we expect, and although they seem to have been in that configuration for a long time, we're still suspicious of them and wondered if we might be seeing touching due to them being higher than they should be (smaller OSEMINF IN value = more OSEM light occulted by flag). We tried putting Vertical offsets of +/- 200,000 counts in the M0 and/or R0 TEST banks and taking transfer functions, but all the configurations we tried still looked like there was the same amount of rubbing every time.
Some of the measurements we were seeing some 'glitching' happening on LL as well, but for the most part we still weren't seeing much other movement.

	Offset(s)	Data
M0 L2L	M0: -200,000, R0: 0	`/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2100_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml`
M0 L2L	M0: +200,000, R0: 0	`/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2115_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffsetplus200000.xml`
R0 L2L	M0: 0, R0: -200,000	`/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2135_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml`
R0 L2L	M0: +200,000, R0: -200,000	`/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2145_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_R0Voffset-200000_M0offset200000.xml`

ISC

Images attached to this report

LHO VE - HAM7 Ports Leak Check

gerardo.moreno@ligo.org — Tue, 25 Aug 2026 17:56:54 -0700

Author: gerardo.moreno@ligo.org

Report ID: 91683

(Travis S., Jordan V., Gerardo M.)
We connected the leak detector, Inficon UL5000, to the back the SS-500 aux cart, the leak detector was turned on and left to reach nominal operation.
We started leak checking the viewport on the -Y door, no response from the helium leak detector, but then the leak detector showed a signal when Travis sprayed the +Y door port, signal reached ~ 2.7X10^-09 Torr*L/Sec, but the signal was not fast, it moved slow but with a steady upward trend, we do have a couple of D1100999 viewports, O-ring type. Travis stopped and we decided to bag the individual ports to leak check, after bagging the ports they were sprayed with helium and no change was noted at the leak detector helium signal.
No leak was detected above the leak detector's background of 2.0X10^-10 Torr*L/Sec.

Attached photo is the initial background.

Images attached to this report

H1 CAL - PCAL End X End station Measurement

anthony.sanchez@ligo.org — Tue, 25 Aug 2026 16:31:15 -0700

Author: anthony.sanchez@ligo.org

Report ID: 91681

Caroline and I went to End X with PS4 and followed the instruction on the DCC doc T1500062.
The Current limit red LED was lit up again. I simply adjusted the voltage down a few thousandths of a volt and the current steadied right up at 10V again.
The beams were a little offset on the Apature of the RX Sphere when we arrived. But I did not touch up the alignment this time. I may touch up alignment again next months.
Also we wore gloves this time... that was fun I guess.

Commands ran & subsequent output:
anthony.sanchez@cdsws32: python generate_measurement_data.py --WS PS4 --date 2026-08-24
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2026-08-24 corrected to ES temperature 299.3 K :
-4.699251194624549 -0.0002694340454223 0.00075040881877916
Copying the scripts into tD directory...
Connected to h1daqnds1
martel run
reading data at start_time: 1471716950
reading data at start_time: 1471717444
reading data at start_time: 1471717888
reading data at start_time: 1471718420
reading data at start_time: 1471719060
reading data at start_time: 1471719400
reading data at start_time: 1471719630
reading data at start_time: 1471720300
reading data at start_time: 1471720660
Ratios: -0.4615405682485709 -0.46591058962067394
writing nds2 data to files
finishing writing
Background Values:
bg1 = 8.879049; Background of TX when WS is at TX
bg2 = 5.011307; Background of WS when WS is at TX
bg3 = 8.896423; Background of TX when WS is at RX
bg4 = 5.129760; Background of WS when WS is at RX
bg5 = 8.965872; Background of TX
bg6 = 0.027675; Background of RX

The uncertainty reported below are Relative Standard Deviation in percent

Intermediate Ratios
RatioWS_TX_it = -0.461541;
RatioWS_TX_ot = -0.465911;
RatioWS_TX_ir = -0.455518;
RatioWS_TX_or = -0.460890;
RatioWS_TX_it_unc = 0.070028;
RatioWS_TX_ot_unc = 0.067789;
RatioWS_TX_ir_unc = 0.072976;
RatioWS_TX_or_unc = 0.075331;
Optical Efficiency
OE_Inner_beam = 0.987476;
OE_Outer_beam = 0.989974;
Weighted_Optical_Efficiency = 0.988725;

OE_Inner_beam_unc = 0.046927;
OE_Outer_beam_unc = 0.047569;
Weighted_Optical_Efficiency_unc = 0.066821;

Martel Voltage fit:
Gradient = 1636.904156;
Intercept = 0.551415;

Power Imbalance = 0.990620;

Endstation Power sensors to WS ratios::
Ratio_WS_TX = -1.078224;
Ratio_WS_RX = -1.391522;

Ratio_WS_TX_unc = 0.041912;
Ratio_WS_RX_unc = 0.038391;

=============================================================
============= Values for Force Coefficients =================
=============================================================

Key Pcal Values :
GS = -5.135100; Gold Standard Value in (V/W)
WS = -4.699251; Working Standard Value

costheta = 0.988362; Angle of incidence
c = 299792458.000000; Speed of Light

End Station Values :
TXWS = -1.078224; Tx to WS Rel responsivity (V/V)
sigma_TXWS = 0.000452; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS = -1.391522; Rx to WS Rel responsivity (V/V)
sigma_RXWS = 0.000534; Uncertainity of Rx to WS Rel responsivity (V/V)

e = 0.988725; Optical Efficiency
sigma_e = 0.000661; Uncertainity in Optical Efficiency

Martel Voltage fit :
Martel_gradient = 1636.904156; Martel to output channel (C/V)
Martel_intercept = 0.551415; Intercept of fit of Martel to output (C/V)

Power Loss Apportion :
beta = 0.998895; Ratio between input and output (Beta)
E_T = 0.993797; TX Optical efficiency
sigma_E_T = 0.000332; Uncertainity in TX Optical efficiency
E_R = 0.994896; RX Optical Efficiency
sigma_E_R = 0.000332; Uncertainity in RX Optical efficiency

Force Coefficients :
FC_TxPD = 7.900632e-13; TxPD Force Coefficient
FC_RxPD = 6.191631e-13; RxPD Force Coefficient
sigma_FC_TxPD = 3.624112e-24; TxPD Force Coefficient
sigma_FC_RxPD = 2.753947e-24; RxPD Force Coefficient
data written to ../../measurements/LHO_EndX/tD20260825/ and can be found on the gitlab here.

CAL

Images attached to this report

Non-image files attached to this report

LHO_EndX_PD_ReportV6.pdf

Sosb-office26082516240.pdf

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Tue, 25 Aug 2026 16:30:15 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 91682

TITLE: 08/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Very Busy Maintenance Day at the End Stations and the Corner Station. The biggest update is that ALSY now reliably works with WFS Converging! As such, PRMI has been locked consistently with some instability in the BBSS. Commissioners Elenna and Louis are working on improving it in various ways.

Broken down by station

EX:

PCAL Measurement - Tony and Caroline (PCAL)

Start Time: 9:55
End Time: 12:35
Details: Needs EX Hazard, ETMX Aligned
Summary: Success!
Links: WP 13545,

ETMX BOSEM Measurements and Troubleshooting - Oli, Fil, Betsy (SUS, EE)

Start Time: 10:15
End Time: None
Details: HEALTH_CHECK state needed for EX Transfer Functions.
Summary: The TFs taken seem to indicate rubbing in the transfer functions, but OSEM trends seem to imply otherwise. We are still somewhat confused as to what is exactly going on here. This problem has grown to a larger issue that will involve many alogs - will try and update this Alog with these when they come in.
Links: Alog 91650, Alog 91678

EY:

UPS Access System Replacement - Fil (EE)

Start: 9:50
End: 11:40
Summary: Success!
Links: WP 13544

Beckhoff Chassis Swap, Repair ALSY WFS Demod RF Level Monitor - Marc (EE)

Start: 8:40, back out at 11:05 with new ideas
End: 10:40
Details: Put SUS_ETMY in SAFE and ETMY ISI in DAMPED as a precaution. Readbacks for two channels are malfunctioning for power in the local oscillator. Troubleshooting pointed to Beckhoff, but a chassis swap seems that this did not fix the problem. Marc has a hunch that he will potentially chase.
Summary: Success - faulty connector.
Links: WP 13548, Alog 91672

Corner:

Gate Valve, Leak Check and Output Tube Gauge Work (Gerardo, Jordan, Travis)

Start: 8:40, 11:30 (leak checks HAM7)
End: 10:45 (For Gate Valve and Output Tube Gauge work), 12:00 (Leak Checks HAM7)
Summary: Success
Links: WP 13549,

TCS Line Inspection and TCS Inventory Work (TJ, Christina, Camilla)

Start: 9:20
End: ~11
Details:
- TCS lines need to be inspected. TJ found glycol dripping along one of the lines that go back to the chiller from the mechanical room. He and Jim are working on removal.
- There are old parts and pieces, including an old TCS chiller in the LVEA. These need to be disposed of and inventoried.
Summary: Success
Link: Alog 91675, Alog 91674

ITMY Optical Lever Relocated for CHETA:

Start: 9:15
End: 10:15
Summary: Success
Links: WP 13534, Alog 91667

CDS:

Work stations rebooted

Link: Alog 91662

Control Room Screens:

Control room screens had various issues but these were fixed by Erik and Jonathan
- NUC 28 had a full disk preventing operator control and crashing the computer
- NUC 20 did not come back after the work station reboot and had to be turned on and manually set up
- NUC 30 had to be reset
- NUC 5 plots froze for a bit but a refresh is all it took

Vacuum Electronics Work (Patrick, Jordan, Gerardo, Travis)

Start: 8:00
End: 12:40
Details: Update the configuration and PLC code on H0vaclx to change the BSC8 PT180 gauge from a BSG 450 to a BSC552. This takes the LX Vac readback down for a period of time. DAQ Restart Required After
- It got delayed, with cooperation with the Vacuum team needed to troubleshoot PT110 (HAM6).
Links: WP 13532, Alog 91676
Summary: Success. Only 1 DAQ restart was needed, which was taken care of by Dave and CDS as part of their restart.

CDS DAQ Restart (Dave):

Start: 12:35
End: 12:45
Details: Remove the decommissioned h1daqscript0's CDS LOAD MON channels from the EDC. DAQ+EDC restart needed on a target-of-opportunity. If they can time it with Patrick’s Vacuum Electronics work, then there would only be one restart needed. However, since VAC EE took time, they couldn’t do the restart and by the time they wanted to do their own restart, Tony and Caroline were in the middle of their PCAL measurement at EX. Thus, they are planning to do the restart at around noon, when PCAL is expected to be done. Requires BBSS in SAFE
Summary: Success!
Links: WP 13542, Alog 91671

IOC Container Host Cluster Update (Jonathan):

Alog 91664, WP 13538

Commissioning/Ctrl Room Work - Started at 12:40 (approx.)

ISCT1 POP Power Measurement - Alog 91657
BBSS Damping Loop Lowpass Changes - Alog 91656
ALSY Locking with WFS - Works!
ALSX gameplan following ETMX findings of rubbing - Alogs coming soon because this rabbit hole turned into a mole network. - Alog 91678
PRMI Locking - Works but commissioners are improving it

Other:

Monthly Churn Test of Fire Pumps - Eric (FAC) - WP 13541

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:24	FAC	Kim	EX	N	Technical Cleaning	16:26
16:19	EE	Fil, Oli	EX	N	Troubleshooting	16:47
16:23	VAC	Jordan, Gerardo	LVEA	Y	Gate valve work, Output Tube Guage	18:01
16:23	TCS	TJ	LVEA	Y	Chiller disposal, Line inspection	17:23
16:25	FAC	Kim	EY	N	Technical Cleaning	17:52
16:25	EE	Marc	EY	N	Beckhoff chassis swap	17:47
16:27	FAC	Eric	Wood Shop	N	Fire pump	16:54
16:39	TCS	Jason, Camilla	LVEA	Y	IY Oplev table move to make room for CHETA	17:17
16:41	PCAL	Tony, Caroline	PCAL Lab	N	Grabbing things for EX PCAL Measurement	16:55
16:47	EE	Fil	EY	N	UPS Access System replacement	18:58
16:57	PCAL	Tony, Caroline	EX	Y	PCAL Measurement	19:45
17:11	FAC	Richard	LVEA, Y-arm	N	Walkabout + Y-arm padding accessibility check	17:59
17:18	VAC	Travis	LVEA	Y	Gate Valve and Output Tube Guage work	18:01
17:48	TCS	TJ, Christina	LVEA	Y	Planning of diisposal of old TCS equipment	19:21
17:52	FAC	Kim	LVEA	Y	Technical Cleaning	18:38
18:01	TCS	Camilla	LVEA	Y	TCS Equipment Disposal/Removal/Recycle	19:21
18:08	EE	Marc	EY	N	Continued troubleshooting of local oscillator malfunction	18:55
18:44	VAC	Gerardo, Jordan, Travis	LVEA	Y	HAM7 Leak Checks	19:03
19:45	FAC	Randy	EX	N	Garb room curtain pack-up	22:43
19:46	PCAL	Tony, Caroline	PCAL Lab	N	Pack up PCAL equipments	19:49
20:54	PCAL	Tony, Caroline	PCAL Lab	Local	PCAL Measurements	22:37
20:57	TCS	Camilla	Optics Lab	N	Tidying	21:34
22:52	EE	Marc	LVEA	Y	HAM6 Chassis Inspection	22:59
23:12	TCS	TJ	LVEA	Y	Inventory of chiller equipment SNs and then chiller line management	01:12
23:22	SUS	Sheila, Betsy	EX	Y	Troubleshooting ETMX Issues	01:22
23:25	VAC	Gerardo, Jordan	EX	Y	Parts search	01:25

H1 CDS - h1daqnds1 daqd restart related to client request volume

david.barker@ligo.org — Tue, 25 Aug 2026 16:06:35 -0700

Author: david.barker@ligo.org

Report ID: 91680

Jonathan found a correlation between the number of NDS requests around 15:15 this afternoon and the crash of nds1-daqd. Plot show number of processes and cpu usage against nds1-daqd uptime. Logs suggest a nds client rapidly asked for data, possibly on cdsws37.

Images attached to this report

H1 SEI - Comment to HAM3 CRS Noise Budget

arnaud.pele@ligo.org — Tue, 25 Aug 2026 15:54:41 -0700

Author: arnaud.pele@ligo.org

Report ID: 91679

Thanks for adding the in-loop crs functionality to the noise budget, this looks great. Note, the base infrastructure for this noise budget is described here: https://dcc.ligo.org/LIGO-G2100779.

Since the orange curve on Figure 4 is the predicted residulal motion, we don't necessarily expect the measured in-loop CRS to match it. The in-loop sensor signal might be low, but still impress some of it's own (or other blended sensors) noise into real platform motion.

This new predicted residual platform tilt noise (crs in loop) is probably a good enough proxy to be used as an input to the horizontal loop to help design new X blend filters.

H1 SUS - ETMX L1 UL Jumped ~2000 counts twice with Earthquakes

camilla.compton@ligo.org — Tue, 25 Aug 2026 15:37:19 -0700

Author: camilla.compton@ligo.org

Report ID: 91678

Besty, Oli, Ibrahim, Camilla. Follow on from 91650.

Betsy said that the OSEMINF INMON channels should not change much (over last two years has been < 300 counts) but twice in the last 2 months H1:SUS-ETMX_L1_OSEMINF_UL_INMON has jumped ~2000 counts, both at the time of large earthquakes and when the EX ISI tripped:

24th June 2026 15:15 UTC- plot
17th July 2026 14:58 UTC - plot

Strangely this is not the same quadrant that has been the non responding (91650).

Images attached to this report

H1 CDS - Comment to CDS Maintenance Summary: Tuesday 25th August 2026

david.barker@ligo.org — Tue, 25 Aug 2026 15:22:54 -0700

Author: david.barker@ligo.org

Report ID: 91677

At 15:16 NDS1 restarted itself. Jonathan is investigating.

H1 CDS - PT180 changed to BCG 552, PT140, PT191, PT192, PT193 removed

patrick.thomas@ligo.org — Tue, 25 Aug 2026 14:44:11 -0700

Author: patrick.thomas@ligo.org

Report ID: 91676

WP 13532. Dave, Gerardo, Jordan, Patrick The EtherCAT configuration and PLC code on h0vaclx have been updated to change the PT180 gauge on BSC8 from a BCG 450 to a BCG 552. In the process I found out that PT140 had been removed in the past month or so, so I also removed it from the configuration and code. I also had errors from PT193, and learned that it was potentially broken, and along with PT191 and PT192 was slated for removal. I therefore asked Jordan to disconnect these from the EtherCAT hub, and removed them from the EtherCAT configuration and PLC code as well. When I tried to take the system to OP, the second section of the CU1128 EtherCAT hub kept going into an error state. I eventually tracked it down to what I think was a mismatch between the vendor id of the hub in the TwinCAT solution and that of the actual hardware. Oddly I don't remember this being an issue in the past. I could find no indication of what the vendor id was in the solution, other than what the error was reporting, or how to change my script to make it match. I found a way around this by selecting and choosing 'change to compatible type' for each of the three parts of the hub in the generated solution, rescanning the IO tree, and when it showed mismatches in the version numbering, used the dialog box to change what was configured to what was found by the scan. This seemed to fix the problem. Dave restored the PID and other settings from SDF. The channels have been updated in the DAQ. The tripped high voltages have been turned back on. I have closed the work permit. CDS, VE

H1 TCS - TCS chiller lines inspection

thomas.shaffer@ligo.org — Tue, 25 Aug 2026 13:52:29 -0700

Author: thomas.shaffer@ligo.org

Report ID: 91675

FAMIS (no number atm)

This morning I inspected the lines starting from the chillers and then went to each table. Everything looked good: no leaks, stress on pipes, etc.

I did have a scare when I saw liquid pooling around the Leak Detection Dixie Cup (LDDC) on the mech room mezzanine. Turns out it was glycol from the HEPI lines and it just happened to land next to the LDDC after dripping down an extention cord, dripping down two pipes and finally resting next to the cup. Jim was notified, picture sent.

H1 SEI - CS HEPI Plumbing leak on Mezzanine

jim.warner@ligo.org — Tue, 25 Aug 2026 13:50:23 -0700

Author: jim.warner@ligo.org

Report ID: 91674

TJ reported this morning that he found glycol from the CS HEPI plumbing on the mechanical room mezzanine this morning. I went and looked, there is a large puddle where the the pump station manifolds are joined to the LVEA piping by some thick rubber hose clamped by pipe clamps. The supply line seems to have a very slow seep that has been dripping onto the mezzanine deck for an unknown period of time. Puddle is in the first image, the leaking connection is the lower yellow boot on the stainless pipe in the second image. I put down a bunch of pads to soak up the glycol and cinched down the hose clamp on the side of the boot that is leaking about 1/4 turn. I will come back and clean up more of the glycol and try to put some clean padding down to try to help with assessing how bad the leak is or if tightening the hose clamp fixes the leak. If this needs replaced it will be a huge mess and probably require shutting HEPI down for an extended time. If that is the case, we can probably lock all the HEPI's in the corner (like LLO does). I would prefer sealing the seep with epoxy if possible.

Images attached to this report

H1 ISC - ALSY WFS Demod Repair Complete

marc.pirello@ligo.org — Tue, 25 Aug 2026 13:50:14 -0700

Author: marc.pirello@ligo.org

Report ID: 91672

WP13548

Intiially Fil replaced the ALSY WFSA Quad Demod S1001021 with one of our new spares S2600094 due to bad readbacks. These bad readbacks were caused by corrisoin and shorting due to mouse urine, see first image. We cleaned up the malfunctioning unit and it tested good.

The spare that was installed exhibited some of the same characteristics, bad readbacks, so troubleshooting lead us to replace the Beckhoff modules. This did not solve the issue, so we went back to look at the connections, and found that the spare exhibited bad LO and RF monitor channels when a 6k resistor was placed on the bad channels, absent the Beckhoff. This lead us to believe there was an issue with the chassis, so we swapped back the original WFSA Quad Demod S1001021 and investigated the sprae S2600094. Visual inspection lead us to these poorly installed zero ohm resistors, see second image, that are positioned right before the final DB9 on the IQ Demod board. We are now investigating all of the new Quad Demods for the same issue.

Marc P, Fil C, Keita K.

Images attached to this report

H1 AOS - Comment to BBSS damping loop

elenna.capote@ligo.org — Tue, 25 Aug 2026 13:46:59 -0700

Author: elenna.capote@ligo.org

Report ID: 91673

SDF of new settings

Images attached to this report

H1 CDS - CDS Maintenance Summary: Tuesday 25th August 2026

david.barker@ligo.org — Tue, 25 Aug 2026 13:26:51 -0700

Author: david.barker@ligo.org

Report ID: 91671

WP13536 SUS BS additional fast channels

Oli, Dave:

We installed Oli's latest h1susbs which added 13 new fast DQ channels, most at 2k, some at 256Hz. h1susbs model was restarted at 12:37 and the DAQ soon after.

WP13535 Add DAQSTAT channels to DAQ

Dave:

The new DAQSTAT's non-string records were added to the DAQ as EDC channels.

WP13542 Remove h1daqscript0 epics-load-mon channels from DAQ

Dave:

A new H1EPICS_CDSMON.ini was generated sans DAQSCRIPT0 channels. DAQ restart was needed

WP13532 Upgrade VAC LX Beckhoff and IOC, update PT180, remove obsolete gauges.

Patrick, Dave:

Patrick installed the latest VAC LX code and I installed its new INI file into the DAQ.

Gauges removed: PT140, PT191, PT192, PT193.

PT180 was modified, some channels removed, some added, some stayed the same name.

Note that PT180's MOD1 and MOD2 gauges have been reversed

	Before Today	Now
MOD1	Had been BSC8 gauge, recently has been reading zero	reads ~900
MOD2	Had been reading ~740	Now is BSC8 gauge, reading 7e-08 Torr

DAQ Restart

Jonathan, Dave

We did a DAQ restart, 1-leg and EDC at 12:39, 0-leg at 12:41. Frame writers (which are not restarted with the new code) had caught up with the new run number and were writing identical full frames at 12:44.

H1 ISC - Comment to Debug of ALS Y WFS auto centering

elenna.capote@ligo.org — Tue, 25 Aug 2026 13:08:28 -0700

Author: elenna.capote@ligo.org

Report ID: 91670

Now today, with the appropriate integrators and centering loops engaged, the ALS Y arm WFS are working, and the signal have converged. Yay! I'll chalk the two main problems up to 1) beam clipping with the wires and 2) me screwing up the WFS engagement by not having integrators on.

Images attached to this report

H1 SEI - HAM3 CRS Noise Budget

shoshana.apple@ligo.org — Tue, 25 Aug 2026 13:03:56 -0700

Author: shoshana.apple@ligo.org

Report ID: 91582

Started making a new HAM3 noise budget with the CRS included

Modified pre-exisiting NB: /ligo/svncommon/SeiSVN/seismic/HAM-ISI/Common/HAM_ISI_Model/HAM_simple/ham_isi_nb_clean.m
Added new function get_blnd_filters_BP.m which is the same as get_blnd_filters.m but allows for HAMs to have BP filters

CRS out of loop measurement (1470454819) : Witnesses the table rotation. Looks how we expect it, with the CRS tilt measured more or less matching the predicted noise cure below 1Hz and matching the GS13. (Figure 2)

CRS in loop measurement (1470458418): Figure 3 shows the RY blends on HAM3 with the CRS in loop (i.e. with a bandpass filter),

Figure 4 shows the Noise Budget for the platform, with the GS13 and CRS tilt measurements, the predicted tilt, and the noise contribution from each sensor. The CRS measured tilt falls a bit below the predicted tilt, but this might be from the various sensor noise estimates (most likely CRS) being a bit higher than realitly, or the ground tilt estimate being inaccurate at low frequencies.

Figure 5 and 6 shows the CRS noise contributions to the CPS and GS13 respectfully

Figure 7 shows the CRS noise budget

These are still a little rough and I'll keep working on them. In particular, I'm slightly confused on why the CRS noise contribution is so dominate in for the GS13.

Images attached to this report

LHO General - EY Access System - UPS installed

filiberto.clara@ligo.org — Tue, 25 Aug 2026 12:49:52 -0700

Author: filiberto.clara@ligo.org

Report ID: 91669

WP 13544

A Eaton Tripp Lite UPS was installed at EY. The access switch, building cameras and phone were connected to the UPS. Unit failed on 8/06/2026, alog 91438.

H1 SEI - Comment to CRS Ellipse Fitting Changes

shoshana.apple@ligo.org — Tue, 25 Aug 2026 12:19:32 -0700

Author: shoshana.apple@ligo.org

Report ID: 91668

I've pushed the values gotten from 1600s of data from 2026-08-24 10:00:00. The ellipse fitting is shown in figure 1

The values are listed in the table below

HoQI	Variable	Channel	Initial Value	New Value	% Change
HoQI1	x₀ Offset*	H1:ISI-HAM3_CRSRY_HOQI1_QUAD1_OFFSET	0.0730847	0.07301	-0.1022
HoQI1	y₀Offset*	H1:ISI-HAM3_CRSRY_HOQI1_QUAD2_OFFSET	0.0595926	0.05879	-1.35
HoQI1	1/Axes a**	H1:ISI-HAM3_CRSRY_HOQI1_QUAD1_ROT_GAIN	1.25922	1.28566	-2.1
HoQI1	1/Axes b**	H1:ISI-HAM3_CRSRY_HOQI1_QUAD2_ROT_GAIN	1.39394	1.4266	-2.3
HoQI1	Rotation Angle	H1:ISI-HAM3_CRSRY_HOQI2_PHASE_ROT	146.645°	147.03°	0.26
HoQI2	x₀ Offset*	H1:ISI-HAM3_CRSRY_HOQI2_QUAD1_OFFSET	0.0606974	0.06256	3.1
HoQI2	y₀ Offset*	H1:ISI-HAM3_CRSRY_HOQI2_QUAD2_OFFSET	-0.00274197	-0.00589	-114
HoQI2	1/Axes a**	H1:ISI-HAM3_CRSRY_HOQI2_QUAD1_ROT_GAIN	1.5438	1.46578	-5.3
HoQI2	1/Axes b**	H1:ISI-HAM3_CRSRY_HOQI2_QUAD2_ROT_GAIN	1.61934	1.5262	-6.1
HoQI2	Rotation Angle	H1:ISI-HAM3_CRSRY_HOQI2_PHASE_ROT	162.256°	161.22°	-0.64

*Offsets have a minus sign applied to them in the code when outputting, in this table the negative is ignored, i.e. what the channel reads

**The axes are actually 1/output, this table shows 1/axes, i.e. what the channel reads

Images attached to this report

H1 AOS - POP power measurement on ISCT1

louis.dartez@ligo.org — Tue, 25 Aug 2026 11:25:48 -0700

Author: louis.dartez@ligo.org

Report ID: 91657

[Jenne, Keita, Louis] Following up on the POP path issues mentioned in 91647. Keita suggested measuring the power in the POP beam on ISCT1 to 1.) compare it against what we expect to have and 2.) to compare it with different spot positions on PR2. Today we did the initial measurement. We'll need to come back (hopefully tomorrow) to repeat after moving the PR2 spot position. We did the measurement in single bounce with ITMX with 60 W input power (which put 55.3 W at the PRM). Following Keita's suggestion, Jenne turned on POPX centering and noted a POPX NSUM value of 0.76. After each spot position change on PR2 we will remeasure the power in the POP beam just out of the periscope and note any fluctuations in the POPX NSUM (centered). Having both numbers should help us determine if we are clipping upstream or downstream of the dichroic splitter (M10). There is good reason to suspect that we are clipping on the periscope on ISCT1 (see 91647 and 91481). We grabbed one of the red Thorlabs power meters from the optics lab and placed it just upstream of the POP beam shutter. At first the power meter read about 71 uW steadily. After a few moments, the power meter readout started to fluctuate from about 69 uW to about 72 uW. We couldn't immediately tell what was causing the swinging. The AS Air camera was stable and not swinging. The REFL camera was saturated (most likely because we had the door open on ISCT1). Trending back I found that POPX NSUM and YAW started being very noisy at 1471643523. This lasted for about 30 minutes. I have not been able to find a source. I checked suspensions and QPDs from POPX back to IM4, + PR3, BS, and TMs and could not identify a culprit for the 'swinging'. There was a power glitch in the afternoon before we went out to ISCT1 but Ibrahim reported the glitch timestamp to be 1471640837, about an hour before the POPX issue. I put a screenshot showing POPX NSUM, YAW_OUT and a few other channels I checked during the same time (pop_isct1_shaking.png. There was some JAC-related ASC testing going on at around the same time but none of the trends I checked showed clear correlation to noise in POPX. === With 55.3 W at the PRM (taken from IM4 trans, which is assumed to be calibrated to Watts at the PRM), we expect the power coming out of the periscope on ISCT1 to be P_isct1 = P_PRM * T_PRM * R_ITMX * 2*T_BS * T_PR2 * R_HAM1_air_bs = 55.4 W * 3.1% * 98.5% * 0.25 * 229e-6 * 90% = 87.2 uW With 71 uW measured at at ISCT1, we are missing about 18.5 % of the expected light in the IR POP AIR path. All optics values were taken from galaxy, with the exception of the BS in HAM1 on the POP Air path. I found this optic on the HAM1 assembly (D1000313) and corresponding bill of materials.

Images attached to this report

H1 AOS - BBSS damping loop

elenna.capote@ligo.org — Tue, 25 Aug 2026 11:14:53 -0700

Author: elenna.capote@ligo.org

Report ID: 91656

Just for the purposes of commissioning in the short term, I am doing some resdesign of the BBSS damping loop lowpass. Currently, the low passes are customized to each dof, but are roughly 3 Hz low passes with a low-Q elliptical design that gives something like 30-50 dB of attenuation. The rollof is extreme enough that we can't raise the gain. I have created a similar low-Q elliptical at 10 Hz with about 40 dB of attenuation that can be used for every dof. This design should give us plenty of phase to raise the beamsplitter damping gain significantly. I propose we use this design for now while we work on alignment. We can then try disengaging all oplev damping. Oli is working on determining the QOSEM performance, so once we understand it better, we can determine what kind of damping loop we need to meet noise requirements. To be clear, it's not my intention for us to use this design while in observing, just so that we can keep the beamsplitter still while we work on getting DRMI back. Here is a comparison of the current and new low pass

I have confirmed that a larger top mass damping gain is likely to help us lock without the oplev. This is a screenshot of a timeseries during a PRMI locking attempt showing both the BBSS top mass damping error signals and the oplev signals when the oplev damping was off. Both sets of error signals see the motion related to the PRMI locking kicks. I also plotted a spectrum of each signal compared to a quiet time just 5 minutes before (live traces are during locking, refs are quiet time). Both the oplev and osems signals can see the motion well above the noise during this locking time.

I have not yet tried turning up the gain in the damping loops- BS is currently in safe for tuesday work. Will try later today.

***

Edits to add:

Louis and I engaged the new low pass with a gain of -3 instead of -1. We tried step testing with offsets on the top mass, and could see that indeed the ring down from these steps was about a factor of three shorter. We then tried a test offset in length on M3 since that replicates the kick that occurs during PRMI or DRMI locking. The oplev shows that with the higher gain damping, the motion from that kick damps down to the ambient level in about half the time (these are very rough numbers).

Images attached to this report

H1 AOS - ITMy Optical Lever Laser Relocated (WP 13534)

jason.oberling@ligo.org — Tue, 25 Aug 2026 10:28:17 -0700

Author: jason.oberling@ligo.org

Report ID: 91667

C. Compton, J. Oberling

This morning we relocated the ITMy OpLev laser to make room for the ITMy CHETA table, which is going to live in the old laser location to the -Y side of the ITMy OpLev receiver pylon. We moved the laser to the +X side of the beamtube, see attached pictures. Before the move the OpLev SUM counts were ~9500 and after the move they are ~9300, a drop of ~2.1% (so not at all concerning, IMO); pitch and yaw alignment were unchanged. Since we had to open up the cooler to disconnect the fiber for the move the laser will need some time to return to thermal equillibrium; I'll monitor it over the next several hours (SUM counts may return to the pre-move value during this time period). This completes LHO WP 13534.

AOS

Images attached to this report

H1 ISC - Comment to ETMX ALS issues maybe caused by issues with ETMX L1 LL Output

ibrahim.abouelfettouh@ligo.org — Tue, 25 Aug 2026 09:38:05 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 91665

Plots of ETMX BOSEMs at UIM, Top Mass and Opleves show that there is no sign or major change of BOSEM degradation in LL. It has remained at comparable counts for the last two years.

Images attached to this report

H1 CDS - WP 13538 updated the IOC container host cluster

jonathan.hanks@ligo.org — Tue, 25 Aug 2026 08:43:47 -0700

Author: jonathan.hanks@ligo.org

Report ID: 91664

Per WP 13538 we updated and restarte the IOC container cluster. This is getting more visibility as we have moved more of our soft IOCs to the cluster and the brief outages may be noticed when we update and reboot. So for the next few cycles at least this will be done under work permit. Part of the goal of this infrastructure work is to be possible to update these hosts (and to be more discoverable, and resilent).

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Tue, 25 Aug 2026 07:41:45 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 91663

TITLE: 08/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 0mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY:

IFO is in MANUAL_INITIAL_ALIGNMENT for PLANNED MAINTENANCE

First, Tuesday Maintenance with an array of CDS and other activities.

Then, Continuing comissioning for alignment, particularly on WFS/ALS and POP path issues.

H1 CDS - workstations updated

erik.vonreis@ligo.org — Tue, 25 Aug 2026 06:59:15 -0700

Author: erik.vonreis@ligo.org

Report ID: 91662

Workstations were updated and rebooted. This was an OS packages update. Conda packages were not updated.

H1 ISC - Comment to ETMX ALS issues maybe caused by issues with ETMX L1 LL Output

oli.patane@ligo.org — Mon, 24 Aug 2026 18:10:33 -0700

Author: oli.patane@ligo.org

Report ID: 91655

Fil, Oli

We did a few tests at EX to try and figure out what was wrong with the ETMX L1 LL osem. We couldn't find anything wrong, but were able to rule out basically(?) everything outside of chamber. Tomorrow Fil will be checking the resistances of the L1 osems.

The LL channel generally seems to be moving a lot less than it should be(ndscope6). It also sometimes doesn't really line up with the normal breathing frequency of the other L1 osems (I had seen it happening earlier but wasn't able to find an example), but other times it does seem to breathe at the same frequency, albiet still moving a much smaller amount.

COILOUTF OFFSET tests
If you turn on smaller offsets (5,000 counts) in L1 COILOUTF, the UL, UR, and LR OSEMINF OUT values would react to each other's offsets, but LL would not react to their offsets and they would not react to an LL offset(ndscope1). If you put a larger (~50,000 counts) offset into COILOUTF osems, we found that sometimes LL would only react a tiny bit (hundredths of a micron) to the other osems' offsets, and it would either react a tiny bit to its own offsets, or it would move about 8 um. One of the times that we put a large offset into LL, it barely moved for over 3.5s before suddenly moving the entire 8 um in 1 second(alltraces,zoomedin). It was very strange (almost like it was stuck???????).

Coil driver to satamp voltage
At the ETMX L1 coil driver (SUS-C1 U29), Fil put a breakout board in the Coil Out to Sat path. Connecting to each channel, we turned on an offset in the COILOUTF filter bank for that channel and monitored the voltage going out to the satamp. Everything made sense - when there was an offset in the measured sensor, we saw a voltage. When there was no offset in that sensor, the coil driver wasn't sending any voltage out. The voltages measured all matched. We did this test with offsets of 5,000 and then of 50,000, and we correctly saw a difference in a factor of 10 in the voltage.

UL	OFFSET in COILOUTF [cts]	Voltage [mV]
	5,000	-10.5
	50,000	-105
LL	OFFSET in COILOUTF [cts]	Voltage [mV]
	5,000	+10.4
	50,000	+102
UR	OFFSET in COILOUTF [cts]	Voltage [mV]
	5,000	-10.7
	50,000	-108
LR	OFFSET in COILOUTF [cts]	Voltage [mV]
	5,000	+10.5
	50,000	+105

Aux channel check with Coil driver to satamp chain
We also tried turning on all the L1 COILOUTF offsets at once (all offsets of 50,000) without the plug plugged into the other side of the breakout board. All channels react the same with their VOLTMONs reading in the 1000s and we were reading ~9 V on the mulitmeter, then once the cable is plugged back in, we see the FAST IMONs and RMS IMONs jump to their normal values, and the voltage on the multimeter dropped to the values in the table as the current was able to flow (ndscope4).

Swapping PD to AA inputs
We also tried swapping the PD to AA cables on the L1 coil driver (SUS_ETM_022) with the PD to AA cable on the R0 F1F2F3 coil driver (SUS_ETMX_014), and saw no difference in the LL signal.

Swapping satamps
We also tried swapping the ETMX L1 satamp with the ETMX M0/R0 LF/RT satamp. LL still reacted the same way as it had been reacting earlier. This rules out the satamp.

Fake osem signal
Fil had the idea of sending fake osem signals into the satamp to more confidently rule out the satamp/AA/ADC path. We sent a signal into each channel and LL saw the signal exactly the same as the other osems, so that rules out that path as the issue(ndscope5).

SUS

Images attached to this report

H1 ISC - Debug of ALS Y WFS auto centering

elenna.capote@ligo.org — Mon, 24 Aug 2026 17:28:22 -0700

Author: elenna.capote@ligo.org

Report ID: 91661

Keita, Elenna, Jenne

The ALS Y WFS were not working when engaged. I checked the WFS autocentering and we saw that the power on WFS B was very low, indicating clipping. The auto centering servo could not run because the threshhold was too low to engage, but even with sweeping the PZT steering mirror, we could not increase the WFS B sum great than 150 ct. Trending showed that both WFS A and B were close to 3000 ct in March when we last locked ALS on both arms.

We could make large moves in TMSY and ETMY to bring the power up on both WFS, but the autocentering would rail. Keita stated this indicated something was very wrong, and we could be clipped somewhere on the way to WFS B.

Keita and I drove down to EY, and opened the table. We confirmed that WFS A is labeled correctly by covering it with a card. We could see a strange clipping pattern in front of WFS B. We looked along the path and saw that a bundle of cables related to the HWS and the old analog camera placed there were hanging partly in the beam. Once we moved the cables out of the way, the power on WFS B return to 2800 ct, which is nominal. Now the autocentering of WFS B works.

We removed the analog camera from the table, and coiled the remaining cables on top of the cable rack above the table. We also unplugged the power cable for the camera.

Ok, we were confused about why WFS A was not working, but it turns out I accidentally turned off the integrators when we were troubleshooting the WFS earlier today (sorry).

If we request WFS on in the guardian, the WFS engagement causes a lockloss. However if we go to a No WFS slow controls state, and then engage the WFS by hand it does not cause a lockloss. However, the WFS loops are not yet converging.

Image 1 shows the beam clipping on the cables on the table.

Image 2 shows the beams unclipped.

Image 3 shows our cable solution.

***

Edit the following morning to add: given my gaffe regarding the integrators in the auto centering loops, I took a moment to look at the guardian code. When we run 'LOCKED_SLOW_WFS_ETM_TMS' the integrators are engaged by the guardian, but when I was turning on the WFS by hand, I had forgotten to turn on the top mass integrators on ETMY and TMSY. This explains why we engaged the WFS but the loops didn't converge. However, that still doesn't solve the problem, because the reason why I turned the loops on by hand was because running the 'LOCKED_SLOW_WFS_ETM_TMS' was causing a lockloss.

Images attached to this report

H1 ISC - Comment to ETMX ALS issues maybe caused by issues with ETMX L1 LL Output

camilla.compton@ligo.org — Mon, 24 Aug 2026 16:59:55 -0700

Author: camilla.compton@ligo.org

Report ID: 91660

Attaching green locking this morning, when we locked green in March, and in O4, the L1 LL behavoiur is different now than before.

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Mon, 24 Aug 2026 16:31:50 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 91659

TITLE: 08/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

IFO is in MANUAL_INITIAL_ALIGNMENT at 2W

Lot's of alignment work today, mostly on getting ALS working:

ALSY locking has some issues with WFs that are being troubleshot. Elenna and Keita are hazard at EY now confirming alignment is okay at ISCTY. This can lock but WFs turn it unstable.
ALSX locking issues from last week also have issues with the WFs. Oli and Fil went down to EX and found that the UIM ETMX is anomolously unresponsive compared to the others. It doesn't show the normal breathing and doesn't respond to actuation. This became one of the main investigations of the day which included Oli, Fil, Betsy, Camilla and Jenne. Trending shows that the OSEM and Oplev counts have not changed. More info in alog 91650 and alog 91655. This can lock but again, WFS turn it unstable.
ISCT1 alignment confirmation using 60W was done and seemed successful.
We had another power glitch where OPS (Ryan S and Oli) had to go to the end stations to power cycle HEPI while Jim was watching. This is happening more often and Richard has said he's thinking about a long term failsafe.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
16:32	VAC	Travis	LVEA	Y	HAM7 Check	16:47
16:33	FAC	Tyler + Guest	LVEA	Y Tour		16:47
16:51	FAC	Kim	MY	N	Technical cleaning	17:51
18:03	EE	Fil, Oli	EX	N	ETMX L1 Electronics	20:03
18:07	TCS	Camilla	CHETA Lab	N	Photos	18:13
20:38	ISC	Jenne, Louis, Keita	LVEA	Y	ISCT1 alignment (Jenne out and Keita in at 21:35 UTC)	22:15
20:38	AOS	Mitchell	LVEA	-	Dog clamps	21:39
21:09	OPS	Ryan S	EY	N	Reset WD	21:48
21:10	EE	Oli, Fil	EX	N	ETMX L1 Electronics and cycle WD	21:54
21:10	SUS	Betsy, Jim	CER	Y	Look at racks	21:38
22:30	TCS	Camilla, Jackie	Cheta Lab	N	Photos	22:59
22:59	ISC	Keita, Elenna	EY	Y	Checking beams on ISCTEY	00:59

H1 SEI - Comment to CRS Ellipse Fitting Changes

shoshana.apple@ligo.org — Mon, 24 Aug 2026 15:57:27 -0700

Author: shoshana.apple@ligo.org

Report ID: 91658

I ended up also looking at the most recent time the CRS was rung up (2026-08-19 05:00:00) for a 10 second window. I got a similar result (below) to for longer periods when the CRS is damped down, which implies that the difference in the HoQI2 Offset isn't due to either of those factors, and is infact either because it has drifted, or because the original offset wasn't great.

10s from 2026-08-19 05:00:00
HOQI 1:
OFFSET X0=-0.0730847 --> -0.07069 [-3.2% Change]
OFFSET Y0=-0.0595926 --> -0.05883 [-1.3%]
Axes a: 0.794142406 --> 0.76297 [-3.9%]
Axes b: 0.71738585 --> 0.68999 [-3.8%]
Rotation Ang: 146.645-->146.82° [0.12%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.05580 [8.1%]
OFFSET Y0=0.00274197 --> 0.00563 [105%] ????
Axes a: 0.6477522995 --> 0.61450 [-5.1%]
Axes b: 0.61753553917 -->0.58815 [-4.8%]
Rotation Ang: 162.256-->161.40°° [0.53%]

H1 SEI - CRS Ellipse Fitting Changes

shoshana.apple@ligo.org — Mon, 24 Aug 2026 14:57:14 -0700

Author: shoshana.apple@ligo.org

Report ID: 91652

I re-wrote the ellipse fitting code for the CRS (previously /opt/rtcds/userapps/release/isi/h1/scripts/write_ellipse_values3.py ---> /opt/rtcds/userapps/release/isi/h1/scripts/write_ellipse_values4.py)

While the script works well while the CRS is rung up (i.e. moving a lot), I was running into an error where the previous duration was set much too low (2 seconds), and the CRS wasn't moving enough to get enough data to construct a full ellipse, which would either result in an error or an incorrect fit.

I've made a new version (write_ellipse_values4.py) for when the CRS isn't rung up where you can pick the duration and it can look at data from a earlier time (i.e. ask to use 20 minutes of data starting 20 minutes ago).

I ran the ellipse fitting code for multiple times over multiple periods from over the weekend, while each time gave a slightly different result (listed below), most gave a change of <10% of values vs the current values, with the exception of the HoQI2 y0 Offset, which had a >10% change for all runs and had a max of an 146% change. This either indicates that the HoQI2 signal is drifting significantly, or the original HoQI2 offset used wasn't great.

1600s from 2026-08-24 10:00:00
HOQI 1:
OFFSET X0=-0.0730847 --> -0.07301 [-0.1022% Change]
OFFSET Y0=-0.0595926 --> -0.05879 [-1.35%]
Axes a: 0.794142406 --> 0.77781 [-2.1%]
Axes b: 0.71738585 --> 0.70098 [-2.3%]
Rotation Ang: 146.645-->147.03° [0.26%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06256 [3.1%]
OFFSET Y0=0.00274197 --> 0.00589 [114%] ????
Axes a: 0.6477522995 --> 0.68223 [5.3%]
Axes b: 0.61753553917 -->0.65521 [6.1%]
Rotation Ang: 162.256-->161.22° [0.64%]
---------------------------------------------------
2026-08-23 10:00:00 3600s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07455 [2% Change]
OFFSET Y0=-0.0595926 --> -0.06007 [0.8%]
Axes a: 0.794142406 --> 0.78580 [-10.5%]
Axes b: 0.71738585 --> 0.71265 [-0.7%]
Rotation Ang: 146.645-->146.74° [0.06%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06395 [5.4%]
OFFSET Y0=0.00274197 --> 0.00676 [146%] ????
Axes a: 0.6477522995 --> 0.69167 [6.7%]
Axes b: 0.61753553917 --> 0.66174 [7.1%]
Rotation Ang: 162.256-->160.98° [0.79%]
----------------------------------------------------
2026-08-23 11:00:00 1600s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07124 [2.5% Change]
OFFSET Y0=-0.0595926 --> -0.05432 [8.8%]
Axes a: 0.794142406 --> 0.75956 [-4.4%]
Axes b: 0.71738585 --> 0.68506 [-4.5%]
Rotation Ang: 146.645-->146.27° [0.26%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06083 [0.22%]
OFFSET Y0=0.00274197 --> 0.00469 [71%] ????
Axes a: 0.6477522995 --> 0.67375 [4.0%]
Axes b: 0.61753553917 --> 0.64620 [4.4%]
Rotation Ang: 162.256-->160.73° [0.94%]
-----------------------------------------------------
2026-08-23 11:00:00 1000s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07251 [0.79% Change]
OFFSET Y0=-0.0595926 --> -0.05377 [9.8%]
Axes a: 0.794142406 --> 0.76077 [-4.2%]
Axes b: 0.71738585 --> 0.68627 [-4.3%]
Rotation Ang: 146.645-->145.57° [0.7%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06151 [1.3%]
OFFSET Y0=0.00274197 --> 0.00520 [89.6%] ????
Axes a: 0.6477522995 --> 0.67432 [4.1%]

Rotation Ang: 162.256-->161.59° [-0.41%]

Images attached to this report

H1 TCS - TCS Chiller Water Level Top-Off and sock filter replacement

thomas.shaffer@ligo.org — Mon, 24 Aug 2026 14:02:04 -0700

Author: thomas.shaffer@ligo.org

Report ID: 91654

FAMIS81869

With our FAMIS tasks up and running again I was reminded to swap out the chiller sock filters. The old filters both were slightly discolored, but there were no large bits of debris or other worrying particulate. I also replaced the X chiller radiator screen cover as it had a few dead bugs in it and hair.

I did not add any water as it was at a good levels for both chillers. I've updated T2200289.

H1 PSL - PSL 10-Day Trends

ryan.short@ligo.org — Mon, 24 Aug 2026 13:49:28 -0700

Author: ryan.short@ligo.org

Report ID: 91653

FAMIS 63913

Jason's brief entrance into the enclosure last Tuesday is clearly seen on several trends, but no major events of note this week otherwise.

Images attached to this report

H1 SEI - Comment to Continue CRS commissioning and testing with different ISI configs

brian.lantz@ligo.org — Mon, 24 Aug 2026 12:21:47 -0700

Author: brian.lantz@ligo.org

Report ID: 91651

"3 again. ... We should test the new l2l."

No, we should abandon the Local 2 Local measurements. It is useful to see if sensors are alive and working, but not useful for precision calibration. The CPS and GS-13 are in different places, so they respond differently to RX and RY motion. When we drive 1 actuator, we impose lots of RX and RY motion. Trying to make the local GS-13 and local CPS match each other is a mistake, because it would be extrememly surprising if they were seeing the same signal. When the payload changes, the (RX or RY)/Z motion changes is a frequency dependent way, so the L2L measurements are likely to change.

The comb drive tries to fix this. The excitation is a mostly vertical signal, and then the code does a virtual repositioning of the CPSs to the GS-13 location. Seeing that the blue curves match so well is reassuring.

H1 ISC - ETMX ALS issues maybe caused by issues with ETMX L1 LL Output

camilla.compton@ligo.org — Mon, 24 Aug 2026 11:38:19 -0700

Author: camilla.compton@ligo.org

Report ID: 91650

Oli, Fil, Camilla, Jenne,

We followed on from Keita's Friday issue with ALS WFS 1.6Hz wobble 91647, found it was WFS DOF 1 PIT, increasing or decreasing gain, this did not help. This pushes on ETMX (as does tidal) so Oli in turn turned on offsets in ETMX TEST banks while we watched all the inputs. All M0 was fine. In L1, while pushing on LL nothing moved. See attached. Fil found it strange that the H1:SUS-ETMX_L1_VOLTMON_LL_OUT16 did behave as expected though.

The L1 LL readback didn't react when UL was moved. It did move 6urad when we turned the YAW slider off (our initial test) but the shape of the trend is different than the others, and it didn't move after that, attached.

Fil and Oli went to EX to investigate.

SUS

Images attached to this report

H1 SEI - Comment to Continue CRS commissioning and testing with different ISI configs

huyen.pham@ligo.org — Mon, 24 Aug 2026 09:10:52 -0700

Author: huyen.pham@ligo.org

Report ID: 91607

3 again. The symmetrization filters: The new comb drive filters are suprisingly very similar to the old comb drive ones, while the l2l drive filters old vs new filters are distinctly diferrent - see figure 1. We should test the new l2l.

4. Remeasure CRS resonance (tilt to tilt TF): I used the same ry_exc2.txt awggui template but to get the same drive amplitude, I have to up the gain to 7e3 instead of 2e3 as last time this was measured (alog 91179). After fitting, the result shows that the resonance moved very slightly, see figure 2. The delta (distance between CoM and Center of Rotation) moved from 11µm to 10µm, and the natural frequency moved from 22.22mHz to 22.11mHz. I updated new sensor inversion anyway in both theta filter bank and the 30mHz bandpass of the blend, see figure 3. I also did two excitations with low gain that might be good for SPI commissioning. The excitation time shows below (no CRS damping nor CRS in-loop for these).

Date	Time start	Duration	Gain	Note
08/17/2026 PDT	20:57	30min	8e3 - 1e4	ISI isolated. SPI QPDA pit and yaw under 0.3
08/18/2026 PDT	08:20	1hr	2e3	ISI damped. SPI QPDA pit and yaw under 0.3
08/18/2026 PDT	20:35	1.5hrs	8e3	ISI damped

5. Horizontal to tilt coupling above 1Hz: An excitation in X direction was done via ISO_X path, see figure 4, and the dtt is saved in /ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM3/CRS/Templates/dtt/HAM3_CRS_X_to_RY_coupling_1-100Hz_20260818.xml. The coupling starts to subside as above 1.5Hz. This length drive also excited the torsional mode of the CRS around 8.7Hz.

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Mon, 24 Aug 2026 07:46:37 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 91649

TITLE: 08/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: EARTHQUAKE
Wind: 5mph Gusts, 3mph 3min avg
Primary useism: 0.14 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY:

IFO is IDLE

Continuing alignment work today.

H1 CDS - h1iopoaf0 timing error, 2nd ADC, Sun 19:04 23aug2026 PDT

david.barker@ligo.org — Mon, 24 Aug 2026 07:41:57 -0700

Author: david.barker@ligo.org

Report ID: 91648

EJ, Dave:

We got another "2nd ADC timing error" event last night on h1iopoaf0. The previous one was Wed 11aug2026 on h1iopiscex (alog 91508). Unlike the h1iscex one, h1iopoaf0's cpu did not spike, but it is running high anyway. No dmesg log was generated.

It is looking more likely this is software and not an issue with the second Adnaco backplane as postulated in the 11th Aug alog.

Images attached to this report

H1 ISC - Belated Friday 21/Aug/2026 commissioning report

keita.kawabe@ligo.org — Mon, 24 Aug 2026 00:01:53 -0700

Author: keita.kawabe@ligo.org

Report ID: 91647

1. ALSX is not healthy yet

Slow servo to ETMX (tidal) doesn't work yet. The feedback signal actually pushes the ETMX. I can see that the oplev moves by as large as 1urad or so when tidal into L1 is active but I don't know if that's the reason why ALSX loses lock as soon as slow is enabled. Ryan confirmed that the L2A gains/filters didn't seem to have changed recently.

I tried turning on green WFS (but not camera) without slow servo by going to ENABLE_WFS and turning off camera servo manually. That resulted in a slow 1.6Hz oscillation. I gave up after failing twice.

2. It seems that POP beam needs to be moved in +Y direction on HAM1/HAM2 septum

Not everything makes sense but it seems that POP beam needs to be steered in +Y direction on HAM1HAM2 septum (-X direction in ISCT1).

I looked at the single bounce beam from ITMX at 60W in ISCT1 and the beam seemed to be shifted too much in +X direction on ICST1 top periscope mirror compared with how I set the path up when ISCT1 was open. See POP_beam_too_much_to_the_left.jpg.

I quickly moved the POP beam in HAM1 using just PR3 angle as a quick and dirty method. I used POP_X_SUM as the power monitor for the single bounce beam in HAM1. I used PM1 to center POP_X. Without centering, when the beam is close to the center, a change in the beam position will result in a meaningful increase of power due to the center gap between the PD elements. If the beam is entirely in one quadrant this isn't an issue but it's difficult to know if that's the case when you're intentionally moving the beam.

I moved PR3 YAW from -236.7 to -245.7urad (PIT wasn't moved) and used PM1 to compensate. As the beam moved, at first the power didn't seem to change much if at all, but eventually it increased from 42 counts to 48 counts. This was pretty repeatable. I couldn't move PR3 further as PM1 railed. See POP_X_SUM_increase.png and POP_beam_after_PR3_move.jpg.

After moving PR3 I lost the beam on POP_A completely but that wasn't surprising. Even before moving PR3, by scanning PM1 I saw that the beam was not centered on POP_A when POP_X was centered. (The POP_X and POP_A see the same beam coming through the 334mm lens, but the distances from the lens to POP_X and POP_A are about 390mm and 310mm according to my eyeballing D1000313. That's large enough of a difference. If for example the beam position on PM1 changes by 5mm and you use PM1 to center the beam on POP_X, the beam position shifts by ~1mm on POP_A, that's already the radius of POP_A PD.)

After this excercise I moved PR3 and PM1 back to where they were before I started.

Not sure if we're ready to use pico in HAM3 yet as not everything seems to make sense. For example Masayuki and Sheila moved spot position on PR2 and saw no change in POP power.

3. Realigned COMM and DIFF

In the COMM path the beams were too low on the common BS and was heavily clipped. I fixed that and the COMM beat note changed from ~ -1.3 to 5.9 dBm. I changed the DIFF path too but it didn't change much.

See COMM_and_DIFF_touchup.png.

ISC

Images attached to this report

H1 General - OPS Friday EVE shift summary

ryan.crouch@ligo.org — Fri, 21 Aug 2026 17:57:08 -0700

Author: ryan.crouch@ligo.org

Report ID: 91646

TITLE: 08/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Keita investigated the beams out on ISCT1, he relocked green after he was finished, they still look good (~1.15 for ALS-Y, and ~0.75 for ALS-X). I'm leaving them unlocked.
LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
22:19	PEM	Robert	EX	N	Troubleshooting ground injection	00:10
22:21	ISC	Keita	LVEA	Y	Checking beams on ISCT1	00:49
23:24	PEM	Reinhardt	LVEA	Y	Checking on DAS fiber	23:51

H1 CDS - tconvert leapseconds file updated

david.barker@ligo.org — Fri, 21 Aug 2026 16:55:42 -0700

Author: david.barker@ligo.org

Report ID: 91645

Oli, Erik, Dave

Oli found that tconvert was complaining of an expired /ligo/data/tcleaps/tcleaps.txt file. The "valid through" line in this file is the UNIX time for 07aug2026, which is when we think this warning started.

We have extended the "valid through" time by 10 years, it will expire August 2036.

LHO General - Ops Day Shift Summary

ryan.short@ligo.org — Fri, 21 Aug 2026 16:32:40 -0700

Author: ryan.short@ligo.org

Report ID: 91644

TITLE: 08/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Quiet day for the most part with a Beckhoff reboot, more alignment work with ALS troubleshooting, various PEM activities, and a couple of tour groups. The JAC temperature servo still appears to be settling out slowly since the reboot, causing the JAC to unlock periodically (trend attached). The LVEA remains Laser HAZARD.
LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
17:29	CDS	Daniel	CR	-	Beckhoff computer restart	17:55
18:34	PEM	Robert, Reinhardt	LVEA	-	Shaker on output arm	23:23
21:46	PEM	Miranda, Shrey	MER	-	Set up seismometers	22:15
22:19	PEM	Robert	EX	-	Troubleshooting ground injection	Ongoing
22:21	ISC	Keita	LVEA	Y	Checking beams on ISCT1	Ongoing
23:24	PEM	Reinhardt	LVEA	-	Checking on DAS fiber	Ongoing

Images attached to this report

H1 CDS - Comment to New DAQSTAT

david.barker@ligo.org — Fri, 21 Aug 2026 15:10:01 -0700

Author: david.barker@ligo.org

Report ID: 91643

Claude has written a DAQSTAT User Guide, which I've posted to the DCC as T2000607

H1 CDS - h1syscssqzsdf restarted after getting stuck.

david.barker@ligo.org — Fri, 21 Aug 2026 14:06:03 -0700

Author: david.barker@ligo.org

Report ID: 91642

SQZ slow controls SDF became unresponsive late this morning. I tried a restart of this model on h1ecatmon0

> rtcds restart h1syscssqzsdf

but it did not read the monitor request file and ran with zeros in all the channel counts.

After verifying the monitor.req and safe.snap files existed and looked ok, I did a slow stop/start of this model with about 1 minute inbetween. This time it read the monitor file and is monitoring 1340 chans.

H1 CDS - Comment to Beckhoff PC restart (Ryan, Daniel, Keita)

ryan.short@ligo.org — Fri, 21 Aug 2026 13:46:26 -0700

Author: ryan.short@ligo.org

Report ID: 91641

Restored some ISC settings following Beckhoff reboot, SDFs attached.

Images attached to this report

H1 CDS - New DAQSTAT

david.barker@ligo.org — Fri, 21 Aug 2026 13:33:00 -0700

Author: david.barker@ligo.org

Report ID: 91640

I've completed the upgrade of DAQ stat. New features ported from the old system are:

- DC broadcast list check-sums must be identical

- DC FE network port bandwidth must match within a tolerance

- FWs disk usage is displayed, warnings issued to too large or too small

The MEDM was getting too tall to fit a 2k monitor, so the framewriter section was moved to the right.

Remaining task is to add the new channels to the DAQ next week.

Images attached to this report

H1 CDS - Beckhoff PC restart (Ryan, Daniel, Keita)

keita.kawabe@ligo.org — Fri, 21 Aug 2026 12:05:35 -0700

Author: keita.kawabe@ligo.org

Report ID: 91639

Daniel tried to rebooted Beckhoff PC remotely, but it didn't come back so he rebooted it in MSR.

After that things came back mostly, there were two major exceptions:

1. JAC WFS whitening/dewhitening mismatch.

WFS whitening was off for two stages we use but the anti-whitening was on. WFS was at first turned on by the guardian when we tried to lock JAC and it totally misaligned it. We had to manually locked JAC, noticed that the alignment was off, cleared WFS history both in WFS feedback filters as well as JM1 lock filters, fixed the whitening/dewhitening mismatch by pressing "ON" buttons for two whitening stages, and after that it started working OK.

2. JAC got cooler, temperature servo overheats at first, and we're only getting 15 minutes lock stretches for now.

It took about 20 minutes for the Beckhoff to come back because the first reboot attempt didn't work (1st attachment). Thermistor 1 temperature dropped by about 0.05 degC as the temperature servo wasn't doing anything (2nd attachment, it looks like a sudden change but it's not, it's just that the Beckhoff EPICS numbers were frozen before that). Temperature servo started heating it hard as soon as it came back, overshot and tried to reduce heating, but it's still heating harder than it used to. Because of that, JAC lock PZT voltage quickly goes to zero after relocking. We'll have to wait.

CDS, ISC

Images attached to this report

H1 ISC - Comment to ALSY WFS demod RF level monitor is broken but the fast channels are working fine but Beckhoff computer needs rebooting tomorrow (Mark, Fil, Daniel, Keita)

daniel.sigg@ligo.org — Fri, 21 Aug 2026 11:36:56 -0700

Author: daniel.sigg@ligo.org

Report ID: 91638

Main Beckhoff computer rebooted. Required a power cycle.

H1 PEM - Comment to Corner Station PEM Accelerometer mismatch identified and fixed

mirandarose.claypool@ligo.org — Fri, 21 Aug 2026 09:39:24 -0700

Author: mirandarose.claypool@ligo.org

Report ID: 91637

For detchar: Based on our (dave, robert, my) best guesses, this error starts on JAN 26th 2024 when the ENdevcos, as well as the signal conditioners for the accelerometers, were replaced (alog 75592). This is post end of O4a (Jan 16th 2024), so the data for O4a is okay, but the data for O4b/c is affected. This means that if there's an hveto round winner/trigger/pemcheck correlation/etc for one of the three channels on the right, it will instead be data from the detector on the left column. For clarity:

If the trigger says H1:PEM-CS_ACC_BEAMTUBE_SRTUBE_X_DQ, then the data is actually from the lvea floor accelerometer, H1:PEM-CS_ACC_LVEAFLOOR_HAM6_Z_DQ.
If the trigger says H1:PEM-CS_ACC_EBAY_FLOOR_Z_DQ, then the data is actually from the beamtube accelerometer, H1:PEM-CS_ACC_BEAMTUBE_SRTUBE_X_DQ.
if the trigger says H1:PEM-CS_ACC_LVEAFLOOR_HAM6_Z_DQ, then the data is actually from ebay accelerometer, H1:PEM-CS_ACC_EBAY_FLOOR_Z_DQ.

Here are some examples that I hope help clarify (as I was also confused):

When Dave and I tapped the ebay floor accelerometer with a pen, there was a spike on the ham6 floor accelerometer channel. So, H1:PEM-CS_ACC_LVEAFLOOR_HAM6_Z_DQ was incorrectly reading data from the ebay floor accelerometer and not the lvea floor accelerometer.
Likewise, when Robert unplugged the srtube accelerometer, the ebay floor z channel disappeared. So, the H1:PEM-CS_ACC_EBAY_FLOOR_Z_DQ channel was receiving information from the srtube accelerometer.
I've also attached spectra that shows a few days before and after the switch, Jan 25th and Jan 29th, 2024. You can see the channel names change for the different spectra while retaining the same shape.

CDS, DetChar, PEM

Images attached to this report

LHO General - Ops Day Shift Start

ryan.short@ligo.org — Fri, 21 Aug 2026 07:43:57 -0700

Author: ryan.short@ligo.org

Report ID: 91636

TITLE: 08/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 1mph Gusts, 0mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: More alignment work expected today including attempting to fix clipping in the POP path. Beckhoff restart also expected this morning; the computer looks to have lasted the night. The X arm is currently locked in green with good IR flashes.

LHO VE - Comment to HAM7 Pumpdown Started

gerardo.moreno@ligo.org — Fri, 21 Aug 2026 00:04:26 -0700

Author: gerardo.moreno@ligo.org

Report ID: 91635

(Travis, Gerardo)
Update.
HAM7 chamber pumpdown continues to progress, see attached plot for pumpdown trend.
AIP, the annulus system continues to pumpdown also, small can turbo attached at the annulus and a small cube aux-cart backing the can turbo, with a pressure of 7.8X10^-06 Torr reported by the aux-cart, we turned the ion pump on a few days ago, and the system has made some progress, see attached plot for progress.

Images attached to this report