aLIGO LHO Logbook

H1 ISC - Comment to Thursday locking: achieved 65W input power.

keita.kawabe@ligo.org — Fri, 13 Nov 2026 11:26:25 -0800

Author: keita.kawabe@ligo.org

Report ID: 92720

Last lock loss from 65W lock at around Nov/13/2026 00:55:18 UTC was due to 2.1Hz oscillation visible in OMC DCPD, LSC-MICH and ASC-DHARD_Y among others. (OMC trans camera was pulsating REALLY strongly it was kind of nerve wracking.)

The third plot shows how 2.1Hz got noticable at 50W into JAC, but really started ringing up after reaching 60W.

Images attached to this report

H1 TCS - Comment to Thursday Ops EVE Report

louis.dartez@ligo.org — Fri, 13 Nov 2026 11:15:30 -0800

Author: louis.dartez@ligo.org

Report ID: 92728

BTW I uncommented the grd lines left behind by TJ (92711) to turn off central CO2 heating at 25W ... so for the lockloss from 65W noted here by Tony the CO2 central heating should have been toggled off when we hit 25W.

H1 IOO - Hunting for JAC ASC glitches

jennifer.wright@ligo.org — Fri, 13 Nov 2026 10:46:17 -0800

Author: jennifer.wright@ligo.org

Report ID: 92727

Tony left JAC unlocked betwen 04:06:11 UTC and 15:35:44 UTC while the IFO was in IDLE last night so we can look for glitches on the PSL PZT mirror. The yaw of this mirror is H1:JAC-PZT_YAW_OUTPUT and the tilt is H1:JAC-PZT_PIT_OUTPUT.

During this period I didn't see any onvious large height glitches around 100 ms.

There were two mode flashes in the cavity at 08:17:56 UTC and 13:35:19 UTC which caused dips/crests on the WFS as expected, but I couldn't find any unexplained gitches on the WFS or on the PZT drive to the JAC length as in previous examples. It is very hard to see these 100ms gltiches in long 11 hour stretches of data though so I might do some spectrograms of this data to double check.

Images attached to this report

H1 CDS - NDS0 restarted, using temporary minute trend location while they are being offloaded

david.barker@ligo.org — Fri, 13 Nov 2026 09:17:50 -0800

Author: david.barker@ligo.org

Report ID: 92726

WP13756 TW0 Offload

As the first part of the offload of the last 6 months of raw minute trend data from TW0 I reconfigured h1daqtw0 to write to a new empty directory at 08:10. This freezes the minute_raw_1478621118 area in preparation for file copy.

After we lost lock at 09:05 I restarted NDS0, which is configured to serve data from this temporary location.

H1 SPI - Comment to SPI status guardian and SPI control guardian update

jason.oberling@ligo.org — Fri, 13 Nov 2026 08:54:53 -0800

Author: jason.oberling@ligo.org

Report ID: 92725

Some notes on the FSS behavior Jennie discusses above.

From the trends Jennie posted this, to me, looks like a normal RefCav relock sequence and not a series of oscillations. The FSS Oscillating tag should not be used when the RefCav is unlocked, which it is during the majority of this sequence, as the normal behavior of the autolocker can trigger the tag even though the loop is not oscillating. It does oscillate briefly at the beginning when the IMC unlocks; this does sometimes happen, depending on how hard the IMC unlock kicks the FSS. It looks like the IMC tries to relock but for some reason IMC_F, the IMC feedback into the FSS, does not settle out and the FSS starts oscillating, then unlocks completely.

The autolocker then begins to reacquire RefCav lock, as seen by the FSS_FAST channel (this is the signal sent to the PZT in the NPRO laser, that is mounted on the NPRO crystal itself) going to its max value and the NPRO crystal temperature search starting up. During this relock sequence the FSS does not oscillate at all, as seen by the FSS_FAST channel remaining flat; when the loop does oscillate the FSS_FAST channel will also oscillate, as seen at the beginning of the relock sequence shortly after IMC unlock. What is happening here is the FSS autolocker is trying and failing to lock onto a 00 mode; when this happens the peak-to-peak voltage of the FSS PDH Mixer, which is the channel we monitor to check for FSS oscillations and is not shown on the trends, can increase above the oscillation threshold (which I think is either 0.4 or 0.5 V) as it tries to lock the RefCav, which then activates the FSS Oscillating tag. This, however, is NOT an FSS oscillation; again, the FSS_FAST channel does not oscillate. The autolocker attempts to lock the RefCav a few times, as seen by the FSS_TPD channel, and when it finally does catch a 00 mode the autolocker smoothly transitions through its states to state 4, RefCav Resonant. I should note that the FSS does ocassionally start oscillating upon initial RefCav lock, which can, but doesn't always, trigger the state 2 -> 3 -> 4 loop I discuss in my comments to alog 88087. That did not happen in this case.

H1 ISC - DRMI buzzing in DRMI_LOCKED state, removed bandstops from PRM

sheila.dwyer@ligo.org — Fri, 13 Nov 2026 08:43:03 -0800

Author: sheila.dwyer@ligo.org

Report ID: 92724

This morning DRMI mode hopping is quite bad, probably because the microseism combined with the length to pitch decoupling on the BBS not being ideal.

A trick to get around DRMI mode hopping is to go into the ISC_DRMI guardian, and request ACQUIRE_DRMI_1F instead of DRMI_LOCKED. This prevent the mode hopping offset and some filter changes and boosts from happening, and gives us a chance to align DRMI better by hand while it stays locked.

Ibrahim and I stepped through DRMI_LOCKED state line by line to see which filters cause the instability when we are mode hopping.

The line that turns on PRM M3 ISC_INF FM3 seems to cause the loud buzzing when we are mode hopped, with this filter off DRMI can swing between positive and negative POP90 without instability. So, we have commented this out for now. It is series of bandstops from 270-430Hz.

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Fri, 13 Nov 2026 07:32:44 -0800

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 92723

TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 2mph Gusts, 0mph 3min avg
Primary useism: 0.07 μm/s
Secondary useism: 0.63 μm/s
QUICK SUMMARY:

IFO is in IDLE

Secondary microseism is on the rise. I'm starting with an initial alignment.

H1 General - Thursday Ops EVE Report

anthony.sanchez@ligo.org — Thu, 12 Nov 2026 20:08:36 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92722

TITLE: 11/13 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
I aquired H1 during a very exciting time! We got up to Low_Noise_Coil_Drivers[552]!

We lost lock shortly there after, BUT I was able to get back to Max power for another 20 minutes!
Lockloss table:

7: 2026-11-13_01:19:38Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
6: 2026-11-13_01:32:14Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
5: 2026-11-13_01:45:11Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
4: 2026-11-13_02:57:38Z ISC_LOCK MAX_POWER -> LOCKLOSS <<<< ------------OH Yeah MAX Powa !!!
3: 2026-11-13_03:11:40Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
2: 2026-11-13_03:23:34Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS_DRMI
1: 2026-11-13_03:44:02Z ISC_LOCK POWER_10W -> LOCKLOSS
0: 2026-11-13_03:56:29Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS

H1 SPI - SPI status guardian and SPI control guardian update

jennifer.wright@ligo.org — Thu, 12 Nov 2026 18:52:17 -0800

Author: jennifer.wright@ligo.org

Report ID: 92721

Jennie W, Jim W, Jeff K,

After checking recent trips of the ISIs which were caused by the frequency stabilisation servo going into a oscillation state (see this alog 92603 from Jeff).

And following on from Jim and I's work this morning in this comment (LHO alog ), J^3 agreed on some updates to the logic for the guardians.

The FSS autolocker sometime only goes into oscillation sor short periods which are too fast for SPI to notice much deviation. If the FSS loses lock however, the autolocker can get stuck trying to re-lock and will tune the PSL temperature. Sometimes during this process the REF Cav also loses lock.

Both of these latter things cause large phase excursions in the SPI that can be less than a second.

We want the SPI status guardian to not only show a fault if the FSS is oscillating but also check that the auto-locker has re-locked properly (see Jason's comment in above linked alog) before we report the SPI as being 'READY' again in the stat guardian.

The SPI control guardian (which brings the SPI back to nominal if the SPIH23_STAT guardian shows a fault) will wait for the SPI stat guardian to be in state 'READY' and then it will do some extra checks on the HAM3 blend epics channels to check that we have already changed to a two part blend (CPS/GS13), and that the ramp time left on the blend transtion is 0.

Once these two conditions are met the SPI control guardian will reset the phase. Therefore I think we want the blend guardian to look at SPIH23_CTRL guardian when deciding to use a three part blend and not the SPIH23_STAT guardian as this ensures we don't try to change the blend before we reset the phase.

I have loaded the updated code with these changes to the guardian state machine and saved them in the svn is userapps/spi/common. I did the reload just before 01:48 UTC on both guardians.

As I was writing this alog the IFO unlocked and the FSS started oscillating (SPI is not in loop currently). The control node flipped between FSS FAULT state and READY quite a few times even though the state node reported 'PHASE_BAD' before the FSS settled so I probably need to correct some logic (see attached ndscope).

As we don't have a high rate monitor for the FSS autolocker, it is actually unlocking more frequently than this plot shows. The FSS did not settle to a locked state for ~22s. We might have to include some timers in our SPI control guardian so it doesn't report SPI as READY till at least 30s have passed.

Summary: SPI STAT guardian compiles and seems to spot FSS oscillating, but SPI_CTRL need some logic fixes.

PSL

Images attached to this report

Non-image files attached to this report

SPIH23_STAT.py

SPIH23_CTRL.py

H1 ISC - Thursday locking: achieved 65W input power.

louis.dartez@ligo.org — Thu, 12 Nov 2026 18:05:54 -0800

Author: louis.dartez@ligo.org

Report ID: 92718

[Sheila, Elenna, Camilla, TJ, Jenne, Tony, Louis, Ryan S., others in CR]

Summary

Today we continued the work of powering up. We have made it to 65W input power. We saw that some ASC (CHARD) was starting to ring up so we backed down to 50W to move spots, measure PRCL OLG, and determine how to continue powering up without losing lock. We spent most of the afternoon working on increasing stability in DHARD / MICH to allow us to power up to 65W.

Comparing the highest circulating power part of that lock to O4, we had 83% of the O4 circulating power 320kW vs 385kW according to our TMS monitor), 84% of the input power (48W vs 57W at IM4), and 88% of the power out of the PSL. Our final request out of the PSL for O4 was 62W, to get the same power on IM4 now that we have JAC we should set this to 65W.

SRC1 ASC will now engage with low gain, and then get the gain ramped up later in the guardian. Sometimes it still appears unstable, but it goes away when gain is ramped to zero and then back up to nominal.

DHARD-Y problems

It looks like when we were in 50 W, we had a lockloss from DHARD Y ringing up at 2 Hz. Once we got back to 50 W, Elenna ran her measurement template. DHARD Y has an anomalous phase feature at 2 Hz (DHARD_Y_olg_debug.png). I’m not sure what could cause such a phase, but I started thinking of loops that could be cross coupling to DHARD Y. I decided to check MICH Y, and indeed there is some excessive gain peaking near 2 Hz. I’m not sure that’s exactly the issue, but as soon as I started changing the gain in MICH Y to improve the loop stability, DHARD Y rang up, so I think I’m on to something. MICH_Y_olg_debug.png

I increased the MICH low pass frequency to 20 Hz to add more phase margin. I also adjusted the gains, which requires disengaging fm4, and reducing the overall gain by half. The MICH Y settings should be FM2,3,5,8 with gain of -0.05.

Looks like this has fixed the anomalous phase issue in DHARD Y!

Guardian changes

ISC_LOCK is set up to take us straight to 65W input power via the MAX_POWER state. This has worked reliably today. However, towards the end of the day we started having trouble with CARM_5_PICOMETERS again. The reason we had this issue last night was due to CO2 getting turned off and not getting re-engaged when re-locking. That is not an issue now.

CARM_5_PICOMETERS and the transition of CARM to REFL9

Towards the end of the commissioning day we started having issues getting through CARM_5_PICOMETERS. We are currently transitioning later in the offset reduction process (larger offset value in TR_CARM) which is expected to come with its own reliability challenges. It's not clear yet if that's why we are having CARM_5_PICOMETERS issues this evening but it's not unlikely. see 92702 for some discussion on our CARM transitions.

Images attached to this report

H1 SPI - Comment to Reset SPI phase

jennifer.wright@ligo.org — Thu, 12 Nov 2026 17:48:52 -0800

Author: jennifer.wright@ligo.org

Report ID: 92719

I also had to restart the SPIH23_STAT and SPIH23_CTRL guardians as they had some errors and I had to remove some states.

LHO General - Ops Day Shift End

thomas.shaffer@ligo.org — Thu, 12 Nov 2026 16:34:01 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92710

TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Locking up to DRMI has been easy, I've only had to touch up ALSX once. Violin modes up at higher power are doing well other than 2

EY mode 1 - I've had negative gain both work and not work, +gain has done nothing but it didn't rise.
ITMX mode 12 - +30 phase -0.5 gain worked great. I didn't update this in the guardian but it might be time for that.

Water for the VPW and Staging building have been shut off for the weekend.

Commissioners made it up to 50W input power 2x today! See their alog for all work there.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
18:09	TCS	Sophie	LVEA	YES	CHETA Y table work	20:33
18:22	ISC	Keita	Opt lab	n	Optics lab work	19:02
18:22	ISC	Alex	Opt Lab	n	Opt lab work	19:02
18:43	-	Mitchell	EY, EX	n	FAMIS checks	19:16
20:51	FIT	Mallika, Rachel	X-arm	n	On a walk	21:32
21:10	ISC	Keita, Alex	Opt Lab	n	AM laser calibration	22:39
21:45	FAC	Water	VPW, Staging	n	Water OFF	01:45
22:40	TCS	Camilla, Sophie	LVEA	YES	CHETA Y table work	00:30
23:05	TCS	Edward	LVEA	YES	Job shadow joining CHETA crew	00:30
23:06	-	Jenne	LVEA	YES	Dropping off job shadow	23:17

