Today we've had to run many initial alignments and mess around with mirror alignments to cajol DRMI into locking. In the first part of the day, we were coming back from a big earthquake which had kept us down for hours. I don't know what we can attribute the struggle to lock to, but it can't be related to the BS heating since we had been down for many hours.

Later in the day, we were relocking after a few hours up, and just after the lockloss we proceeded to DRMI locking. The alignment was very poor. The guardian quickly took us to PRMI and then MICH FRINGES because of the very bad alignment. This is perhaps a sign that the BS slow release method isn't working so well, since it should keep the alignment decent just after lockloss. I cleared the history on the BS M1 pitch lock bank, and proceeded to help the MICH FRINGES and PRMI state by hand. Once we got back to DRMI we were able to lock relatively quickly.

I am suggesting that our DRMI locking problems are "maybe not an alignment issue" because this morning after several alignments, DRMI took a very long time to lock, and just after lockloss in the afternoon, where the slow release method should help keep the alignment good, the alignment was very bad. Maybe we should look into the triggers or engagement of the locking to see if there is a problem there. Just based on my experience this afternoon, I would want to turn off the BS slow release, or recheck that it is doing what we want it to do.

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

Relocking notes:
Today started off with an Initial_Alignment that was interrupted by earthquake mode being reactivated.
Which prompted another Inital_Alignment.
While trying to relock there was many attempts at the  DRMI-> PRMI-> Check_Mich_Fringes which yeilded no locking results.
Another Initial Alignment happened, Which allowed us to lock DRMI but we caught a lockloss at LOW_NOISE_COIL_DRIVERS, and on the next attempt OMC_WHITENING.

After that H1 Bouced around through DRMI-> PRMI-> and Check_Mich _Fridges again until another Inital_Alignment was ran.

We finally got back to NLN at 20:54 UTC and were locked for a little over 2 hours before the 4pm Lockloss struck.


LOG:                                                                           

Today while in DRMI ASC, and while trying to debug other problems with DRMI acquisition, Ryan, Tony, and I saw that the DRMI ASC starting pulling the buildups in a bad direction, which made no sense. We were trying to figure out which loops were the culprit, when I saw that the SRC1 offsets were engaged. These offsets had been put in place during the problems with the OFI, and we don't run with these offsets in full lock anymore. I turned the offsets off and the buildups starting moving in the good direction again. This is very confusing, because we've been running like this for ages probably without a problem. Today it was suddenly a problem. I commented out the lines in the ISC_DRMI guardian state PREP_DRMI_ASC where these offsets are turned on and loaded.

TITLE: 07/07 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: H1 just lost lock after a couple hours of being locked, so starting relocking now.

• Wind and microseism low
• All other systems nominal

 M. Todd, S. Dwyer

We moved the OPO crystal around again, following the work we did last week. We had much better luck this time with the translation stage controller (until the end, where we seemed to lose where we were).

After we took the measurement at -1100, we decided that given the historesis in the controller the better way to go back to a "position" was to set our OPO temperature to the value that corresponded to that position and move the controller until we re-found the green/ir coresonance.

We tried this, and then got veeery lost. But eventually found our way closer to our high NLG and ~31.4 OPO crystal temp, but it was not at the position we expected it to be at. This method may be refined in the future, where instead of doing finite steps with the controller to map out the NLG parameter space, we could sweep the OPO temp and follow it with the controller position via the co-resonance.

Regardless, we are at a much higher NLG than when we started!

18:52 UTC lockloss while we were in OMC_WHITENING damping violins

Below is the summary of the DQ shift for the week from 2025-06-16 to 2025-06-22

• During this week, the average BNS range was ~150 Mpc with a low of ~130 Mpc and a high of ~160 Mpc.
• The average duty cycle of this week was ~69%.
• We did see some line structures in the strain spectrogram at different frequencies, some of the causes are not obvious.
• There was some excess earthquake motion on Monday, Wednesday, Saturday, and Sunday.
• The wind motion was excessive on Tuesday and Thursday.
• Thursday, the glitch rate was pretty high due to the wind.
• There is a line structure at ~ 7 Hz in the corner BSC Y arm throughout the week. It was more significant on Friday.
• Hveto summary is not available on Saturday. Mostly, ASC (H1:ASC-Y_TR_B_NSUM_OUT_DQ -top count) channels were the winning channels, but other channels also won on some days.
• Lasso-No channels with significant correlation this week.
• Line count from FScan was below the alert threshold throughout the week.

The full DQ shift report with day-by-day details and plots is available here.

Mon Jul 07 10:07:08 2025 INFO: Fill completed in 7min 4secs

Gerardo confirmed a good fill curbside.

