• 8:05UTC We had a 8:05UTC lockloss where HAM1 HEPI WD tripped (ATC type trip)
• 8:18UTC I saw no obvious issue with ground motion or HAM1 so Untripped HAM1
  • Then noticed that CDS screen was red with timing card, adc, dac, dk errors on machines sus123, sush2a, sus34, sus56, iopoaf, and ioplsc0. 
• 08:24UTC Left voice message with Dave Barker. 08:32UTC Voicemail left with Erik. 
• 08:35UTC Dave Barker online and looking at front end crashes. alog 73629
• 08:45UTC Dave restarting computers as all DAC cards look okay. I requested ISC_LOCK to IDLE and all corner station (not HAM7) SUS to SAFE (Safe State for IFO wiki)  and Dave bypassed SEI. 
• 09:10UTC CDS Okay
  • SUS WD untripped and back to nominal configuration. 
  • SEI ISI WD tripped (payload type) when Dave bypassed them reset those WDs too. 
• 09:35UTC All SUS and SEI nominal. Resumed locking with ISC_LOCK via DOWN, INIT, NLN. 
• 09:45UTC No light seen on green arms so plan to run baffle align scripts (62024).

Investigating a dolphin crash of several corner station front ends.

TITLE: 10/21 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 162Mpc
INCOMING OPERATOR: Camilla (OWL)
SHIFT SUMMARY: Observing and Locked for 35hrs 45mins.
LOG:

23:00UTC Detector in Commissioning and has been Locked for 28hours

23:02 Back to Observing

23:26 Earthquake mode activated due to incoming earthquake from Guatemala
23:36 Back to CALM

Observing at 164Mpc and have been Locked for 32 hours.

Nothing to report

Gabriele, Jim, Arnaud

We have been looking for the 1.23Hz line seen largely in DARM and other loops (73622). We think this is coming from the ETMX ISI, which shows a strong line at the same frequency mostly in the Y and RZ dofs. The summary pages from today show the evidence of this problem, as well as the ndscope attached in fig1. Trending back the signal, this issue started around October 01 at 05am PDT, see bottom plot on fig2. Spectrum of all individual sensors (in loop) before and after are attached. Some outliers in the stage 1 sensors (H1 L4C, Y1, Y2 T240 ...) but hard to tell what's the problem without taking the ISI down. More to follow at next opportunity (maintenance, or ifo down).

TITLE: 10/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 165Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

• 18:06UTC superevent S231020bw, still only getting the automated phonecall and no verbal alarm
• The operator NUC cdsws13 has been really slow today, I noticed it especially struggling when I was trying to ndscope multiple months of data for just 1 channel
• We had commissioning time from 20:00 - 23:09UTC which included a SRCL FF retune (accepted in SDF), peakmon filter updates/checks, and SQZ tests/checks                                                                                                                                                                                                  LOG:                                             

TITLE: 10/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.31 μm/s
QUICK SUMMARY:

We're Commissioning and are going on 28hours Locked.

(Randy P., Chris S., Travis S., Gerardo M.)

After flipping the septum carefully with the forklift to get to the non-grooved side, the new door for HAM7 +X side got new threads on what it used to be the annulus thru hole.  Now, the door is in queue to get cleaned.  We used this aLOG as a guide, as well as the following drawing taken from the DCC D1900512.  Only IPA alcohol was used to cut the threads.

Naoki, Sheila

Summary:  We have repeated the test from 73400, with our higher level of squeezing after the crystal move, and with the ASC off for squeezing angles other than squeezing.  This seems to generally reproduce the results in that alog, convincing us that most of the rotation we are seeing is from the mode matching change not an alignment shift.  

We have saved references in userapps/sqz/h1/Templates/dtt/DARM/PSAMS_tests_Oct202023.xml.  This is a copy of PSAMS_tests_Oct112023.xml, with the references saved there and shown in alog 73400  The times written below are minimum times, for many of these references there is actually more time.  

times (PSAMs 200/200):

• no sqz 10/20/2023 20:19-20:32 UTC (large glitch at around 20:22, starting at 20:23) (reference 10)
• after some ASC troubles and temperature adjustment, resetting AS42, start FDS time at 21:19:33 300 seconds demod 162.95 (ref 11)
• turned off AS42, and FC ASC, anti sqz 21:33:34 300 seconds demod 228.64 (ref 12)
• + mid sqz 21:43:16 300 seconds demod 193.56 (ref 13) (until 21:50:50, big glitch near end of time)
• - mid sqz 21:53:17-21:59:57 300 seconds demod 30.48 (ref 14)

set sqz angle back to sqz, turned AS42 and FC ASC, set PSAMs to 120/120 with 30 second ramp

times (PSAMS 120/120):

