H1 called for help this morning at 6:15 PST when it could not go to observing because of the SQZ system not functioning properly. Eventually I saw that the Slow Controls section of the CDS overview was red, so I called in Dave for assistance. So far we have not found evidence of an actualm hardware failure, but Richard noted that a chiller in the CER had failed this morning, causing temperatures to rapidly rise there, potentially creating this issue with the SQZ Beckhoff terminals. Richard has turned on a fan and both chillers in the CER to bring the temperatures back down.

H1 is back to observing as of 12:58 UTC. I accepted two SDF diffs on EY_ISC (these were accepted by Austin during his shift, so I've essentially undone his accepting).

TITLE: 01/12 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Austin
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTH_QUAKE
    Wind: 23mph Gusts, 20mph 5min avg
    Primary useism: 1.06 μm/s
    Secondary useism: 0.90 μm/s
QUICK SUMMARY:

Austin called and reported on a large nearby earthquake unlocking H1 and tripping ISIs for all four QUADs, BS, HAM7, and HAM8. There was also a typo in the SEI_ENV Guardian which caused it to go into error at this time, but this has been fixed.

Since the earthquake is still shaking, I'll wait until it has fully passed and SEI_ENV goes back to CALM to untip the ISIs, then I'll start an initial alignment and have H1 try to lock. The wind is elevated, but not terrible (20-30mph gusts), so there's potential for that to cause issues.

TITLE: 01/12 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

- EX saturation @ 1:08

- Lockloss @ 5:53 - cause unknown

- Airhandler alert on alarm handler for MY REHEAT channel - looks like there has been a sharp spike over the past hour, Tagging FMCS

- Relocking was mostly straightforward, I did give ETMY a little tap during ALS to get it to catch but locking was otherwise automated

- Back to NLN @ 7:17/OBSERVE @ 7:24

- Following SDFs on ALS Y popped up, preventing me from going into observing, accepting for now for them to be looked at later, Tagging ISC

- Lockloss @ 7:49 - caused by 5.9 EQ from Alaska

• This EQ put the SEI ENV node guardian in ERROR
• The error came from line 87 of SEI ENV.py with the return state having a typo, changed the return function from EARTHQUAKE to EARTH_QUAKE to match the guardian states, saved and hit LOAD which fixed the issue

- Called Ryan S. and let him know of the situation, ground motion is already starting to settle and he intends to untrip the WDs and begin an initial alignment soon after

LOG:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

Lockloss @ 7:49, caused by a 5.9 EQ from Alaska.

Lockloss @ 5:53 - cause unknown. Potentialy see a slight rise in oscillations in the DSOFT YAW loops that starts around ~35 seconds before the lockloss. Looking at the LSC loops, it looks like LSC DARM sees the motion first.

Tonight has been uneventful this far. H1 is going strong, 28 hours into its current lock. Secondary microseism has stabilized at 0.5 um/s, but the wind has been steadily on the rise, now ~30 mph here on site.

TITLE: 01/12 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 26mph Gusts, 20mph 5min avg
    Primary useism: 0.10 μm/s
    Secondary useism: 0.42 μm/s
QUICK SUMMARY:

- H1 still locked, just hit 24 hours and appears to still be stable

- Microseism continues to trend down

- CDS/DMs ok

TITLE: 01/11 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY: Locked for 24 hours, quiet day.
LOG:

• 2128-2130 Travis walking through the FCES
• 2145-2153 Tyler running forklift from staging building to LSB

ENDY Station Measurement:
During the Tuesday maintenace, the PCAL team(Rick Savage & Tony Sanchez) went to ENDY with Working Standard Hanford aka WSH(PS4) and took an End station measurement.

The ENDY Station Measurement was carried out according to this Modified version of the procedure outlined in Document LIGO-T1500062-v15,  Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by 11 am. The modification was just an extra background measurement with the covers on at the very end of the procedure.

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

Martel:
We started by setting up a Martel Voltage source to apply 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. 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, we 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 Transmitter module and the receiver module operation without the WS in the beam path at all.

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

Special Notes: In the pcal_params.py
PCALPARAMS['WHG'] = 0.91536 # 12/05/2023
was changed to:
PCALPARAMS['WHG'] = 0.91616 # 01/10/2024
The updated "Local measurement" value for WHG is the average of two lab measurements taken specifically for the End Station measurement. A "FrontBack"(PS4 on the Front track) and a "BackFront" (PS4 on the Back track) of PS4_PS5 Responsivity ratios. They were measured on the day of the end station measurement Jan 9th 2024. This pcal_params.py  For future reference, changing this number multiplys the entire series of measurements for the entire run by the new number.

The above change might have a slight impact on the RxPD calibration reported in LHO_EndY_PD_ReportV2.pdf.

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

LAB Measurements Notes:
The PCAL Team has made a proceedural change that now requires the lab results to be processed before the End station results to allow for what we are now calling a "Local in time measurement" of the integrating sphere ratios.
The calculation I used to get this "Local measurement" is:
(BackFront_mean + FrontBack_mean)/2 . It's literally just an average of the last two lab measurements in "BF FB pairs".
This is the first time we have tried this change, but it allows us to treat these measurements more like a metrology shop would.
This is the number we measured today, thus we will use this number today baring any data aquisition or quality issues which will be addressed as they arrive.

BackFront configuration PS4/PS5 Responsivity Ratio.
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)BF 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.
BFraw_voltages.pdf
BFavg_voltages.pdf
BFraw_ratios.pdf
BFavg_ratios.pdf The mean on the bottom of this plot is where I got the BF number to use for the Local measurement.

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_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf The mean on the bottom of this plot is where I got the FB number to use for the Local measurement.
alphatrends.pdf shows the history and temperature correction of the lab measurements.

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

