TITLE: 11/27 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.31 μm/s
QUICK SUMMARY:

• 2ndary microseism is still decreasing, wind is low
• We've been locked for 2.5 hours
• Violins look to be damping well
• The range has been slightly dcreasing, low frequency SQZing doesn't look the best on NUC33's DTT

Closes FAMIS28381

The in-lock charge measurements did not run this week due to the IFO losing lock from an Earthquake.

FAMIS 27803 (logging for TJ who actually did this check)

CO2X

• Before: 29.1
• After: 30.0
• Added 300mL

CO2Y

• Before: 9.2
• After: 9.8
• Added 250mL

There was no water in the leak cup. Spreadsheet in T2200289 has been updated.

Now that I have the function working pretty well for my liking (testing from last week - alog81420), I wanted to try it out in a few different scenarios and see how well it performed and how long it took. I also wanted to compare it to our current Increase_Flashes state both in duration and execution. The big changed from last week's testing is that now that we have a working PSL, the PLL and PDH loops are locked. This seemed to really help out and it seems like a very viable solution for a faster alignment state.

Overall, Scan_Alignment seems to work well and in these tests it was faster. I haven't put the functionality back into Scan_Alignment to hold and alignment if it get above threshold, so once I can test that out again it will speed up the smaller misalignment scans. Saving a few minutes for every acquisition that needs some alignment work should add up pretty quick. If given more time next week, I'd like to test this some more with that functionality and see how much faster it is. I'd love to get this into production soon, but I really want to thoroughly test this.

Last week Jenne had to comment out an import of aslArmconfig out of ALS_ARM.py in order for ALS_XARM to run (alog81424). This was a bit odd to me since this file contained info for both arms, and should be fine. I ended up restarting ALS_XARM and this worked. Seems like another case of issue 22. This particular issue is seem in the sei guardians frequently.

The 35.5MHz was switched from the Marconi (IFR2023) to the LHO 35.5MHz RF Source. Temporarily switched to the Marconi as part of troubleshooting of the PMC, see alog 81277. Both the PMC and SQZ were taken down prior to switching the RF signal.

Due to limited maintenance time between diagnosis and action, we triaged the fan failures with IFO uptime.  The following solution while not perfect is just good enough to get us to next Tuesday maintenance.

1 - Failed supply fan on CER-C5 LHS ISC-R2&R4 +24V is runnning at 90F front and rear, no airflow.  The ambient air in that location is very cool, and the current draw is quite low, so we do not expect this supply to trip in these conditions.  Fernando noticed that the -24V supply on the same rack is also slightly elevated in temperature and does not have good air flow, so we suspect this supply fan is comprimised as well.  Neither of these supplies have had their fans upgraded yet.

2 - Failed supply fan on EX-VDD-1 ISC-R1 +24V 3A was running at 110F front and rear, no airflow.  This supply has not had its fan upgraded yet.  The PCAL team was using this supply so we could not replace it before close of maintenance window.  We applied supplementary cooling to the power supply to see it through until next Tuesday.  After supplemental cooling we measured 85F front and 95F rear.

The power supply tray had to be pulled out about 1 foot into the walkway to make space for the supplemental cooling, I placed cones around the hazard, be mindful of the extended rack tray if you do go out to EX berfore next Tuesday.

WP12221

J. Figueroa, F. Mera, M. Pirello

Maintenance activities have finished, the LVEA has been swept, and initial alignment has just finished. Starting lock acquisition now.

WP12220

Prior checkups:
13 August 2024 ALOG79537
14 May 2024 ALOG77832
7 May 2024 ALOG77686
19 Sept 2023 ALOG72968

EY Power Racks
VDC-C2 U35-U33 +12V ISC-YC1-TCS; minor stumbling vibrations detected, good airflow
VDC-C1 U19-U17 +/-18V PCAL; minor stumbling vibrations detected, good airflow 

EX  Power Racks
VDD-1 U24-U22 LHS ISC-R1 +24V; no vibrations, no airflow, 110F front, 110F rear, front meter 27V, 3A, measured 24.5V. (BAD FAN)

CER Power Racks
C1 U39-U37 RHS SUS-C8 18V 6A; no vibrations, 90F front, 115F rear
C5 U7-U5 RHS PSL-R1 18V 3A; minor stumbling vibration detected
C5 U11-U9 LHS ISC-R2&R4 +24V; no vibrations, 90F front, 90F rear, no airflow (BAD FAN)

M. Pirello, J. Figueroa

Tue Nov 26 10:01:33 2024 INFO: Fill completed in 1min 32secs

Very quick fill, only TC-A exceeded the -80C trip (-95C).

Following instructions in alog79596, I took the opportunity this morning to calibrate the PSL rotation stage since it hasn't been done following the most recent NPRO swap.

The measurement file, new calibration fit, and screenshot of newly accepted SDFs are attached.

Daniel, Vicky. We offloaded the TTFSS crystal frequency offsets of ~1.5 GHz to the temperature knobs on the laser controllers again, following the final successful swap to the O1 laser last week lho81426.

The initial to final laser crystal temperature we set on the knobs:

• SQZ 26.07 C --> 25.58 C
• ALS X 26.40 C --> 25.92 C
• ALS Y 30.00 C --> 29.53 C  (finicky broken temperature knob on this laser controller)

