TITLE: 01/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 6mph Gusts, 3mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.70 μm/s
QUICK SUMMARY: H1 has been locked and observing for just over an hour.

• Wind is low, microseism higher since yesterday but possibly turning around
• All other systems nominal

1420492969

ETM glitch tag, looks like there was some glitchy behavior from ETMX just before the lock loss.

useism is getting to the point that it might be tough to relock, we shall see.

Sheila, Camilla

After TJ found out OPO was struggling to get enough SHG pump power to lock 82196, Sheila repeated Daniel's 82057 SHG work as he had increased H1:SQZ-SHG_GR_DC_POWERMON from 95 to 125mW but now it's down to 92mW: Tried steering the beam with picos moves, and by adjusting the temperature it improved to 93mW only.

We went only SQZT0 and Sheila adjusted the alignment into the OPO pump fiber with the OPO unlocked, bringing the the OPO REFL DC power from 1.7 to 1.9mW.   We also moved the SHG wave plate further to maximize the amount of light Now CLF could lock with controlmon around 5.8V. Much better and closer to the center of the range so should avoid this mornings 82196 issues.

Homdyne Work:

• Increased SEED power from 0.6 to 70. Subtraction was fine and we adjusted the LO waveplate to balance the LO and SEED powers.
• Measured visibility with the oscilloscope to be (1930-25.6)/(1930+25.6) = 97.4% visibility. No alignment changes needed.
• Found that the issue we saw with the LO unlocking yesterday 82153 was that  the LO loop was unstable, we reduced H1:SQZ-LO_SERVO_IN2GAIN gain, see notes below

To take the below data, SEED power reduced back to 0.6mW, and then:

• NLG measured at (Toggle SQZ/HD path and follow 76542)
• Took SQZ_MANAGER to SQZ_READY_HD (FC2 misaligned) and take data on HD DTT
• Change opo_grTrans_setpoint_uW in sqzparams.py, reload OPO guardian, take it to NO_ISS and then back to LOCKED_CLF_DUAL to check it can reach opo_grTrans_setpoint_uW
• Repeat

We measured ~6.5dB of SQZ on the HD and up to 19dB of ASQZ. Plot attached.

Next time we work on the HD, we should measure the LO loop to know the correct gain to use.

SQZ data set

• Brought opo_grTrans_setpoint_uW back to 80uW, it locked with controlmon at 6. This is now much closer to the center of the range so should avoid this mornings 82196 issues.
• Measured NLG to be: 10.2
• Before starting to take data, paused SQZ_MANAGER, turned off SQZ ASC and SQZ_ANG_ADJUST to DOWN
• FDS data and FIS data all saved to camilla.compton/Documents/sqz/templates/dtt/SQZdata_20250109.xml
• I took 4 minutes of data for FDS, then 3 minutes for FIS but only 2 minutes each for FIS ASQZ +/-10deg as we were running out of time.
• Back to observing reverted the OPO_SERVO_COMEXCEN sdf diff from dither locking, this should be turned off in SQZ_MANAGER, accepted new OPO temp.

All wrapped up, returned to Observing at 2002UTC.

Thu Jan 09 10:03:57 2025 INFO: Fill completed in 3min 55secs

Jordan confirmed a good fill curbside. TCmins [-90C, -88C] OAT (1C, 34F)

Broadband and simulines ran without squeezer today. There was also a small earthquake that started to roll through at 1651UTC during this measurement.

Simulines start:

PST: 2025-01-09 08:36:47.309046 PST
UTC: 2025-01-09 16:36:47.309046 UTC
GPS: 1420475825.309046
 

Simulines end:

PST: 2025-01-09 09:00:29.590371 PST
UTC: 2025-01-09 17:00:29.590371 UTC
GPS: 1420477247.590371
 

Files:

2025-01-09 17:00:29,514 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250109T1
63648Z.hdf5
2025-01-09 17:00:29,524 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_2025
0109T163648Z.hdf5
2025-01-09 17:00:29,528 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_2025
0109T163648Z.hdf5
2025-01-09 17:00:29,535 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_2025
0109T163648Z.hdf5
2025-01-09 17:00:29,541 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_2025
0109T163648Z.hdf5
 

This should conclude at 2000UTC or 12000PT

VACSTAT detected a single BSC3 glitch at 03:18 this morning. This glitch is consistent with sensor noise.

I attempted to restart vacstat_ioc.service on cdsioc0 at 07:44 to reset the glitch, which failed with a leap-seconds error.

I updated the tzdata package on cdsioc0 and was then able to start vacstat_ioc.service.

After the restart, I disabled PT110 HAM6 which is currently not running.

TITLE: 01/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 124Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.63 μm/s
QUICK SUMMARY: Locked for 16 hours, useism up slightly from yesterday. The range has been trending down and we've been going in and out of Observing since Tony had to intervene. Looks like something in the squeezer is unlocking. It just unlocked again as I'm typing this up. Investigation ongoing.

