For FAMIS #26294:  All looks well for the last week for all site HVAC fans (see attached trends).

(Camilla,Corey,Naoki, Vicky)

Once H1 got through a few hiccups at the DRMI ASC & BSC St2 steps, it went straight to NLN. 

There were some Squeezer items which needed to be changed:

1. PSAM Offset changes for ZM4 & ZM5 (under the TCSCS SDF) were ACCEPTED with Camilla's approval (see attached screenshot)
2. ZM4/5/6 alignment changes needed---Naoki updated pointing & Camilla ACCEPTED the SDF.
3. SQZ_MANAGER Guardian node needed to be transitioned to MANAGED---> Select MANAGED button on ALL screen
   • Plus SQZ_MANAGER needed to be listed as Managed by "ISC_LOCK"----> In a terminal entered:   caput H1:GRD-SQZ_MANAGER_MANAGER ISC_LOCK  (Vicky helped us with this)

I made an attempt at updating Camilla's PSAMs double raster script to include alignment scans to optimize the squeezing throughput at each step and to automate measurements of FDS and FDAS spectra:

/opt/rtcds/userapps/release/sqz/h1/scripts/PSAMs_double_raster_v2.py

This should roughly replecate the functionality of the PSAM scan automation code used at Livingston (llo 64645).  It likely still requires debugging, but I wanted to tag it here before I leave.

Naoki, Camilla, Eric

We've decided to try out our other candidate PSAM values for a few days.  While retuning, we also took some FDS/AS and FIS/AS traces so we can characterize this operating point using Dhruva's interactive_sqz code.

PSAMs at 8.8/-0.7

• 20:48:30-20:58:30 UTC  No SQZ time (10 min)

Measured NLG =  17.07 (following 76542). Adjusted OPO temperature  to 31.475

PSAMs moved to  7.5/0.5,  walked alignment back manually on ZM4/5 using trend from Tuesday, Ran Scan_alignment for FDAS. 

Data:

• 21:13:40-21:18:40  FDAS, CLF=104 (5 min)
• 21:20:30-21:25:30  FDAS +10deg,  CLF=114 (5min)
• 21:26:30-21:31:30  FDAS - 10deg,  CLF=94 (5 min)
• 21:33:45-21:38:45 FDS, CLF = 195 (5 min)
• 21:39:10-21:44:10 FDS + 10deg ,CLF=205 (5 min)
• 21:44:45-21:49:45 FDS - 10deg, CLF=185 (5 min)
• 21:51:00-21:56:00 MidSQZ, CLF=148 (5 min)
• 21:57:10-22:02:10 MidSQZ2, CLF = 216.45 (5 min)
• 22:06:00-22:11:00 FIAS, CLF = 104 (5 min)
• 22:13:20-22:18:20 FIS, CLF = 195 (5 min)
• 22:21:00-22:26:00 MidFIS, CLF = 217 (5 min)
• 22:27:10-22:32:10 MidFIS, CLF = 150 (5 min)

