TITLE: 11/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan Short
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 6mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY:

• Relocking from a recent LL
• All systems look good

I noticed earlier this week that two vacuum guage pressures had been temporarily removed from the alarm system in Sep 2022 during a BSC2/HAM6 vent. I have added them back into the alarm configuration and restarted the service.

+<!-- WP10675 remove for vent
 <Channel name="H0:VAC-LY_Y1_PT120B_PRESS_TORR" low="1.0e-10" high="2.0e-06" description="VE gauge, PT120B BSC2 CC">
 

+<!-- WP10675 07Sep2022. Temporarily remove HAM6 Alarms for the duration of the vent.
 <Channel name="H0:VAC-LX_Y0_PT110_MOD1_PRESS_TORR" low="1.0e-10" high="5.0e-06" description="HAM6 VAC">
 

I have added trend buttons to the FMCS Overview MEDM which open MEDM screens showing the most recent 1day, 1week, 1month trend plots.

Attachment shows the Overview and the VEA temperature trends, showing the recent MY drop in temperature.

A follow up to an operator report that the MC3 camera image on the FOM occassionally flashes blue-screen. I can confirm I have seen several flashes today on my gstreamer display running on my nomachine session. Normally we would immediately restart the server process, except h1digivideo1 was actually rebooted late Tuesday morning which appears to have caused the issue.

At the next TOO I will restart the server process as a simple first test. We may then progress to power cycling the camera.

The low temperature in Mid Y this morning was the result of a malfunctioning heater. Both SCRs had burned up so there was no heating control available. I bypassed both SCRs and wired straight from the line voltage fuses. The heat staging required rewiring as it had been wired to bring on all stages of heating with only a single stage heating command. 

1384194867

21 hr 17 min lock. PRG was seen on the nuc30 FOM oscillating and incresing before lock loss. Looking at the standard plots, it looks like an ASC ringup, though I can't tell who was first.

Thu Nov 16 10:03:35 2023 INFO: Fill completed in 3min 32secs

Gerardo confirmed this short fill was a good one from curbside.

TITLE: 11/16 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY: Locked for 18.75 hours. MY has a temperature alarm, looks to be acknowledged but I'll contact FAC.

TITLE: 11/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We've been locked for 10:43, the range has dropped by ~5 Mpc over the past 2 hours or so, the wind has also increased over the same time frame but not by too much 5 -->10mph, and the live SQZ DARM trace is below the FDS reference on NUC33. Another quiet night.
 

• STATE of H1: Observing at 160Mpc

• We've been locked for 6:47, in Observing since 00:33

Naoki, Sheila

In the AS72 sensing matrix measurement in alog74106, Daniel suggested to increase the whitening gain of AS72 since it could be limited by ADC noise. We checked the whitening filter of AS72 A and B. Both of them have 12dB whitening gain, but one stage whitening is engaged for AS72 A, while two stage whitening is engaged for AS72 B. We decided to engage the 2 stage whitening for AS72 A, which is used in SRC1. The IFO locks without any problem with this additional whitening. We accepted some SDFs as shown in the attached figures. We will try to increase the whitening gain later.

Sheila, Camilla, Naoki

After alog74223, we engaged the SQZ phase dither servo as shown in the first attached figure. After we engaged the dither servo, the error signal (SQZ-PHASE_DITHER_DEMOD_I_OUTPUT) goes to 0 and the SQZ phase (SQZ-CLF_REFL_RF6_PHASE_PHASEDEG) goes to around optimal value. 

Detail

First we checked the error signal of dither servo by scanning SQZ phase as shown in the second attached figure. The dither error signal is SQZ-PHASE_DITHER_DEMOD_I_OUTPUT shown in gray. You can see the two zero crossing points where the BLRMS4 (SQZ-DCPD_SUM_RMS4_MON) is minimum and maximum.

Then we made a new state in SQZ_MANAGER guardian named ADJUST_SQZ_ANG to adjust the SQZ phase using dither servo. The servo is engaged with cdu.Servo and it uses the SQZ-PHASE_DITHER_DEMOD_I_OUT16 as readback channel and the SQZ-PHASE-OUTMTRX_1_1 as control channel. We cannot use the SQZ phase (SQZ-CLF_REFL_RF6_PHASE_PHASEDEG) as control channel since it is a discrete number (SQZ-CLF_REFL_RF6_PHASE_DELAYSTEP must be an integer). So we stored the value of the DELAYSTEP in the unused output matrix element (SQZ-PHASE-OUTMTRX_1_1) and used it as control channel. The DELAYSTEP itself is controlled by rounding the value of SQZ-PHASE-OUTMTRX_1_1 to an integer. 

