Lockloss during commissioning at 2025-06-25 17:52UTC after over 5.5 hours Locked. Cause not known, but probably not commissioning related.

TJ, Camilla WP 12605, WP 12593

As HAM1 is now low enough in pressure, we removed the HAM1 +Y yellow VP covers, re-attached bellows and removed guillotines. ISCT1 was moved back into place on Friday 84850.

After TJ transitioned to Laser Hazard, we opened the ALS and PSL light pipes and turned back on the SQZ, CO2s and HWSs lasers.  

After okay from VAC, IMC locked without issue, PRC and MICH alignments look good enough on AS AIR camera and we will begin realigning ISCT1 soon.

HWS servers now point to /ligo/data/hws as the data directory.

The old data directory, h1hwsmsr:/data, is now moved to h1hwsmsr:/data_old

The contents of the old directory were copied into the new directory, except H1/ITMX, H1/ITMY, H1/ETMX, H1/ETMY, under the assumption that these only contain outputs from the running processes.

HWS processes on h1hwsmsr, h1hwsmsr1, h1hwsex were stopped and restarted and are writing to the new directory.

h1hwsey had crashed previously and wasn't running.  It was restarted and is also writing to the new directory

Addressed TCS Chillers (Mon [Jun2] 100-125am local) & CLOSED FAMIS #27816:

• TCSx Chiller:  Had level of 29.6 cm.  Added 300mL for 30.4cm.
• TCSy Chiller:  Had level of 9.6 cm.  Added 280mL for 10.3cm.  
• There was no water in the small cup under the slow leak.

TJ, Sheila, Matt, Andrew (job shadow today), Camilla. WP12433. Table layout D1400241.

Following on from other beam profile work at the end stations 81358, Madi Simmonds models G2500646 and the ideas we had for understanding ETM mode matching better (googledoc), today we took some beam profiles of the EY ALS beam reflected of ETM HR in the HWS path.

We added a 532nm quarter waveplate downstream of the beamspiltter (ALS-M11) and tuned it to maximize the light reflected into the HWS path. This was removed when we were finished and left with Nanoscan beam profile.

We first took some beam profile measurements (photos 1-4) first with the QPD offsets on nominally, and then with the offsets zero'ed (phots 5-9). Unless the beam has been pico-ed (which it may have) the zero offsets should have the beam more centered on the Transmon parabolic mirrors. The beam changed when the offsets were turned off but did not look better/worse, just different. Compare photo 4 (QPD offsets on) and photo 5 (offsets off).

Closes FAMIS 27812. Last checked in alog 83486

CO2Y:

Before: 10.4ml

After: 10.4ml

Water Added: 0ml

CO2X:

Before: 30.1ml

After: 30.1ml

Water Added: 0ml

No water leaking in our leak detection system (aka dixie cup)

J. Kissel

I've been tasked with using the analog voltage input to the OMC DCPD transimpedance amplifiers (LHO:83466) to drive a sine wave around 10 kHz, in order to try to replicate a recent PI ring up which apparently caused broad-band low frequency noise LHO:83335.

There is a remote excitation channel that typically drives the this analog input excitation path is running at 16 kHz: the H1:OMC-TEST_DCPD_EXC channel's filter module lives in the h1lsc.mdl model in a top_names OMC block at the top level of the model, and the output of that filter bank is connected to the lsc0 IO chassis' DAC_0's 11th / 12th digital/analog channel. That DAC's AI channel goes through quite an adventure before arriving at the OMC whitening chassis input -- following D19000511,
    - AI chassis for lsc0 IO chassis DAC_0 lives in ISC-C1 U7, port OUT8-11 D9M spigot (page 2, component C15), connected to cable ISC_406
    - The long ISC_406 DB9 cable connects to a LEMO Patch Panel (D1201450) on the other end in ISC-R5 U12 (page 22, component C210).
    - Funky LEMO to D9M cable D2200106 ISC_444 connects from the patch panel to the whitening chassis,
    - ISC_444 D9F end of the cable to lands at the  J4 D9M port labeled "From AI/DAC / Test Inputs" of OMC DCPD whitening chassis in U24 of ISC-R5 rack.

... but this won't work: this channel is driven at 16 kHz sampling frequency. So, we can't drive anything technically above 8192 Hz, but realistically above ~5-6 kHz.
I digress.

I'm going with SR785 excitation via DB9 breakout.

Anyways -- I attach here an ASD of the OMC DCPDs sampled at 524 kHz during nominal low noise this morning (taking advantage of the live-only 524 kHz channels), low-passed at 1 Hz, without any digital AA filters; the channel H1:OMC-DCPD_524K_A1 filter banks channels from LHO:82686. The OMC DCPD z:p=1:10 Hz whitening is ON during nominal low noise.

