TITLE: 04/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 23:00 UTC (45 min lock)

Other:

H1:PEM-CS_DUST_PSL101                    Error: data set contains 'not-a-number' (NaN) entries

TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

H1 Is currently Locked for 44 Min and Observing for 8 Min.  
The Myster H0:CDS-VID_CAM_REQ Button was pushed by a button pusher.

In unrelate news:
Unknown Lockloss 21:22 https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1396041753

Relocked with out an Initial Alignment
The SQZ_FC Gaurdian got stuck for 10 minutes, Vicky jumped on TeamSpeak and helped us out. 
Nominal_Low_Noise 22:24 UTC

LOG:

SUS SDF changes saved to Safe.snap.
IM
IM1,2,3,4 Pitch
IM1,2,3,4 Yaw

OMC, OFI, OM1, 2, 3

J. Kissel
ECR E1700387
IIET 9392
WP 11743

Here, this week we tackle the last of the suspension types that need suspension watchdog upgrades after having finished the End Station, Corner BSC, and HAM Triple suspensions this past month (LHO:76269, LHO:76545, and LHO:76712, respectively).

WP 11797
While doing so, I'm also going to address the OMC ASC routing bugs found in the h1susifoout top-level model and its OMCS_MASTER library part (which used to live in h1susomc.mdl), and fix those too.

As such, I'm doing a linear combination of the following changes:
    (1) In library part, removed sending watchdog out to top level
    (2) In library part, removed ODC parts from DAMP and LOCK banks
    (3) In library part, removed never-usered software shutter system
    (4) In library part, upgraded watchdog trigger generator to actual functional RMS
    (5) At top level, removed USER DACKILL
    (6) At top level, removed wires to ground (i.e. things never used) at top-level for WD, SHUTTER, and ODC outputs and SHUTTER input
    (7) At top level, cleaned up receiving of ISC ASC signals (see discussion in LHO:76842)

Below is the list of models, their respective library parts, and the optics in that model that this impacts, followed by a call out of which of the above changes happened
h1susim       HSSS_MASTER    IM1, IM2, IM3, IM4      (1), (2), (4), (5), (6)
h1sushtts     HSSS_FF_MASTER RM1, RM2                (1), (2), (3), (4), (6)
h1susifoout   OMCS_MASTER    OMC                     (1), (2), (4), (5), (6), (7)
              OFIS_MASTER    OFI                     (1), (2), (4), (6)
              HSSS_MASTER    OM1, OM2, OM3           (1), (2), (4), (5), (6)
h1sussqzout   HSSS_MASTER    ZM4, ZM5, ZM6           (1), (2), (4), (5), (6)
h1sussqzin    HDDS_MASTER    ZM1, ZM3                (1), (4)
              OPOS_MASTER    OPO                     (1), (2), (4), (6)
              HSSS_MASTER    ZM2                     (1), (2), (4), (5), (6)

I've test-compiled all of the above listed models, so they're ready for re-compile, install, and restart of the front-end process tomorrow morning.
All model changes have been committed to the userapps repo, either under
    /opt/rtcds/userapps/release/sus/h1/models/
    /opt/rtcds/userapps/release/sus/common/models/
where the above mentioned models live.

Screenshots describing the changes will be posted in the comments.

While studying the improvement made by stray light modifications over the break (summary alog soon), I found that the coupling was minimized by changing ITMY R0 yaw offset from -300 to -250. We want to change the settings before my alog, hence this mini-alog.

SDF Diff accepted.
H1:IOP-SEI_HAM6_DK_BYPASS_TIME

Since the camera servo offset was monitored by SDF in safe.snap, everytime we lose lock, the camera servo offset was set to the values in safe.snap which are kind of random. So I unmonitored the camera servo offset in safe.snap. This will make it easy to look back the camera servo offset in different locks.

TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY:
Some Commissioning was being done until the 16:23 UTC Dophin Crash.
Took all SUS to SAFE
Took all SEI to ISI_DAMPED_HEPI_OFFLINE
Took HAM1 HEPI to MASTERSWITCH_OFF
CDS started restarting DAQs at 16:53 UTC ish

The FC SUS kept trying to put itself into aligned everytime we went into prep for locking even though ISC_LOCK was in IDLE.
I then Manualed ISC_LOCK to IDLE then took SQZ_MAN to Down, then Paused SQZ_MAN and finally I took FC to SAFE for good.

17:33 UTC Took all the SUS back to Aligned.
Then took ISI's & HEPI's back to ISOLATED.
Then took SEI_ENV back to Calm
Started Initial_Alignment 17:53 UTC
Increase_Flashes ran for both arms

IA could not get passed Input align due to IMC unlocking issues seen on friday's Alog 76793

Once the Issue was Identified I took all sliders except for SQZ to 1395811454 ( tail end of the last Initial Alignment) 

Y arm looked bad so I took Yarm sliders only to 1396030446 (Tail end of Increase Flashes)  to get good Y arm Values in Green arms Manual.