H1 General - New state after SDF revert to prepare locking - SDF_RECOVER

thomas.shaffer@ligo.org — Thu, 12 Nov 2026 16:30:06 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92716

We've created a new state that sits just after SDF_REVERT and before READY called SDF_RECOVER (I'm not married to the name). The goal of this state is to either reset settings that were changed in SDF_REVERT, or move them from PREP_FOR_LOCKING to here.

There was no room in the indexes for this state and I didn't want to change a large number of them yet, so it's at 14. Might change on Tuesday.

The first and only test in there right now is resetting OMC whitening to match.

ISC, OpsInfo

H1 SPI - Reset SPI phase

jennifer.wright@ligo.org — Thu, 12 Nov 2026 16:18:47 -0800

Author: jennifer.wright@ligo.org

Report ID: 92715

Reset the phase twice at 00:18:00 UTC as I think I accidentally shut the SPI shutter while testing the guardian.

H1 SUS - Comment to QOSEM LED Drive Current is Quite Coherent with QPDs' SUM and Quadrants

jeffrey.kissel@ligo.org — Thu, 12 Nov 2026 15:59:56 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92714

Data and scripts are posted to the following obscure corner of the SusSVN: ${SusSVN}/sus/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2500178/S2600154/LEDCurrent_to_QPDQuads_Coupling/ Common/Scripts/ plot_ledc_to_qpd_coh_20261110.m rev 13219 CH3_F3/Data/ 2026-11-10*.TXT CH4_SD/Data/ 2026-11-10*.TXT

H1 SUS - Comment to QOSEM LED Drive Current is Quite Coherent with QPDs' SUM and Quadrants

jeffrey.kissel@ligo.org — Thu, 12 Nov 2026 15:57:04 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92713

As an explorative aside, I also grabbed the coherence between CH4 SD's LED current (TP1604) and QD Q4 (TP501) a few times an hour apart to show how stable it is; it's not convincingly stable, though the statistics are N = 2. The high-frequency asymptote value changed from 0.95 to 0.9. Also, as I did with the ASDs, I always measured the coherence with the B input of each CH1 (the LED current) and CH2 (the SUM or quadrant voltage) connected to the board's ground -- the A inputs being the respective signal. But, just to check, I tried one measurement configuration with only the voltage signals, with the grounds disconnected, and the SR785 inputs configured to only use the A input. No significant change in the coherence -- still high. This implies it's NOT that we're getting coherence between the LED current and SUM / Quadrants because the ground is super noisy and dominating above the signal voltage.

Non-image files attached to this report

2026-11-10_H1SUSBS_M1_CH4_SD_LEDC_to_Q4_TestCases_COH.pdf

H1 TCS - TCS power guardians turning on central heating at 0.2W, option to turn off at 25W PSL power

thomas.shaffer@ligo.org — Thu, 12 Nov 2026 15:54:59 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92711

Since it seems that the 0.2W central power might be our new norm for the early stages of locking, I've moved it into the TCS CO2 PWR guardian nodes. I've had to comment out and change a few things to get it to be okay with requesting 0.33W but only getting 0.2W at the power meters just after the masks. I might change and clean up this node a bit more in the near future to make it work better with our current TCS plans.

In ISC_LOCK's POWER_25W state I've put in two commented out lines that can be uncommented to turn off the CO2s at that point, per commissioner request.

Next week I'll test out the mask changing nodes to also change the rotation stage calibration so that we don't have to fudge the requested power number.

ISC, OpsInfo

Images attached to this report

H1 SUS - Comment to QOSEM LED Drive Current is Quite Coherent with QPDs' SUM and Quadrants

jeffrey.kissel@ligo.org — Thu, 12 Nov 2026 15:50:41 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92712

Here I attach measurement diagrams for measuring the coherence between the LED current drive and either the SUM or each Quadrant. I also attach the SR785 parameters I used for measuring the coherence, 'cause lemme tell ya -- there are a lot of gotchas in the SR785 firmware that will cause non-sensible results if you treat the coherence like you would an ASD. Namely, for an ASD -- i.e. Measurement Group FFT; measurement = FFT1 or FFT2, - I typically use RMS averaging, and you *need* to use Vector averaging or else you get coherence values between 0.0 and 4.0, and - I typically have the PSD units ON, because I want V/rtHz, but this can get *stuck* when you switch over to measurement = Frequency Response or = coherence, leaving the units as "[ / Hz]" when they should be dimensionless [V/V] or [V^4 / V^4], respectively. To fix, you have to switch the displayed measurement to FFT1, FFT2, PSD1, PSD2, or CSD, switch the PSD Units OFF, and then switch the displayed measurement *back* to Frequency Response or Coherence. Oy!

Non-image files attached to this report

T2600496-v3_QOSEM_SatAmp_MeasurementConfigurations_LEDDrive_to_QPD_COH.pdf

T2600496-v3_QOSEM_SatAmp_MeasurementConfigurations_LEDDrive_to_QPD_COH_SR785Params.pdf

H1 SUS - QOSEM LED Drive Current is Quite Coherent with QPDs' SUM and Quadrants

jeffrey.kissel@ligo.org — Thu, 12 Nov 2026 15:24:53 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92709

J. Kissel, T. Roocke This past Tuedsay I completed the third test described in T2600496-v2: checking the coherence between a few QOSEMs' LED driver current and the QPD's SUM -- and *if* there's signficant coherence, check the coherence to each quadrant. The idea: we expect the coherence to be low, an indication that the SUM is *not* driven by a noisy current driver. The design intent is for the LED current driver's noise to be well below the shot noise level of the QPD, and thus the QOSEM sensitivity is limited by shot-noise rather than LED current driver noise. The result: the SUM is *very* coherent, greater than 0.95 from 0.6 Hz to 100 [Hz], for both the channels I measured (CH3 F3 and CH4 SD). Further -- and maybe this is the interesting part -- the coherence of each quadrant to the LED current is different, and unrelated to the centering on the QPD. Plots Collections: - Attachment 1: three page .pdf showing the coherence between the LED driver current (TP1604) and the SUM (TP601) (both channels' SUMs on the same page), and then for each channel to each quadrant (TPs 201, 301, 401, and 501). . As mentioned above, the SUM is clearly dominated by LED current noise. . The quadrants are less dominated, but still coherent to values ranging from 0.7 in a few channels to 0.9 in others. No obvious pattern, e.g. the amount of coherence of a given channel is uncorrelated to its DC voltage. - Attachment 2: two page .pdf showing the amplitude spectral density of TP1604 for both CH3 and CH4. . Page 1 is the raw voltage noise, and Page 2 is the same voltage noise, but cast into current noise by dividing by the value of R1604 (100 [Ohm]). . We're expecting the LED current noise above ~10 [Hz] to be at the 10 to 50e-12 [pA/rtHz] range. Instead, it's 2 to 4e-9 = 2000 to 4000 [pA/rtHz], several orders of magnitude more than it should be. - Attachment 3: Not *sure* if this plot collection is useful, but in case it's useful to compare -- I show . Page 1 is the raw voltage noises of the Quadrants and the SUM; TPs 201, 301, 401, 501 and 601 to show that this measurement's sensor TIA output performance is no different than that from 2026-11-03 (LHO:92640). . Page 2 shows all these traces divided by their DC voltage, such that it's recast into RIN/rtHz. . Page 3 shows the ratio of the SUM ASD divided by LED current ASD, to get a rough number for the coupling coefficient. . In voltage units for both, the dimensionless coupling factor is about 3 [ (QPD SUM V) / (LED CURRENT V) ]. Converted to the more "fundamental units" of each, that's ~30 [RIN / A]. I'll discuss these results with Tom and come up with the next set of steps. Details of the measurement will be posted in the comments.

Non-image files attached to this report

2026-11-10_H1SUSBS_M1_QOSEM_LEDCurrent_to_QPDQuads_Coupling_COH.pdf

2026-11-10_H1SUSBS_M1_QOSEM_LEDCurrent_to_QPDQuads_Coupling_LEDC_ASDs.pdf

2026-11-10_H1SUSBS_M1_QOSEM_CH3_F3_LEDCurrent_to_QPDQuads_Coupling_QPD_ASDs.pdf

H1 SPI - Comment to In retrospect it's Obvious: When the FSS is Oscillating and/or Recovering REFCAV Lockloss, You Can't Use the SPI IFO's L Signal

jeffrey.kissel@ligo.org — Thu, 12 Nov 2026 14:55:50 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92708

I've saved the ndscope session I used to make the annotated trends posted to the aLOG as a template which lives here: /opt/rtcds/userapps/release/spi/h1/ndscope/FSSlockloss.yaml rev 36645 Which is a copy of the same template in my own non-outward facing folder /ligo/home/jeffrey.kissel/Templates/NDScope/SPI/FSSlockloss.yaml.

H1 AOS - JAC PZT channel calibration to mirror displacement and equivalent cavity frequency noise

sina.koehlenbeck@ligo.org — Thu, 12 Nov 2026 14:12:11 -0800

Author: sina.koehlenbeck@ligo.org

Report ID: 92707

Authors: Sina, with help from Masayuki

I updated the calibration of H1:JAC-PZT_DRV_OUT_DQ to obtain the PZT-mounted mirror displacement ASD. I also added a secondary axis showing the corresponding equivalent cavity-resonance frequency noise. The calibration values are taken from aLOG 91950. The cavity geometry is described on page 26 of Jan Hendrik Pold's thesis, Design, implementation and characterization of the advanced LIGO 200 W laser system (Leibniz Universitat Hannover, 2014).

Displacement calibration

The reported fringe calibrations are:

At the driver-voltage calibration point: 532 nm / 179 V = 2.9721 nm/V, rounded to 2.97 nm/V for this analysis.
At H1:JAC-PZT_DRV_OUT_DQ: 532 nm / 8601 counts = 0.0618533 nm/count = 6.1853273 x 10^-11 m/count.

The displacement is interpreted as motion of the PZT-mounted mirror, not as the change in round-trip optical path length.

I compared the direct counts-to-displacement calibration with a calibration obtained by reversing the supplied Foton filters and then applying 2.97 nm/V. The supplied filter chain is:

gain(91.45)gain(0.52)
zpk([1],[10],1,"n")gain(0.5,"dB")
zpk([1],[10],1,"n")gain(0.5,"dB")

Using the normalized continuous-frequency interpretation of these filters, the magnitude of the forward chain is:

|H(f)| = 91.45 x 0.52 x 10^1/20 x [1 + (f / 1 Hz)²] / [1 + (f / 10 Hz)²].

The two identical zero/pole sections give the squared magnitude factor above. The two 0.5 dB gains combine to an amplitude gain of 10^1/20. The inverse-filtered displacement calibration is:

C_x(f) = [2.97 x 10^-9 / |H(f)|] m/count.

For the recorded channel ASD A_counts(f), the calibrated mirror-displacement ASD is:

A_x(f) = C_x(f) A_counts(f).

This procedure assumes that the supplied forward filter chain maps driver volts to recorded counts, with no additional conversion factors omitted. The correction is applied to ASD magnitudes; it is not a phase-corrected reconstruction of the time series.

Comparison with the direct calibration

Direct calibration: 6.1853273e-11 m/count

Frequency (Hz) | Via-volts (m/count) | Via-volts/direct
          0.01 |       5.5657847e-11 |       0.89983673
          0.10 |       5.5117746e-11 |       0.89110476
          1.00 |       2.8109995e-11 |       0.45446254
         10.00 |       1.1022447e-12 |       0.017820313
        100.00 |       5.6214369e-13 |       0.0090883419

Asymptotic via-volts/direct ratios:
  Well below 1 Hz:  0.899926
  Well above 10 Hz: 0.00899926

The low-frequency calibration scales agree within approximately 10%. As another scale check, the fringe measurements imply 8601 / 179 = 48.05 counts/V, compared with 91.45 x 0.52 = 47.554 for the scalar gain alone, before including the two 0.5 dB gains and the frequency-dependent sections.

I selected the inverse-filtered calibration for the JAC displacement plots so that the supplied filters' frequency dependence is removed. The direct calibration is retained as a reference. The low-frequency agreement is a scale cross-check; it does not independently verify the filter direction or dynamic response.

Conversion to equivalent cavity-resonance frequency noise

Page 26 of the thesis describes the PMC as a four-mirror bow-tie resonator with a 2.02 m round-trip length, three mirrors mounted on the spacer, and one mirror mounted on a PZT. The mirrors are tilted by 5.6 degrees. For this calculation, 5.6 degrees is taken as the incidence angle relative to the PZT mirror normal, and the displacement calibration represents mirror motion along that normal.

The parameters used are:

Round-trip optical path length L_rt = 2.02 m.
Wavelength lambda = 1064 nm.
PZT mirror incidence angle theta = 5.6 degrees.
Finesse = 125.
Reported cavity pole approximately 593.9 kHz.

For one reflection from the moving mirror, the round-trip optical path change is:

delta L_rt = 2 cos(theta) delta x = 2 cos(5.6 degrees) delta x.

For a fixed longitudinal mode, the resonance-frequency change is:

delta nu = -[nu₀ / L_rt] delta L_rt, with nu₀ = c / lambda.

The sign drops out for ASDs, giving:

A_nu(f) = [2 c cos(theta) / (lambda L_rt)] A_x(f).

Using c = 299792458 m/s:

2 c cos(5.6 degrees) / [(1064 x 10^-9 m)(2.02 m)] approximately equals 2.7764 x 10¹⁴ Hz/m.

Thus, 1 pm of PZT mirror displacement corresponds to approximately 277.6 Hz of equivalent cavity-resonance frequency change. The right-hand axis is this fixed rescaling of the displacement ASD. It is not an independent measurement of laser-frequency noise.

As a geometry consistency check, c / L_rt = 148.41 MHz, consistent with the thesis value of 149 MHz. With finesse 125, FSR / (2 x finesse) = 593.65 kHz, consistent with the quoted approximately 593.9 kHz cavity pole. Neither the finesse nor the cavity pole is an additional factor in the static mirror-displacement-to-resonance-frequency conversion.

Attached comparison plot

The attached three-panel figure compares the 1800 s datasets starting on November 3, 2026 at 05:00 UTC and 06:00 UTC:

SPI differential X displacement ASD.
IMC-L ASD, retained in native recorded units.
Inverse-filtered JAC PZT mirror-displacement ASD in m/sqrt(Hz), with equivalent cavity-resonance frequency noise in Hz/sqrt(Hz) on the right-hand axis.

The JAC trace represents the mirror motion inferred from the actuation channel and its calibration, rather than an independent measurement of all cavity-length fluctuations.

SPI

Images attached to this report

H1 ISC - carm offset for transition, some notes

sheila.dwyer@ligo.org — Thu, 12 Nov 2026 13:35:46 -0800

Author: sheila.dwyer@ligo.org

Report ID: 92702

We are now transitioning CARM to refl signals at 94% of the full on resonance arm build up, while notes in the guardian say that we used to do this at 85%. Camilla went through some of our old locking attempts and made this spreadsheet: spreadsheet. Our final PRG and our PG at the TR_CARM offset of -40 seem similar to how they were in O4, the main difference is that we are now going higher up the fringe to make the transition.

We used to set the CARM offset for this transition using a calculation that Stefan set up, as described in 44075. We disabled that calculation after the EOM was damaged in Sept 2025.

The calculation notes the power in reflection when the IFO is unlocked P0, which was 3.56 in last night's sucsesfull lock. Then when the TR_CARM offset is -40 (at DHARD WFS, with the arm build ups about half of what it will be on resonance), it again notes the power in reflection (1.7 last night)), and calculates the fraction of the unlocked reflected power (the refl dip), 0.48 last night, the reference value that Stefan's calculation uses is 0.57. The calcuation as it currently is implemented would have wanted us to transition to RF CARM signal at an offset of -46, I've updated it to calculate something more like -56 or -57 for today's locking attempts, this is just printed in the log not used by the guardian.

The attached plots show the magnitude of the transfer function from our TR_CARM error signal to the various choices we have for RF CARM signals, at different CARM offsets. The phase of all of these signals is the same as their final phase by an offset of -45, at -40 the RF45 signals have not yet gone through their sign flip. Other than a gain, REFLair 9 / TR and REFL9 / TR are very similar, with less gain changes than the RF45 signals. This makes it seem like for these TCS settings, the REFL9 signals should be useable at much earlier offsets than we are using them at now, and the gain doesn't change as much for 9 MHz signals as for 45MHz signals, indicating that REFL 9 may be easier to use than REFL45.

Images attached to this report

H1 TCS - Comment to Looking at HWS signals at 25W - Need longer time or no annular CO2s for better data

camilla.compton@ligo.org — Thu, 12 Nov 2026 12:50:24 -0800

Author: camilla.compton@ligo.org

Report ID: 92706

Attached is the plots after 120 seconds and 10 minutes of being in POWER_25W. Central CO2s are on but haven't been changed between the reference and show images.

On ITMX, the IFO beam is more over the point absorbers than usual, but we haven't yet gone through MOVE_SPOTS.

ITMY appears clean.

Images attached to this report

H1 SPI - Comment to SPI guardian nodes update

jennifer.wright@ligo.org — Thu, 12 Nov 2026 12:15:59 -0800

Author: jennifer.wright@ligo.org

Report ID: 92705

Jim, TJ, Jennie

We decided to add a FAULT_FSS state to the SPIH23_STAT guardian so that when the FSS starts oscillating we can use a faster transition from a three-part blend (CPS/SPI/GS13) to a two part-blend (CPS/GS13). This is to avoid the platform tripping, otherwise the false phase information causes excess motion that trips the ISI. The the reason we want to do it fast as the trip caused by this last week happened over three seconds (alog #92603) but can happen in as little as one second. The guardian only goes into this fault state if no other errors in power, contrast or alignment of the SPI exist and only if both platforms have not tripped, otherwise it goes into the normal fault state and a slow (7s) transition to a 2-part blend will happen.

Non-image files attached to this report

SPIH23_STAT.py

H1 ISC - Comment to Guardian edit to make DRMI ASC engage smoothly

elenna.capote@ligo.org — Thu, 12 Nov 2026 11:15:32 -0800

Author: elenna.capote@ligo.org

Report ID: 92704

I noticed a similar issue with the PRC2 engagement, so I made a similar change to the guardian,

H1 SPI - Comment to SPI guardian nodes update

jennifer.wright@ligo.org — Thu, 12 Nov 2026 11:05:06 -0800

Author: jennifer.wright@ligo.org

Report ID: 92703

SPIH23_STAT code here:

from guardian import GuardState, GuardStateDecorator

import time

########################################

# Constants

# Initial request state, set on initialization

request = 'READY'

# Node is nominally in the ready state.

nominal = 'READY'

########################################

#if both pwr mon pds on HAM3 show a power larger nominal power then true.

def Check_laser():

if ezca['SPI-H23_FBR_PWRIN_MEAS_OUTMON'] >= 8 and ezca['SPI-H23_FBR_PWRIN_REF_OUTMON'] >= 8:

return True

else:

notify("SPI input power has dropped. Check shutter and laser prep chassis.")

return False

def Check_fss():

if ezca['PSL-FSS_OSCILLATION'] == 0:

return True

else:

notify("PSL frequency servo is oscillating.")

return False

#if all four PDs have a contrast above 75% then counter should count up to 4 and check will be True.

def Check_contrast():

pds = ['A', 'B']

intefs = ['MEAS', 'REF']

counter = 0

for intef in intefs:

for pd in pds:

if ezca[f'SPI-H23_IFO_{intef}_{pd}_CONTRAST_OUT16'] >= 75:

counter += 1

if counter >= 4:

return True

else:

notify("Contrast of one of the interferometers has dropped.")

return False

#If both platforms isolated then true

def Check_trip():

if ezca['ISI-HAM2_WD_MON_STATE_INMON'] == 1 or ezca['ISI-HAM3_WD_MON_STATE_INMON'] == 1:

return True

else:

notify("HAM 2 or 3 has tripped.")

return False

def Check_qpd():

#sum must be between 15 and 45 counts, pitch and yaw under |0.3| otherwise test is returns false

qpds = ['A','B']

dofs = ['PIT', 'YAW']

for qpd in qpds:

for dof in dofs:

if ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] > -0.3 and ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] < 0.3 and ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] > 15 and ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] < 45:

