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.

As looked at in 79117 and 78399. the OFI's temperature control changes as we power up.

In a nominal lock before this alignment change, VOLTAGEBACK changes 0.0091V and the temperature wobbles 0.0031 degC: plot.

In today's power up at the new alignment, VOLTAGEBACK changes 0.0267V and the temperature wobbles 0.0135 degC: plot. This is 3 to 4.5 times larger than usual and larger than the changes we saw May 28th/29th 78442 power-ups: 0.0458V and 0.0097degC plot.

Note that we don't understand if this is damaging at all but it makes us think that we are closer to clipping the OFI or have the beam spot in a different position in relation to the TEC/thermistor: TEC is on bottom of the OFI TGG holder (OMC side): G1902217 slide 22. Unsure location of thermistor.

FAMIS 27793

I added 200mL to the CO2X chiller, but none to CO2Y. The CO2Y filter needs to be replaced at the next opportunity.

All values updated in the T2200289 sheet.

CS Mains mon trend attached.

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).

AS_A Counts after shuttering yield a ratio of 325 ppm. Find screenshot below. Template for this ndscope is saved under:

/opt/rtcds/userapps/release/sys/h1/templates/ndscope/fastshuttercheck.yaml

This is with the +Y alignment spot in SR3 detailed in alog 79103:

Tue Jul 16 08:07:49 2024 INFO: Fill completed in 7min 45secs

Jordan confirmed a good fill curbside.

Workstations were updated and rebooted.  This was an update to OS packages.  Conda packages were not updated.

TITLE: 07/16 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: 1mph Gusts, 0mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

IFO is attempting to lock based on an SR3 +Y position that Sheila believes may have promise. See alog 79103.

Tuesday Maintenance has been deferred for this week as we work on high priority IFO Locking Issues.

Other:

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

In initial alignment we trigger the length feedback to SRM in SRY.  In the last day I've been setting these thresholds to zero so that we aren't triggering, and this has worked fine many times now.  However, when the alignment is poor and the build ups are too low for the triggers we have been using, the WFS don't work well.  I suspect that we've been using the LSC triggers to make sure the alignment is good enough for the WFS to work. 

We could consider a dither alignment instead of WFS, since the length lock seems very robust.  Or, as a first step let's move the threshold to a check that's run before ASC comes on, rather than preventing length locking of the cavity.

Chris is actively working on refitting our VEA HEPA filters. This required swapping of the fans at the both EX and EY. The swap occurred between 7:10a-7:15a PST.

C. Soike T. Guidry

TITLE: 07/16 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: None
SHIFT SUMMARY: I've put the detector in IDLE for the rest of the night. Sheila and I found that the +Y alignment (from 79103) doesn't seem to be the best (see Sheila's thoughts on this alignment: 79155), and so we decided to try out the +P alignment. We were eventually able to get DRMI to lock with this, but the beamspot on AS_AIR didn't look great(attachment1), and once ASC kicked in we started getting mode hopping(attachment2), with DRMI staying locked. We got through to CHECK_AS_SHUTTERS and ran the fast shutter test and got values for ASC_AS_A_DC_NSUM_OUT_DQ of 3.2k before the shutter closed, and ~1 when the shutter closed. giving 250ppm (attachment6). Unfortuately, we lost lock from CHECK_AS_SHUTTERS a while after and I haven't been able to get DRMI locked since then, but PRMI locks quickly.
LOG:

IFO in +Y alignment (79103)
23:00 Troubleshooting and at ENGAGE_ASC_FOR_FULL_IFO
23:07 Lockloss from DARM_OFFSET
23:21 Lockloss FROM CARM_TO_TR
23:49 Got to DARM_OFFSET (offset at 9e-5)
    - 23:50 Dip in power recycling gain started, Ryan S changed darm offset to 6e-5 and was able to save lock, we continued to sit in DARM_OFFSET
23:58 I took ifo to DOWN and into SR2_ALIGN in ALIGN_IFO guardian
    - Comparing AS_{A,B}_NSUM_OUT_DQ and AS_C_NSUM_OUT_DQ values to those channels' values from second to last initial alignment before last NLN on Friday morning and trying to rase those channels' values to match previous alignment (attachment3). horizontal cursors are placed at the bounds where these channels were during the second to last lock's IA.

04:12 Back to DOWN and tried to get DRMI locked
    - locked PRMI, but doesn't look great after ASC (attachment4)
    - DRMI wouldn't lock for more than a second or two, and it looks Bad (attachment5).
04:38 Went to DOWN, decided to try +P location
    - Went into MANUAL_INITIAL_ALIGNMENT, went to SR2_ALIGN, changed power to 10W, and moved SR2 and SR3 to the locations given in 79135. Then Sheila moved SRM to line up the beams on AS_AIR. We went through SRC alignment and offloaded

IFO in +P alignment (79103)
05:24 To DOWN, started relocking
05:39 DRMI locked itself after 10 minutes of trying
    - Looked weird (attachment1)
    - Lots of SRM saturations while in OFFLOAD_DRMI_ASC
    - After ASC, DRMI started splitting while staying locked (mode hopping) (attachment2)
05:42 CHECK_AS_SHUTTERS ran fast shutter test (attachment6)
    - Value in AS_A before shutter close = 3.2k and after = ~ 1.0 counts; 250 ppm overall for ASC_A - not bad, seems like beam spot is fully blocked
        - Compare to Keita's earlier tests 79141, 79147
06:04 Lockloss from CHECK_AS_SHUTTERS, trying to relock
    - Cannot seem to get DRMI to lock again, but PRMI will lock quickly
    - Cycled thorugh PRMI and MICH and still couldn't get DRMI
07:44 Put detector in IDLE for the night

Oli was searching for a better throughput to AS diodes when I logged in, based on the observation earlier that in the +Y SR3 position from 79103.  As I commented 79153 I think that is explained by poor DRMI build ups.

Because we did have a CARM offset reduction lockloss earlier from the +Y position, I thought we should try a different one, and we opted for -P from 79103. The attached screenshots show the AS camera and slider settings after running SRC alignment, and again after locking PRMI.  The AS camera looks strange in PRMI.  The third screenshot shows the single bounce beam with 10W (after running full initial alignment), it looks clipped on the AS camera. Our conclusion is that there is some clipping or other problem in the -P position, and it isn't a good place to try locking.

Oli has now moved up to the position called positive pitch in 79103, screenshot after running SRC align is attached.

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

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

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.