aLIGO LHO Logbook

H1 SQZ - Comment to SQZ Looked Bad: Ran SCAN_SQZANG_FDS + Adjusted OPO Temperature

corey.gray@ligo.org — Sat, 21 Jun 2025 12:59:14 -0700

Author: corey.gray@ligo.org

Report ID: 85221

Vicky got back to me on Mattermost. She suggested running another SCAN SQZANG (because of the OPO adjustment). Went out of observing again to do that, and that restored our range. DARM FOM is still better, but H1-Live on nuc33 is still high...it might be a little lower since my first SQZ adjustments. At any rate, back to Observing.

SQZ

H1 SQZ - SQZ Looked Bad: Ran SCAN_SQZANG_FDS + Adjusted OPO Temperature

corey.gray@ligo.org — Sat, 21 Jun 2025 12:35:16 -0700

Author: corey.gray@ligo.org

Report ID: 85220

After returing to Observing for about 18min post-Saturday-Calibration, noticed that the DARM FOM trace was above reference at high frequency (+ "H1 Live" trace on nuc33 was also above the reference). Consulted the Troubleshooting SQZ wiki, dropped out of Observing, and did the following:

Ran SCAN_SQZANG_FDS: This made DARM FOM look better (back at reference for high frequency, but it was still higher for the "H1 Live" trace on nuc33).
Adjusted OPO Temperature: Able to increase H1:SQZ-CLF_REFL_RF6_ABS_OUTPUT a bit (see attached), but still higher for the "H1 Live" trace on nuc33. Then returned to Observing.

These adjustments had H1 out of Observing from 1917-1922utc. It has now been 10min, and it is looking like I have made the range worse (looking like range is ~15Mpc worse). Will give it more time and see how it goes while I grab lunch.

SQZ

Images attached to this report

H1 CAL - Saturday H1 Calibration Measurement (broadband headless + simulines)

corey.gray@ligo.org — Sat, 21 Jun 2025 12:11:46 -0700

Author: corey.gray@ligo.org

Report ID: 85217

Measurement NOTES:

Posted heads up reminder for the Sat Morning Calibration on the IGWN channel on Mattermost.
Following instructions (link)
H1 at NLN for for almost 2hrs55min (over 3hrs at 60W).
Calibration_Monitor medm screenshot is attached
1830-1859 utc Out of Observing for CALIBRATION
Broadband measurement started at 1434565843.086414 (18:30:25utc)
- Measurement at: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250621T183025Z.xml
Simullines measurement
- gps START time: 1434566163.985407 (18:35:45utc)
- gps STOP time: 1434567563.816039 (18:59:95utc)
- File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250621T183546Z.hdf5
- File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250621T183546Z.hdf5
- File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250621T183546Z.hdf5
- File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250621T183546Z.hdf5
- File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/
1859 ISC_LOCK taken back to NLN for observing

Attached is a screenshot of the Calibration Monitor + pdf of Pydarm Report

CAL

Images attached to this report

Non-image files attached to this report

H1_calibration_report_20250621T183546Z.pdf

LHO VE - Sat CP1 Fill

david.barker@ligo.org — Sat, 21 Jun 2025 10:20:39 -0700

Author: david.barker@ligo.org

Report ID: 85219

Sat Jun 21 10:10:09 2025 INFO: Fill completed in 10min 5secs

Images attached to this report

H1 ISC - H1 Back to Observing, Nodes Loaded, CS_ISC sdf Diffs ACCEPTED, Should Be Thermalized for 1830 Calib

corey.gray@ligo.org — Sat, 21 Jun 2025 08:50:19 -0700

Author: corey.gray@ligo.org

Report ID: 85218

H1 is back to Observing. As noted earlier, took the opportunity to take care of some housekeeping tasks:

Timing allowed for a 2nd alignment to happen at a time when the BS was cooled off over an hour.
Alignment above happened after INIT ALIGN was reloaded (to get PRC ALIGN OFFLOADED back into INITIAL ALIGNMENT).
ISC LOCK was also LOADed.
DRMI locked up fairly smoothly and automatically.
H1 hit 60 wats at 1526utc
Had (2) SDFs diffs (for "H1:LSC-REFL_SUM_{A,B}_IN2GAIN") in CS_ISC related to what Elenna mentions in alog 85206. These were ACCEPTED (see attached).

Next uip: Take the Saturday Morning Calibration in about 2.5hrs *knock on wood*

Images attached to this report

H1 ISC - INITIAL ALIGNMENT Run With Reloaded INIT_ALIGN To Include PRC ALIGN OFFLOADED

corey.gray@ligo.org — Sat, 21 Jun 2025 07:44:26 -0700

Author: corey.gray@ligo.org

Report ID: 85216