The top panels show a zoomed in, and zoomed out version of the DCPDA ASD calibrated into photocurrent on the PDs (H1:OMC-DCPD_524K_A1_OUT channel, * 0.001 [A/mA], all the rest of the calibration is built in to the front-end filter bank; see OUT DTT Calibration).
The bottom panels show a zoomed in, and zoomed out version of the DCPD ASD calibrated into ADC input voltage, with what whitening that was ON divided out, and the 2x ~11 kHz poles of the TIA divided out. (H1:OMC-DCPD-524K_A1_IN channel, * 1/4 [four-channel copy sum to avg conversion] * 0.0001526 [V/ct for 40 Vpp range over an 18 bit ADC] * z:p = (10):(1) inverse whitening filter * z:p = (11k,10k):([]) inverse HF TIA response )

In the zoomed in version of the plots, you can clearly see the mess of acoustic modes at 10.4 kHz. 
One can also see relatively noise free region at 10.3 kHz that looks clean enough for me to target with my analog excitation.

I plot the de-whitened ADC voltage because the transfer function between the TEST DAC input and the TIA's output voltage is designed to the 1.0 in the GW band, from ~50 to 5 kHz, given that in that band, the transimpedance is 100e3 [V/A] and the series resistor that turns the voltage injection of the TEST input into current is 100e3 [V/A] (see ). So "nominally" un-whitened ADC counts should be a one-to-one map to DAC voltage input. At 10 kHz, however, the 2x ~11 kHz poles of the TIA, which drop the TEST input voltage by a factor of 5x at 10 kHz (see, e.g. plots from LHO:78372)

So, that's why in the lower panels of the above mentioned plot of OMC DCPD A's ADC voltage calibrated in the way mentioned above. This should be a one-to-one map to the equivalent DAC voltage to drive.

I looks like the non-rung-up 10.4 kHz PI modes today were of-order 1e-2 V = 10 mV, and the surrounding noise floor is around 1e-5 V = 10uV = 0.01 mV of equivalent DAC drive.

