Sheila, Ibrahim

PRMI locking waited a long while with high counts before going into MICH so Sheila changed the timer from 20 mins to 10 mins. 

Lockloss seemingly due to ground motion instability. In the last 6 hours, the microseism increased by an order of magnitude. 

PRG and ASC signals have been oscillating every few minutes since I started shift (and seismic was in micreoseism).

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

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

Range and wind are stable. Microseism is on the rise.

Plan is to stay OBSERVING

TITLE: 10/17 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Relocking and at MOVE_SPOTS. We were having a bit of a rough start trying to relock after the lockloss - for the first few minutes ALSX was buzzing weirdly, but then it went away on its own. I briefly checked the quad movements, and it looks like it may have been caused by ETMX Y moving to adjust the alignment. We then were having trouble locking DRMI or PRMI, so eventually I started an initial alignment and that helped a lot.
LOG:

23:30UTC Observing and have been Locked for 1 hour
    23:49 Earthquake mode activated
    23:50 Out of Observing to run ASC Hi Gains
    23:59 GRB-Short E610763 https://gracedb.ligo.org/events/E610763/view/
    00:09 Back into Observing after going back to nominal gains
    00:09 Back to CALM
03:06 Lockloss https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=87534

Lockloss at 2025-10-17 03:06 UTC after over 4.5 hours Locked. Unsure of cause.

TITLE: 10/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: The DARM fom struggled this morning as it wasn't getting data from GDS and sometimes nds2, ETMY beam spot adjustment alog87508, and we had to swap the ITMY L2 sat amp box alog87515. A PRM filter was also turned off alog87523, and I accepted some CDS calibration report related SDFs. After we relocked post sat amp swap there was a 1Hz ringup seen in ASC, but it calmed down.
LOG:

• 15:00 UTC GRB-Short E610703
  • 15:10 - 15:30 UTC Observing after relocking at 15:07 UTC
• 18:00 - 18:32 UTC Calibration measurement
• 18:45 While Jim was running an ISI HAM5 measurement SUS IY started to report OSEMs in fault and was flashing the red "Rocker Death Switch" on L2, possible Sat Amp issue
  • 19:31 UTC Observing
• 19:54 UTC Dropped Observing to turn L2 feedback back on, half hoping it would break the lock
  • 20:03 UTC We broke the lock to swap the Sat Amp box, Jeff flipped the polarity of IN2 on the IMC common mode board as we do before Tuesday maintenance
  • 20:05 UTC SEI to maintenance for Fil to go into the biergarten
  • 20:16 UTC recovered SEI/SUS and back to locking
  • 20:44 UTC IA
    • The alignment still wasn't great, we couldn't get DRMI and it took 12 minutes to get PRMI with me helping PRM and the BS. I had to move SRM in pitch a decent amount considering that we just finished an IA
  • 22:28 UTC Observing

TITLE: 10/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.16 μm/s 
QUICK SUMMARY:

Observing at 150 Mpc and have been Locked for 1 hour. Looks like everything is going well now.

J. Kissel

The ETMs have L2 to R0 "tracking" in longitudinal (in addition to pitch and roll "damping") L2 sensing to R0 actuation. It's referred to as "tracking" rather than "damping" because the open loop gain is greater than unity over a much broader frequency region, focusing around 0.1 Hz.
These, like the P and R damping, didn't change after the sat amp swaps.

The templates to take this data lives here:
    /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGR0/Data
        2025-10-14_1830UTC_H1SUSETMY_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_L.xml

    /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data
        2025-10-14_1830UTC_H1SUSETMX_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_L.xml

J. Kissel, S. Dwyer, E. Capote

