Thinking about our difficulties locking over the weekend (alog 72493), and the commissioining time on Friday where a new boost filter was tried (alog 72435), I checked which DARM filters are on in which states. 

The summary is that indeed, FM8 of the DARM2 filter bank is not used during initial alignment or locking, so having it prepared and in place is not a cause of our troubles this weekend. 

I attach my somewhat messy notes file, just in case it's useful later, with times, ISC_LOCK state, DARM1_SWSTAT, DARM2_SWSTAT, and translations to what those swstats mean.  But, no need to look at the file unless you're in the mood for a deep dive into the process.

FAMIS#23738 (not closing due to PSL check not having been done yet)

Previous check: 68779

**PSL Anteroom and Laser Room will be done at a later date when going in there is required for other tasks.

WP 11398.

I updated the pylon-camera-server code on h1digivideo3 to 0.1.10. This version adds an attempt at a fix for the "memory leak" and an EPICS channel to indicate if the current frame is saturated: {channel_prefix}SATURATED: 1 if and only if the maximum pixel value of the frame is greater than or equal to the pixel dynamic range. (read only)

Currently monitoring H1:CDS-MONITOR_H1DIGIVIDEO3_MEMORY_AVAIL_PERCENT to see if it improves the "memory leak".

Tue Aug 29 10:08:53 2023 INFO: Fill completed in 8min 48secs

FAMIS 25954

The script reports ITMX_ST2 H1 & H3 high freq noise is high, but they look reasonable to me. All others look OK.
 

Here's fours examples in the last few months of our dust counts in the PSL increasing with the direction of the wind, and three examples of similar wind speeds at a different direction with no increase in dust counts. It looks like if the wind is coming from the ~80deg mark, according to our CS weather station, then our dust counts will start to show up with average wind speeds around 15mph.

bypass will expire:
Tue 29 Aug 2023 09:02:01 PM PDT
For channel(s):
    H0:FMC-EY_CY_H2O_PUMPSTAT
 

Last night at 0827 UTC we dropped out of Observing fir just over a minute while TCSX relocked. This is a known issue (see alog72220 for a quick reference), but I wanted to keep record here in the alog.

TITLE: 08/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

• VAC/SEI/CDS looks good, PLS anteroom dust alarm
• 14:08 lock time
• The charge measurement is finishing up

TITLE: 08/28 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

- Arrived to a relocking IFO, just got back to NLN @ 23:15

- Lockloss @ 23:20 - 5 minutes later :), no obvious cause

- Had a few locklosses at FIND IR and noticing the ITM CAM error signals are poor for both arms, so will be running an initial alignment

• Had to move SRM a bit in P to catch SRC but otherwise the IA was entirely automated

- 23:46 UTC - had a verbal alert for a GRB-Short (E433366) and a STAND DOWN - believe this came from Fermi, as we are currently running an IA

- Back to low noise @ 0:51/OBSERVE @ 1:56

• Vicky mentioned an issue with the SQZ sensing matrix (alog for more info), so she and Naoki are going to troubleshoot while LLO is down and currently relocking (in COMMISIONING mode from 1:11 - 1:56 UTC, we went back to observing once LLO was relocked and had flipped their intention bit)

- 4:54 - inc 5.9 EQ from Indonesia

• 5:14 - another EQ...this one is a 5.4 from Panama
• 5:27 - EQ mode activated, back to CALM @ 5:37

- Overall a quiet night, leaving H1 to TJ in managed mode

LOG:

No log for this shift.

Naoki, Vicky

After alog72496, we turned on the SQZ ASC, but the ANG P/Y ran away for the first 10 minutes as already reported in alog71217. We remeasured the SQZ ASC sensing matrix and decided the input matrix as shown in the first and second attached figures (first: old, second: new). However, the behavior of ANG P/Y with new input matrix is similar to before (third attached figure). The ANG P/Y ran away and SQZ BLRMS got worse for the first 10 minutes and started to converge after that.