return True

elif ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] < -0.3 and ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] > 0.3 and ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] > 15 and ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] < 45:

notify("One or both optical levers need aligned.")

return False

elif ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] < 15 and ezca[f'SPI-H23_OL_QPD_{qpd}_SUM_OUT16'] > 45 and ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] > -0.3 and ezca[f'SPI-H23_OL_QPD_{qpd}_{dof}_OUT16'] < 0.3 :

notify("Optical lever power has dropped.")

return False

else:

notify("Optical lever power and alignment is wrong.")

return False

# qpd B 20 to 45

def Check_SPI():

""" This is the main function used to check on the status of the SPI. """

# Check laser on.

laser_stat = Check_laser()

fss_stat = Check_fss()

contrast_stat = Check_contrast()

trip_stat = Check_trip()

qpd_stat = Check_qpd()

if laser_stat and fss_stat and contrast_stat and trip_stat and qpd_stat:

return "READY"

else:

return "FAULT"

class READY(GuardState):

index = 40

def main(self):

notify('SPI is ready to be blended.')

self.timer['run check'] = 0

def run(self):

if self.timer['run check']:

where_SPI_should_be = Check_SPI()

if where_SPI_should_be == self.__class__.__name__:

# Check every 30s.

self.timer['run check'] = 30

else:

return where_SPI_should_be

return True

class FAULT(GuardState):

index = 10

request = False

def main(self):

notify('SPI not in default state, check laser shutter, qpd alignment or ISI watchdogs.')

self.timer['run check'] = 0

def run(self):

if self.timer['run check']:

where_SPI_should_be = Check_SPI()

if where_SPI_should_be == self.__class__.__name__:

# Check every 30s.

self.timer['run check'] = 30

else:

return where_SPI_should_be

return True

class INIT(GuardState):

"""Jumps to READY if SPI passes tests.

"""

def main(self):

where_SPI_should_be = Check_SPI()

return where_SPI_should_be

H1 ISC - Comment to Wednesday locking, got to 25W.

elenna.capote@ligo.org — Thu, 12 Nov 2026 10:03:51 -0800

Author: elenna.capote@ligo.org

Report ID: 92701

This lockloss from move spots was most likely because the SRC1 loop was no engaged and the SRC alignment could not follow the beam position change.

Although we tested SRC1 in DRMI, we didn't have a chance to test the loop in full lock, so when Jenne and Louis let the guardian power up, SRC1 was not on.

The attached plot shows the buildups as they change during the power up and move spots. RF72 I is the error signal we would like to use for SRC1. The plots show that the PRG and POP18 were high, POP90 was low, RF72 signal was near zero in full lock. Then, we successfully stepped the power to 25 W. Once the beam spots started moving in MOVE SPOTS (508), POP90 started rising, RF72 signals were moving far away from zero.

Also, the buildups show that powering up to 10W increases our PRG slightly, then it starts to turn over and drop as we go to 25 W. We start at 2W with 51.5, and increase to 52 at 10W. Then we drop to 49 by 25 W. WE lost lock in the middle of the spot move, so I don't know where we would have ended up if we finished the spot move.

Incidentally, zooming in on POP90 during the lock, it appears the zero crossings of the RF72 signals correspond with the lowest buildup of POP90, and as they move away from zero POP90 rises. I think this is indicative that RF72 I will be a good error signal for SRM alignment in full lock. see zoomed_buildups.png

Images attached to this report

H1 ISC - Guardian edit to make DRMI ASC engage smoothly

elenna.capote@ligo.org — Thu, 12 Nov 2026 09:52:04 -0800

Author: elenna.capote@ligo.org

Report ID: 92700

We had some locklosses when the DRMI ASC engaged. At first, I thought it was the SRC ASC coming on, so I had TJ hold us in DRMI LOCKED PREP ASC and engaged each loop by hand. However, I found that when I engaged PRC1, it slammed on and caused the buildups to glitch. However SRC ASC engagement was smooth.

The PRC1 engagement is done by just turning on the input- the guardian sets up all filters including the integrator. However, I upped the gain back in October because the loop was so slow. Therefore, I think a better engagement would be to turn on all filters except the integrator in PREP ASC, then ramp the gain on in ENGAGE, wait, and then engage the integrator. I have edited the ISC_DRMI guardian to do this.

Images attached to this report

LHO General - Comment to Ops Day Shift Start

thomas.shaffer@ligo.org — Thu, 12 Nov 2026 09:45:48 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92699

Initial alignment locking notes from this morning.

ALSY was tempermental, but it eventually locked after messing with the ETMY alignment a bit
Input align would lock but was only getting 0.8 on H1:LSC-TR_X_NORM_IN1, I spent far too long trying to move IM4 and PR2 to get this higher and didn't really make much of a difference for the better. I had a few peaks that went to 0.9 and called that good. I tried the ASC but turned off yaw for INP1&2 after it wasn't converging, then offloaded pitch.
PRC, MICH dark, SR2, and SRY all normal. I did not try SRC ASC.

H1 TCS - Looking at HWS signals at 25W - Need longer time or no annular CO2s for better data

camilla.compton@ligo.org — Thu, 12 Nov 2026 09:42:55 -0800

Author: camilla.compton@ligo.org

Report ID: 92698

I looked at the HWS plot for last nights brief power up, t-cursors in attached plot are the "ref" and "show" times used. Optics in O4 were 84716 but this was at full power and a while after CO2's would have turned on.

ITMX plot has point absorbers similar to O4 visible. I think this data is not good enough for a direct comparison of the point absorbers.

ITMY plot is hard to see the IFO self heating, but the annular pattern of the CO2 is visible.

ISC

Images attached to this report

H1 ISC - 2W spot positions

elenna.capote@ligo.org — Thu, 12 Nov 2026 09:21:47 -0800

Author: elenna.capote@ligo.org

Report ID: 92697

I have used the a2l_lookup.m script in /opt/rtcds/userapps/release/isc/common/scripts/decoup/BeamPosition to find our where we are positioned on ITMX at 2W full lock.

ITMX P2L gain: 0.0, which corresponds to 3.93 mm above center

ITMX Y2L gain: 2.0, which corresponds to 7.36 mm to the left of center

In the attached screenshot, I attempted to center in pitch by slowly increasing the P2L gain from 0 to 0.85. It looks like the PRG and POP18 slowly dropped the whole time. However, the ADS pitch signals had not yet converged. To avoid any confusion, I also want to note that the PRG dropped slightly when we went to DARM offset, which I marked with a T cursor.

I have not tried going further towards center in yaw yet.

For both ETMs, we are running centered (0.85, 0) beam positions at 2W.

As a reminder, we use ADS in 2W lock, so setting the A2L gains is equivalent to setting the spot position.

Images attached to this report

H1 General - Comment to Wednesday OPS EVE Shift End

camilla.compton@ligo.org — Thu, 12 Nov 2026 09:05:31 -0800

Author: camilla.compton@ligo.org

Report ID: 92696

At 25W, both CO2 masks swapped from central to annular and power increased to 1.7W (our O4 nominal from 25W to lockloss). At lockloss, the CO2s turned off so they have been off all night. We hope this is why subsequent locks failed. This morning we turned them back to 0.2W with central mask.

TJ is removing any control of the CO2s from ISC_LOCK.

ISC, TCS

LHO General - Ops Day Shift Start

thomas.shaffer@ligo.org — Thu, 12 Nov 2026 07:32:02 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92694