TITLE: 07/07 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 5mph Gusts, 1mph 3min avg
    Primary useism: 0.29 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:
H1 Unlocked due to earthquake when I arrived.

I think the ground motion has come down a fair amount, and in a few minutes we will be leaving EQ mode.
I've started an Initial Alignment to start getting H1 locked again.

12:39 UTC H1 called for help for the initial alignment timer expiring, I found Yarm to be notifying "Find by hand" so I helped it out and it locked after a few taps of ETMY and ITMY.

13:07 UTC finished IA, back to locking

11:14 UTC lockloss from an ETMX glitch

TITLE: 07/07 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 138Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Quiet shift where H1 remained locked throughout, although I did drop observing once briefly to run a SQZ angle scan, but it didn't make an improvement (afterwords I remembered the angle servo is running now, so it makes sense why it was already optimized). Current lock stretch is up to 9.5 hours.

• 03:11 - Dropped observing to run SQZ angle scan
• 03:15 - Observing

Link to DQ Shift Summary here

• The duty cycle for this week was 53.9%
• h(t) spectrograms looked normal throughout the week with some noise in high frequency spectrum due to environmental factor. 
• Seismic, wind and ground motion remained relatively low except for Wednesday, July2 and Friday July 4 which had high seismic activity, which cause noise in the PEMs and in the h(t) spectrograms. . 
• Glitchgram showed large amount of high SNR glitches for some days with increase in glitch rate. 
• HVETO Summary was not available for Monday June 30, Wednesday July 2. All others days summary showed different channel winners every day. 
• FScan plots were available except for Sunday, July 6 with the line count remaining at around 2300 well below the threshold except for Thursday, July 3 which had a line count of a little above the threshold of 2600. 

TITLE: 07/07 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 138Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
I had to run an Initial alignment twice this morning before H1 would get past DRMI and Evetually reached NLN at 16:41:30 UTC.

@ 14:07 UTC Unknown Lockloss today.

Relock needed another Initial Alignment to get past DRMI. We eventually Arrived back at NLN at 19:26 UTC.

@21:01 UTC I noticed the Range drop and I started to Troubleshoot Range Related SQZ  issues.

LOG:

I noticed that the Range started to drop, and the guardians had some things to tell me.

I followed those instructions in the guardian messages and requested RESET_SQZ_ASC_FDS[97]

Immediatley, ZM4 Started to Saturate and wouldn't stop even if I took SQZ_MAN to down.
I eventually took ZM4 to Damped for a few minutes while I try to find a solution.

One of the solutions I tried were to "Gracefully clear the SQZ-ASC offsets.

Eventually I figured out that ZM4 slider needed to be moved in pitch since it had drifted off quite far.
I got SQZ_MAN back to  FREQ_DEP_SQZ to see if that ZM4 move made a difference.

It did not..... then I requested a SCAN_ALIGNMENT_FDS to see if that would help.

I then took a Low range Coherence plot and a comparision plot from before the range fell in this lock and after.

Then I adjusted the OPO Temp and then requested SCAN_ALIGNMENT FDS again.
I was only able to get the range back up to 138 Mpc.

We had been locked for just over 3 hours, the circulating power was ~378.5kW in each arm, a little under the usual 380kW.

Broadband:

Start: 2025-07-04 00:50:39

Stop: 2025-07-04 00:55:50

Data: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250704T005039Z.xml

Simulines:

Start: 2025-07-04 00:56:56.978617 UTC // GPS: 1435625834.978617

Stop: 2025-07-04 01:20:13.539672 UTC // GPS: 1435627231.539672

Data:

2025-07-04 01:20:13,381 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250704T005657Z.hdf5
2025-07-04 01:20:13,389 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250704T005657Z.hdf5
2025-07-04 01:20:13,394 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250704T005657Z.hdf5
2025-07-04 01:20:13,398 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250704T005657Z.hdf5
2025-07-04 01:20:13,403 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250704T005657Z.hdf5

Using a script called histogram.py which calls statecounter2.0, I was able to determine how many times ISC_LOCK spent more than 60 seconds in ACQUIRE_DRMI_1F using Minute trends.

I broke this up into Pre Vent and Post vent:
Pre Vent:
Jan1st to April 1st 2025
Length of data 601
max Duration 19 Min
Average 3.5640

Post Vent:
June 1st 2025 to now
170 data points
Longest:  24 minutes.
Average: 5.1823 Min

Post vent break down.... break down:

Jun 1st to Jun 16th
Length of data 100
max Duration:  24min
Average 5.04 min

Jun 16th - now
Length of data 70
max Duration 13 Min
Average 5.38571

Link to a google sheet with all the exported data, and GPS times.