OPS Eve Shift Start

TITLE: 07/09 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 28mph Gusts, 20mph 3min avg
    Primary useism: 0.11 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

IFO is in PREP_FOR_LOCKING and LOCKING

We just finished doing an initial alignment and are now locking.

Lockloss

Lockloss at 07/09/2025 21:55 UTC after almost 3 hours locked

Lockloss

Lockloss at 07/09/2025 17:39 UTC after 1.5 hours, potentially from an ETMX glitch

Wed CP1 Fill

Wed Jul 09 10:07:36 2025 INFO: Fill completed in 7min 32secs

Gerardo confirmed a good fill curbside.

Kepco Health Checkup

Yesterday I performed a spot check on all Kepco Supplies early to catch any surprises prior to end of maintenance.  I also staged some upgraded Kepcos because we used some spares last week.

Mezzanine:
All supplies, good temperature, good airflow, no oscillations.

EX:
All supplies, good temperature, good airflow, no oscillations.

EY:
All supplies, good temperature, good airflow, no oscillations.

I took time to record the state of both end station supply racks to update D2300167.

Increased CSOFT P Gain from 20.0 to 25.0 again; works...

J. Kissel, O. Patane

We happened to be catching up with the aLOG at the moment (minutes) the IFO began exhibiting "the" 1 Hz oscillation that has an unknown source and yet has troubling the lock acquisition sequence since the vent (and had gotten worse yesterday after maintenance). We found Elenna mentioned increasing the ASC CSOFT P gain from 20.0 to 25.0 helped last night (LHO:85643), so we repeated that gain increase in CSOFT P with a 5 sec ramp (the ISC_LOCK guardian was mid "INJECT_SQUEEZING;" this state is unrelated to this transient oscillation, as the latter takes ~minutes to ring up, but I mention it to inform outsiders that this is occurring relatively late in the sequence).

The gain increase worked again, and seems to have saved this lock stretch. 

We've accepted a gain of 25.0 for the channel H1:ASC-CSOFT_P_GAIN in the h1asc model's OBSERVE.snap, but will leave it to others to programmatically do this in the guardian (or fix the problem "in hardware" by other means.)

Ops Day Shift Start

TITLE: 07/09 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 6mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

Relocking and in ACQUIRE_PRMI. Looks like we've been down for a couple hours and the hours before that that we were up we weren't Observing, even though we were in NLN. Normally, Corey would've been called, but it looks like H1 Manager wasn't set up last night so he didn't get called. Also, the operations mode was set to Observing all night, but thankfully that doesn't affect the summary pages.

OPS Eve Shift Summary

TITLE: 07/09 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 03:01 UTC (1hr 45 min lock)

We spent roughly 2hrs and 40 min in OMC_WHITENING whilst damping violins since they were rung up by TFs that Oli and Jeff took in the morning and afternoon. Violins continue to decrease, reducing by about 1 order of magnitude strain throughout this shift.

Our range is somewhat low but I cannot see that this is due to squeezing since the trace is as low as it is when we are in FDS.

SDFs were accepted and are screenshotted.

LOG:

None

OPS Midshift Update

We just made it to NLN and OBSERVING after roughly 2 hours and 40 minutes of violin mode damping. Violins are still high but going down. 

1 Hz ringing may have been averted by boosting CSOFT P gain

Today we had one lockloss from a growing 1 Hz oscillation. It's hard to tell where it is coming from, but it appears in several ASC signals and the buildups. We have tried several things in the past to avert this problem. Today I tried bumping up the CSOFT P gain to 25. This action seems to be coincident with the oscillation turning around and damping back down. I'm not completely sure it helped, but it's something to try! Before today, it has turned around on its own without intervention. It also doesn't happen every time we lock.

Ops Day Shift End

TITLE: 07/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Attempting to relock and in ENGAGE_ASC_FOR_FULL_IFO. We've had bad luck attempting to relock after maintenance. Last night there were a lot of issues with trying to relock, and once we started relocking after maintenance today, we realized why. Once DRMI ASC turned on, SRC1 started getting pulled away, and we realized that it was because there were offsets in the filter banks that are not supposed to be there. Elenna and gang had noticed that yesterday as well (85593), and had tried to correct it, but appearently there were other places where SRC1 offsets were set and turned on that got missed. We found these today and corrected it. After that we had a lockloss while we were in OMC_WHITENING waiting for violins to damp because of a 1 Hz oscillation (ndscope). We tried relocking and sat in MOVE_SPOTS to try and take some measurements to determine where the oscillation had come from, but we had a lockloss from an earthquake during that time. We then just sat in DOWN for a while and took some measurements to see if we could find the cause of the oscillation, but we just ruled some things out (85639, 85641).
LOG:

