Back to Observing after fighting wind and then stepping through the CARM reduction slowly. There was a SQZ SDF diff that was changed when we lost lock this morning. I accepted it for now.

TITLE: 08/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Maintenance day today. We started relocking around 12 but wind made recovery a bit more difficult. We were not making it past the CARM reduction, so Sheila and Jenne stepped us through it slowly. This worked and just got back to Observing.
LOG:

• 1517 Forced lock loss to start maintenance activities
• Relocking
  • No light was in the X arm when I started green. Running the baffle alignment scripts didn't seem to help either. I assume this is from the EX model restarts this morning, I probably should have trended the sus values back, but I ended up just scanning with the ETM and TMS to get the the alignment back. The rest of initial alignment was uneventful.
  • We have repeatedly lost lock at the last step of CARM reduction , and some earlier. It is quite windy out, so we are assuming wind. I reran an initial alignment just to make sure the alignment was OK, but this didn't improve our locking troubles.                           
• 2330 Observing                                                                                                                                                                                

TITLE: 08/27 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 23mph Gusts, 17mph 5min avg
    Primary useism: 0.13 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

• We've been struggling to relock from the wind
• Currently at move_spots

Ibrahim A, Jeff K

On 8/22, Jeff K and I ran some measurements of our assembled BBSS and determined the Bounce and Roll modes to be:

• Bounce: 19.835 Hz (model prediction: 19.56 Hz)

  • BW: 0.01 (128s/avg)
  • Averages: 50
  • Excitation Waveform: Uniform Noise, 19-20 Hz

• Roll: 32.047 Hz (model prediction: 31.88 Hz)

  • BW: 0.001 (1024s/avg)
  • Averages: 50
  • Excitation Waveform: Uniform Noise, 31-33 Hz
• Confirmation ASD (exponential avg) Excitation:
  • BW: 0.02 (64s)
  • Excitation Waveform: Sine
  • Averages: 5

TJ, Sheila

TJ is having difficulty locking in the high winds this afternoon.  We've been running without DRMI ASC other than the BS, so that operators have to manually adjust PRM and SRM sometimes.  This afternoon we added back in INP1, PR1 and PRC2 loops, but left SRC ASC off.  This seems to be helping with POP18, although the operators may still need to adjust SRM by hand.

Maintenance activies completed around 30 min ago. I ran an initial alignment at 1100 PST, then started locking at 1206 PST. The wind is really starting to pick up and we just lost lock at the state Resonance. We will keep trying but this might be a tough relock.

Since it hasn't been done since before the vent, and the output of the PMC has continued to slowly drop, before locking today I calibrated the PSL rotation stage following the steps in alog79596.

The measurement file, new calibration fit, and screenshot of accepting SDFs are all attached.

Now that CIT's ldas-pcdev2 machine is back up following last week's data center troubles, my CW hardware injection monitoring shows no apparent signals since the return to observing mode on Saturday. Is that by design, or did the injections restart fall through a crack? Thanks.

J. Oberling, R. Short

The FSS RefCav TPD had been trending down again, and Ryan did not get enough improvement from a remote alignment tweak last week.  So today we went into the enclosure to do an on-table alignment of the FSS RefCav beam path.  As usual, we began with a power budget:

• FSS In: 282.9 mW
• AOM In: 283.2 mW
• AOM Out, SP: 174.4 mW
  • SP Diffraction Efficiency: 61.6%
• AOM Out, DP: 122.8 mW
  • DP Diffraction Efficiency: 70.4%
• EOM Out: 121.4 mW

No, we're not getting magic amplification between the FSS In and AOM In power measurements; that kind of small discrepancy is normal with the small stick power meter head we use for this alignment (they are also very AOI dependent, so it's entirely possible we had the head better aligned to the beam for the AOM In measurement).  Immediately we see the single-pass diffraction efficiency is lower than it normally is (generally hangs out in the lower 70% range these days), so we began by adjusting the AOM alignment to improve it.  This also means we have to then adjust M21 to improve the double-pass diffraction efficiency.  After the adjustments we had:

• AOM Out, SP: 199.4 mW
  • SP Diffraction Efficiency: 70.4%
• AOM Out, DP: 143.3 mW
  • DP Diffraction Efficiency: 71.9%