H1 has been locked for just over 2 hours. IFO appears to be behaving nominally, and ground motion looks to have recovered from the 7.1 EQ earlier today.

Naoki, Vicky

At 25W, holding at REDUCE_RF45_MODULATION_DEPTH before MAX_POWER, we did a quick anti-sqz/sqz measurement to see if we could loosely infer sqz losses with the IFO relatively cold. We did not see clearly more squeezing here at lower power / colder ifo, as we have in the past, e.g. 66877. We weren't able to easily engage ASC here (it was before move_spots), but slider values are similar to when IFO was last locked and a little bit of walking alignment didn't make a big difference, so we left ASC off.

Looking at DARM (based on GDS), and the SQZ BLRMS, we can read the sqz levels:

• Anti-sqz:  DARM ~ +13.0 dB,   BLRMS 5,6~ 13 dB
• SQZ:     DARM ~ -3.9 dB,     BLRMS 5,6~ -4 dB

which are surprisingly consistent to what we have at full power, e.g. the recent sqz dataset in 71902 with IFO at 60W and thermalized in full lock.

Thoughts:
  -- I'm not sure what it means that now we have similar amounts of squeezing with the IFO at low and high power.
  -- For this test, we left PSAMS at 200V/200V and didn't try walking PSAMS, though in 66877 we saw better squeezing with a cold IFO and lower PSAMS.
  -- The slope of DARM at high ~kHz frequencies seems to be slightly different between 25W and 60W? From the dtt, compare red dashed = "60W no sqz" & cyan line = "25W FDS". Here, the lock sequence was at REDUCE_RF45_MODULATION_DEPTH, so before lownoise length control and laser noise suppression.

We then measured NLG ~ 11.05. In the sqz dataset 71902 we did not separately measure NLG, but given that the NLG has remained consistently accurate with the Feb 2023 NLG calibration, so we can re-affirm that trusting the calibration is probably okay, assuming opo temperature is well-tuned. For comparison, NLG calibration suggests NLG=11 (gen sqz ~ 14.75dB) with opo_trans=80uW.

• max_ir = 0.0081
• min_ir = 0.00022
• no_pump_ir = 7.1e-4
• dark = -2.5e-5

TITLE: 08/28 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY:
Quiet shift until the noisy earth rolled a Mag7.1 Earthquake to H1.  Made it back to Low Noise (but then it just lost lock).

(Jim discovered LVEA lights were on...probably had been for several days!)

LOG:

• 1500 Vacuuming (w/ Shopvac) in Mechanical Room (to vacuum water out of an air handler drain pan)
• 1506 H1 back to Observing (after 1152 lockloss)
• 1548-1622 Optics Lab cleaning (karen)
• 1659-1931 MX cleaning (cindi)
• 1934 Hanford automated message received about siren testing around ~1pm PT/local time.
• 2002:  M7.1 EQ from indonesia verbal warning
  • 2016 Lockloss around when S-wave passed
• 2040-2052 HAM1 guardian for in-air L4Cs (jim)
• 2052-2113 Installing a new in-air L4C under HAM1 (jim)
  • Lights were left ON in lvea!  (probably since Wed or Tues)
  • Jim did a walk through the LVEA to make sure no one else was out there and then turned OFF the lights in the LVEA & CER (which were also left ON)
• 2101-2108 Grabbing wipes in Cleaning Area (travis)
• 2130 Begin locking post-EQ
  • LOCK#1:
    • X&Y green needed INCREASE FLASHES (did not need to deal with ALSy WFS like Austin had to)
    • took to PRMI & locked (after small BS pitch adjustments)
    • But DRMI did not lock (even with good flashes), so returned to PRMI.
    • DRMI locked on 2nd attempt within 4min!  Woo Woo!  
    • Held at REDUCE RF45 MODULATION DEPTH, so Vicky & Naoki could do Squeezer work in the control room.
    • Handing off to Austin.