TITLE: 11/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 1mph Gusts, 0mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.44 μm/s
QUICK SUMMARY: SEI_ENV recently transitioned to the useism state, though I don't see a rise in the useism. It's not low, but we must be right on its threshold. Temps look good, MSR holding steady with the fans. No alarms.

H1 General - Comment to Wednesday OPS EVE Shift End

louis.dartez@ligo.org — Wed, 11 Nov 2026 21:38:53 -0800

Author: louis.dartez@ligo.org

Report ID: 92693

leaving in idle for the night. for some reason it's suddenly falling over at carm_5_picometers now. unsure why at this point.

before we could get to offset -54 with a TR_CARM gain of 1.5 w/o issue using the grd code. now I need a gain of 2.5 just to get to offset -52. I got close to recovering offset of -54 but needed a gain >3.5. lost lock at offset -53.5 i think.

earlier this evening Jenne and I were not having any issues getting to and even sitting at -54 for a little while (which is what we did while getting to -56 in 92690), so something is different or changing from underneath us.

For now, I commented the lines in CARM_5_PICOMETERS that bring the CARM offset into position for the transition to REFL so that we can request that state and sit there while diagnosing further.

H1 General - Wednesday OPS EVE Shift End

anthony.sanchez@ligo.org — Wed, 11 Nov 2026 20:00:13 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92692

TITLE: 11/12 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
Locklosses during the shift:

8: 2026-11-12_00:54:47Z ISC_LOCK CARM_TO_REFL -> LOCKLOSS
7: 2026-11-12_01:18:46Z ISC_LOCK CARM_TO_REFL -> LOCKLOSS_DRMI
6: 2026-11-12_01:36:43Z ISC_LOCK CARM_TO_REFL -> LOCKLOSS_DRMI
5: 2026-11-12_01:52:14Z ISC_LOCK RESONANCE -> LOCKLOSS
4: 2026-11-12_02:41:20Z ISC_LOCK MOVE_SPOTS -> LOCKLOSS <---- Yeah.... that's right MOVE_SPOTS[508] !!!
3: 2026-11-12_02:53:00Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
2: 2026-11-12_03:03:35Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
1: 2026-11-12_03:26:17Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
0: 2026-11-12_03:39:27Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS

I spent the last hour and a half trying to get back up to Power_25W[506]. Unfortunately CARM_to_5_picometers[309] is still tripping up the IFO. I was able to hold just fine in DHARD_WFS[307].

Holding in IDLE[-10] for the night.

LOG:
no log

H1 ISC - Wednesday locking, got to 25W.

louis.dartez@ligo.org — Wed, 11 Nov 2026 18:12:05 -0800

Author: louis.dartez@ligo.org

Report ID: 92690

[Sheila, Louis, Elenna, Jenne, Camilla, TJ, Ryan S., Tony, others in CR]

Summary

We got to 25W. SRC ASC in DRMI is working now (92685). The cause of most of our 50(ish)Hz "gain peaking" in DRMI has been mitigated (92684). Some work remains to make it reliable via the guardian. We've had a couple of instances during DRMI ASC where we had the BS move a large amount, mainly in pitch. We don't understand why the BS moved in these occurrences, and no other optics seems to follow it. Returning the BS alignment according to the top stage recovers DRMI flashes.

Log

Yesterday Daniel increased the RF power in the 118MHz, 92670. This morning we made another try at closing an ASC loop around SRM in DRMI, and it worked.
At the start of the day, TJ had DRMI lock straight away after his initial alignment. TJ had two lock losses at CARM_5_PICOMETERS with a 60Hz ringing.
Sheila and Louis went to ISCT1 to check for clipping on REFLAIR_B. The beam was little bit clipped & was adjusted to place beam on center of the diode.
Sheila paused in DRMI_LOCKED_CHECK_ASC and turned on SRC2 loops with no issue. Then improved SRM alignment by hand. Then rephased AS_A and AS_B RF72 to put all the signal in I. Accepted this in sdf. We swapped SRC1 loops to use I (was Q). SRC1 loops turned on, pitch and yaw needed a sign flip. Elenna tested the gain with a “step test” put in an offset and adjusted gain so that the step would take ~10 seconds. This was put into the input matrix with a value of -0.5 and a gain of 4 (same as original). This has been updated in the guardian.
SRC2 and SRC1 are back in DRMI ASC (set to true)
~~CARM 5 will go to TR CARM offset of -53~~ We are sticking with -54 since 92684.
We tried using REFLAIR9 in CARM_TO_REFL, this gave us a lockloss. On the next lock we started the transition using REFL9, we went 10% there but this caused a lockloss. Both locklosses with a ~60Hz ring up.
We checked the REFL9/REFL45 and REFLAIR9/REFL9 switches worked correctly by adding offsets one by one and putting them into the YARM.
We were able to transition TR_CARM to TR_REFL9 today. ~~Manually. Once.~~
CARM_5_PICOMETERS: now goes to CARM_OFFSET -56 before transitioning to REFL9. This has been updated in guardian.
Once on TR_REFL9, we requested CHECK_VIOLINS_BEFORE_POWERUP and got there without incident.
Made it through POWER_10W, then through POWER_25W without issue.
Lost lock at MOVE_SPOTS

H1 TCS - CHETA alignment beam on ITMY

sophie.muusse@ligo.org — Wed, 11 Nov 2026 17:54:54 -0800

Author: sophie.muusse@ligo.org

Report ID: 92691

Caroline, Sophie

Yesterday, we found the ITM from the CHETA table using a DSLR camera but in trying to increase the clear aperture almost walked the green beam off the PICO. Today, we reset up our camera path to follow our QCL beam so we could use the PICO and M5 to walk the beam halfway back (13000 counts in -Y). We removed the camera mirror from the beam path and the beam is now about 1/3 of the mirror from the edge (see image). To improve this without sacrificing a clear aperture to the ITM we will have to reduce the height of the mirror.

BUT we then checked the ITMY green camera after turning off the illuminators we saw a new spot from our alignment laser, that appeared and disappeared as we blocked our beam! While moving this beam with the pico we think we saw the edge of the baffle and then the ITM (X: 3625, Y:13900). We found the centre of the baffles in Y and then after observing a count/displacement on the camera determined that 4000 counts got us close to the centre of the ALS beam (X: 7625, Y:13900). Later in the control room during a lock loss we saw our beam was at the bottom edge of the ALS beam and we corrected this position, but are still lightly off in X. Tomorrow we plan to test this by injecting the QCL and measuring deformation on the HWS

Images attached to this report

H1 ISC - SRC ASC in DRMI

sheila.dwyer@ligo.org — Wed, 11 Nov 2026 17:09:40 -0800

Author: sheila.dwyer@ligo.org

Report ID: 92685

Elenna, Camilla, Sheila, TJ, Louis, Jenne

This morning we made another try at closing an ASC loop around SRM in DRMI, and it worked.

Yesterday Daniel increased the RF power in the 118MHz, 92670. We also reset the AS72 dark offsets.

At the start of the day, TJ had DRMI lock straight away after his initial alignment. TJ had two lock losses at CARM_5_PICOMETERS with a 60Hz ringing, and POP90 was high.

Sheila paused in DRMI_LOCKED_CHECK_ASC and turned on SRC2 loops with no issue. Then improved SRM alignment by hand. Then rephased AS_A and AS_B RF72 to put all the signal in I (screenshot). Accepted this in sdf. We swapped SRC1 loops to use I (was Q). SRC1 loops turned on, pitch and yaw needed a sign flip. Elenna tested the gain with a “step test” put in an offset and adjusted gain so that the step would take ~10 seconds. This was put into the input matrix with a value of -0.5 and a gain of 4 (same as original). This has been updated in the guardian.

SRC2 and SRC1 are back in DRMI ASC, this has been working nicely all day. We haven't tested it in full lock yet.

Images attached to this report

H1 ISC - DRMI 50Hz buzzing quashed

louis.dartez@ligo.org — Wed, 11 Nov 2026 16:46:32 -0800

Author: louis.dartez@ligo.org

Report ID: 92684

[Jenne, Louis, Sheila]

The "50Hz buzzing" we've been seeing while sitting in DRMI (mentioned in 92500, 92529) has been resolved (we think) for now. The main knob we used to mitigate the influence of the 50Hz peak is the MICH loop gain (applied at either the MICH2 gain field or at the input matrix value for REFLAIR_B_RF135_Q. Since many (most) of our locklosses recently have been due to the 50Hz issue while trying to evaluate CARM transitions to the REFL path, we are hopeful that we will have an easier time diagnosing our CARM issues getting back to DC Readout consistently.

Jenne grabbed some MICH error and control traces while we had DRMI locked on 1f (left column) and on 3f (right column) [mich_gains_peaking.png]. The plot shows the peak grow considerably with the MICH gain. Each trace color on this plot pertains to a different MICH2 gain (blue, orange, red == 80%, 100%, 120% of nominal).

The difference can be seen in the DRMI error signals while locked at 3f (drmi_err_sigs_3f.png). The dashed traces are from before the MICH gain reduction and the solid traces are after. I am also uploading a plot of the DRMI error signals while locked on 1f before we changed the MICH gain (drmi_err_sigs_1f.png).

I am uploading an additional comparison from Sheila (DRMI_MICH_gain_peaking_spectra.png). The MICH UGF is being lowered to about 10Hz in 3f from about 16Hz in 1f. The y-axis units are in meters on this plot (not um as the ylabels state). The red trace on all subplots show the result when the MICH gain is reduced by 60%. The legend on the top subplot applied to the like-color traces on all subplots.

Images attached to this report

H1 General - Wednesday OPS EVE Shift Start

anthony.sanchez@ligo.org — Wed, 11 Nov 2026 16:46:03 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92687

TITLE: 11/12 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 5mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.53 μm/s
QUICK SUMMARY:
H1 is currently Locked at Carm_to_Refl[409] for about 6 minutes. Comissionig team is working Diligently to get us stability and 10W.

CDS Server room temps have mellowed out a bit with the door open. HVAC service is expected tomorrow. Sorry for the Extra noise in he Control room.

LHO General - Ops Afternoon Shift Summary

ryan.short@ligo.org — Wed, 11 Nov 2026 16:37:46 -0800

Author: ryan.short@ligo.org

Report ID: 92686

TITLE: 11/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Not much different than the activities from the morning; commissioners continuing to troubleshoot locking steps around CARM_TO_REFL and some on-table alignment was touched up. Locking through DRMI has been virtually hands-off with consistently good alignment.
LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
19:10	SEI	Jim	Office	n	CRS testing out of loop	23:10
20:41	FIT	Mallika, Alex	X-arm	-	On a walk	21:12
20:52	TCS	Sophie, Caroline	LVEA	Yes	CHETA-Y table work	00:37
21:21	ISC	Sheila, Louis	LVEA	Yes	Checking REFL diode on ISCT1	21:54
22:54	VAC	Gerardo	MY	-	Checking things post-outage	23:32

LHO General - Morning Ops Shift End

thomas.shaffer@ligo.org — Wed, 11 Nov 2026 12:03:18 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92683

TITLE: 11/11 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Commissioners working on CARM reduction and ASC loops this morning. Locking to that point has been consistent and easy.
LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
18:11	TCS	Sophie, Caroline	LVEA	Yes	CHETA table work	19:08
19:10	SEI	Jim	Office	n	CRS testing out of loop	ongoing

H1 SPI - SPI guardian nodes update

jennifer.wright@ligo.org — Wed, 11 Nov 2026 11:44:32 -0800

Author: jennifer.wright@ligo.org

Report ID: 92682

I have finished updating the guardian node for SPI status (SPIH23_STAT), it lives in userapps/spi/common/guardian/ and has a checker for mis-alignment of the optical levers, low power on the input power pds, low contrast on the measurment pds, a trip of either HAM 3 or HAM2 ISIS, and a checker for if the frequency stabilisation servo goes into an 'oscillation' (high noise) state. I have loaded this updated code into the working version of this guardian.

The SPIH23_CTRL guardian is also in the same folder but I am still working on it so I have not loaded the latest version to the working version of the guardian.

Logic and planned states for these guardians is in the notes at https://dcc.ligo.org/LIGO-E2600348.

TJ is currently working on the architecture to interface the SPI with the ISI blend control nodes.

Images attached to this report

LHO FMCS - HVAC Fan Vibrometers Check FAMIS

thomas.shaffer@ligo.org — Wed, 11 Nov 2026 11:33:14 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92681

FAMIS85197

EX fan 2 seems to be very intermittently noisy as of 2 weeks ago.

CS fan2 might be slowly getting noisier as well.

PEM

Images attached to this report

H1 PSL - PSL Status Report - Weekly

thomas.shaffer@ligo.org — Wed, 11 Nov 2026 11:25:12 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92680

Laser Status:
NPRO output power is 1.857W
AMP1 output power is 70.51W
AMP2 output power is 139.0W
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PDWD watchdog is GREEN

PMC:
It has been locked 50 days, 2 hr 16 minutes
Reflected power = 30.1W
Transmitted power = 103.7W
PowerSum = 133.8W

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

ISS:
The diffracted power is around 3.5%
Last saturation event was 0 days 3 hours and 37 minutes ago

Possible Issues:
PMC reflected power is high (attachment 1)

Images attached to this report

LHO General - Ops Day Shift Start

thomas.shaffer@ligo.org — Wed, 11 Nov 2026 07:33:58 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92679

TITLE: 11/11 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.44 μm/s
QUICK SUMMARY: MSR temps are still elevated but stable, fans on and door propped open. No alarms, useism is holding steady.

Starting initial alignment now.

H1 General - Tuesday OPS Eve Shift Report

anthony.sanchez@ligo.org — Tue, 10 Nov 2026 20:14:49 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92678

TITLE: 11/11 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

A few Locklosses happened right as H1 came into my care. Then another close 4.1 Mag earthquake came and shook us up a bit. This time off the coast of Victoria BC.

