(This is Oli)

Once we had been at 60W for two hours, I started a calibratoin measurement. I started with Simulines since yesterday I had gotten a broadband measurment done (84808). A couple minutes into the measurement, we lost lock. The cause is unknown, but I've attached the output for the simulines measurement (txt).

Jennie W, Robert S, Sheila, Camilla, Georgia

We are worried about jitter peaks in DARM and input pointing just now so Camilla and Sheila asked me to look at the PEM accelerometer we have on the main periscope in the PSL.

The first image is a time series of periscope acceleration on the top, lock state in the middle and range on the bottom. The first vertical cursor shows a time when we were locked at NLN before the vent on 1st April, and the second is during a quiet time with no squeezing injected that Camilla and co. were using for squeeze measurements yesterday 4th June. One can see that the rms motion increased from around 670 counts before the vent to around 1200 after the vent.

The second image shows the spectra of the accelerometer on the top left plot, the darm spectra on the bottom left, and the coherence from accelerometer to darm on the top right plot - plotted for both times.

Ref 0 periscope asd now

ref 1 periscope asd pre-vent

ref 2 darm asd pre-vent

ref 3 periscope to darm coherence pre-vent

ref 4 periscope to darm coherence post-vent

ref 5 darm asd post-vent

After looking over these with Robert, he thinks that the jitter is not much higher up to about 200 Hz but noticeably worse between 500 Hz and 1kHz. There have been vacuum pumps attached to HAM1 post-vent, but these would not cause the broadband features we can see in this region and would instead be reponsible for narrow peaks.

He wants to check the air handling in the PSL enclosure to rule this out as a source.

Since the coherence with DARM is not big for these peaks this will not be causing our jitter problems currently.

Georgia, Sheila, Camilla

PRMI ASC feedback on PRM hasn't been successfully used since the vent. The operators have been by hand touching up PRM.

We looked at this data for PIT (attached today plot) and YAW (attached yesterday plot). Using the same sensor, REFL_A_RF9_I, is fine, zero crossings of signals are good. The YAW sign is wrong. Have changed the gain in ISC_DRMI.py  for ASC-PRC1_Y_GAIN from -0.1 to +0.1 and reloaded. It will get set back to zero by the guardian so shouldn't effect anything else.

This is untested and left off: to test you would need to change line155 of /isc/h1/guardian/lscparams.py to set PRMI ASC to True.

Jonathan, Georgia, Dave:

The DARM FOM on nuc30 stopped updating. After verifying there had been no recent network disconnection, I tried restarting the DARM with no success. I then failsafed back to the CDS only XML (no reference spectra from DMT) and this started running.

Jonathan found there was indeed a DMT issue, starting around 11:50 this morning. He is investigating. In the mean time Georgia says the local DARM is sufficient.

Jordan, Gerardo, Travis, Marc, Fil, Janos - WP 12591

Today, starting at 8:00 am Gerardo and Jordan leak checked the HAM1 annulus system, by connecting a leak checker to the annulus pumping turbo, and of course valving out / switching off the annulus IPs. At first, the all-metal parts of the system have been checked, mostly on top of HAM1. Those were found OK. Then, the Y- door was checked with sniffing He in the leak checking grooves, then after a few seconds flushing it with Nitrogen. Y- door was found OK, too. Then, the Y+ door was checked with the same method, and the bottom half of it showed huge leaks. Therefore, the chamber needs to be re-vented, most likely the O-rings replaced, and the door reinstalled. This will take place tomorrow (06-06).

In the meantime, IP3 was diagnosed, and troubleshooted. Travis and myself swapped the 2 HV cables on the Ion pump, and the same half of the pump remained functional, which indicated that there is a cable failure (together with the consequences of aLog 84761). So we pulled in a legacy H2 (former IP7) cable, and tested, but without success.
Then Marc and Fil jumped in, and after a while we figured that in the MER we plugged the wrong cable in the controller, due to wrong cable labeling. In the end, Marc and myself went back into the LVEA, made sure that the LVEA-end of the currently plugged cable is indeed not connected, then we searched for the appropriate cable-end in the MER, plugged it in to the controller, and so now the IP is working again. The only last thing remaining is to valve it back in to the main volume.

Sheila and Elenna noticed strange behavior with the ALIGN_IFO node early this afternoon where they were doing the 'OFFLOAD_PRC_ALIGN' state and mistakenly requested 'DOWN' and 'INIT' before the offloading was finished, and the Guardian jumped mid-offload, leaving things in a weird state.

