WP12827 SUS HLTS Estimator

Jeff, Oli, Brian L, Edgard, Dave, Ryan C:

New h1suspr3 and h1sussr3 models were installed. Slow channels had been renamed and therefore a DAQ restart was required.

WP12835 h1guardian1 reboot

TJ:

h1guardian1 was rebooted, all nodes now have the latest userapps files and changes will be tracked by GRD-CFC.

DAQ Restart

Dave, Jonathan:

The DAQ was restarted for the model changes. GDS0 needed a second restart. FW1 spontaneously restarted itself soon after the 1-leg restart.

Jennie W, Keita, Rahul

On Friday, Keita and Rahul and I tried moving PDs 2 and 6 to align them better with the others. As can be seen from the scans we did of the DC voltage of the diodes as we moved the input alignemnt in horizontal translation and yaw from alog #87290, 2 and 6 have a range of alignment that is shifted relative to the other 6.

We also checked this with a IR sensitive camera with a zoom lens.

One person used the camera with a zoom lens to check the spot on the PDs as another person loosened the screws from behind the array and the third person held the barrel of the PD assembly to stop it moving or rotating in an undesired direction.

There is not a lot of space as 2 and 6 are in a column and are very close to diodes 1 and 5 on the right.

The horizontal scan we took after these moves showed we had made things worse, see this image.

Later that afternoon, Keita moved the PD 2 back and checked the alignment and it looks better.

The alignment as of yesterday (Monday) was 143mm in pitch (as read out by the allen key in the PZT mirror pitch actuator wheel) and 0.4145 inches in horizontal translation as read out by the translation stage the PZT mirror sits on.

