I updated the POP_A P and Y offsets so the DRMI ASC will take us closer to where the full IFO ASC will take us

• First screenshot of the POP inmon starting at DRMI_ASC, with a time cursor at full IFO ASC
• Second screenshot of the SDF - I'm fairly certain this is SDF controlled and not guardian controlled

FAMIS 25805

pH of PSL chiller water was measured to be between 10.0 and 10.5 according to the color of the test strip.

Betsy, Ryan S, TJ

We did our first walk through after the vent, but next week there will definitely be more to sweep that we either missed or that we said we will hold off a week on. We focused on the most egregious items.

• HAM6 +X-Y cables resting on HEPI cross beam, addressed
• HAM6 +X camera cables and power supplies. There are two cables going to AS Air and only one to OMC Trans. The AS Air cables are messily running down to the floor and to a power supply plugging into a 120V AC outlet. Perhaps this is a temporary setup? The OMC Trans cable get draped over the chamber's viewports.
• HAM6 +Y accellerometer cable roll moved off of the HEPI cross beam.
• HAM4 +X -Y cables on cross beam and curtains barely missing. These were not moved.
• SQZT0 table door handle was very loose and the door could move ~1/2". I quickly opened the table and tighened the handle up with a flat head. This should probably get some locktite at some point.
• BS Oplev cabling and driver. Chaotic cables and new driver. Jason will address this next week.
• HAM1/2 HEPI cross beam cables touching. These also were not address.
• 4 unused extension cords unplugged in HAM2/3 area
• Dust monitors turned off. These are the style with internal pumps, so they are turned off for low noise. Their network cables will need to be moved back to pumpless monitors.
  • HAM1 monitor off
  • BSC8 monitor off
• HAM3 cleanroom turned off by unplugging, fan and lights both off now.
• Dial indicator still connected to chamber (no picture)

Jonathan, Nyath

As per WP 12580 we have replaced the GC switch which interfaces with CDS.  This is in response to the need to cycle the switch twice on Friday.

Unfortunately this took more work than expected.  The first switch we tried was not passing data between the CDS router and the GC core.  So we are running a smaller spare CDS switch with POE + 10Gb capability to service the control room phones, the control room computers, and the DMT interface.

We have two fiber pairs going to the GC core switch.  We typically run them as an aggrigated link.  However for testing we have split that up and are running one pair to the active switch and have the other fiber pair to test another switch.

This work resulted in minor outages to the DMT and control room.  The largest outages being to the non-operator phones.

We will keep the work permit open for a bit.

Attatched to this alog are omicron glitch rate comparions, as a function of frequency and SNR, between O4a and O4b. Here, I used roughly ~ 3425 hours of observing time for O4a and O4b (H1:DMT-ANALYSIS_READY:1 flag). The specific observing times used were:

O4a: 2023-06-24 20:00:00 - 2024-01-17 00:00:00 (~3422 hours observing)

O4b: 2024-04-10 00:00:00 - 2025-01-28 17:00:00 (~3428 hours observing)

The SNR and frequency of the omicron triggers gathered were 7.5 < SNR < 500, and 10 Hz < frequency < 1024 Hz. I find that the glitch rate in O4b is significatly less than O4a. In O4a, there was a lot of non-stationary noise from ~10-50 Hz (see alogs 71005 & 71092), which is why the rate was so high. For frequencies below 50 Hz, the glitch rate per hour went from roughly  ~16.7 in O4a to ~2.5 in O4b. For SNR below 50, the glitch rate per hour went from ~36 per hour in O4a to ~9 per hour in O4b. 

Tue Jun 03 10:11:02 2025 INFO: Fill completed in 10min 59secs

Hello!

I have been working on eventually calculating how much force is being applied to three stages of the quadruple pendulum. The channels I am currently plotting in the figures attached are the DARM control signal (H1:CAL-CFTD_DELTAL_CTRL_DBL_DQ), the penultimate mass control signal (H1:CAL-CFTD_DELTAL_CTRL_PUM_DBL_DQ), the upper intermediate mass control signal (H1:CAL-CFTD_DELTAL_CTRL_UIM_DBL_DQ), the top test mass control signal (H1:CAL-CFTD_DELTAL_CTRL_TST_DBL_DQ), the external excitation signal (H1:CAL-CFTD_DELTAL_EXTERNAL_DQ) and Pcal y (H1:CAL-PCALY_RX_PD_OUT_DQ) - I should include Pcal X next time. By plotting these channels I can map out how much each stage of the quadruple pendulum is moving (or being actuated upon), the Pcal injections, and eventually compare the force needed to control each stage to keep our interferometer locked.

