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

Summary of the report:

• LHO was observing for an average of 85.8% of the time this week.
• Some of the locklosses happened due to earthquakes, but for some, no apparent cause was known.
• The average range stayed around 160 Mpc. But it dropped to ~140 Mpc for a brief period of time on Monday due to squeezer issues.
• There were some high frequency (above 500 Hz) strain lines were present in the h(t) spectrogram some days of the week.
• Nothing unusual in the glitches. Sometimes the glitchrates increased due to ground motion.
• There were some low frequency (6-8 Hz) noises present in the BSCs during the later half of the week.
• In both EX and EY accoustics, some (10-80 Hz) noises appeared consistently everyday.
• Hveto: There were some new channels during the week (please see detailed report for the channel names).
• Fscan: The line counts stayed around 700, but increased to 800 on Tuesday. But it never crossed the threshold.

Full report: link.

Fri Jan 24 10:14:33 2025 INFO: Fill completed in 14min 29secs

Jordan confirmed a good fill curbside. TCmins [-91C, -90C] OAT (4C, 39F), deltaTempTime 10:14:22

[Evan Louis Matthew]

This morning after Evan and Louis fixed the anti-aliasing filters we used our 'lockloss-less' recipe to re-engage the filters while smoothly changing the demod phase. This required a slight adjustment to the arguments in the command LHO:82430 (listed below).

The new filters seem to be working as expected and are not causing yesterday's calibration error. This transition was done without lockloss.

This is a placeholder alog to state that the calibration and the ifo have been reverted to their nominal state from this morning. I'll follow up and edit this entry with additional details later tonight/ tomorrow morning.

To bring the filters back on and step the phase rot back to modified angle in same ramp time as the filters' ramps.

TITLE: 01/24 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY: H1 lost lock just a half hour ago at 15:09 from a not obvious cause (link to lockloss tool) and is relocking; just reached DRMI.

• Wind low, microseism steady just above 50th percentile

During relocking, H1 couldn't get a DRMI or PRMI so it went to go to the Check_Mich_Fringes state but we lost lock a few seconds into it. The LASER_PWR node was still moving up to 10W that we use for Check_Mich at the time that the 2W request came in, but this was ignored while it was moving. I'm not entirely sure why. So as with many lock losses, our IMC lost lock and since we were at 10W, it couldn't relock. The IMC eventually relocked 2.5 hours later, long enough to give me a call. By the time I logged in, it was already started an initial alignment at 10W. I requested 2W for the PRC alignment step and then it finished off initial alignment on its own.

All of the states in LASER_PWR that do the adjusting are "protected" guardian states, meaning that they have to return true before it's allow to move on. I can't remember why exaclty, but I think this was because it would confuse the rotation stage if you made a power request while there's another one going on. I would expect that once this state was done though, that it would have then moved to the 2W adjusting state, but it looks like it ignored that request entirely. I'll add this to my todo list to fix.

TITLE: 01/24 Eve Shift: 21:00-0600 UTC (1300-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
After we got to Observing  and everyone went home, nothing really happened after my last alog . Its been quiet ever since everyone left.

Since the Lockclock was interupted which was mentioned in my last alog, I should remind everyone:
This lock started at 19:41:24 UTC
Thus H1 has been locked for 10+ Hours.

oh also:
CALCS has some pending configuration changes according to the CDS Overview screen.

TITLE: 01/24 Eve Shift: 21:00-0600 UTC (1300-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY:
H1 has been locked for 7 hours as of  02:41:24 UTC
H1 is currently Observing.
 

End of Comissioning and CtrlZ:
Calibration Team has been working all day on the OMC phase and gains.
Camilla touched up the SQZr settings and temp.
Robert covered the Viewports & we are almost ready to get back to Observing.

The calibration team now has to revert all of their changes.

GDS has been restarted a few times.

1:42 UTC DCPD AA filters turned off and phase changed. No lockloss!!! YAY!!
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=82433

After some final tweaks and some SDF accepts from Louis's changes, whe got back to OBSERVING without a Lockloss at 2:09 32 UTC!

This lock started at 19:41:24 UTC.
At 00:33 UTC I noticed that the Lock Clock FOM had crashed, and thus I relaunched the lockclock.
When it returned, it only had 30 minutes on it, even though we have not lost lock yet and had been locked for many hours.
All of the lock clocks all read the same 30 minutes.
On the Calibration_Monitor, CDS_OverView.
According to this FOM Screenshot of Nuc28 we had been locked for 4 hours and 19 minutes at 00:01 UTC:
https://lhocds.ligo-wa.caltech.edu/cr_screens/archive/png/2025/01/23/16/nuc28-1.png
The Lockclock crashed again, it may have coincided with a restart of GDS?  Sorry, Louis.  
After talking with Dave this turned out to be ; hand editing a puppet file issue.
When dave started working on this https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=82429 puppet started to overwrite the file that he had changed.

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