Closes FAMIS 26441

BRS Y looks fine

BRS X was fine for majority of last month, had a hiccup a day or two ago but is now back in its nominal state. alog 76888 shows that it was touched yesterday so that may be it - tagging Seismic.

TITLE: 04/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

Winds have not been as bad as last night, but for most of the day they have hovered just below 20mph. 

Issues with Initial Alignments continue, but piecewise alignment seems to work....a little.  Have had 4 locks which made it deep into ISC Locking (1 to NLN & 3 with locklosses at Transition From ETMx); Here are the 3 locklosses:  1396196815, 1396200017, & 1396216609.  For two of these locklosses one similarity is an Analog board saturation for IMC REFL SERVO SPLITMON.

LOG:

• 1459-1516 Optics lab cleaning (karen)
• 1516 Reverting H1to alignment before the last lock just after Oli's shift at 0733utc/gps-1396164799---this will be a RESTORE to all SUS -except- squeezer.
  • We've been relegated to alignment reversions lately.
• 1523 Alignment #1:   Going for a Manual Alignment to slowly go through each alignment state
  • 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 alignment (this was in the INITIAL_ALIGNMENT state 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 etm_tms_wfs_offloaded & it word. 
    • 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
• 1618 MY cleaning (karen)
• Lock#1:  Preemptively selected PRMI  
  • 1625 lockloss at Transition From ETMx
• Lock#2:
  • 1631 lockloss at FIND IR
  • stopped logging locklosses, since we had several at Locking ALS & FIND IR.  will say it was frustrating to see how long it took FIND IR to get the maximum for the Y-arm (it was close for over a minute, but then we had a lockloss).
• 1627 MX cleaning (kim)
• 1641-1700 MX parts check (chris)
• 1656 BRSx brought back into loop (jim)
• Lock#?:  Made it all the way to Transition from ETMx for another lockloss at this state at 1719 (lockloss was just after step when ADS lines appear).
• Next Lock:  For Check IR, ALS COMM (xarm was fine as usual....but since it takes so long for ALS DIFF to FIND IR, noticed that the Xarm transimission started to drop....down to 0.6.)  :(
• 1728-1818 Pcal lab work (francisco)
• 1805 Back to Nominal Low Noise!
  • This was after (2) locklosses at Transition to ETMx.
  • No changes were made--sort of.....
  • BRSx was brought back into loop, but I think Jim said this happened a few minutes before the previous lockloss at Transition to ETMx (so not necessarily a smoking gun).  Basically, Louis, Sheila, Maggie, and I were all watching H1 at Transition to ETMx & we made it through!
• 2027-2049 TCS chillers FAMIS check (corey)
• 2051 Lockloss (squeezers were commissioning, but they mentioned SQZ rarely causes locklosses.  There were winds approaching 20mph.)
• LOCKING Notes:
  • Several locklosses at LOCKING ALS where the green X-arm was driven off in alignment.  Flashes for xarm were near (but under 1.0).  So I ended up getting flashes above 1.0, but xarm still driven off.  So, ran a Manual Alignment of just Green Arms & this finally did the trick.....BUT DRMI & PRMI looked dead.  And while transitioning to CHECK MICH FRINGES, there was a lockloss.  
  • Strangely after the Check Mich Fringes lockloss, (1) the IMC could not locked and (2) Power was stuck at 10W.  Running ISC LOCK downscript appeared to clear things up.  
  • Finally ran CHECK Mich Fringes.  PRMI flashes were off in yaw, so PRM was tweaked and then locked, and continued tweaking PRM before ASC kicked in.  DRMI flashes were a little low and was out in yaw, so tweaked SRM in yaw to help DRMI lock in a minute.
  • 2156 Lockloss at today's "usual" Transition From ETMx.
  • ALSy went through Increase Flashes, but it wasn't improved better than one can do by hand.
• Made it through TRANSITION FROM ETMX!  (so that makes it twice for the day and 3 locklosses at this state today).  Handing off to Oli for the eve!

TITLE: 04/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 22mph Gusts, 16mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:

Just got into OMC_WHITENING

My first time running this new TCS FAMIS check.  Camilla happened to be nearby and she mentioned that the plot looks good and no notes/comments needed, but screenshot of the plots are attached.

Naoki, Eric, Camilla

We tried the PSAMS coarse scan from 0 to 200 with 100 step for two PSAMS. So 9 PSAMS setting in total. The nominal PSAMS is 100/100 and we tried 0/0. Unfortunately, when we tried 100/0, the lockloss happened. For each PSAMS setting, we ran the SCAN_ALIGNMENT with asqz-optimized and took 5+5 minutes quiet sqz/asqz data. The attachment shows the result. The 0/0 has much worse anti squeezing and large frequency dependence compared to 100/100. However, we are not sure if the mode matching is really worse or alignment is bad with 0/0 although we ran SCAN_ALIGNMENT. We will try to compensate the ZM alignment change caused by PSAMS change tomorrow.

no sqz (10 min)

PDT: 2024-04-03 11:40:00 PDT
UTC: 2024-04-03 18:40:00 UTC
GPS: 1396204818

asqz with 100/100 (5 min)

PDT: 2024-04-03 12:25:07 PDT
UTC: 2024-04-03 19:25:07 UTC
GPS: 1396207525

sqz with 100/100 (5 min)

PDT: 2024-04-03 12:34:10 PDT
UTC: 2024-04-03 19:34:10 UTC
GPS: 1396208068

asqz with 0/0 (5 min)

PDT: 2024-04-03 13:13:17 PDT
UTC: 2024-04-03 20:13:17 UTC
GPS: 1396210415

sqz with 0/0 (5 min)

PDT: 2024-04-03 13:33:50 PDT
UTC: 2024-04-03 20:33:50 UTC
GPS: 1396211648

Addressed TCS Chillers (Tues [April 3] 1327-1349pm local) & CLOSED FAMIS #27786:

• TCSx Chiller:  Had level of 29.7 cm.  Added 100mL for 30.2cm.
• TCSy Chiller:  Had level of 10.5 cm.  Added 0mL.  Curious how the level increased 0.5cm from the 10.0cm it has been at since early Feb.
• There was no water in the small cup under the slow leak.

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