TITLE: 11/02 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 8mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY:

• We've been locked for a little over an hour
• Secondary microseism is descreasing, wind is low

Using the darm_integral_compare.py script from the NoiseBudget repo (NoiseBudget/aligoNB/production_code/H1/darm_integral_compare.py) as a starting point, I made a version that is simplified and easy to run for when our range is low and we want to compare range vs frequency with a previous time.

It takes two starting times, supplied by the user, and for each time, it grabs the DARM data between the start time and an end time of starttime+5400 seconds (1.5 hours). Using this data it calculates the inspiral range integrand and returns two plots(pdf) - one showing the range integrand plotted against frequency for each set of data(png1), and then the second plot just shows DARM for each set of data, along with a trace showing the cumulative difference in range between the two sets as a function of frequency(png2). These are saved both as pngs and in a pdf in the script's folder.

This script can be found at gitcommon/ops_tools/rangeComparison/range_compare.py. To run it you just need to supply the gps times for the two sets of time that you want to compare, although there is also an optional argument you can if you want the length of data taken to be different than the default 5400 seconds. The command used to generate the PDF and PNGs attached to this alog was as follows: python3 range_compare.py --span 5000

Over the past 2 days I've been seeing lots of IMC locklosses right after a main lockloss while ISC_LOCK is in READY. This has been happening 10+ times between relocks. The IMC guardian seems to lock for a split second in its "AQUIRE" state then as soon as it moves on to "BOOST" it loses it. It looks the the MC2 transmision maybe isn't stable, then the BOOST state turns on MC2 lock filters and ramps gains. We also see the bottom stage of MC2 SUS saturate during this. Some are from FSS oscillations but not all.

Lockloss @ 11/02 20:08 UTC after 20 minutes locked

Lockloss @ 11/02 18:38 UTC after only 33 minutes locked

Sat Nov 02 10:10:55 2024 INFO: Fill completed in 10min 51secs

Janos, Dave:

VACSTAT version 1.10

Following several recent false positive VACSTAT alarms due to noise in a single gauge (usually BSC3 PT132) we have made a change to the code to mitigate this.

The new alarm logic is:

• If a single gauge trips, increase the sensitivity of the other gauges. Then if at a later time a second or more gauges trip, send the cell phone alarm to the vacuum team.
• If multiple gauges trip at the same time, send the cell phone alarms to the vacuum team.

The alarm system was modified to alert the vacuum team if the channel H1:CDS-VAC_STAT_GLITCH_NUM_GAUGES is 2 or greater.

My cell phone alarm will continue to sound on a single gauge trip, because tripped gauges are latched out from the sytem and we need to reset any false positives to restore the nominal functionality.

The new code was installed Friday afternoon (15:40 01nov2024 PDT).

Design reasoning:

In the event of an in-chamber gas release the local gauge will see a large signal. Gas migration to neighboring chambers will result in smaller signals there. Increasing their trip sensitivities will increase the chance of seeing a multi-chamber event.

Lockloss @ 11/02 17:13UTC after only 9 minutes locked

Lockloss @ 11/02 15:17 UTC after 4 hours locked

TITLE: 11/02 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 16mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:

In Observing and have been Locked for 3hours 15mins. Secondary microseism is coming down and wind is just over 20mph

TITLE: 11/02 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY: The IMC has been very unhappy and the FSS has been glitching frequently this shift. HLID picket fence seismometer has also been glitching out this afternoon (Tagging SEI), after the locklosses the IMC would lose it again and relock after reaching READY this kept happening this evening. We just locked PRMI as of 05:00 UTC.

The left display of the Operator WS is flickering, unplugging and plugged it back in fixes the issue but only for like an hour.

LOG: No log

Lock#1:

• 23:29 UTC ENGAGE_DRMI lockloss
• 23:42 UTC CARM_OFFSET_REDUCTION lockloss #3, IMC and ASC_AS_A lost lock at the same time, zoomed in
  • 00:25 UTC Observing
• 00:52 UTC lockloss 31 minute lock :(
  • Lots of FSS glitches after this lockloss, the IMC kept locking then the FSS would glitch and kill it in ready. I put ISC_LOCK in down till it locked, this happened 6 times before it would hold it, then it lost it as soon as I moved on from DOWN, I watched the FSS_FAST channel grow until a glitch killed it seconds later. Then the 8th time was the charm and it held.
  • Despite these inital issues relocking was fine after the IMC actually held, automated relock in just over an hour
  • 01:58 UTC Observing
• 04:17 UTC lockloss 2:24 lock
  • The IMC locked and relocked a few times again in READY
  • DRMI doesn't look as good now

04:17 UTC, the IMC lost lock less than 100ms after ASC_AS_A, no IMC tag though and the FSS didn't really look glitchy.

Closes FAMIS26509, last checked in alog79454. It looks as expected, the lack of switching in the recent past was the vent I believe.

00:53 UTC

IMC and ASC_AS lost it at the same time, looks like some kind of fast ringup in the FSS_FAST channel. FSS_OSCILLATION and IMC tag on the lockloss tool.