Right now I am plotting the meters per root Hz for each channel. I am also applying an anti-whitening filter so that I can convert the signals from counts back into the physical displacements. 

The path to the file to plot these figures is: /ligo/home/caroline.capuano/Force_on_ETMX_for_each_stage/phase_and_mag_of_h.py

All you need to do is run "python phase_and_mag_of_h.py" and it should produce both plots.

Currently I am taking data from LIGO Hanford at the GPS start time of 1425831025 for a duration of 1000 seconds.

There is a weird bump around 100 Hz for the external excitation signal, so Craig suggested I find another time of when we were locked and compare to see if the hump is still present.

To do next:
- figure out what filters to divide by so that I can calculate the force being applied to the three stages aka N/rtHz.
- maybe try quick_psd instead of welch's method and see if that makes a significant difference

Two index number changes this morning:

1. Adjust_Power was 1000, we have changed this to 521. This now fits it in linearly in the state graph and doesn't mess with other scripts, checks, and things that check for low noise conditions above 600.
2. Darm_Offset was brought back to 427 from 432. A few days ago (alog84703) it was changed with the thought that the move would bring the state back into order, but we plan to move the state back to it's old place between DRMI_TO_POP and ENGAGE_RF_VIOLINS when we can. Sorry for the confusion.

TITLE: 06/03 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: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY:

IFO is in DOWN for PLANNED ENGINEERING

Today is a light maintenance day in with the plan being to continue locking H1 to NLN.

The highest state we are able to get to is: LOWNOISE_LENGTH_CONTROL.

Workstations were updated and rebooted.  This was an os packages update.  Conda packages were not updated.

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

Just had another lockloss so I'm just putting the detector in IDLE for the night. I have a list of things from Elenna to check/try with relocking, but I won't be able to get to any of them before the end of my shift, so they can be checked tomorrow morning. This last lockloss was during OFFLOAD_DRMI_ASC while I was trying to adjust SRM, although I don't think I caused the lockloss? It took a while for DRMI to catch this time, so maybe running an initial alignment is warranted. The highest state we were able to get to today was LOWNOISE_LENGTH_CONTROL.

The list Elenna gave me is:

• Watch ADS for problems (we weren't seeing any ringing up, but ADS were taking more than 10 mins to converge in MOVE_SPOTS (84734)
• Check that CHARD Y gain goes to 300 at the end of MAX_POWER (once we are at 60W and ADS have converged) (84732)
• Watch for DHARD P oscillation during TRANSITION_FROM_ETMX (84736)
• Try to damp violins at full power (I put Rahul's new damping settings into lscparams for 2W (84720), so during damping at higher powers we will need to see whether the current settings or the 2W settings work best for those three modes) Tagging SUS, OPS Info

LOG:

23:00UTC Commissioning and sitting in POWER_10W
23:20 Started trying to increase power
01:49 Lockloss from LOWNOISE_LENGTH_CONTROL while sitting there running measurements
    - Started a manual initial alignment
        - Stopped at PRX_LOCKED, touched up PRM, then finished IA
    - Stopped at OFFLOAD_DRMI_ASC, touched up SRM, then continued
    - Lockloss in DRMI_TO_POP
        - Probably due to DRMI alignment not being the greatest
    - Stopped at OFFLOAD_DRMI_ASC, touched up SRM, SR2, and PRM, then continued
    - Lockloss in LOWNOISE_ESD_ETMX due to a CHARD P ringup that started in TRANSITION_FROM_ETMX
    - Lockloss from OFFLOAD_DRMI_ASC while I was trying to touch up alignment using SRM. Not sure if my fault?

Writing this alog on behalf of most of the control room...

After we redid the input matrix for CHARD and INP1 10W, we checked the PRC2 and INP1 bandwidth. We were also concerned about the overall gain of CHARD P and Y since they seemed to be way too low

• We stepped the offset of INP1 pitch and yaw as a rough bandwith measurement. We found that INP1 yaw gain to be too high by a factor of 10, and the INP1 P gain to be just fine.
• we ran OLGs of PRC2 pitch and yaw, and found the gain to be about a factor of 3 too high for both, which may have been responsible for some 0.8 Hz buzzing we saw in the ASC signals whenever we tried to raise the CHARD gains
• After this, we were able to raise the CHARD P gain to achieve a UGF around 3 Hz, as desired.
• We were still unable to raise the CHARD Y gain to a reasonable value without ringups
  • it seemed anywhere between 20 and 40 dB too low, but it was hard to tell from the measurements.

We decided to power up anyway, and saw that the pitch ADS was able to run fine, now that the CHARD pitch gain was nominal. However, yaw ADS still had problems during move spots.

• We stepped up power from 10 W by hand, and then ran through the power 25W state by hand (which also changes loop gains, engages soft yaw, etc).
• Then we ran move spots successfully- towards the end of the state is where we had to drop the yaw ADS gains due to an instability.

Everything looked good, so I took us up in power from 25W to 60W, stopping frequently to check for instabilities. We made it, but again the ADS was unstable, so Georgia used the Camera servo guardian to move off the ADS to camera servos, and everything was fine.

I stepped through lownoise ASC by hand, skipping the lownoise steps of CHARD P and Y since those gains were not nominal.

• Then, I rescaled the overall lownoise gain of CHARD P and engaged its lownoise filters, no problem.
• I measured the CHARD Y OLG and found the gain  still very low. But this time I could step it up from 3 to 300 as needed and the higher gain made the buildups look a little better.
• Since the gain was back to nominal, I scaled to the lownoise gain and engaged the lownoise filters.
• The gain scaling is saved in the guardian.

Lots of the of the usual wobbly stuff in the ASC and buildups at high power, but the overall alignment and control looks good: PRG is still around 50 at full power.

We then ran through lownoise coil drivers and the ETMX ESD transition. We had one guardian error at the end of TRANSITION FROM ETMX due to divide by zero error since the convergence checker looks for something that is like [ADS error signal / ADS CLKGAIN] and the ADS CLKGAINs were zero. Georgia and I fooled the guardian by setting the CLKGAINs to 1 momentarily, and then undoing them once the state completed.

We ran all the way through LOWNOISE LENGTH CONTROL, although the LSC feedforward is no longer well-tuned, so I turned it off momentarily so we could check OLGs.

The LSC feedforward is currently so bad that we should go from-scratch when we retune it instead of the iterative method.

We had a fast unknown lockloss while sitting in this state- no one was doing anything and we don't see an obvious cause.

We think we have properly SDFed and guardianized all changes from today.

My only worry: we were not able to raise the CHARD Y gain until we reached maximum power, but obviously we are having ADS stability issues since this gain is too low. Currently I have set the guardian to have what I think is the "correct" CHARD Y gain (300 once all loops are closed), but if it's too high, drop it back to 3.

Recommended to do list:

• check PRCL OLG
• Check PRCL/SRCL/MICH sensing at high power
• consider turning off some LSC notches, many seem unnecessary
• Run MICH/SRCL (PRCL?) LSC feedforward measurements, tune, etc
• determine if we want to run camera servos sooner during power up/locking process
• Check SRCL offset

Changed the DARM_OFFSET ISC_LOCK state number to be in order, after ENGAGE_ASC_FOR_FULL_IFO

Jennie W, Sheila, Elenna

In order to get data for mode-matching and for Elenna to get data to calibrate sideband heights we ran some mode scans after the SR3 heater was turned on last night.

16:55:24 UTC Carried out single bounce OMC scan at 10W PSL input with sensor correction on HAM6 on, high voltage on for PZT driver in HAM6, sidebands off , SRM mis-aligned, ITMY mis-aligned, DC 3 and 4 on, OMC ASC on.

Excitation freq changed to 0.005 Hz as the top peak of the TM00 mode looked squint so could have been saturating. Lowering this frequency prevented this.

Ref 15-17 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

Then mis-aligned ITMX and aligned ITMY (Sheila had to re-align SR2 to centre on ASC-AS_C).

Measurement starts at 17:08:18 UTC.

Ref 18-20 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

Traces saved in 20250516_OMC_scan.xml. The top left plot is the first scan bouncing beam off ITMX, the second scan is the bottom right bouncing off ITMY.

The top right is the two plots of the PZT2 DC voltage monitor. That is, the current voltage applied to the PZT. The bottom left is the plot of the voltage ramp applied to the PZT2 on the OMC for this measurement.

The ndscope attached shows the power in mA transmitted through the OMC on the top, then the PZT used for the scan DC voltage underneath, then the input PZT voltage underneath that, then the reflected power from the OMC in mW, then at the bottom the SR3 heater element temperature in degrees.

Elenna did two more scans in single bounce with sidebands back on and different modulations depths in each.

TJ, Camilla, Sheila

TJ and Camilla got the HWSs working, and now we turned on the SR3 heater at 15:54 UTC, 2W requested power.  This is to do a check of the SR3 heater calibration and range similar to 27262