There was a fair amount of A2L work going on concurrently which may have been altering the technical noise quite a bit across the dataset.  We intended to grab another NoSQZ at the end, but there was lock loss :( 

We are going to leave things at this PSAM setting tonight with H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG = 190.  

Jennie W, Sheila, Jenne

We did steps of 1 up in PITCH for camera offset servo 2 which controls the beam spot on ETMX by moving ITMX and ETMX, as suggested by this overnight test Camilla  and I did.

This improved the build-ups and we went past the optimum point which we found to be CAM_PIT2_OFFSET = -173, so we set the offset to this. The optimum point is shown by the right most cursor in this image.

We did steps of 1 up in YAW for camera offset servo 3 which controls the beam spot on ETMY by moving ITMY and ETMY, as suggested by this overnight test Camilla  and I did.

This improved the build-ups and we went past the optimum point which we found to be CAM_YAW3_OFFSET = -349.5, so we set the offset to this. The optimum point is shown by the right most cursor in this image. There was confusion as the PITCH and YAW degrees are cross-coupled (this confused us as one must wait for the pitch servo to converge while changing the yaw degree of freedom).

We then tried to optimise our last DOF for the camera servos: PITCH for servo 3. We first moved the offset up and then down, but made the build-ups worse each time. By this point we had increased thje gain of the camera servo filter banks by 2 to speed up the converging. CAM_PIT3_OFFSET should be set to its nominal at -230 counts.

Then we ran the A2L gain scripts we used the other day successfully to optimise thse loops to match the new arm alignment. During running of this script we lost lock, not sure why.

We did not add these new offsets to the guardian because of the lock loss, we will do them together with the A2L optimisation during the nest commissioning period.

The A2L script is is userapps/isc/h1/scripts and is called run_all_a2l.sh

TITLE: 04/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.16 μm/s
QUICK SUMMARY:

Getting hand-off from TJ as H1 was recovering from a lockloss (from a 17.5hr lock).  So far we have had 3-locklosses in a row toward the end of DRMI turning on ASC (to most recently when turning on BS's Stage-2----contemplating an Initial Alignment if there is a 4th lockloss!

TITLE: 04/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Currently recovering from a 17.4 hour lock. Commissioning time from 1pmPT today and has just wrapped up. Handing off to Corey to finish locking.
LOG:

• 2010 Out of Observing for planned commissioning
• 2232 Lock loss

Fri Apr 12 10:12:09 2024 INFO: Fill completed in 12min 5secs

Gerardo confirmed a good fill curbside.

TITLE: 04/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 1mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY: Locked for 10 hours. We've had a handful of EX saturations throughout the night, but our range is looking good. Commissioning planned for today at 1pm PT.

Below is the summary of the DQ shift for the week from 2024-04-01 to 2024-04-07

• The detector had an average (observing) uptime of 60%. There were also times when the detector was locked and used for commissioning activities.
  • The range was typically around 158 Mpc.
  • Most of the days, some non-stationary noise was visible in the low-frequency region, specifically in the 10 - 50 Hz band.
  • There were a few strong lines in the 20 - 50 Hz region, which seem to come from the bounce and roll modes of the triple suspensions (HSTS, HLTS)  (a-log 70778, a-log 49643). 
  • There were BS violin modes around 300 Hz and their second and third harmonics around 600 and 900 Hz, respectively. 
  • Some wandering lines around 4640 Hz, 6020 Hz, and 6310 Hz which all seem connected. 
• The glitch rates at different Omicron SNRs were mostly consistent throughout the week. 
  • There were excess glitches around 1300 Hz, causing a bump around SNR ~ 10 in the omicron glitch histogram, which went away after the SQZ ADF was turned off (a-log 76962). 
  • Most of the strong omicron glitches were centered around specific frequencies such as 32 Hz, 40 Hz, 50 Hz, 280 Hz, 400 Hz, etc.
• For most days of the week, we saw occasional noise bursts around 32 Hz, which was also seen on many of the corner station accelerometers and ground seismic sensors (a-log 77127). 
• A few accelerometers had data quality issues, probably either not connected or bad connection (a-log 77009). 
• The dominant channels in Hveto were usually H1:PEM-EX_VMON_ETMX_ESDPOWER48_DQ, H1:ASC-X_TR_B_NSUM_OUT_DQ, H1:ASC-AS_A_RF45_Q_YAW_OUT_DQ. The ASC channels showed up on the last few days of the week.
• The rate of PyCBC triggers seemed comparable to previous weeks. 
• On April 1st, the scattering page identified many glitches in the 20 - 60 Hz region as due to scattering. Due to the network outage, the scattering pages were unavailable for the last few days of the week. So it is not clear whether this applied to the rest of the week. 
• Nonsens cleaning removed some of the features between 100 Hz and 600 Hz, improving the range.

The full DQ shift report with day-by-day details is available at https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20240401

Since PMC is so sensitive to acoustic noise I was curious if PMC added additional contributions to the sqz phase noise. So, I did the same SQZ phase noise budget analysis that was done in O3. The explanation and the methodology can be found in P2200287 chapter 6.3.1 onward.  

PMC noise contribution to sqz phase noise is 0.59 mrad. There's no need to put extra efforts into damping the cavity unless people are annoyed that it loses lock everytime we use some of the motorized half wave plate.

The FWHM and FSR of the PMC was measured by Vicky at MIT. They are 175MHz and 713 MHz respectively. We didn't repeat this measurement after the installation because the LVEA was too loud and the finesse is high for s-pol (4070).

The Vpp calibration for the PMC is 2.22 Vpp/FWHM. This was measured after the PMC was installed. In order to fit the transfer function I had to multiply a factor of 1.5. Vicky mentioned the PMC PZT is very nonlinear so my V/Hz calibration could be off. If that's true then the PMC trace needs to be multiplied by a factor of 1.5.

I had to multiply a factor of 0.33 to the CLF and LO loop in order to fit the transfer function. Even after using the new VCO V to Hz calibration that Daniel measrued. I suspect the Vpp/rad calibration was over estimated due to RLF. If that's true then the LO and CLF traces shown in this alog needs to be multiplied by a factor of 0.33. 

The PZT driver for the PMC is the same as in the SHG and the OPO

This plot shows overall noise contributions to the sqz angle from all the sqz loops. The data were taken in between 11-18 March 2024 (pre O4b). The rms from different loops are added in quadrature to get sqz phase noise. I don't have filter cavity red lengthnoise data handy but a rough calculation from Dhruva's measurement back in February last year the lengthnoise should be sitting at 0.3 mrad/sqrt(Hz) at a 100Hz. If the rms scales the same way that's 3 mrad added in quadrature with the rest of the noise contributions. 

This screenshot shows more details analysis from PMC, SHG, OPO, CLF (6dBm and -23dBm) along with the transfer functions and sensing noise.

A separate screenshot for LO loop, low and high CLF power, with the transfer functions and sensing noise.

The table below lists all the noise contribution from sqz loops to sqz angle. Until we achieve a single digit % loss these numbers are negligible. The major contribution to sqz angle pahse nosie still comes from the IFO control signal sidebands. I didn't remeasure the TTFSS noise so I used the in-loop rms number from last year.

TITLE: 04/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Mostly quiet shift with just one lockloss. Reacquisition was fairly straightforward; I only had to manually find DIFF IR.

• 03:37 - Lockloss, unkown cause (alog77126)
• 04:58 - Reached NLN and started observing
  • Waited for 10 minutes in OMC_WHITENING to damp violins

H1 has now been locked for 2 hours.

LOG:

No log for this shift.

We see occasional excess nosie around 32.5 Hz in the h(t). This feature has been there for a long time, was present even in O3. They were identified before and were a-logged, for example 52796 (?), 73601. The first plot in this a-log shows the feature in last week's data. A corresponding featuer is seen in almost all the accelerometers and ground seismometers in the corner station (the second and third plots show the HAM6 and PSL accelerometers data while the fourth plot shows the HAM2 STS). In addition to the 32.5 Hz feature, if we squint, we can also a 38-39 Hz feature in h(t) which seems to presnt only in the vibration sensors in the PSL/HAM1/HAM2 region, so maybe there is a coupling is in that region. Not all features we see in those sensors show up in h(t), not atleast very strong, so maybe something special about these frequencies. 

Lockloss @ 03:37 - no obvious cause, but there was an ITMX saturation immediately before the lockloss. First signal that shows motion is LSC-DARM.

Online lockloss tool is down.

State of H1: Observing at 163Mpc

H1 has now been locked for 9.5 hours. Very quiet evening so far.

HAM1 ASC FF was off from 1396381762 to 1396382969 (20 minutes starting 90 minutes into lock). Using this data I could retune the feed forward filters that subtract HAM1 motion from the ASC signals.

I based the attached jupyter code on an older version, and automated the subtraction training for all pitch and yaw ASC signals (CHARD, INP1, PRC2, DC1 and DC2).

Looking at the filters that are loaded now, we used to do the FF only for the pitch degrees of freedom. The subtraction seems to be doing something good in yaw too, so I suggest we upload and try the yaw feedforward filter.

The first plot shows the expected subtraction predicted by NonSENS. The second plot shows the absolute value of the transfer functions.

Finally, the attached text file contains the foton filter definitions for all the feedforward filter banks. I haven't upload those flter to foton, and not tried them yet. Before each filter there is the name of the filter bank where it should be loaded, for example H1:HPI-HAM1_TTL4C_FF_CART2ASCP_1_1