Once that passed I there were a bunch more attempts to get up to Check_Violins_Before_Powerup[503], but locklosses were persistant in the CARM_TO Refl_45 or 5 Picometers.

LL LOG:

2026-11-11_00:13:22Z ISC_LOCK CARM_TO_REFL -> LOCKLOSS
2026-11-11_00:21:50Z ISC_LOCK ACQUIRE_DRMI_1F -> LOCKLOSS
2026-11-11_00:37:59Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
2026-11-11_00:50:01Z ISC_LOCK CARM_TO_REFL_45 -> LOCKLOSS
2026-11-11_01:49:10Z ISC_LOCK ACQUIRE_PRMI -> LOCKLOSS
2026-11-11_02:09:36Z ISC_LOCK CARM_150_PICOMETERS -> LOCKLOSS
2026-11-11_02:23:56Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
2026-11-11_02:35:53Z ISC_LOCK CARM_TO_REFL_45 -> LOCKLOSS
2026-11-11_02:52:16Z ISC_LOCK CARM_TO_REFL_45 -> LOCKLOSS
2026-11-11_03:04:23Z ISC_LOCK CARM_5_PICOMETERS -> LOCKLOSS
2026-11-11_03:17:38Z ISC_LOCK CARM_TO_REFL_45 -> LOCKLOSS
2026-11-11_03:35:47Z ISC_LOCK CARM_TO_REFL_45 -> LOCKLOSS
2026-11-11_03:48:48Z ISC_LOCK LOCKLOSS_DRMI -> LOCKLOSS

These all seemed to lockloss in a similar way, so it seemed systematic.
I tried to hold in DHard WFS. and was success full for a few minutes, then pushed on the CARM_5 Picos and lockloss.

LOG:
No Log

H1 ISC - Tuesday locking: FULL IFO ASC Engaged, trouble with CARM to REFL transitions again, REFL45 signals still better than REFL9

louis.dartez@ligo.org — Tue, 10 Nov 2026 18:28:51 -0800

Author: louis.dartez@ligo.org

Report ID: 92677

ASC engagement successfully done by the guardian, after initial alignment with yesterday’s new green references, and adding POP QPD feedback to PRM into DRMI ASC (PRC1 in DRMI)

PRC1 is back in the DRMI ASC.

Elenna measured MICH ASC in full lock:

MICH P loop at 2 Hz UGF, raised gain to -0.2 and disengaged FM1 (MICH_P_OLG_2W.png)

MICH Y has significant gain peaking at 5 Hz, probably needs low pass redesign (MICH_Y_OLG_2W.png)
Caused lockloss trying to change the MICH Y low pass filter
Gain of -0.1 and FM1 off sets UGF to 3 Hz, following design

Engage ASC is now set to *not* engage SRC1, but will engage MICH ASC and then bump up the gain similar to CHARD.

TMS servo and Engage soft loops ran. Louis measured an OLG of DARM on DC readout. We are keeping the FM10 boost off since it still seems to be eating too much phase (an incorrect engagement of this boost turning the dc readout transition caused another lockloss today).

Adjusted AS 72 dark offsets with IMC offline, (they didn’t change much).

We then had many unsuccessful locking attempts when going to resonance. It seems that the required gain for REFL45 is changing enough from lock to lock to cause instabilities. We have started to look at going back to reflair9, however the attached scope shows that the refl9 signals are not very sensitive to the carm offset changes, but refl45 still is (carm_offset_refls.png). We may want to start using the tr_refl45 signal though.

Louis and Elenna did not get a chance to try this though, because we had a lockloss and then absolutely no DRMI flashes on relocking. It appears that the BS moved a large amount in pitch, and we had a hard time recovering the correct alignment. I have no idea what happened, but Tony, Louis and I (Elenna) checked all the other optics and they did not move. BS_move_lockloss.png

Tony and Elenna reran an initial alignment, and then started relocking. A local earthquake swept through and held us up briefly, and then lockloss in TR carm…

Louis and I tried to get through to resonance again, by checking the matrix values for various refl signals at carm 5 pm. There was a lockloss as I stepped from -53.5 to -54. I’m not sure if I am the cause of that lockloss, or something was already ringing up.

Images attached to this report

H1 TCS - Found ITMY with Camera in CHETA path

sophie.muusse@ligo.org — Tue, 10 Nov 2026 18:21:22 -0800

Author: sophie.muusse@ligo.org

Report ID: 92676

Camilla, Robert, Sophie, WP https://services2.ligo-la.caltech.edu/LHO/workpermits/view.php?permit_id=13752

This morning we removed the telelens from the camera (nikon D810) and replaced it with a 200m lens. With the camera roughly in the CHETA beam path, in effectively the same alignment as alog 92614, we could now focus on the VP and pico to create the largest clear apperture to the VP.
Robert then removed the yellow VP cover of the VP above the CHETA VP (currently unused IR camera port) and shone a flashlight into the VP until we could see light on the camera (we expect reflected off a baffle or beam tube). The flashlight was oriented down from the angle required to point at the ITM. We then pico’ed the final steering mirror up, following the flashlight until it was pointing level and towards the ITM. At this point we started to see HAM4 in there illuminators. We kept going until the ITMY was on the camera screen! See attached (also attached is the camera image of the ITM from the VP above CHETA for comparison).

We tried putting our green laser in but could not see it on the ITMY green CDS camera or through the VP with phone camera (did not turn off illuminators).

After lunch we removed the bellows to check our alignment on the VP, it was very high and to the -X side (see image). We then realigned our QPD path with the green alignment laser to mark this alignment and zero’ed our pico here. As we were not sure that the camera was aligned along our beam path, we added an extra iris and steering mirror in the camera path. We then aligned the camera to the irises. At this point when we focuses at infinity we could already see the ITM.

We then walked M5 and the pico mirror M6 to get the ITM centered in the camera view, with less clipping. However, we over shot in -Y and are now towards the bottom of M6 (the picomirror in the camera cube) and low on the viewport. We will walk this back slightly tomorrow. We have not tried to inject the green laser in this alignment and will try tomorrow. If this cant be seenwe plane to will attempt a sweep around this position using the QCL and the HWS.

Images attached to this report

H1 General - Tuesday Ops Eve Transition

anthony.sanchez@ligo.org — Tue, 10 Nov 2026 17:22:20 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92675

TITLE: 11/11 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 1mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.54 μm/s
QUICK SUMMARY:

Locking progress has been up and down so far today.
MSR is getting hot sue to some HVAC issues in there the doors are propped open.

We are running through an Initial Alignment now.

H1 SEI - Comment to HAM3 CRS blend guardian testing

arnaud.pele@ligo.org — Tue, 10 Nov 2026 16:41:57 -0800

Author: arnaud.pele@ligo.org

Report ID: 92674

TJ, Jim, Arnaud

To fix this problem we added a new state BLEND_SETTLING in the CRS_HAM3 guardian checking for the output of the CRS blend filter to be below a threshold of 100cts over a period of 1 minute to be considered quiet, and allow the CRS to be put in loop. This threshold may need to be adjusted with further testing.

Documentation with logic description for this guardian was updated to -v2 of T2600479

svn commit -m "new BLEND_SETTLING class added"
Sending CRS_HAM3.py
Transmitting file data .done
Committing transaction...
Committed revision 36577.

LHO General - Ops Day Shift End

thomas.shaffer@ligo.org — Tue, 10 Nov 2026 16:38:35 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92665

TITLE: 11/11 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Maintenance recovery was straight forward, alignment notes below. The MY power outage took most of the day but has been recovered. See the coordination Trello for a full list of completed activites for the day. Commissioners continue their work, we had an hour long lock at DC readout where we damped violins and they worked on phasing.

Post maintenance initial alignment
- ALS locked with only a minor tweak to ETMY. COMM beatnote was +1, Diff was something ridiculous, but we could tell the BS was way off.
- Input align ASC Y didnt work, so we turned that off and adjusted PR2 and IM4 Y by hand, then offloaded
- In MICH dark, the BS was heavily pitched, had to move 19 counts on the P slider (I've heard these aren't calibrated)
- All other steps were normal

LOG:

DRMI locked @2016UTC(1216PT)
2136 DC readout
2241 Lock loss
2331 MY CDS recovered - alog92672

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:39	-	POWER	MY	n	MY power disconnect. Watch VAC and CDS	23:32
15:54	CDS	Jonathan	Office	n	Aux epics IOC restarts	16:24
15:54	CDS	Dave	Remote	n	h1lsc model restart, DAQ restart	16:11
16:03	-	Mike, photographer	EY	n	Taking pictures	16:45
16:18	SYS	Betsy	LVEA	Yes	Mapping around BSCs	17:06
16:45	FAC	Kim, Matt	FCES	n	Tech clean	17:41
17:08	SUS	Jeff	LVEA	Yes	BBSS QOSEM meas at rack	19:56
17:10	CDS	Fil	EX	n	New weather station testing	19:10
17:41	FAC	Kim, Matt	EY	n	Tech clean	18:42
18:00	TCS	Sophie	LVEA	Yes	CHETA Y ITM hunt	21:30
18:12	CDS	Marc	EX, EY	n	Power supply checks	19:03
18:26	SUS,SEI	Ryan C	CR	n	Testing out safing scripts, and medms	19:26
18:43	FAC	Kim, Matt	EX	n	Tech clean	19:11
18:48	TCS	Camilla, Robert	LVEA	YES	Viewport flashlight and laser pointer pointing (Robert out @1944)	21:30
19:13	FAC	Kim, Matt	LVEA	Yes	Tech clean	20:01
19:23	SQZ	Ryan S	LVEA	YES	SQZ table measurements	20:35
21:06	TCS	Robert	LVEA	Y	Check on CHETA work	21:26
21:17	PCAL	Tony, Caroline	PCAL lab	Yes	Shutter some apperatures, grab computer	21:30
22:14	TCS	Sophie	Prep lab	n	Looking for parts	22:28
22:28	TCS	Camilla, Sophie	Prep lab -> LVEA	Yes	CHETA table work	ongoing
22:45	VAC	Travis	MY	n	Vacuum recovery from power disconnect	23:10
23:05	CDS	Dave	MY	n	Turning h1pemmy back on	23:49
23:24	ISC	Daniel	CER	n	Adding more modulation depth to 118 MHz	23:38

H1 SPI - Comment to Proposed HAM2 X, RY, and RZ CPS-SPI-GS13 blend filters

sina.koehlenbeck@ligo.org — Tue, 10 Nov 2026 16:16:59 -0800

Author: sina.koehlenbeck@ligo.org

Report ID: 92671

Version v003 features higher GS13 blend frequencies for HAM2 X, RY, and RZ to diagnose noise in the SPI sensor.

SEI, SPI

Images attached to this report

Non-image files attached to this report

HAM2_RY_v003_SPI_design_cancellation_comparison.txt

HAM2_RZ_v003_SPI_design_cancellation_comparison.txt

HAM2_X_v003_SPI_design_cancellation_comparison.txt

H1 CDS - CDS Maintenance Summary: Tuesday 10th November 2026

david.barker@ligo.org — Tue, 10 Nov 2026 16:16:58 -0800

Author: david.barker@ligo.org

Report ID: 92673

WP13748 Restore TR_REFL45 choice in h1lsc

A new h1lsc model was installed at 07:51. A DAQ restart was needed.

WP13746 New FW2 Code

Jonathan restarted FW2 with new code, no impact on rest of the DAQ

WP13742 MY Power outage

h1pemmy was powered down prior to the outage, and then powered back on following power restoration.

DAQ Restart

Jonathan restarted the DAQ for the h1lsc model change. 1-leg at 07:51, 0-leg at 07:56.

H1 CDS - h1pemmy powered back up 15:31

david.barker@ligo.org — Tue, 10 Nov 2026 16:11:17 -0800

Author: david.barker@ligo.org

Report ID: 92672

Following restoration of power to MY, we powered h1pemmy IO Chassis and computer up at 15:31. The DC power supplies for the IO Chassis, AA chassis and accelerometer were already running.

I then undid the "greening" I did this morning when h1pemmy went down:

edc_disconnection count back to zero, daqstat dcu count 136, EY timing fanout port16 active, Alarms for DC dcu count back to 136.

The CDS_HW_STAT and DAC_OVERFLOW went green by themselves after the restoration.

H1 TCS - Comment to Adding CO2 annular heating simulation

evan.hall@ligo.org — Tue, 10 Nov 2026 15:54:41 -0800

Author: evan.hall@ligo.org

Report ID: 92666

The first attachment gives the intensity patterns before and after the mask, and also magnified to the CP plane (with a corrected normalization that was missing in the previous comment). Essentially, only 50% of the incident laser power makes it through the mask. Then only about 60% of that transmitted power falls within the aperture of the compensation plate. The measurement above inferred from FLIR data is not consistent, but on the other hand, the laser spot is not too far off from Gaussian so one wonders why the two do not agree.

The second attachment gives the expected OPD from annular heating, calibrated to refer to watts emitted from the mask (i.e., including the 50% factor above, but not the 60% factor), based on TJ's indication that this is how the TCS CO2 power readback epics record is calibrated. (The band is the azimuthal variation due to the mask pattern.) If this simulation is correct, it means the annular illumination nominally is supposed to give minimal spot-weighted quadratic actuation. This is not the same as what is inferred from FLIR and Hartmann data. Measurements indicate a quadratic power roughly 50 to 100 times larger (see also LHO:89999).

Going back to the theoretical profile, there is a rough complementarity of the annular intensity profile and the expected beam heating profile on the ITM HR surface. Roughly, every watt of beam power absorbed at the ITM HR surface can be complemented by about 30 W or so of annular beam power launched from the mask output, which should give minimal higher order aberration. This suggests (again, in the theoreical/modeling world) that to cancel single-pass higher order aberration through the ITP and CP substrates, one should use about 5 W of annular CO2 power to cancel the expected beam heating at the current arm powers if the ITM HR absorption is 0.5 ppm.

MDL/SIM

