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. Driggers, T. Sanchez, O. Patane, M. Todd, L. Dartez

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.

In short:
- The OMC demod phase changes from LHO:82413 have been reverted using the steps in LHO:82430 successfully without breaking lock.
- The additional 16kHz AA filters in the DCPD A and B paths have been turned off.
- Camilla reverted her adjustments to the squeezer (LHO:82432)
- The calibration changes have been fully reverted.


There are many details to the several attempts we made to get things working in the calibration pipeline to keep the AA filtering in place. I'll share more with an update ASAP.

After the CAL team changed the OMC digital phase in 82413, the SQZ at the start of the lock went through an excursion much larger than usual, all the way to 5dB of ASQZ before settling around -3.5dB of SQZ, plot. We often have a SQZ excursion at the start of the lock but it rarely gets above 0dB. We are unsure if it makes sense that the OMC change would effect the SQZ like this or we were just unlucky.

I paused SQZ_MANGER and took SQZ_ANG_ADF to DOWN. I think tuned H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG for the best SQZ and adjusted H1:SQZ-ADF_OMC_TRANS_PHASE to get H1:SQZ-ADF_OMC_TRANS_SQZ_ANG to zero, effectively setting the setpoint of the servo. Adjusted from -138 to -128 sdf. We may need to change this again or revert before going back to observing if the SQZ isn't good with a more thermalized IFO.

Also used this time to reduce the HAM7 rejected SHG power. Enabling (not moving) the picos unlocked SQZ which is surprising.

E. Goetz, J. Kissel, L. Dartez

In previous aLOGs (see, e.g., LHO aLOG 82405), we had to decimate the 524 kHz data offline in order to evaluate the improvement of TEST channels with changes to anti-alias filtering. We expected to see a reduction in artifacts with the addition of 1 extra 65-16k decimation filter. Attached is a figure showing before and after the ratio of ASDs calculated in DTT from the DCPD A0 channel (not the TEST A channels). This figure shows some improvements (though perhaps hard to see visually) and introduces more questions, especially comparing to a plot like in LHO aLOG 82405, attached here as well.

Statistics:
Bins above 1% before = 33416
Bins above 1% after = 30273
Bins above 1% before, f < 2000 Hz = 9011
Bins above 1% after, f < 2000 Hz = 8362
Mean before = 1.1087
Mean after = 1.0651
Mean before, f < 2000 Hz = 1.0756
Mean after, f < 2000 = 1.0495

So we do see that the number of bins above 1% has gone down as expected (good), but the raw number of bins above 1% is much different than our expectations. Figure 1 simply seems far noisier than Figure 2. What is the cause of this? It would seem to imply that the IOP downsampling is not simply grabbing 1 value for every 32 samples in a consistent manner, or perhaps the way DTT grabs and exports the PSD data? I'll have to keep digging, but this seems strange

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