This is the lowest we've seen the diffraction efficiencies of this AOM, and suggests maybe it's time to swap the AOM for a new one (pretty sure this is the same AOM installed with the PSL in 2012, would have to go back through the alog to see if it's been swapped since install).  As usual, we had to do some small tweaks to the FSS EOM (provides the 21.5 MHz PDH sidebands for RefCav locking), and had to tweak the beam alignment into the RefCav using the input iris.  Once done, the RefCav locked without issue and our picomotor mounts were used to maximize the RefCav TPD; we began with a TPD of 0.57 V and ended with a TPD of 0.82 V.  We've had it higher in the past, but we have less power out of the PMC than usual (due to our slowly increasing PMC Refl that we have yet to figure out the cause of), and less power out of the PMC means less power available for the FSS RefCav which means lower maximum RefCav TPD.  To end we realigned the beam onto the RefCav RFPD and took a visibility measurement:

• Unlocked: 1.162 V
• Locked: 0.221 V
• Visibility: 81.0%

This finished the FSS RefCav tune-up, so we left the enclosure.  We left the ISS OFF while the enclosure returns to thermal equilibrium; it will be turned back ON once that equilibrium is reached, and Ryan will do a rotation stage calibration.  This closes LHO WP 12057.

WP12061 Upgrade RCG h1susex, remove LIGO-DAC delays

EJ, Erik, Jonathan, Dave, Daniel, Marc:

h1susex RCG was upgraded to a custom 5.3.0 specifically for the IOP to remove a delay in the new LIGO 28AO32 DAC. We compliled all of the user models with this RCG as well.

Our first restart was a simple model restart, but we got Dolphin errors. So our second restart was to fence h1susex from the Dolphin fabric and power cycle h1susex via IPMI. After this the models started with no issues.

No DAQ restart was required.

Code path is /opt/rtcds/rtscore/advLigoRTS-5.3.0_dacfix

WP12063 Alert System

Dave:

The locklossalert system code was modified to permit an alert window which spans over midnight, needed for the new owl shift hours.

Note that the business/every day filter is applied after the minute-in-day filter, so a window starting Friday evening and extending into Saturday morning will cut off at midnight if business days only is selected.

One other change:

For everyone subscribed to Guardian alerts, if for any reason the Guardian EPICS record cannot be read (node down, h1guardian1 down) the alert will now default to SEND.

Guardian Reboot

TJ:

h1guardian1 was rebooted at 08:21 PDT. All nodes except TEST came back automatically. TJ worked on TEST and got it going.

MSR Rack Cleanup

Jonathan:

Jonathan removed two test switches from the MSR racks which are no longer needed.

I removed two switches from the h1-daq-1 rack that had been put in for testing.  They are no longer needed in racks.

I also took a moment to sort and clean up a number of SFP transceivers that had been left out on the MSR work area.

Tue Aug 27 08:08:21 2024 INFO: Fill completed in 8min 17secs

Jordan confirmed a good fill curbside.

TITLE: 08/27 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: 6mph Gusts, 3mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: Locked for 2.5 hours, seems like an automated relocked before that. PEM magnetic injections are running now. Planned 4 hours of maintenance today.

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

TITLE: 08/27 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Observing and have been Locked for 5.5 hours. Quiet evening with nothing to report. Feedforward measurements were run, and I also just tuned squeezing up.

Little comparison on the damping for new PI over the past 5 days (ndscope)
Since starting back up last week, we have been seeing a new PI (79665), and it had caused a few locklosses. On Friday afternoon (08/24 ~00:00UTC - crosshairs on ndscope) it was decided that the easiest way to try and control it for now would be to change our input power from 60W to 61W. This, along with some changes to the damping gain, has helped keep it under control. Comparing the PI's behavior to the length of our lock stretches, we only see the ringups during the first 1.5-2 hours of each lock, so once we're thermalized past a certain point, they stop happening. The changes to damping (I'm not sure what was done besides raising the damping gain) also means that they get caught and damped quickly.
 

LOG:

23:30 Observing and Locked for 2 minutes
04:27 Dropped Observing to take FF measurements
04:46 Feedforward measurements done, running SQZ alignment
04:55 Back to Observing

TITLE: 08/26 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: Observing and just got to NLN a few minutes ago. Once we're thermalized I'll be taking LSC FF measurements.

Before the vent, we had lowered the DARM offset used at the end of the DARM_OFFSET state for locking the OMC since we had seen the PRG fall off and cause a lockloss with the nominal offset of 9e-05 (see alog79082 for details). When locking this afternoon, I raised the offset from 6e-05 back to 9e-05 after running through DARM_OFFSET, and seeing that the PRG didn't plummet and cause a lockloss, we continued locking. The OMC locked on the first try, something that hasn't been the case recently, so having more carrier light there seems to help. I compared OMC scans from this lock against the last lock, which used the lower DARM offset; attachment 1 shows the scan with the higher offset and attachment 2 with the lower offset. According to the OMC-DCPD_SUM channel, we get ~10mW more carrier light on the OMC when locking with this higher DARM offset.

I've put this DARM offset of 9e-05 back into ISC_LOCK and loaded it. We can watch over the next couple of lock acquisitions to see if the problem wth the PRG dropping off resurfaces.