First ENDX Station Measurement:
During the Tuesday maintenace, the PCAL team( Rick Savage & Tony Sanchez) went to ENDX with Working Standard Hanford aka WSH(PS4) and took an End station measurement.
But the Upper PCAL BEAM had been move to the left by 5 mm last week. See alog https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=72063.
We liked the idea of doing a calibration measurement with the beam off to the left just to try and see the effects of the offset on the calibration.

Because of limitations of our analysis tool which names files with a date stamp, the folder name for this non nominal measurement is tD20230821 even though it actually took place on Tuesday 2023-08-22.

Beam Spot Picture of the Upper Beam 5 mm to the Left on the apature
Martel_Voltage_Test.png
Document***
WS_at_TX.png
WS_at_RX.png
TX_RX.png
LHO_ENDX_PD_ReportV2.pdf
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_EndX/tD20230821/

We then Moved the PCAL BEAM back to the center, which is its NOMINAL position.
We took pictures of the beam spot.

Second NOMINAL End Station Measurement:
Then we did another ENDX Station measurement as we would normally do which is appropriately documented as tD20230822.
The second ENDX Station Measurement was carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by noon.
We took pictures of the Beam Spot .

Martel:
We started by setting up a Martel Voltage source to apply some voltage into the PCAL Chassis's Input 1 channel and we record the times that a -4.000V, -2.000V and a 0.000V signal was sent to the Chassis. The analysis code that we run after we return uses the GPS times, grabs the data and created the Martel_Voltage_Test.png graph. 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 document .

After the Martel measurement the procedure walks us through the steps required to make a series of plots while the Working Standard(PS4) is in the Transmitter Module. These plots are shown in WS_at_TX.png.

Next steps include: The WS in the Receiver Module, These plots are shown in WS_at_RX.png.

Followed by TX_RX.png which are plots of the Tranmitter module and the receiver module operation without the WS in the beam path at all.

All of this data is then used to generate LHO_ENDX_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.

All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_EndX/tD20230822/

PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)BackFront Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf

All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LabData/PS4_PS5/

I switched the order of the lab Measurements this time to have the Front Back Last this time to see is it changed the relative difference between FB and BF measurements.
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages2.pdf
avg_voltages2.pdf
raw_ratios2.pdf
avg_ratios2.pdf

This adventure has been brought to you by Rick Savage & Tony Sanchez.

J. Kissel, D. Barker

As of today Dave helped me install the new front-end, EPICs controlled oscillators discussed in LHO:71746. Then, after crafting a few new MEDM screens (see comments below), I've turned ON some of those oscillators in order to replace the unstable function of the CAL_AWG_LINES guardian.

So, there're no "new" calibration lines (not since we turned CAL_AWG_LINES back ON last week at 2023-07-25 22:21:15 UTC -- see LHO:71706) -- but they're now driven by front-end, EPICs controlled oscillators rather than by guardian using the python bindings for awg (which was unstable across computer crashes, and other connection interruptions).

This is true as of the first observation segment today: 2023-08-01 22:02 UTC
However, due to a mishap with me misunderstanding the state of the PCALY SDF system (see LHO:71879), I accidentally overwrote the PCALXY comparison line at 284.01 Hz, and we went into observe. Thus, 
The short observation segment between 22:02 - 22:11 UTC is out of nominal configration, because there's no PCALY line contributing to the PCALXY comparison.
 
The was rectified by the second observation segment starting on 2023-08-01 22:16 UTC.

Also, because of these changes the subtraction team should switch their witness channel for the DARM_EXC frequencies to H1:LSC-CAL_LINE_SUM_DQ.
The PCALY witness channel remains the same, H1:CAL-PCALY_EXC_SUM_DQ, as the newly used oscillators sum in to the same channel.
Below, I define which oscillator number is assigned to which frequency.

