The monthly fire pump test was conducted this morning. Water was only churned per NFPA requirements. Each pump was run for ten minutes. The jockey pump and fire pump 1 were started via simulated pressure drop on the supply line, fire pump 2 was manually started. 

Edgard, Oli.

Follow up to the work summarized in 84012 and 84041.

TL;DR: Oli tested the estimator on Friday and found the ISI state affects the stability of the scheme, plus a gain error in my fits from 84041. The two issues were corrected and the intended estimator drives look normal (promising, even) now. The official test will happen later, depending on HAM1 suspension work.

____

Oli tested the OSEM estimator damping on SR3 on Friday and immediately found two issues to debug:

1) [See first attachment] The ISI state for the first test that Oli ran was DAMPED. Since the estimator was created with the ISI in ISOLATED (and it is intended to be used in that state), the system went unstable. This issue is exacerbated by point 2) below. This means that we need to properly manage the interaction of the estimator with guardian and any watchdogs to ensure the estimator is never engaged if the ISI trips.

2) [See second attachment] There was a miscalibration of the fits I originally imported to the front-end. This resulted in large drives when using the estimator path. In the second figure, there are three conditions for the yaw damping of SR3:
           ( t < -6 min )          OSEM damping with gain of -0.1.
    ( -6 min<  t  < -2 min)   OSEM damping with a gain of -0.5, split between the usual damping path and the estimator path.
     ( -2 min < t < 0 min)     OSEM + Estimator damping.

The top left corner plot shows the observed motion from every path. It can be seen that M1_YAW_DAMP_EST_IN1 (the input to the estimator damping filters) is orders of magnitude larger than M1_DAMP_IN1 (the imput to the regular OSEM damping filters).

The issue was that I fit and exported the transfer functions in SI units, [m/m] for the suspoint to M1, and [m/N] for M1 to M1. I didn't export the calibration factors to convert to [um/nm] and [um/drive_cts], respectively.

____

I fixed this issue on Friday. Updated the files in /sus/trunk/HLTS/Common/FilterDesign/Estimator/  to add a calibration filter module to the two estimator paths (a factor of 0.001 for suspoint to M1, and 1.5404 for M1 to M1). The changes are current as of revision 12288 of the sus svn.

The third attachment shows the intended drives from the estimator and OSEM-only paths. They look similar enough that we believe the miscalibration issue has been resolved. For now we stand by until there is a chance to test the scheme again.

Morning dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 , approx. -43C

Tue Apr 29 10:04:37 2025 INFO: Fill completed in 4min 34secs

Closes FAMIS26501

2025-04-29 08:05:53.258718

There are 13 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 2 DOF X/U = -1.18 [V]
ETMX T240 2 DOF Y/V = -1.115 [V]
ETMX T240 2 DOF Z/W = -0.803 [V]
ITMX T240 1 DOF X/U = -1.733 [V]
ITMX T240 2 DOF Z/W = 0.355 [V]
ITMX T240 3 DOF X/U = -2.292 [V]
ITMY T240 3 DOF X/U = -0.976 [V]
ITMY T240 3 DOF Z/W = -2.401 [V]
BS T240 2 DOF Y/V = -0.318 [V]
BS T240 3 DOF X/U = -0.604 [V]
BS T240 3 DOF Z/W = -0.365 [V]
HAM8 1 DOF Y/V = -0.478 [V]
HAM8 1 DOF Z/W = -0.764 [V]

All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = -0.1 [V]
ETMX T240 1 DOF Y/V = -0.082 [V]
ETMX T240 1 DOF Z/W = -0.092 [V]
ETMX T240 3 DOF X/U = -0.035 [V]
ETMX T240 3 DOF Y/V = -0.154 [V]
ETMX T240 3 DOF Z/W = -0.063 [V]
ETMY T240 1 DOF X/U = 0.011 [V]
ETMY T240 1 DOF Y/V = 0.083 [V]
ETMY T240 1 DOF Z/W = 0.149 [V]
ETMY T240 2 DOF X/U = -0.134 [V]
ETMY T240 2 DOF Y/V = 0.152 [V]
ETMY T240 2 DOF Z/W = 0.046 [V]
ETMY T240 3 DOF X/U = 0.158 [V]
ETMY T240 3 DOF Y/V = 0.031 [V]
ETMY T240 3 DOF Z/W = 0.058 [V]
ITMX T240 1 DOF Y/V = 0.22 [V]
ITMX T240 1 DOF Z/W = 0.14 [V]
ITMX T240 2 DOF X/U = 0.155 [V]
ITMX T240 2 DOF Y/V = -0.054 [V]
ITMX T240 3 DOF Y/V = 0.253 [V]
ITMX T240 3 DOF Z/W = 0.139 [V]
ITMY T240 1 DOF X/U = -0.059 [V]
ITMY T240 1 DOF Y/V = 0.018 [V]
ITMY T240 1 DOF Z/W = -0.067 [V]
ITMY T240 2 DOF X/U = 0.008 [V]
ITMY T240 2 DOF Y/V = 0.211 [V]
ITMY T240 2 DOF Z/W = -0.046 [V]
ITMY T240 3 DOF Y/V = -0.056 [V]
BS T240 1 DOF X/U = 0.176 [V]
BS T240 1 DOF Y/V = -0.272 [V]
BS T240 1 DOF Z/W = -0.278 [V]
BS T240 2 DOF X/U = 0.094 [V]
BS T240 2 DOF Z/W = 0.221 [V]
BS T240 3 DOF Y/V = -0.039 [V]
HAM8 1 DOF X/U = -0.297 [V]

