Following the resync of the atomic clock on Monday, it went out of sync again today starting at 09:53 PDT. This time it is -0.106 Seconds out from GPS.

Previous out-of-syncs this year: 04 May = -0.298 S, 15 July = 0.242 S

To "green up" the corner timing status, I have temporarily increased the comparitor's tolerance from 1uS to 0.999 Seconds.

Jennie, Sheila, Camilla

Before loosing ITM op-lev alignments, we checked that ITMX and ITMY oplevs are within 0.5 of the time we were unlocked before our last good NLN lock on Thursday/Friday, this is good. Plot.

Wed Jul 17 08:08:52 2024 INFO: Fill completed in 8min 49secs

TITLE: 07/17 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 16mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

IFO is in IDLE and CORRECTIVE MAINTENANCE

Prepping for our upcoming HAM 5, 6, 7 vent.

Other:

*H1:PEM-CS_DUST_PSL102     WARNING: dust counts did not change, please investigate

TITLE: 07/17 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: None
SHIFT SUMMARY: Detector in IDLE for the night.
After the discovery while locked that 20% of our power was unaccounted for(79180), Keita wanted to check that the ASC_AS sensors were still reading similar values as they had been before the lock. This ended up taking the entire evening though since the AS_AIR beam spot had dissappeared(attachment1)! We did a lot of trending and eventually were able to figure out what happened and how to get the beam back. With the beamspot back, we went into MANUAL_INITIAL_ALIGNMENT and to SR2_ALIGN in ALIGN_IFO. We got decently good values (attachment2 - cursors are min/max of values in 10W single bounce before this last lock) so our ASC_AS photodiodes are good!

Looking for the beamspot:
TLDR; It looks like a combination of alignment work and HAM5 being taken to DAMPED and ISI_DAMPED_HEPI_OFFLINE changed the AS_AIR beamspot alignment, but we were able to get it back by adjusting the slider values until the SR3 oplev values were back to what they had been previously.
    Part of what happened probably: 
    - Images of the AS_AIR camera are saved every hour in /ligo/data/camera/archive/2024/07/16/. In this attachment3 showing AS_AIR for the last several hours of 07/16, we were Locked and had the beamspot present up to the screenshot at 19:56 UTC, but it was absent* starting the next hour at 20:56 UTC (*Important note: sometimes the beam will be swinging out of view when the image is taken, so maybe it was still there, but a beamspot missing three times in a row is a little unusual). We had a lockloss in between these two times at 20:34 UTC, but that shouldn't have affected the spot on AS_AIR. Attachment4 is looking at LSC_DARM_IN1 vs the ASC-AS_{A,B,C} channels, with the left cursor being the time of the lockloss. 22 minutes after the lockloss, there is a spike seen in all three ASC_AS channels followed by AS_A and AS_C getting noticeably quieter. This is only two minutes before the next AS_AIR image is saved, which is the first one where we can no longer see the beamspot.
        - Keita and I checked the driftmon and sliders for the optics around this time and saw that, to correlate with the work going on at sqzt7, some of the optics were being aligned and misaligned around this time, but it didn't look like any of those would've affected the beam on AS_AIR. Our best guess is that something else we didn't check was changed during that time or them walking around the area was putting the beam in a different spot.
    Actually for sure: 
    - At 23:10 UTC HAM5/6 were taken to DAMPED for HEPI to be locked, and when trending the SR3 oplevs, we found that at this time the oplev values for Y changed by ~1.5urad and P by 0.1urad. Using the sliders, we adjusted the pitch and yaw until the oplev values were back to what they had been before this time, and we got our beamspot back!**
    **This does mean that once HEPI is unlocked, we'll need to adjust SR3 back!**

LOG:

23:00 Detector in IDLE

00:35 Went into MANUAL_INITIAL_ALIGNMENT to SR2_ALIGN to verify that current alignment has same values on AS_{A,B}_DC_NSUM_OUT_DQ and AS_C_SUM_OUT_DQ
    - 10W
    - Opened fast shutter
    - Verified SRM misaligned
    There was no light on AS_AIR, and AS_{A,B,C} channels read 0 (attachment1 - AS_A and AS_C traces are very dim and at 0)
    - Took ALIGN_IFO to DOWN and saw beam swing across AS_AIR, but after settling we are back to black screen
01:10 - 04:07 Trying to find AS_AIR
04:08 Went into MANUAL_INITIAL_ALIGNMENT and TO SR2_ALIGN in ALIGN_IFO to compare current ASC_AS values to previous
04:55 Put detector in IDLE

Ibrahim, Oli, Betsy, Jeff

On July 12, Ibrahim retook the transfer functions for M1 of the BBSS (79083) after adjusting some of the alignment issues that we saw in the July 10th transfer functions (79032). I've compared this latest data set to our dynamical model for the BBSS, attached and at $(sussvn)/BBSS/X1/BS/SAGM1/Results/2024-07-12_1400_tfs/. I've also compared this dataset to both our first measurements back in January (first build of BBSS), as well as our July 10th measurements(rebuild w/ change in wire loop length). Those plots are also attached and can be found in $(sussvn)/BBSS/Common/Results/allbbss_2024/Jan05vJuly10vJuly12_X1SUSBS_M1/.

