After Gabriele's CHETA tests with the Hamamatsu Detectors in CIT#612 . We compared to our CO2X VIGO PWM 10.6 diodes.

The coherence is much worse between the two IN and OUT diodes (in the same path, separated by a 50/50 BS), we have no coherence above 600Hz, which is opposite to what Gabriele sees.

Attached are plots with our slower and faster channels.

• H1:TCS-ITMX_CO2_ISS_IN_AC_OUT = H1:IOP-OAF_L0_MADC2_TP_CH10
• H1:TCS-ITMX_CO2_ISS_IN_DC_OUT = H1:IOP-OAF_L0_MADC2_TP_CH11
• H1:TCS-ITMX_CO2_ISS_OUT_AC_OUT = H1:IOP-OAF_L0_MADC2_TP_CH12
• H1:TCS-ITMX_CO2_ISS_OUT_DC_OUT = H1:IOP-OAF_L0_MADC2_TP_CH13

Even looking at the coherence between the DC and AC channels on the same PD is similarly bad, attached, where green is the CO2X OUT PD, Purple is the CO2X IN PD.  Gabriele suggests this could be shot noise or dark noise or electronics noise or saturation in the PD electronics as he saw at CIT.

We already know that the DC signal is dominated by dark noise, e.g. plot from 82187 so that's probably what we're seeing reducing the coherence here.

Mon Feb 24 10:13:51 2025 INFO: Fill completed in 13min 47secs

TCmins [-144C, -143C] OAT (10C, 50F) DeltaTempTime 10:13:57

As per WP 12345 we put a custom build of the camera server on digivideo4 and digivideo3.  We restarted all the cameras on digivideo4 (MC1, MC3, PRM, PR3) and one camera on divideo3 (FC2).  This gave us a better handle on the frame rate of the camera streams.  We see the digivideo4 cameras producing a much higher frame rate.  This confirms the higher cpu rate we have seen on digivideo4 and on the clients.

At this point Patrick is now looking at how to configure the camera client to be able to better control the maximum frame rate if desired.

Summary: The average duty cycle for LHO this week was 62.5%
The BNS range fluctuated between 140 and 160Mpc this week, especially hitting the lower bound towards the end of the week
2 super events on tuesday
Some lock losses can be explained due to earthquakes and wind
Wednesday morning lock loss around 4:30 am, Saturday lock loss at 2:30 am
Friday 21:15 lockloss due to wind
No glitch rate and strain on Tuesday
Multiple new channels in hveto
Change in Fscan line count page on Thursday: line counts increased significantly to 2000 from 750 > Change in format of line counts.

Full report: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20250210

Summary: Average duty cycle for LHO this week was 65.4%
The BNS range fluctuated between 140 and 160Mpc this week
A couple of the locklosses can be explained due to ground motion
Friday's earthquake at 04:51 UTC
Saturday's earthquake at 23:31 UTC, which extended to sunday morning
Multiple Superevents this week!
Strange noise pattern in H1 BSC2 motion Y Wednesday through Sunday
Fscan line count was very low on Saturday and Sunday (below 600)
Multiple new channels in Hveto this week

Full report: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20250203

Reset the No SQZ AS42 Offsets by taking SQZ out of IFO and then running SQZ > SQZ Overview > IFO ASC > "! reset as42 nosqz". Changes were minimal and are attached.

