Lockloss @ 23:11 UTC - link to lockloss tool

As usual, no obvious cause for this lockloss, but there's evidence of an ETMX glitch right before it. Ends lock stretch at almost 11 hours.

Following instructions from the TakingCalibrationMeasurements wiki, this morning I ran the usual broadband PCal and Simulines sweeps.

Broadband PCal: 19:30:44 to 19:35:54 UTC

Simulines: 19:36:46 to 20:00:29 UTC

File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250125T193648Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250125T193648Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250125T193648Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250125T193648Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250125T193648Z.hdf5

H1 was out of observing from 19:30 to 20:01 UTC.

Sat Jan 25 10:10:10 2025 INFO: Fill completed in 10min 6secs

TCmins [-94C,-93C] OAT (1C,33F), deltaTempTime 10:10:12

TITLE: 01/25 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 137Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY: Two locklosses overnight, but looks like H1 was able to recover well enough each time. H1 has now been locked for just over 3 hours, and calibration sweeps are scheduled for 19:30 UTC.

• Wind moderately low, microseism dropping slightly around 50th percentile

TITLE: 01/25 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Over a few hours I've seen the range slowly degrade as the SQZ angle slowly increases and REFL_RF6_ABS_OUTPUT decreases. (Tagging SQZ) Lockloss at the end of the shift, currently relocking at DRMI
LOG: No log

00:56 Observing

05:15 UTC lockloss (6 hour lock)

We keep losing it at locking ALS, something makes the arm start oscillating and then the wfs start working hard to fix it and we lose lock. ALS_Y can survive it sometimes. The BS is wicked misaligned now, CHECK_MICH moved it 2 urads in pitch and 1 urad in yaw.

05:15 UTC lockloss

[Matthew Camilla Louis Sheila]

There is concern that the CO2 laser proposed for the CHETA design has enough intensity noise to saturate the ESD preventing lock.

By calibrating the displacement noise projected from CHETA RIN data into counts at the L3_ADC, using the DARM loop OLG and transfer function between DeltaL_ctrl and L3_ADC, we can get a rough estimate of whether we expect the CHETA noise to saturate the ESDs. This is done by looking at the RMS of the cts/rtHz of CHETA noise at the ESD and comparing it to the 25% of saturation level (2^19 counts).

Figure 1 is the loop model for mapping the displament noise (CHETA RIN) to ESD counts, Figure 2 is a plot of the darm olg, Figure 3 is plot of the tf from deltaL_ctrl to L3_adc.
Figure 4 is the projection of CHETA RIN to the ADC counts, showing that we do not estimate CHETA is likely to saturate the ESDs.

Next steps are to see if we estimate CHETA nosie to saturate the DCPDs at different power up stages.

I reported in LHO aLOG 82376 that there were aliasing artifacts as well as a large number of line artifacts not predicted by the offline anti-aliasing analysis. Digging deeper into these unknown artifacts, these may instead be due to the fact that DTT normally holds data as single precision. The DCPD data has a large DC component, so if the data is processed with the "Remove mean" unchecked, then there may be artifacts owing to the large dynamic range. My hunch was confirmed when I tried two things:

1. re-check the "Remove mean" option. Many of the unknown additional line artifacts disappeared
2. using the diaggui_test program, which holds data as double precision.
 2a. Using "remove mean", the unknown additional line artifacts disappeared
 2b. Disabling "remove mean", the unknown additional line artifacts still were gone

Check out LHO aLOG 78559 for other experiences.

Attached is a plot comparing the 524 kHz data of H1:OMC-DCPD_A0_OUT (red) with the 16 kHz of H1:OMC-DCPD_A_OUT_DQ (blue). We don't see any significant differences now that the additional anti-aliasing filters have suppressed high frequency artifacts. The second figure is the now updated PSD comparison before the additional AA filtering in DTT using the "Remove mean" option for the 16k data. Additional artifacts consistent with the expected contribution from aliased artifacts are visible, but now the rest of the spectrum seems more-or-less in agreement.

[Matthew Louis Sheila]

This alog was motivated by trying to understand how CHETA intensity noise will affect the ESD, where we are interested in the open loop gain of DARM (explained more in future alog).

Measuring the open loop gain of DARM

A sample script can be found at the bottom as well as these notebook style instructions.

First you will need to activate the appropriate conda environment