Non-image files attached to this report

annular_CO2_mask_D1201477_intensity_CP.pdf

CP_OPD_annular.pdf

H1 ISC - 118 MHz modlation index boosted by 6dB

daniel.sigg@ligo.org — Tue, 10 Nov 2026 15:45:17 -0800

Author: daniel.sigg@ligo.org

Report ID: 92670

Added a 4-way combiner to the 118 MHz RF signal which is driving the in-vac EOM.

H1 SEI - Comment to HAM3 CRS blend guardian testing

arnaud.pele@ligo.org — Tue, 10 Nov 2026 15:01:18 -0800

Author: arnaud.pele@ligo.org

Report ID: 92667

I think the velocity calculation, and the guardians worked as expected here.

The problem was the crs 30mHz blend filter didn't have time to ring down after the laser was turn on and off (the step response of this filter is *very* long, see the SUPERSENS6_LO_OUTPUT channel on the attached plot), which rung up the ISI when putting the CRS in-loop. This caused the CRS itself to ring up, triggering its guardian to go to the CRS_RUNG_UP state, and creating the chain of events. The ISI ring up is clear looking at the THETA_INMON, HOQI distance, or CPS channels (see attached).

We should have the ISI_HAM3_BLND guardian node watch the SUPERSENS6_INERT_LO_OUTPUT channel in addition of the CRS_HAM3 state before turning the CRS in/out of loop, or find a clever way to bypass the long filter step response.

Images attached to this report

H1 SQZ - Swapped SQZ locking back to PZT1

camilla.compton@ligo.org — Tue, 10 Nov 2026 14:38:48 -0800

Author: camilla.compton@ligo.org

Report ID: 92668

Ryan, Camilla

Ryan repeated 92590 both on PZT2 with the PZT dither locked around 50V. Then we swapped the PZT1 and PZT2 cables so that the nominal PZT1 is now used for locking. We changed H1:SQZ-OPO_IR_LSC_SERVO_GAIN back from -100 to -300 in the OPO guardian and Ryan repeated the data set with PZT1 dither locked around 56V.

Changing from locking on PZT2 to PZT1 did not effect the alignment.

H1 SPI - Comment to In retrospect it's Obvious: When the FSS is Oscillating and/or Recovering REFCAV Lockloss, You Can't Use the SPI IFO's L Signal

jeffrey.kissel@ligo.org — Tue, 10 Nov 2026 12:53:47 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92664

Apologies -- I attached the Nov 4th annotated screenshot twice. Here's the annotated screenshot for Oct 28th. Good catch @Shreevathsa!

Images attached to this report

H1 IOO - Comment to Checking for glitches in JAC actuators

jennifer.wright@ligo.org — Tue, 10 Nov 2026 11:27:19 -0800

Author: jennifer.wright@ligo.org

Report ID: 92663

If it turns out the problem is the PSL PZT mirror, Keita mentioned we have had to replace these before as the PZT would slip its alignment. Jason is looking for spares just in case.

H1 IOO - Checking for glitches in JAC actuators

jennifer.wright@ligo.org — Tue, 10 Nov 2026 11:26:17 -0800

Author: jennifer.wright@ligo.org

Report ID: 92661

Jennie W, Keita K,

Summary: Found another JAC glitch - unsure if the cause is the PSL PZT mirror or some electronics issue, as we also see a change on the voltaqge to the JAC length actuator.

