TITLE: 11/10 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Calibration
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
The morning was plagued with IMC Fault issues alog . 

After simply holding ISC_LOCK in  DOWN and holding IMC in LOCKED [ Specifically  to Not be in "ISS_ON " ] to wait for the IMC to be calm before starting to relock. Then wait again for a 5.8M EQ from Panama, I was able to get a lock all the way to Observing.

I was able to pass a locked IFO to Ibrahim.


LOG:                                                                                                                                                                                                                                                                                               

Calibration Sweep done with new ini file Louis asked us to use for Simulines: /ligo/groups/cal/H1/simulines_settings/newDARM_20231221/settings_h1_20241005_lowerPcal_higherPUM.ini

Broadband Start Time: 1415232600

Broadband End Time: 1415204090

Simulines Start Time: 1415233192

Simulines End Time: 1415234617

Files Saved:

2024-11-10 00:42:42,493 | INFO | Commencing data processing.
2024-11-10 00:42:42,493 | INFO | Ending lockloss monitor. This is either due to having completed the measurement, and this functionality being terminated; or because the whole process was aborted.
2024-11-10 00:43:19,012 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20241110T001937Z.hdf5
2024-11-10 00:43:19,020 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20241110T001937Z.hdf5
2024-11-10 00:43:19,025 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20241110T001937Z.hdf5
2024-11-10 00:43:19,030 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20241110T001937Z.hdf5
2024-11-10 00:43:19,034 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20241110T001937Z.hdf5
ICE default IO error handler doing an exit(), pid = 3252963, errno = 32

TITLE: 11/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 122Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 0mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.43 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 21:24 UTC

Since we are thermalized, I am about to go into CALIBRATION for our calibration sweep of the day.

TITLE: 11/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.44 μm/s
QUICK SUMMARY:

I set ISC_LOCK into Idle while waiting for the 5.8M Earthquake to stop shaking us for a few minutes.

I've been tryign to get this IFO to lock since I walked in this morning.
The IMC is unlocking and going into Fault at random times in the Locking process and In the Initial Alignment process.
15:47UTC
15:56:31 UTC
And multiple other times, including when I had taken ISC_LOCK to IDLE.
I called Elenna to try an confirm where this glitch was coming from and was the reason that I was losing all my locks.



Observing reached at 21:24 UTC
 

Sat Nov 09 10:05:20 2024 INFO: Fill completed in 5min 17secs

Note to FMCS, MY chilled supply water temp increase which started around 9am Fri 08nov2024 PST.

TITLE: 11/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 4mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.40 μm/s
QUICK SUMMARY:
Walking in I was greeted with ISC_LOCK in Engage Soft Loops.
Unfortunately we lost lock at Transition_From_ ETMX  and again at DRMI
Starting an Initial_Alignment

Notes on OWL:
IFO called Ryan early in the morning https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=81160.
Over the Owl Shift there were a number of locks and locklosses, I'll follow up with a comment to this alog with more information about each lockloss.

H1 called for assistance from the 2 hour "NLN" locking timer expired, We were at LOWNOISE_COIL_DRIVERS and reached NLN shortly after and Observing at 10:41 UTC. I didn't have to touch anything. 

TITLE: 11/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:

I was passed a Locked IFO:
Lockloss potentially Caused by PSL issues:  https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1415141124

Relocked by 23:38 UTC
Lockloss potentially Caused by PSL issues https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=81153

Relocked by 3:50 UTC after an Initial Alignment
Unknown Lockloss https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=81156

H1 Is currently Locked and Observing for 2 Hours.
Everything is currently running smoothly now.

LOG:
Josh -> H2 building to retrieve laptop.

J. Freed,

PRM shows very little coupling but there was a strong ~9.6Hz unknown noise was introduced.

Yesterday we did damping loop injections on all 6 BOSEMs on the PRM M1. This is a continuation of the work done previously for ITMX, ITMY, PR2, and PR3

As with PR3, gains of 300 and 600 were collected (300 is labled as low_noise).

The plots, code, and flagged frequencies are located at /ligo/home/joshua.freed/20241031/scrpts. While the diaggui files are at /ligo/home/joshua.freed/20241031/data. This time, 600 gain data was also saved as a reference in the diaggui files (see below), saved in 20241107_H1SUSPRM_M1_OSEMNoise_T3_LN.xml