Here's the latest list of calibration lines:
Freq (Hz)   Actuator                   Purpose                      Channel that defines Freq             Changes Since Last Update (LHO:69736)     
8.825       DARM (via ETMX L1,L2,L3)   Live DARM OLGTFs             H1:LSC-DARMOSC1_OSC_FREQ              Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
8.925       PCALY                      Live Sensing Function        H1:CAL-PCALY_PCALOSC5_OSC_FREQ        Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
11.475      DARM (via ETMX L1,L2,L3)   Live DARM OLGTFs             H1:LSC-DARMOSC2_OSC_FREQ              Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
11.575      PCALY                      Live Sensing Function        H1:CAL-PCALY_PCALOSC6_OSC_FREQ        Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
15.175      DARM (via ETMX L1,L2,L3)   Live DARM OLGTFs             H1:LSC-DARMOSC3_OSC_FREQ              Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
15.275      PCALY                      Live Sensing Function        H1:CAL-PCALY_PCALOSC7_OSC_FREQ        Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
24.400      DARM (via ETMX L1,L2,L3)   Live DARM OLGTFs             H1:LSC-DARMOSC4_OSC_FREQ              Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
24.500      PCALY                      Live Sensing Function        H1:CAL-PCALY_PCALOSC8_OSC_FREQ        Former CAL_AWG_LINE, now driven by FE OSC; THIS aLOG
15.6        ETMX UIM (L1) SUS          \kappa_UIM excitation        H1:SUS-ETMY_L1_CAL_LINE_FREQ          No change
16.4        ETMX PUM (L2) SUS          \kappa_PUM excitation        H1:SUS-ETMY_L2_CAL_LINE_FREQ          No change
17.1        PCALY                      actuator kappa reference     H1:CAL-PCALY_PCALOSC1_OSC_FREQ        No change
17.6        ETMX TST (L3) SUS          \kappa_TST excitation        H1:SUS-ETMY_L3_CAL_LINE_FREQ          No change
33.43       PCALX                      Systematic error lines       H1:CAL-PCALX_PCALOSC4_OSC_FREQ        No change
53.67         |                            |                        H1:CAL-PCALX_PCALOSC5_OSC_FREQ        No change
77.73         |                            |                        H1:CAL-PCALX_PCALOSC6_OSC_FREQ        No change
102.13        |                            |                        H1:CAL-PCALX_PCALOSC7_OSC_FREQ        No change
283.91        V                            V                        H1:CAL-PCALX_PCALOSC8_OSC_FREQ        No change
284.01      PCALY                      PCALXY comparison            H1:CAL-PCALY_PCALOSC4_OSC_FREQ        Off briefly between 2023-08-01 22:02 - 22:11 UTC, back on as of 22:16 UTC
410.3       PCALY                      f_cc and kappa_C             H1:CAL-PCALY_PCALOSC2_OSC_FREQ        No Change
1083.7      PCALY                      f_cc and kappa_C monitor     H1:CAL-PCALY_PCALOSC3_OSC_FREQ        No Change
n*500+1.3   PCALX                      Systematic error lines       H1:CAL-PCALX_PCALOSC1_OSC_FREQ        No Change (n=[2,3,4,5,6,7,8])

Evan Goetz noticed that there is a mismatch between the Pcal injected frequency and "matching" demodulator for PCALY line 4.  This line at 24.5 Hz is in place for temporary monitoring of the thermalization effects on calibration, eg, alog 69478.  I don't think that this is detrimentally affecting our calibration at this time, so I'm not going to call Jeff while he's on vacation.  He can take a look Monday morning to make it more clear which frequency is supposed to be where.

I went through the hardware injection screens (CAL_INJ_CONTROL2, PCAL_END_EXC) and cleaned them up based on the way that we're now handling hardware injections

• The INJ_TRANS guardian node was decommissioned, so references to that node were removed from the screen
• The old status bits that were controlled by the INJ_TRANS node were also removed
• The STATUS indicator bits were fixed to reflect their proper
• removed some inaccurate/misleading indicators in the PCAL_END_EXC screen

I then did some test injections and confirmed that all the status bits were working as expected.  Here's an example of the screen with an active "detchar" injection (as labeled by the H1:CAL-INJ_TINJ_TYPE record):

The H1:CAL-INJ_STATUS bit word (purple indicators) behaved correctly, and reset appropriately when the EXC was stopped.