WP12249

Jonathan, Dave:

The offloading of the past 6 months of raw minute trend files from h1daqtw0 SSD-RAID to permanent archive on HDD-RAID is completed.

TW0 raid usage went from 91% to 2%. Jonathan made the DAQ puppet change to configure nds0's daqdrc file with the new archive.

Currently Dust LAB2 is not working, 0.3u count is NaN, 0.5u count is flatline zero.

FRS32930

Laser Status:
    NPRO output power is 1.842W
    AMP1 output power is 70.15W
    AMP2 output power is 138.6W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 0 days, 2 hr 46 minutes
    Reflected power = 23.78W
    Transmitted power = 105.4W
    PowerSum = 129.2W

FSS:
    It has been locked for 0 days 0 hr and 33 min
    TPD[V] = 0.8228V

ISS:
    The diffracted power is around 3.2%
    Last saturation event was 0 days 0 hours and 33 minutes ago

Possible Issues:
    PMC reflected power is high, its a little higher after the FSS/PMC work today

Sheila D, TJ

To help understand why we've been having inconsistent locking of SRY lately, Sheila and I took an OLG of SRCL with SRY locked this morning. I stopped ALIGN_IFO at WFS_CENTERING_SRY so it was locked but not fully aligned. Compared to the last reference (July 2018) that was on the template, things look a bit worse off. We plan to have someone look at this and try to tune the loop a bit better.

The LVEA has been swept, the FARO is left plugged in in the East bay.

We've been seeing the FSS RefCav TPD signal dropping over recent weeks (not surprising for this time of year), so I went into the PSL enclosure this morning to tune up the FSS path alignment in advance of the holiday break.

To start, I attempted to touch up alignment into the PMC remotely using the picomotors right before it with the ISS off, but I wasn't able to get much of any improvement, so I turned the ISS back on and made my way out to the enclosure. Once there, I started with a power budget of the FSS path using the 3W-capable Ophir stick head:

• FSS In: 280.4 mW
• AOM In: 274.0 mW
• AOM Out (single-pass): 180.3 mW
  • SP Diffraction Efficiency: 65.8%
• AOM Out (double-pass): 130.2 mW
  • DP Diffraction Efficiency: 72.2%
• EOM Out: 129.2 mW

The largest (and least surprising) area of power loss I noticed was in the AOM diffraction efficiencies, so I started there. I adjusted the AOM stage itself, mostly in pitch, to improve the single-pass, and M21 to improve the double-pass. I also checked that the beam was passing nicely through the FSS EOM (it was, no adjustment needed here). The final power budget:

• FSS In: 280.4 mW
• AOM In: 274.0 mW
• AOM Out (single-pass): 195.9 mW
  • SP Diffraction Efficiency: 71.4%
• AOM Out (double-pass): 139.5 mW
  • DP Diffraction Efficiency: 71.2%
• EOM Out: 138.6 mW

Having made good improvements, I proceeded to adjust M23 and M47, the picomotor-controlled mirrors before the RefCav, to align the beam back onto the alignment iris at the input of the RefCav. That done, I then instructed the FSS autolocker to lock the RefCav. As seen before and noted most explicitly in alog81780, the autolocker could briefly grab the TEM00 mode but then lose it. I lowered the autolocker's State 2 delay (which determines how long to wait before turning on the temperature control loop after finding resonance) from 1.0 seconds to 0.5, and the autolocker was immediately successful. I've accepted this shorter delay time in SDF; screenshot attached. The TPD was reporting a signal of 0.515 V with the RefCav locked, so I used the pictomotors to improve alignment, finishing with a TPD signal of 0.830 V.

Seeing the beam spot on the RefCav REFL camera was now more than half out of view, I rotated the camera in its mount slightly to center the image. I then unlocked the FSS and used M25 to tweak up the alignment onto the RFPD, improving the voltage when using a multimeter from 0.370 V to 1.139 V, then locked the FSS again to get an RFPD voltage of 0.213 V. This gives a visibility of the RefCav of 81.3%. I wrapped up in the enclosure, turned the environmental controls back to science mode, and returned to the control room. After about an hour while maintenance activities were finishing, I turned the ISS back on; currently diffracting around 3.3%.

This closes WP 12250.

While Oli was ding initial alignment, I saw that the Y arm guardian was in the state ENABLE_WFS although the arm wasn't locked and wasn't well enough aligned to lock.  looking at the code, there was no check that the arm was locked before the locking state returned true, it only checks for errors.  I've changed the return true to happen if H1:ALS-Y_REFL_LOCK_STATUS = 1

After doing this I caused an issue by trying to cycle through these states while the INIT_ALIGN guardian was still managing the arm guardians.  The X arm had already run the WFS and completed, but the initial alignment guardian saw that it wasn't locked, and requested it to scan_alignment.  Perhaps this check could be made to only happen if the arm hasn't already offloaded, or if the arm has been in the locking state for a certain amount time. 

Fil, Fernando, Patrick, Dave:

We are investigating a Beckhoff device error on the CS-AUX PLC, DEV1 on the CDS Overview. Device went into error at 11:21 PST.

Looked at the spectum of th 50W CO2 lasers on the fast VIGO PVM 10.6 ISS detectors when the CO2 is locked (using the laser's PZT) and unlocked/ free running: time series attached. Small differences <6Hz, see spectrum attached. 

Tue Dec 17 10:02:58 2024 INFO: Fill completed in 2min 56secs

Quick fill, coincident with dewar filling.

Ryan S noticed that the range drop before the lockloss at 11:34UTC could be related to the glitches we've been seeing as Omicron sees similar glitches screenshot. DARM looks worse 30-100Hz plot.

Besfreo the lockloss we see a 26-28Hz wobble in DARM (not in the other LSC loops) plot.

TITLE: 12/17 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 2mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.39 μm/s
QUICK SUMMARY:

IFO re-locked itself twice overnight and is currently running magnetic injections before we start maintenance activities.

Slight strangeness that the IFO mode was in "relocking" H1:ODC-OBSERVATORY_MODE = 21 when I arrived.

TITLE: 12/17 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
LOG:

IFO is in INITIAL_ALIGNMENT and ENVIRONMENT

Still recovering from the 7.4 EQ today in Vanuatu. After this, there were many 5+ Mag aftershocks and our primary microseism is still above the 0.1 line. We briefly left EQ mode for 5 or so minutes before another earthquake (Atlantic Ocean this time) caused us to reactivate.

I began locking at 05:22 UTC and managed to get to PRMI but had no flashes. A few minutes later, another EQ hit and we lost lock. At this point, I started initial alignment. I believe IFO will be able to lock very soon since seismic conditions are coming down quickly.

Lockloss Alog 81859

Other:

As the pacific plate shook, Robert took the time to conclude his viewport work, meaning we are capable of transitioning to LASER SAFE once again. I have informed the morning operator independently too.

Interesting LL that happened between the detection of a 7.4 mag EQ but before any picket fence or STS detection. So I don't think it's EQ caused but seems suspicious. Either way, we're riding out a huge EQ right now and will attempt locking afterwards.

J. Oberling, R. Short

This afternoon, Jason and I started to look into why the FSS has been struggling to relock itself recently. In short, once the autolocker finds a RefCav resonance, it's been able to grab it, but loses it after about a second. This happens repeatedly, sometimes taking up to 45 minutes for the autolocker to finally grab and hold resonance on its own (which led me to do this manually twice yesterday). We first noticed the autolocker struggling when recovering the FSS after the most recent NPRO swap on November 22nd, which led Jason to manually lock it in that instance.

While looking at trends of when the autolocker both fails and is successful in locking the RefCav, we noticed that the fastmon channel looks the most different between the two cases. In a successful RefCav lock (attachment 1), the fastmon channel will start drifting away from zero as the PZT works to center on the resonance, but once the temperature loop turns on, the signal is brought back and eventually settles back around zero. In unsuccessful RefCav lock attempts (attachments 2 and 3), the fastmon channel will still drift away, but then lose resonance once the signal hits +/-13V (the limit of the PZT as set by the electronics within the TTFSS box) before the temploop is able to turn on. I also looked back to a successful FSS lock with the NPRO installed before this one (before the problems with the autolocker started, attachment 4), and the behavior looks much the same as with successful locks with the current NPRO.

It seems that with this NPRO, for some reason, the PZT is frequently running out of range when trying to center on the RefCav resonance before the temploop can turn on to help, but it sometimes gets lucky. Jason and I took some time familiarizing ourselves with the autolocker code (written in C and unchanged in over a decade) to give us a better idea of what it's doing. At this point, we're still not entirely sure what about this NPRO is causing the PZT to run out of range, but we do have some ideas of things to try during a maintenance window to make the FSS lock faster:

• Reduce delay turning on temploop (state 2; currently 1.0 sec)
• Increase wait time for mode to be centered (state 1; currently 0.1 sec; LLO uses 5.0 sec)
• Allow more voltage to PZT (requires using newer version of TTFSS box)
  • Current TTFSS limits PZT voltage to 13V-15V max
  • HV capable of supplying up to 65V
  • PZT capable of running up to 65V-100V

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.

Sheila, Jenne, Tony, Camilla

We've had locklosses in DRMI because the PRCL gain has been to high when locked on REFL1F.  Tony looked and thinks that this started on 77583, the day of our big shift in the output alignment.

Today we acquired DRMI with half the gain in the PRCL input matrix for 1F, this one acquisition was fast.  I've attached the OLG measurements for PRCL and MICH after the change. 

Tony is working on making histograms of the DRMI acquisition times, before the 23rd, from the 23rd to today, and eventually a histogram from today for the next few weeks to evaluate if this change has an impact on the DRMI acquisition times.

Jenne also found that it seems out POP18 build up seems higher in DRMI since the 23rd.