Note: Although the SQZ phase dither servo seems to work, the SQZ phase the servo ended up (152.7 deg) is not exactly optimal value (145.47 deg). We needed to adjust the SQZ phase manually to really optimize the SQZ BLRMS.

This morning I took measurements for MICH and SRCL feedforward and exported in .txt files in /lsc/h1/scripts/feedforward.  Gabriele changed SRCL in 73662 Oct 20th. MICH last changed 73420 Oct 12th.

I didn't have good luck re-fitting MICH, I made a new filter in FM7 but although it fit 100-200Hz well, I couldn't get the fit to also be good <20Hz. Plot attached - RED TRACE.

I also tried the current FF without 17.7Hz line, FM6, 74139, it alos change the fit of the filter 20-80Hz, wasn't sure if this was better or worse so will discuss with others and we can implement on Friday. Plot attached, RED TRACE.

Strangely, the current MICH FF looked better than it has done recently and didn't appear to change with thermalization. What has changed since last week 74102?!

TITLE: 11/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.30 μm/s
QUICK SUMMARY:

• Commissioning just wrapped up, back into observing at 00:33
• All systems look good

TITLE: 11/16 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: One lock loss from commissioning with an automated relock during the shift. Most of the shift has been occupied by commissioning time, but we are back to observing at 0033 UTC.
LOG:

• 1606 Senske on site to start blowing out sprinklers
• 1709 Out of Observing for commissioning time
• 1906 Observing
• 2009 Commissioning
• 2009 Lock loss
• 2117 Low noise, more commissioning
• 0033 Observing

Louis and I have been looking at increasing the offloading of the signal from the ESD to the PUM and UIM, in light of 73913. 

I have attempted a few times to make measurements by exciting at the L2 LOCK L filter, this results in poor coherence even for amplitudes that are quite large in DARM, and turning up the amplitude slightly has caused a lockloss by saturating the ESD. 

On Tuesday morning I engaged the PUM boost (L2 LOCKL FM2, boost4.5 which is a boost with a little resG aaround 4.5Hz).  Some history (with links to old alogs about this filter is here: 48767) we used to run with this boost but turned it off in early O3 because angle to length cross couplings were causing instabilities of the DARM loop.  On Tuesday morning I engaged this boost, and we stayed locked.  The first attachment shows a comparison of our ETMX drives to LLO's (LLO also uses ETMY L1 for DARM control, but I haven't plotted that here), H1's usual configuration is in gold and the time with the PUM boost engaged is in red. The ESD drive RMS is reduced by more than a fator of 2 with the PUM boost engaged.  I quickly tried a swept sine injection, and saw that the coherence was somewhat better than earlier measurements with a very small amplitude injection, so it seemed promising that we might be able to get a better measurement of the cross over with the PUM boost engaged.  

Today I engaged this boost again during commisoning time and we immediately lost lock.  The third attachment shows that turning on the boost certainly seems to be the cause of the lockloss. 

We can probably rely on the pyDARM model for the PUM crossover, since the calibration measurements validate the model above 10Hz. Today I was able to make a measurement of the UIM crossover, which Louis can use to compare to pyDARM from 1-10Hz. 

I measured FC IR OLG as shown in the attached figure. The FC IR OLG is higher than the purple reference on March 2023. So I decreased the IR gain from -5 to -3.5 and the OLG became similar to the purple reference. I updated the fc_wfs_a_ir_gain in sqzparams and loaded SQZ_FC guardian.

I checked the FC GR SUS/VCO crossover as shown in the attached figure. The crossover is about 60 Hz which is much larger than the blue reference on December 2022. This higher GR SUS gain could cause the instability during the transition from GR to IR. I reduced the GR SUS gain from 1 to 0.5 and the crossover became similar to the blue reference. I updated the SQZ_FC guardian to change this gain. Let's see if this helps the recent failure of FC GR to IR transition.