Camilla, TJ, Dave:

On 26jun2025 I started my HWS camera control code on the four HWS machines [h1hwsmsr, h1hwsmsr1, h1hwsex and h1hwsey]. The code disables the HWS cameras when H1 is in observation mode and re-enables them on lock-loss.

Data since that time has shown no clear correlation between HWS camera status and the 2Hz DARM comb. The comb appears to have persisted until the 4th July, at which point it diminished.

Camilla and TJ decided we should try turning off the camera control code and keep the HWS cameras enabled.

Following the 11:43 lock loss this morning (at which point the cameras were enabled by the code) I stopped the camera control python code on all four machines between the times 11:54 and 11:57 PDT. Note that Ctrl-C inside the tmux sessions did not work, I had to "kill -9 " the python processes.

Attached camera control MEDM from 12:03 shows the cam-ctrl agents have stopped, with their GPS times not updating (denoted by purple boxes).

For now I have removed the CCTL (Cam Control) box from the CDS overview, but I am keeping the cam_ctrl_ioc running and the channels remain in the DAQ.

Looking at the measurement of CSOFT from this alog, and also remembering that CSOFT P tends to be highly coherent with DARM from 10-15 Hz, I decided to make some adjustments to the CSOFT P lowpass filter that would both suppress noise around 10 Hz, and also maybe buy back some phase at 1 Hz. I designed a 7 Hz low pass filter with only 40 dB of attentuation. The current lowpass filter design has 60 dB of attenuation, which seems like overkill. I adjusted the low pass to be elliptic, low Q, which gives us back about 5 degrees of phase, but reduces the gain at 10 Hz and above by a factor of 10. I didn't get a chance to try it in lock, but I changed the guardian to engage this filter on the way up to NLN (line 3341 of ISC_LOCK). There will be an SDF diff. The new filter is in FM7, the old filter is in FM9.

Jennie, Rahul

On Tuesday Rahul and I took the measurements for the horizontal coupling in the ISS array currently on the optical table.

The QPD read 9500 e-7 W.

The X position was 5.26 V, the Y position was -4.98 V.

After thinking about this data I realise we need to retake it as we should record the mean value for the DC coupled measurements. This was with a 78V signal applied from the PZT driver and an input dither signal of 2 Vpp at 100Hz on the oscilloscope and I think 150 mA pump current on the laser.

Based on a recent bruco, it appeared that PRCL had relatively high coherence, especially near 100 Hz. I ran an injection today during commissioning to check the coupling. I adjusted the overall PRCL feedforward gain and found a lower coupling when the gain was reduced from 1.3 to 1. As soon as the gain reduced beyond 1, the coupling around 20 Hz started to get worse. I chose to use a new gain of 1, and updated the guardian and SDF. These changes are loaded. I also took a longer measurement of PRCL, on the off chance we want to do another iterative feedforward shaping in the future.

Sheila, Camilla

We ran a couple of squeezing angle scans to check the settings of the ADF servo. 

One thing that we realized is that the ADF Q demod signal is divided by H1:SQZ-ADF_OMC_TRANS_Q_NORM rather than mulitplied which is what we had thought.  We changed the coefficent from 0.18 to 5.8. The first png attachment shows that this transforms the blue ellipse into the orange one.  It would be a bit better if we first adjusted the demod phase to maximize the Q signal, so that the ellipse would be aligned along the axis, and the rescaled version would be more like a circle.  However you can see in the right side plot that this gives us a reasonably linear readback of sqz angle as we change the RF6 demod angle (which is actually cabled up to RF3 phase) about 150 degrees where our best squeezing is.

Camilla turned the servo back on in sqzparams. 

For future reference, a slightly better way to do this would be to move the demod phase to maximize Q, do a scan and set H1:SQZ-ADF_OMC_TRANS_Q_NORM to the ratio (max of Q)/ (max of I).  Then you can do a smaller scan around the point with the best squeezing, and in sqzparams set sqz_ang_adjust_ang to the readback angle that you think is best.

Thu Jul 17 10:07:21 2025 INFO: Fill completed in 7min 17secs

Just some quick directions on how to run a script to get the full 524 kHz DCPD data, and then save it in a useful file format.

The script to save this is in /ligo/home/elenna.capote/OMC_DCPD/H1OMCDPCD_HF.py

Right now it is set to collect data from these two channels (line 62 of the code):

channels = ["H1:OMC-DCPD_A0_OUT", "H1:OMC-DCPD_B0_OUT"]

The amount of time to collect data is set on line 66:

duration = 600  # seconds

To run the code:

> conda activate labutils

> python H1OMCDPCD_HF.py

The files will be saved in /ligo/home/elenna.capote/OMC_DCPD in a new folder labeled with a datetime and "xcorr_data" since I have traditionally used this script to collect data for cross correlation measurements. However, you can change the label on line 71, label="xcorr_data"

The output is a set of 1 second HDF5 frames for each second of data collection (so 600 seconds = 600 files). To put this data into a single .gwf format of the full data length, which can easily be read in with GWPY, use the combine.py script. Copy combine.py into the new directory with the frames and run it. The code generates a file for each OMC DCPD channel at the full rate, and at a decimated 64 kHz rate.

This is a bit odd the way it is set up, but the way this works ensures that even if you have to quit the script early, you don't lose all the data, since it saves each file by the second.

We were locked for over 6.5 hours when the measurements were started.

Simulines start:

PDT: 2025-07-17 08:07:30.859380 PDT
UTC: 2025-07-17 15:07:30.859380 UTC
GPS: 1436800068.859380
 

Simulines end:

PDT: 2025-07-17 08:30:47.210989 PDT
UTC: 2025-07-17 15:30:47.210989 UTC
GPS: 1436801465.210989
 

Files:

2025-07-17 15:30:47,050 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_
SS/DARMOLG_SS_20250717T150731Z.hdf5
2025-07-17 15:30:47,058 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DA
RM_SS/PCALY2DARM_SS_20250717T150731Z.hdf5
2025-07-17 15:30:47,062 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_
L1_SS/SUSETMX_L1_SS_20250717T150731Z.hdf5
2025-07-17 15:30:47,067 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_
L2_SS/SUSETMX_L2_SS_20250717T150731Z.hdf5
2025-07-17 15:30:47,073 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_
L3_SS/SUSETMX_L3_SS_20250717T150731Z.hdf5
 

TITLE: 07/17 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 3mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY: We've been locked for 6.5 hours, range steady around 150Mpc. Looks like the earth has finally calmed down after the large earthquake and aftershocks in Alaska yesterday. Planned calibration and commissioning today (1500-1930UTC).

State of H1: Observing at 154Mpc

Following the power supply replacement at EX earlier tonight, Oli and I were able to recover H1 and run an initial alignment (only ETMX needed some adjustment). Lock acquisition afterwards went without issue and fully automatically and H1 began observing as of 08:16 UTC.

One thing that needed attention after rebooting the EX frontends is a restart of the ALS_XARM Guardian to reinitialize its awg connections; something we've encountered before after frontends are rebooted. I also restarted PEM_MAG_INJ and ESD_EXC_ETMX while I was at it, as I think these are the only nodes that need an awg connection to EX.

TITLE: 07/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Ryan S is currently working to get the detector back up through running an initial alignment after Dave and Fil helped fix the power supply failure at EX (85805).

After getting back up after the earthquake, there were some sdf diffs relating to the Big Red Button:

-  On ISIHAM2/3/4/5 saying that there were filter diffs for ISI-HAM{2,3,4,5}_GS13INF. I called Jim and he let me know that those were because of SPM diffs on each HAMs' ISI_HAM{2,3,4,5} guardian and that all I needed to do was INIT each of the guardians. I did that and they cleared.

- On SEIPROC - Jim fixed those somehow (sdf)

LOG:

23:00UTC Unlocked and waiting for the ground to calm down from the huge earthquake
00:31 Started trying to relock
    - Ran an initial alignment
01:52 NOMINAL_LOW_NOISE
    - Had SDF diffs from ISIHAM2/3/4/5 saying that there were filter diffs for ISI-HAM{2,3,4,5}_GS13INF. I called Jim and he let me know that those were because of SPM diffs on each HAMs' ISI_HAM{2,3,4,5} guardian and that all I needed to do was INIT each of the guardians. I did that and they cleared.
    There were also a few sdf diffs on SEIPROC that Jim fixed somehow
02:16 Observing
    03:49 GRB-Short E581446 - Observing
04:11 Lockloss due to power supply failure
    - ETMX M0/R0 suspension WD tripped
    - ETMX and TMSX OSEMs in FAULT
    - ETMX HWWD tripped (I put SEI_ETMX in ISI_OFFLINE_HEPI_ON beforehand)
    05:02 GRB-Short E581463 - not locked
06:39 Started trying to relock

Lockloss at 2025-07-17 04:11 UTC due to a power issue with ETMX and TMSX. Currently in contact with Dave and Fil is on his way in.

ETMX M0 and R0 watchdogs tripped

ETMX and TMSX OSEMs are in FAULT

ETMX ESD off

ETMX HWWD notified that it would trip soon, so SEI_ETMX was preemptively put into ISI_OFFLINE_HEPI_ON to keep ISI from getting messed up when it trips

TITLE: 07/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY: We've only been at low noise for 20 min, but magnetic injections are running now. Maintenance day today.

Jennie W, Rahul

Yesterday we made some measurements to calibrate the spot size on the QPD as we scan the beam position across it.

We used a connector Fil made us to plug in the OT301 QPD amplifier into a DC power supply after checking it contained voltage regulators that could cope with a voltage between 12 and 19 V ( as the unit says it expects DC supply but the previous one we were using was AC with a 100mA current rating and was getting too hot so we assume that was the incorrect one). We hooked it up at 16V (this draws about 150mA of current). The QPD readout looks normal and does not have any of the strange sawtooth we saw with the original power cable.

We moved the M2MS beam measurement system out of the way of the translation stage.

To calibrate the QPD we need to change the lateral position of the M1 mirror and lens to change the yaw positioning on the QPD and measure the X and Y voltages from the QPD.

We need to check we are centred first. The QPD bullseye readout shows the beam is off a tiny bit in yaw but this was as good as we could get at centering the beam when we moved the QPD. All 8 PDs are reading about 4.6 V so this means the beam is well centred in the array plane.

We measure 11000 counts on the bullseye qpd readout at this M1 position.

I plotted the data from lowest reading on the translation stage to highest and fitted the linear region using Calibrate_QPD.m which is attached.

Data is shown in attached pdf.

The slop of the linear region in V/inch is 112 V/inch. Which means to if the beam moved 8.93 e-3 inches on the QPD in yaw, the yaw readout would change by 1 Volt.