WP 12836
ECR E2400330
Modified List T2500232

The following SUS SAT Amps were upgraded per ECR E2400330. Modification improves the whitening stage to reduce ADC noise from 0.05 to 10 Hz.

F. Clara, J. Kissel, O. Patane

After maintenance wrapped up this morning, I swept through the LVEA to prep for observing. I unplugged an unused extension cord near the PSL racks and the scissor lift in the vertex/west bay area. Everything else looked okay.

Jeff also mentioned that he moved an SR785 from the PSL racks into the Biergarten for his work this morning, but it's unplugged (in case someone goes looking for it later).

I have created an EPICS IOC which reports any Guardian nodes which use source file(s) which have been modified in userapps but have not been loaded into the nodes. On the next restart of such nodes (e.g. guardian reboot) the new code will be automatically loaded, and so this system permits us to load new code in a scheduled and orderly way, for example by the code-author/node-manager during Tuesday maintenance.

This is similar to the front-end filter-module configuration file change (CFC) system, so I've called this GRD-CFC.

The CDS Overview MEDM has a "GRD CFC" button at the bottom showing the GRD-CFC status as GREEN/YELLOW. Pressing this button opens the H1CDS_GUARDIAN_CFC.adl MEDM (attached).

This MEDM has three main areas:

• Top is the system overview. the magenta box encompasses the CFC summary (it will be yellow if one of more nodes are in need of reloading), the STATUS shows the IOC status
• Middle is the main Guardian nodes table. The grey boxes will turn yellow if any node has one or more source files which need to be loaded
• Bottom is the IOC details section. the yellow box encompassing server start and runtime information. The red box encompasses the database files' validity.

If any nodes are reporting pending changes, you can get pending file details by running the shell command:

guardian_modified_not_loaded

The output from this command provides information on how to list the line differences between pending files and what is running.

Tue Oct 14 10:08:10 2025 INFO: Fill completed in 8min 7secs

Rebooted h1guardian1 at 1547UTC so that we could start with fresh fresh and it would become easier to manage any file differences with help from some of Dave's new screens and scripts.

All nodes started up on their own, and Ryan C helped me recover them all back to a maintenance state.

I went to test the high gain ASC states I made for SEI_ENV this morning while we were still locked this morning. The good news is that there were no errors in the code and it did exactly what I asked of it. The bad news is that we lost lock while transitioning back to a low gain state. This wasn't a great test though because I had a brain fart and forgot to change the thresholds for the test. The high gains were turned on, then immediately turned back. So I'm not entirely sure if the lock loss was from the transition back, or just the fact that we quickly flipped it back and forth. 

The major change between what SEI_ENV does and what the script the operators use right now is that the sleep timers between engaging/disengaging each loop are almost completly gone. At minimum for the next test it seems that we need some for the return back to low gain, or maybe increased tramps.

On the bright side, it looks like the structure of the node and the code seems to work, just need to tune it a bit. For now I've returned this node back to its normal operation, without the high asc states.

M. Todd