• sqz 22:07:33 300 seconds demod 162.95 (ref 15)  Note: while Naoki was tuning the sqz angle here, he found that for a few degrees different demod phase the high frequency squeezing could be better than what is shown here, but the 400Hz squeezing was worse.  Here we are just using the same demod phase as for 200/200 psams, but this isn't the best high frequency demod phase.  
• turned off ASC for AS 42 and FC
• asqz 22:17:33-22:23:30 360 seconds demod 228.64 (ref 16) (a big glitch around 22:21:30) (ref 16)
• + mid sqz 22:24:27 300 seconds demod angle 193.56 (ref 17)
• - mid sqz 22:33:33 300 seconds demod angle 30.48 (ref 18)

RyanC, Camilla

I wrote some code to plot 5 months of ESD actuation force on ETMX based on equation 10 from T1700446 using the coefficients derived by the inlock charge measurements, I wasn't sure the values to use for δV_s so the exact numbers for force are incorrect but the trend should be the same. We can see that the ESD actuation force for ETMX has been increasing since June.

Regarding Kappa_TST there was a step down at the end of August which was from the CAL team updating the calibration to bring Kappa closer to 1 alog72594, but we can see that it has been slowly increasing since June. KAPPA_TST increasing means that for the same amount of digital counts, the ESD is applying more force which matches what the figures are showing.

The code is located at /ligo/home/ryan.crouch/Desktop/Charge_measurements/Force_calc_from_inlock.py and it needs to be run in the aligoNB conda environment.

Following up on the observtion that the SRCL FF is increasing the DARM low frequency (2-3 Hz) motion (73561) and that this motion might be the origin of non-stationary noise (73546), I designed a new high pass filter for SRCLFF and retuned the FF.

The new high pass gives us about 4 times less reinjection between 2 and 4 Hz, at the price of a phase rotation of 20 degrees at 10 Hz. Therefore the old SRCL FF was not performing well anymore. I did a noise inection and refit the FF filter. Fitting this filter is tricky and I don't think I got an optimal solution. But it looks like the new highpass with the new FF performs fine, is at least as effective as the old highpass and the old FF, by looking at the coherence between DARM and SRCL.

DARM RMS is improved a little between 3 and 4 Hz, so maybe we'll see some improvement in the non-stationary noise. We need to figure out what else is making DARM noise at 3.4 Hz. There is also an enormous line at 1.23 Hz that is the cause of most of DARM RMS. I think the bicoherence shows that the 1.23 Hz line is a source of noise modulation too.

Fri Oct 20 10:11:27 2023 INFO: Fill completed in 11min 23secs

Gerardo confirmed a good fill curbside.

After Gabriele's 73546, Jenne and I looked LSC-DARN_IN1 before and after the feedforward was added. You can see the new FF (in particular SRCL) has more noise 5 to 9Hz, plot attached of only old vs new FF. The larger peaks at 0.05 and 0.1Hz are caused by increased microseism, they are not present on Oct 14th. No other noise down to 1e-4Hz.

We turned off the MICH FF only 20:07UTC - 20:21UTC and then the SRCL FF only 20:22UTC - 20:35UTC. Turned off both FF from 20:35UTC until 20:42UTC where we had a lockloss. Plot attached of LSC-DARN_IN1 in these configurations.

And the old verus new MICH and SRCL FF filters attached.

Using two periods of quiet time during the last couple of days (1381575618 + 3600s, 1381550418 + 3600s) I computed the usual coherences:

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

The most interesting observation is that, for the first time as far as I can remember, there is no coherence above threshold with any channels for wide bands in the low frequency range, notably between 20 and 30 Hz, and also for many bands above 50 Hz. I'll assume for now that most of the noise above ~50 Hz is explained by thermal noise and quantum noise, and focus on the low frequency range (<50 Hz).

Looking at the PSDs for the two hour-long times, the noise belowe 50 Hz seems to be quite repeatable, and follows closely a 1/f^4 slope. Looking at a spectrogram (especially when whitened with the median), one can see that there is still some non-stationary noise, although not very large. So it seems to me that the noise below ~50 Hz is made up o some stationary 1/f^4 unknown noise (not coherent with any of the 4000+ auxiliary channels we record) and some non-stationary noise. This is not hard evidence, but an interesting observation.

Concerning the non-stationary noise, I think there is evidence that it's correlated with the DARM low frequency RMS. I computed the GDS-CALIB RMS between 20 and 50 Hz (whitened to the median to weight equally the frequency bins even though the PSD has a steep slope), and the LSC_DARM_IN1 RMS between 2.5 and 3.5 Hz (I tried a few different bands and this is the best). There is a clear correlation between the two RMS, as shown in a scatter plot, where every dot is the RMS computed over 5 seconds of data, using a spectrogram.