TITLE: 07/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY: We're testing/investigating if we can still lock, DRMI locks pretty easily so this alignment might be ok.

• Rahul confirmed HAM5 SUSes looks healthy
• Recreating the trend from alog77392 back in May, HAM6s power looks a little lower but not as large as previously, less than 2% vs 5% loss
• 17:22 UTC Camilla, Naoki, and Sheila ran an single bounce SQZ test and tried to do some centering
• 18:17 UTC A decent sized earthquake passed through 
• 21:10 UTC We started an IA to move SR3 before trying to lock DRMI to check the fast shutter again
• 22:20 UTC Successful fast shutter test
• 22:30 UTC Daniel reset the atomic clock alog79119

LOG:                                                                                                                                                                                                                                     

Genevieve and Sam asked about HAM1 and HAM2 motion around 40 hz. I hadn't look in detail in this frequency band for a while, this is typically higher frequency than we are worried about with ISI motion. But it turns out HAM2 is moving a lot more than HAM3 generally over 25-55hz, and particularly around 39hz. It looks like it might be due to gain peaking from the isolation loops, but could also be from something bad in the HEPI to ISI feedforward. The extra motion is so broad I don't think it's just one loop has a little too much gain, so I'm not sure what is going on here. 

First image are spectra comparing the motion of the HEPIs for those chambers (HAM2 HEPI is red and HAM3 is blue) and the ISIs (HAM2 ISI is green, HAM3 is brown). The HEPI motion is pretty similar, so I don't think it's a difference in input motion. HAM2 is moving something like 10x as much as HAM3 over 25-55hz. The sharp peak at 39 hz looks like gain peaking, but I'm not sure that explains all the difference.

Second plot shows the transfer functions from HEPI to ISI for each chamber. Red is HAM2, blue is HAM3. The 25-55hz tf for HAM3  is not very clean probably because HAM3 is well isolated. HAM2 tf is pretty clean, it makes me wonder if maybe something is messed up with feedforward on that chamber. Maybe that is something I could (carefully) fix while other troubleshooting for the detector is going on.

TITLE: 07/15 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 18mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

Currently in ENGAGE_ASC_FOR_FULL_IFO, which is currently doing okay. Winds have jumped up but look like they're going back down.

Sheila, Keita, Ryan Short, Camilla and TJ

Part way through initial alignment, we stopped and moved SR3 towards the positive yaw spot from 79103, and used the SR2 osem values from that time.  A small manul adjustment of AS_C was needed, otherwise initial alingment was uneventful.

With DRMI locked, we ran the fast shutter test that Keita and Ryan S have both looked at.

We also looked at the ratios of AS PDs  to compare to   78667, they are most similar to the good times in that alog. After these checks we have decided to try locking.

• as_c/as_a is now 1.22e-5
• as_c/as_b is now 1.17e-5

Sheila, TJ

In times of heavy commissioning or troubleshooting, we want full control of the IFO and don't want to fight the automation. Sheila suggested that we add a manual_control boolean to lscparams.py that ISC_LOCK will look at to decide whether it will automatically run states like Check_Mich_Fringes, PRMI, Increase_Flashes, etc. When this is set to True, it will avoid these automated state either through a conditional in a state's logic, or by weighting edges to force ISC_LOCK to avoid particular states.

For now we are setting manual_control = True while we troubleshoot the IFO.  We will need to remember to return it when we want fully automatic operation again.

Pre April 18

• Camera offsets made : 77139 : April 12
• Unknown issues began with FC IR unlocking : 77164 : April 14
  • Solved : high winds : April 16
• Wind induced lockloss : 77192 : April 15
  • Audible creak in Control Room
  • 5.9 EQ in S. Korea inbound
• Windy making lock difficult : 77188 : April 16
• Squeezing having lock issues 77219 : April 16
• Lockloss - IX saturation : 77224 : April 16 16:41
• Lockloss - reason unknown : 77233 : April 16
• Nominal SQZ angle changes lock-to-lock : 77238 : April 17
• Feedforward and squeezing problem solving

April 18

