Lockloss @ 01:50 UTC - link to lockloss tool

No immediately obvious cause. We had an incoming EQ alert at the same time, so I thought an S-wave could've hit and caused the lockloss, but no noticable ground motion was seen at the time.

TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:  Currently Observing and have been Locked for almost 2 hours.
LOG:

14:30 Detector already unlocked and maintenance started

19:37 Took detector to DOWN and then started an initial alignment
    - Couldn't see ALSX at all, ended up running the dither align scripts (TMSX, ITMX, and ETMX) and then using the quick sweep from the ETMX dither align script to find a good alignment for ETMX
20:47 Initial alignment done, relocking
21:37 NOMINAL_LOW_NOISE
22:00 Observing
22:22:06 - 22:22:15 Quick jump out and back into Observing due to misclick

23:20 - 23:30 The second Norco truck came down the Xarm and by the corner station on the way back from a CP fill at MX, causing some ground motion tagging Detchar                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

TITLE: 06/25 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 9mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: H1 has been locked and observing for 1.5 hours. Sounds like relocking after maintenance went smoothly.

• Norco truck is still at MX
• Wind and microseism are low
• All other systems nominal

13:10-13:40UTC. Adjusted ZM4 PSAMs to 2 different settings this morning as LLO started an extended maintenance period.

Only adjusted ZM4 PSAMs as ZM5 seems to have more effect but is harder to realign after, last large raster in 76986.

In each of the two steps, I adjusted the PSAMS offset, used alignment sliders to bring the alignment back, ran scan sqz alignment. 

