J. Kissel 

During today's Systems Call, it came up that there was scant documentation on the timing performance of the existing fast shutter system. A quick look through the aLOG showed some results from the 2016 era including examples like LHO aLOGs 29062, 28958, and 26263. Koji's LHO:29062 is probably the most conclusive, quoting (repeated here for convenience): "The fast mechanical shutter start blocking the beam at 1.7ms, reaches half blocking at 1.85ms, complete block at 2.0ms."

Here, I take some modern data with what digital signals stored in the frames:
    [65 kHz]  H1:OMC-PI_DCPD_64KHZ_AHF_DQ                OMC DCPDs (down stream of the OMC Cavity)
    [4096 Hz] H1:ISI-HAM6_BLND_GS13Z_DQ                  Vertical GS13s on the HAM6 ISI (nominally calibrated into 1 nm/s, but I've scaled it to arbitrarily show up demonstratively on the OMC DCPD plot)    
    [2048 Hz] H1:ASC-OMC_A_NSUM_OUT_DQ                   OMC QPD A SUM (up-stream of the OMC Cavity, but still down-stream from the fast shutter)
    [2048 Hz] H1:ASC-OMC_B_NSUM_OUT_DQ                   OMC QPD B SUM (""")
    [2048 Hz] H1:ASC-AS_C_NSUM_OUT_DQ                    AS_C QPD SUM (up-stream of the fast shutter)
    [16 Hz]   H1:SYS-MOTION_C_FASTSHUTTER_A_STATE        Slow-channel record of the logical state of the shutter
    [16 Hz]   H1:YSY-MOTION_C_SHUTTER_G_TRIGGER_VOLTS    Slow-channel record of the trigger PD voltage (which is AS_C)

With these channels, I show three recent lock-losses. 

It seems like all of the photo-diode signals show a very long "turn off time," (of order ~1 [sec]) and are pretty un-reliable at precision estimates of shutter timing. This is likely a linear combination of 
   - For the OMC DCPDs at least, there's an *additional* hardware "shutter" where the cavity's length actuator -- the OMC PZT -- are quickly railed to unlock the cavity after a lock-loss trigger,
   - For the OMC DCPDs at least, there's a non-negligible cavity ring-down time,
   - For OMC DCPDs and all the QPDs, impulse response of the photo-diode's readout electronics and anti-aliasing filters, and/or the  

However, the "clunk" of the shutter on the HAM6-ISI is quite obvious and precise, so I use the start of the impulse (a few samples after the transition from "no motion" to "large fast negative start of the clunk's ring-down") that as an upper-bound estimate of when the shutter is completely closed. But, with the imprecision of the [16 Hz] channels -- 62 ms -- it's tough to get anywhere.

In short -- what's stored in the frames are a pretty bad metrics for precision timing of the fast shutter system. 

But anyways -- the upper limit of the time between the change of the logical state of the trigger and the HAM6 ISI GS13s registering a large kick is 
    - 08:23:20 UTC :: 0.3125 (+/-0.0625) and 0.341064 (+/-0.000244) = 0.02856 [sec] = 28.5 [ms].
    - 13:01:26 UTC :: 0.125 and 0.1604 = 0.0354 [sec] = 35.4 [msec]
    - 23:39:28 UTC :: 0.3125 and 0.328857 = 0.016357 [sec] = 16.4 [msec]

I'll keep looking for better ways to increase the precision on this statement, but for now, we should still role with Koji's results from LHO:29062

During yesterday's (4/16) maintenance period, a Norco tech came to the site to inspect the 8 LN2 dewars that feed the cryopumps. Inspection report will be posted to Q2000008 once received.

The vacuum jacket pressures were also measured during inspection:

Sheila, Naoki, Vicky, Camilla

As we continue to see the nominal SQZ angle change lock-to-lock (attached BLRMs). We edited SQZ_MANAGER to scan sqz angle (takes 120s) every time the SQZ locks, i.e. every time we go into NLN.

In  SQZ_MANAGER we have:

• Added a state FC_WAIT_FDS after SQZ ASC, which asks the FC to lock and waits up to 5 minutes (this used to be done in nominal state FDS). 
• Changed the next nominal state to SCAN_SQZANG (120s scan to get best squeezing at 350Hz BLRMs, may still need improvements).
  • This can be bypassed if we don't like this addition be removing the weighting from '('FC_WAIT_FDS', 'FREQ_DEP_SQZ', 3)'
• I added an LO_checker_FDS() to FC_WAIT_FDS  and FDS to come back to FDS_READY_IFO if the LO unlocks to avoid copy-pasting code everywhere.
• SCAN_SQZANG still has paths to/from FDS so we can still request it whenever.
• Old and new graphs attached. svn commit 27520.

We tested this taking SQZ_MANAGER down and back up, it went though SCAN_SQZANG as expected and improved the SQZ by 1dB, range improved by ~10MPc.

We'll want to monitor that the change as SCAN_SQZANG may not give us the best angle at the start of the lock when SQZ is very variable. We expect this won't delay us going into observing as only added 120s and ISC_LOCK is often still waiting for ADS to converge during  this time.

Ran a broadband and simulines calibration sweep at 15:30 UTC and successfully finished at 16:01 UTC.

Now going into planned Wednesday comissioning.

Start:

PDT: 2024-04-17 08:39:27.631946 PDT

UTC: 2024-04-17 15:39:27.631946 UTC

GPS: 1397403585.631946

End:

PDT: 2024-04-17 09:00:59.127599 PDT

UTC: 2024-04-17 16:00:59.127599 UTC

GPS: 1397404877.127599

2024-04-17 16:00:59,060 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,066 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,071 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,075 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,079 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240417T153928Z.hdf5

ICE default IO error handler doing an exit(), pid = 685800, errno = 32

TITLE: 04/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 11mph Gusts, 7mph 5min avg
    Primary useism: 0.30 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING

TITLE: 04/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: The wind was really bad during my shift and caused the time between the 23:39 LL and NOMINAL_LOW_NOISE to be 3.75 hours. We had a second lockloss at 06:44UTC and just finished an initial alignment.
LOG:

23:00 Detector in NOMINAL_LOW_NOISE and troubleshooting going on wrt sqz

23:34 Into Observing

23:39 Lockloss

- Relocking -
23:57 Lockloss from AQUIRE_PRMI
23:59 Lockloss from LOCKING_ALS
00:00 Started Inital Alignment

00:20 DIAG_MAIN message that ALSY polarization is above 20%
    - I using Camilla's instructions(58773) to find the right screen, and went to follow the instructions there, but all I did was press ON and then press Restore like it said, but just by clicking those the ALSY polarization value went down to 7% and ALSX up to 12%, so without needing to adjust anything I pressed OFF.

00:22 Initial Alignment completed
00:40 Lockloss from ACQUIRE_DRMI_1F
00:43 Lockloss from FIND_IR
00:48 Lockloss from LOCKING_ALS
00:51 Lockloss from FIND_IR
    - Sitting in DOWN for a bit
01:00 Trying relocking again
01:07 Lockloss from ACQUIRE_DRMI_1F
01:10 Lockloss from LOCKING_ALS
    - Sitting in DOWN for a bit again
02:00 Trying to relock again again
    - Wind still > 30mph
02:14 Started another Initial Alignment
    - Went through CHECK_MICH_FRINGES and then ifo wanted to do CHECK_MICH_FRINGES again
02:40 Initial Alignment done
- Done relocking -

03:23 NOMINAL_LOW_NOISE
03:26 Observing

06:22 Lockloss

- Relocking -
06:44 I took us to initial alignment because we couldn't get past ACQUIRE_PRMI
07:00 Initial alignment done

Lockloss 04/17 06:22 for unknown reasons

After three hours of not being able to get past ACQUIRE_DRMI due to the high wind, we finally are making it up and are currently at MAX_POWER.

Closes FAMIS#26292, last checked 77145

Corner Station Fans (attachment1)
All fans are looking normal and within range.

Outbuilding Fans (attachment2)
MX_FAN1_370_1 is still jumping in noise like it's been doing for the last few weeks. These jumps in noise are still well within range. 
All other fans are looking normal and are within range.

Lockloss 04/16 23:39UTC - IX saturation at lockloss

The HASH_INT channel was updated at 16:00 and its new value was accepted into CDS SDF. These two channels were removed from h1calcs SDF by hand editing the snap file.

As a test that the cal_hash_ioc restores it values on startup, we restarted it at 16:30. CDS SDF didn't notice it had gone, the EDC connected channel counter dropped by 5 for about 15 seconds.

Shiela, Naoki, Rahul, Kar Meng, Terry

Same as yesterday (77188), we are again today having trouble locking the FC. Wind is again constant at 0-20mph. Can get green flashes but no locking, even with FC feedback turned off, VCO locking also fails. 

Rahul changed the M1 coil driver state on FC1 and FC2 from state 1 (usually only used in TFs) to state 2: IFO nominal for other triples. State 2 contains a low pass filter. 

Rahul took FC2 P and L transfer functions, look healthy and same as 66414.

Rahul took FC2 OSEMINF spectrums and checked ther health, as previously had issues with FC1 BOSEMS  (72563). Can see the 0.3 to 0.4Hz peak, Rahul's not worried about it but we could check old data for this peak.

Lately it's been very difficult to fit an efficient SRCL feedforward filter, as reported many times by Camilla et al. (76993). Here I'm trying to figure out why. Spoiler alert: I don't have an answer yet.

The main problem with the SRCL FF filter (see first plot), is that the transfer function to fit has a large phase rotation, that looks basically like a phase advance (the opposite of a delay) of about 2 ms. This is very large, and being an advance, it can't be realized in a precise and simple wasy digitally.

First observation: we can fit a pretty good SRCL FF if we allow for unstable poles, i.e. poles with positive real parts (see second plot) Of course this is not something that can be implemented in the real time system. The fit ends up having a unstable complex pole at about 420 Hz and about 5 Hz. I have no intepretation for the origin of those poles, and they might very well be only a way to reproduce a phase advance (think of the Padé approximation for phase delays).

So the question is: what is the origin of this large phase rotation? It's not seen at LLO, for example see 70548

Second observation: this phase advance appeared after we switched the LSC FF from ETMX (full chain) to ETMY PUM. The third plot compares the MICH and SRCL feedforward to be fit in two cases: an old measurement when the FF was going to ETMX, and a more recent measurement with the FF going to ETMY PUM only. For both MICH and SRCL the orange traces (FF to ETMY) show a phase advanced with respect to the blue traces (FF to ETMX). For some reasons I don't fully understand, this rotation is more problematic for SRCL than for MICH, although fitting MICH has also been more difficult and the MICH FF is relevant at lower frequencies than SRCL, so maybe the phase advanced isn't that problematic.

Looking at the measurement of the MICHFF to DARM and SRCLFF to DARM, one can see that there seems to be an additional phase delay in the FF path through ETMY PUM with respect to the FF path through ETMX full chain. Since this transfer function is at the denominator when computing the ratio SRCLtoDARM/SRCLFFtoDARM that gives use the LSC FF to fit, this seems to explain the additional phase advance we observe.

The ETMY PUM L2 lock filter bank contains a "QPrime" filter module that compensates partially the additional 1/f^2 due to the actuation from L2 instead of L3. This filter however doesn't seem able to explain this additonal phase delay.

I'm now suspicious that there might be something wrong or mistuned in the ETMY L2 drive, maybe a whitening filter missing or not functioning properly or not properly compensated?

It would be worth doing a quick test in the next commissioning time with full IFO locked: inject some white noise on ETMX L2 L and ETMY L2 L and comapre the two transfer functions to DARM. In theory they should be equal, except for a sign difference. If they're not, then there must be something wrong with ETMY, since we're using ETMX L2 to lock without issues.