The pressures:
HAM7: ~2.9E-7 Torr
HAM8: ~3.3E-7 Torr
Corner: ~4.9E-8 Torr
EX: ~5.4E-9 Torr

Today's activities:
- The X-manifold turbo-station water lines have been updated - now the controller and pump lines are separated

- HAM8 RGA scan is done, details in the comments
- HAM8 IP was valved in
- HAM7 Annulus Ion Pump has railed; it is caused supposedly by a leaky plug on the septum plate, or just the AIP controller - either way, it will be found out soon
- Relay tube - HAM7 - HAM8 further schedule: This volume will be valved in to the main volume around the end of the week - RV1; FCV1; FCV2; FCV3; FCV4; FCV8; FCV9 will be opened; preferably after the HAM7 AIP issue is solved

TITLE: 03/06 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: None
SHIFT SUMMARY:

Locking troubleshooting continues. The commissioning team was able to get to PREP ASC before losing lock, so good progess is being made. Alog on today's locking extravaganza here.

Last shift from me, peace out yall :)
LOG:                                                                                                                  

Elenna, Sheila, Gabriele, Jennie W et al.

• ran the TMS and ITM baffle alignment again, and reset the green camera offsets for the position we found in this way (see SDF screenshot)
• ran a full initial alignment and were able to lock PRMI and DRMI
• disabled DRMI ASC except for MICH
• disabled shuttering of ALS beam and SDF revert
• made it to PREP_ASC_FOR_FULL_IFO, lost lock due to 0.45 Hz instability in DARM.
• There was a lot of graound motion due to fire trucks and Jim took BRSX out of loop.
• Chnaged the order of offsets in ALS DIFF guardian to speed up FINDIR - this worked.
• The POPAIR checker goes to PRMI when it shouldn't.
• Lost lock at CARM OFFSET 5 pico m. REFL was 0.5 of unlocked power when locked, ARM TRANS was 800 x single arm which from plots linked implies PRG in mid-40s - good enough for locking.

NB:   LHO alog 62110 shows PRG gain plots.

[Jennie W took this log over from Gabriele]

We had issues yesterday with h1dmt1 receiving both gds broadcast streams.  Last night John Zweizig and I left it working with only one stream active.

Today John and I did two tests.

1. We switched which ethernet port was deactivated. During this test we still saw issues with retransmits during periods with both broadcasts being received.  When we disabled the other port that receives the broadcasts things settled down.

2. We rebooted the machine to see if there was some state that was bad and just needed a reboot.  This seems to have done the trick.  Presently we do not know what exactly was cleared up.  We checked the network settings (including buffer sizes, tweaks, ...), software package versions, physical links, ... between h1dmt1 and h1dmt2 and could not find a difference that would explain this behavior.

h1dmt1 is running, and the control room should have access to all the DMT products that are needed (range, darm, ...).

WP11753

Jonathan, Dave:

As part of the investigation into recent camera image instabilities we upgraded h1digivideo3's 106 VLAN network port from 1GE copper to 10GE fiber.  A solar flare PCIe card was installed in h1digivideo3 at 14:05 this afternoon.

The new fiber is connected to a spare 10GE port on sw-msr-h1aux (ethernet 3/1/2).

On h1digivideo3 we have left the original copper connection to eno2, the new fiber port is enp1s0f0np0.

Currently the EPICS_LOAD_MON channel being trended by the DAQ is still H1:CDS-MONITOR_H1DIGIVIDEO3_NET_RX_ENO2_MBIT, the new channel is H1:CDS-MONITOR_H1DIGIVIDEO3_NET_RX_ENP1S0F0NP0_MBIT, which Jonathan is working on remapping to ENO2 so we don't need a DAQ restart.

As we went through SDF revert yesterday when locking all the OMC SDFs were reset. I turned off the QPD A offsets and reset the input and output ASC matrices to those we had found allowed us to lock the OMC with ASC and no saturation of the OMC suspension.

First picture is the reference picture from yesterday before the revert. I have not set back the changes to DCPD offsets as I think these were to make sure DCPD SUM output did not dip to a negative number due to dark noise.

Second picture is the OMC model SDFs now.

The guardian has been set to not go through SDF revert when we lose lock however the guardian has the ASC gains hard-coded in so we may want to replace these with the new values in the OMC guardian once we verufy these are correct by manually locking the OMC once the full IFO is locked.