• Lockloss, unkown cause, Apr 18 01:02 UTC : 77275
• USGS reports 4.3 in Gulf of Cal Apr 18 04:22:45 UTC
• Lockloss, Apr 18 04:46
• USGS reports 5.1 off CDN coast Apr 18, 06:06:04 UTC
• Lockloss from EQ @ Apr 18 06:11UTC : 77259
• USGS reports 4.3 off CDN coast Apr 18, 06:41:45 UTC
• USGS reports 5.2 in Gulf of Cal Apr 18 07:39:39 UTC
• Still aligning : EQ 5.3 from Mexico April 18, 2024 07:39:45UTC : 77261
• USGS reports 4.1 off CDN coast Apr 18, 08:40:12
• USGS reports 3.5 off west coast of Cal Apr 18, 09:33
• USGS reports 4.2 in Gulf of Cal Apr 18, 11:14:04
• USGS reports 2.7 in N Cal Apr 18, 11:28
• USGS reports 2.6 in N Cal Apr 18, 13:21
• USGS reports 5.6 in Gulf of Cal Apr 18, 15:12:30
• USGS reports 3.6 in W Wyom Apr 18, 15:15
• USGS reports 4.3 in S Cal Apr 18, 19:19

Post April 18

• Locked and observing for 36 min : 77280
• Locked for >8.5 hrs : 77281 : April 19, 08:02
• Back to FF and SQZ troubleshooting
• Lockloss, errant gain change at 21:56 : 77283
• Locked for ~4 hours at Apr 19 20:02
• USGS reports 2.9 N of Badger Mt Community Park : Apr 20 04:18:57
  • Stayed locked : 77299 : Apr 20, 00:00
• Lockloss Apr 2024, 15:23 : 77301
• Lockloss at Apr 20, 22:25
• 2 relocks : Apr 21 23:58 (windy)
• Lockloss 26 min after mid-shift entry : 77318
  • Claim - 5.4 EQ from Mexico at 13:43 cause lockloss
  • USGS reports a 5.4 EQ from 19:05 or a 4.4 EQ at 07:28
  • I am probably getting time zones mixed up

• Locked and observing for 36 min : 77280
• Locked for >8.5 hrs : 77281 : April 19, 08:02
• Back to FF and SQZ troubleshooting
• Lockloss, errant gain change at 21:56 : 77283
• Locked for ~4 hours at Apr 19 20:02
• USGS reports 2.9 N of Badger Mt Community Park : Apr 20 04:18:57
  • Stayed locked : 77299 : Apr 20, 00:00
• Lockloss Apr 20, 15:23 : 77301
• Lockloss at Apr 20, 22:25
• 2 relocks : Apr 21 23:58 (windy)
• Lockloss 26 min after mid-shift entry : 77318
  • Claim - 5.4 EQ from Mexico or wind at 13:43 cause lockloss
  • USGS reports a 5.4 EQ from 19:05 or a 4.4 EQ at 07:28
  • I am probably getting time zones mixed up, but these times conflict

Naoki, Sheila, Camilla

To continue investigating alignment changes: 79105. More details in Sheila's 79127.

We put SRM back to before alignment shift, misaligned SRM2 and ITMs,  injected 1.28mW of SQZ SEED beam (as measured on SQZT7 OPO_IR_PD_DC_POWERMON). Followed as in 78115. Increased AS_AIR camera exposure form 10,000 to 100,000

Translated SQZ beam around last NLN spot, each direction the throughput was getting better but in both pitch directions we saturated ZM4 before moving far. Were able to get all expected 0.9mW throughput by moving ZM5 Pitch and yaw both positive.

