I edited ISC_LOCK LOWNOISE_ASC state to engage the -0.15 offset in AS_A_YAW_DC that was found 76407, I have just loaded it now so it should happen the next time we lock the IFO.

FAMIS 26464, last checked in alog75972

Trends look very stable, except H1:HPI-PUMP_L0_CONTROL_VOUT has been falling very slightly over the past ~3 weeks.

Trending Lock Acquisition times from state 10 (DOWN) to state 600 (NOMINAL LOW NOISE) for the last 6 lock acquisitions yields an average of 37.2 mins. That same average for the last 6 lock acquisitions of 04a was 86.8 mins (1 hr and 26 mins). This means that so far, our lock acquisition time seems to have improved by a whole 49.6 minutes, which is also a 230% improvement/time reduction. 

However, it is worth noting that so far, every lock acquisition (bar one or so) since we started relocking to Nominal Low Noise has required an initial alignment, which takes a rough 20-25 minutes. Therefore, from Lockloss to NLN, the last 6 lock acquisitions took 57.2 minutes (assuming 20 mins to initial), which is still a 150% improvement/time reduction. This doesn't count times in O4a where we had that long lock time AND a 20 min initial alignment so it's likely better than 150% on average (which is great!).

Also relevant: Georgia recently pointed out potential redundancies in wait times via the rigorous alog 76398, though none of the changes suggested within have been added yet.

Once H1 is ready for O4b, a similar comparison should/will be made, but this should hopefully foreshadow lock acquisition time improvements.

FAMIS 20020

PMC alignment seems to be drifting; PMC_TRANS has decreased by ~0.7W and PMC_REFL has increased by the same amount over the past 10 days.

I found a quiet time for Jenne to use to train the cleaning. Picture below. Time starts 1394621323 GPS for cleaning training of around 38 mins with no big range drops. It was early Saturday morning before Ibrahim's shift started and as far as I can tell from the labbook no one was measuring anything. We had been thermalised for more than 5 hours.

At 10:12 all h1seib3 models stopped running with an ADC timeout due to CER rack work. We fenced this frontend from the Dolphin fabric and power cycled the computer to recover the system.

Mon Mar 18 10:10:47 2024 INFO: Fill completed in 10min 43secs

Travis confirmed a good fill curbside.

Ibrahim A, Oli P, Jeff K

During commissioning on Friday, excitations on the ETMs caused the watchdogs to trip for TMSX SUS, ETMX SUS, and ETMX ISI for stages 1&2. When installing and setting up the new SUS watchdogs and filter banks for the ETMs and TMSs on Tuesday (76269), Jeff and I decided to set the trigger threshold for the watchdogs to 25microns (the threshold value read outs on the ETM and TMS watchdog screens are now in microns instead of ADC counts). This value is arbitrary - we decided on it after the initial untripping of the watchdogs following installation kicked the suspensions over the previous threshold value of 5 (also arbitrary).

After this trip, the L1 and L2 stages on ETMX were having trouble getting lower than 25 (attachment1). We were waiting almost 30 minutes before raising the threshold since we could confirm that the trip hadn't been caused by something unknown. The damping loops were then able to bring all values below 25 within 11 seconds(attachment2).

So far we've only had these two experiences, so it'll take us a bit to figure out the best threshold values.
As a very rough comparison of how close our current values are compared to watchdog trips before the change, I trended ETMX_{M0,R0,L1,L2}_WD_OSEMAC_BANDLIM_*_OUT channels grouped by stage(I can't trend the RMSLP channels because they didn't exist before Tuesday) versus ETMX_{M0,R0,L1,L2}_WDMON_STATE(M0, R0, L1, L2). I've set the horizontal cursors to the min and max of this latest trip.
Even the trip with the smallest WD_OSEMAC_BANDLIM_*_OUT values had at least double the amplitude of our trips after the model change.
Based on this info and the max values reached during this last trip, I have increased the SUS watchdog values for ETMX and ETMY to:
M0 -> 100
R0 -> 120
L1 -> 170
L2 -> 270
and for TMSX and TMSY:
M1 -> 100.
These values may still change as we get a better understanding of the normal range of the suspensions through trips and running health check transfer functions.
Changes are committed to SDF safe but will need to be committed to OBSERVE(ETMX, ETMY, TMSX, TMSY).

The new DARM configuration drastically reduced the number of low frequency glitches.

See a comparison of omicorn glitches with old DARM and with new DARM, and glitch rates with old DARM and new DARM.

TITLE: 03/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 2mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY:

IFO is in DOWN

Louis put IFO in DOWN due to issues locking itself. Will begin locking now.

Other:

H1:PEM-CS_DUST_PSL101   dust counts did not change, please investigate.

EX Pressure EX_X5_PT526 MOD1 PRESS TORR is showing a yellow alert on the vacuum alarm handler.

The IFO is having trouble locking itself this evening. Requesting down for the night.

TITLE: 03/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is at LOCKING and at CARM_5_PICOMETERS (309)

(15:00 UTC 0- 21:45 UTC) ISI IY Interface Chassis is dead and requires replacement:

ISI IY WD tripped around 3AM - I go to untrip right now, it trips again, triggering our last lockloss.  (09:48 UTC)

Looking at the values, they are all below threshold so I untrip and then <1 minute later, it trips again. I try this one more time while trending the relevant channel, T240 ISI Stage 1and the counts climb uo irrattically until it trips again (<1 min later). After ensuring, Screenshots of this behavior below.

I get in contact with Jim, and he informs me that the corner 1 sensors are all dead, indicating an interface chassis issue. With instructions, I go to the CER to power cycle but it stays dead. Photos of the dead chassis below.

After getting a hold of Fernando, him and Richard were able to get a hold of Fil, who said he would come to site to do the replacement/fix (according to Richard).

Jim noticed that the Chassis came back at 10:53 but that we should stay down until Fil investigates.

At around 21:00 UTC, Fil arrived and we replaced the Chassis with a functional one. Fil stayed until ALSY locked, confirming that the issue was fixed.

21:25 UTC - Began Locking

22:23 UTC - Started Initial Alignment due to CHECK MICH FRINGES ran and failed for the 3rd time and manual touching of BS and PRM was going nowhere.

22:49 UTC - Initial Alignment Complete, locking now

22:56 UTC - DRMI Locked - requested NLN

Other:

EX Pressure EX_X5_PT526 MOD1 PRESS TORR is showing a yellow alert on the vacuum alarm handler.

LOG:

Sun Mar 17 10:09:59 2024 INFO: Fill completed in 9min 56secs

We now have the new DARM offloading configuration up and running, and fully calibrated, so we can do a direct comparison of the old offloading (Old DARM) and new offloading (New DARM) using GDS-CALIB_STRAIN.

As pointed out by Elenna, the new DARM configuration improves the low frequency noise level. See first plot.

The old DARM configuration induced non-stationary noise at low frequency, as visible in the spectrogram in the second plot, and also in the whitened spectrogram in the third plot (where DARM is whitened with the median of the Old DARM configuration, to show at the same time the reduction in noise and the better stationarity).

Those same spectrograms also show that the new DARM configuration makes the low frequency noise more stationary.

Other comparison plots:

• DARM BLRMS at low frequency with old and new DARM
• ESD drive RMS
• scatter plot of DARM BLRMS vs ESD drive RMS, that shows a clear relation in old DARM

Finally, the last two plots show bicoherence of DARM with the ESD drive in old DARM and new DARM: nothing is visible in new DARM.

Georgia, Trent

To get the finesse of the omc as a function of the pzt voltage (in order to double check the pzt voltage calibration). OMCscan.py has shortcoming in that it doesn't like when there are more than three carrier 00 peaks so to get three carrier 00 peaks that were included in my initial scan I had to seperate the data into two "bins". I had the GPS time 1393542033 with a duration of 80 to get the first two peaks and the GPS time 1393542063 with a duration of 60 to get the second and third peaks. The links of the GPS times are the corresponding pzt calibrations. The links in the finesse are the zoomed in plots for the corresponsing peaks. To get the plots we ran OMCscan.py and fit_peak_w_args.py

Graeme, Matt, Craig

Using our setup from yesterday (alog 76397), we injected into the common mode board and measured a CARM to DARM transfer function.
Matt will post plots, comparisons, and measurement times later.

I am posting the data now, it lives in /ligo/gitcommon/psl_measurements/data/carm_to_darm_tfs/.

Just to clarify what these measurements are, we injected a 600 mV broadband white noise injection from 51.2 kHz to 102.4 kHz frequency span into the common mode board excitation point.
We measured out at the REFL A 9 QMON at the PSL racks (which is actually REFL A 9 I used for frequency feedback) and out of the OMC DCPD whitening chassis A+ terminal, patched over to the PSL racks as described in alog 76397.

We saw a significant rise in the REFL A 9 QMON noise as we injected more (Matt's plots to come), but very little increase in the OMC DCPD noise.
We had around 5e-3 coherence between the two at best.
We took 10000 averages, so we believe that anything above 1e-4 is "well-resolved".

We did not have time to try injecting between 1 kHz and 51.2 kHz before we lost lock, or to try looking at OMC DCPD A / EXC
We were not injecting at the time of the lockloss.  
We left the SR785 out there but not plugged in to anything on the racks so we can relock peacefully.

EDIT:
We went back out, got some data betwen 1 kHz and 52 kHz, and then unplugged everything, including the SR785 and the HAM6 OMC DCPD A+ whitening chassis cable.  We didn't unplug the patch panel connection.

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

Ryan S, Jennie W, Camilla

Camilla noticed the OMC_LOCK guardian was failing to find the carrier resonance during the ISC_LOCK guardian state.

Ryan discovered this was due to the triplet (1 45MHz peak either side of the carrier) that the OM_LOCK guardian looks for was not being found by scipy.find_peaks() as the carrier resonance are bellow 9 counts which is its threshold. So we changed the 'height' threshold of find_peaks to 7 on line 327 of OMC_LOCK guardian and commited this change.

We also changed the OMC_LOCKED guardian state at line 511 to look for OMC-DCPD_SUM_OUTPUT to be more than 7 instead of 10.