FRS33974

Following this morning's reboot of x1dtslogin, the EPICS IOC reporting the H2 building DTS environment channels froze with its last values instead of crashing. After 10 minutes this was reported on the main DTS MEDM with a red banner showing a stuck GPS time, but this was not reflected on the CDS Overview.

I have modified DTS.adl, which is used by the CDS overview, to show a red flag if the GPS time stops updating. Attachment shows the new flag and a trend of the DTS air flow channel showing the freeze which started at 07:33 Tue 29apr2025

TITLE: 04/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.50 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

• Some of the work today includes
  • EY wind fence work
  • HAM1 cable work
  • Ground checks of LSC/ASC diode boxes now fully cabled
  • HAM1 - RM finish SUS troubleshooting - get suspended with good TFs
  • HAM1 RM1 troubleshooting ground - alog missing pin 1 ?
  • VAC - HAM1 Top flange Gauge work table side
  • PCAL
  • HAM4/5 cable trays
  • When all SUS, SEI, PSL seem in good order, transition to Laser Haz and perform 200mW lockout power into HAMs
  • Model work, DAQ restart
  • Clean room moves, BSC8

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

1. Beckhoff computer and terminals in Mechanical Room
2. Beckhoff terminals in LVEA (BSC2)
3. Connected to switch: sw-mech-aux port 5

TITLE: 04/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is in PLANNED ENGINEERING for VENT

Short summary of  work done:

• Move HAM1 CR
• IOT2L Table move (alog 84149)
• HAM1 progress contd (alog 84155)
• RM work contd.
• Boom lift to EY

LOG:

Oli, Camilla.

Following work done in 84115 to repopulate HAM1 with some optical components, today Oli and I placed the SLED in position and placed all the diodes, most (not LSC POP A ) are cabled. Photos taken from -Y side and +Y side attached.

Apart from LSC POP A, they are all cabled up according to the cables in D1000313 BOM googlesheet. LSC POP A has a heli-coil that needs replacing before we can install the RF cable so neither cable are currently installed. ASC REFL A and B are in the incorrect position to allow for beam profiling before moving the the final position. LSC REFL A and B may need to be moved slightly but we need more of the correct size dog clamps to allow that. 

FAMIS 31083

Short list of PSL-related events over the past week are as follows:

• Picomotor driver change (in enclosure): alog84045
• PMC/RefCav alignment: alog84063
• Model restarts of h1pslpmc and h1pslfss (resetting lock counts): alog84044
• AMP1 pump diode current increase: alog84081

Aside from these events, no other major changes of note.

Input Arm alignment pointing for the HAM2 an HAM3 suspensions was re-checked after corner pumpdown. Since HEPI is locked currently, we wanted a time pre-venting where HEPI is also locked in order to be able to compare. I used the pointing values which follow the format: H1:SUS-{suspension}_M1_DAMP_{P or Y}_INMON.

HAM HEPIs LOCKED and CORNER (except HAM1) UNDER VACUUM - GPS TIME: 1427710424

Most of these are very close and do not need to be adjusted, with only 2 being different by over 100 microradians. 45% of values have less than 10urad discrepancy. 85% have less than 50urad discrepancy. After speaking with TJ, I realigned two most egregious ones IM4 Y, and IM2 P to their pre-vent (HEPI Locked) values using the OPTICALIGN sliders. Screenshots below of plots used further show the pointing as well as the old to new value differences of the two suspensions that were aligned. After alignment, all values are under 100urad discrepancy and 95% are under 50urad difference.

