I've written a new check_model_changes program (used to be called check_model_daq_changes) to additionally check for any IPC addition or removal.

If an IPC sender has been removed, the code gives the list running models which currently have receivers as a reminder that they should also be changed.

The code is designed to be ran between running "rtcds build" and "rtcds install" to catch any issues before the production files are overwritten.

If the list of DAQ channels which have been added/removed is long, the code defaults to showing the first ten channels. The --all argument gives the full list.

For example, after building the h1susitmx and h1isiitmx models on h1build:

david.barker@opslogin0: check_model_changes h1susitmx
--------------------- file times ----------------------
Fri Mar 15 13:35:17 2024 = Model build time
Tue Mar 12 14:47:02 2024 = Current configuration load time
 
DAQ configuration is changed, processing...

++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OFFSET added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_GAIN added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_LIMIT added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_TRAMP added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_SWREQ added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_SWMASK added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_INMON added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_EXCMON added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OUT16 added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OUTPUT added to the DAQ
++: ... plus 210 more slow channels ...
--: slow channel H1:SUS-ITMX_DACKILL_STATE removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_RESET removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_BPSET removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_BPTIME removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_PANIC removed from the DAQ 
--: slow channel H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_TX removed from the DAQ 
--: slow channel H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_SHMEM_TX removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_SD_RMSMON removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RT_RMSMON removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_LF_RMSMON removed from the DAQ 
--: ... plus 19 more slow channels ...

Total number of DAQ changes = 249
(220 additions, 29 deletions)
 
IPC Senders have been removed
Please wait while ipc receiver database is generated...
----------------------------------------------------------------------------------------------------------------------------done 
IPC: 2 Removed Senders
     H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN NOTE: receiver in model(s) ['h1isiitmx']
     H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_SHMEM NOTE: receiver in model(s) ['h1susitmpi']

david.barker@opslogin0: check_model_changes h1isiitmx
--------------------- file times ----------------------
Fri Mar 15 13:20:55 2024 = Model build time
Tue Mar 12 14:47:01 2024 = Current configuration load time
 
DAQ configuration is changed, processing...

--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_ER removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_ET removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_PS removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_RX removed from the DAQ 

Total number of DAQ changes = 4
(0 additions, 4 deletions)
 
IPC: 1 Removed Receiver:
     H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN

The readback of the broadband PD in transmission of the SHG (SQZ-SHG_TRANS_DC) was electronicslly saturating. We switched the gain from 10x to 1x on the generic PD interface box and adjusted the transimpedance gain accordingly. The readback now shows ~1.2V and 7.2mW.

Closes FAMIS 26235

Laser Status:
    NPRO output power is 1.819W (nominal ~2W)
    AMP1 output power is 67.79W (nominal ~70W)
    AMP2 output power is 138.9W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN

PMC:
    It has been locked 14 days, 20 hr 29 minutes
    Reflected power = 16.63W
    Transmitted power = 109.4W
    PowerSum = 126.1W

FSS:
    It has been locked for 0 days 0 hr and 25 min
    TPD[V] = 0.8046V

ISS:
    The diffracted power is around 2.5%
    Last saturation event was 0 days 0 hours and 25 minutes ago

Possible Issues: None

Around 2024/03/15 18:39 UTC Elenna noticed that H1:GRD-ALS_XARM was in INITIAL_ALIGNMENT waiting for the WFs to converge. But the WFS weren't on!

ENABLE_WFS state compleated at 18:34UTC. It stayed in INITIAL_ALIGNMENT (state -16) until unlocked at 18:39:51UTC. Plot attached showing WFS off.

I've updated TRANSITION_FROM_ETMX to activate the new DARM configuration directly. On the next lock we'll test whether we can transition directly into this configuration smoothly without having to move to ETMY before settling in.

svn commit version: r27235

On Wednesday, while testing filters in the "New DARM" state, the ETMX roll mode was inadvertently rung up (I assume it was ETMX because that was the suspension we were changing filters on). It dominated the DARM RMS long enough that I figured I could get a fit of the ringdown and measure the via the OMC DCPD sum.

