locking this AM

Sheila, Gabriele, Corey, Jennie, others

• Based on the alog from last night, we decided to start with an initial alingment, using the camera set points that were set yesterday based on the baffle PD alignment.  This went smoothly, and allowed us to lock to PRE_ASC_FOR_FULL_IFO several times.
• We undid some guardian changes from yesterday, we removed all DRMI ASC except MICH, and put the DHARD gain increase in DHARD_WFS back in.
• We realized that we have been loosing lock because the ALS DIFF guardian was thinking that we lost lock (when we skip shuttering ALS this checker doesn't get disabled).  I've added IDLE states to both ALS_DIFF and ALS_COMM, for now we are manually selecting these when we get past the ALS steps of the CARM offset reduction.
• After that, we are able to sit and walk alignments for longer in PREP_ASC_FOR_FULL_IFO.  We lost lock as we moved CHARD P in the negative direction which was improving the PRG, but in the last seconds of the lock POP90 was increasing.  Our next plan is to turn off MICH ASC while we walk alignment.

Summary of guardian changes that are useful to make when we are recovering from a vent, for future reference:

• bypass shuttering of ALS in CARM offset reduction by changing wieghts of connections, this allows us to reset the green references when we lock.
• Greatly extend the timer for INCREASE_FLASHES
• change connection weights to go through CHECK SDF rather than SDF revert (if this is what we want)
• we are thinking about the check for giving up on DRMI and moving to PRMI, the logic we have worked well during O4a so we are hesititant about changing it.  A workaround for if it is switching to DRMI when we don't want that is to pause ISC_LOCK and let the DRMI guardian lock DRMI.

Some guardian changes made yesterday to think about maybe reverting:

• got rid of DHARD gain reduction at DHARD WFS
• added SRC1 back to DRMI ASC
• change of ALS normaliztion to Y arm.

Restarted BRS EX Beckhoff machine

Jim W., Patrick T.

Jim asked me to restart the computer after issues with the BRS not damping. Logged in over rdesktop and restarted the OS by running 'shutdown /r'. Or maybe it was 'shutdown \r'. Logged back in as controls after restart. Beckhoff code had restarted automatically. Started the analysis code and IOC from the desktop icons. The IOC reported some errors in the database, but seems to be running alright.

Thu CP1 Fill

Thu Mar 07 10:14:07 2024 INFO: Fill completed in 14min 3secs

Gerardo confirmed a good fill curbside.

Record of Guardian Changes

ISC_LOCK.py changes since 2024-01-07

• Remove control of SQZ_MANAGER  76154
• In PREP_FOR_LOCKING added 'ezca['LSC-POW_NORM_MTRX_1_18'] = 0'  # Remove the normalization for DARM
• In ACQUIRE_DRMI_1F: Change DRMI to PRMI thresholds 76167, also PRMI to MICH was changed. And increase flashes timer increased from 2 minutes to 20 minutes
• In DARM_TO_RF:
  • Added 'ezca['LSC-POW_NORM_TRY_SQRT_ENABLE'] = 1  # added 6 Mar 2024 JCD' in (previously just for TRX)
  • Commeneted out  'ezca['LSC-POW_NORM_MTRX_1_17'] = 0.37', added 'ezca['LSC-POW_NORM_MTRX_1_18'] = 0.37 # Use TRY not TRX, 6 Mar 2024 JCD'
• Added weight to edges to not nominally go through SDF_REVERT 76154
• Changes to NEW_DARM

 

 

Overnight results of h1digivideo3 camera stability after 10GE upgrade yesterday

Jonathan, Patrick, Dave:

Around 14:00 yesterday (Wed 06mar2024) we upgraded the camera network link to h1digivideo3 from 1GE TPE to 10GE fiber. After running overnight, all of the cameras on this server are still running and, with the exception of ETMY, no further VALID=0 have been seen (2 day trend attached, upgrade at the 18h mark).

ETMY continues to have an hourly VALID=0 which flashes the camera client images blue-screen for a few seconds. This happens at roughly the 20 minute mark in the hour and it slowly advances through the hour.

The ETMY periodicity is not changed by h1digivideo3 reboots, suggesting it is in the camera itself. To test this, I power cycled the ETMY camera at 08:34 this morning.

Thurs DAY Ops Transition

TITLE: 03/07 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

Arrived with Sheila & Gabriele running an Manual Initial Alignmnent.  Randy and Eric are moving items around the site as well.  Low winds currently and a couple of earthquakes over night (5 & 7hrs ago).  No alarms or major red-ness on the CDS Overview.

Alignment Notes - Evening

Jenne, Elenna, Jennie W., Camilla, Ryan S., Austin, Matt, Gabriele, Georgia.

 

Going to offload DRMI ASC and try and offload things by hand as build-ups are decaying.

Got to Offload DRMI ASC.

Elenna changing PRM to improve build-ups. LSC-POPAIR_B_RF90_I_NORM and LSC-POPAIR_B_RF18_I_NORM.

PR2 helped.

SRM and SR2.

All of these pitch needed changing.

DHARD hit some limits at CARM offset reduction and we lost lock. First image.

DHARD YAW and DHARD PITCH rung up.

Annother lockloss (image 2) from state 309 but lockloss is reporting state number incorrectly.

We think its losing lock around DHARD WFS.

SRM yaw changed. Improves things.

Noticing some glitches on DHARD Pitch out - not sure what is causing them. Third image.

Changing CHARD alignment to improve ASC.

Lost lock. Possibly from state 305 (DHARD WFS)

PRM pitch being changed helps with build-ups (OFFLOAD DRMI ASC state).

Then stepping the guardian manually up the states making tweaks.

Tried to go from CARM offset reduction to Carm 5 picometers and LSC channels rung up at 60 Hz and we lost lock.

One of the LSC loops might have too much gain.

Elenna measuring TFs to check the loops, but DARM measurement is not giving good coherence and increasing the gain.

Power Normalisation of some loops uses IM4_TRANS_QPD and this is very mis-centred so may be adding in noise. (image 4)

Lockloss due to excitation?

Reached OFFLOAD DRMI ASC again and Elenna moving IM3.

Moved IM4 and less clipping on IM4_TRANS.

We lost lock.

DARM is normalised by X_ARM_TRANS and BRS X has been taken out of loop so Jenne changed the normalisation to be with Y-ARM in ISC_LOCK guardian.

Jenne aligning BS and we are in FIND IR.

Lost lock again.

Elenna doing went to MANUAL Initial Alignment state.

Had to undo the changes Jenne made to IM3 and IM4.

Gabriele is going to measure DARM with white noise measurement.

This shows the UGF is 15Hz instead of what we think it should be (50Hz).

Increased DARM gain by 50%.

Lockloss.

Problem comes with DHARD gain increase during DHARD WFS state (305). Georgis is commenting this out  in line 2337 and 2338 of ISC_LOCK.

Keep losing LOCK from LOCKING GReen ARMS State.

When we lose lock the power normalisation for DARM should reset to 0 but it did not and so was causing noise on the ALS DIFF input. Probably because the DOWN STATE of the guardian is not set to do it.

Elenna updated prep for locking to set this state to 0 even with using Y ARM for the power normalisation instead of X.

We fell out at CARM to TR.

Low vs High CLF -- No significant squeeze degradation observed

Camilla Naoki Daniel Georgia Nutsinee

This morning we had difficulty seeing squeezing in the HD. The problem was a combination of railing CLF ISS and alignment. We had to reduced the power sent to CLF fiber from 1.2mW back to 0.7 mW (the value prior to PMC alignment work). SHG ISS was working fine. We moved FC1, ZM5 and ZM4 (mostly FC1) and eventually saw some squeezing. OPO IR camera was a useful indication to which DOF we should move these optics. We optimized the OPO crystal temperature. NLG was 17.39. We tried squeezing at CLF launch power of 0.07, 0.1, and 0.7 mW. Common mode board gain and squeeze angle was optimized everytime the power changed. No significan't change in squeezing level observed. If we lower CLF or LO gain a coherence between HD DIFF anf LO/CLF around 1-2 kHz can be observed. I suspect this is due to vacuum pump noise on the floor. Reducing LO gain will degrade the over all squeeze level. Reducing CLF level will make acoustinc noise worse.

3-6 vent vacuum diary

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

Wednesday Shift Summary

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:                                                                                                                  

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
23:29	SAF	LASER SAFE	LVEA	-	The LVEA is LASER SAFE	03:14
16:00	FAC	Ken	High Bay	N	Lighting	??
16:09	FAC	Karen/Kim	LVEA	N	Tech clean (Kim out 1646)	17:26
17:05	VAC	Jordan	HAM 8	N	RGA prep	17:33
17:15		Hanford Fire	Site		Tumbleweed burn	??
17:47	SEI	Jim	Remote	N	Restart BRS X	??
18:25	FAC	Karen	MY	N	Technical cleaning	19:11
18:48	VAC	Travis/Janos	LVEA	N	Turbo pump water line work	20:32
19:12	ISC	Sheila/Matt/Trent	ISCT1	YEYE (LOCAL)	Beam dump installation	19:46
20:33	VAC	Gerardo, Jordan	LVEA	N	Climbing on HAM6 for turbopump	21:33
21:59	VAC	Jordan	HAM 8	N	RGA scans	23:25
22:08	VAC	Janos	HAM 7	N	Annulus ion pump work	22:20
22:46	VAC	Travis	LVEA	N	Disconnect pump cart	23:12

h1digivideo3 video network port upgrade

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.

I updated the load_mon_epics on digivideo3 to make the eno2 channel hold the traffic data from ENP1S0F0NP0 so we can keep a consistent trend of the traffic from the cameras.

Locking this evening

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.