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

Alignment notes

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]

WP 11752 investigating issues with sending dual data streams to h1dmt1

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, ...).

The CDS view into this is facilitated through two PVs, H1:DAQ-GDS0_BCAST_RETR and H1:DAQ-GDS1_BCAST_RETR.  These PVs show the broadcast retransmit requests that h1daqgds0 and h1daqgds1 receive each second.  We get a stream of these, usually in sets of 3 (1 for each dmt machine).  When the pattern changes and/or we start receiving many more requests that is a sign that their are problems with the broadcast into the DMT.

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.

Reset OMC ASC matrices and gains to those set on 4th March

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.

Changes to ISC_LOCK Guardian for O4b Commissioning

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.

Updating OMCscan to reflect transition to OMC001

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