J. Kissel, G. Vajente
ECR E2400116
IIET 30863
WP 11797

After yesterday's infrastructure changes to the H1 SUS OMC front-end model (LHO:76856 and LHO:76894), which moved the OMC ASC control signals
    - from going 
        . straight from the OMC ASC 2k model 
        . through the SUS-OMC_M1_ASC filter bank for plant compensation, and 
        . then out to EUL2OSEM matrix for basis transformation to the DAC 
    - to going 
        . from the OMC ASC 2k model
        . through the SUS-OMC_M2_ISCINF filter bank (for proper 2k to 16 kHz anti-imaging), 
        . through the SUS-OMC_M1_LOCK filter bank (for the same filtering that was done by the former M1_ASC bank),  
        . through the the SUS-OMC_M1_DRIVEALIGN matrix (though configured at the moment to no do any off-diagonal decoupling), and 
        . *then* out to EUL2OSEM matrix for basis transformation to the DAC

there was some worried that the excess noise between 10 and 100 Hz might be this infrastructure change.

It's not, as far as we can tell, responsible for and change in the noise in DARM.
In LHO:76928, Gabriele posted an ASD of the SUS-OMC_M1_MASTER_OUT_DQ channels to confirm that the drive to the OMC SUS's DAC is the same (the thought being that if the DAC request is drastically different, then we should be suspicious of the infrastructure change).

Here, in the attached ASD I show a different perspective -- the input to the former M1_ASC bank compared with the current M1_LOCK bank in pitch and yaw, and then showing those channels' coherence with DARM.
I compare 25 averages (0.02 Hz frequency resolution, 50% overlap) two times, 
    RED 2024-04-02 6:00 UTC Pre-change (in the middle of a good overnight lock stretch; 2024-04-01 23:00 PDT)
    BLUE 2024-04-03 18:05 UTC Post-change (in the middle of a good lock stretch this afternoon, though in the middle of SQZ tuning of ZM alignment)

This ASD also focuses on where the control signal is real signal (from the very slow loop design -- see LHO:65861).

While the character of the ASD control signal and coherence with DARM has changed around the (presumably OMC SUS) resonances, this perspective corroborates that we don't see substantial change. *Maybe* the change in character around the resonances changed because I misinterpreted the former infrastructure, and somehow we *were* using the confused DRIVEALIGN gain values from LHO:47488, but I think not.

Notes from locking this morning (with Alignment woes and Transition from ETMx locklooses)

After spending 3hrs trying to get through an alignment yesterday afternoon, and since H1 was having issues after this morning's lockloss and multiple Initial Alignment cycles (and also after talking with TJ [owl shifter]), decided to REVERT all suspensions (except squeezer) to a time before last night's lock. 