Yesterday Keita and I took a look at the glitch Elenna saw in this entry (alog #92620), that caused a dip in the JAC transmitted power, based on the size of the glitch on the JAC wavefront sensors, Masayuki hypothesised that this is coming from one of the ASC actuators.

Yesterday Keita concluded that this effect will then be corrected by the ASC itself and so that explains why the power dip is corrected on the JAC trans PD after 100ms (roughly 1/UGF of WFS loops). Last night I had the operator leave the JAC unlocked so we could see if we still see this dip in the wavefront sensor dc signals when the asc is off and not locked. This allows us to rule out any affects from the JAC length loop or electronics.

I found one glitch, at around 15:51:49 UTC, where the power on all four wavefront sensors changed by about 0.04 counts and did not return to their initial values. Also the drive readback on the JAC length PZT actuator changed by 13 V even though we were not locked at the time.

Comparing this glitch to the one Elenna found on the 4th November, the JAC length PZT drive did not change but the reponse to the glitch on WFS B yaw was a lot higher 0.1 counts.

If this was caused solely by the ASC actuators drifting we would not expect to see any change on the HV readback for the JAC length PZT as the cavity was unlocked.

Another confusing thing that happened after this was that at 15:54:23 UTC JAC servo input turnend itself on without the guardian requesting it, this happened after the glitch though and I assume is caused by some combination of DAQ restarts/other computer restarts this morning - otherwise I am stumped.

Here is another zoomed out picture where the first cursor is when the JAC length PZT started driving and the length servo input turned on, the second cursor (16:36:32 UTC) is when the JAC guardian actually started trying to lock it.

Conclusion: More observations of this glitch needed, while we are not doing any computer restarts that might confuse things.

Images attached to this report

H1 ISC - Kepco Health Checkup EX, EY

marc.pirello@ligo.org — Tue, 10 Nov 2026 11:15:50 -0800

Author: marc.pirello@ligo.org

Report ID: 92662

EX Supply Analysis:
Airflow is good on all supplies, no deficiencies. All supplies show 70F to 80F on fan housings, no deficiencies.

EY Supply Analysis:
Airflow is good on all supplies, no deficiencies. All supplies show 70F to 80F on fan housings, no deficiencies.

Updated supply layout document here: https://dcc.ligo.org/LIGO-D2300167

H1 SQZ - Comment to Small Grid of SQZ Beam Profiles with OPO Locked with PZT2

camilla.compton@ligo.org — Tue, 10 Nov 2026 10:38:15 -0800

Author: camilla.compton@ligo.org

Report ID: 92660

To dither lock on PZT2 we needed to change H1:SQZ-OPO_IR_LSC_SERVO_GAIN from -300 to -100. See via "OPO DITHER" screen on SQZ Overview medm. Changed the OPO GRD code.

H1 SEI - HAM3 CRS blend guardian testing

jim.warner@ligo.org — Tue, 10 Nov 2026 10:08:29 -0800

Author: jim.warner@ligo.org

Report ID: 92659

TJ and I tested his blend code some this morning. I think the blend node itself behaves as it should, but there are some adjustments that need to be made to the velocity channel that is used for a witness.

To test the node this morning, we used the CRS_LASER node to turn off the laser. As intended, the laser node changed its state, but waited for the CRS_HAM3 node to go into fault, which made the HAM3_BLND node take the CRS out of loop, by change the ry blend to a CPS/GS13 blend. We then turned the laser back on. This time, the laser turned on correctly, but I think the blend node acted a little too quickly, putting the CRS back in loop immediately after the laser finished ramping the power up, which rung the CRS up. I think we should probably wait a bit after turning the laser on, before calling the CRS good.

Ringing up the CRS was the next test we had planned anyways, so this immediately tested the CRS_RUNG_UP state in the HAM3_CRS guardian. Again the blend node behaved as it should and took the CRS out of loop again. However, I think the velocity calculation could use some adjustment, because we immediately got into a state of the blend node ping-ponging between states, because the HAM3_CRS was going back and forth between CRS_GOOD and CRS_RUNG_UP.

First attachement shows the CRS_RUNG_UP test. Top trace is the calibrated CRS theta out channel, the second row is the VEL_BLRMS channel that is supposed to be a witness of CRS angular velocity, but I'm not sure the filters there are doing what we claim. The bandpass is a 15-40mhz butterworth filter, the output of that gets squared, the multiplied by a 10mhz lowpass to do the mean. Both of these induce a lot of phase at the 25mhz CRS mode and it means this blrms channel lags the CRS by quite a bit. I'm not sure that's what we want. The delay in the blrms calculation and the tight threshold ( CRS_RUNG_UP is when the vel blrms >1 ) on its value means the HAM3_CRS guardian is bouncing in and out of CRS_RUNG_UP, even though the CRS itself (as seen in the theta out channels) seems quiet enough.

Automation is almost there, though. A little more thought and I think we should probably be in a good state to try running the CRS full time. It has already run for several days at a time with no issues.

Images attached to this report

H1 CDS - CDS Overview while h1pemmy is powered down

david.barker@ligo.org — Tue, 10 Nov 2026 09:45:51 -0800

Author: david.barker@ligo.org

Report ID: 92658

I did some "greening" of the CDS Overview while the Mid-Y building is powered down today.

1. EDC is now green with the expected 79 disconnected MY channels

2. DAQSTAT is now expecting 134 DCUs instead of the normal 136

3, TIMING fanout at EY expecting port16 (link to MY) to be down

4. pemmy models down

5. DAC_OVERFLOW system reporting loss of h1ioppemmy

6. CDS_HW_STAT reporting loss of h1pemmy cards

7. CDS oveview was using h1ioppemmy for timing PV, now using h1ioppsl0

Images attached to this report

H1 CDS - MSR warming up, loss of cooling unit closest to hallway doors

david.barker@ligo.org — Tue, 10 Nov 2026 09:35:51 -0800

Author: david.barker@ligo.org

Report ID: 92657

Temperature trends suggest the Mr Slim cooling unit closest to the hallway doors stopped working around 01:30 this morning, Tue 10nov2026. Jonathan has propped open the hallway doors for now.

Images attached to this report

H1 PEM - DUst Mon 10 powered off

betsy.weaver@ligo.org — Tue, 10 Nov 2026 09:12:15 -0800

Author: betsy.weaver@ligo.org

Report ID: 92656

This morning I found that the temporary installation Dust Monitor up on top of the platform around BSC2 had it's cable running around the BSC1 NE HEPI pier with a bit of tension on it. So, I powered this DM off, disconnected the cable and dropped it to the pile of cabling on the ground below. This DM is used mainly during installation activities so not needed now.

Images attached to this report

H1 ISC - Comment to h1lsc ready for model change: Adding REFLAIR 9 back in for TR COMM option.

camilla.compton@ligo.org — Tue, 10 Nov 2026 09:02:35 -0800

Author: camilla.compton@ligo.org

Report ID: 92655

Updated medm to show this change. See attached.

Images attached to this report

LHO General - Ops Day Shift Start

thomas.shaffer@ligo.org — Tue, 10 Nov 2026 07:37:47 -0800

Author: thomas.shaffer@ligo.org

Report ID: 92654

TITLE: 11/10 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: EARTHQUAKE
Wind: 2mph Gusts, 0mph 3min avg
Primary useism: 0.24 μm/s
Secondary useism: 0.43 μm/s
QUICK SUMMARY: Maintenance Tuesday starting with an earthquake in El Salvador. IMC was in FAULT since the JAC was down, h1pemmy down in prep for the MY power work.

MSR temperatures jumped 5C about 3 hours ago. (tagging CDS)

CDS

H1 CDS - Workstations updated

erik.vonreis@ligo.org — Tue, 10 Nov 2026 06:14:32 -0800

Author: erik.vonreis@ligo.org

Report ID: 92653

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

H1 General - Comment to Monday Eve Shift Report: The Grateful Violin Damper

anthony.sanchez@ligo.org — Mon, 09 Nov 2026 21:06:00 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92652

I restared Nuc30 to get the screen shots running again but there was a Lockloss while I was washing my dishes at 4:26 UTC. :(
IMC to AUTO and Down & JAC is in Down.

H1 General - Monday Eve Shift Report: The Grateful Violin Damper

anthony.sanchez@ligo.org — Mon, 09 Nov 2026 20:18:08 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92651

TITLE: 11/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
H1 was been locked all night. H1 has been in DARM_TO_DC_REDOUT for almost 2 hours and Ive been able to focus entirely and Violin damping.

New And improved 2W DC Violin settings to try!
ITMX Mode12 started to ring up I changed the I tried different gains and then tried turning on the FM4-60 deg which was able to damp all night.
ETMX Mode2 also started to ring up I took the Gain from -20 ! down to ZERO for a while. I ended up turning off FM2 which is the -60 deg filter then slowly added more gain to that to get all the way up to -16 which quickly dropped the violin.

There has not been a Lockloss all night! No Initial Alignment was ran.

Sorry PSL team I know ya'll wanted to test PZT glitches.

Restarting NUC 30 to get screen shots working again.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
20:54	FIT	Alex, +2 fellows	XARM	n	Walking	21:23
21:41	VAC	Travis, Richard, Gerardo	MY, MX	n	Taking measurements	22:28
22:27	PCAL	Tony, Caroline	PCAL Lab	y(local)	Swapping out spheres for a measurement	22:57
22:50	VAC	Gerardo	MY	n	Prepping for tomorrow	01:30
23:23	TCS	Sophie	LVEA	YES	Checking for CHETA beam	01:57
23:40	TCS	Camilla, Jackie	LVEA	YES	Joining Sophie for CHETA work	01:04
00:30	ISC	Sheila, Louis	LVEA	YES	ISCT1 alignment	01:30

Images attached to this report

H1 ISC - We are back to DC readout, full alignment references set!

elenna.capote@ligo.org — Mon, 09 Nov 2026 18:33:43 -0800

Author: elenna.capote@ligo.org

Report ID: 92650

Sheila, Oli, Elenna, Louis, Camilla, Keita

Authorial note: We wrote this alog by committee throughout the day, so there are other alogs posted that report various pieces of this work. Here is the rest of the summary, and the final endpoint for the day.

After Oli's initial alignment, we stopped at CARM_5_PICOMETERS. Sheila ran the userapps/lsc/h1/templates/CARM/TR_CARM.xml template. Last week the input matrix value (ISC_LOCK) between REFLBIAS and REFL_A45I was -154, but today it was around 300. We increased the TR_CARM offsets (sitemap > LSC > TR COMM (left side of screen) in steps of 1, each time measuring how much the TR_GAIN needs to then increase to keep REFLBIAS_IN1/IN2 at the original level. Aiming to see this gain increase effect TR_REFL45. We thought we had got there and manually went through the CARM_TO_REFL45 transition but lost lock. We tried again but lost lock before even trying the transition.

As this had also not worked on Friday (only worked once for Corey 92612), we decided to undo the green references changes from Thursday in order to relock. Green references on "QPD OFFSETS" and "CAM ITM PIT" screens (from ALS end station overview) reverted to values from 92602 screenshot. Oli completed another initial alignment. ALS COMM at -8, ALS DIFF at -14, no table realignment needed.

After the realignment we again stopped at CARM_5_PICOMETERS, repeated what we did earlier. We increased the TR_CARM offset from -52 to -54.5 where we saw a REFL45 response, as we did this we stepped gain from 1.5 to 2. Last week the input matrix value (ISC_LOCK.py) between REFLBIAS and REFL_A45I was needed to be -250. We got through CARM_TO_REFL45 fine but lost lock at CARM_TO_ANALOG.

Confirmed that we can go to carm 5, change offset to -54 and gain to 2 again, and then successfully run carm to REF45 and resonance a second time. Guardian code is now updated to do this offset in carm 5.

PRG channel reports PRG of 50 on resonance, checking with alog 62110 says something between 48 and 54.

We had at least one lockloss due to an incorrect settings of the trigger matrix to trigger on the TRX and Y, which is then set to 0, below the trigger threshhold, incorrectly causing a lockloss. We encountered this problem last week and thought we fixed it- turns out it is incorrectly set in SDF, so SDF reverts the proper setting in prep for locking. Louis and I may look into splitting up the state before and after SDF revert. I properly SDFed it this time, and Sheila and Louis updated the guardian.

**interlude where we did more TCS things, see other alogs**

We have made it to full IFO, and closed most alignment loops! What is not yet closed:

SRM alignment, SRC1, the RF72 signal has not been good so far. We are still walking SRM by hand
CSOFT/DSOFT P, remember these are effectively damping loops so I am not worried about their effect on alignment (just no powering up until we close these).

We have also not gone through all the steps of raising the bandwidth of the loops, so we need to check loop bandwidths and adjust as necessary. All ASC has been engaged by hand. I have tried to keep up with my steps in MINI_ASC_ENGAGE, but I have not tested the state so I have no guarantee it will actually work.

I have set green references for full IFO alignment! See attached screenshot. Sheila and Louis touched up ISCT1 to ensure we have these alignment references set.

I found a better location for the ITMX beam spot, still miscentered but less so. See SDF screenshot.

Keita and I pico’ed the POP QPDs to bring the beams close to center (reference alog), screenshot. There is still a ways to go, but I have set POP A QPD offsets for now that will allow us to use PRC1 in DRMI. Further notes: we did the same move as the reference alog, move pico 1 steering DOWN and pico 2 steering UP in pitch. Do this iteratively, which slowly converges towards center on both QPDs. For yaw picoing, both picos move in the same direction. We have beams on both QPDs, but still not completely centered.

DC readout transition:

We lost lock earlier in this transition due to a 14 Hz ring up in DARM. I stopped in PREP DC READOUT and measured the DARM OLG. I noticed that there is considerably less phase in RF darm than the template reference, which was last measured in October. So, I tried disengaging FM10, which is a boost eating quite a bit of phase around 10 Hz. This seems to have done the trick! I added a step in PREP DC to disengage this boost, since it might be helpful during carm offset reduction.

Leaving us here, we're locked now 2 hours 20 minutes. Tony is damping violins.

OpsInfo

Images attached to this report

H1 SUS - Comment to Electrical Grounding on QOSEM Chassis in U38-U39 of SUS-R2 is Questionable; Impacting LED Feedback Front-panel Status Lights at Least

thomas.roocke@ligo.org — Mon, 09 Nov 2026 17:45:21 -0800

Author: thomas.roocke@ligo.org

Report ID: 92647

Thanks for the find Jeff!

While the circuit which drives those front panel LEDs is buffered and isolated from the critical QOSEM LED current or QPD readout signals, I agree that if this is due to a grounding issue, it could certainly affect those signals. With that said, I'd expect any ground driven noise to be common amongst all TIA channels, and would therefore see a decent amount of rejection on the difference outputs, so wouldn't be my immediate guess for the excess noise we're seeing.

I checked the spare chassis here at CIT, and it doesn't exhibit the same behavior when touching the chassis or moving the lid around. Nor did I see this behavior when at LHO testing the chassis in the EE shop. My best guess for whats happening, is as follows: If the rack ground is at some potential compared to the QOSEM +/-18V PSU ground, then when touching the chassis with the grounding strap on, this could briefly disturb the ground potential in the sat amp, which would mess with the comparator level which turns those front panel LEDs on and off. This would also disturb the signals lines, but again would be hard to show up in the difference signals at very least.

Hard to tell what could be causing this weird grounding from afar, but my suggestion for a test would be to measure the difference in potential between QOSEM +/-18VPSU ground (where the entire chassis pulls ground from) and the rack:

Using a multimeter, measure DC voltage between QOSEM PSU ground (TP3 on the D1000217 PSU board) and a point of interest on the SUS-R2 rack. TP3 is a direct connection to the ground wire on the 3 pin power connector to the chassis.
Power down the QOSEM sat amp, and disconnect the power connector
With the power connector disconnected from the sat amp, measure the potential between the ground pin on the connector (middle pin), and the rack. If the measured potential has changed by disconnecting the QOSEM sat amp power then the ground imbalance is caused by the QOSEM sat amp.

All internal PCBs get their grounds from the D1000217 PSU (The TP3 trace). There is a connection from the PCB ground to the front panel via the SMA connectors unfortunately. This could potentially be introducing a ground loop within the sat amp, and causing these issues. If these are the culprit, the SMAs can be removed, as they are only there for monitoring and not essential (or used to my knowledge). Doing so will make it that the only connection to the PCB ground is via the PSU ground, as it should be.

H1 ISC - improved table alignment for POPAIR and COMM/DIFF paths on ISCT1

louis.dartez@ligo.org — Mon, 09 Nov 2026 17:27:10 -0800

Author: louis.dartez@ligo.org

Report ID: 92649

[Sheila, Louis]

Sheila and I went out to ISCT1 to check for clipping and see if we could improve the beatnotes and/or the POPAIR path. The POPAIR_B path was clipped on the shutter downstream of the POP persicope. Sheila translated the shutter a bit and it's no longer clipping but now the beam is a little bit high on the shutter. POPAIR_B_RF18 improved from about 207 to 217 counts.

We were able to get the COMM beatnotes from -5 to about 0.75 dBm. The DIFF beatnote was increased from about -13.5 to -11dBm with some walking. We translated the 1-inch lens just upstream of the DIFF PD a little bit to avoid clipping. We were hoping to get somewhere closer to -6dBm on the DIFF beatnote but couldn't get there in the time we had today.

Images attached to this report

H1 General - Monday OPS day shift report.

anthony.sanchez@ligo.org — Mon, 09 Nov 2026 16:56:41 -0800

Author: anthony.sanchez@ligo.org

Report ID: 92648

TITLE: 11/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.44 μm/s
QUICK SUMMARY:
H1 is currently at Locked with H1:GRD-ISC_LOCK_STATE_N state in PREP_ASC_FOR_FULL_IFO[429] and heading towards DARM_TO_DC_READOUT[501].
Violins are elevated behind the legend.

H1 General - Ops DAY Shift End

oli.patane@ligo.org — Mon, 09 Nov 2026 16:33:46 -0800

Author: oli.patane@ligo.org

Report ID: 92646

TITLE: 11/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Currently in PREP_ASC

Initial Alignment
- The FSS kept unlocking while running IA, both during INPUT_ALIGN_OFFLOADED and sometimes when I manually took ALIGN_IFO to DOWN. One time I had to toggle the FSS autolocker OFF and then ON to get it to stop oscillating.
- Changes compared to the IA printout:
- When trying to go to WFS_CENTERING_XARM, we lost lock three times and the FSS unlocked, causing JAC and the IMC to unlock.
- Because of this happening all three times we got into WFS_CENTERING_XARM, we just went to ACQUIRE_XARM_IR, saw that TR_X_NORM_IN1 was locked at 1, and continued with the rest of IA
LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
20:54	FIT	Alex, +2 fellows	XARM	n	Walking	21:23
21:41	VAC	Travis, Richard, Gerardo	MY, MX	n	Taking measurements	22:28
22:27	PCAL	Tony, Caroline	PCAL Lab	y(local)	Swapping out spheres for a measurement	22:57
22:50	VAC	Gerardo	MY	n	Prepping for tomorrow	ongoing
23:23	TCS	Sophie	LVEA	YES	Checking for CHETA beam	ongoing
23:40	TCS	Camilla, Jackie	LVEA	YES	Joining Sophie for CHETA work	ongoing
00:30	ISC	Sheila, Louis	LVEA	YES	ISCT1 alignment	ongoing

H1 SUS - Comment to QOSEM QPD Relative Intensity Noise is NOT Spatially Dependent

jeffrey.kissel@ligo.org — Mon, 09 Nov 2026 15:58:41 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92645

I couldn't really find a good location in the SusSVN that made sense to commit the data, scripts and results. C'est la vie, all the stuff likes in this folder structure: ${SusSVN}/sus/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2500178/S2600154/TIAVoltageNoise/ CH3_F3 Data/ # raw SR785 ASCII .TXT files Results/ # .pdfs of plots of the data CH4_SD/ Data/ # raw SR785 ASCII .TXT files Results/ # .pdfs of plots of the data Common Data/ # raw SR785 ASCII .TXT files Results/ # .pdfs of plots of the data Scripts/ # Scripts to analyze the data and make the plots plot_tiavoltagenoise_20261103.m rev 13213 plot_tiavoltagenoise_CH4_SD_20261027.m rev 13213

H1 SUS - Comment to QOSEM QPD Relative Intensity Noise is NOT Spatially Dependent

jeffrey.kissel@ligo.org — Mon, 09 Nov 2026 15:54:14 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92644

Here's a comparison of CH4 SD's quadrant 4's raw, AC-coupled TIA voltage noise output comparing - The raw voltage from TP 501 alone connected to CH1 A of the SR785, and CH1 B 50-Ohm terminated vs - The same voltage from TP 501 connected to CH1 A, but with CH1 B connected to the board's GND reference (as shown in the measurement diagram above). In both measurements the SR785 was configured in the exact same way, with the CH1 input in A-B mode, AC-coupled, and at the -46 [dBVpk] input range. As mentioned above, the noise *floor* doesn't really change, but there's lots of spiky junk, and not necessarily just at integer multiples of 60 Hz.

Non-image files attached to this report

2026-10-27_H1SUSBS_M1_CH4_SD_TIAOutput_Q4_A_vs_A-B_GND_VprtHz.pdf

H1 SUS - Electrical Grounding on QOSEM Chassis in U38-U39 of SUS-R2 is Questionable; Impacting LED Feedback Front-panel Status Lights at Least

jeffrey.kissel@ligo.org — Mon, 09 Nov 2026 15:33:51 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92643

J. Kissel, O. Patane While Oli and I were getting started taking measurements of the QOSEM satamp in SUS-R2 (see LHO:92640; data taken on Tuesday morning of Nov 03 2026), we found that the electrical grounding situation of QOSEM satamp suspicious if not down-right dismal. Check this video of me sliding the lid around along the top and how it impacts LED Feedback loop's ON / OFF status lights. This renders the status light's completely useless. Even when we're *not* actively moving something, these lights will be intermittently ON or OFF, regardless of the status of the switch below it. Similarly this video shows me (after the lid is OFF) tapping the front panel lightly, and watching the same LED feedback loop status lights flicker. As shown by the tail end of the second video, I'm wearing the rack's "ground yourself to the rack" wrist strap, so this is even with me supposedly at the same voltage as the chassis. I will note, when we were measuring on the prior Tuesday (Oct 27 2026), I was lazy and did *not* wear the wrist strap at first, and while connect the clip-leads within the chassis, I felt small electrical discharges to the front panel several times when going from SR785 to chassis and back. Further indication that the rack has some voltage w.r.t. ground. I note that Josh experienced the same thing when he was installing SPI RF electornics -- see brief mention of it in LHO:90790. I'll actually measure some chassis to ground voltages directly during tomorrow's tests. CDS, FRS

H1 TCS - CO2 Central Heaters on at 0.2W for ITMX and ITMY

camilla.compton@ligo.org — Mon, 09 Nov 2026 15:25:24 -0800

Author: camilla.compton@ligo.org

Report ID: 92642

Sheila, Elenna, Louis, Daniel, Camilla

Today we are getting a lot of mode hopping lock losses again, similar to before the ring heaters were turned on to 0.5W/segment each. We want to get back to the good locking place we were on Thursday. On Thursday we were still in the overshoot of the transient of the ring heaters turning off. A simulated 5uD above current levels on the ITMs, plot. HWS see this overshoot transient too.

When we tried turning the central CO2's on in 92425, we went to 0.6W central on ITMX and ITMY, this was a change of +15uD. In this change we saw a lot of mode hoping. But we were in a different thermal configuration as the ring heaters were asymmetric: 0.44W/segment ITMX and 0W on ITMY.

This afternoon we have put 0.2W on each central CO2 to increase each ITM +5uD, hoping to getting closer to the thermal state we were in on Thursday.

ISC

Images attached to this report

H1 SUS - Comment to QOSEM QPD Relative Intensity Noise is NOT Spatially Dependent

jeffrey.kissel@ligo.org — Mon, 09 Nov 2026 15:20:16 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92641

To measure these voltages, we needed to take the lid off the QOSEM sat amp chassis. Space is tight in SUS-R2 to take off the lid, given that the QOSEM satamp is positioned right under the RF patch panel. While one should always do this anyways, it deserves an extra reminder here -- one *must* where the available "ground yourself to the rack" wristband. I did *not* do this in our first attempt at this measurement, and I would repeatedly feel static discharge when I went from the SR785 back to the rack change clip leads to connect a different quadrant. I attach diagram of the measurement setup. We found it essential to subtract off the board ground (referenced from GND TP101 and TP102) from the measurement (using the SR785's B channel of CH1), or else the data was spoiled by a lot of 60 Hz spiky crap (though the broadband noise floor did not change). I'll post a plot of "GND substracted off vs. Raw Voltage" in further comments below to show what I mean. SR785 settings are also posted. Also I post a few pictures of the reality of the setup. - SUS-R2 with the QOSEM satamp spanning U38 and U39. - QOSEM satamp with everything on, connected, and running as designed -- just with the lid off and the SR785 connected in to measure voltages of test points from the top. - A zoom of the Front, TIA portion of the CH4 SD QOSEM board, connected to the SR785 BNC cables via clip leads in the RIN configuration.

Images attached to this report

Non-image files attached to this report

T2600496-v3_QOSEM_SatAmp_MeasurementConfigurations_QPD_RIN.pdf

T2600496-v3_QOSEM_SatAmp_MeasurementConfigurations_QPD_RIN_SR785Params.pdf

H1 SUS - QOSEM QPD Relative Intensity Noise is NOT Spatially Dependent

jeffrey.kissel@ligo.org — Mon, 09 Nov 2026 14:44:42 -0800

Author: jeffrey.kissel@ligo.org

Report ID: 92640

J. Kissel, O. Patane, T. Roocke After fixing the DC gain of the F1 QOSEM SUM's whitening stage, we continue on the noise investigations described in T2600496. This aLOG covers Test 2 of that doc -- testing the suspicion that there is some spatial dependence to the (relative) intensity noise on the light of the QOSEM LED, which therefore renders the intensity-noise-reducing LED's drive current feedback loop to behave differently than expected. Namely, the feedback loop uses the SUM as its error signal, but if the SUM is dominated by one QPD quadrant's measure of that region's larger RIN from the LED, and that noise more than the others, then the loop will do the wrong thing and the overall performance will be worse than expected. In short: with the feedback loop OFF, the RIN from each quadrant is the same within measurement uncertainty, ruling out the spatially-dependent RIN theory. However -- and maybe this is the issue, or a symptom thereof -- than raw voltage noise for both channels on all quadrants is much larger than expected; ~4e-6 [V/rtHz] rather than the expected 0.05e-6 [V/rtHz]. A reminder -- in general the QOSEM design suppresses LED intensity noise with the linear combination of two tactics: - When the LED spot position is centered on QPD, then the analog subtraction of half of the QPD's quadrants from the other (the "X DIFF" and "Y DIFF" channels) does the bulk of the work - When mis-centered on QPD, then LED / SUM loop suppression does the bulk of the work. As such, we took the comparison between two channels at these two extremes to hopefully better understand the performance of the subtraction vs. the SUM feedback: - the F3 QOSEM, whose projected LED spot position is not-so-well centered on the QPD. - the SD QOSEM, whose projected LED spot position is well-centered on the QPD, and The ISI was fully isolated, though the sensor correction was OFF. The QOSEM damping loops were OFF (though we measured both ON and OFF and there was little difference). More measurement details will follow in the comments. Attached are the data comparing the two channels with each other with feedback OFF, then with feedback ON, and then comparing LED feedback ON vs. feed. For each of the comparisons I post both the raw voltage noise measured, as well as that same voltage noise converted to relative intensity noise by dividing by the DC voltage. In each plot, the SR785 measurement noise floor is also shown to validate that we're measuring real QOSEM TIA output voltage noise and not limited by our measurement setup. F3 vs. SD FEEDBACK OFF RIN ASD Raw V ASD FEEDBACK ON RIN ASD Raw V ASD F3 FEEDBACK ON vs. OFF RIN ASD Raw V ASD SD FEEDBACK ON vs. OFF RIN ASD Raw V ASD The frequency region we're focused on is the 10-100 Hz region where we expect to be LED intensity noise limited. In F3 and SD sensors, with the feedback OFF, the broad-band noise floor is about 4e-6 [(V/V)/rtHz = RIN/rtHz], and the raw voltage noise is 1e-6 [V/rtHz] = 1 [uV/rtHz]. Tom expected the raw voltage noise to be 0.05e-6 [V/rtHz] = 50 [nV/rtHz]. (And note that this SR785 measurement setup should be able to measure this, if we ever figure out what's going wrong.) Between 3-10 Hz, where the data may appear colorful above the broad-band LED intensity noise floor -- this is confirmed via damping ON vs. OFF tests to be SUS resonances, i.e. more real motion of the suspension, not QOSEM sensor noise. Below 3 Hz, where the data's RIN ASD rises quickly -- this is confirmed to be residual seismic motion, i.e. more real motion of the suspension, not QOSEM sensor noise. See above for preliminary conclusions from this data set, but we'll confirm the conclusion after discussing this with Tom. Next up -- Test 3 of T2600496, which will attempt to rule out coherence between the LED drive and the QPD quadrants when the feedback loop is OFF.

Non-image files attached to this report

2026-11-03_H1SUSBS_M1_TIAOutput_ASD_0p1-100Hz_LEDFB_OFF_CH3_F3_v_CH4_SD_RINprtHz.pdf

2026-11-03_H1SUSBS_M1_TIAOutput_ASD_0p1-100Hz_LEDFB_OFF_CH3_F3_v_CH4_SD_VprtHz.pdf

2026-11-03_H1SUSBS_M1_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_CH3_F3_v_CH4_SD_RINprtHz.pdf

2026-11-03_H1SUSBS_M1_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_CH3_F3_v_CH4_SD_VprtHz.pdf

2026-11-03_H1SUSBS_M1_CH3_F3_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_v_OFF_RINprtHz.pdf

2026-11-03_H1SUSBS_M1_CH3_F3_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_v_OFF_VprtHz.pdf

2026-11-03_H1SUSBS_M1_CH4_SD_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_v_OFF_RINprtHz.pdf

2026-11-03_H1SUSBS_M1_CH4_SD_TIAOutput_ASD_0p1-100Hz_LEDFB_ON_v_OFF_VprtHz.pdf

H1 PSL - PSL 10-Day Trends

ryan.short@ligo.org — Mon, 09 Nov 2026 13:45:32 -0800

Author: ryan.short@ligo.org

Report ID: 92639

FAMIS 63924

The ISS diffracted power is hanging out a little below our desired 4% setpoint, so I'll bump that up tomorrow morning during maintenance. Otherwise, no major events of note this week.

Images attached to this report

H1 SUS - Comment to SUS MASTERSWITCH Ramp installed on all suspension models (and a couple scripts updated)

oli.patane@ligo.org — Mon, 09 Nov 2026 13:30:14 -0800

Author: oli.patane@ligo.org

Report ID: 92638

I wanted to add that these model changes were completed on all LHO current (plus HRTS/HATS) model top-level library parts found in /opt/rtcds/userapps/release/sus/common/models/ except for BHSS_MASTER because I forgot since we don't use that yet. The full list of updated parts is below.

I've also attached screenshots of the MASTERSWITCH before and after the changes.

Updated parts in /opt/rtcds/userapps/release/sus/common/models/:

BBSS_QOSEM_MASTER.mdl
HATS_MASTER.mdl
HDDS_MASTER.mdl
HLTS_MASTER.mdl
HLTS_MASTER_W_EST.mdl
HRTS_MASTER.mdl
HSSS_MASTER.mdl
HSTS_MASTER.mdl
HTTS_MASTER.mdl
MC_MASTER.mdl
OFIS_MASTER.mdl
OMCS_MASTER.mdl
OPOS_MASTER.mdl
QUAD_ITM_MASTER.mdl
QUAD_MASTER.mdl
RC_MASTER.mdl
TMTS_MASTER.mdl

Images attached to this report

H1 SEI - ISI CPS Noise Spectra Check Weekly FAMIS

oli.patane@ligo.org — Mon, 09 Nov 2026 12:22:01 -0800

Author: oli.patane@ligo.org

Report ID: 92637

Closes FAMIS#85080, last checked 92280

Compared to last time:
HAM5, HAM6
- H3 is a bit elevated at 8 Hz
ITMY Stage 1
- H1/H2/H3 are a bit elevated around 8 Hz
ETMY Stage 1
- Everyone is a bit elevated between 3 - 13 Hz

I think they generally look fine to me even with these few differences.

Non-image files attached to this report

CPS_spectra_12:02-11_09_2026.pdf

H1 ISC - h1lsc ready for model change: Adding REFLAIR 9 back in for TR COMM option.

camilla.compton@ligo.org — Mon, 09 Nov 2026 12:19:49 -0800

Author: camilla.compton@ligo.org

Report ID: 92636

Sheila, Camilla, WP 13748

In 92516 we swapped being able to use REFLAIR9 to use the in-vac REFL45 for use in TR COMM locking.

We now still want the option of using REFLAIR9 so added in a second choice for 9 vs 45 then AIR vs invac REFL9. See attached simulink screenshot. Medm has not yet been updated.

This has been saved and committed to svn, so is ready for tomorrow’s h1lsc model restart.

Images attached to this report

H1 ISC - Automating MICH/PRCL/SRCL FF filter estimation

mallikaranjan.sinha@ligo.org — Mon, 09 Nov 2026 10:38:32 -0800

Author: mallikaranjan.sinha@ligo.org

Report ID: 92621

[Mallika, Louis]

TL;DR We're developing a script that will automatically estimate a feedforward filter to mitigate the coupling between DARM and MICH/SRCL/PRCL. Currently testing out a draft Python script on old data to finalise everything. Below are our results on a set of old PRCL feedforward measurements.

We're trying to develop a largely hands-free method for designing the feedforward filters used to mitigate the coupling between DARM and MICH/SRCL/PRCL. What we've developed so far is primarily based on discussion with Elenna, looking at old alogs, chapter 2 from Evan Hall’s thesis, and this helpful document written by Jennie D. (T1600504). The vision for the final output is a script that will:

Take in some measurements
Run a fitting algorithm for a specified frequency range
Output an initial fit for inspection where the operator can choose specific frequency ranges where the fit could be improved
Output a .txt filter file to be imported to the relevant feedforward filter bank

We've adapted Jennie's diagram (figure 1 in T1600504) to include the channel names and where these channels are picked off from in the attached pdf (MICH at any point can be replaced with SRCL or PRCL) The filter, $\alpha$ is the ratio of two transfer functions (1/2):

DELTAL_EXT (DARM) / MICH_OUT (with a MICH excitation)
DELTAL_EXT (DARM) / MICHFF_IN2 (excitation of the actuation path of the filter)

We're working under the assumption that we would measure this with $\alpha=0$ and build the feedforward filter from scratch. In principle you could iteratively build this filter, but we do not consider that here yet. We’ve identified a set of PRCL measurements with $\alpha = 0$ (t = 1408575248.0 79693 for the measurement, and the fit described in 80118, but seems complicated due to HAM1FF 79989) and the feedforward filter designed at the time, and are using this to develop and test this method.

Instead of removing points with low coherence, we use fitting algorithms that can weight certain frequencies. These weights are given by 1/uncertainty, where we convert the coherence of each measurement to uncertainty and add in quadrature. We test a vecfit algorithm that works in the pole-residue space, and Vlad’s chebychef that uses Chebychev polynomials in the zero-pole space. In image 1, we plot the best result from both runs on the PRCL measurement. In purple we have the data, in blue the resulting chebychef filter, and in orange the vecfit filter. The bottom panels show the total uncertainty of the data and the equivalent coherence on the left and right, respectively. The left-hand side shows the result, the right side the residuals from the data/fit. In general, this result has a similar amount of poles and zeros (or equivalent), but the weighting has attributed these to different frequency ranges. We move forward with chebychef, which seems to work better at this stage.

In image 2, we compare the chebychef filter to an old designed filter (brown). There are some differences in features, some of which may or not be physical pieces missing from the chebychef fit. Say we think the feature around 30Hz is something that needs to be modelled, we can manually increase the weight of those points and refit. This gets us to image 3 where we have the old and new fit. The new fit generally does a bit worse, but this feature may have not been real and we could always go again with a different weighting.

Still need to design the roll-off at high and low frequencies, but we have successfully output the .txt file needed to create the foton filter (plotted in image 4).

Images attached to this report

Non-image files attached to this report

MICHFF_cropped.pdf

H1 CAL - Pcal Measurement using IR1 repo update

caroline.capuano@ligo.org — Mon, 09 Nov 2026 09:17:11 -0800

Author: caroline.capuano@ligo.org

Report ID: 92626

update from alog 92611

After pushing and pulling again from the git, I was able to pull the updated files and ran another PS5 PS6 measurement. This measurement ended up failing because of some indentations in the PSparams.yaml file (see attached image). I quickly fixed the indentation in the local file and ran another measurement. I won't push everything to git until I get approval from Tony, but I just wanted to make this small correction to see if it fails again (and for what reason).

The second measurement failed because of a simple formatting issue that was easy to fix (see attached image for error message).

The third and last measurement I took on Friday also failed due to an index error (see attached image for error message details). After the measurement runs, pcalRRS_diagnose_ratios.py re-reads all previous PS5/PS6 measurements to compare ratios. It read the 131006 and 154452 measurements fine but crashed on 20261106_181857.yml with IndexError: list index out of range in pcalRRS_analyze.py (line 131, calc_set). That measurement seems to have fewer background readings than the code expects, probably because it was a failed run from Friday that saved incomplete data.

CAL

Images attached to this report

H1 General - Ops DAY Shift Start

oli.patane@ligo.org — Mon, 09 Nov 2026 07:36:17 -0800

Author: oli.patane@ligo.org

Report ID: 92634

TITLE: 11/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 6mph Gusts, 4mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.39 μm/s
QUICK SUMMARY:

useism is still a bit high (0.4 um/s), but seems to be coming down. I'll try to run an initial alignment and start relocking