The broadband glitching that was present in the early hours of Dec 11 (UTC) appears to have suddenly and entirely stopped at 10:36:30 UTC - this sharp feature can be seen in the daily range plot. I completed a series of LASSO investigations around this time in the hopes that such a sharp feature would make it easier for LASSO to identify correlations. I find a number of trend channels that have drastic changes at the same time as this turn-off point related to TCS-ITMY_CO2, ALS-Y_WFS, and SUS-MC3_M1.

The runs I completed are linked here: 

1. LASSO run of the first half of Dec 11 with the sensemon range as the primary channel 
2. LASSO run of times near the turn-off point with TCS-ITMY_CO2 as the primary channel 
3. LASSO run of times near the turn-off point with the sensemon range as the primary channel

Run #1 was a generic run of LASSO in the hopes of identifying a correlation. While no channel was highlighted as strongly correlated to the entire time period, this run does identify  H1:TCS-ITMY_CO2_QPD_B_SEG2_OUTPUT (rank 11) and H1:TCS-ITMY_CO2_QPD_B_SEG2_INMON (rank 15) as having a drastic feature at the turn-off point (example figure). Based on this information, I launched targeted runs #2 and #3. 

Run #2 is a run of LASSO using H1:TCS-ITMY_CO2_QPD_B_SEG2_OUTPUT as the primary channel to correlate against. This was designed to identify any additional channels that may show a drastic change in behavior at the same time. Channels of interest from this run include H1:ALS-Y_WFS_B_DC_SEG3_OUT16 (example figure) and H1:ALS-Y_WFS_B_DC_MTRX_Y_OUTMON (example figure). SEISMON channels were also found to be correlated, but this is likely a coincidence. 

Run #3 targets the same turn-on point, but with the standard sensemon range as the primary channel. This run revealed an additional channel with a change in behavior at the time of interest, H1:SUS-MC3_M1_DAMP_P_INMON (example figure). 

Based on these runs, the TCS-IMTY_CO2 and ALS-Y_WFS channels are the best leads for additional investigations into the source of this glitching. 

TITLE: 12/11 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.32 μm/s
QUICK SUMMARY:

• We've been locked for 14:20, in observing since 03:33
• 2ndary microseism is decreasing, its just below the 90th percentile
• Low wind

TITLE: 12/11 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 102Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Currently Observing and have been Locked for almost 5 hours.  Our range is still all over the place unfortunately. I jumped in and out of Observing a few times by turning squeezing on and off to check for differences with the range (81753), but didn't find anything.
LOG:

00:30 Relocking
01:08 NOMINAL_LOW_NOISE
01:14 Observing

    02:57 Went out of Observing and turned off SQZ to see if that fixes the mystery noise 
    03:09 Back to FDS
    03:19 Turned off SQZ
    03:33 Back to FDS and back to Observing

[Jason, Masayuki]

Summary

The PMC heater calibration was performed last week (Tuesday). The calibration involved adjusting the temperature loop set point and monitoring the corresponding changes in PMC temperature and length. The results were validated using previous measurements and compared to similar evaluations at LLO. Additionally, the necessity of the heater for JAC operations was assessed, highlighting it would be needed for long term operation.

Details

PMC Heater Calibration

• The calibration of the PMC heater was conducted. The PMC remained locked while the temperature loop set point was adjusted from the usual 3.7V to 1.7V. This adjustment corresponds to a PMC length change of 0.30 μm based on a prior measurement (alog entry 81385).
• A PMC temperature change of 0.023 K was recorded using the thermometer. From this result, the thermal expansion coefficient was calculated as:

  0.30 μm / 0.023 K = 13 μm/K

  This result is consistent with the thermal expansion coefficient of aluminum, 22e-6/K, and the approximate PMC length of 0.5 m.
• No significant changes in heater output were detected before and after the set point adjustment.
• First Plot Description:
  • Top panel: PZT input calibrated for PMC length.
  • Middle panel: PMC temperature measured with the thermometer.
  • Bottom panel: Heater output, with histograms shown for the middle and bottom panels.

Reference to LLO Calibration

• To further calibrate the PMC heater, the LLO heater calibration (alog entry 51467, attached plot) was used as a reference.
• At LLO, heater input changes from 2.5V to 4V resulted in PMC temperature changes from 292.2 K to 291.125 K, indicating a heater efficiency of \(0.67 \, \text{K}/\text{V}\). Using this efficiency, the PMC expansion rate per heater voltage was calculated as:

  13 μm/K × 0.67 K/V = 8.7 μm/V

Monthly Drift Analysis

• With this calibration, the monthly heater output was evaluated.
• Second Plot Description:
  • Top panel: Heater-induced temperature actuation (left axis) and the corresponding PMC expansion (right axis).
  • Bottom panel: Required PZT input for equivalent actuation without the heater.
• Periodic large spikes were observed daily. However, since each spike occurred within approximately 10 seconds, as shown in the attached screenshot, these spikes are not attributed to actual temperature changes. A moving median (red line) was applied to highlight the spikes. Note that this moving median is not an ideal representation, as the extracted data is already averaged over 1-minute intervals. However, it is still useful for illustrating the spikes.
• Despite the spikes, the heater compensated for a length change equivalent to approximately 500 V in PZT input is typical day-time drift, but sometime, it can drift more than 1000V in a day.
• A 10-day analysis of LLO PMC showed no spikes, and the results were consistent with LHO data. Result is shown in the third plot as same structure as the second plot.