This is not ideal, as the offloading states in this node are meant to be "protected" (redirect=False) and the Guardian should not leave these states unless they return True, even with a redirect request. I've highlighted in the Guardian log below that the initial requests for the 'PRX_LOCKED' and 'DOWN' states were correctly ignored, but a request for 'INIT' prompts an "INIT redirect," which then waits for one second for worker completion, which finishes, then terminates the worker. This restarts the code, which starts the node at 'INIT.'

Is INIT a special state which overrides a protected state? Why did the worker crash in this case? These are questions still under investigation.

Since we slowly stepped through the LOWNOISE ASC state yesterday, I was able to plot ASDs of the DHARD P error signal and determine what exactly creates the 1 Hz peak. My hypothesis was it was something from the damping loops, but I was wrong! The peak appears after we engage the low bandwidth DHARD P controller. I will take a look at the loop design and adjust to reduce this peak. My guess right now is some gain peaking is present at 1 Hz.

Attachment shows the sepctrum of the error signal during the state. If you are looking at the calibration lines in DHARD P and getting worried- this was before we fixed the A2L gains, and in full lock low noise there are no cal lines present in either DHARD P or Y.

It looks like the ITMX green camera is poorly centered.  We should repoint this soon, as we are using it for green alingment.

Ibrahim, Sheila, Elenna

We were having trouble in the "FIND IR" state, ans Sheila realized that it was due to the guardian thinking the x-arm alignment was poor. However, X arm had locked fine and Ibrahim had run the initial alignment. We asked Ibrahim to run it again, and noticed that it continued to lock the X arm green with a transmission of 0.6 (when it should be like 1). However, the convergence of the WFS and camera signals did not improve the arm alignment.

We saw that the COMM beatnote was also low, so I trended PR3 osems. The OSEMs show a few microradian movement in pitch and no movement in yaw. I tried moving PR3 pitch in the "right" direction according to the osems, but it only made the beatnote worse. Same moving in the opposite direction. Based on the ALS X camera, it looked like the beam was off in yaw, so I instead moved PR3 in yaw, which returned the beatnote to a good place and increased the X arm transmission to >1. So, we are baffled, but we trust our current table alignment so we are going to go with this PR3 placement. Overall, this is a 2 microradian movement in PR3 yaw to regain the beatnote/ALS X transmission.

The y cursor on the top plot shows the pitch position of PR3 two weeks ago when we originally aligned the table. There was not a significant change in PR3 yaw in the osem.

In light of 84770 and 84811, I've taken BR0604 out of the MICH LSC loop.  This filter was added to try to address a line in DARM, but didn't ulitmately help with that line, 78205. 

The filter is costing us 50 degrees of phase at 16.9 Hz, where this loop has been ringing. 

This morning the DRMI problem wasn't happening, it seems to be happening in the evenings lately. 

Thu Jun 05 10:09:05 2025 INFO: Fill completed in 9min 2secs

FAMIS H1 ISI CPS Sensor Noise Spectra Check - Weekly 26045
This CPS noise check doesn't include HAM1 yet.

 

TITLE: 06/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

IFO is in DOWN and PLANNED ENGINEERING

This morning we have vacuum going into the LVEA to find out which annulus on the HAM1 doors is leaking (WP 12591). TJ is transitioning LVEA to laser safe for this (WP 12590). Commissioning will then resume.

TITLE: 06/05 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Just put the IFO in DOWN for the night after losing lock from ENGAGE_ASC_FOR_FULL_IFO. I was having trouble all evening getting DRMI to stay locked - we kept losing lock from the 16.2 Hz oscillation that Craig and Elenna had found yesterday (84769). I have no idea why it's only been appearing in the evenings - yesterday evening we had these issues, then this morning no issues at all, and then this evening issues again!! I would lose lock from it anytime after ENGAGE_DRMI_ASC, but even just in DRMI_LOCKED_PREP_ASC, the oscillation was there, just not ringing up.

One of the times I was able to get DRMI to lock, I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements. Later on, Sheila called and figured out it must be due to the MICH gain being too high, so I lowered MICH2 gain, originally at 1, by 30% to 0.7. After doing that, the 16 Hz oscillation went away (diaggui) and we were able to get through DRMI. Sheila said we probably needed that gain back to 1 for DRMI_TO_POP, so I paused at RESONANCE, reset the MICH2 gain to 1, and then continued. We lost lock during ENGAGE_ASC_FOR_FULL_IFO.

So the MICH2 gain is currently at its original gain of 1.