I extracted the data during the ringdown time, after the filter that was driving the mode was turned off. I split the data up into smaller segments and estimated the height of the peak in the ASD and fit a decaying exponential. The estimated Q of this mode is about 6173 with an estimated frequency of 13.759 Hz. The resulting plot of the exponential fit is show in the third attachment. I performed the fit by taking the logarithm of the data and fitting a linear regression- the resulting r-squared value was 0.998, so I think this is a very good fit. However, I made no estimate of the background for this fit, so there may be some bias in the fit itself. I tried to perform a more precise fit of the damped sinusoid using a digital heterodyne, but I'm unhappy with my curve fitting algorithm. I think ultimately that may be a better way to get a more accurate Q (but if I'm being honest I am unlikely to follow through on that work unless someone really wants me to).

However, I think this is still a pretty good measurement, especially given that Jeff measured a Q of about 7000 for the ETMY roll mode. It is a bit high, given the goal of the BRD was "a Q between one and a few thousand" (quoting Norna's slides from https://dcc.ligo.org/LIGO-G1600371). From a practical point of view, within 10 minutes the roll mode was back to nominal anyway.

Fri Mar 15 10:12:31 2024 INFO: Fill completed in 12min 27secs

Gerardo confirmed a good fill curbside.

With the offset on the AS_A WFS centering, that should lower DHARD_Y coupling to DARM:

https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_1394535464_DARM

Indeed, DHARD_Y coherence with DARM is much lower. Interestingly, now CHARD_Y coherence seems higher.

In other news, there is some coherence with MICH, but hopefully the retuned FF filter will help with that.

Coherence with input jitter witness is also large, see for example the PSL periscope

Picket Fence on nuc5 stopped updating 18:44 Thu 14mar2024 PDT. I killed the frozen window and started the code by hand on nuc5 via a vnc connection, it is updating again now.

[Louis, Gabriele]

We did again the noise injections for retuning the MICH FF, analysis and fit will follow tomorrow.

[Louis, Gabriele]

The DHARD_Y to DARM coupling always showed two regimes: a steep coupling below 20-30 Hz, and a flatter coupling above 20-30 Hz. We've been able to change the flatter coupling above 20-30 Hz by changing the ITMT Y2L coefficient.

Today we confirmed a suspicion: the steep low frequency coupling is due to length to angle coupling at the AS WFS. We changed the beam position on the WFS by adding an offset to the WFS centering (H1:ASC-AS_A_DC_YAW_OFFSET) and saw a change in the DHARD_Y to DARM coupling.

A value close to -0.14 gives the minimum coupling below 20 Hz. we now have two independent knobs to minimize the DHARD_Y to DARM coupling at all frequencies.

Incidentally, the higher frequency couping is now lower than yesterday, with the same ITMY Y2L coefficient of -1.65

We did a scan of the AS_A_WFS Y centering from -0.2 to -0.1 in steps of 0.01, an analysis will follow tomorrow:

-0.200: 1394510627 - 1394510727
-0.190: 1394510777 - 1394510877
-0.180: 1394510927 - 1394511027
-0.170: 1394511077 - 1394511177
-0.160: 1394511227 - 1394511327
-0.150: 1394511377 - 1394511477
-0.140: 1394511527 - 1394511627
-0.130: 1394511677 - 1394511777
-0.120: 1394511827 - 1394511928
-0.110: 1394511978 - 1394512078
-0.100: 1394512128 - 1394512228
 0.000: 1394512278 - 1394512378

We are leaving a value of -0.14 in the WFS offset

Naoki, Dhruva, Nutsinee

Yesterday we had only 3dB squeezing at IFO so we checked squeezing at homodyne. Although the visibility is good (98.5%), the squeezing was only 4.5dB at homodyne with 6dBm CLF6. We reduced the CLF power and recovered 8dB squeezing as shown in the attached figure.

The CLF6 was reduced from 6dBm to -42dBm and the 8dB squeezing was obtained with -38dBm CLF6. The CLF6 between -38 and -20 dBm gave similar squeezing so we set it at -24dBm, which is similar to O4a value and corresponds to 8uW CLF_REFL_LF_OUTPUT. The squeezing at IFO is recovered to 4.5dB with -24dBm CLF6.

Note that the LLO also saw the better squeezing at IFO with less CLF power in LLO70072.

We had 6.5dB squeezing at homodyne in 76040 and 4.5dB squeezing at IFO in 76226 with 6dBm CLF6 before. The question is why we lost squeezing at homodyne and IFO this week with same CLF power? The commissioning list in 76369 might give us a clue.

Last week when we locked the new OMC by hand I copy-pasted some guardian code into a shell, and found that there was a gain set and wait that were totally unnecessary. This inspired me to start reading through ISC_LOCK to look for other redundant waits. Here are my notes, I only got up to the start of LOWNOISE_ASC before I went totally cross-eyed.

Here are the notes I took, the ones in bold we can for sure remove.

Preparing for lock

Line 301-305 [ISC_LOCK, DOWN] Prcl UGF servo turn off (do we still do this?) no wait times but maybe unnecessary
Line 327 [PREP_FOR_LOCKING] Thermalization guardian (are we using this?)
Line 350-354 [PREP_FOR_LOCKING] Turn off CHARD blending, no wait times
Line 423 [PREP_FOR_LOCKING] turn off PR3 DRIVEALIGN P2P offset for PR3 wire heating
Line 719 [PREP_FOR_LOCKING] toggling ETM ESD HV if the output is low, seems redundant with line 445

Initial alignment

INITIAL_ALIGNMENT for the green arms only offloads a minute or 2 after it's visually converged. Initially I thought the convergence checker thresholds should be raised, but it's a 30 second average. Might make sense to reduce the averaging time?
(2 screenshots attached for this one)

Arm Length Stabilization

ALS_DIFF [LOCK] Ramps DARM gain to 40, waits 5 seconds, ramps DARM gain to 400, waits 10 seconds. Seems long.
ALS_DIFF Line 179, waits 2* the DARM ramp time, but why?
ALS_DIFF [LOCK] Enegages boosts with a 3 second wait, engages boosts with another 10 second wait
ALS DIFF Line 191 wait timer 10 seconds seems unnecessary.

ALS_COMM [PREP_FOR_HANDOFF] line 90 5 second wait - maybe we could shorten this?
ALS_COMM [HANDOFF_PART_3] lines  170 and 179 - 2 and 5 second timers but I'm not sure I get why they are there
ALS_COMM's Find IR takes 5 seconds of dark data, has two hard coded VCO offsets in FAST_SEARCH, if it sees a flash it waits 5 seconds to make sure it's real, and then moves to FINE_TUNE_IR, taking 50 count VCO steps until the transmitted power is >0.65
Suggest updating the hard coded offsets (ALS_DIFF line 247) from [78893614, 78931180] to [78893816, 78931184] (second spot seems good, first spot needs a few steps)

ALS_DIFF's find IR has 3 locations saved in alsDiffParams.dat which it searches around. This list gets updated each time it finds a new spot, HOWEVER the search starts 150 counts away from the startin location and steps in in increments of 30. Seems like it would be more efficient to start 30 below the saved offset?

ISC_LOCK [CHECK_IR] line 1206 has a 5 second wait after everything is done which could probably be reduced?

Power- and dual- recycled michelson locking

PRMI locking - a bunch of 1 second waits idk if they are needed?
ISC_DRMI line 627/640 [PRMI_LOCKED] self.timer['wait']=1 seems maybe unnecessary?
ISC_DRMI line 746, 748 [ENGAGE_PRMI_ASC] - MICH P and Y ASC ramps on with a 20 second timer, but wait = false, but this seems long anyway?
ISC_DRMI line 762/765/768 [ENGAGE_PRMI_ASC] self.timer['wait'] = 4... totally could remove this?
ISC_DRMI [PRMI_TO_DRMI] line 835 - wait timer of 4 seconds (but I don't think it actually waited 4 seconds, see third attached screenshot, so maybe I dont know what time['wait'] really means!!!
When doing the PRMI to DRMI transition it first offloads the PRMI ASC, does the PRMI_TO_DRMI_TRANSITION state, then runs through the whole DOWN state of ISC_DRMI which takes ~25 seconds? maybe there can be a quicker way to do this

In ISC_DRMI there's a self.caution flag which is set as True if AS_C is low, and has 10 second waits after ASC engagements and a *90 second* wait before tirning on the SRC ASC. Might be worthwhile to to replace this with a convergence checker since it might not be needed that we wait for a minute and a half if we are already well algined

Line 1845 ISC_LOCK [CHECK_AS_SHUTTERS] 10 second wait for...? This happens after the MICH RSET but before the FAST SHTTER is reqested to READY
Lines 1837/8 and 1865 redundant?
Line 1870 wait timer 2 seconds after AS centering + MICH turned back on but why
Line 1887 - straight up 10 second wait after increasing MICH gain by 20dB

CARM offset

Line 2119 [CARM_TO_TR] time.sleep(3) at the end of this state not clear what we're waiting for
Line 2222 [DARM_TO_RF] self.timer['wait'] = 2 that used to be 1
Line 2235 [DARM_TO_RF] another 2 second timer?
Line 2314 [DHARD_WFS] 20 second timer to turn DHARD on, but maybe we should just go straight to convergence checking once the gains are ramped on?
Line 2360 [PARK_ALS_VCO] 5 second wait after resetting the COMM and DIFF PLLs
Line 2406 [SHUTTER_ALS] 5 second wait followed by a 1 second sleep after the X arm, Y arm, and COMM are taken to shuttered
Line 2744 [CARM_TO_ANALOG] 2 second wait when REFLBIAS boost turned off but before summing node gain (A IN2) increased?
Line 2753 [CARM_TO_ANALOG] 5 second wait after summing node gain increased
Line 2760 [CARM_TO_ANALOG] 2 second wait after enabling digital CARM antiboost?
Line 2766 [CARM_TO_ANALOG] 2 second wait after turning on analog CARM boost
Line 2772 [CARM_TO_ANALOG] 2 second wait after raming the REFL_DC_BIAS gain to 0, actually maybe this one makes sense.

Full IFO

There are a ton of waits during the ASC engagement but I think usually the convergence checkers are the limit to time spent in the state.
Line 3706 [ENGAGE_SOFT_LOOPS] 5 second wait after everything has converged?
Line 3765 [PREP_DC_READOUT_TRANSITION] 3 second wait after turning on DARM boost but shouldn't it be 1 second?
Line 3816 [DARM_TO_DC_READOUT] 10 second wait after switching DARM intrix from AS45 to DC readout, might be excessive
Line 3826/7 [DARM_TO_DC_READOUT] - DARM gain is set to 400 (but it's already 400!) and then there is a 4 second wait, these two lines can for sure be removed!
Line 3834 [DARM_TO_DC_READOUT] - 5 second wait after turning ramping some offsets to 0 BUT the offsets ramp much more quickly than that!

Power up

line 4033 [POWER_10_W] 30 second wait after turning on some differential arm ASC filters but actually, never mind I don't think it actually does this wait
Line 4299 [REDUCE_RF45_MODULATION_DEPTH] we have a 30 second ramp time to ramp the modulation depths, maybe this could be shorter?
Line 4614 [MAX_POWER] 20 second thermal wait could be decreased?
Line 4641 [MAX_POWER] 30 second thermal wait could be decreased??
Line 4645 [MAX_POWER] 30 second thermal wait for the final small step could be devreased?

Lownoise stuff

line 4463/4482 [LOWNOISE_ASC] 5 second wait after we turn off RPC gains that were already off
line 4490 [LOWNOISE_ASC] 10 second wait after CHARD_Y gain lowered, but it looks to have stabilized after 5 seconds so I think we can drop this to 5.
honestly a lot of waits in lownoise_asc so I ran out of time to check them all for necessity

The CAL-CS filters installed by Jeff (LHO:76392) do a better job of correcting CAL-DELTAL_EXTERNAL. See darm_fom.png. Here's a screenshot of the filter banks: new_darm_calcs_filters.png.

Also, Evan's 5Hz high pass filter (LHO:76365) pretty much killed the strong kick we've been seeing each time we switch into this new DARM state from ETMY.