Then enter into an ipython shell, then enter the following commands

To write to a file, you can use the numpy command

Today we re-engaged the 16k Digital AA Filter in the A and B DCPD paths then re-updated the calibration on the front end and in the gstlal-calibration (GDS) pipeline before returning to Observing mode.

### IFO Changes ###

* We engaged FM10 in H1OMC-DCPD_A0 and H1OMC-DCPD_B0 (omc_dcpd_filterbanks.png). We used the command in LHO:82440 to engage the filters and step the OMC Lock demod phase (H1:OMC-LSC_PHASEROT) from  56 to -21 degrees (77 degree change). The 77 degrees shift is necessary to compensate for the fact that the additional 16k AA filter in the DCPD path introduces a 77 degree phase shift at 4190Hz (the oscillator frequency at which the dither line that the OMC Lock servo is locked to) (omc_lock_servo.png). All of these changes (the FM10 toggles and the new OMC demod phase value) have been saved in the OBSERVE and SAFE sdfs.

* It was noted in the control room that the range was quite low (153Mpc) and re remembered that we might want to tune the squeezer again as Camilla had done yesterday (LHO:82421). We have not done this.

* Preliminary analysis of data taken with this newly installed 16k AA filter engaged suggests that the filter is helping (LHO:82420).


### Calibration Changes ###

We pushed a new calibration to the front end and the GDS pipeline based on the measurements in 20250123T211118Z. In brief, here are a few things we learned/did:

- The inverse optical gain (1/Hc) filter changes are not being exported to the front end at all. This is a bug.
- We included the following delays in the actuation path:
    uim_delay = 23.03e-6   [s]
    pum_delay = 0  [s]
    tst_delay = 20.21e-6   [s]
    
    These values are stored in the pydarm_H1.ini file.

- The pyDARM parameter set also contains a value of 198.664 for tst_drive_align_gain, which is inline with CALCS (H1:CAL-CS_DARM_FE_ETMX_L3_DRIVEALIGN_L2L_GAIN) and the ETMX path in-loop (H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN).

- There is still a 5% error at 30Hz that is not fully understood yet. Broadband pcal2darm comparison plots will be posted in a comment.

Closes FAMIS26356 Last checked in alog82332

I didn't see anything of note on either of the scopes.

TITLE: 01/25 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Few hours this morning spent working on calibration, then a lockloss caused another couple hours of reacquisition time this afternoon. H1 has been observing for almost 1.5 hours.

• 15:30 - H1 relocking
• 16:45 - Observing
• 17:16 - Dropping observing for calibration work
• 20:14 - Back to observing
• 20:42 - Lockloss (alog82445)
• 21:50 - HAM7 CPS glitch and ISI WD trip (possibly from someone walking by?)
• 23:10 - Observing

LOG:

FAMIS 26352

Laser Status:
    NPRO output power is 1.85W
    AMP1 output power is 70.23W
    AMP2 output power is 137.2W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 3 days, 4 hr 31 minutes
    Reflected power = 26.16W
    Transmitted power = 102.5W
    PowerSum = 128.6W

FSS:
    It has been locked for 0 days 1 hr and 44 min
    TPD[V] = 0.6629V

ISS:
    The diffracted power is around 3.6%
    Last saturation event was 0 days 3 hours and 19 minutes ago

Possible Issues:
    PMC reflected power is high
    FSS TPD is low

RefCav alignment will likely need to be fixed on-table next Tuesday (I can try touching it up with picos if there's some TOO downtime this weekend, but I don't expect to get much improvement). PMC Refl being high is nothing new.

TITLE: 01/25 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 11mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.22 μm/s
QUICK SUMMARY:

• We've been locked for almost an hour
• Wind is decreasing
• High frequency noise is elevated

Sheila, Jennie W, Ryan S

Summary: The camera servos got turned off accidentally last time we moved PR3. Worth another try at this measurement

Analysis of why we lost lock the other day while doing the PR2 spot move in lock by moving PR3 yaw alignment and pico-ing to stay on the POP and POPAIR PDs, see image.

When we first started alktering the yaw of PR3 at the first cursor the circulating power started to get higher in the arms and around 17:22:02 UTC the circulating power began to go down as did LSC-POP_A. About 30 mins after this the circulating power began to recover as we stopped changing PR3 position and the pic-motor position. We are not sure why this happened. After this preiod we started moving PR3 yaw down again and the circulating power and POP-A power decresed and then we lost lock.

