A PCAL EndX Station Measurement was done on 2024-07-02, the PCAL team (Dripta B. & Francisco Llamas.) went to EndX with Working Standard Hanford aka WSH(PS4) and took End station measurements using T1500062-V17 as a guide.

Measurement Log
First thing we did was take a picture of the beam spot before anything is touched!

Martel:
Martel Voltage source applies voltage into the PCAL Chassis's Input 1 channel. We record the GPStimes that a -4.000V, -2.000V and a 0.000V voltage was applied to the Channel. This can be seen in Martel_Voltage_Test.png . We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the above document.

Plots while the Working Standard(PS4) is in the Transmitter Module during Inner beam being blocked, then the outer beam being block, followed by the background measurment: WS_at_TX.png.

The Inner, outer, and background measurement while WS in the Receiver Module: WS_at_RX.png.

Plots of inner, outer, and background measurement while WS sphere is in the RX enclosure with both beams on it and RX with both beams : WS_at_RX_BOTH_BEAMS.png

Then placed the Working Standard (PS4) in the path of the INNER Beam at the TX module.
Then the Working Standard (PS4) in the path of the OUTER Beam at the TX module.
A background measurement.

Took the Working Standard and put it in the RX module to get the INNER Beam.
Then the OUTTER Beam in the RX Module.
And a Background.

We remove the beam block and give the Working Standard Both Inner and Outer Beams at the SAME TIME while it's at the RX module.
We also put the RX sphere back to the RX module and put both beams on it at the same time. Like nominal opperation when the PCAL lines are turned off.
Then we take a background.

The last picture is of the Beam spots after we had finished the measurement.

All of this data and Analysis has been commited to the SVN or GIT:
https://git.ligo.org/Calibration/pcal/-/tree/development/O4/measurements/LHO_EndX/tD20240702?ref_type=heads

This adventure has been brought to you by Dripta B. & Francisco.
This is a late alog due to the updates in the procedure and the trends document.

Today we conducted a brief test on the SUS-EX ESD DAC vs the SUS-EX LD32 DAC, both driving the PEM AA chassis at end X per WP11976.  This testing was cut short due to relocking attempts.  We changed the cable to the PEM output ~1:10pm PST, and replaced the cable back to its original position at ~2:15pm PST.  We are still looking at the results of this testing.

F. Clara, R. McCarthy, M. Pirello, D. Sigg

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

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

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.