After a 2nd alignment and finally getting DRMI to lock (post-wind storm), OFFLOAD_DRMI_ASC had a very odd behavior with POP90 & PR_GAIN getting very LOUD (see attachement#1) and for ASC, the SRC2 pitch and yaw also had very odd and noisy behavior (see attachement #2).  There were also SRM & SR2 verbal alarms as well.

Stopped at OFFLOAD_DRMI_ASC as soon as we noticed this, and then it cleared up after about 2-minutes.

• X-Arm's X1 section (Corner to MX) looks like it's mostly passable, but there are some tumbleweed drifts blocking the road--with a big one right near MX.
• X-Arm's X2 section (MX to EX) this section definitely has several large tumbleweed drifts completely blocking the road.
• Y-arm looks passable to EY.

TITLE: 02/24 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 7mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:

H1's been down for about 13hrs with the big wind storm last night starting all the ruckus (winds are  generally under 10mph now) & H1 kept at PREP FOR LOCKING last 3hrs due to the struggles with locklosses in early states of locking (primarily ALS) as noted by Oli who had several wake up calls last night.  Currently have H1 running through an alignment.

Other than that, secondary microseism has stabilized down between the 50th & 95th percentile lines.

Detector still can't lock and called me again. It looks like it's been getting locklosses from Green Arms, Find IR, and DRMI, and it mostly looks like it's due to ALS dropping out. It's even gotten DRMI but then had multiple MC2 saturations before losing lock at DRMI_LOCKED_CHECK_ASC. I have no idea why it's struggling so much. I can only think that it might be related to the wind. The wind is still coming and going, and it isn't too strong, but maybe the changes in wind speed are still kind of a lot for the lower states right now? I'm putting the detector in DOWN until 14 UTC and at that time I'll try again and call someone if I don't think it's related to anything environmental.

H1 Manager requested assistance after the initial alignment timer ran out. ALSY couldn't lock because the wind has been so strong, especially at EY. The wind was over 40mph and gusting up past 50mph, but when I got called it was below 40mph and still decreasing, so I decided to help it try to lock. I was able to get ALSY to lock and finished Initial alignment with no other issues. We had multiple locklosses during PRMI_ASC, so I went to start another initial alignment, but we were getting a CHECK_CRYSTAL_FREQUENCY error from ALSX, which went back and forth between correcting itself and going into error for about 15 minutes. Now that initial alignment finished, but we keep getting low level locklosses, probably due to the wind gusts. I'm going to let it try and sort itself out and hopefully we can relock. Windy.com says that the wind is supposed to be low the rest of the night, but it said that about the current situation too, so it might just not be predicting gusts very well. I'll check back in in a few hours if it's still having trouble.

TITLE: 02/24 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 41mph Gusts, 25mph 3min avg
    Primary useism: 0.13 μm/s
    Secondary useism: 0.28 μm/s
SHIFT SUMMARY:
H1 was locked for a few hours, until 03:05 when the wind started gusting over 40 MPH.

Since then I have done an Intilal Alignment, and just let it attempt to lock while doing other work.
Observatory mode is set to wind.
H1 currently unlocked Wind still gusting.

LOG:                                                                                                                                                           

TITLE: 02/24 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 39mph Gusts, 23mph 3min avg
    Primary useism: 0.09 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:

3:05 UTC Lockloss very likely due to Wind gusts

https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1424401545

While we were out of lock yesterday, I replaced the viewport covers I had removed, so we are ready to go to laser safe when needed.

Robert Schofield, Richard McCarthy, Tyler Guidry, Genevieve Connolly, Ben Mannix, Jonathan Olson

Last summer, Genevieve identified the 35.4 Hz peak as likely from the office area air handler (80655). Recently, Ben was working a Data Quality Shift and reported that the peak had moved by tenths of a Hz and had increased dramatically in amplitude (82519).  This week I used a speaker to sweep in the region around 35 Hz and found that there was a sharp maximum in vibration coupling that happened to lie just where the HVAC peak has been for the last couple of months (See Figure). This meant that, if we could move it just a little in frequency, we would reduce the amplitude in DARM. We power some of the HVAC equipment with variable frequency drives (VFD), which convert the mains 60 Hz to other frequencies. We set the office area air handler VFD to 69 Hz, instead of the 72 Hz that it had been running at, and greatly reduced the amplitude of the peak in DARM (see Figure, page 2).

TITLE: 02/24 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 14mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:
H1 has been locked and Observing for 4 hours now.

0:23 UTC LIGO Hanford Control room received a call about a ADreq  super event candidate S250223dk that was not announced on verbal alarms and no Stand Down signal was given.

Incoming Earthquake from cayman Islands which we should survive.

All other systems are running well.

To test the new h1digivideo4 server we moved four production cameras from servers running the old software to the new server. This required changes to the camera overview MEDM, which up to this time had been hand edited.

I took this opportunity to write a python program to generate the camera overview MEDM (see attached).

The main changes are:

. cameras are sorted alphabetically by name, not by camera number.

. cameras are not grouped by the server machine they run on.

. camera data is stored in a yaml database. Camera details can be viewed by pressing the INFO buttons.

. process control buttons are provided for each camera (VID0 = h1digivideo0, etc). Servers running the new code have green text (VID3 and VID4)

SITEMAP.adl has been upgraded to use the new overview. To open the old overview there is a "Traditional Overview" button provided in the bottom right corner.

Paths for the generator code and the yaml database file are shown at the bottom of the window.

FM6 + FM8 + FM10 Gain +0.01 (+30deg phase) looks to be working for now - see attached screenshot.

The other settings which I tried and it didn't work are listed below,

zero phase Gain 0.01 (IY05 increasing, IY06 decreasing).

-30deg phase gain 0.01 (IY05 increasing, IY06 decreasing).