• Started with ZM4 PSAM strain voltage at 9.0V
• Tried 9.75V: plot squeezing looked bad and not flat (can't optimize low freq yellow BRLMs at the same time as high frequency blue BLRMS)
• Tried 7.5V: plot squeezing looked good and flatter here 4-4.5dB squeezing, range increased from original settings to 152MPc plot (but we hadn't recently optimized in the original settings). 
  • Leaving PSAMs and ZM alignment in this configuration. Can revert during maintenance if we want. 
  • Good SQZ time for 5 minutes: 1403357710 (2024/06/25 13:34:52 UTC) to IFO unlocked 1403358016 (2024/06/25 13:39:58 UTC).

TJ, Camilla. We turned off the HWS SLEDs to save their lifetime as the HWS hasn't been well aligned since our April SRC alignment shift. These channels are not in sdf. We started to realign them in 78083 but paused as may change our SRC alignment  again.

Closes FAMIS 28360

The in-lock charge measurements were not run this week.

There was two different sets of anchors drilled for the EMT support in the LVEA, one set on the technical slab, near the termination slab, and the second set on the termination slab (Y-Arm).

(Gerardo)
Anchor holes were drilled for two unistrut post bases, they are for supporting the long run of EMT, anchors were dropped in and unistrut post base was fasten, no issues to report.

(Janos, Isaiah, Gerardo)
The 3 high voltage cables, for the filter cavity tube ion pumps, that were pulled during the last couple of weeks were switched from their temporary controller, in the LVEA, to their permanent controller, in the mechanical room, no issues encountered during the switching process.  Next step is to get the controller signal cable connected to the vacuum rack, and get them into their respective MEDM screens.

(Isaiah, Gerardo)
Drilled the last four holes for the short supports, the post bases were anchored without problems, and the rest of the components were fasten to the footings to support the EMT run.

The LVEA has been swept, the only thing I noticed was an unused extension cable left plugged in next to the bier garten which I unplugged.

FAMIS tasks 24924 and 24948, WP 11941

Procedure checklist for both stations completed.  No issues were identified at this time.

MY: Scroll pump hours: 80.6

       Turbo pump hours: 216

       Crash bearings: 100%

EY: Scroll pump hours: 79.2

       Turbo pump hours: 1284

       Crash bearings: 100%

Tue Jun 25 10:08:05 2024 INFO: Fill completed in 8min 2secs

Gerardo confirmed a good fill curbside.

[Dave, Erik]

Dave found that DACs in h1sush2a were in a FIFO HIQTR state since 2024-04-09 11:33 UTC.

FIFO HIQTR means that DAC buffers had more data than expected.  DAC latency would be proportionally higher than expected.

The models were restarted, which fixed the issue.

[Erik, Marc, Dave]

h1susex now has a a LIGO 28-bit 32-channel DAC installed.

The timing card was also swapped out for a new card with firmware that's compatible with the DAC.

h1susex now boots from h1vmboot0 running models built with RCG 5.3.0, necessary to support the DAC, as opposed to the rest of the front ends which boot from h1vmboot1 running RCG 5.1.4.

The timing fanout is reporting an firmware version error on the port for h1susex  (physical port 4, medm port 3).  This is probably because the firmware on the timing card is new.  We think we can run with this error.

DAQ Failure

After the install, DAQ leg 0 was restarted but it only connected to h1susex.  When setting up bootserver h1vmboot0, I'd accidentally replaced the DAQ master file.  Restoring the old master file resolved the issue.

Fil, Camilla

After finding that the sqz laser glitches may be linked ot the last 9th May TTFSS swap 78549, today Fil and I swapped  D2300329 Laser Locking Fiber Beat Note Chassis back to the original.

Installed Chassis S2300258
Removed Chassis (but left in the rack) S2300259

To avoid issues seen after swapping chassis before 77754, 77746 we may want to adjust TTFSS beatnote threshold polarization as RFAMP has dropped from 7.7 to 1.8dB. Plot

TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY: We went down earlier to start our early maintanence day.

State of H1: Observing at 153Mpc; locked for almost 7 hours.

Dropped observing from 23:42 to 00:17 UTC to implement new SRCL FF (alog78632), get 12 minutes of no-SQZ time (from 23:52 to 00:04 UTC), and optimize SQZ angle with the SCAN_SQZANG Guardian state. Otherwise, it's been a quiet shift so far.

Jennie, Ryan S, Camilla

After Jennie's 78629 measurements, we fit the SRCL FF (not time for MICH). Possible we might add noise at 300Hz but this is FF looks overall better.

Old SRCLFF was FM2 with gain 1.18 (didn't account fort this is code but should have changed this to 1 for best iterative fitting). New FF is FM4 gain 1.18. Plot attached. SDF saved and ISC_LOCK edited and loaded.

A few weeks back Oli put in an alog about IMC and SRM M3 saturations during earthquake lock losses. In April of 2023 Gabriele had redesigned the M1-M3 offload, reducing the gain of the offload somewhat to get rid of 3-ish hz instabilities in the corner cavities. This may have contributed to the SRM saturations that Oli found, so we want to try adding some low frequency gain back into the SRM offloading.

Sheila wrote out the math for me for the stability of both the SRCL loop and the stability of the M1-M3 crossover, so I have been looking at ways to increase the low frequency gain without affecting the stability above 1hz. The open look gain for SRCL looks like :

SRCL_OLG =  SRCL_sens * SRCL_FIlter * (SRM_M3_PLANT+SRM_M1_LOCK_FILTER * SRM_M1_PLANT);

The SRM M1-M3 offloading looks like:

SRM_OFFLOAD_OLG = SRM_M1_LOCK_FILTER * SRM_M1_PLANT * SRCL_sens * SRCL_Filter / (1-SRM_M3_PLANT * SRCL_sens * SRCL_FILTER);

Both of these are (or behave like) open loop gains (g), so the suppression/gain peaking can be show by looking at the 1/(1-g) for each.

I made a 50mhz boost filter for this and tried it during the commissioning window this morning. Bode plots for the boost (red), boost *m1 lock filters(blue) and the nominal M1 lock filter(green) are shown in the first image).  The affect on M3 drives and SRCL are shown in the second image asds, live traces are with the new boost, refs are without. There is good reduction below 100mhz, but there is gain peaking from the M1-M3 offloading at .2-.4hz. which might bleed into the secondary microseism during the winter. I'm working on a filter with similar gain, but less gain peaking in a region that won't affect the overall rms of the m3 drive as much. I will try installing and testing during maintenance tomorrow.