TITLE: 01/26 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Mostly quiet shift aside from regular calibration sweeps and a lockloss this afternoon. H1 just finished initial alignment and is starting lock acquisition.

• 19:30 - Dropped observing for calibration sweeps; alog82461
• 20:01 - Resume observing
• 23:11 - Lockloss; alog82462
• 23:57 - Starting initial alignment
  • Strange scenario during ALS alignment where X-arm was locked (around 0.8 transmitted power) but WFS were not turning on. Eventually found that ALS-X_WFS_AUTOC_PZT2_INPIT was too high to trigger, so from the WFS Auto Centering Trigger screen, I flipped the FORCE switch, saw the WFS turn on and bring the PZT input back down to a good level, then turned the FORCE off again. Everything went smoothly after this. Maybe an edge case where the arm can lock but not well enough for the WFS to turn on?
• 00:26 - IA finished, starting lock acquisition

TITLE: 01/26 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 17mph Gusts, 12mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

• Currently running an alignment
• Wind is moderate
• 2ndary microseism is decreasing

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.