Ibrahim, Dave:

RM1 exceeded its RMS motion limit, and 5 minutes later the HAM1 DACs were DACKILLed, stopping all h1isiham1 and h1hpiham1 drives.

We have bypassed RM1 and SEI-HAM1 watchdogs indefinitely for now.

Thu Apr 24 10:07:42 2025 INFO: Fill completed in 7min 39secs

Gerardo confirmed a good fill curbside.

Jennie Wright, Sheila, Keita, Camilla

Jennie has been working on modeling of our arm to OMC mode matching, and while she was looking for some distances we noticed a discrepancy between the as built numbers and the mode matching design.  It seems possible that there was a mix up, where design documents call for a distance of 97cm between the OMC waist and OM2, and the as built distance is 97 cm between the OMC input coupler and OM2 (so,  the OMC seems to be translated by 14 cm from where the mode matching design expected it to be).  If we have the q parameter used in the design (ROC matched to SRM, beam size there is 2.1mm), this would introduce a 1% mismatch between the OMC mode and the SRC mode (the impact could be larger for a different q parameter).   Note that the analysis done in 71145 was using the design distances, so we will want to revisit that.  I've attached an a la mode script below.

Editing to add more information:

I initially did this with the design ROC for OM2, which is 1.7meters, which is also what is in Finesse.  This results in an overlap for the design locations of 99.95% and 99% for the as built locations, with the as built waist location 12cm from the OMC waist location (there are differences in the other distances that partially cancel the 14cm difference between OMC input coupler and OMC waist location), and a waist size of 545um compared to the OMC eigenmode of 509um. In 71145 Keita says that the OM2 ROC is 2m cold and 1.75m hot. 

If we change the OM2 curvature for the as built path to 2 meters, the overlap becomes 93.8%, and the waist location becomes 14.3cm from the OMC waist location, with a waist size of 649um.  Using the hot ROC of 1.75m, the overlap becomes 98.5% and the waist is 563um 11.5cm from the OMC waist.  So, if our q parameter was the design one at SRM, the error in OM2 curvature would be compounding the error in the OMC placement to make the mode matching worse.  The single bounce measurements agree that the mode matching is worse with OM2 cold than hot, but the full IFO measurements are the opposite.

Summarizing distances:

T1000317:

• OMC waist to OM3: 26.8 cm
• OMC waist to OM2: 97.6 cm
• OMC waist to OM1: 2.37 m
• OMC waist to SRM: 6.017 m

T1200410 says we should have:

• OMC waist to OM3: 26.2cm
• OMC waist to OM2: 97 cm
• OMC waist to OM1: 2.365 m
• OMC waist to SRM: 5.936 m

.yaml file, which is based on E2100383:

• OMC input coupler to OM3: 30.4cm
• OMC input coupler to OM2: 97.1cm
• OMC input coupler to OM1: 2.416m
• OMC input coupler to SRM: 5.858 m

Camilla looking at edrawings (which agree with photos):

• OMC input coupler to OM3: 30.1cm
• OMC input coupler to OM2 95.5cm
• OMC input coupler to OM1: 2.4meters

To compare the solid works to the photos we looked at D0901822 and compared it to OM3 photo and this photo of OM2 when it was a tip tilt. 

Using the beam q from table 1 of T1200410 for just after SRM, and propagating it through the distances from T1000317, gives an overlap with the OMC waist of 99.96%.  Adjusting the SRM to OM1 distance to agree with T1200410 gives 99.95%, so that difference between the two design documents isn't significant. 

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

Dew point measurement at HAM1 , approx. -42C

As part of installing a third DAQ framewriter I have written python code to generate a new DAQ Detail MEDM. It is launched by the DETAIL button on the CDS Overview (see attached).

Note that while FW2 is being tested its entry is a placeholder. When FW2 is put into production, the frames from all three framewriters will be checked to ensure they are identical.

The only difference between the old and new MEDM is that the new shows when the framewriters are actively writing their frame files to disk (the BUSY flag).

At 17:40:57 Wed 23apr2025 PDT (GPS 1429490475) some corner station long-range-dolphin IPC receivers got a single receive error from h1susetmx and h1susetmy senders. This is one error in the 16384 packets received in that second.

The 6 receivers in h1oaf and h1calcs are the only receivers of the h1sus[etmx,etmy] senders but they are not the only receivers of channels being sent from h1sus[ex,ey] frontends (h1sus[etmx,etmy]pi sends to h1omcpi). Nor are they the only receivers of signals coming from the end stations; h1lsc and h1asc receive channels from h1isc[ex,ey].

Because these receive errors were at the same time and symetrical between the two end stations, a glitch in the cdsrfm system is suspected.

TITLE: 04/24 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: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

IFO is in PLANNED ENGINEERING for the VENT

Today's planned activities:

• HAM1
  • Cable dressing
  • Install RMs and cable
  • ISC prep
  • Straighten cables
  • Top flange gauge
• HAM 4-5 cable tray work and some craning
• EY wind fence work prep
• HEPI software upgrade
• PCAL at both ends

Work safe!