They are clean and agree very well with the model and our first build measurements. Pitch has a small shift in one of its peaks as well as a new peak right up next to it, but we know this is attributed to the change in wire length that was made during the rebuild. We will work with the dynamical model to make sure that this change in wire length gives us these same peaks in pitch. Everything is committed to svn.

HAM5&6 HEPI's were locked this afternoon in prep for chamber cleaning. Isolation loops are bypassed so the ISI can still be isolated if we want to.

TITLE: 07/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is DOWN and in CORRECTIVE MAINTENANCE

A very dynamic day that I will try to sum up as best as I can. Check alogs 79102, 79164, 79167, 79160, 79178, 79156, their comments and the plethora of alogs about this OFI issue.

Context: IFO has been struggling to lock due to what we think is an OFI issue. The plan today was to test out our movement of SR3 in the +Y direction to see if we can get to NLN to the point of potentially delaying a vent to fix/replace the OFI. Here’s what happened next:

14:30 UTC (Shift Start): Tuesday Maintenance had been canceled, Sheila and I were moving the IFO up in the new SR3 +Y position but losing lock repeatedly at around ENGAGE_ASC_FOR_FULL_IFO. This happened for a few hours. Allowed maintenance activities happened (technical cleaning, HVAC stuff, NORCO delivery).

14:30 - 18:00 UTC: 3 IPA tour groups came in as expected. They went to the LVEA, which disrupted locking activities so we waited a bit until they were out.

18:26 UTC: We finally reach NLN for the first time since Friday. The range is low at around 130 MPc. Tuning, measurement and assessment of the IFO alignment begins. The alignment doesn’t look fantastic but we are NLN.

19:14 to 19:37 UTC: I take a calibration sweep by Sheila’s request since it seems that we are not well calibrated only to find out that simulines is broken and that there is no way to generate the report even for broadband on its own. Calibration team takes a look at this very briefly, confirm that the kappa c is 90% so we’re calibrated enough. Then, we discover a newer, more pressing problem.

~20:00 UTC: Keita and Sheila realize that there is only 80% of the beam power making it to sensors (table comments to alog 79160). This then took priority because it meant that should we lose lock, there could be damage to the IFO in unknown ways, including to the pressure. A quick discussion was had and commissioners agreed to manual over to ADJUST_POWER (20:31 UTC) and then slowly bring the power down until we can safely unlock the IFO. Until..

20:32 UTC: Lockloss. Sheila adjusted the power by only 1W down to 59W and we lost lock immediately. The cause for this is generally unknown but it meant we are now unlocked and need to check quickly for damage. Janos and the Vacuum team were called in to check the pressures for any glitches or spikes and thankfully, everything was okay on that front.

21:00 UTC: LVEA transitioned to LASER HAZARD per WP 11979 for SQZ work primarily.

22:00 UTC: After the SQZ work, a meeting was called to discuss next steps, specifically with respect to venting. IFO has been DOWN since then.
23:00 UTC: Prep is being done to vent, such as activating the purg

LOG:                                                                                                                                                                                                                                                                                                                                 

Naoki, Sheila, Camilla. WP 11979

Using the SQZ (ZM4/5/6) and SRM alignment of our last time in NLN, Naoki added two irises in the IR path of SQT7 so that we can keep store this alignment if we vent. This is the path of the SQZ beam heading to the IFO, reflected off beam divertor, to serve as a reference for the alignment which doesn't have good throughput in HAM5.

• First iris after periscope: location and photo.
• Second iris before trans/HD flipper mirror: location and photo.
• Beam on SQZT7 IR Trans camera: photo.

As noted in alog79128 the beam on AS_C isn’t centered in this alignment, it’s around 0.1-0.3 off center. We moved ZM4 to align to the center of AS_C (noisy as NSUM was 0.15mW), we didn't see a noticeable difference on the irises. 

TITLE: 07/16 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 5min avg
    Primary useism: 0.22 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

Sitting in IDLE, and there's currently a discussion going on about venting

There was another pressure spike in HAM6 volume this morning at ~4:28:35 am PDT. The total rise in pressure in HAM6 is 1.15E-8 Torr. This pressure rise was also seen in BSC2 (PT120B), where the total pressure rise was ~3E-10 Torr. See attached plot. Top channel is BSC2 PT120B gauge, middle plot is HAM6 (PT110) and the bottom is the IFO lock state, where -10 is equal to IDLE, so this does not correlate with any lockloss.

Looking at the RGA on the Output tube, there is a small bump in AMU 28 at the same time as the pressure spike, see 2nd attachment. The blue trace on the bottom plot is AMU28 ion current for each 5ms dwell time scan (0-100), so not a true MID scan. Using PT120B as a quick calibration for the RGA at the time just before the pressure rise (P~8E-9 Torr) , and AMU 2 & 18 ion current (Sum~8E-9 amp). Calibration is ~1 to 1. The AMU28 rise is ~2E-10 Torr. Typical HCs (41, 43, 53, 55, 57) had no significant change and similarly for argon (AMU 40), so this does not seem to be argon instability of the ion pumps.