Over this period when wer were not actively chnaging the alignment, PR2 was still moving. So we checked the camera servos to see if they move PR2 (they don't) but we discovered that the camera serrvos were switched off by the camera guardian, see image.

We realised that because the PR2_SPOT_MOVE guardian state that we had ISC-LOCK in is less than 577 which tripped this condition in the CAMERA_SERVO guardian.

The CAMERA-SERVO guardian went to state 500 as shown in the  ndscope final row at the first cursor. This guardian node then stalled here as the PR2_SPOT_MOVE state does not contain a call to the unstall nodes function in ISC_LOCK, instead of switching on ADS servos and then trying to get back to the CAMERA_SERVO_ON state as in its state graph.

We altered the CAMERA SERVO guardian to eliminate the turning off of camera servo if it thinks the IFO is unlocked (ie. in a low number state) as this should be handled by ISC_LOCK which manages it.

Still need to think about why our overall circulating power got better then worse several times during these changes and why precisely we lost lock.

Lockloss @ 20:42 UTC - link to lockloss tool

No obvious cause, but the wind had recently picked up and looks like there was an ETMX glitch immediately before the lockloss.

H1 dropped observing from 17:16 to 20:14 UTC for fixes to the calibration. Log entry to come from Louis/Evan with specifically what was done.

J. Kissel, E. Goetz, L. Dartez

As mentioned briefly in LHO:82329 -- after discovering that there is a significant amount of aliasing from the 524 kHz version of the OMC DCPD signals when down-sampled to 16 kHz -- Louis and Evan tried a versions of the (test, pick-off, A1, A2, B1, and B2) DCPD signal path with two copies, each, of the existing 524 kHz to 65kHz and 65 kHz to 16 kHz AA filters as opposed to one. In this aLOG, I'll refer to these filters as "Dec65k" and "Dec16k," or for short in the plots attached "65k" and "16k."

Just restating the conclusion from LHO:82329 :: Having two copies of these filters -- and thus a factor of 10x more suppression in the 8 to 32kHz region and 100x more suppression in the 32 to 232 kHz region -- seems to dramatically improve the amount of aliasing.

Recall these filters were designed with lots of compromises in mind -- see all the details in G2202011.

Upon discussion of applying this "why don't we just add MOAR FIRE" option 2xDec65k and 2xDec16k option for the primary signal path, there was concerns about 
    - DARM open loop gain phase margin, and
    - Computational turn-around time for the h1iopomc0 front-end process.

I attach two plots to help facilitate that discussion,
    (1st attachment) Bode plot of various combinations of the Dec65k and Dec16k filters.
    (2nd attachment) Plot of the CPU timing meter over the weekend, the during in which these filters were installed and ON in the 4x test banks on the same computer.

For (1st) :: Here we show several of the high-frequency suppression above 1000 Hz, and phase loss around 100 Hz for a couple of simple combinations of filtering. The weekend configuration of two copies of the 65k and 16k filters is shown in BLACK, the nominal configuration of one copy is shown in RED. In short -- all these combinations incur less than 5 deg phase loss around the DARM UGF. Louis is going do some modeling to show the impact of these combinations on the DARM loop stability via plots of open loop gain and loop suppression. We anecdotally remember that the phase margin is "pretty tight," sub-30 [deg], but we'll wait for the plots.

For (2nd) :: With the weekend configuration of filters, with eight more filters (the copies of the 65k and 16k, copied 4 times in each of the A1, A2, B1, B2 banks) installed and running, the extremes of CPU clock cycle turnaround time did increase, from "never above 13 [usec]" to "occasionally hitting 14 [usec]" out of the ideal 1/2^16 = 15.26 [usec], which is rounded up on the GDSTP MEDM screen to be an even 16 [usec]. This is to say, that "we can probably run with 4 more filters in the A0 and B0 banks," though that may necessarily limit how much filtering can be in the A1, A2, B1, B2 banks for future testing. Also, no one has really looked at what happens to the gravitational wave channel when the timing of the CPU changes, or gets near the ideal clock-cycle time, namely the basic question "Are there glitches in the GW data when the CPU runs longer than normal?"