Keita measured the coupling (after finding an error in my code from the previous coupling measurement I plotted last Thursday (alog #87400)).

The coupling in both vertical and horizontal is below 10, so this should be good enough for install if all else checks out.

Yesterday afternoon, Rahul and I did the vertical scan (slightly off from the horizontal reference position of 0.4145 inches that Keita had aligned to). The data in this graph was collected at a horizontal translation stage reading of 0.4162 inches.

We had to redo the horizontal scan today as I missed out some scan values yesterday. The data was collected with the pitch indicator at 143mm (the allen key on the pitch wheel actuator).

WP 12836
ECR E2400330
Modified List T2500232

The following SUS SAT Amps were upgraded per ECR E2400330. Modification improves the whitening stage to reduce ADC noise from 0.05 to 10 Hz.

F. Clara, J. Kissel, O. Patane

After maintenance wrapped up this morning, I swept through the LVEA to prep for observing. I unplugged an unused extension cord near the PSL racks and the scissor lift in the vertex/west bay area. Everything else looked okay.

Jeff also mentioned that he moved an SR785 from the PSL racks into the Biergarten for his work this morning, but it's unplugged (in case someone goes looking for it later).

I have created an EPICS IOC which reports any Guardian nodes which use source file(s) which have been modified in userapps but have not been loaded into the nodes. On the next restart of such nodes (e.g. guardian reboot) the new code will be automatically loaded, and so this system permits us to load new code in a scheduled and orderly way, for example by the code-author/node-manager during Tuesday maintenance.

This is similar to the front-end filter-module configuration file change (CFC) system, so I've called this GRD-CFC.

The CDS Overview MEDM has a "GRD CFC" button at the bottom showing the GRD-CFC status as GREEN/YELLOW. Pressing this button opens the H1CDS_GUARDIAN_CFC.adl MEDM (attached).

This MEDM has three main areas:

• Top is the system overview. the magenta box encompasses the CFC summary (it will be yellow if one of more nodes are in need of reloading), the STATUS shows the IOC status
• Middle is the main Guardian nodes table. The grey boxes will turn yellow if any node has one or more source files which need to be loaded
• Bottom is the IOC details section. the yellow box encompassing server start and runtime information. The red box encompasses the database files' validity.

If any nodes are reporting pending changes, you can get pending file details by running the shell command:

guardian_modified_not_loaded

The output from this command provides information on how to list the line differences between pending files and what is running.

Tue Oct 14 10:08:10 2025 INFO: Fill completed in 8min 7secs

Rebooted h1guardian1 at 1547UTC so that we could start with fresh fresh and it would become easier to manage any file differences with help from some of Dave's new screens and scripts.

All nodes started up on their own, and Ryan C helped me recover them all back to a maintenance state.

I went to test the high gain ASC states I made for SEI_ENV this morning while we were still locked this morning. The good news is that there were no errors in the code and it did exactly what I asked of it. The bad news is that we lost lock while transitioning back to a low gain state. This wasn't a great test though because I had a brain fart and forgot to change the thresholds for the test. The high gains were turned on, then immediately turned back. So I'm not entirely sure if the lock loss was from the transition back, or just the fact that we quickly flipped it back and forth. 

The major change between what SEI_ENV does and what the script the operators use right now is that the sleep timers between engaging/disengaging each loop are almost completly gone. At minimum for the next test it seems that we need some for the return back to low gain, or maybe increased tramps.

On the bright side, it looks like the structure of the node and the code seems to work, just need to tune it a bit. For now I've returned this node back to its normal operation, without the high asc states.

M. Todd

Today I ran another OMC scan (following last week's instructions alog 87316 and 87342) after the morning lockloss to see if could a better measurement of the hot state overlaps.

I was still limited to about 12 minutes after the lockloss, so we expect some amount of difference in the full hot state.

I've plotted the results on top of last week's scans, in yellow. Analysis of this will follow in a comment.

Workstations were updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

The second stage heating contactor had burned up, reducing heating capacity. This is why the zone had difficulty maintaining set point on 10/13. I replaced the ruined contactor and checked functionality. 

TITLE: 10/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 10mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.26 μm/s 
QUICK SUMMARY:

• Secondary microseism looks to be rebounding after increasing into the night
• We've been locked for ~19 hours
  • PEM_MAG_INJ node is in error (Key error 'freq_low')
  • The operator WS was stuck at "failed to unmount" when I arrived
• 11:33 UTC Superevent S251014cn

TITLE: 10/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

IFO is in NLN and OBSERVING (~10 hr lock)

2:53 - SQZ Dropped

4:10 - SQZ recovered, back to OBS

Mostly quiet shift except for the SQZ dropping due to FC lockloss.

The Squeezer FC lost lock due to FC2 alignment walking away from a lockable GR_LOCKED configuration. As per the wiki, I trended the last time we had a stable lock and reset values for FC1, FC2 and ZM3 (P/Y). Then, I tuned FC2 a bit more to maximize GR_TRANS output. This worked.

Interestingly, I first tried an alignment from a few days ago but this didn't work. I did this because FC2 has been increasing quite a bit in the last few days (screenshots) - probably worth looking into. The values I set FC suspensions to (using opticalign sliders)

FC2 P: 1558, FC2 Y: 109.6 

FC1 P: -899.6, FC1 Y: -74

ZM3 P: -66.25 ZM3 Y: -463

I hope this issue doesn't happen again during OWL shift though the trend below from a few days ago shows FC2 P going up for the last few days seemingly with SQZ compensating in its alignment. Anecdotally, it seems related to the temperature since there's a diurnal breathing day to day (lows at night, highs in the day). Tagging SQZ to look at FC2 and FC.

LOG:

TITLE: 10/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Locked for 4 hours. We had one lock loss during commissioning time today, though it does not seem to be caused by any commissioning activites. useism is on its way up, and the wind is gusting above 30mph at times. 
LOG:

• 1543 Commissioning start
• 1740 GRB short E609775
  • Since we were already commissioning we will not stand down
• 1747 Lock loss
• 1817 GRB short E609786
  • Relocking, no stand down
• 1917 Observing

In 86964 I ran a side by side comparison of the powers at various ports before and after the power outage so we could determine what, if anything had changed. Although it generally seemed like we had regained or even increased the powers everywhere, kappa C has indicated that the optical gain reduced. Our current kappa C has been consistently near 0.98 since the outage.

However, I calculated the full optical gain value today from the most recent calibration report (20251012T200500Z) and the current exported report on August 23 (20250823T183838Z). Each report lists H_c in ct/m. I also chose a time just before each report was measured to calculate the OMC-DCPD_SUM/LSC-DARM_IN1 transfer function that provides the mA/ct calibration value.

It seems like our optical gain between these two times has actually stayed the same to much less than a percent. I'm not sure what to make of this with regards to the calibration, given that the calibration report suggests an overall magnitude change in the sensing function (that we are correcting in the TDCFs), but in actuality the magnitude of the sensing function has remained constant.

Another big EQ rolling through.  This one is down near Antartica!  Debated when to transition to "ASC Hi Gn", since R-wave was going to be 45-60min.  But S&P waves triggered EQ Mode + saw a yellow Picket Fence---Clicked on ASC Hi Gn button, but during the transition H1 lost lock.  This might have been too big for ASC Hi Gn regardless, but kinda wished I clicked it earlier.

Winds were peaking just under 40mph around the lockloss as well.

Will be hanging out here for a few hours. 

• 2040 Notification of a M7.6 EQ down near Antartica at the Drake Passage
  • R-wave due to arrive in ~1hr and is in the yellow/red area on EQ Response plot (see attached)
• 2043 Start seeing Picket Fence activity (no colors tho)
• 2045 L1 goes down
• 2045 Start seeing S&P Wave spikes on 0.03-0.1Hz Band on nuc5
• 2048 EQ Mode Activated and also get get yellow Picket Fence
• 2049 Turned on Hi Gain ASC
• 2049 H1-LOCKLOSS
• 2050 Keeping ISC LOCK at READY while riding out EQ.
• 2059 Red Picket Fences -AND- SEI_ENV to LARGE_EQ -AND- SEI_CONF goes to LARGE_EQ_NOBRSXY
• 2101 V1 goes down
• 2125 Saw some light BLUE Picket Fences!  (which most likely corresponds with the R-Wave arrival)
• 2135 R-Wave peak (Same or a little bigger than the big Philippines last night). 

Now we wait for R-wave which is probably due to arrive around 2135-ish utc.