Recap of process:

1. Noted the laser temp when TTFSS was running to lock laser to new PSL frequency. This is the "target" temperature we want to offload to knobs.
2. Turned off TTFSS and set crystal frequency to 0 MHz.
3. Note the initial laser temp. Move laser crystal temperature knob to the "target" temperature.
4. Relock TTFSS and check for mode-hopping.

From start (Sept 2024) to end (Nov 2024) of laser swapping saga:

• SQZ:    24.83 C --> 25.58 C
• ALS X: 24.8 C --> 25.92 C
• ALS Y: 28.59 C --> 29.53 C

Recent auxilary laser adjustments:

• 80922: 1st adjustment for O3 NRPO freq
• 81074: 2nd adjustment for O3 NRPO freq (b/c it was mode-hopping)
• 81108: 3rd adjustment for O3 NRPO (after finally tuning laser out of mode-hop zone). ALS Y had to be re-adjusted the next day due to mode-hopping 81117.
• Here: After final NRPO swap to O1 laser.

Bypass will expire:
Tue Nov 26 03:29:36 PM PST 2024
For channel(s):
    H0:FMC-CS_FIRE_PUMP_1
    H0:FMC-CS_FIRE_PUMP_2
 

FAMIS 31061

This week's trends capture how things compare pre- and post-NPRO swap towards the end of last week. Generally things are looking good and have been stable since the swap with probably the most notable change being the drop in PMC transmitted power by ~2W and rise in reflected power by ~5W. We suspect this to be due to slightly worse mode-matching into the PMC, which we plan to check in the coming weeks.

TITLE: 11/26 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 4mph 3min avg
    Primary useism: 0.12 μm/s
    Secondary useism: 0.32 μm/s
QUICK SUMMARY: H1 lost lock this morning at 14:12 UTC due to a M6.1 quake out of Japan and has been down since (meaning magnetic and charge measurements were not run). Moving ISC_LOCK to 'IDLE' and SEI_ENV to 'MAINTENANCE' for maintenance day.

This morning there was a range drop on H1 (163Mpc down to about 151Mpc, see attachment#1).  Was working on trying to figure out how to run the Range Check measurements, but while chatting with Vicky on Teamspeak, she reminded me about the daily CP1 Fill can affect range (see attachment #2 which is plot from Dave's alog)  ....and the effect certainly lines up! (Also see Oli's alog from Sept here.)  The time in question is 1802-1812utc (1002-1012amPT).  I will not share the Low-Range-Plots I took for 1810utc since CP1 Fill is most likely the culprit.

However, a note about the range is that it has not really returned to 163Mpc---it's hovered at 157Mpc post-CP1-Fill for the last 4+hrs.

So I ran another Low Range DTT for about an hour ago (2117utc/1317PT).

• ASC:  Can see noisier CHARD_Y & CHARD_P (attachment #3)
• LSC:  MICH, PRCL, & SRCL are noisier at various frequencies (attachment #4)
• IMC WFS:  There are some noisy IMC WFS B pit & yaw peaks (attachment #5)

After the very successful PSL work this week, we're electing to not offload the temp changes for the ALS or SQZ lasers to their physical knobs tonight.  This means that they all need Crystal Freqs of something near 1.6 GHz (1600 in the channel H1:ALS-X_LASER_HEAD_CRYSTALFREQUENCY).  The new-ish ALS state CHECK_CRYSTAL_FREQ is written assuming that all the lasers have the changes offloaded to their knobs, so that the value in that channel is close to zero.  After we went through SDF revert, we lost those values (and the search values, which Daniel has updated in SDF for the weekend), so we we lost the PLL lock of the aux lasers.  The CHECK_CRYSTAL_FREQ state was 'fighting' us, by putting in candidate values closer to zero.  I've updated its candidate values to be closer to 1600.  Once we offload their temps to the knobs on their front panels (early next week), then we'll want to undo this change.

Oli, Camilla WP12203. Repeat of some of the work done in 2019: EX: 52608, EY: 52636, older: part 1, part 2, part 3.

We misaligned ITMY and turned off the ALS-Y QPD servo with H1:ALS-Y_PZT_SWITCH and placed the Ophir Si scanning slit beam profiler to measure both the 532nm ALSY outgoing beam and the ALSY return beam in the HWS path.

The outgoing beam was a little oblong in the measurements but looked pretty clean and round by eye, the return beam did not! Photos of outgoing and return beam attached.  Outgoing beam was 30mW, return beam 0.75mW. 

Attached is the 13.5% and D4sigma measurements, I also have photos of the 50% measurements if needed. Distances are measured from the optic where HWS and ALS beams combine, ALS-M11 in D1400241. 

We had previously removed HWS-M1B and HWS-M1C and translated HWS-M1A from whats shown in D1400241-v8 to remove clipping. 

Until we figure out these laser glitches, I've increased all of the timers in H1_MANGER and IFO_NOTIFY by 50%. This will hopefully help avoid the late night notifications that resulted in no actual interventions.

I added a laser_fudge = 1.5 to both nodes, and then multipled the defined timers in H1_MANAGER lines 149-152  and IFO_NOTIFY lines 30-35.