Today I ran another OMC scan (following last week's instructions alog 87316 and 87342) after the morning lockloss to see if could a better measurement of the hot state overlaps.

I was still limited to about 12 minutes after the lockloss, so we expect some amount of difference in the full hot state.

I've plotted the results on top of last week's scans, in yellow. Analysis of this will follow in a comment.

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

The second stage heating contactor had burned up, reducing heating capacity. This is why the zone had difficulty maintaining set point on 10/13. I replaced the ruined contactor and checked functionality. 

TITLE: 10/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 10mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.26 μm/s 
QUICK SUMMARY:

• Secondary microseism looks to be rebounding after increasing into the night
• We've been locked for ~19 hours
  • PEM_MAG_INJ node is in error (Key error 'freq_low')
  • The operator WS was stuck at "failed to unmount" when I arrived
• 11:33 UTC Superevent S251014cn

TITLE: 10/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

IFO is in NLN and OBSERVING (~10 hr lock)

2:53 - SQZ Dropped

4:10 - SQZ recovered, back to OBS

Mostly quiet shift except for the SQZ dropping due to FC lockloss.

The Squeezer FC lost lock due to FC2 alignment walking away from a lockable GR_LOCKED configuration. As per the wiki, I trended the last time we had a stable lock and reset values for FC1, FC2 and ZM3 (P/Y). Then, I tuned FC2 a bit more to maximize GR_TRANS output. This worked.

Interestingly, I first tried an alignment from a few days ago but this didn't work. I did this because FC2 has been increasing quite a bit in the last few days (screenshots) - probably worth looking into. The values I set FC suspensions to (using opticalign sliders)

FC2 P: 1558, FC2 Y: 109.6 

FC1 P: -899.6, FC1 Y: -74

ZM3 P: -66.25 ZM3 Y: -463

I hope this issue doesn't happen again during OWL shift though the trend below from a few days ago shows FC2 P going up for the last few days seemingly with SQZ compensating in its alignment. Anecdotally, it seems related to the temperature since there's a diurnal breathing day to day (lows at night, highs in the day). Tagging SQZ to look at FC2 and FC.

LOG:

TITLE: 10/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Locked for 4 hours. We had one lock loss during commissioning time today, though it does not seem to be caused by any commissioning activites. useism is on its way up, and the wind is gusting above 30mph at times. 
LOG:

• 1543 Commissioning start
• 1740 GRB short E609775
  • Since we were already commissioning we will not stand down
• 1747 Lock loss
• 1817 GRB short E609786
  • Relocking, no stand down
• 1917 Observing

In 86964 I ran a side by side comparison of the powers at various ports before and after the power outage so we could determine what, if anything had changed. Although it generally seemed like we had regained or even increased the powers everywhere, kappa C has indicated that the optical gain reduced. Our current kappa C has been consistently near 0.98 since the outage.

However, I calculated the full optical gain value today from the most recent calibration report (20251012T200500Z) and the current exported report on August 23 (20250823T183838Z). Each report lists H_c in ct/m. I also chose a time just before each report was measured to calculate the OMC-DCPD_SUM/LSC-DARM_IN1 transfer function that provides the mA/ct calibration value.

It seems like our optical gain between these two times has actually stayed the same to much less than a percent. I'm not sure what to make of this with regards to the calibration, given that the calibration report suggests an overall magnitude change in the sensing function (that we are correcting in the TDCFs), but in actuality the magnitude of the sensing function has remained constant.

TITLE: 10/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 19mph Gusts, 14mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.31 μm/s 
QUICK SUMMARY:

IFO is in NLN and OBSERVING (4 hr lock)

Wind is pickign up. Secondary microseism is picking up. Hoping to stay quiet and locked for the shift.

For the SR3 P estimator, we had initially developed and installed blend filters (in H1:SUS-SR3_M1_EST_P_FUSION_MEAS_BP and H1:SUS-SR3_M1_EST_P_FUSION_MODL_BP filter banks), named pit_v1, that blended between the OSEMs on-resonance, and the estimator everywhere else (86452). After a bit, Brian Lantz made a pit_v2 that included OSEM damping at two extra frequencies because we were having issues with extra resonances at 0.65 and 0.75 Hz that weren't being damped (86510)(filter comparisons).
Eventually we realized the reason why those two peaks weren't being damped was because we had forgotten to include the model contribution to P from L, and we installed those needed filters(86567). However, we didn't swap the blend filters back to pit_v1 at the time.
So during relocking today (2025/10/13 19:05:00 UTC), I swapped us back to pit_v1. We will run with this until at least tomorrow morning and then verify that we don't see a difference in the damping of those two peaks.

Another big EQ rolling through.  This one is down near Antartica!  Debated when to transition to "ASC Hi Gn", since R-wave was going to be 45-60min.  But S&P waves triggered EQ Mode + saw a yellow Picket Fence---Clicked on ASC Hi Gn button, but during the transition H1 lost lock.  This might have been too big for ASC Hi Gn regardless, but kinda wished I clicked it earlier.

Winds were peaking just under 40mph around the lockloss as well.

Will be hanging out here for a few hours. 

• 2040 Notification of a M7.6 EQ down near Antartica at the Drake Passage
  • R-wave due to arrive in ~1hr and is in the yellow/red area on EQ Response plot (see attached)
• 2043 Start seeing Picket Fence activity (no colors tho)
• 2045 L1 goes down
• 2045 Start seeing S&P Wave spikes on 0.03-0.1Hz Band on nuc5
• 2048 EQ Mode Activated and also get get yellow Picket Fence
• 2049 Turned on Hi Gain ASC
• 2049 H1-LOCKLOSS
• 2050 Keeping ISC LOCK at READY while riding out EQ.
• 2059 Red Picket Fences -AND- SEI_ENV to LARGE_EQ -AND- SEI_CONF goes to LARGE_EQ_NOBRSXY
• 2101 V1 goes down
• 2125 Saw some light BLUE Picket Fences!  (which most likely corresponds with the R-Wave arrival)
• 2135 R-Wave peak (Same or a little bigger than the big Philippines last night). 

Now we wait for R-wave which is probably due to arrive around 2135-ish utc.

E. Capote, J. Kissel, S.Dwyer

The ~1 Hz ring-up that had been marginally stable and transient is now fully unstable during the lock acquisition sequence as we recover from maintenance. The suspicion is that the change in ITM M0/R0 satamps might have changed the top mass damping loop OLGTF enough to augment the damped plant that's the plant for the never-really-well-designed L2DAMP that takes the L2 (or PUM) OSEMs and feeds back their sensor signal to the reaction chain top mass OSEMs actuators. But also, we've never measured these loops in any substantial form, so we wanted to just see what they were doing.

Attached are the results. Here're the templates:
    /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/
        2025-07-08_2240UTC_H1SUSITMY_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_P.xml
        2025-07-08_2240UTC_H1SUSITMY_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_R.xml

Very little loop gain and only at 3.3 Hz. The loop stability is questionable at that frequency -- for a few averages the suppression (i.e. the gain peaking) looks really sharp around 3.3 Hz. 
T'was really tough to get good coherence; the excitation is pretty well tailored, but it's tough to fight the 1/f^6 suppression of the physical suspension and dirt coupling.
I had to turn OFF the R0 alignment offsets to get this data for pitch. (They were ON for the Roll measurement).

So -- perhaps not the source of the ~1 Hz IFO instability, but boy could this loop use some TLC in order to more effectively achieve its goals...