All 8 pre-filters were swapped out at End-Y AHU-1. Of the 2 Supply Fans, SF-1 was running. The 8 pre-filters on the other side (SF-2) where it wasn't pulling air were still in great condition and left alone. 
Also, all 8 pre-filters were swapped out at End-X AHU-1. Same situation as E-Y. AHU-2 side was not swapped out. The pre-filters still looked near brand new.
Another note worth mentioning is that of the 16 pre-filters that were replaced, the filtration level of each was MERV-12 or MERV-11. They were replaced with 16 new pre-filters that are all MERV-11. This will likely slightly increase the air volume flowing through the unit. 

4-22 (Tuesday) activities:

- After reaching ~1.3E-6 Torr at the corner, GV2 was opened (the corner was valved together with the X-manifold), that brought down the pressure to ~9E-7 Torr in ~2 hours
- The aux carts from GV5, BSC8, and HAM4 have been detached, 2 of them have been staged at HAM1/HAM2 as a preparation for the pumpdown of the annulus volume

4-23 (Wednesday) activities:

- The stiffening frame for the 1000 amu RGA is being built
- The filter elements were replaced in the EX clean air supply, and it is now running for 24 hours, with a vent valve open in the VEA

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

Productive day in which the following tasks were done:

• HAM 1
  • IAS alignment checks - DONE
  • Actuation reattachment work, ISI prep - DONE
  • SEI, IAS cabling - DONE
  • More cabling - Almost done
  • Cable straightening and cable tray
• RANDY - Crane 3IFO flange crate over BT - DONE
• MARC - Post install measurement of RF cables (contd.) - DONE

LOG:

Jonathan, Dave,

We replaced the hardware that is running h2daqfw2 today.  This was done to put in a system that had more memory.  We pulled a spare daq unit out of the test stand (most recently named x6dc0).  While doing that we swapped the memory with a broken daqd system, so that the new h2daqfw2 now has 256GB of ram.  The system is up and running again, I'm tracking the setup in puppet so that we have a low rebuild time.

This was done to support investigating differences between the frames generated on h1daqfw[01] and hqdaqfw2.  I need to be able to run modified versions of daqd to see some of the internal state that is not exposed to be able to understand and fix differences in encoding of the frames.  When I ran daqd on the old hardware, it ran out of memory, even after reducing buffer sizes.

After finishing initial alignment this morning, Mitch and I wrapped up the upgrade of the ISI to A+ spec. The last parts to go on were the vertical stops for the new .25mm vertical CPS and the vertical St0 L4Cs. All the sensors look live now, I will take some more detailed data later. Last pieces to be installed will be some spring tuned mass dampers that have been waiting for me to measure in the staging building for a couple weeks now. 

Tomorrow, I'll help with the cable routing up the ISI, and ISC can start re-installing the optics.

Marc Fil Daniel

We finished the cabling work for the ISC cables between HAM1, ISCT1, and ISC-R1/2/4. This includes re-labeling of all cables that had no or misleading labels.

There is a ladder section along the X-arm access road between the mid- and end-stations.

The second attached photo was taken looking toward the mid-station from the direction of the end-station.

Edgard, Brian.

Following up on the fits for the SR3 estimator. I ran the plotall scripts on the transfer functions we took last Friday [see 84003]. Then ran the attached code to fit the transfer functions.

Figure 1 shows the ISI-M1 fitted transfer function. The Q-factors for the fit were tweaked by hand so I could get a decent fit. The exported M1 to M1 transfer function is shown in the second attachment. I decided it should have the same poles as the ISI one, and the gain was fit so the estimator matches the high-frequency behavior of the measured transfer function. The choice to share poles is because the math indicates that it will lead to some potential modeling errors cancelling out.

The pole information for the two filters is:

         Pole              Damping       Frequency      Time Constant  
                                       (rad/seconds)      (seconds)    
                                                                       
 -4.38e-02 + 6.38e+00i     6.86e-03       6.38e+00         2.28e+01    
 -4.38e-02 - 6.38e+00i     6.86e-03       6.38e+00         2.28e+01    
 -7.64e-02 + 1.44e+01i     5.30e-03       1.44e+01         1.31e+01    
 -7.64e-02 - 1.44e+01i     5.30e-03       1.44e+01         1.31e+01    
 -2.97e-02 + 2.13e+01i     1.39e-03       2.13e+01         3.37e+01    
 -2.97e-02 - 2.13e+01i     1.39e-03       2.13e+01         3.37e+01

And the zpk strings (in MATLAB format) are:

ISI to M1:

zpk([-0.068+20.398i,-0.068-20.398i,-0.099+11.454i,-0.099-11.454i,0,0],[-0.03+21.271i,-0.03-21.271i,-0.076+14.435i,-0.076-14.435i,-0.044+6.384i,-0.044-6.384i],-0.75)'

M1 to M1:

zpk([4745.079,-0.089+8.28i,-0.089-8.28i,-0.113+19.058i,-0.113-19.058i],[-0.03+21.271i,-0.03-21.271i,-0.076+14.435i,-0.076-14.435i,-0.044+6.384i,-0.044-6.384i],-0.015)

I did the fits by using the spectrumest function in MATLAB (which is sadly not available in 2019a). The long term plan is to switch to one of the many python fitting tools that people like for the fits. The code is attached to this logpost for bookkeeping