Per Elenna's alog85200 yesterday + RyanS's subentry (with updated INIT ALIGN), Ran a 2nd INITIAL ALIGNMENT this morning for two reasons (to (1) enact Ryan's changes with a RELOAD of INIT ALIGN, and (2) to let the BS chill for about 65min).

Looks like the PRC ALIGN OFFLOADED worked fine as Elenna notes (see attached IR signals during alignment.

Images attached to this report

LHO General - Sat DAY Ops Transition

corey.gray@ligo.org — Sat, 21 Jun 2025 07:21:51 -0700

Author: corey.gray@ligo.org

Report ID: 85214

TITLE: 06/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

Walked in to see H1 down from a lockloss at 1317utc. It had a 16.5+hr lock (no obvious culprits for the lockloss). I am in a little early, but was too late to:

Prevent ISC_LOCK from automatically going into an alignment with a "hot-ish" BS....so another alignment may be needed. But the alignment did start 45min after the lockloss at 1403utc, so maybe our BS is cooled.
- And looks like PRC ALIGN OFFLOADED was skipped due to INIT ALIGN (needing a LOAD).
- I'm thinking, I might just do another complete INITIAL ALIGNMENT with a reloaded INIT ALIGN.
And to RELOAD: ISCLOCK & INITALIGN

LHO General - Ops Eve Shift Summary

ryan.short@ligo.org — Fri, 20 Jun 2025 22:01:03 -0700

Author: ryan.short@ligo.org

Report ID: 85213

TITLE: 06/21 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Very quiet evening where H1 was observing throughout; current lock stretch is up to just over 8 hours.

High frequency BLRMs (and DARM) were slowly getting worse over the first few hours of the lock, but have since leveled out (this didn't seem to affect inspiral range much)
Wind speeds have been coming down for the last couple hours and the forecast for the night looks favorable
Since we've been observing, I haven't had a chance to load ISC_LOCK and INIT_ALIGN, so that'll have to be done tomorrow

H1 ISC - Comment to PRC Align in ALIGN IFO looks good

ryan.short@ligo.org — Fri, 20 Jun 2025 16:46:47 -0700

Author: ryan.short@ligo.org

Report ID: 85212

Since PRC_ALIGN should be working again, I removed the edge in the INIT_ALIGN Guardian between 'INPUT_ALIGN_OFFLOADED' and 'MICH_BRIGHT_ALIGNING' that was added in alog84950 so that automatic initial alignments will now include PRC.

OpsInfo

H1 General - Fri Ops DAY Shift Summary

corey.gray@ligo.org — Fri, 20 Jun 2025 16:38:42 -0700

Author: corey.gray@ligo.org

Report ID: 85194

TITLE: 06/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Today's main activity was supposed to be a Commissioning Time (from 8am-2pm (PDT) [1500-2100utc]), but with a lockloss near the start, much of the commissioing time was focused on troubleshooting for locking issues with DRMI and also ALS (some commissioning tasks happened at the beginning & end of today's Commissioning Period of 8am-2pm (PDT) [1500-2100utc].

ALSO A New NOTE for Operators:

It looks like we can now run the usual INITIAL_ALIGNMENT (vs MANUAL_ALIGNMENT), because for IFO_ALIGN, the PRC_ALIGN_OFFLOADED state now looks good (see Elenna's alog85200). However, Sheila noted, we should be mindful of the BS heating (Camilla's alog84922). In other words, we should run alignments about 30min after a lockloss (or even 60min)---to allow the BS time to cool down and return to its "nominal" pointing at the beginning of locks.
Elenna has some changes in ISC_LOCK, so after the next lockloss, we'll need to run a LOAD of ISC_LOCK and ACCEPT the SDF Diffs which come up (see Elenna's alog85207).

VAC Note: There were hopes we could turn OFF the HAM1 Pump, but there is a pressure we need to get below before we can do this, and we were not there today. Travis mentioned it will have to wait until Monday.
LOG:

1510 Commmissioning begins (sheila)
- Sheila starts with running Jennie's DARM offset step script. Then Keith Kuns@MIT and Sheila will run a measurement using the Squeezer to check H1 mode matching via the ADF (Audio Diagnostic Field).
1528 LOCKLOSS (this was just after Keith started his SQZ measurement--which we don't think was the reason for the lockloss; bad timing H1)
LOCKING notes: Letting H1 try to lock on its own
- Y-arm did a Scan Alignment
- DRMI didn't look great, so I went for CHECK FRINGES + PRMI
- 1602-1622 Manual Initial Alignment (PRM tweaked to get AS_A up to 1.32 (from 1.28))
- For DRMI, it looked better post-alignment, BUT after 11min, GRD took to PRMI.
  - 1640 Sheila running a check at PRMI_ASC but no change made; after this DRMI locked, but had lockloss at ENGAGE ASC as the PR Gain rung up before the lockloss.
- For next locking attempt hold at DRMI LOCKED PREP ASC
  - Although the X-arm was locked above 1, it was taken to a SCAN ALIGNMENT which was odd.
1617-1629 H2 Room cleaning (kim, nellie)
1625 Setting up measurement in PCal Lab (francisco)
1630 Receiving roll-up opened (for cardboard) (kim)
1708-1714 Connecting cable to CM board at racks (sheila, matt)
1802-1819 Parts check in lvea (mitch)
1804 3IFO checks (betsy, suresh, LIGO visitors)
1820-1837 Running another Manual Alignment
- PRC ALIGN OFFLOADED looks it works---Elenna checked it out during this alignment: So we should be able to run the standard INITIAL_ALIGNMENT
MORE Locking Notes: Had several more locklosses during the commissioining time---due to ALS & ENGAGE ASC for FULL IFO. Focus switched to troubleshooting the ALS locking, DRMI locking, and getting through ENGAGE ASC.
- 2046 H1 finally back to NOMINAL LOW NOISE. Elenna was able run a measurement once we were back to NLN & once she was done, she disconnected the SR560 out on the floor and disconnected it from the racks and then turned out the LVEA lights.
1930 ISS array work in the optics lab (keita, rahul)
1957-2005 Checking shutters in Pcal Lab (francisco)
2115 Back to OBSERVING

LHO General - Ops Eve Shift Start

ryan.short@ligo.org — Fri, 20 Jun 2025 16:03:13 -0700

Author: ryan.short@ligo.org

Report ID: 85210

TITLE: 06/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 141Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 28mph Gusts, 14mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: H1 has been locked for over 2 hours.

Will load ISC_LOCK when next out of observing - alog85207
Wind speeds have been rising, microseism low
All other systems nominal

H1 CAL - Comment to Calibration Sweep 06/19 - Failed - Lockloss during Simulines -

elenna.capote@ligo.org — Fri, 20 Jun 2025 15:28:11 -0700

Author: elenna.capote@ligo.org

Report ID: 85209

Here is a screenshot of the broadband measurement. The calibration still looks good!

Images attached to this report

LHO FMCS - HVAC Fan Vibrometers Check - Weekly

ryan.short@ligo.org — Fri, 20 Jun 2025 15:13:29 -0700

Author: ryan.short@ligo.org

Report ID: 85208

FAMIS 26395, last checked in alog85021

All fans look largely unchanged compared to last week and are all within noise thresholds.

PEM

Images attached to this report

H1 ISC - Comment to CARM OLG and gain change

elenna.capote@ligo.org — Fri, 20 Jun 2025 14:57:18 -0700

Author: elenna.capote@ligo.org

Report ID: 85207

I see now, with Keita's help, that I changed the "wrong" gain sliders, because I should have adjusted the "H1:LSC-REFL_SERVO_IN{1,2}GAIN" sliders. However, jsut based on how things are connected, I don't think it is having an overall different effect right now. But, to do this properly, I am updating the guardian code on line 5882:

if ezca['LSC-REFL_SERVO_IN1GAIN'] < 6:

ezca['LSC-REFL_SERVO_IN1GAIN'] += 1

ezca['LSC-REFL_SERVO_IN2GAIN'] += 1

That "6" had been 3, but Sheila had lowered that value from 6 to 3 during the O4a/b break (see 76751) following some measurements. Now, I am wondering if we should have lowered that gain at all during that break.

That means, on the next lockloss, the ISC_LOCK guardian must be loaded, and then when we go to observing, there will be SDF diffs in the H1:LSC-REFL_SERVO_IN{1,2}GAIN and H1:LSC-REFL_SUM_{A,B}_IN2GAIN channels. These differences should be accepted. Tagging OpsInfo.

H1 ISC - CARM OLG and gain change

elenna.capote@ligo.org — Fri, 20 Jun 2025 14:35:51 -0700

Author: elenna.capote@ligo.org

Report ID: 85206

Sheila measured the CARM gain during vent recovery at a thermalized time (84944), and it seemed low, so today we plugged in the SR785 and measured the CARM OLG at the start of lock.

Right at the beginning of lock, the UGF was 14.4 Hz, which is fine except that we will lose gain from thermalization. I bumped up the gain by 1 dB on each REFL A and B slider ("H1:LSC-REFL_SUM_{A,B}_IN2GAIN") and remeasured, and the UGF was about 14.3 Hz. Then, I increased the gain another 2 dB each on each slider and remeasured, 16 kHz. This is where we want to be, although I imagine it will decay more as we thermalize.

This means that in NLN, we want our CARM gain settings to be 15 dB on each slider, which I accepted in SDF. However, I have not yet put them in the guardian because I am trying to figure out where that actually should be adjusted.

I have attached the three measurements I took. The title of the first one is misleading since I used the wrong template, but the time stamps on all are accurate.

First measurement

Second measurement, both gains up +1 dB

Third measurement, both gains up +2 dB more

SDF in observe

Procedural notes for future me to measure the OLG and plot the measurement:

> cd ligo/gitcommon/psl_measurements/templates

> conda activate psl

> python ../code/SRmeasure.py carm_olg_template.yml

> python ../code/quick_tf_plot.py ../data/carm_olg/[filename]

I unplugged the SR785 before observing.

PSL

Images attached to this report

Non-image files attached to this report

carm_olg_at_carm_to_analog_20-06-2025_135810.pdf

CARM_OLG_20-06-2025_140109.pdf

CARM_OLG_20-06-2025_140300.pdf

H1 ISC - Comment to SDF Diffs Post Today's Commissioning/Troubleshooting Work

elenna.capote@ligo.org — Fri, 20 Jun 2025 14:24:32 -0700

Author: elenna.capote@ligo.org

Report ID: 85205

I don't understand what the ALS diffs are, but I reverted them because I think they may have occurred because Sheila and I left the green shutters open today to check the offsets.

I reverted all CAL gain tramps. Francisco had changed them due to a test.

I also SFDed the REFLAIR gains as done in this alog 85201, but didn't take a screenshot.

Images attached to this report

H1 ISC - SDF Diffs Post Today's Commissioning/Troubleshooting Work

corey.gray@ligo.org — Fri, 20 Jun 2025 14:21:05 -0700

Author: corey.gray@ligo.org

Report ID: 85204

After today's commissioning and trouble shooting work we had a list of SDFs to address. Elenna and I both addressed these.

Elenna will add a comment to this alog with the SDFs she addressed.

I took care of the SDF Diff for SQZ ADF. Kevin Kuns noticed this channel was not restored to its OBSERVING value; he took it to 320, but SDF flagged this because it should actually be 322, so I REVERTed this channel (H1:SQZ-ADF_VCXO_CONTROLS_SETFREQUENCYOFFSET) to 322 (see attached).

Images attached to this report

H1 ISC - ENGAGE ASC locklosses due to high CHARD P gain

elenna.capote@ligo.org — Fri, 20 Jun 2025 13:21:49 -0700

Author: elenna.capote@ligo.org

Report ID: 85203

We have been having large glitches and sometimes locklosses from ENGAGE ASC FOR FULL IFO. I have tracked the problem down to the CHARD P gain coming on at full gain at the start of the state. This is an error that we made when trying to recover from the vent- we commented out a 30 dB gain filter in the late part of the state, and then set the new full gain at teh gain that engages at the start of the state. I have now edited the guardian to engage CHARD P with a gain that is 30 dB less than the final gain ('ENGAGE_ASC_FOR_FULL_IFO_initial'), and then the final gain is ramped at the end of the state (ENGAGE_ASC_FOR_FULL_IFO_final). These gains are set in lscparams.

Also, we put back the ITMX spot position to center in pitch, instead of the strange offset we added during vent recovery.

H1 ISC - Comment to DRMI acquistion sensing adjusted

elenna.capote@ligo.org — Fri, 20 Jun 2025 13:09:43 -0700

Author: elenna.capote@ligo.org

Report ID: 85202

SDFs for phases

these will need to also be updated in OBSERVE

Images attached to this report

H1 ISC - DRMI acquistion sensing adjusted

sheila.dwyer@ligo.org — Fri, 20 Jun 2025 13:03:07 -0700

Author: sheila.dwyer@ligo.org

Report ID: 85201

Corey, Elenna, Sheila

Recently we have been having trouble locking DRMI even when the flashes seem good. We stopped to check some DRMI phasing, similar to what we've done for PRMI in 85080 and 84630.

The first screenshot shows the PRCL OLG, which has a large wiggle from 20-40 Hz before we started (REFL AIR 9 phase -21). We ran the template in userapps/lsc/h1/templates/phase_REFLAIR.xml to send a 300 count excitation to PRM M3 at 132 Hz, and phased this into I for REFLAIR 45 (to reduce PRCL cross coupling to the MICH loop), and into I for REFLAIR 9. Then we checked the TF of PRM to both I sigal to estimate the matrix element we should use to cancel the PRM coupling to the SRCL error signal, and updated this from -1.8 to -1.7.

These three things have reduced the wiggle. We are hoping this will help with DRMI acquisition, our first two attempts have gone well but we will wait to collect some statistics.

Images attached to this report

H1 SUS - SRM Transverse OSEM, Mounted on Opposite Side, has incorrect OSEM2EUL / EUL2OSEM matrix sign; Inconsequential, but should be Fixed for Sanity's Sake.

jeffrey.kissel@ligo.org — Fri, 20 Jun 2025 12:03:44 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 85198

J. Kissel I'm building up some controls design documentation for the derivations of the OSEM2EUL / EUL2OSEM matrices for existing suspension types (see G2402388), in prep for deriving new ones for e.g. the HRTS and if we upgrade any SUS to use the 2-DOF AuSEMs. In doing so, I re-remembered that the HLTS, HSTS, OMC controls arrangement poster (E1100109), defining the now-called "6HT" OSEM arrangement in T2400265 calls out two possible positions for the transverse sensor, the "side" and "opposite side," which I'll abbreviate as SD and OS, respectively from here on. If the transverse sensor is mounted in the SD position, then as the suspension moves in +T, the OSEM further occults the LED beam, creating a more negative ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be -1.0. If the transverse sensor is mounted in the OS position, then as the suspension moves in +T, the OSEM opens up revealing more LED beam, creating a more positive ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be +1.0. Not *actually* remembering that the HLTSs PR3, SR3, and two of the 9 HSTSs, SR2 and SRM use OS as their transverse sensor yesterday, and missing the note from Betsy in the abstract of E1100109 to look at the each SUS' Systems Level SolidWorks assembly for transverse sensor location assignment (prior to this morning it was not in red, nor did it call which suspension explicitly have their transverse sensor mounted in the OS position), I was worried that we'd missed this when defining the sign of *all* HLTS / HSTS / OMCS OSEM2EUL / EUL2OSEM matrices, and assumed they were all installed as SD OSEMs with -1.0 OSEM2EUL and EUL2OSEM matrix elements. Below, I inventory the status with - suspension name, - a reference to picture of the transverse OSEM (or the corresponding flag w/o the OSEM), - confirming SW drawing does match the picture, - the current value / sign of the OSEM2EUL / EUL2OSEM matrix element (H1:SUS-${OPTIC}_M1_OSEM2EUL_2_6 or H1:SUS-${OPTIC}_M1_EUL2OSEM_6_2) - a conclusion of "all good" or what's wrong. Optic T Sensor aLOG pic SW check OSEM2EUL Conclusion Mount value /EUL2OSEM MC1 SD LHO:6014 D0901088 g -1.0 all good MC3 SD LHO:39098 D0901089 g -1.0 all good PRM SD LHO:39682 D0901090 g -1.0 all good PR3 OS LHO:39682 D0901086 g +1.0 all good MC2 SD LHO:85195 D0901099 g -1.0 all good PR2 SD LHO:85195 D0901098 g -1.0 all good SR2 OS LHO:41768 D0901128 g +1.0 all good SRM OS LHO:60515 D0901133 g -1.0 OSEM2EUL/EUL2OSEM wrong! SR3 OS LHO:60515 D0901132 g +1.0 all good FC1 SD LHO:61710 D1900364 g -1.0 all good FC2 SD LHO:65530 D1900368 g -1.0 all good OMC SD LHO:75529 D1300240 g -1.0 all good (see also G1300086) So, as the title of this aLOG states, we've got the sign wrong on SRM. Shouldn't we have discovered this with the "health check TFs?" Why doesn't this show as a difference in the "plant" ("health check") transfer functions when comparing against other SUS that have the sign right? Why *don't* we need a different sign on SRM's transverse damping loop? Because the sign in the EUL2OSEM drive and OSEM2EUL sensed motion is self consistent: When SRM EUL2OSEM matrix requests to drive in +T as though it had an OSEM coil in the "SD" position, it's actually driving in -T because the OSEM coil is in the OS position. On the other side, the OSEM2EUL matrix corrects for a "SD" OSEM, with "more negative when moves in +T", and and has the (incorrect) -1.0 in the OSEM2EUL matrix. But since the SUS is actually moving in -T, making the flag occult more of the OS OSEM LED beam, yielding a more negative ADC signal, the -T is reported +T in the DAMP bank because of minus sign in "SD" OSEM2EUL matrix. So the phase between DAMP OUT and DAMP IN at DC is still zero, as though "everything was normal," because requested physical drive +T is sensed as +T. Thus the Sensor / Drive phase is zero at DC like every other HSTS, we can use the same feedback -1.0 sign like every other DOF and every other HSTS. Does this matter for the IFO? No. This sensor is only used to damp transverse, i.e. transverse to the main IFO beam. If there're no defects on the SRM optic HR surface, and the transverse displacement doesn't span a large fraction of the beam width, then there should be no coupling into L, P or Y which are the DOFs to which the IFO should be sensitive. This is corroborated by Josh recent work where he measured the coupling of the "SD" OSEM drive (actually in the OS position, driving -T) and found it to be negligible; see LHO:83277, specifically this SRM plot. Not only is the IFO not sensitive to the transverse drive from the OSEM, but also the absolute sign of whether it's +T or -T doesn't matter since there's no *other* sensors that measure this DOF that we'd have to worry about comparing signs against. Should we fix it? I vote yes, but with a low priority, perhaps during maintenance when we have the time to gather a "post transverse sensor sign change fix" set of transfer functions.

Non-image files attached to this report

allhstss_2025-06-20_H1SUSSRM_TransverseOSEM_SignCheck_TtoT_TF.pdf

G2402388-x0_Derivation_of_OSEM2EUL_Sensing_Matrices_6HT_TSensing.pdf

H1 ISC - PRC Align in ALIGN IFO looks good

elenna.capote@ligo.org — Fri, 20 Jun 2025 11:33:18 -0700

Author: elenna.capote@ligo.org

Report ID: 85200

While Corey ran an initial alignment, I went to PREP_PRC_ALIGN to check the WFS error signal for that state. Both pitch and yaw looked good, I confirmed the signals cross zero when expected, and so I turned on the PRC ALIGN state and the initial alignment engaged and offloaded properly. Seems like we can use PRC align now!

I tagged OpsInfo so operators know. I recommend that the operators just pay attention during PRC Align over the next few days just to ensure nothing is going wrong (watch build ups as the ASC engages and confirm it's going in the right direction).

GRD, OpsInfo

LHO VE - Fri CP1 Fill

david.barker@ligo.org — Fri, 20 Jun 2025 11:11:32 -0700

Author: david.barker@ligo.org

Report ID: 85199

Fri Jun 20 10:07:53 2025 INFO: Fill completed in 7min 49secs

Images attached to this report

H1 ISC - DARM offset stepping, unrelated lockloss

sheila.dwyer@ligo.org — Fri, 20 Jun 2025 10:40:43 -0700

Author: sheila.dwyer@ligo.org

Report ID: 85197

Corey and I ran the DARM offset stepping script using Jennie Wright's instructions from 85136.

Writing data to data/darm_offset_steps_2025_Jun_20_15_11_46_UTC.txt Moving DARM offset H1:OMC-READOUT_X0_OFFSET to 4 at 2025 Jun 20 15:11:46 UTC UTC (GPS 1434467524)

We lost lock 2 minutes after this script finished. Kevin was running an ADF sweep at the time, but that was not doing anything at the time of the lockloss, so this seems like an unrelated lockloss.

H1 PSL - PSL Status Report (FAMIS #26427)

corey.gray@ligo.org — Fri, 20 Jun 2025 10:39:10 -0700

Author: corey.gray@ligo.org

Report ID: 85196

This is for FAMIS #26427.
Laser Status:
    NPRO output power is 1.844W
    AMP1 output power is 70.07W
    AMP2 output power is 140.3W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 3 days, 0 hr 25 minutes
    Reflected power = 23.23W
    Transmitted power = 105.5W
    PowerSum = 128.7W

FSS:
It has been locked for 0 days 0 hr and 5 min
TPD[V] = 0.8216V

ISS:
The diffracted power is around 4.0%
Last saturation event was 0 days 0 hours and 32 minutes ago

Possible Issues:
PMC reflected power is high

PSL

H1 SUS - Comment to B&K Hammer Done in HAM3 Baffles, SR2 Cage, and of Primary/Final/Large in-vac TCS Steering Mirrors in BSC2

jeffrey.kissel@ligo.org — Fri, 20 Jun 2025 09:19:17 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 85195

Adding an oldy-but-goldy picture of MC2 (background) and PR2 (foreground) taken by Conor Mow-Lowry the day of this BnK exercise. The picture is taken from the -Y HAM 3 door, so IFO +X and the beam splitter is to the right, and +L for both suspensions is to the left as their HR surfaces point back toward HAM2 (to the left). Critical to today's yak shaving: the OSEM measuring Transverse at the top mass (M1) stage is toward the camera for both suspensions, i.e. in their +T direction, which means it's the "SIDE," or SD OSEM, per E1100109 (rather than the OPPOSITE SIDE, or OS). (yak-shaving: while putting together the derivation of the OSEM2EUL matrices in G2402388), I'm reminded that some HSTS were assembled with the Transverse sensor on in the OS position, and I'm on the hunt as to which ones -- and making sure the (SD to T) & (T to SD) element OSEM2EUL & EUL2OSEM matrices, respectively, are correctly -1.0 if SD and +1.0 if OS.) MC2 and PR2's OSEM2EUL matrix value H1:SUS-[MC2,PR2]_M1_OSEM2EUL_2_6 is correctly -1.0.

Images attached to this report

LHO General - Fri Ops Day Transition

corey.gray@ligo.org — Fri, 20 Jun 2025 07:38:22 -0700

Author: corey.gray@ligo.org

Report ID: 85193

TITLE: 06/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

H1's been locked 8.75hrs with no Owl shift notifications and a fairly quiet environmental conditions (breezes picking up a little (just over 10mph).

After the lockloss Oli notes at the end of their shift, H1 relocked fine without a need for another alignment.

Commissioning is also scheduled from 8-2PDT today.

H1 General - Ops Eve Shift End

oli.patane@ligo.org — Thu, 19 Jun 2025 22:08:45 -0700

Author: oli.patane@ligo.org

Report ID: 85192

TITLE: 06/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently relocking and in FIND_IR.

We've been having short locks all day, two of them being during my shift, despite the locklosses seemingly being caused by different or unknown causes. None of them seem to be caused by anything environmental, as wind and ground motion have been low (secondary useism was a bit elevated, but has been coming down and is nowhere near the amoount that we would typically be having problems with it). We've also now had two locklosses during the last two relock attempts from ENGAGE_ASC_FOR_FULL_IFO, from the spot where we've been having that glitchiness in the PR gain since coming back from the vent. Also, like Ibrahim mentioned in his end of shift alog (85186), DRMI has been taking a really long time to catch even though the flashes have been great. It's been taking us down to CHECK_MICH multiple times, and each time the alilgnment looks great.

During the relock following the 2025-06-20 00:09 UTC lockloss (85188), once we got back up to NLN, the squeezer was still working on trying to relock. It wasn't able to lock the OPO and was giving the messages "Scan timeout. Check trigger level" and "Cannot lock OPO. Check pump light on SQZT0". However, I just tried re-requesting LOCKED_CLF_DUAL on the OPO guardian, and it locked fine first try. So I guess that wasn't actually a problem? tagging sqz anyway?

LOG:

23:30 Relocking
23:59 NOMINAL_LOW_NOISE
    00:01 Observing
00:09 Lockloss
    - Running a manual initial alignment
    - Lockloss at ENGAGE_ASC_FOR_FULL_IFO
    - Lockloss from CARM_TO_TR
02:05 NOMINAL_LOW_NOISE
    02:11 Observing
03:32 Lockloss
    - Running a manual initial alignment
    - Lockloss at ENGAGE_ASC_FOR_FULL_IFO

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
23:36	FAC	Tyler	XARM	n	Checking on his beloved bees	23:52

SQZ

H1 General - Lockloss

oli.patane@ligo.org — Thu, 19 Jun 2025 20:33:24 -0700

Author: oli.patane@ligo.org

Report ID: 85191

Lockloss at 2025-06-20 03:32 UTC after 1.5 hours locked. Not sure why we're having all these short locks today

Lockloss

H1 General - Comment to Locklosss 15:55 UTC

oli.patane@ligo.org — Thu, 19 Jun 2025 19:21:28 -0700

Author: oli.patane@ligo.org

Report ID: 85189

I wasn't able to confirm for sure that the lockloss was caused by the calibration sweep. It looks like the QUAD channels all had an excursion at the same time, before the lockloss was seen in DARM(ndscope1). It does look like in the seconds before the lockloss, there were two excitations that were ramping up (H1:SUS-ETMX_L2_CAL_EXC_OUT_DQ at ~6 Hz(ndscope2) and H1:SUS-ETMX_L3_CAL_EXC_OUT_DQ at ~10Hz(ndscope3)). Their ramping up is not seen in the QUAD MASTER_OUT channels, however, so it's hard to know if those excitations were the cause.

Images attached to this report

H1 General - Comment to Lockloss

oli.patane@ligo.org — Thu, 19 Jun 2025 19:12:24 -0700

Author: oli.patane@ligo.org

Report ID: 85190

02:11 Back to Observing

H1 General - Lockloss

oli.patane@ligo.org — Thu, 19 Jun 2025 17:12:16 -0700

Author: oli.patane@ligo.org

Report ID: 85188

Lockloss at 2025-06-20 00:09 UTC after only 10 minutes locked

Lockloss

H1 General - Comment to Lockloss 22:25 UTC

oli.patane@ligo.org — Thu, 19 Jun 2025 17:02:11 -0700

Author: oli.patane@ligo.org

Report ID: 85187

00:01 Observing

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 16:32:49 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85186

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

IFO is in DHARD_WFS and LOCKING

Overall a quiet shift with three seemingly different locklosses. Two of these happened less than 2 hours into the lock.

Lockloss 1: During Simulines - Alog 85178. Calibration sweep could not produce the report but BB ran successfully - Alog 85179

Lockloss 2: ETM Glitch - Alog 85182

Lockloss 3: EY Kick right before - Alog 85184

I also reverted the edits that Camilla and Oli made by Camilla’s request. These were to SQZ_FC Beamspot Control, turning it back on (SDFs attached)

Other than that, it seems that locking is taking a very long time to lock DRMI without doing an initial alignment despite excellent flashes. Touching mirrors does not seem to help and whenever DRMI does lock, it stays locked so I do not think this has to do with alignment or too much motion (ground or otherwise).

Microseism is on the rise and there are regular 5.0 quakes happening at the mid-atlantic ridge.

LOG:

None

Images attached to this report

H1 General - Ops Eve Shift Start

oli.patane@ligo.org — Thu, 19 Jun 2025 16:16:29 -0700

Author: oli.patane@ligo.org

Report ID: 85185

TITLE: 06/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

Curently relocking and in ACQUIRE_DRMI. Flashes are great but it won't catch. It caught PRMI pretty fast, but now we're back in DRMI

H1 General - Lockloss 22:25 UTC

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 15:47:31 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85184

Unknown Cause lockloss around the same time into NLN as the previous one, which was ETM Glitch. The H1 Lockloss tool does not show this though. Rather, it shows that EY L2 was the first to have a small glitch-like shake followed by the LL.

Lockloss

H1 General - Lockloss 19:05 UTC

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 12:16:24 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85182

ETM Glitch Lockloss. There were no earthquakes or at the time of the lockloss. Microseism is on the rise though it is nowhere near a lock-affecting amount - same for wind.

H1 Lock Report just ended and it was the ETM Glitch.

Lockloss

LHO VE - Thu CP1 Fill

david.barker@ligo.org — Thu, 19 Jun 2025 10:10:56 -0700

Author: david.barker@ligo.org

Report ID: 85181

Thu Jun 19 10:08:15 2025 INFO: Fill completed in 8min 12secs

Images attached to this report

H1 General - Comment to Ops Eve Shift End

camilla.compton@ligo.org — Thu, 19 Jun 2025 09:47:17 -0700

Author: camilla.compton@ligo.org

Report ID: 85180

Ibrahim turned FC Beamspot control back on while we were relocking this morning as we do not think it was related to the FC locklosses yesterday (85172), more likely was the high wind.

SQZ

H1 CAL - Calibration Sweep 06/19 - Failed - Lockloss during Simulines -

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 09:06:19 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85179

Headless Start: 1434382652

2025-06-19 08:42:24,391 bb measurement complete.
2025-06-19 08:42:24,391 bb output: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250619T153714Z.xml
2025-06-19 08:42:24,392 all measurements complete.
Headless End: 1434382962

Simulines Start: 1434383042

2025-06-19 15:55:14,510 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 8.99, and amplitude 0.53965, is finished. GPS start and end time stamps: 1434383704, 1434383727
2025-06-19 15:55:14,510 | INFO | Scanning frequency 10.11 in Scan : L3_SUSETMX_iEXC2DARMTF on PID: 2067315
2025-06-19 15:55:14,511 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 10.11, is now running for 28 seconds.
2025-06-19 15:55:17,845 | ERROR | IFO not in Low Noise state, Sending Interrupts to excitations and main thread.
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:LSC-DARM1_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L2_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L3_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:CAL-PCALY_SWEPT_SINE_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L1_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file structure.
PDT: 2025-06-19 08:55:22.252424 PDT
UTC: 2025-06-19 15:55:22.252424 UTC
Simulines End GPS: 1434383740.252424

Could not generate a report using the wiki instructions (probably due to incomplete sweep).

Images attached to this report

H1 General - Locklosss 15:55 UTC

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 08:57:55 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85178

Lockloss whilst running simulines. Since this has happened in the last two weeks, caused by the sweep, and there are no immediate other causes, it is probably what caused the Lockloss. We were in Observing for nearly10 hrs.

Lockloss

H1 CDS - Comment to DAQ DC0 crash

david.barker@ligo.org — Thu, 19 Jun 2025 08:44:54 -0700

Author: david.barker@ligo.org

Report ID: 85177

FW0 full frame gap due to crash and restart:

Jun 18 16:14 H-H1_R-1434323584-64.gwf
Jun 18 16:26 H-H1_R-1434324288-64.gwf

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Thu, 19 Jun 2025 07:43:01 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85176

TITLE: 06/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 6mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING since 05:53 UTC (~9hr lock!)

Plan is to continue observing.

H1 AOS - Comment to ISS 2nd loop assembly S1202966 inspection: No damage, but no upgrade parts, no cover/lid (JennieW, Keita)

keita.kawabe@ligo.org — Wed, 18 Jun 2025 23:25:29 -0700

Author: keita.kawabe@ligo.org

Report ID: 85175

Brief update about the following two items. No spare was found at LHO as of Jun/18/2025, so in the worst case we will use the parts salvaged from the damaged S1202967 assembly (they were already sent to C/B).

D1300718. This is a kit comprising two 4.501" poles with cutout (Type 1), one 6.511" pole (Type 2) and two thinner 3" poles (Type 3).
- Total of 10 Type 1, 8 Type 2 and 10 Type 3 have been manufactured (ICS record) enough to manufacture 5 kits.
- One kit is in WHAM2, one in LHAM2, one in the damaged S1202967, there might be another one for India unit S1202968, that's 4 kits in total maximum. There should be at least one spare kit somewhere.
D1300719. This is called QPD MT PLATE, it's a top platform to mount the QPD as well as the ISS array cover assembly.
- Total of 8 has been manufactured (ICS record).
- Like D1300718, 3 or 4 pieces were used (WHAM2, LHAM2, damaged S1202967, maybe one in India unit S1202968). There should be at least 4 spare pieces somewhere.

H1 General - Ops Eve Shift End

oli.patane@ligo.org — Wed, 18 Jun 2025 22:32:59 -0700

Author: oli.patane@ligo.org

Report ID: 85174

TITLE: 06/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Currently relocking and at MOVE_SPOTS. We lost lock earlier after having been locked for 4.5 hours, with half of that locked time being spent messing with the SQZ filter cavity and trying to keep it from unlocking(85169). We still haven't figured out why it was unlocking. For the night we are keeping the FC beam spot control off. SDFs have been accepted to keep the FC beam spot control filter inputs off(sdf). We don't really think that was the issue, but we got out longest span (15 mins before LL) of a locked sqzer after turning it back off after the unlocking issue had started. We'll look more into the sqzing issues tomorrow, so for Tony: if we have SQZ issues overnight, just go to Observing without SQZing and it'll get dealt with tomorrow.

LOG:

23:30 Relocking and in MOVE_SPOTS
    23:40 Earthquake mode activated
23:48 NOMINAL_LOW_NOISE
    23:50 Observing
    00:10 Back to CALM
    01:40 Out of Observing due to SQZ unlocking
    01:43 Back into Observing
    01:47 Out of Observing due to SQZ unlocking
    01:50 Back into Observing
    01:56 Out of Observing due to SQZ unlocking
    02:31 Back into Observing
    02:32 Out of Observing due to SQZ unlocking
    03:16 Back into Observing
    03:17 Out of Observing due to SQZ unlocking
    03:29 Back into Observing
    03:29 Out of Observing due to SQZ unlocking
    03:45 Back into Observing
    03:51 Out of Observing due to SQZ unlocking
    03:57 Back into Observing
    03:59 Out of Observing due to SQZ unlocking
    04:03 Back into Observing
04:21 Lockloss
    - Manual initial alignment

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
23:41	FAC	Tyler	MX	n	Checking out the bees	00:41

OpsInfo, SQZ

Images attached to this report

H1 SQZ - Comment to Ops EVE Midshift Update

oli.patane@ligo.org — Wed, 18 Jun 2025 22:23:29 -0700

Author: oli.patane@ligo.org

Report ID: 85173

Regarding what Camilla said about the ASC being twice as loud during this time - it looks like that started earlier this morning (ndscope1) - before it would make sense if we were counting on my wind theory below being the cause, so my theory is probably incorrect. It looks like then something was changed prior to 06/18 16:50 UTC that is causing the differnce in the FC ASC, which may or may not be related to the FC unlocking issue.

Here is my wind theory - that is currently backed up by only a few data points - is that when the wind is blowing against the FCES at a specific angle above a certain speed, it wiggles FC2 more than it should. I kept seeing messages from SQZ_FC saying that FC2 is too noisy, and FC2 M1 DAMP IN P was twice as noisy as it was a day ago when I trended the pointing back. However, Camilla did note that the Yaw ASC signals were a bit large, so obviously that's the opposite dof from what I saw. Anyway, here's a quick trend back of a few days showing a correlation between the wind pointing in the direction almost perpendicular to the FCES, and the SQZ FC subsequently unlocking multple times while the wind is high (ndscope2)

Images attached to this report

H1 ISC - PR2 dither coupling VS BS spot position (Ibrahim, Elena, Sheila, Keita)

keita.kawabe@ligo.org — Wed, 18 Jun 2025 21:51:53 -0700

Author: keita.kawabe@ligo.org

Report ID: 85081

Summary:

Robert's alog 84015 shows that IFO beam hitting the [+X, +Y] side barrel/edge of the BS could be coupling to DARM somehow.

Out of curiosity, we scanned the BS spot position in YAW with 2mm steps from -6mm to +6mm (measured along the BS surface, -6mm being the closest to the [+X,+Y] side barrel) while dithering the YAW angle of PR2 at 31Hz, and measured the coupling from the dither to DARM in nominal low noise.

Expectation is/was that the coupling monotonically gets worse as the beam approaches the [+X, +Y] side, but we didn't see such a simple pattern. See the 1st attachment showing H1:LSC-DARM_IN1_DQ/PR2_M3_DITHER_Y_OUT TF at the dither frequency. There could be a minima at around +2mm position but there's no phase flip around that point. No clear conclusion here.

	-6mm (closest to the +X+Y side)	-4mm	-2mm	0mm	2mm	4mm	6mm (farthest from the +X+Y side)
amplitude [ct/ct]	2.3e-11	2.7e-11	2.84e-11	2.8e-11	1.9e-11	2.4e-11	2.8e-11
phase	-21.4deg	-18.5deg	-17.5deg	-16.8deg	-17.3deg	-15.9deg	-15.7deg

BS spot position and its (rough) calibration

The camera servo uses the centroid position of BS spot obtained from GigE camera image in raw pixels. Nominal spot position on BS is (230, 236) for (P, Y), which is given by H1:ASC-CAM_PIT1_OFFSET=-230, H1:ASC-CAM_YAW1_OFFSET=-236.

The camera is looking at BS from -X+Y direction (WBSC2 G8 viewport). Positive increase in YAW position, which appears as a shift towards the right for the camera, means the shift in -X-Y direction on the BS surface (i.e. away from +X+Y side of the BS).

The entire frame width (640 pixels) of the GigE image is very roughly the same with the diameter of the BS (370mm nominal), so the calibration of the camera image is 370mm/640pix. Using this, +2mm step is 2mm/(370mm/640pix) ~ 3.5 pixels.

BS spot steps were given by increasing/decreasing H1:ASC-CAM_YAW1_OFFSET by integer multiple of 3.5 pixels.

Note that BS is tilted by 45 degrees relative to X and Y axis, thus +2mm on the plot means [-sqrt(2),-sqrt(2)]mm in [X,Y] direction, respectively.

We started with 0mm offset, then proceeded with -2mm, -4mm, -6mm, +2mm, +4mm and +6mm in this order. After each step, we waited until the camera servo settle, measured the transfer function at the injection frequency, and proceeded to the next step.

After we were done, spot position was set back to 0mm offset.

Injection

We made an injection of 8 counts pp at 30Hz into H1:SUS-PR2_M3_DITHER_Y_EXC, which made a huge peak in DARM. Injection was active from ~19:03 UTC to 20:14 UTC on 2025/06/18.

A2L

Before we started injection and before we moved the BS spot position, Ibrahim ran A2L script to set the A2L gains for quads. All measurements, even after BS spot was moved, was done with these A2L gains (4th attachment), and Ibrahim put these gains in the guardian.

A2L measurement was done with +6mm offset after all of the measurents were done, too, as we might need that data later (5th attachment).

DTT template

It's in /ligo/home/keita.kawabe/BSPOS\ VS\ jitter\ 20250618.

REF0-1: no exc, ref2-5: 0mm offset, ref6-9: -2mm, ref10-13: -4mm, ref14-17: -6mm, ref18-21: +2mm, ref22-25 +4mm, ref26-29: +6mm.

Images attached to this report

H1 SQZ - Comment to Ops EVE Midshift Update

camilla.compton@ligo.org — Wed, 18 Jun 2025 21:43:01 -0700

Author: camilla.compton@ligo.org

Report ID: 85172

Oli and I checked that neither the FC beamspot control or FC ASC were running away or had signals any different than normal locked times. The ASC YAW signals had some slightly noisier times with FC_ASC_INJ_ANG_Y up to 0.003 rather than the max 0.002 earlier in the day. Oli noted that the wind had picked up during the locklossy time, maybe that is to blame.

FC beamspot control: locked time earlier today, locklossy period
FC ASC: locked time earlier today, locklossy period, some yaw signals noiser.

We thus don;t think there's reason to keep the FC beamspot control off but are leaving FC beamspot control off for tonight just incase as it's nearly the end of Oli's shift. It could be turned back on tomorrow AM.

Images attached to this report

H1 General - Lockloss

oli.patane@ligo.org — Wed, 18 Jun 2025 21:23:42 -0700

Author: oli.patane@ligo.org

Report ID: 85171

Lockloss at 06/19 04:21 UTC due to unknown causes

H1 SQZ - Comment to Ops EVE Midshift Update

oli.patane@ligo.org — Wed, 18 Jun 2025 20:58:23 -0700

Author: oli.patane@ligo.org

Report ID: 85170

Daniel, Oli

After trying to work on the alignment for the filter cavity (I tried following 72084 and wiki) and not being able to get the filter cavity to stay locked for more than a couple of minutes, I contated Daniel. He tracked down the FC beam spot control that Camilla and Sheila had turned on earlier today (85149), and we tried turning the inputs off to the H1:SQZ-FC_ASC_INJ_ANG_(P,Y) filter bank. The first SQZ lock after this lasted less than a minute, but the next one kept the filter cavity locked for a few minutes. We were unsure as to if this was the solution, but since it didn't lose lock right away, we might as well go back into Observing, so I accepted the SDFs of those inputs being off and we went back into Observing.

As I was writing this, the SQZer lost lock again, so this was not the solution. I let it relock on its own and that worked, and I let it keep the ASC_INJ filter inputs on and accepted those back into SDF since that isn't the issue.

H1 SQZ - Ops EVE Midshift Update

oli.patane@ligo.org — Wed, 18 Jun 2025 20:06:35 -0700

Author: oli.patane@ligo.org

Report ID: 85169

We are currently Locked and have been for over 3 hours. We've been dropping out of Observing a few timnes due to the FC unlocking, and a couple times it was able to relock itself, one time I had to adjust FC2, and currently I've been working on relocking it but I've been having trouble. I've adjusted FC2 to maximize flashes, I've trended back FC1 and FC2 to a time yesterday when the green trans was good based on the DAMP INMONs and now the M3 Witness channels, and none of that has worked. FC2 seems twice as noisy as usual in pitch and I'm wondering if that's affecting things? The wind is getting in the high 30s at M/EY?

Images attached to this report

H1 SEI - Comment to St0 to St1 feedforward on HAM1 ISI today

elenna.capote@ligo.org — Wed, 18 Jun 2025 18:19:24 -0700

Author: elenna.capote@ligo.org

Report ID: 85168

There is about an order of magnitude improvement in the CHARD P error signal between 10-20 Hz as a result of these improvements, comparing the NLN spectra from three days ago versus today. Fewer noisy peaks are also present in INP1 P. I included the CHARD P coherence with GS13s, focusing on the three DoFs with the most coherence: RX, RZ, and Z. The improvements Jim made greatly reduced that coherence. To achieve the CHARD P shot noise floor at 10 Hz and above, there is still some coherence of CHARD P with GS13 Z that is likely contributing noise. However, for the IFO, this is sufficient noise reduction to ensure that CHARD P is not directly limiting DARM above 10 Hz. I also compare the CHARD P coherence with OMC DCPD sum from a few days ago to today, see plot.

In terms of how this compares with our passive stack + L4C feedforward performance, I found some old templates where I compared upgrades to our HAM1 feedforward. I compare our ISI performance now with the passive stack, no L4C feedforward to ASC, and passive stack with the best-performance feedforward we achieved: the results. It's actually a pretty impressive difference! (Not related to the ISI seems to be a change in the shot noise floor- looks like the power on the REFL WFS may have changed from the vent.)

The coupling of CHARD P to DARM appears to be largely unchanged, so this generally means we are injecting about 10x less noise from CHARD into DARM. from 10-30 Hz.

Images attached to this report

H1 ISC - Two ~13 Hz ring up locklosses identified

elenna.capote@ligo.org — Wed, 18 Jun 2025 17:21:13 -0700

Author: elenna.capote@ligo.org

Report ID: 85167

Oli, Elenna

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

1434317297

1434276630

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

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

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

Lockloss

Images attached to this report

H1 General - Comment to Lockloss 21:28 UTC

oli.patane@ligo.org — Wed, 18 Jun 2025 16:52:06 -0700

Author: oli.patane@ligo.org

Report ID: 85166

23:50 Observing

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 16:47:34 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85165

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

IFO is LOCKING in OMC_WHITENING

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

Relevant alogs from commissioning:

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

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

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

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

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:22	SAF	LASER SAFE	LVEA	SAFE	LVEA is LASER SAFE \u0d26\u0d4d\u0d26\u0d3f( \u2022_\u2022)	15:37
14:31	FAC	Tyler	X1 Turnout	N	Forklift transport	17:31
14:54	FAC	Chris, Erik	Xarm	N	Beamtube work (quiet)	18:39
15:45	FAC	Christina	Optics Lab	N	Inventoryu	16:24
18:38	EPO	Camilla, SURFs, Kiet, Nellie	Rooftop	N	Gathering views	19:13
18:39	FAC	Tyler, Beekeper	X-arm	N	Bee Removal	22:39
18:58	3IFO	Betsy, LIGO India Team, Jason	MY	N	3IFO Fun, Jason back 19:25	19:59
18:59	3IFO	Rick, LIGO India Team	LVEA or Optics or PCAL Lab	?	? ? ? (operator not informed)	00:58
19:41	CAL	Tony	PCAL lab	LOCAL	TS Kagra kit serial numbers	21:37
19:52	CAL	Francisco	PCAL lab	LOCAL	Join Tony	21:37
21:27	TCS	Camilla, Matt	Optics Lab	Local	Tidy CO2 Table	22:27
23:41	FAC	Tyler	MX	n	Checking out the bees	00:41

H1 SEI - St0 to St1 feedforward on HAM1 ISI today

jim.warner@ligo.org — Wed, 18 Jun 2025 16:42:54 -0700

Author: jim.warner@ligo.org

Report ID: 85162

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

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

Images attached to this report

H1 CDS - DAQ DC0 crash

david.barker@ligo.org — Wed, 18 Jun 2025 16:42:35 -0700

Author: david.barker@ligo.org

Report ID: 85164

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

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

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

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

H1 General - Comment to Lockloss 21:28 UTC

elenna.capote@ligo.org — Wed, 18 Jun 2025 16:40:48 -0700

Author: elenna.capote@ligo.org

Report ID: 85163

This lockloss could have been caused by some ring up that appears to be at a frequency between 11-13 Hz in the LSC loops.

Here is the lockloss tool link: https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1434317297

Images attached to this report

H1 General - Ops Eve Shift Start

oli.patane@ligo.org — Wed, 18 Jun 2025 16:35:04 -0700

Author: oli.patane@ligo.org

Report ID: 85161

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

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

H1 General - Lockloss 21:28 UTC

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 16:16:51 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85160

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

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

Lockloss

H1 SQZ - Comment to SQZ ASC and FC beamspot control back on

camilla.compton@ligo.org — Wed, 18 Jun 2025 14:13:34 -0700

Author: camilla.compton@ligo.org

Report ID: 85159

SQZ ASC was running away at the start of the lock so I've turned SQZ ASC off again.

I tried re-measureing the sensing matrix, the result was different to that measrue in September 80373 with the YAW sensor swapped (see output of /sqz/h1/scripts/ASC/python AS42_sensing_matrix_cal.py below) but when I tried it later the sensing matrix seemed to be different, I expect you need to start in good squeezing for it to work well which we were not when I tried it.

Plan to remeasure the sensing matrix more carefully (as in 80373) and then try a new one again.

Also tried today the SQZ_ANG_ADJUST servo using ADF, as the ASC was running away this was confusing, left off.

Using ZM4 and ZM6.

PIT Sensing Matrix is:

[[-0.0006984 -0.0011916]

[ 0.00143 0.001 ]]

PIT Input Matrix is:

[[ 994.44305222 1184.97834103]

[-1422.05356468 -694.51902767]]

YAW Sensing Matrix is:

[[-0.0031535 0. ]

[ 0. -0.00165 ]]

YAW Input Matrix is:

[[-317.10797527 -0. ]

[ -0. -606.06060606]]

H1 General - Some observe SDF diffs reverted

elenna.capote@ligo.org — Wed, 18 Jun 2025 14:07:32 -0700

Author: elenna.capote@ligo.org

Report ID: 85158

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

ISC, OpsInfo

Images attached to this report

H1 General - Comment to A2L All Run

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 13:46:47 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85157

These values have been added to ISC_LOCK.py (screenshot of specific gains attached).

Images attached to this report

H1 ISC - DC6 P does not contribute noise to DARM

elenna.capote@ligo.org — Wed, 18 Jun 2025 11:57:57 -0700

Author: elenna.capote@ligo.org

Report ID: 85156

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

At a later time I will check DC6 Y.

Images attached to this report

H1 General - A2L All Run

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 11:47:23 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85155

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

Images attached to this report

LHO VE - Wed CP1 fill

david.barker@ligo.org — Wed, 18 Jun 2025 10:23:08 -0700

Author: david.barker@ligo.org

Report ID: 85154

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

Images attached to this report

H1 SEI - H1 ISI CPS Noise Spectra Check - Weekly

anthony.sanchez@ligo.org — Wed, 18 Jun 2025 09:49:17 -0700

Author: anthony.sanchez@ligo.org

Report ID: 85153

H1 ISI CPS Noise Spectra Check - FAMIS 26048

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

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

Non-image files attached to this report

CPS_spectra_09:40-06_18_2025.pdf

H1 AOS - SQZ ASC and FC beamspot control back on

camilla.compton@ligo.org — Wed, 18 Jun 2025 09:39:33 -0700

Author: camilla.compton@ligo.org

Report ID: 85149

Sheila, Camilla

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

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

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

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

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

Images attached to this report

H1 CDS - h1guardian1 rebooted to fix AWG issue

david.barker@ligo.org — Wed, 18 Jun 2025 09:07:57 -0700

Author: david.barker@ligo.org

Report ID: 85152

Jonathan, Erik, Dave, Ibrahim, Tony:

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

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

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

H1 General - Locklosss 14:56

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 09:06:47 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85151

Unknown cause lockloss

However our two guesses are:

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

Lockloss

H1 CDS - New HAM1 vacuum gauge PT100_MOD2 added to MEDM and FOM

david.barker@ligo.org — Wed, 18 Jun 2025 08:59:58 -0700

Author: david.barker@ligo.org

Report ID: 85150

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

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

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

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

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Wed, 18 Jun 2025 07:33:45 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85148

TITLE: 06/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 11:57 UTC

Looks like we were able to recover from a 5.8 Mexico quake fully automatically last night.

H1 General - Ops Eve Shift End

oli.patane@ligo.org — Tue, 17 Jun 2025 22:04:19 -0700

Author: oli.patane@ligo.org

Report ID: 85147

TITLE: 06/18 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Currently Observing at 145 Mpc and have been Locked for almost 2 hours.Everything looking good.

Two hours into our previous lock, our range was slowly dropping and we could see that SQZ wasn't looking very good, and trending back the optic allignments Camilla saw that ZM4 and ZM6 weren't where they were supposed to be because the ASC hadn't been offloaded before all the updates earlier today(ndscope1). To fix this, we popped out of Observing and turned on the SQZ ASC for three minutes, which made the sqzing better(ndscope2)! This better sqzing has persisted to this next lock stretch.

After the 01:30 lockloss (85145), I sat in DOWN for a couple minutes while restarting a few Guardian nodes since awg was restarted earlier today and this should help with the guardian node error (like in 85130) (these are the ones I could think of that probably all use awg): ALS_{X,Y}ARM, ESD_EXC_{I,E}TM{X,Y}, SUS_CHARGE, PEM_MAG_INJ Tagging Guardian

LOG:

23:30 Observing and have been Locked for over 1 hour
00:24 Popped out of Observing quickly to run the SQZ ASC for a few minutes
00:27 Back into Observing
01:30 Lockloss
    - Sat in DOWN for a couple minutes while I restarted some Guardian nodes
    - We ended up in CHECK_MICH_FRINGES but that didn't help, so I started an IA
03:05 NOMINAL_LOW_NOISE
03:08 Observing

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:22	SAF	LASER SAFE	LVEA	SAFE	LVEA is LASER SAFE ദ്ദി( •_•)	15:37
20:49	ISS	Keita, Rahul	Optics lab	LOCAL	ISS array work (Rahul out 23:45)	00:28

GRD

Images attached to this report

H1 General - Comment to Lockloss

oli.patane@ligo.org — Tue, 17 Jun 2025 20:44:33 -0700

Author: oli.patane@ligo.org

Report ID: 85146

03:08 Observing

H1 General - Lockloss

oli.patane@ligo.org — Tue, 17 Jun 2025 18:49:03 -0700

Author: oli.patane@ligo.org

Report ID: 85145

Lockloss @ 06/18 01:30 UTC

Lockloss

H1 SUS - Comment to Excessive movement in ITMY may have been caused by bad IPC table in OMC0

erik.vonreis@ligo.org — Tue, 17 Jun 2025 17:50:56 -0700

Author: erik.vonreis@ligo.org

Report ID: 85144

ITMX, which received the same clobbered channel as ITMY, also showed a spike in movement during the same period, but was properly stilled by guardian.

Images attached to this report

H1 SUS - Comment to Excessive movement in ITMY may have been caused by bad IPC table in OMC0

erik.vonreis@ligo.org — Tue, 17 Jun 2025 17:37:50 -0700

Author: erik.vonreis@ligo.org

Report ID: 85143

The attach list shows the mapping from OMC0 IPCs to IPCs that were clobbered during the ten minutes OMC0 was running on the wrong IPC table.

Non-image files attached to this report

omc_chan_clobber.txt

H1 CDS - Comment to DAQ restart of PSLDBB and EDC restart for Vacuum LX PT100 and digivideo CAM37 additions (and some removals)

david.barker@ligo.org — Tue, 17 Jun 2025 17:28:23 -0700

Author: david.barker@ligo.org

Report ID: 85142

Detailed list of DAQ channel changes (9097 additions, 91 removals)

Non-image files attached to this report

daqchange_17jun2025.txt

H1 CDS - DAQ restart of PSLDBB and EDC restart for Vacuum LX PT100 and digivideo CAM37 additions (and some removals)

david.barker@ligo.org — Tue, 17 Jun 2025 17:20:13 -0700

Author: david.barker@ligo.org

Report ID: 85141

The DAQ was restarted for a second time today at 12:41 (0-leg) and 12:50 (1-leg) for three reasons:

1) h1psldbb had a bad DAQ status following model change at 09:15 to remove an IPC sender

2) H0EPICS_VACLX.ini has new PT100 HAM1 gauge channels

3) H1EPICS_DIGVIDEO.ini has new CAM37 ISCT1-REFL channels (camera was added recently)

I regenerated H1EPICS_DIGVIDEO.ini using generate_camera_daq_ini.py, which correctly added CAM37 channels as a new server machine, but reverted CAMs[21, 23, 24, 26] back to "old" server settings. Remember these cameras were moved to a new server, but lack of masking forced them back to the old server (digivideo2). At this point the EDC was expecting a new set of channels, so as a work around I built a dummy ioc to simulate these channels to keep EDC happy. So to make a long story short, these cameras are back with their original PV set and digivideo_dummy_ioc is no longer needed. To test this I shut down the IOC with no loss of EDC connections, and verified tha the Guardian CDS_COPY "from" list was still functioning.

H1 OpsInfo - Instructions for running DARM offset step to do output loss meas

jennifer.wright@ligo.org — Tue, 17 Jun 2025 16:57:26 -0700

Author: jennifer.wright@ligo.org

Report ID: 85136

To run the test that calculates how much loss we have between the ASC-AS_C (anti-symmetric port) and the DCPDs at the output of the OMC (where strain is derived from).

This test is set up to run in NLN.
Turn off OMC ASC. Go to sitemap -> OMC -> OMC Control and note down the MASTER GAIN value in circled section in attached photo, then change this value to 0.
Go to /ligo/gitcommon/labutils/darm_offset_step and run:

conda activate labutils

python auto_darm_offset_step.py

The script turns on one notch in the DARM LSC loop, then changes the PCAL line heights so all the power is in just two frequencies.

At the end it reverses both these changes.

It can be stopped using Crtl-C but this will not restore the PCAL line heights back to their default values so you may have to use time machine.

After setting up the PCAL the script steps the DARM offset level in 120 s steps, I think it takes about 21 minutes to run.

After the script finishes, please put the OMC ASC MASTER GAIN back to its original value.

ISC

Images attached to this report

H1 General - Ops Eve Shift Start

oli.patane@ligo.org — Tue, 17 Jun 2025 16:39:53 -0700

Author: oli.patane@ligo.org

Report ID: 85140

TITLE: 06/17 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

We are Observing and have been Locked for almost 1.5 hours. SQZ doesn't look good, so I might pop out of Observing in another hour to run sqz scan align. Also, if we lose lock I will be restarting a couple guardian nodes that use AWG since that was restarted earlier today, and we've already had one awg error pop up in ALS_YARM (85130).

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Tue, 17 Jun 2025 16:38:47 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 85137

TITLE: 06/17 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 140Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 22:26 UTC

TUES Maintenance Activities:

We had a very productive maintenance day during which the following was completed

LVEA Laser SAFE Transition - OPS
RCG Upgrade and misc CDS work - CDS
- WP 12624, WP 12625, WP 12626, WP 12627
- Alog 85120,
VAC Channel Work - CDS
- Alog 85134
Anchor drill work - VAC
Laser Curtains around HAM1 replaced
- Alog 85125
Gauge replacement prep - VAC
ISCT7 Poke Homodyne - ISC
- Alog 85116
HAM ISI Measurements - SEI -
FAC Work (Bees, Tech Cleaning, Inventory, Lifts, Monitors)
3IFO Visit Support - 3IFO
- WP 12628

LVEA was swept - alog 85128

*Only listing completed WP’s - close your permits if work is done.

Lock Reacquisition:

Lock recovery was quite rough due to a few issues

ITMY Oscillation - Whilst locking ALSY, we noticed that it was oscillating at ~3Hz. No alarms had sounded other than the CDS/Maint work’s ISI/SUS trips expected earlier in the morning that were since successfully reverted. Ryan C discovered that the L1 BOSEMs were also oscillating independently of ALS WFs (which was the initial hypothesis). Then we found a worrying increase in the IY reaction chain gain (which showed an apparent increase of a few ten thousand!). This appears to have started when the CDS upgrade was done even though the right values were save into the SDF SAFE files. CDS advised that any signals from this time are not to be trusted, but clearly something must have moved since the 3Hz signal we were still getting was still ringing (albeit ringing down for the last 3 hrs). We managed to find the appropriate filter banks, IY_R0_L2DAMP_R_GAIN and IY_R0_L2DAMP_P_GAIN and identified them as the culprits, turning them off. After the involvement of Ryan C, Tony, Sheila, Elenna, Keita, Jonathan, Dave, EJ, Oli and myself, we came to the conclusion that we were going to test turning on the gain (nominally set to 1.5 and -2.5 not 10k) with a ramp. We did this and there were no issues. Weird. So essentially CDS is saying that there was no gain and power cycling the gain fixed the IY motion which was seen IY L2, IY L1 OSEMs as well as ALSY during ALS. Elenna still thinks something is weird with IY Reaction Chain so is investigating. Picture of Tony’s IY Power Spectrum Below. (alog 85135)
ALS Y Fault during ScanAlign. ALSY Faulted during scan-align causing a guardian node error. I had to manual out to continue locking. This is now a known issue whereby ALS scan align (not specific to X or Y) fails due to an AWG issue. The SUSCHARGE and ALS guardians will be restarted by Oli once we have our next Lockloss. (alog 85130)
IMC Locking Issues. The CDS work today threw the IMC out of alignment so we had to move MC1, MC2, MC3 and PZT sliders to a time where we were successfully auto-locking.
SEI states, PSL and SUS were all transitioned to their SAFE (Safe State Transition Wiki) and then transition out (Safe State De-transition Wiki)
SDF Screenshots Linked

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:22	SAF	LASER SAFE	LVEA	SAFE	LVEA is LASER SAFE \u0d26\u0d4d\u0d26\u0d3f( \u2022_\u2022)	15:37
15:07	FAC	Kim, Nellie	LVEA	N	Technical Cleaning	16:12
15:40	VAC	Jordan, Gerardo	LVEA	N	Anchor Drill work	17:31
15:42	OPS'	Camilla	LVEA	N	Laser SAFE transition, ISCT1 check	16:14
15:42	3:00	Christina	LVEA	N	Walkabout	17:08
16:05	FAC	Randy	LVEA	N	Inventory	20:49
16:12	FAC	Kim	EX	N	Technical Cleaning	17:58
16:13	FAC	Nellie	EX	N	Technical Cleaning	17:15
16:19	PSL	Jason	LVEA	N	PSL Inventory + Cable pull	17:08
16:23	3IFO	Betsy, Mitchell, LIGO India Delegation	LVEA	N	Tour, 3IFO Walkabout + Rick	18:20
16:28	VAC	Richard	LVEA	N	Check on vac	18:48
16:30	AOS	Jennie	Optics Lab	Local	ISS Array	17:21
16:42	ISS	Kieta	Optics lab	Local	Joining Jennie W in he optics lab	19:15
16:43	CDS	Erik	Remote	N	Restarting EndX IOC	16:53
16:57	EE	Fil	LVEA & Both Ends	N	Looking for Scopes & Talkign to Richard.	18:55
17:08	FAC	Christina	End stations	N	Getting Pictures of hardware	18:25
17:13	ISC	Sheila, Matt, Camilla	LVEA	N	ISCT1 Laser Panels	17:41
17:27	Bee	Tyler	LVEA	N	Being a Busy Bee keeper and intercepting Betsy	17:35
17:27	ISS	Rahul	Optics Lab	Local	Helping Keita with ISS work	19:15
17:28	ISS	Jennie W	Optics Lab	Local	Working on ISS with Keita	19:15
17:42	ISC	Camilla	ISCT table	N	ISCT table work	17:58
17:44	PEM	Ryan C	LVEA	n	Checking Dust mons	18:18
17:45	VAC	Gerardo	Mid & EY	N	Guage replacements	18:56
17:58	FAC	Nellie, Kim	FCES	N	Technical Cleaning	18:32
18:20	3IFO	Mitchell, Jim, 3IFO team member	LVEA	N	3IFO inventory check	18:23
18:25	3IFO	Brijesh, Jim	LVEA	N	3IFO Inventory	18:43
18:34	TCS	Camilla	LVEA	N	TCS Part Search	18:45
18:57	VAC	Gerardo	LVEA	N	Vac Gauge Reconnection	19:06
19:58	OPS	Tony	LVEA	N	Sweep	20:49
20:49	ISS	Keita, Rahul	Optics lab	LOCAL	ISS array work	22:55
20:58	FAC	Chris	EX, MX	N	Air handler checks	22:12
21:11	PSL	Rick, 3IFO Delegation	PSL Anteroom	N	PSL Anteroom Tour	22:06
21:21	ISS	Jennie W	Optics lab	Local	Working on ISS system	22:51

Images attached to this report

LHO VE - Comment to new Kobelco installation complete

janos.csizmazia@ligo.org — Tue, 17 Jun 2025 16:37:45 -0700

Author: janos.csizmazia@ligo.org

Report ID: 85138

And here is the filter element, in an absolutely ridiculous condition, as Travis described it.

Images attached to this report

H1 CDS - Comment to RCG5.5.0 completed 09:51

david.barker@ligo.org — Tue, 17 Jun 2025 16:37:27 -0700

Author: david.barker@ligo.org

Report ID: 85139

Here is a rough squence of today's upgrade, all times local PDT

07:22 rebuild H1EDC.ini to convince outselves the first DAQ restart will be model changes only

07:43 h1cdsrfm powered down, this breaks the linkage between Dolphin locations

07:43 h1ecatmon0 upgrade (reboot)

07:45 Dolphin network manager started on h1vmboot5-5, causing the standard set of end station systems to crash (susey, seiey, iscey and susex). We PAUSE'd the remaining EX (iscex, seiex)

07:51 Reboot h1susaux[ex, ey, b123, h2, h34, h56] pem[mx, my] to upgrade them. susaux[h34, ey] got stuck and were power cycled via IPMI.

08:03 DAQ 0-leg restart for new INI files across the board.

08:18 DAQ 1-leg restart. At this point omc0, susaux's and pemmid have good DAQ data, everyone else has BAD DAQ data.

08:27 Power down EX machines, power up EY machines. SWWD IPCs working, Dolphin IPC checks out.

08:32 Power up EX machines, all at the same time because of the Dolphin switch issue. They do not start. After some head scratching we remembered that the startup sequence needs to activate a dolphin switch port, which cannot happen at EX because the switch is damaged. Work around is for all three EX front ends to switch an unused port on the EY switch. Once this was put into place the EX machines started without anyone having to drive to the end station.

08:55 Reboot h1psl0 to upgrade PSL models (no dolphin cards, more about this later...)

08:56 Power down all non-upgraded corner station machines (SUS+SEI+ASC+LSC+OAF) but not h1omc0 (more about this later..)

09:00 h1psldbb is not running. It has an obsolete Dolphin IPC sender part in the model but no Dolphin card. RCG5.5.0 does not allow this. Rebuild model sans IPC part, starts running. Note PSLDBB DAQ data is BAD from this point till the second DAQ restart.

09:10 First power up h1sush2b, h1seih16 for HAM1 SEI work. SWWD IPC between the two working well (well, for these two, more later...)

09:20 Power up all remaining corner station computers

09:30 Discover wierd SWWD IPC receive values for HAM3 and HAM4 (val should be 1.0, but is -0.002 or 0.000).

09:34 try restart h1iopsush34, IPC values still bad. But h1omc0 has not been restarted so its using the old IPC configuration and could be writing out-of-bounds

09:35 restart h1omc0 models, SWWD IPC errors are resolved

09:44 power up h1cdsrfm. First EX is PAUSE'd, EY and CS are fenced. long range dolphin starts with no issues. A new MEDM is generated from the new H1.ipc file.

09:51 Complete in 2 hours.

H1 SUS - Excessive movement in ITMY may have been caused by bad IPC table in OMC0

erik.vonreis@ligo.org — Tue, 17 Jun 2025 16:12:07 -0700

Author: erik.vonreis@ligo.org

Report ID: 85135

Trend of H1:IOP-SUS_ITMY_WD_OSEM1_RMSOUT shows increased motion during the 10 minutes post-RCG upgrade that OMC0, see alog 85120, was clobbering IPCs, including two peaks.

The attached screenshot has cursors at the approximate start and end of OMC0 clobbering IPCs. RMS remained high until guardian was started 30 minutes later, after which ITMY continued to ring until guardian was again restarted.

We will attempt to trace the clobbered IPCs to see if they plausibly could have driven ITMY.

CDS

Images attached to this report

H1 CDS - Updates to h0vaclx and addition of the HAM1 PT100 BCG552 EtherCAT gauge

patrick.thomas@ligo.org — Tue, 17 Jun 2025 15:59:12 -0700

Author: patrick.thomas@ligo.org

Report ID: 85134

WPs: 12577 and 12608 Previous work: alog 84871 This portion of the first work permit has been completed: "Migrate h0vaclx from the svn repo to the git repo. Also migrate it from using the C# code to the PowerShell code for generating the TwinCAT 3 Visual Studio solution. This would make it match h0vacmr and h0vacly in both of these regards. Update the PLC code on h0vaclx to add PT100 as an Inficon BCG552 gauge." The installation of TwinCAT 3 on h0vaclx has been updated to version 3.1.4024.35. The PowerShell script to generate the TwinCAT 3 solution has been changed to use the TwinCAT XAE Shell instead of Visual Studio 2010 because I could not get it working with the latter. The new Inficon BCG552 EtherCAT gauge on HAM1 is connected and being read into EPICS. The code being used for the scripts is at commit d27c3ebfb424572f3aba003744e97e947e5a4873 in the git repo at https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum. The shortcut in the TwinCAT autostart folder to start the EPICS IOC has been updated to point to the location of the checkout of this repo. The shortcut on the Desktop has similarly been updated. Timeline of work: 9:56 Stopped the EPICS IOC. Set the TwinCAT runtime to Config. Started the installer for TwinCAT 3.1.4024.67. 10:02 A Windows Security dialog message appeared three times: "Windows can't verify the publisher of this driver software". Clicked "Install this driver software anyway" each time. The installer took a very long time on "Installing Microsoft .NET Framework 5.6.1 Full". 10:22 The computer spontaneously logged me out during the installation. 10:24 Logged back in. 10:26 I started the installation of TwinCAT 3.1.4024.67 again and then soon canceled it. 10:35 I started the installer for TwinCAT 3.1.4024.35. 10:50 I restarted the computer to complete the install as prompted. 10:52 Logged back in. The installation appeared to be successful. I tried to generate the TwinCAT 3 solution from the scripts. I could not find a way around an error saying that the project template could not be found, despite it being at the path shown. 11:19 I ran 'shutdown /r' to restart the computer and try again but still got the same error about the template after the restart. I changed the script to use the TwinCAT XAE Shell instead of Visual Studio 2010. The script froze. I logged out and back in. The script succeeded in generating the solution. I scanned for terminals and did not see the BCG552 gauge on HAM1. Gerardo told me it was not connected and went to connect it. The gauge showed up and everything appears to be working. I updated the paths in the scripts for the IOC and the shortcuts to start the IOC. I checked in all of the changes to git. CDS, VE

Images attached to this report

H1 SUS - Roll Mode T ramp set in guardian, accepted in SDF

elenna.capote@ligo.org — Tue, 17 Jun 2025 15:27:56 -0700

Author: elenna.capote@ligo.org

Report ID: 85132

We keep having some SDF observe diff for the roll mode damping gain ramp time. I added a line to the DAMP BOUNCE ROLL guardian state to set the gain to 10 seconds when the gain is set. Apparently we've been engaging the damping with no gain ramp. Hopefully this observe diff will stop popping up now.

Images attached to this report

H1 GRD - Comment to ALS-YARM Guardian issue in Scan Alignment.

anthony.sanchez@ligo.org — Tue, 17 Jun 2025 14:32:45 -0700

Author: anthony.sanchez@ligo.org

Report ID: 85131

Seems similar to this Alog From Oli.

H1 GRD - ALS-YARM Guardian issue in Scan Alignment.

anthony.sanchez@ligo.org — Tue, 17 Jun 2025 14:31:08 -0700

Author: anthony.sanchez@ligo.org

Report ID: 85130

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

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

Error Log:

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

GRD

H1 General - LVEA has been swept

anthony.sanchez@ligo.org — Tue, 17 Jun 2025 13:06:47 -0700

Author: anthony.sanchez@ligo.org

Report ID: 85128

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

H1 AOS - Comment to Violin mode contaimination near 500Hz: possible mixxing between the 2nd harmonic (near 1500 Hz) and the 1st harmonic (near 1000 Hz)

kiet.pham@ligo.org — Tue, 17 Jun 2025 12:45:31 -0700

Author: kiet.pham@ligo.org

Report ID: 85127

Adding plot comparing the PSDs before and after getting rid of the peaks that can be indentified by this method.

DetChar, SUS

Images attached to this report

H1 ISC - Quick Info about the AWGLines guardian

elenna.capote@ligo.org — Tue, 17 Jun 2025 12:03:16 -0700

Author: elenna.capote@ligo.org

Report ID: 85126

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

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

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

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

H1 ISC - Laser Curtains around ISCT1/IOT2L replaced

camilla.compton@ligo.org — Tue, 17 Jun 2025 11:29:16 -0700

Author: camilla.compton@ligo.org

Report ID: 85125

Sheila, Matt, Camilla

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

H1 CDS - Comment to RCG5.5.0 completed 09:51

david.barker@ligo.org — Tue, 17 Jun 2025 11:20:48 -0700

Author: david.barker@ligo.org

Report ID: 85124

Images attached to this report

LHO VE - Tue CP1 Fill

david.barker@ligo.org — Tue, 17 Jun 2025 11:08:13 -0700

Author: david.barker@ligo.org

Report ID: 85123

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

Images attached to this report

H1 PEM - Comment to DustMon Monthly Trends

ryan.crouch@ligo.org — Tue, 17 Jun 2025 10:20:13 -0700

Author: ryan.crouch@ligo.org

Report ID: 85122

LVEA5 being off is expected, it's a pumped dust monitor so we turned it off for observing.

LHO VE - new Kobelco installation complete

travis.sadecki@ligo.org — Tue, 17 Jun 2025 10:11:46 -0700

Author: travis.sadecki@ligo.org

Report ID: 85121

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

Images attached to this report

H1 CDS - RCG5.5.0 completed 09:51

david.barker@ligo.org — Tue, 17 Jun 2025 10:01:49 -0700

Author: david.barker@ligo.org

Report ID: 85120

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

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

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

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

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

Images attached to this report

H1 ISC - Comment to Update to MOVE_SPOTS to speed things up

elenna.capote@ligo.org — Tue, 17 Jun 2025 09:58:27 -0700

Author: elenna.capote@ligo.org

Report ID: 85119

To be more specific, the first attempt as described above meant the state took 6 minutes, 50 seconds. I loaded the change to reduce the wait time from 120 to 90 seconds, which only shortened the state length to 6 minutes, 30 seconds. The gain was only ramped to 8 for a very short period of time. I still think we can make this shorter, which we can do by making that wait time 60 seconds, and maybe taking bigger steps in the gain each time. However, we are still in the RCG upgrade, so I will hold off on changes to the guardian for now.

YAW3 is still limiting the length of the state. In this morning's relock, YAW3 convergence took nearly an additional minute more than the other loops. Once we have caught YAW3 up to everything else, we could make the state even shorter by raising the gain of other ADS loops. Two minutes of the state are taken up in the ramp of the A2L gain, so it is taking an additional 4 minutes, 30 seconds to wait for loop convergence.

H1 GRD - Comment to THERMALIZATION guardian edited and put into use for SRCL1 offset stepping

elenna.capote@ligo.org — Tue, 17 Jun 2025 09:37:18 -0700

Author: elenna.capote@ligo.org

Report ID: 85118

This shows the entire lock using the thermalization guardian with the SRCL offset ramping from -200 to -455, The line uncertainty holds steady the entire time within 2-3%!

Images attached to this report