Unknown Lockloss
This Lockloss does not have the same PSL_FSS signal signaturet that the previous locklosses tonigh have had.

Vickie and I are both thinking that this was a different type of lockloss then what we have seen earlier tonight.

Another lockloss
Looks like this lockloss may have also been an IMC/ PSL-FSS issue.
 

TITLE: 11/08 Eve Shift: 0030-0600 UTC (1430-2200 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 1mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.43 μm/s
QUICK SUMMARY:
H1 has been locked for 1 hour.
All systems running well.
Lockloss potentially Caused by PSL issues

The first Channels that show motion is the H1:PSL-FSS_FAST_MON_OUT_DQ

Relocking now, Currently @  Engage soft loops.

FAMIS 26448 : Trend the BRSX & BRSY Drift

The minute  trends of the driftmon for BRSX hav 2 spikes but both of those are from Jim adjusting the BRSX on Sep 19th and Sep 24th.

TITLE: 11/08 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Putting my alog in early since I'm leaving early. Currently observing at 160Mpc and have been Locked for 50 minutes. Secondary useism is high-ish, but we just went back to CALM from USEISM. The relock attempt from when I came in this morning wasn't too bad, and then relocking after the lockloss was also not bad besides SRM tripping during SRC align in IA and not wanting to lock SRC.
LOG:

15:30 In PREP_FOR_LOCKING
    - stuck?
15:42 DOWN and then started relocking
    16:28 Lockloss from MAX_POWER
    16:43 Lockloss from ACQUIRE_DRMI_1F
    16:45 Started an initial alignment
    17:04 Initial alignment done
17:55 NOMINAL_LOW_NOISE
17:59 Observing

20:17 Lockloss due to earthquake
    20:25 Started an initial alignment
        - SRM WD tripped during SRC aligning
            - I raised the WD trip level for SRM M3 to 200 from 150 since we get this tripping quite a bit
            - Tried SR2 align and AS centering again, didn''t work
            - Left IA
    20:56 Left IA, relocking
21:46 NOMINAL_LOW_NOISE
22:05 Observing

Summary:

Attached shows a lockloss at around 11:31 PST today (tGPS~1415043099). It seems that the fast shutter, after it was shut, bounced down to momentarily unblock the AS beam at around the time the power peaked.

For this specific lock loss, the energy deposited into HAM6 was about 17J and the energy that got passed the fast shutter is estimated to be ~12J because of the bouncing.

Bouncing motion was known to exist for some time (e.g. alogs 79104 and 79397, the latter has an in-air slow-mo video showing the bouncing), it seems as if the self damping is not working. Could this be an electronics issue or mechanical adjustment issue or something else?

Also, if we ever open HAM6 again (before this fast shutter is decomissioned), it might be a good idea to make the shutter unit higher (shim?) so the beam is still blocked when the mirror reaches its lowest position while bouncing up and down.

Details:

The top panel shows the newly installed lockloss power monitor (blue) and ASC-AS_A_DC_NSUM which monitors the power downstream of the fast shutter (orange).

The shutter was triggered when the power was ~3W or so at around t~0.36 and the ASC-AS_C level drops by a factor of ~1E4 immediately (FS mirror spec is T<1000ppm, seems like it's ~100ppm in reality).

However, 50ms later at t~0.41 or so, the shutter bounced back down and stayed open for about 15ms.  Unfortunately this roughly coincided with the time when the power coming into HAM6 reached its maximum of ~760W.

Green is a rough projection of the power that went to OMC (aka "AS_A_DC_NSUM would have looked like this if it didn't rail" trace). This was made by simply multiplying the power mointor itself with  AS_A_DC_NSUM>0.1 (1 if true, 0 if false), ignoring the 2nd and 3rd and 4th bouncing.

All in all, for this specific lock loss, the energy coming to HAM6 was 16~17J, and the energy that got past FS was about 11~12J because the timing of the bounce VS the power. OMC seems to be protected by the PZT though, see the 2nd attachemt with wider time range,

The time scale of the lock loss spike itself doesn't seem that different from the L1 lock loss in LLO alog 73514 where the power coming to HAM6 peaked tens of ms after AS_A/B/C power appreciably increased.

OMC DCPDs might be OK since they didn't record crazy high current (though I have to say the IN1 should have been constantly railing once we started losing lock, which makes the assessment difficult), and since we've been running with bouncy FS and the DCPDs have been good so far. Nevertheless we need to study this more.