Chose time when ISC LOCK was in the Alignment state (#11) and picked a time within a minute of the end of when it was in this state.  (Still not sure if that is the best way to pick a time, because how would one know if ALL sus were in an "aligned" state.)  So---I reverted to the following time:

• 0733utc/gps-1396164799

Alignment #1:   Going for a Manual Alignment to slowly go through each alignment state since some states are broke.

• als:  ALSy was a first failure (and even after I touched up its alignment to flashes near 1.0 before aligning!)---as WFS drove off the y-arm alignment (this was the INITIAL_ALIGNMENT state selected for als_yarm).  So for the next one one, I worked on optimizing alignment for flashes a little above 1.0 and this time I selected the etm_tms_wfs_offloaded  state & it worked fine. 
  • Eventually SUCCESS
• Input Align:  had red-x-arm flashes of 1.0, but twice in a row it knocked out the IMC (this is different from TJ who said he had no issues).  so i am SKIPPING!
  • FAILURE
• prc_ALIGN:  SUCCESS
• mich_bright:  SUCCESS
• src_align:  SUCCESS

Lock#1:  Selected PRMI (locked within 15sec), but had a lockloss at Transition From ETMx.

Then there were several early-state locklosses.

Had another Transition From ETMx lockloss at 1719utc (note:  during this lock and before the lockloss, Jim brought the BRSx back in-loop (at 1656utc)---we hadn't been using it for the last day or so.).

Finally, H1 made it to NLN at 1805utc.

We got some no squeeze quiet time almost an hour into lock this morning and our low frequency noise looks worse than yesterday - so impacting our range.

Sensor correction is on (confirmed by Corey).

Not sure what has changed.

Template is saved as /ligo/home/jennifer.wright/Documents/Noise_DARM/20240403_DARM_comp_sqz_no_sqz2.xml
I compared this with NO SQZ quiet times from yesterday, 17th March, and December 2023 during O4a. These other times were all after thermlisation.

Wed Apr 03 10:07:57 2024 INFO: Fill completed in 7min 53secs

Jordan confirmed a good fill curbside.

Naoki, Eric, Camilla

Before PSAMS scan, we checked the NLG. We followed the instruction in 76542. The OPO temperature seems already optimal. The measured NLG is 0.169/0.00994 = 17, which is consistent with previous measurement in 76540.

cds-crtools was updated to version 4.11 in the CDS conda environment.

The major changes are:

• A bug fix in awggui that could cause a glitch in an exciation when loading a file.
• foton no longer warns by default when a filter has a zero in the right-hand plane.  The warning can be turned on with a command line argument '-Z t', or an environment variable FOTON_WARN_RHP_ZEROS=true.
• The criterion for detecting a zero in the right-hand plane has been relaxed. Zeros that are ostensibly on the imaginary axis, but due to precision issues are slightly in the right-hand plane will no longer be flagged.

A complete change history for all crtools can be found here:

https://git.ligo.org/cds/software/dtt/-/wikis/ChangeHistory

WP11743 SUS DACKILL removal and WD consolidation

Jeff, Oli, Dave

New models were install for h1susim, h1sushtts, h1sussqzin, h1sussqzout, h1susifoout. No SEI model changes were needed, IOP models were not restarted so no SWWD bypass was necessary. DAQ restart was required.

Beckhoff OPLEV upgrade

Fernando, Daniel, Dave:

New OPLEV code was installed on the Beckhoff slow controls, resulting in additional 20 slow channels to H1EPICS_ECATAUX[CS,EX,EY]. EDC+DAQ restart was required.

PSL Neolase Beckhoff code change

Patrick, Ryan S, Dave:

The PSL Diode room Beckhoff code was modified, resulting in one additional channel (H1:PSL-LASER_PDWD) in H1EPICS_PSLNEOLASE.ini. EDC+DAQ restart was required.

DAQ Restarts

Jeff, Dave:

The DAQ was restarted twice. The first around 09:30 immediately after the SUS model changes, and then a second time with an EDC restart around 11:30 to support the Beckhoff changes.

GDS Broadcast List Change:

The h1susifoout change resulted in the removal of 6 fast channels (256Hz) from the frame, of which 2 were being sent DMT via the GDS broadcaster. ECR2400116 was created and approved to cover this removal.

--: fast channel H1:SUS-OMC_M1_ASC_L_IN1_DQ removed from the DAQ 
-!: fast channel H1:SUS-OMC_M1_ASC_P_IN1_DQ removed from the DAQ  ***GDS-CHAN***
--: fast channel H1:SUS-OMC_M1_ASC_R_IN1_DQ removed from the DAQ 
--: fast channel H1:SUS-OMC_M1_ASC_T_IN1_DQ removed from the DAQ 
--: fast channel H1:SUS-OMC_M1_ASC_V_IN1_DQ removed from the DAQ 
-!: fast channel H1:SUS-OMC_M1_ASC_Y_IN1_DQ removed from the DAQ  ***GDS-CHAN***
 

To expediate the broadcast list change, I hand editied the gds_broadcast.ini file on h1daqgds[0,1]. This needs to be made permanent in puppet.

Three fast channels were added to the frame:

++: fast channel H1:SUS-OMC_M1_LOCK_L_IN1_DQ added to the DAQ
++: fast channel H1:SUS-OMC_M1_LOCK_P_IN1_DQ added to the DAQ
++: fast channel H1:SUS-OMC_M1_LOCK_Y_IN1_DQ added to the DAQ
 

Yesterday 4-2-2024 the HVAC pre-filters at each of the 4 out station buildings along the arms were replaced with new pre-filters. The new pre filters are the same size (24"x24"x2") and filtration level (MERV-13) as the old pre-filters that were taken out. 
During inspection of the pre-filters an inspection was done on the "Main Filter Cartridge" which is the harder, more permanent, deeper, and heavier duty material type cartridge. It's installed in front of the pre-filter that is used for air filtration in the HVAC system. These are nearing the end of their life cycle. These will likely be replaced in the coming couple months.

Alerted around 645 PT about initial alignment not completing. I found it with MICH not locking, but flashes seemed a bit off. I tried realigning via the camera and trying to maximize the flashes in AS_A. Even after getting a good spot on camera and having good flashes, it would diverge when tring to lock. MICH dark was the same. I tried to skip this state but SR2 alignment wouldn't even lock, and trying it by hand seemed that there was something very off.

Richard had told me that he set a node to INIT around 630PT, trending back it looked like in Input_Align. We've been having issues with this state recently, I guess that makes sense. I then tried this state and it locked without issue. I then tried PRC, no issues. Back to MICH, same issues as before. Tried skipping it with a well aligned spot on camera, and ran into the same issues with SR2 alignment.

I'm handing off to Corey with the suggestion to restore alignment to the last alignment Oli did and then trying an alignment since I was able to lock with this earlier.

TITLE: 04/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY:

H1 lost lock about 3.5hrs ago (1238utc), and TJ (owl shift-er) has been trying to help H1 with an alignment, BUT the Initial Alignment woes continue.  Strangely, Input Align appeared to work for him, but every other (atleast MichBright and SRC) were not completing for him. 

Will try an overall alignment revert to the alignment Oli/TJ had last night.  And from that will run an alignment to see if Initial Alignment steps still have issues.  (if they do, I'll skip the alignment and try locking with the reverted alignment.

Enviornmentally all is quiet after the windy and shaky night.

Oli handed off the IFO with the wind keeping ALS from locking, but they made it through an initial alignment earlier. Once the wind calmed down a bit ~30min later, it was able to keep ALS locked and then went right up without intervention. 

TITLE: 04/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Relocking from when I showed up went quickly, but after the earthquake knocked us out it's been impossible to lock due to the ground motion and the rising high winds :(
LOG:

23:30 Reached NOMINAL_LOW_NOISE    
23:41 Observing

00:11 Lockloss due to large earthquake from Taiwan (76897), holding in IDLE

Relocking
04:45 Untripped all watchdogs, attempting to lock green arms before starting an inital alignment
    - Green arms are super wiggly still from the earthquake/wind/both but I finally got them both
05:18 Started MANUAL_INITIAL_ALIGNMENT
    05:24 Skipped INPUT_ALIGN_OFFLOADED due to same issues everyone else has had recently (76870, 76843)
        - I couldn't even get it to ACQUIRE_XARM_IR
05:41 Initial alignment complete, relocking
    - Having trouble locking ALSY due to high wind at EY - you can see the spot swinging on camera :(. Flashes look great though!
05:56 Going to sit in DOWN for 10 mins and rest the quads - wind just broke past 40mph
06:02 Tried to take advantage of a slight drop in wind speeds, but didn't work
06:16 Went back to sitting in DOWN
06:33 Trying locking again
06:35 Lockloss during LOCKING_ALS
06:48 Back to DOWN after multiple locklosses during LOCKING_ARMS_GREEN and LOCKING_ALS                                                                                                                                                                                                                                                                                                                                                                                                         

Ran the data for the In Lock SUS Charge Measurements that ran this morning. Like Camilla said (76895), the excitations only worked for the ETMs, so although I am attaching all four plots, note that the last plot point for the ITMs is March 13th (ETMX, ETMY, ITMX, ITMY).

We've been sitting in IDLE since the earthquake rolled through three hours ago. Ground motion is still too high to lock.

Functionality tests were performed on the LVEA turbo stations. The details:

X-manifold:
Bearings: 100%
Turbo hours: 1950
Scroll hours: 1946
The recently installed separated water lines were also tested and found water-tight.

Y-manifold:
Bearings: 100%
Turbo hours: 951
Scroll hours: 2279

OMC:
Bearings: 100%
Turbo hours: 5964
Scroll hours: 5903

Lockloss at 04/03 00:11UTC from Taiwanese earthquake that Jamie experienced in person