• In starting alignment ASC-AS_C measured 0.1 to 0.2mW. Same after we centered beam on AS-C.  Time: 2024/07/15 17:52:14 UTC Plot. AS_AIR beam very bad.
• Moving ZM5 Positive YAW (recentering with ZM4 +Y), increased AS_C measured to 0.6mW before it started getting worse. Time: 2024/07/15 18:10:56 UTC Plot
• From this spot (ZM5 Positive YAW) we moved ZM5 Positive PITCH (recentering with ZM4 -P), increased AS_C measured to 0.9mW before it started getting worse Time: 2024/07/15 18:16:33 UTC Plot AS_AIR beam got better.
• We then went back to the original ZM4/5 alignment
• Moving ZM5 Negative YAW (recentering with ZM4 -Y) we were improving but saturating ZM4 before we could finish, AS_C measured to 0.44mW,  Time: 2024/07/15 18:55:00 UTC Plot
• Moving ZM5 Positive PITCH (recentering with ZM4 -P) we were improving but saturating ZM4 before we could finish, AS_C measured to 0.25mW,  Time: 2024/07/15 19:01:57 UTC Plot
• Moving ZM5 Negative PITCH (recentering with ZM4 +P) we were improving but saturating ZM4 before we could finish, AS_C measured to 0.22mW  Time 2024/07/15 19:12:57 UTC Plot
• Note the max we got when not aligned on AS_C was around 0.1mW, maybe caused by edge effects as expect 0.7% reflection off SRM HR surface = 0.7 x 1.28mW  = 0.896mW MAX.

at 08:50 PDT the MSR Atomic Clock lost sync with the timing system, the comparator is reading a steady 0.24S 1PPS difference. This has happened before, it requires a manual resync of the Atomic Clock to the timing-system 1PPS. This was last done 6th May 2024

To help characterize the recent issues we've seen with IFO alignment that are familiar to the output change in late April, I moved SR3 in 10W single-bounce configuration with the SRC2 ASC loop on so that SR2 would follow (ALIGN_IFO's SR2_ALIGN state), much like in alog77694. I moved SR3 far enough in each direction (+/- pitch and yaw) to bring the ASC-AS_C_NSUM signal back up to our target value of 0.022, which I was successful doing in every direction except -Y, where I could only bring AS_C up to 0.018. In the three directions where I was successful, the beam spot on the AS AIR camera looked much more like the clear circle we're used to seeing and less like the upside-down apostrophe we have now.