Ibrahim, Sheila, TJ, Camilla, Naoki

Since the +/- pitch alignments of SR3 from 79103 both seem like they will not work, this morning I ran intial alignment for the +Y spot again.   After running SR2 align (single bounce, 10W), the power on AS_C NSUM was 0.0219 Watts arriving in HAM6, 5% worse than the 0.023W before Friday (79101). Attached are screenshots of the AS air camera and the sliders after running initial alignment.   After PRMI ASC ran, POP18 NORM was 45, POP90 NORM was 48 counts (sliders and camera in PRMI). 

DRMI locked with POP18 NORM of 50 counts, so still with 15% less power than last Thursday.  We have had a number of locklosses trying to get to DC readout.  We saw that again a DARM Offset of 9e-5 causes the ASC to fail and causes a lockloss, so we changed the DARM offset to 6e-5, and made edits to OMC_LOCK to allow it to lock (lowered prominence in FIND_CARRIER to 5, and height to 6, threshold in OMC_LOCKED to 6 instead of 10).

We have been able to lock, with a range of 100Mpc. 

Editing to add a comparison of this lock to last Thursday's lock. 

The single bounce throughput is (0.219/0.023) = 95% of what it was last Thursday.  The optical gain is then expected to be srt(0.95) = 0.97.  Right now kappa C is reporting an optical gain of 0.907, 1 hour in to the thermalization, so significantly worse than expected.  I think think that this is beyond the range of values where kappa c is a good approximation, so we need to run a calibration measurement soon. 

AS_A, AS_B DC, AS_C, and OMC REFL are 86% of what they were last Thursday.  Power recycling gain and arm powers are still thermalizing, but may be a bit low.  OFI PD A (the one in HAM7, measures rejected beam from the TFP on the side of the OFI closer to HAM6), is lower by 5%, Camilla pointed out to me that the power on this diode changes each time that we move ZM4/5/6, so it's not very reliable for comparisons.  OFI PD B, the one in HAM5 that measures the rejected beam from the first polarizer in the OFI, sees more rejected power by 17% than it did on Thursday. 

We opened the AS beam diverter and captured screenshots of the image with the normal exposure of 800 and with the exposure lowered to 50. 

IFO is in NLN and in MAINTENANCE as of 18:26 UTC (52 min lock)

With the +Y position detailed in alog 79164, we were able to achieve NLN.

Taking calibration sweeps right now.

We ran the coherence plot (instructions in LowRangeChecks wiki) for 2024/07/16 18:47 UTC with reported 132MPc, plot attached. See lots of coherence with SRCL, PRCL, MICH so we plan to re-tune these feedforwards. The CHARD coherence <15Hz isn't new but the coherence around 30Hz is, it might be coupling through the LSC loops though.

At the beheast of Jeff, I have revived this script from 2011 written in python2 to generate medm matrixes. Updating seemed pretty straightfoward, I ran a builtin automated conversion to start, "2to3 file.py" (-w if you want it to actually write the changes).

I tested it by running "python3 generate_KisselButton2024.py 10 4 H1:OMC-ADC_INMTRX" and copy pasting the output into a blank .adl which gives me this 10x4 matrix button with a connected display window based on the input channel arg. It needs a minumum of 3 args: #rows #col channel. You can also specify the size of the button/matrix, and the linked related display .adl file(you can put the whole path).

The new script is found at /opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton2024.py, and is svned. I left the old script where it is (the same name minus the 2024).

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

J. Kissel, L. Dartez, F. Llamas

As Louis and I were wracking our brains for all the changes to the IFO that might have impacted the IFO's calibration in 2024 in order to update / maintain T2300297, we realized that Francisco's work -- changing the PCAL "inner beam" spot position of PCALX to explore and validate models of systematic errors the PCAL system -- would potentially impact the measurements that are constantly running on PCALX -- the so-called "roaming lines" which is a really long duration, repeating sweep of the sensing function between 1 and 5 kHz. Because this long-duration sweep relies on nominal low noise data, the speed at which the sweep frequency advances is dependent on the IFO's duty cycle, and is thus irregular; sometimes complete in 6 days, other times taking 10 days or more.

To facilitate this research, I plot the trend of the PCALX Oscillator Frequency that's used to define the sweep frequency over time and overlay Francisco, et. al's PCALX spot moves.

And just so you can join us in our worry -- while Francisco's work (see latest in LHO:78964) is showing 0.03%-level changes in the comparison between PCALX and PCALY at 283.91 and 284.01 Hz respectively (via plots like this), the roaming lines measurement is only PCALX and the sweep is from 1-5 kHz, where it's been known for a long time that PCAL spot position changes of ~5 [mm] at RX, or ~2.5 [mm] scale at the Test Mass, can cause 1-to-10%-level errors in reported displacement values at 3, 4, 5 kHz (largest at highest frequencies) -- see, for example, figures 2.30 through 2.35 in T2300381.

Stay tuned!

This aLOG does not suggest we've done the leg work to quantify that we've seen the a problem, but the start of doing such a study.