Ryan C, Rahul

We have finished the assembly of the 10^th Ham Relay Triple Suspension (HRTS) for O5, which is being assembled and characterized in the stagings clean room lab upstairs. In June we reported the assembly and testing of first five Freestanding HRTS suspension (see LHO alog 78574 and 78711), since then we have built an additional five of them, thus bringing the total count to ten for both the sites (with two more to go, total twelve required between LHO & LLO which includes one spare at each site).

I have attached several pictures (attachment01, attachment02, attachment03, attachment04) below which shows the assembled & locked HRTS stored in the lab on the flow bench in the clean room. Picture01 shows an HRTS with BOSEMs and cables attached, ready to be characterized on test stand (reference pic is shown here).

In this round of HRTS assembly work we have assembled three Freestanding configuration, one Suspended version (shown in the attachment05 below) and one OM0 (attachment06). The Suspended version of HRTS will be attached to the new BBSS (beam splitter) in O5 and Om0 will have bottom mass (optic) actuation using AOSEMS.The top mass will be controlled by 6 BOSEMs which is common for all types of HRTS.

After finishing the assembly work, we balanced all three stages of the suspensions for all six degrees of freedom. This involved lowering and matching  blade tip height and angle on the top stage (2 blade springs) and on the top mass (4 blade springs). In all the cases, optic's lowest edge was lowered to a height of 40.5mm (+-0.5mm) from the bottom of the cage. The PUM and Top Mass height was adjusted based on the scribe lines on the structure.

Given blow are the details (OLV, offsets and Gain) of the six BOSEMs attached the HRTS.

1. Structure no. 07, Configuration: Suspended

Suspended masses: Top Mass = 755gm, Penultimate mass = 802gm, Dummy optic = 300gm

BOSEMs s/n D060108-E. S1900741, S1900749, S1900622, S1900662, S1900637, S1900613.

2. Structure no. 06, Configuration: OM0

Suspended masses: Top Mass = 755gm, Penultimate mass = 802gm, Dummy optic = 301gm

BOSEMs s/n D060108-E. S1900726, S1900723, S1900746, S1900732, S1900742, S1900747

3. Structure no. 04, Configuration: Freestanding

Suspended masses: Top Mass = 758gm, Penultimate mass = 802gm, Dummy optic = 301gm

BOSEMs s/n D060108-E. S1900749, S1900722, S1900724, S1900735, S1900740, S1900744

4. Structure no. 05, Configuration: Freestanding

Suspended masses: Top Mass = 755gm, Penultimate mass = 803gm, Dummy optic = 300gm

BOSEMs s/n D060108-E. S1900730, S1900727, S1900750, S1900738, S1900743, S1900734

5. Structure no. 09, Configuration: Freestanding

Suspended masses: Top Mass = 758gm, Penultimate mass = 800gm, Dummy optic = 300gm

BOSEMs s/n D060108-E. S19007309 S1900725, S1900733, S1900736, S1900803, S1900728

********************************************

Note- The test results of the suspension will be posted below as comments.

Betsy asked me to take a look at doing B&K measurements of the BBSS being assembled in the staging building, so I reminded myself how to use the B&K and took measurements this morning. I'll attach a photo shortly, but I put the accel on the very bottom of the cage, with +X axis aligned with optic longitudinal, Z aligned with is optic vertical, Y is optic transverse. Plots are titled with the accel axis that I hit on the suspension cage, while the legends are labeled with the accel axis response, so "BBSS X Meas" shows the X,Y,Z tf from hitting the cage along the accel X axis. These measurements are a kind of a mid point of the assembly, looks like most of the parts were there, but the bottom stage osems didn't have flags, I didn't see any vibration absorbers.

I think the most concerning thing I see is this 65-ish hz X mode on the first plot. It's the biggest peak and is in a band that could potentially really limit some of the ISI loop gains, if it's not well damped on the table.

A while ago I made a script to plot these measurements, but didn't explicitly say how to run it. Script is quick_plot.py is userapps/sys/h1/scripts/bruel_and_kjaer:

jim.warner@cdsws22:~ 0$ userapps
jim.warner@cdsws22:release 0$ cd sys/h1/scripts/bruel_and_kjaer/
jim.warner@cdsws22:bruel_and_kjaer 148$ ./quick_plot.py -t "BBSS Z Meas" -f "/path/to/data/BBSS_Z_meas.csv"
 

Vicky, Sheila, Naoki

First we tried SRCL offset of -400, which looked good in yesterday's FIS SRCL offset measurement 79903. We took the calibration measurement with SRCL offset of -400 in 79911, but Louis reported in the mattermost that there is a large optical spring in the sensing function. Also, FDS with SRCL offset of -400 is worse than nominal. Vicky will add more plots for this.

Then we decided to change the SRCL offset to -290 and optimized FC detuning. This improved the sensitivity below 100 Hz as shown in the first attachment and improved the range by ~5Mpc. The optimal FC detuning changed from -34 Hz to -28 Hz and this could be because of SRCL offset change and arm power change.

After FC detuning improvement, we took the calibration measurement with SRCL offset of -290 in 79922, but the measurement did not make sense according to Louis so we took an another calibration measurement with SRCL offset of -290 in 79928. 

This was a fast test right at the end of the commissioning period. I tried changing the offset on the AS WFS to see if that changes the low frequency sensitivity of DARM. Short answer: no change in sensitivity without the offset, and no improvement in sensitivity with a higher offset, which yesterday's tests suggested would help (79904).

I forgot to save the reference for the higher offset test (it was exactly the same as the others), but here is a comparison of the current offset (-0.15) and zero offset. The April 11 reference trace is also shown. We are very close to our best low frequency sensitivity in April (pre-OFI problems).

I think that if it helps the SQZ ASC to have no offset, we should turn this offset off. DHARD Y coherence is now very low even with the offset off.

Dropped out of OBSERVING at 1530utc (830amPT), for calibration measurements and then went immediately into Thurs COMMISSIONING time.  Commissioning ended 1917utc (1217pmPT).

Sheila, Dave:

On Sheila's request, I have edited the generate_ifo_range_medm.py script to add a new line for the H1:CDS-SENSMON2_BNS_EFF_RANGE_CLEAN_MPC channel (plus its associated GPS channel).

This icalibration was requested by Sheila after today's Commissioning work.

Measurement NOTES:

• Following instructions (link)
• H1 at NLN for for over 13.25hrs
• Calibration_Monitor medm screenshot is attached
• 1827utc (1409596056 gps) Out of Observing, ISC LOCK to NLN_CAL_MEAS & Observatory Mode to CALIBRATION
• 1827-1832  Broadband measurement run
  • Measurement at:  /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/
• 1832-1856 Simullines measurement
  • gps START time:  1409596387.219105
  • gps END time: 1409597812.855494
  • Files writtten to subfolders here:  /ligo/groups/cal/H1/measurements

I've expanded the use of the new "system" MEDM widget to the CDS section of the oveview. HW_STAT, PICKET_FENCE and CDS_SDF are now color coded blocks, replacing the related-display+LED pairs.

These blocks will turn RED in non-nominal conditions. In addition HW and PKT will turn MAGENTA if their respective servers stop updating.

Sheila D, Elenna C, TJ S

Yesterday we ran the a2l_min_multi.py script and then Elenna adjusted the ITM yaw gains by hand to see if the script was actually helping our coupling in a way we would like (alog79904). Today, we did a similar exercise but made some adjustments to the script to see if we could tune it a bit better and get it work properly. The short answer is that the script stills seems to want the ITMY Y gain to be ~0.2 different compared to where Elenna found the best CHARD Y coherence. Other quads and dofs seemed to be ok in this instance though.

This morning we were curious if the script agreed with the changes made yesterday, so we quickly ran it at the start of commissioning. Sheila and Elenna noticed that the script didn't actually have a zero crossing for a few of the dofs, ITMY was particularly far off (seen in <a href="https://alog.ligo-wa.caltech.edu/aLOG/uploads/79921_20240905113858_a2l_demod_3_tries.png">attachment 2</a>). When the script doesn't find a zero crossing within its scan range, it would just return the initial gain and stop. So, Sheila and I made some changes by hand using a pen to screen linear fit, then ran the script again. This was better but ITMY Y didn't change because the magnitude of the gain change was greater than the gain change threshold coded in. We bumped this up from 0.2 to 0.5 and tried one more time. This try had only ITMY Y gain appreciably change, and all other dofs looked much better from a perspective of all of their demod signals had zero crossings in the center of their scan range.

