TITLE: 11/04 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Microseism
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently still trying to relock, and at POWER_25W. All day we've been working on getting back up, but the secondary microseism is so high. It is slowly coming down though. At one point, we were in OMC_WHITENING for over an hour trying to damp violins so we could go into NLN,  but we lost lock before we could get there.
LOG:

15:30 In DOWN due to very high secondary useism
15:38 Started relocking with an initial alignment
    - When we got to PRC, I had to do the Pausing-PSL_FSS-Until-IMC-Is-Locked thing again (see 81022)
    - 16:04 Initial alignment done, relocking
    - Lockloss from ACQUIRE_DRMI_1F, OFFLOAD_DRMI_ASC, ENGAGE_ASC_FOR_FULL_IFO, TRANSITION_FROM_ETMX
    - 18:07 Sitting in DOWN for a bit
    - 18:45 Started relocking
    - More locklosses
    - 21:48 Lost lock after sitting in OMC_WHITENING damping violins for over an hour
    - More trying to lock and losing lock                                                                                                                                               

 Most of the locklosses over this weekend have the IMC tag and those do show the IMC losing lock at the same time as AS_A, but since I don't have any further insight into those, I wanted to point out a few locklosses where the causes are different from what we've been seeing lately.

2024-11-02 04:17UTC

• No IMC tag, does have a DCPD tag
• Everything looking normal, then 100ms before the lockloss is first seen by anyone, PSL-ISS_AOM_DRIVER_MON_OUT shows a steep drop in value, getting larger in amplitude until the lockloss (ndscope1, ndscope2)

2024-11-02 17:13 UTC

• No IMC tag, does have a DCPD tag
• Everything looking normal, then 1s before the lockloss is first seen by anyone, PSL-ISS_AOM_DRIVER_MON_OUT shows a steep drop in value, getting larger in amplitude until the lockloss (ndscope3, ndscope4)
• Very similar to the above example, except the glitch isn't as steep. There is another one of these glitches that happens a few seconds before, but that one is even less steep and it is able to catch itself

2024-11-02 18:38:30.844238 UTC

• No IMC tag, does have a DCPD tag
• Small glitch in the FSS FASTMON channel caused NPRO temperature to spike and NPRO power jumps down, then ISS AOM DRIVERMON sees glitch up to the lockloss start (ndscope5, ndscope6-zoomed into FSS drop)

TITLE: 11/03 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Microseism
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 22mph Gusts, 18mph 3min avg
    Primary useism: 0.13 μm/s
    Secondary useism: 0.60 μm/s
QUICK SUMMARY:

• High microseism has made locking a struggle, in addition to the FSS issues
  • Violins have been rung up and we haven't stayed locked long enough to fully damp them for OMC_WHITENING
• Microseism seems to been slowly coming down
• Wind is increasing a little bit
• Relocking at CARM_TO_REFL

Closes FAMIS#27801

Last checked a week ago by Camilla, but since the water swap was done recently, I am doing the next check only a week later.

CO2X

• Before: 30.2
• After: 30.2
• Did not add any water

CO2Y

• Before: 10.2
• After: 10.2
• Did not add any water

There was no water in the leak cup.

Sun Nov 03 10:13:13 2024 INFO: Fill completed in 13min 10secs

TITLE: 11/03 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.09 μm/s
    Secondary useism: 0.72 μm/s
QUICK SUMMARY:

Looks like we have been sitting in PREP_FOR_LOCKING since a relocking lockloss at 10:52UTC(81032). I just started an initial alignment. The secondary microseism is really high so not sure how far we'll get

H1 has been having a hard time locking tonight due to very high microseismic motion. Unlocked at 05:43 UTC (lockloss tool) and has been down since; highest state I've seen H1 reach is TRANSITION_FROM_ETMX, alignment doesn't seem to be the problem.