As we aligned into the OMC before locking efforts started and we think this was a good OMC alignment I accepted these alignment slider values for OM1,2,3 and OMC in SDF, picture attached.

Locking woes continue. We reran the baffle align scripts for all 4 quads this morning and after a few touch ups, ALS now seems to be in a good spot. Commissioners are now trying to get through DRMI locking as flashes on our pop signals are not great. A more detailed alog to follow.

Per commissioner request, I've made two changes to the early main locking steps as set in ISC_LOCK:

1. By default, ISC_LOCK now goes through CHECK_SDF rather than SDF_REVERT so settings are preserved lock to lock
2. The timer for moving the ALS arm nodes to INCREASE_FLASHES during LOCKING_ARMS_GREEN has been increased from 2 minutes to 20

Changes have been loaded and committed to svn.

Wed Mar 06 10:14:59 2024 INFO: Fill completed in 14min 55secs

Previously done 75898 - closes FAMIS#27784

Both TCSX and TCSY were at their max fill level, so I did not add any water. There was no leaking.

Elenna, Jenne, Gabriele, Matt, Trent, Louis, Georgia

- Jenne and I checked the fast shutter and ran the fast_shutter test (SYS -> AS port protection -> run)

- After the initial alignment (alog here) we got through green arms locking at up to CHECK_MICH_FRINGES. When we tried to do PRMI there was a timer that kept taking it back to MICH fringes since the POP90 buildups were so poor. On the AS_AIR camera the alignment looks bad in yaw.

- We edited ISC_LOCK line 1353 to lower the threshold for PRMI flashes on POPAIR_B_RF90 from 20 to 4.

- We ran the dark offsets script with the IMC offline and the ALS shuttered (sdf screenshots here), and started locking again.

- The Y arm was finicky, we struggled to get the flashes above 0.6... We lowered the PD threshold in the ALS Y PDH (H1:ALS-Y_REFL_LOCK_TRANSPDNORMTHRESH) from 0.7 to 0.6.

- We also lowered the threshold in ALS_ARM gen_INCREASE_FLASHES from 0.9 to 0.6.... feels like cheating, maybe the alignment onto ISCT1 is off? The camera alignment for ALS_Y also looks bad (see screenshot)

- Even though we did an initial alignment earlier today, the PRMI flashes are bad and the MICH fringes don't look great. PRMI_ASC caused a couple of locklosses, so we took the guardian to PRMI_LOCKED and tried aligning it by hand. Elenna aligned PRM and BS, but the buildups and camera indicated bad pitch alignment.

- We re-ran initial alignment, and then the guardian took us straight up to PRMI_ASC, DRMI also locked easily! POPAIR_RF18 was a little noisy.

- We started the CARM offset reduction sequence but lost lock at DHARD_WFS, the two arms were very different (higher build up for Y arm), when DHARD came on the arms were pulled closer together but we lost RF9, and we lost lock.

- We decided to stop at DARM_TO_RF, step the X arm (X hard) closer using the move_arm_dev script and fix PRM and SRM alignment to increase the buildups.

- While we stepped the arm and adjusted PRM, the green arms lost lock. We think we might be aligning the whole IFO to some bad ITM alignments (how accurately aligned are they after the baffle PD alignment script?)

We decided to call it a night at this point.

Matthew, Jennie W, Gabriele

In the initialization of the OMCscan code (which gets OMC scan data, analyzes it and then plots it), I updated several values to reflect the transition from OMC003 to OMC001, so that omc analyses are accurately done. For example, several small changes include:

• FSR -> 264.97 MHz
• Finesse --> 426.96
• TMSv --> 58.05 MHz
• TMSh --> 57.94 MHz
• PZT2response --> 6.435 MHz/V (this change is from 5.9 MHz/V, which is puzzling because the previous PZT2response [12.73 nm/V] is quite close to the new one [12.92 nm/V])

The values were obtained from T1500060 Table 19, which report the OMC optical test results for OMC001; note: the conversion from nm/V to MHz/V is found by the relation delta(f)/f = delta(L)/L, where delta(L) is 2*PZTresponse in nm/V, L is the round-trip cavity length, and f is 1064nm converted to MHz

I made a LOCK_PMC state in SQZ_MANAGER guardian. The LOCK_PMC state is between LOCK_TTFSS and LOCK_SHG states. The LOCK_PMC state is copied from LOCK_SHG state, but I commented out the PZT checker because the PMC_PZT_OK function is not defined now.