At this point, the script wants ITMY Y at -2.46. Elenna then moved ITM Y gains by hand and found that the previous value (from the second running of the script) of -2.2 for ITMY Y looked best. See attachment 1. The -2.46 gain looked worse <20Hz, see the top right plot in the attached. Elenna also checked DHARD and agreed that it looks good.

We aren't really sure why the script disagrees so much with this one dof right now. This script is based on one that LLO uses, and it seems to work for them. More thought needed.

Initial a2l gains before starting this morning:

            'P2L':{'ITMX':-0.98,
                   'ITMY':-0.36,
                   'ETMX':3.08,
                   'ETMY':4.48},
            'Y2L':{'ITMX':2.90,
                   'ITMY':-1.7,
                   'ETMX':4.85,
                   'ETMY':1.13 },

Final a2l gains:
            'P2L':{'ITMX':-1.0,
                   'ITMY':-0.39,
                   'ETMX':2.98,
                   'ETMY':4.72},
            'Y2L':{'ITMX':2.87,
                   'ITMY':-2.25,
                   'ETMX':4.88,
                   'ETMY':1.49 },

Here is a summary of the 4 spontaneous IPC errors we have seen during the O4 run so far.

Note that both the * and the @ events are identical pairs of events.

The fact that h1susetmx had todays issue back on Oct 2023 rules out the recent addition of the new LIGO-28AO32 DAC card as being a possible problem.

Today after the SRCL offset was changed from -175 to -400, I quickly ran an injection to check the performance of the feedforward. I also had uploaded a new feedforward that would fix the 100-200 Hz bump that is injecting excess noise.

The "current" feedforward, which is in FM5, still worked well even with the new -400 offset. The "new" feedforward, in FM8, fixes the excess noise and also still performs well. The "old" feedforward FM4, post vent, is shown for comparison (this is what I was improving against last week).

I have SDFed in observe and changed the guardian to use this new FF.

This is with a new SRCL1 OFFSET of -400 (for H1:LSC-SRCL1_OFFSET), as requested by Sheila from commissioning work yesterday.

Measurement NOTES:

• Following instructions (link)
• H1 at NLN for for over 10hrs
• Calibration_Monitor medm screenshot is attached
• 1530utc (1409585476gps) Out of Observing, ISC LOCK to NLN_CAL_MEAS & Observatory Mode to CALIBRATION
• 1530-1536  Broadband measurement run
  • Measurement at:  /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/
• 1536-1559 Simullines measurement
  • gps START time:  1409585811.704323
  • gps END time: 1409587193.962640
  • Files writtten to subfolders here:  /ligo/groups/cal/H1/measurements

Now handing over to Commissioners for Thurs Commissioning.

Before running this morning's calibration, Sheila asked me to change the offset for LSC's SRCL1 (so change to -400 [from -175] for H1:LSC-SRCL1_OFFSET) was made and the SDF has been ACCEPTED (attached).

Thu Sep 05 08:08:55 2024 INFO: Fill completed in 8min 51secs

Gerardo confirmed a good fill curbside.

At 02:08:03 the h1oaf and h1calcs models reported a single IPC receive error for channels being sent by the h1susetmx model.

Preliminary findings:

For all three channels this was a single IPC error in all receivers (one packet in that second's 16384 packets didn't get received in time)

There was no issue with h1susetmx's CPU usage at the time

There was no issue with h1cdsrfm's EX2CS thread (nor any thread) processing at the time

Last night at GPS=1381715243 (Wed Oct 18 18:47:05 2023 PDT) h1oaf and h1calcs long-range-dolphin receivers from h1susetmx reported a single receive error (1 errror in the 16384 packets received in that second). This is the first error of this type this year. There was no issue with h1susetmx at the time, its cpu max is 20uS. I'll clear the errors on the next TOO.

With an error rate of 1 per year, (1 in 5.2e+11) we will just continue to monitor this for now.