Jonathan, Dave:

The DAQ detail MEDM has been updated to show FW2's progress within the 64 second cycle for full frames, 600 second cycle for second trends and 3600 second cycle for minute frames.

When each progress bar reaches the end, the next data accumulation phase starts and the frame file writing begins.

A new run_number column has been added, along with a LED stack checking these all agree with each other.

The retransmission column has been removed.

Randy, Mitchell, Tyler, TJ, Betsy, Oli, Camilla. WP#12444, WP#12496, moved away from HAM2 in 83686.

We attempted to move IOT2L back into place on Friday but the cleanroom had been moved into the way of the final table position for ISI work and one of the casters of the table was stripping rubber off one side and kept rubbing so we paused.

This morning the cleanroom was moved out of the way (+X by ~1-2 feet) and then Randy finished moving IOT2L into place with the help of the forklift. Once IOT2L's corners were over the markings made in 83296 and the height was correct, we re-attached the bellows, removed the guillotines and replaced the guillotine slot covers. Photos attached. The HAM2 VP furthest to -Y never had a guillotine slot cover, so one was added. 

Summary

Q: What is the relationship between the strength of violin mode ring-ups and the number of narrow spectral artifacts around the violin modes? Is there a clear cut-off at which the contamination begins?

A: The answer depends on the time period analyzed. There was an unusual time period spanning from mid-June 2023 through (very approximately) August 2023. During this time period, the number lines during ring-ups was much greater than in the rest of O4, and the appearance of the contamination may have begun at lower violin mode amplitudes.

What to keep in mind when looking at the plots.

1. These plots use the Fscan line count in a 200-Hz band around each violin mode region, which is a pretty rough metric, and not good for picking up small variations in the line count. It's the best we've got at the moment, and it can show big-picture changes. But on some days, contamination is present, but only in the form of ~10 narrow lines symmetrically arranged around a high violin mode peak. (Example in the last figure, fig 7) This small jump in the line count may not show up above the usual fluctuations. However, in aggregate (over all of O4) this phenomenon does become an issue for CW data quality. These "slight contamination" cases are also particularly important for answering the question "at what violin mode amplitude does the contamination just start to emerge?" In short, we shouldn't put too much faith in this method for locating a cut-off problematic violin mode height.

2. The violin modes may not be the only factor in play, so we shouldn't necessarily expect a very clear trend. For example, consider alog 79825 . This alog showed that at least some of the contamination lines are violin mode + calibration line intermodulations. Some of them (the weaker ones) disappeared below the rest of the noise when the violin mode amplitude decreased. Others (the stronger ones) remained visible at reduced amplitude. Both clusters vanished when the temporary calibration lines were off. If we asked the question "How high do the violin modes need to be...?" using just these two clusters, we'd get different apparent answers depending on (a) which cluster we chose to track (weak or strong), and (b) which time period we selected (calibration lines on or off). This is because at least some of the contamination is dependent on the presence & strength of a second line, not a violin mode.

Looking at the data

First, let's take a look at a simple scatter plot of the violin mode height vs the number of lines identified. This is figure 1. It's essentially an updated version of the scatter plots in alog 71501. It looks like there's a change around 1e-39 on the horizontal axis (which corresponds to peak violin mode height).

However, when we add color-coding by date (figure 2), new features can be seen. There's a shift at the left side of the plot, and an unusual group of high-line-count points in early O4.

The shift at the left side of the plot is likely due to an unrelated data quality issue: combs in the band of interest. In particular, the 9.5 Hz comb, which was identified and removed mid O4, contributes to the line count. Once we subtract out the number of lines which were identified as being part of a comb, this shift disappears (figure 3).

With the distracting factor of comb counts removed, we still need to understand the high-line-count time period. This is more interesting. I've broken the data down into three epochs: start of O4 - June 21, 2023 (figure 4); June 21, 2023 - Sept 1 2023 (figure 5); and Sept 1 2023 - present (figure 6). As shown in the plots, the middle epoch seems notably different from the others.

These dates are highly approximate. The violin mode ring-ups are intermittent, so it's not possible to pinpoint the changes sharply. The Sept 1 date is just the month boundary that seemed to best differentiate between the unusual time period and the rest of O4. The June 21 date is somewhat less arbitrary; it's the date on which the input power was brought back to 60W (alog 70648), which seems a bit suspicious. Note that, with this data set, I can't actually differentiate between a change on June 21 and a change (say) on June 15th, so please don't be misled by the specificity of the selected boundary.