It seems that our old output spot (starting place in TJ's alog) is still bad (-Y direction with SR3 from current place) since that was the only direction where I couldn't get the AS_C power back up.

Slider values of SR3 after each move:

Attachment 1 is the starting AS AIR camera image (and our current spot), attachment 2 is after the +P move, attachment 3 is after the -P move, and attachment 4 is after the +Y move.

Yesterday, the fast shutter test failed due to dark offsets in the AS WFS DC NSUM channels.

The guardian started running the TwinCAT testing code, which works as intended: it sends a close command to the trigger logic, which in turn fires the fast shutter. The fast shutter works fine as can be seen on the HAM6 geophones. The slow controls readbacks also indicate that both fast shutter and PZT shutter are closed no later than 200ms after the trigger. However 0.5sec after the guardians started the test, it checks the AS WFS DC NSUM outputs and compares them against dark offset limits of ±15. Since the dark offset on WFS B was over 30, the guardian then sent an abort command to the TwinCAT code and reported a failure.

We were only about 2 and half hours into lock when I did this test due to our earthquake lockloss this morning.

I ran the

python auto_darm_offset_step.py

in /ligo/gitcommon/labutils/darm_offset_step

Starting at GPS 1404768828

See attached image.

Analysis to follow.

Returned DARM offset H1:OMC-READOUT_X0_OFFSET to 10.941038 (nominal) at 2024 Jul 11 21:47:58 UTC (GPS 1404769696)

DARM offset moves recorded to 
data/darm_offset_steps_2024_Jul_11_21_33_30_UTC.txt

Ibrahim, Rahul

BOSEM counts have been visibly drifting over the last few days since I centered them last week. Attached are two screenshots:

1. Screenshot 1 shows the 48hr shift of the BOSEM counts as the temperature is varying
2. Screenshot 2 shows the full 8 day drift since I centered the OSEMs.

I think this can easily be explained by Temperature Driven Suspension Sag (TDSS - new acronym?) due to the blades. (Initially, Rahul suggested maybe the P-adjuster was loose and moving but I think the cyclic nature of the 8-day trend disproves this)

I tried to find a way to get the temp in the staging building but Richard said there's no active data being taken so I'll take one of the thermometer/temp sensors available and place it in the cleanroom when I'm in there next, just to have the available data.

On average, the OSEM counts for RT and LF, the vertical facing OSEMs have sagged by about 25 microns. F1, which is above the center of mass, is also seeing a long-term drift. Why?

• Is this because there's an ever-so-slight P instability, so the sag "reveals" it?
• Is it because the blades are differentially sagging
• Is it because (assuming temp. driven DC sag offset), the flag is slowly moving up or down and allowing less light in?

More importantly, how does this validate/invalidate our OSEM results given that some were taken hours after others and that they were centered days before the TFs were taken?

I ran the DARM offset step code starting at:

2024 Jun 13 16:13:20 UTC (GPS 1402330418)

Before recording this time stamp it records the PCAL current line settings and makes sure notches for 2 PCAL frequencies are set in the DARM2 filter bank.

It then puts all the PCAL power into these lines at 410.3 and 255Hz (giving them both a height of 4000 counts), and measures the current DARM offset value.

It then steps the DARM offset and waits for 120s each time.

The script stopped at 2024 Jun 13 16:27:48 UTC (GPS 1402331286).

In the analysis the PCAL lines can be used to calculate how the optical gain changes at each offset.

See the attached traces, where you can see that H1:OMC-READOUT_X0_OFFSET is stepped and the OMC-DCPD_SUM and ASC-AS_C respond to this change.

Watch this space for analysed data.

The script sets all the PCAL settings back to nominal after the test from the record it ook at the start.

The script lives here:

/ligo/gitcommon/labutils/darm_offset_step/auto_darm_offset_step.py

The data lives here:

/ligo/gitcommon/labutils/darm_offset_step/data/darm_offset_steps_2024_Jun_13_16_13_20_UTC.txt

DARM Offset Test:

Test was run without issues and upon checking the PCAL X and Y Excitation screens, the only differences I can see before vs. after are in the OSC_TRAMP Times:

PCALX: OSC TRAMP (sec) OSC1 was 3 and went to 5

PCALY: OSC TRAMP (sec) OSC1-9 were 10 and went to 5.

I reverted these to their before values - everything else is the same (screenshots below).

The previous timing master which was again running out of range on the voltage to the OCXO, see alogs 68000 and  61988, has been retuned using the mechanical adjustment of the OCXO.

Today's readback voltage is at +3.88V. We will keep it running over the next few months to see, if it eventually settles.

Jennie, Jenne, Elenna, Vicky, Erik

As referred to in this entry we took a suite of measurements on the 3rd May to determine what changing the SRCL offset, DARM offset and turning off the whitening on DCPD would have on the sensitivity.

Measurement Order: from 05/03/2023

• Elenna measures contrast defect.
• Measure SCRL1 offset and optimise, see this entry.
• Vicky optimised squeezing.
• Elenna took BB PCAL > DARM measurement.
• Change DARM offset to 40 mA.
• SRCL1 offset measured and optimised.
• Elenna took BB PCAL > DARM measurement.
• DCPD whitening off.
• Elenna took BB PCAL > DARM measurement.
• Change DARM offset back to 20 mA

At low frequencies DARM looks better with 20mA offset, but we must remember that many things at low frequency are optimised for this DARM offset. See first plot for 20mA/40mA comparison.

The whitening ON/OFF (see second plot attached) does not look to have made a large difference to the sensitivity from these plots.

There is no coherence in the PCAL > DARM BB measurements we took at high frequency so to give us a good idea of the difference between 20mA and 40 mA DARM offset we will scale the DARM spectra using the one of the high frequency calibration lines.

Unfortunately, we did not spend any time in NLN with 40mA (just NLN CAL MEAS) so we will need to measure another DARM spectra in that state today.

The code I used to correct the DARM spectra with the PCAL to DARM measurements is in /ligo/home/jennifer.wright/git/DARM_offset

• Run_DARM_calib_20230503.ipynb runs the analysis.
• reference_times/reference_times_pre_O4.yml contains the measurement dictionary.
• Measurement data locations are listed in the table above.
• I used PCal_bb_inj_quick_cal.py by Craig to process the measurements but I had to alter it to use a DTT xml file reader that Erik wrote (reftf.py), as some of the TF measurements referenced in the .xml file were missing their B channels. Note: only an issue if you try to read directly from xml, I could still export the measurements as text files.