14:30 Relocking and in an initial alignment. I put us to IDLE after input align offloaded so we could start maintenance
18:37 Relocking start
    - Initial alignement
        - SRY wouldn't lock, so Elenna touched up SRM
    - Once DRMI ASC turned on, SRC1 started getting pulled away. This was due to offsets in SRC1 being turned on - related to 85593 - lockloss from OFFLOAD_DRMI_ASC
    - Lockloss from OMC_WHITENING due to 1Hz ASC ringup
    - Lockloss from MOVE_SPOTS due to earthquake. We had been sitting in MOVE_SPOTS while running tests to try adn figure out the cause of the oscillation earlier.

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
14:41	FAC	Kim	EX	n	Tech clean	15:56
14:41	FAC	Nellie	quick MY, then EY	n	Tech clean	15:47
14:43	FAC	Randy, Ken	LVEA	n	HAM3 cable tray work	17:30
14:44	FAC	Chris	YARM	n	FAMIS tasks	16:29
15:06	VAC	Janos, Gerardo	EY	n	CP7 troubleshooting	17:09
15:15	EE	Marc	CER, EX, EY	n	Listening for sad fans	17:25
15:15	SUS	Jeff, Oli	CR	n	ITM R0, TMSX, MC2, SR2, FCs, ETMs, PR2 OLTFs	18:29
15:22	VAC	Jordan, Anna	LVEA	n	Swapping pump controller	16:16
15:24	FAC	Eric	EY	n	Checking out tripped chiller pump circuit breaker	15:57
15:27	FAC	Tyler	LVEA, Mids, Ends	n	FAMIS tasks, helping Eric at EY	17:00
15:28	EE	Fil	LVEA	n	Swapping satamps for SR2, ITMs	18:02
16:19	FAC	Mitchell	Mids, EX	n	FAMIS tasks, 3IFO	17:16
16:19	FAC	Kim, Nellie	LVEA	n	Tech clean	17:31
16:30	FAC	Chris	LVEA	n	FAMIS tasks, battery checks	18:07
16:37	PEM	Robert, Leo, Sam, Tooba, Carlos	Roof, LVEA	n	Tour	18:06
16:44	ISC	Jennie, Rahul	OpticsLab	y(local)	ISS array (Jennie out 17:46)	17:49
16:56	FAC	RyanC	EX, EY	n	Checking dust monitors	18:12
17:15	ISC	Keita	OpticsLab	y(local)	ISS inventory	17:49
17:50	ISC	Rahul, Keita	MY, then OpticsLab	n	Grabbing ISS array 3IFO and taking to optics lab	17:58
17:58	ISC	Keita	VacPrep Lab	n	inventory	19:18
17:59		Rahul	OpticsLab	n	Grabbing stuff quickly	18:02
18:00	EPO	Mike + tour	LVEA	n	Tour	18:59
18:08	FAC	Kim, Nellie	HAM Shack	n	Tech clean	18:51
18:29	PEM	Robert	LVEA	n	Hooking up cables for commissioning	18:40
18:30	FAC	RyanC	OpticsLab, VacPrep Lab	n	Checking dust monitors	18:44
18:30	VAC	Gerardo, Jordan	EX	n	Picking up parts	18:55
18:44	EPO	Elenna + Detchar	LVEA	n	Tour	19:05
19:00		Betsy, Fil	LVEA	n	Sweep + grabbing flashlight (Fil out 19:05)	19:07
20:00	FAC	Randy	MY	n	3IFO forklifting	21:19
20:48	ISC	Jennie, Rahul	OpticsLab	y(local)	ISS Array	21:14
22:28	ISC	Keita	VacPrep	n	Inventory	23:35

(some) ITMX M0/R0 OLTFs taken to check for inconsistancies after satamp swap