The lower limit of the SR785 SRC amplitude is 0.1 mVp = 0.2 mVpp (single ended).
Also, using the SR785 in a FFT measurement mode, where you can drive the source at a single frequency, there is no ramp. It's just ON and/or OFF.
(I should also say that a SR DS340 function generator also doesn't have a ramp on its output. I considered using that too.)

So -- hopefully, suddenly turning on a noisy 10.3 kHz line at 0.1 mVp into the IFO with a noise floor of 0.01 mV/rtHz at 10kHz won't cause problems, but ... I'm nervous.

Closes FAMIS 28458. Last checked in alog 82659.

• CO2 IY and IX PD_OUT signals are constant rather than offset at week intervals compared to last month. I assume this is due to changes between Tuesdays.
• HWS SLEDPOWERMON signals for both IX and IY are continuing to go down very gradually as last month's trend showed.

Attached are monthly TCS trends for CO2 and HWS lasers.  (FAMIS link)

FAMIS: 27805

CO2X was found at 30.0, I added 150ml to get it to right to the MAX line at 30.5.

CO2Y was found at 10.3, I added 150ml to get it to the MAX line at 10.7.

Side note:
I was up there checking for leaks and I saw this old looking goopy mess toward the corner of the mezzanine. It looks like it is from an old Hepi fluid leak. Tagging SEI.

To hopefully help combat our recent bouts of PI24 ring ups (alog81890), we've bummped the ETMY ring heater power from 1.1W per segment to 1.2W. The safe.snap and observe.snap are updated.

We also have a plan to update the PI guardian to temporarily increase the ETM bias to hopefully give us more range to damp the PI. We will need to be out of Observing for this, but we could hopefully save the lock. TBD.

The broadband glitching that was present in the early hours of Dec 11 (UTC) appears to have suddenly and entirely stopped at 10:36:30 UTC - this sharp feature can be seen in the daily range plot. I completed a series of LASSO investigations around this time in the hopes that such a sharp feature would make it easier for LASSO to identify correlations. I find a number of trend channels that have drastic changes at the same time as this turn-off point related to TCS-ITMY_CO2, ALS-Y_WFS, and SUS-MC3_M1.

The runs I completed are linked here: 

1. LASSO run of the first half of Dec 11 with the sensemon range as the primary channel 
2. LASSO run of times near the turn-off point with TCS-ITMY_CO2 as the primary channel 
3. LASSO run of times near the turn-off point with the sensemon range as the primary channel

Run #1 was a generic run of LASSO in the hopes of identifying a correlation. While no channel was highlighted as strongly correlated to the entire time period, this run does identify  H1:TCS-ITMY_CO2_QPD_B_SEG2_OUTPUT (rank 11) and H1:TCS-ITMY_CO2_QPD_B_SEG2_INMON (rank 15) as having a drastic feature at the turn-off point (example figure). Based on this information, I launched targeted runs #2 and #3. 

Run #2 is a run of LASSO using H1:TCS-ITMY_CO2_QPD_B_SEG2_OUTPUT as the primary channel to correlate against. This was designed to identify any additional channels that may show a drastic change in behavior at the same time. Channels of interest from this run include H1:ALS-Y_WFS_B_DC_SEG3_OUT16 (example figure) and H1:ALS-Y_WFS_B_DC_MTRX_Y_OUTMON (example figure). SEISMON channels were also found to be correlated, but this is likely a coincidence. 

Run #3 targets the same turn-on point, but with the standard sensemon range as the primary channel. This run revealed an additional channel with a change in behavior at the time of interest, H1:SUS-MC3_M1_DAMP_P_INMON (example figure). 

Based on these runs, the TCS-IMTY_CO2 and ALS-Y_WFS channels are the best leads for additional investigations into the source of this glitching. 

Per the WP12246:

Visual inspections were performed in the LVEA to track the wires and verify the picomotor controllers existence, connections and spares (physically only). The information gattered was updated in the document E1200072. Important findings were found and the document is pretty much near to the real installation. Electrical part investigations will follow to determine the spares. The names of the rack as well as the physical location for the controllers were verified using the O5 ISC wiring diagram D1900511.

Marc, Fernando

TITLE: 12/02 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: A long relock today from DRMI locking struggles and lock losses at Transition_From_ETMX. Once back up to observing the range hasn't been very stable, hovering between 140-150Mpc. I was waiting for a drop in triple coincidence before trying to tune squeezing, but that didn't happen before the end of my shift. The 15-50Hz area in particular looks especially poor.
LOG:

• Relocking notes
  • MICH and PRMI caught no problem, but DRMI would not catch. I tried moving SRM but nothing seemed to work. MICH and SRCL were triggering and flashes looked good. I ended up doing an initial alignment but skipping green alignment since this looked good before.
  • DRMI had basically no flashes after initial alignment. Odd. Did MICH and then couldn't lock PRMI. Trying a full initial alignment.
  • Flashes better this time, but it still took 4 min to lock. Finally locked DRMI though.
  • Lost lock at Transition_From_ETMX
  • And again.
  • One more lock loss at Transition_From_ETMX. I had it sitting in this state for 5 min while I was looking at the state code, then there was an ASC pitch ringup. I'm not sure which was the worst of the ASCs.
  • Another initial alignment. Another struggle for DRMI after PRMI and with seemingly great flashes.
  • Bumped SUS-ITMX_L3_LOCK_BIAS_TRAMP to 25 from 30 during the transition to ETMX state, similar to what Sheila did on Nov 22. The hope was to move faster to a safer place and avoid the CHARD P ringup.

I edited the sys/h1/guardian/injparams.py and  sus/h1/guardian/SUS_CHARGE.py code to move the magnetic injections and in-lock charge measurements 20 minutes earlier tomorrow, usual start times are 7:20am and 7:45am. Moved to 7 am and 7:25am, should be over by 7:40am. If we drop out of observing, can an operator please reload PEM_MAG_INJ and SUS_CHARGE guardians.

Aim to turn CO2 laser off  at 7:40am tomorrow, before the lockloss to see if we see similar SQZ alignment changes related to CO2 lasers as LLO does: 72244.

Ansel reported that a peak in DARM that interfered with the sensitivity of the Crab pulsar followed a similar time frequency path as a peak in the beam splitter microphone signal. I found that this was also the case on a shorter time scale and took advantage of the long down times last weekend to use  a movable microphone to find the source of the peak. Microphone signals don’t usually show coherence with DARM even when they are causing noise, probably because the coherence length of the sound is smaller than the spacing between the coupling sites and the microphones, hence the importance of precise time-frequency paths.

Figure 1 shows DARM and the problematic peak in microphone signals. The second page of Figure 1 shows the portable microphone signal at a location by the staging building and a location near the TCS chillers. I used accelerometers to confirm the microphone identification of the TCS chillers, and to distinguish between the two chillers (Figure 2).

I was surprised that the acoustic signal was so strong that I could see it at the staging building - when I found the signal outside, I assumed it was coming from some external HVAC component and spent quite a bit of time searching outside. I think that this may be because the suspended mezzanine (see photos on second page of Figure 2) acts as a sort of soundboard, helping couple the chiller vibrations to the air. 

Any direct vibrational coupling can be solved by vibrationally isolating the chillers. This may even help with acoustic coupling if the soundboard theory is correct. We might try this first. However, the safest solution is to either try to change the load to move the peaks to a different frequency, or put the chillers on vibration isolation in the hallway of the cinder-block HVAC housing so that the stiff room blocks the low-frequency sound. 

Reducing the coupling is another mitigation route. Vibrational coupling has apparently increased, so I think we should check jitter coupling at the DCPDs in case recent damage has made them more sensitive to beam spot position.

For next generation detectors, it might be a good idea to make the mechanical room of cinder blocks or equivalent to reduce acoustic coupling of the low frequency sources.