Sun Jan 26 10:05:46 2025 INFO: Fill completed in 5min 43secs

TCmins [-87C, -51C] OAT (-1C, 30F) DeltaTempTime 10:05:55. Note TC-B didn't reach its minimum plateau.

Lockloss @ 17:57 UTC - link to lockloss tool

Usual signs of an ETMX glitch on this lockloss, otherwise cause not obvious. Ends lock stretch at just over 4 hours.

TITLE: 01/26 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY: Two locklosses overnight, but H1 again relocked itself each time without issue. H1 has been locked and observing for 2 hours.

• Noticed OMC DCPD signals growing as I came in and found ETMY mode 20 was ringing up again just as Ryan C. saw last night (since VIOLIN_DAMPING hasn't been loaded, his new settings weren't applied); I've changed the damping to the settings he found, and they seem to be damping the mode down well so far.
• Wind low, microseism steady around 50th percentile

TITLE: 01/26 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: The coherence checked yielded lots of CHARD_Y, MICH & SRCL. MC2 and ITMY cameras are blue from Roberts viewport work. We've been locked for ~4.5 hours.
LOG:                                                                                                                                                         

• 01:23 UTC Observing
  • I noticed that ETMY mode20 was slowly ringing up after seeing the DCPD min/max plot on NUC31 look to be slightly diverging, so I turned off the gain at 02:00 UTC. I've set its' gain to 0 in lscparams for now. I've found a setting that has been damping it well for a few hours, I changed the phase from -60 to -30 and used a gain of -1, so FM1 + FM2 + FM10, G = -1.0 (OPSinfo, SUS) the VIOLIN_DAMPING node needs to be reloaded next time we're out of observing.

I was also getting a DIAG_MAIN message about "Noisy BSC CPS on: ITMY, ST1, V2" (SEI).

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 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