Evening task progress for today:

• SRCL offset check FDS + range DONE
• Try new LSC FF DONE 84807
• Run CAL sweep PARTIALLY DONE 84808
• Close ISS 2nd loop
• Try LASER_NOISE_SUPPRESSION
• OMC alignment offsets
• IMC injection (overnight) IN PROG RUNNING SOOOOON

LOG:

23:30 Sitting in NOMINAL_LOW_NOISE while tests are being run
00:32 Started BB calibration measurement
00:37 BB measurement done
00:38 Lockloss due to earthquake
    - started a manual initial alignment
        - tried to leave SCAN_ALIGNMENT for UNLOCKED and got a Guardian node error about the time being in the past - had to manual before reloading to get out of it (txt)
    - After the initial alignment was done, I relocked SRY and left it there for a while while Vicky and Kevin worked on SQZ stuff
    02:24 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation (84769)
    02:37 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
        - I paused in DRMI_LOCKED_PREP_ASC and adjusted SRM to make POP look better, then went into ENGAGED_DRMI_ASC. We had an oscillatoni start, but we were able to survive it. Then I went into TURN_ON_BS_STAGE2 and we immediately lost lock
    03:24 Lockloss from ACQUIRE_DRMI_1F while trying to acquire. We had gotten it earlier and I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements, but we lost DRMI when I aborted the SRCL measurement and we weren't able to grab it again
    03:40 Lockloss from ACQUIRE_DRMI_1F
    - Ran another initial alignment
    04:20 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
    04:31 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation
    - Sheila called, I lowered MICH2 gain (originally at 1) by 30% to 0.7, then the 16 Hz oscillation went away and we were able to get through DRMI
    - Paused at RESONANCE, reset the MICH2 gain to 1, and then continued
    04:58 Lockloss from ENGAGE_ASC_FOR_FULL_IFO

I was only able to take the broadband measurement due to an earthquake that knocked us out of lock a minute later. We had been at full power for around 5 hours at the time this measurement was run. Unfortunately since we weren't able to take the Simulines measurements, I am not able to run the report.

Broadband:

Start time: 1433118749 (2025-06-05 00:32:11 UTC)

End time: 1433093874 (2025-06-05 00:37:36 UTC)

Data found in: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250605T003226Z.xml

M. Todd, C. Cahillane, G. Mansell

We're curious if any of the IMC WFS channels (DC and RF) are seeing some of the peaks we witness in DARM. Most of the sensors seem dominated by phase noise due to being in air; IMC-TRANS seems the best witness. Not sure if there is anything meaningfull from these, indicating coherence with the DARM peaks.

List of Figures: references are from March 12th, 2025 -- lives are from June 4th, 2025

1. IMC REFL and TRANS PSD estimate comparison before (March 12, 2025) and after vent (June 4, 2025)
2. IMC WFS A/B DC/RF-I PITCH
3. IMC WFS A/B DC/RF-I YAW

The template to measure these again is found at /ligo/home/matthewrichard.todd/Templates/imc/imc_wfs_comparison.xml

Oli, Georgia, Elenna

While we were taking care of several LSC items, Georgia pointed out that we are seeing the 0.8 Hz buzzing in INP1 yaw again, and to a lesser degree CHARD Y. While we did several useless things to debug, I noticed that the DC centering loops were also buzzing with the same frequency oscillation. I decided to try changing the DC centering loop gain (since I had raised the loop gain significantly last week), and noticed that NONE of the DC6 pitch or yaw filters were engaged, but a gain of 1 was engaged, essentially feeding the input signal right back to PM1. Bad!!

Searchingh DC6 in the guardian shows that in PREP_ASC_FOR_FULL_IFO, I found these lines of code:

Not good! Since the gain of DC6 is set on, this effectively keeps the gain on but turns off all the filters and just feeds back the pure error signal to the suspension.

I commented those lines out of the guardian and loaded, and then reengaged all the proper filters. A large 28 Hz line that had been present in DARM disappeared at this point, likely because the DC centering loops require a 28 Hz notch to avoid some suspension mode.

After this, I then tried turning down the DC1 and DC2 pitch and yaw gains to -1. This seemed to help the buzzing in CHARD and INP1. Georgia and I were able to engage all the low noise ASC settings without any issues (CHARD P had been held in high bandwidth to avoid a ring up and the soft loops had high gain for the same reason).

We need to monitor for a while longer and also try relocking, but these changes may fix many of our ASC issues.

I have SDFed these gain changes.