TITLE: 01/09 Owl Shift: 0600-1530 UTC (2200-0730 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 6mph Gusts, 4mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.53 μm/s
QUICK SUMMARY:
When I was first woken by the H1, we were in Nominal_Low_Noise, but not observing.
I noticed that the SQZ_MANAGER had an issue.
I was Very much not awake yet, So I just watched SQZ_MANAGER LOG and the SZQ_MAN states and observed the following:
SQZ_MANAGER couldn't get all the way up to FREQ_DEP_SQZ[100] and would hit FC_WAIT_FDS[64] and then drop down to FDS_READY_IFO[50] again.
I then started to read read the error messages we were getting, some beam diverter messages that would flash up quickly.
I then started to read some alog about recent SQZ issues.
I saw this alog from Camilla, which links to Oli's, but I wasn't sure if I was having the same exact issue.

But it did kinda point me in A direction.
I then checked the SQZ_LO_LR and the SQZ_OPO_LR  Guardian nodes & Logs and Init'ed SQZ_LO_LR. This did not solve the issue, but I tried other things from Oli's alog like requesting RESET_SQZ_ASC & RESET SQZ_ANG . I stepped away after hitting init on SQZ_Manager, to wash the sleep from my eyes and it was relocked when I came back. 

TITLE: 01/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Very quiet shift with H1 staying locked the whole shift and one BBH candidate event. H1 has now been locked for almost 7 hours.

• 01:06 - Candidate event S250109f

TITLE: 01/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: One lock loss with an automated relock, and some SQZ tuning on the prior lock. Other than that it was a quiet shift.
LOG:

• 1633-1635 Out of Observing to adjust SQZ OPO temp
• 1808-1812 Out of Observing due to SQZ unlock
• 2130 lock loss
• 2312 Observing                                                                      

TITLE: 01/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 4mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.48 μm/s
QUICK SUMMARY: H1 has been locked for just over an hour.

• Wind is low, microseism just around 90th percentile
• All other systems nominal

For reference here is a link with a summary of somewhat recent status for the LIGO SUS Fiber Puller:  alog #80406

Fiber pulling was on a bit of a hiatus with a busy Fall/Winter of Ops Shifts and travel.  This week, returned to the Fiber Puller lab  to pull as many fibers as possible (have some free days this/next week).  Thought I would note today's work because of some odd behavior.

Yesterday ended up spending most of the time making new Fiber Stock (we were down to 2, and about 12 more were made).  Also packaged up Fiber Cartridge hardware returned from LLO and stored here to get re-Class-B-ed.  Ended the day yesterday (Jan7) pulling 2025's first fiber:  S2500002.  This fiber was totally fine and no issues.

Today, I did some more lab clean-up but then around lunch I worked on pulling another fiber. 

Issue with RESET Position

The first odd occurrence was with the Fiber Puller/Labview app.  When I RESET the system to take a fresh new Fiber Stock, the Fiber Puller/Labview moved the Upper & Lower Stages to a spot where the Upper Stage/Fiber Cartridge Bracket was too "high" wrt the Fixed Lower Bracket---so I was not able to install a new Fiber Stock.  Closing the Labview App, and a couple of "dry pulls" later, I was FINALLY! able to get the system to the correct RESET position.  (not sure what was the issue here!)

Laser Power Looks Low

Now that the Fiber Stock was set to be POLISHED & PULLED, I worked on getting the Fiber Stock Aligned (this is a step unique to our set up here at LHO).  As I put CO2 beam on the Fiber Stock, the first thing I noticed was very dim light on the stock (as seen via both cameras of the Fiber Puller).  This was at a laser power of 55.5% (of the 200W "2018-new" laser installed for the Fiber Puller last summer).  The alignment should not have changed for the system.  I wondered if there were issues with the laser settings.  I notice I had the laser controller at the "ANV" setting---it should be "MANUAL".  But nothing improved the laser power.  

Miraculously, the laser power (as seen with the cameras) returned to what I saw yesterday for S2500002, so I figured it was a glitch and then moved on to a POLISH, but within a few minutes and being mindful of the laser power on the stock on the cameras, once again the laser spot became dim.  But I did nothing and just let the POLISH finish (about 15min).  Fearing there was power-related issue, I decided to run the Pull (takes less than a minute), but at a higher power (75% vs 65% which had been the norm the last few months).  

S2500003 pulled fine and passed.

I thought we were good, but when I set up for S2500004, I noticed more low and variable laser power.  I worked on this fiber later in the afternoon after lunch.  This one started with power which looked good to me (qualitatively), so I continued with set-up.  But in a case of déjà vu, the laser power noticeably dipped in power as seen via the cameras.  For this fiber I decided to continue, but since S2500003 had a "low-ish" violin fundamental freq (~498Hz), I figured I would return to a power of 65% for the Pull (hoping the laser power was hot enough for the pull (and not cool enough to cause the fiber to break during the pull---something which happened with our old and dying 100W laser we replaced in 2024).

Pulled the fiber and it all looked fine, profiled the fiber, and then ran an analysis on the fiber:  it FAILED.

This is fine.  Fibers fail.  Since Aug we have pulled 29 fibers and this was the 5th FAIL we have had. 

This is where I ended the day, but I'm logging this work only for some early suspicions with the laser.  Stay Tuned For More!

WP12271

We investigated the SHV cable connectivity between the Ion Pump Controller at EY and the Ion Pump at Y2-8 checking for faults.  We did not detect any obvious faults, we did detect the prior splice which was installed back in 2016.  We used the Fieldfox in TDR mode with a 1.2 meter launch cable in low pass mode. I have attached scans of these findings:

First photo is a shot from the Controller, there is a large impedance change at 19 meters from the connection point, this is the same location of the splice made in 2016, the repair looks like we would expect a splice to look.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=28847

Second photo is a shot from the Ion Pump back to the end station.  There is a very small bump at 20 meters from the ion pump that is real, but is very very tiny, could be a kinked cable, but not enough to cause issues.

Otherwise, the cable looks fine.  Future testing is warranted.

M. Pirello, G. Moreno, J. Vanosky

Elenna, Camilla

Ran the automatic DARM offset sweep via Elenna's instructions (took <15 minutes):

DARM offset moves recorded to /ligo/gitcommon/labutils/darm_offset_step/data/darm_offset_steps_2024_Oct_21_23_37_44_UTC.txt