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. 

Closes FAMIS#26000, last checked in alog78993

For the HAMs low frequency noise is reduced

For the BSCs the ETMs look different at low frequency, esp ST2__CPSINF_V{1,2,3}

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.

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.