We recently re-discovered that H1SUSPRM M3 DRIVEALIGN matrix has an L2P filter ON with gain of -1.36 that was designed in 2014 (see LHO:9589). Unsure of its function/performance with the modern IFO, we wanted to test turning it OFF. We turned it OFF (by ramping the gain in that bank to 0.0 with a 10 sec ramp time) at the end of the most recent lock stretch, with the IFO in nominal low noise (just after Elenna's calibration push; LHO:87520). Namely the IFO was suffering from a failed H1 SUS ITMY PUM sat amp, and we knew we needed to replace it, so we were looking for "useful" ways to break the lock.

Turning off the H1 SUS PRM M3 DRIVEALIGN L2P filter, at first superficial glance, has no impact on the IFO excpet for reducing the M3 pitch drive from +/- 300 to +/- 2 (Euler Basis) DAC Counts.

For more in-depth analysis, 
    - 2025-10-16 18:45 UTC the problems with the ITMY satamp started
    - 2025-10-16 19:54 UTC we turned off the PRM M3 L2P filter, and
    - 2025-10-16 20:02 UTC I caused the IFO lock loss by inverting the polarity on IN2 of the IMC common mode board.

So, we should have a good 5 minutes of time right before vs. right after to compare ISC ASDs.

We also tried this next lock acquisition with the filter OFF, to see if it's still needed for lock acquisition.
PRMI isn't locking after 10 minutes of trying (*after* going through MICH fringes), though we did NOT run an initial alignment prior to this lock attempt and the AS port does look a little splotchy.
Turned it back on 2025-10-16 20:39:44 UTC, but pretty quickly decided to run initial alignment instead (by 2025-10-16 20:42:57 UTC).
We'll leave it ON and test more / again some other day; we'd rather get back to observing.

18:45 UTC While Jim was running a measurement on ISI HAM5, SUS ITMY started to flash its' red Rocker Switch Death on L2 and report that its' L2 OSEMs were in fault, we also noticed there's a big new line at ~92Hz. Jeff turned off feedback from L2. It looks like it could be a sat amp issue, the L2 sat amp was upgraded this past Tuesday alog87469. Jeff is starting to work on characterizing a sat amp box in the EE shop to swap in. 

We would need a lockloss to swap this component.

We are going to try to go back into Observing for a bit until we can fix it or lose lock.

J. Kissel

This past Tuesday (Oct 14 2025), we upgraded the L2 (PUM) OSEM PD Sat Amps to improve their whitening filter, per ECR E2400330; see LHO:87469. These QUAD L2 PUM OSEMs (in which the flags are on the QUADs main chain PUM, and the LED & PD are on the reaction chain PUM [aka the "PenRe"]) are used in feedback. This "damping" of a "3.3" Hz reaction chain resonance is different ITMs and ETMs (ITM Install = LHO:65728; ETMs Install = LHO:68012 --- commissioning of both = LHO:68200); the ITM has resonances at 3.28 / 3.31 Hz and the ETM has modes at 3.18 Hz / 3.42 Hz.

Because the improved sat amps come with better compensation of the whitening filter frequency response, we know that the frequency dependent gain on each channel -- especially around 3.3 Hz may change by as much as ~10%. 

In the aLOG (and comments collection) I report 
    (a) That we *did* see a change in the open loop gain TFs of these loops, but (after ~2 days of observing since the upgrade) the IFO doesn't seem to mind the changes.
    (b) We were able to get better coherence on the open loop gain TFs in the 0.1 to 10 Hz region because of the sat amp whitening improvement
    (c) A comparison between all four QUAD's PITCH and YAW damping, so that we might understand them better and potentially improve them.

In this main aLOG I show the comparison between the PITCH and ROLL open loop gain TFs and loop suppression for all four QUADs.

Rushed commentary:
    - The surprising thing to me is that we're getting gain peaking and/or some suppression of other modes below 1 Hz, which I'm confident was not the design intent.
    - Even though the filters and EPICs gains are the same for EX and EY, ETMX has a lot more open loop gain below 1 Hz.
    - Also though the ETM loop suppression is about the same on these 3.18 / 3.42 Hz, the ITM loops have pretty different amount of gain peaking.
    - I'm guessing we *don't* want this much sharp gain peaking just *off* the "3.3" Hz mode.

Summary: Since we have made many changes to DRMI over the last few weeks and locking is much slower than it was, I started trying to restore us to the old configuration which worked pretty well.  We have locked DRMI 6 times since, none of the acquisitions have taken longer than 8 minutes. (see second attachment)

Lesson for the future:

We should be much more careful about making changes to DRMI acquisition, and look at locking statistics to evaluate whatever we do.

TJ Massinger pointed out that there is a page that already displays times, ISC_LOCK summary.  If you scroll to the bottom and click on the state LOCK_DRMI_1F [101] you can see a list of the locking attempts and their duration. Craig and I used this data to make the histograms in the second attachment.  We were locking much more quickly in Sept 9-12 than in the first days of October, and after making the changes tonight the times are closer to what we had in mid September although the distribution will probably not be as good. 

I think our approach going forward should be to wait a few days after making a change, and get several tens of locking attempts for statistics before we make a change.  If we compare the locking statistics before and after the change, and they are better, we can go ahead try another change if we want to then.  

Details:

I compared changes in the DRMI acquisition settings for LSC using conlog.  The two times are used are Sept 12 2018 at 21:43 (1220823832), this was a week when we remember DRMI locking quickly and looking back at the data confirms that it was locking quickly. Now DRMI locking is consuming a lot of time, and we have made many changes and aren't sure which of the changes made are the problem.  

I was reluctant to make changes to SRCL FM1 because that is the filter that has twice given huge and inexplicable outputs when we modified it. 

Things I haven't done which could be done (after collecting some stats about this state, if we want to try to get closer to Sept):

• Run conlog for these times for the suspensions, starting with BS, then PRM and SRM
• check the filter archive for differences in LSC, BS, then PRM and SRM
• check the guardian svn (or git) for differences Sept 12 to now.