Last checked in alog80348

Nothing really of note, for the OUTs MY_FAN2_270_1 is a little noisy, along with MR_FAN5_170_1 at the CS.

Still down for maintenance and it will be up to two more hours before we can start relocking - some investigations/experiments will be done to try and narrow down the cause of the FSS issues.

The independent GPS receiver at EX has failed. It 1PPs signal into the comparator starting oscillating at 03:53 this morning. Its MEDM screen is frozen from that time.

Erik is on his way out to EX to investigate

Before this morning's lockloss until 15:20UTC, we left CO2X and CO2Y on at their nominal annular powers (1.7W into vac) so that we could measure the IFO beams absorption on the ITMs using the HWS data.

B. Weaver, J. Kissel
WP 12109

Betsy, myself, and several others are looking to propose redlines to the WHAM3 flange cable layout (D1002874) in prep for O5 (see T2400150 for DCN and discussion there-of). 

However, in doing so, we discovered that the flange layout may have double-counted the shared cable for the MC2/PR2 M1 (top) RTSD / T1T2 OSEMs. Other drawings (e.g. the Cable Routing D1101463 and the wiring diagrams D1000599) indicate "yes, there's an extra 'SUS-TRIPLE' entry somewhere between the D6 and D3 allocation," but we wanted to be sure.

As such, Betsy went out to HAM3 today and confirmed that YES the MC2/PR2 M1 (top) RTSD / T1T2 cable, labeled "SUS_HAM3_002" in the wiring diagram or "SUS-HAM3-2" in real life, does come out of D3-1C1 and *not* out of any D6 port, and thus we validate that D6's list of 4x DB25s to support the 'SUS-TRIPLE' (i.e. MC2) in D1002874 is incorrect.

Pictures attached show the D3 flange, and highlight the SUS-HAM3-2 cable at the flange going to D3-1C1, and then the other end of that cable, clearly going into the MC2-TOP/PR2-TOP satamp box in the SUS-R2 field rack (S1301887).

Oli, Camilla

Oli found there was 3 sdf diffs after the in-lock charge measurements this morning. One was from lscparams.ETMX_GND_MIN_DriveAlign_gain being changed and th SU_CHARGE guardian not reloaded, the others it seems from an out of date filter and the original tramp ot being reverted correctly. The tramp wasn't explicitly changed but was ramped using a different than nominal value ezca.get_LIGOFilter( ... ramp_time=60).

Code changes attached and all sus charge guardians reloaded.

Tue Oct 08 08:07:33 2024 INFO: Fill completed in 7min 29secs

Gerardo confirmed a good fill curbside.

TITLE: 10/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 0mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:

Detector Locked for 3.5 hours now and running injections.

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

H1 called cause ITMX ISI watchdoog trip.

TITLE: 10/08 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: We've been locked for just under 2 hours, the range has been just under 160Mpc.

• 23:52 UTC NLN
  • 00:00 UTC Observing
  • PSL_ISS diffracted power low notification on DIAG_MAIN despite Corey touching it up in the beginning of the lock.
• 00:55 UTC lockloss from an earthquake (1:03 lock)
  • I went one more step on H1:PSL-ISS_REFSIGNAL to increase the ISS_DIFF power a bit more (-1.916 -> -1.906) (tagging PSL)
  • 02:02 UTC lost it at LOWNOISE_ESD_ETMX
  • FIND_IR and PRMI locklosses, no LLes got the FSS tag
  • 03:10 Observing

I've taken one of Sheila's and TJ's scripts and adjusted it to plot the max values for PSL-FSS_FAST_MON_OUT_DQ and PSL-FSS_PC_MON_OUTPUT channels before and after we started having issues with the FSS, only looking at data when we were in NLN (600+) and ignoring the data from the last minute in each locked stretch when we lost lock (since the IMC unlocks during locklosses and everything in the detector is generally all over the place).

We started seeing FSS related locklosses starting September 17th, so the plot(attachment1) shows the 'before' in two chunks - June 12 - July 13 (in blue), which was pre- FSS issues and pre- OFI vent, August 24th - September 17th in green, which was after the OFI vent but before we started having FSS issues, and then the 'after'/during is September 17th - October 4th, shown in red.

In both channels we can see that the red tends to reach higher than the blue or green, but the difference isn't as drastic and the glitching doesn't seem to be more frequent during the FSS issues either. By squishing up the plot(attachment2), I did notice that the level FASTMON reaches does look to have been gradually increasing over the last 4 months, which is interesting.

Lockloss at 00:55 UTC, most likely from earthquake ground motion.

Our range has increased back to around 160 Mpc on the CALIB CLEAN channel the past few days. I ran the DARM integral compare plots using an observing time on Sept 28 (before OPO crystal and PRCL FF changes) and Oct 5 (after those changes). It appears the largest improvement has occured at low frequency. Some of that can be attributed to the PRCL feedforward, but not all. Based on the previous noise budget measurements, and the change in the coherence of PRCL from Sept 28 to Oct 5, I think the improvement in DARM from 10-30 Hz is likely due to the PRCL improvement. Above 30 Hz, I am not sure what could have caused that improvement. It doesn't appear there is much improvement above 100 Hz, which is where I would expect to see changes from the squeezing, if it improved from the OPO changes.

Sheila, Camilla.

New SQZ ASC using AS42 signals with feedback to ZM4 and ZM6 tested and implemented.  We still need to watch that this can keep a good SQZ alignment during thermalization. In O4a we used a SQZ ASC with  ZM5/6, we have not had a SQZ ASC for the majority of O4b.

Prep to improve SQZ:

• No squeezing from 15:31:30 to 15:41:30UTC.
• Adjusted OPO temperature following no observing instructions in 80461. Measured NLG to be 12.8. (0.1165/0.0091) following 76542.
• This improved the squeezing from 2.5dB above 300Hz to 3dB at 300Hz and 4.2bD above 1kHz.

Testing ASC from 80373:

• Ran the "reset as42 nosqz" offsets script while in no sqz. SDF accepted.
• Put the input matrices form 80373 into SQZ ASC and checked they were diagonalized correctly by moving ZM4/6 in turn and watching ASC_POZ/ANG input signals. ZM4 pitch wasn't completely diagonalized but that others looked good.
• Reduced ASC_WFS gain from 0.1 to 0.05, cleared histories, set all ASC_POS/ANG gains to 1 and one at a time turned on the inputs. We had some troubleshooting with POS_Y but there was a minus sign inside one of the filter banks we hadn't seen. In this troubleshooting we found the matrix was mostly diagonal so removed the cross-coupling terms for the YAW input matrix.
• Found WFS gain is better with lower WFS gain to 0.01 so we took a factor of 100 for the input matrix and left H1:SQZ-ASC_WFS_GAIN at 0.5. Accepted all in sdf. And edited sqzparams and reloaded SQZ_MANAGERT to turn on SQZ ASC.
• To test, we tried the "offload AS42 ASC" script with the plan to compare the AS42 alignment with the alignment from the guardians scan SQZ alignment. The script didn't work as expected, it's hard-coded to offload ZM45/6 rather than ZM4/6 that we are now using, we should fix this or go back to using ther guardian states. After turning off the ASC and running again to clear histories, this caused a lockloss, probably as ZM6 P moved 60urad in 0.3s. See attached lockloss plot.