Special Note: I had to retake a lab measurement due to one of the background data files for the FrontBack PS4_PS5 measurement only having one entry of non-zero data, seems like labview failed to properly communicate with the Keithley after the first background voltage value was read. I have since retaken that measurement on the 10th.

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

I discovered this morning that my new HWS camera control code, which only talks to the camera when it needs to turn the camera on or off, was locking up in its caget of the IFO lock status. The last change was for the lock status function to return both the caget call status and the ifo_lock_state.

I reverted the code back to the previous version, and it is now running correctly on h1hwsex, h1hwsey and h1hwsmsr1 but for an unknown reason is still locking up on caget on h1hwsmsr. When I run the caget command on h1hwsmsr's command line it works. Investigation is continuing.

Note due to this bug HWS ITMX camera was mistakingly left ON overnight until I manually turned it OFF at 08:33 PST this morning.

TJ, Jonathan, Erik, Dave:

yesterday the camera client flashing-blue-screen for cameras whose servers are running on h1digivideo1 steadily got worse as time progressed. This was seen before on 21 Nov 2023, at that time reseating the ethernet cable which connects h1digivideo1 to the cameras fixed it.

We tried, with no success, the following:

• reboot h1digivideo1
• reseat the ethernet cable
• replace the ethernet cable
• move the ethernet cable to a different port on the switch (sw-msr-h1aux 1/1/16 -> 1/1/34)

In all cases the switch port utilization went close to 50%, packets were dropped and camera-clients flashed blue-screen

We then stopped the server processes of three cameras which were not being used often in the control room and were not on any FOM. The port utilization dropped to 36% (still higher than h1digivideo0 (28%) and h1digivideo2 (20%)) but it resolved the flashing.

Current status:

h1digivideo1 eth1 ethernet is temporarily connected to sw-msr-h1aux port 34. Should put this back to port 16.

h1digivideo1 monit is not running the camera service for three cameras:

1. cam17: SRM
2. cam18: SQZ SHG TRANS
3. cam20: SQZ IR TRANS

Thu Jan 11 10:15:36 2024 INFO: Fill completed in 15min 32secs

TITLE: 01/11 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 18mph Gusts, 13mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.40 μm/s
QUICK SUMMARY: Locked for 16 hours. useism still trending down, but the time is picking back up a bit.

TITLE: 01/11 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

- EX saturations @ 1:21/3:32/4:35/4:46

- Quiet night otherwise, H1 has just reached an 8 hour lock

- Secondary microseism continues its steady decline, now just above 0.5 um/s velocity
LOG:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

Uneventful night so far other than a couple glitches. The detector appears stable, microseism is still above the 95th percentile but is beginning to trend down.

We've been seeing SQZ angle not optimizing correctly (75245, 75151). At 20:05 Ibrahim took us into commissioning and I tried to change ADF frequency H1:SQZ-ADF_VCXO_FREQ_SET from 1300Hz to 200Hz. The ADF line didn't move from the 1300Hz region, just became noisy when I changed it. PLL didn't lock. Unsure why the ADF wouldn't move, I also tried 800Hz to no avail.  ADF frequency hasn't successfully been changed since Daniel adjusted the model in May 69453.