TITLE: 11/03 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:Short locks, the IMC kept losing lock during SDF_REVERT/READY/LOCKING_GREEN as it did yesterday. Primary useism has been increasing over the last few hours (there's been more small US EQs today than normal... Missouri, Idaho, Nevada all in the 3s).
LOG: No log

• 22:15 UTC Observing, low range check
• 00:44 UTC lockloss (2:29 lock)
  • 01:09 DRMI_TO_3F lockloss
  • 02:00 UTC Observing
• 02:28 UTC lockloss (0:31 lock)
  • 03:45 UTC Observing
    • Range isn't so good
  • 03:43-04:45: UTC dropped observing from the SQZer losing lock
    • The FC keeps losing IR lock trying to get GR locked, it says "LO SERVO RAILED" alog81027

The FC keeps losing IR lock, it says "LO SERVO RAILED" pretty much as soon as the LO_LR grd startings working after the FC locks IR.

02:28 UTC lockloss, IMC tag

00:44 UTC lockloss, ASC_AS_A and IMC lost lock ~10 ms apart.

TITLE: 11/02 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently Observing at 157Mpc and have been Locked for over an hour. We relocked many times today and relocking tended to take a bit long due to many locklosses, but for the most part was hands-off. The only things that required help were 1) during both initial alignments I ran today, when we got to aligning PRC, the IMC unlocked and could not relock - every time it would relock the FSS would glitch and unlock. To solve this, I waited until the PSL_FSS guardian was in READY_FOR_MC_LOCK, and then I paused it. Then, I waited for the IMC to lock and it would lock fine that next try, and once it had been locked for a few seconds, I unpaused the PSL_FSS guardian (tagging OpsInfo) and 2) one of the times when we were in GREEN_ARMS, ALS_XARM was stuck in CHECK_CRYSTAL_FREQUENCY, but taking it to UNLOCKED and then ETM_TMS_WFS_OFFLOADED fixed it right away.
LOG:

14:30 Observing and locked for over 3 hours
14:47 Superevent S241102cy

15:17 Lockloss
    15:17 Started an initial alignment
        IMC lost lock when trying to align PRC
            - Every time it would relock, the FSS would oscillate and cause the IMC to lose lock again & FSS would lose lock
            - I paused the FSS guardian once the FSS was locked and then unpaused once the IMC was good and locked
    15:40 Initial alignment done, relocking
    16:12 Lockloss from MOVE_SPOTS
17:04 NOMINAL_LOW_NOISE    
17:05 Observing

17:13 Lockloss
18:05 NOMINAL_LOW_NOISE
18:08 Observing

18:38 Lockloss
    18:38 Started an initial alignment
        - Same issue as before - during PRC the mode cleaner unlocks and cannot relock due to the FSS glitching and unlocking.
            Steps that have worked for me: (tagging Ops)
            1) Wait until the PSL_FSS guardian is in READY_FOR_MC_LOCK
            2) Once it is, pause PSL_FSS
            3) Wait for IMC to lock
            4) Once it has, unpause PSL_FSS
        - For some reason, even once the FSS and IMC were locked and we were aligning PRC, the ISS diffracted power was jumping all over the place
    18:58 Initial alignment done, relocking
        - ALS_XARM CHECK_CRYSTAL_FREQUENCY issue - toggling Force/No Force did not work, so I changed ALS_XARM to AUTO and then took it to UNLOCKED. I selected ETM_TMS_WFS_OFFLOADED and it locked immediately before I could troubleshoot further
19:48 NOMINAL_LOW_NOISE
19:52 Observing

20:08 Lockloss
22:15 NOMINAL_LOW_NOISE
22:15 Observing                                                                                                                                                                                   

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

Building on work last week, we installed a 2nd PI AI chassis (S1500301) in order to keep the PI signals separate from the ESD driver signals.  Original PI AI chassis S1500299.

We routed the LD32 Bank 0 thorugh the first PI AI chassis to the ESD drive L3, while keeping the old ESD driver signal driving the PI through the new PI AI chassis.

We routed the LD32 Bank 1 to the L2 & L1 suspension drive.

We did not route LD32 Bank 2 or Bank 3 to any suspensions.  The M0 and R0 signals are still being driven by the 18 bit DACs.

The testing did not go as smoothly as planned, a watchdog on DAC slot 5 (the L1&L2 drive 20 bit DAC) continousouly tripped the ESD reset line.  We solved this by attaching that open DAC port (slot 5) to the PI AI chassis to clear the WD error.

Looks like we made it to observing.

F. Clara, R. McCarthy, F. Mera, M. Pirello, D. Sigg