Implications for JAC Operations

The PZT can be railed in a day from this measurement, so we would need the heater for JAC operation.

Additional Observations

Spikes observed at LHO caused glitches in transmitted power, as shown in the attached plot, and may require resolution. Redesigning the filters could potentially mitigate these anomalies.

Just went out of Observing and took SQZ manager to no squeezing to check if the noise issues are related to squeezing. We'll be doing no squeezing for 10mins, SQZ for 10, no sqz for 10, and then back to sqzing and Observing

Today Sheila realigned the beam on IM4 trans QPD (81735). This beam has been clipped at least since the O4 break due to various reasons (in this particular alog we tried to fix it, but then undid the fix, I'm adding here so we have a general time reference for when we first noticed the problem: 76291). As a result, the PRG calibration for O4b has been fishy, since it is normalized by the IM4 trans QPD power. Today, with the beam properly centered, I checked the PRG calibration to make sure it's still good.

Craig did this after ITMY was replaced: 58327. I followed his same steps with help from Ryan S and Sheila. First, we ran initial alignment on the y arm, which uses the green camera references. We waited until that alignment was converged and then stepped through the input_align_yarm states in the ALIGN_IFO guardian. I recorded the IM4 trans value as well as the y arm transmission value.

When we run a normal initial alignment, we lock input align with the x arm, so I used that opportunity to similarly record the x arm transmission value and IM4 trans. As a note: the green input alignment references are set when we converge the full IFO ASC, therefore I believe the single arm alignment after we run the green initial alignment is probably very close to the full IFO alignment.

Then, we paused in DARM_TO_DC_READOUT in the ISC LOCK guardian; this is just after all the full IFO ASC converges at 2W. I grabbed the x and y arm transmission values and IM4 trans.

Channels: H1:IMC-IM4_TRANS_NSUM_OUT16, H1:LSC-TR_X_NORM_OUT16, H1:LSC_TR_Y_NORM_OUT16

Single arm lock values:

Y-arm trans: 0.91, IM4 trans: 1.95

X-arm trans: 1.01, IM4 trans: 1.98

Full lock values:

Y-arm trans: 1684

X-arm trans: 1708

IM4 trans: 1.98

Calculation:

PRM transmission = 0.031

PRG = Tp * Y-arm trans (full ifo) / Y-arm trans (yarm only) * Input power (yarm only) / Input power (full ifo) (copied directly from Craig's alog)

PRG from Y arm = 56.5

PRG from X arm = 54.0

PRG reported from H1:LSC-PR_GAIN_OUT16 at the 2W lock time: 54

Therefore, I think our PRG calibration is correct. We can begin to cultivate a good O4b power up data set for modeling.

TITLE: 12/11 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Long maintenance day with a great many activities wrapped up late afternoon and initial alignment started around 23:40. The biggest issue we've encountered is that the FSS autolocker is having trouble locking the RefCav; it can grab the resonance but loses it after about a second, so it's been taking quite a while to lock (I manually did it twice this afternoon to speed things along). However, if the FSS is locked, it seems happy, the only issue appears to be with relocking. Otherwise, initial alignment ran smoothly and main locking started at 00:24. Currently up to PREP_ASC_FOR_FULL_IFO.
LOG:

After our CO2 tests this morning 81723 we've reverted the PEM_MAG_INJ and SUS_CHARGE back to their nominal Tuesday start times of 7:20 and 7:45am. This was changed in 81474 but today was the first chance we got to turn off the CO2s before Tuesday maintenance started.

TITLE: 12/11 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ryan C / Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 4mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.43 μm/s
QUICK SUMMARY:

Just started relocking after finishing an initial alignment. Little bit of a spike in the secondary microseism but nothing too bad

Sheila D, TJ S

There has been a bout of SRM M3 watch dog trips around the SRY locking step of initial alignment over the last few weeks (alog81670 for example). Today Sheila and I discussed locking without the FE triggering at all, and just having the ALIGN_IFO node see good flashes and turn on the necessary filters and banks. I tried this out today but I wasn't able to get it to lock any more reliably than what we have now. No matter the method, it would seem to catch with low AS_A values, ~2500 on NSUM vs the normal 5000. From here, SRM would start to be driven before it would realize that it wasn't quite locked. I tried adding some code in ACQUIRE_SRY to try to turn on and off the SRM M1 LOCK L input and the SRCL FM4 filters and even clear the history if necessary, but this didn't work without long settling periods between attempts.

I ended up keeping the ISC_library.is_locked('SRY') looking as AS_A_DC_NSUM_OUTPUT > 4000. This value is a bit higher but safer. It will let the node run through Down and reset drives, integrators, and let SRM settle a bit. I don't think this is a fix, barely even a band aid. It will need some more thought on how to only catch on the correct mode.

Oli, Ibrahim

IFO has been swept.

Of note:

• Crane had to be re-parked to right spot.
• Scissor lift on pallet jack (pictured below) was found plugged in and unplugged. Tagging FMCS.
• Unplugged extension cord (was plugged in with nothing plugged into it).

Per the WP12246:

Visual inspections were performed in the LVEA to track the wires and verify the picomotor controllers existence, connections and spares (physically only). The information gattered was updated in the document E1200072. Important findings were found and the document is pretty much near to the real installation. Electrical part investigations will follow to determine the spares. The names of the rack as well as the physical location for the controllers were verified using the O5 ISC wiring diagram D1900511.

Marc, Fernando