INITIAL_Alignment started again and completed near 19:07 UTC.

NOMINAL_LOW NOISE has been reached 19:49 UTC.

J. Kissel, [Corroborated by J. Wright and J. Driggers]
WP 11797

While upgrading the OMCS_MASTER.mdl library part for the OMC Suspension (which now lives in the h1susifoout.mdl top-level model), I found two distressing things:
    (1) The OMC ASC signals that are sent from the h1omc.mdl model -- running at 2kHz -- are not anti-imaged at all before being sent to the OMC SUS DAC -- running at 16 kHz. So, we're sending unnecessary imaging noise to the SUS DAC.
    (2) The OMC ASC L, P, amd Y signals are being sent through a filter bank that does NOT past through the DRIVEALIN matrix, rendering 2019's attempt at diagonalization (LHO:47488) unused.

These bugs have been long standing.
I see it now as I touch the h1susifoout.mdl and the OMCS_MASTER library part for watchdog upgrades, but I'd previously identified the issue when 
 - I was upgrading the front-end models for O4 (i.e. when the OMC SUS transitioned from the h1susomc.mdl to the h1susifoout.mdl) in 2021 (LHO:59652), and
 - When we were identifying which SUS models used the broken "TrueRMS" bloick -- there's a preceding note in the simulink model that suggests this has been around since 2015 or earlier.

We can fix this tomorrow, with *only* a change to the h1susifoout.mdl and OMCS_MASTER.mdl models, and we're already doing that anyways for the SUS watchdog upgrade.


Attached are several series of screenshots showing:
    (1) The signal path from the h1omc.mdl model where the OMC ASC control signals begin, to where they land in the OMC SUS driving in the EULER basis (again WITHOUT going through the DRIVEALIGN MATRIX)
    (2) MEDM Screens showing that in practice we only drive L, P, and Y (as one should for an ASC signal) and we don't use T, V, or R drive and likely never will.
    (3) The existing filters that will need to be copied over, and the DRIVEALIGN gain values that will likely need to be re-addressed -- since effectively we've NOT been using them.

Note -- I checked on how this is done at LLO, and they *do* drive through the LOCK banks and DRIVALIGN banks (BUT they don't have any anti-imaging filters in pace either, even though their ISCINF FM1 banks are ON... whoops)...
So, when we change the OMCS_MASTER library part, this won't affect them.

[Dave, E.J., Erik]

At about 16:25 UTC, the corner station had a timing glitch that put the IOPs on h1susb123, h1sush2a, h1sush34, h1sush56 and h1lsc0 into an error state. 

The affected front ends had no error messages in the system logs.. 

The SUS IOPs all had long cycle times in the tens of milliseconds.  These times are typical of a "dolphin" timing glitch, seen when someone powers on a computer attached to the dolphin network, but no system was powered on in this case. 

h1lsc0 had a long cycle of only 3 milliseconds, too short for a "dolphin" glitch.  Also, it's time_0 value, which reads the clock time at the start of each second was off by 17 milliseconds, though the duotone value was correct. (see attached screen shot).

There's no evidence anyone was in the CER or MSR at the time of the glitch.

The operator put the IFO into a safe state.  Models on the affected systems were restarted.

During the restart, h1susb123 reset it's Ethernet adapter.

Mon Apr 01 10:08:10 2024 INFO: Fill completed in 8min 6secs

Jordan confirmed a good fill curbside

FAMIS 20022

The main chiller alarm was active last night, so this morning I added 100mL of water to stope the low-level alarm.

We plan on doing a remote PMC alignment tomorrow during maintenance to address the recent rise in PMC reflected power.

TJ, Camilla, WP 11746, LLO did in LLO#14419

• Data set A: No mask. Razor blade 2 3/8" downstream of the center of the annular mask
• Data set B: Annular mask in mask. Razor blade 2 3/8" downstream of the center of the annular mask
• Data set C: No mask. Razor blade 10 7/8” upstream of the center of the annular mask

Sheila, Jennie W

At around 21:49 UTC we used the step_45MHz.py in userapps/isc/h1/scripts to step the modulation depth in steps of 1dB down from 21dBm to 18dBm. This script adjusts the loop gains to compensate for a drop in power on the RF45 PDs.

Its also important to open the POP beam diverter to monitor what is happening to the RF 45 PD signals.

This is to check that the noise does not decrease with decreasing modulation depth which would imply that the modulator was imposing noise on the carrier through the ISS loop.

At around 22:18 UTC we put the modulation depth down by 3 dB we saw a 4% increase in the DARM broadband noise (measured the level at 2kHz with cursors) which is the green trace in the second image. The level of KAPPA C (shown in first image on bottom plot) only decreased by around 1% over this time, so we suspect some other cause other than a change in optical gain being responsible for this.

When we stepped the modulation depth up by 3dB (third image) we saw no change in the noise from the nominal state (purple trace on second image). Kappa C (bottom plot) looks almost the same as the nominal also.

In the fourth image it can be seen that f_C does not change much either.