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.

Patrick, Jonathan, Erik, Dave:

We are working on an issue with some cameras on the new video server (h1digivideo3) becoming unstable over the past few weeks, resulting in their images going blue-screen until their server process is restarted.

I've opened FRS30615 for this issue.

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
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 1mph Gusts, 0mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.16 μm/s
QUICK SUMMARY:

H1 still struggling with locking post vent. Troubleshooting continues, starting off the morning with an initial alignment.

Naoki, Daniel, Nutsinee

The newly installed squeezer (iLIGO) PMC took a while to lock so we investigated. Turned out the PMC had difficulty locking when the PZT was scanning from 0-100V but was able to lock reliably when the PZT turned around from 100-0V. We maybe seeing something we've seen before in the OPO where some element inside of the PMC heated up, expanded the cavity length against the PZT movement from 0-100V making it difficult to grab a lock. We triggered the PMC lock on the Refl diode and the channel we used has 2kHz sampling rate. Beckhoff trigger is running at 1kHz. The resonance passed by so quickly that sometimes if we're lucky the trigger would work but most of the time it didn't.

However, when scanning from 100-0V the cavity expansion help extended the period that light stored inside the cavity, making it easier to grab lock. Now that the PMC is better aligned, the effect became more severe.

The scan shows PMC refl and trans having a much narrower dip/peak when scaning from 0-100V compared to 100-0V.

We revert the scan from 0-100V to 100-0V so it starts from the top. Changes related to PMC scan has been accepted in the SDF.

In case of the OPO the cavity self-lock due to heating within the crystal. In case of PMC we have about ~100mW of light missing that can't be accounted for. We believe this amount of light maybe absorbed somewhere inside of the PMC. 

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.

We lost dmt displays in the control room around 12:16 today.  John Zweizig and I have been working on this for the past few hours.

What seems to have happened is after a reboot h1dmt1 is having problems with redundant data streams (for reference the identically configured h1dmt2 has no issue).  When we disable one of the input streams it is able to receive data.  At this point we have disabled one of the streams and will look at it more in the morning.

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.