Troubleshooting the 1 Hz lockloss we had earlier from OMC_WHITENING, there was some thought that it could be related to the ITMs' damping loops after the satamp swaps today. While we were sitting in DOWN recovering from an earthquake, we took the opportunity to take some OLTFs to compare to the measurements we took before the swaps.

These measurements all look pretty similar to before the satamp swap, so we don't think there's anything with the satamps that would be causing this.

ITMX M0
- In HEALTH_CHECK
- Took measurements for L, R, P, Y (note that the new loop suppression for Y is higher by 2 bc the 'before' measurement was taken with the damping gain at -0.5 while this 'after' measurement was taken with the gain at -1)
- Found in /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGM0/Data/2025-07-08_2230_H1SUSITMX_M0_WhiteNoise_{L,R,P,Y}_0p02to50Hz_OpenLoopGainTF.xml r12413

ITMX R0
- In HEALTH_CHECK
- Took measurements for Y
- Found in /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Data/2025-07-08_2250_H1SUSITMX_R0_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml r12414

H1SUSITMY L2DAMP P and R Open Loop Gain TFs

E. Capote, J. Kissel, S.Dwyer

The ~1 Hz ring-up that had been marginally stable and transient is now fully unstable during the lock acquisition sequence as we recover from maintenance. The suspicion is that the change in ITM M0/R0 satamps might have changed the top mass damping loop OLGTF enough to augment the damped plant that's the plant for the never-really-well-designed L2DAMP that takes the L2 (or PUM) OSEMs and feeds back their sensor signal to the reaction chain top mass OSEMs actuators. But also, we've never measured these loops in any substantial form, so we wanted to just see what they were doing.

Attached are the results. Here're the templates:
    /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/
        2025-07-08_2240UTC_H1SUSITMY_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_P.xml
        2025-07-08_2240UTC_H1SUSITMY_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_R.xml

Very little loop gain and only at 3.3 Hz. The loop stability is questionable at that frequency -- for a few averages the suppression (i.e. the gain peaking) looks really sharp around 3.3 Hz. 
T'was really tough to get good coherence; the excitation is pretty well tailored, but it's tough to fight the 1/f^6 suppression of the physical suspension and dirt coupling.
I had to turn OFF the R0 alignment offsets to get this data for pitch. (They were ON for the Roll measurement).

So -- perhaps not the source of the ~1 Hz IFO instability, but boy could this loop use some TLC in order to more effectively achieve its goals...

FYI, we also took ITMX data for these loops as well.
    /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Data
        2025-07-08_2240UTC_H1SUSITMX_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_P.xml
        2025-07-08_2240UTC_H1SUSITMX_R0_WhiteNoise_0p02to50Hz_L2DAMP_OLGTF_R.xml

OMC Scan with SQZ beam yesterday

Naoki, Vicky, Jennie W

 

Naoki followed the directions in to set up the SQZ beam OMC scan.

We had a problem with the DC centering loops. After we switched them on they saturated the OM1 and OM2 suspensions.

We got around this by switching each of the 4 degrees of freedom on first - ie. DC3 Y, DC3 P, DC4 Y, DC4 P.

Then we engaged OMC ASC and this seemed to work ok.

When we tried to manually lock the OMC length loop we had problems as when we switched the gain of 1 on it would lose lock, even when on a TM00 mode of the expected height (0.6mA on DCPD_SUM).

Vicky got around this this using a lower gain and not engaging the BOOST filter in the servo filter bank.

Then she had to touch up the alignment in lock with OM3.

locked quiet time 1397329970 GPS 1 min:

OMC-REFL_A_LF_OUT16 = 0.0930255 mW

OMC-DCPD_SUM_OUTPUT = 0.652156 mA

 

unlocked quiet time 1397330106 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = 1.04825 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

dark measurement 1397330625 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = -0.0133655 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

I noticed after I took the dark measurement that OM1 and 2 were staurating again and need to clear history twice on OM1 to remove this.

Reverted OM1 and 2, 3 OMC sliders at 8:33 am (local time) on the 16th April.

Data is saved as REf 3, 4 and 5 in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_04_16_OMC_scan.xml. Where 3 is the scan channel OMC-DCPD_SUM_OUT_DQ on the bottom right plot, 4 is the PZT excitation channel OMC-PZT2_EXC on the bottom left plot, and 5 is the monitor of the actual PZT output voltage OMC-PZT2_MON_DC_OUT_DQ on the top right plot.