• Summary of lock trial from Down to OBSERVATION state
  • success of lock acquisition = 913 / 1129
  • fail of lock acquisition         = 216 / 1129
  • probability to success lock trial = 80.9 [%]
• In the lock trial, it failed at the following state and moved to Down state.
  •  'LOCK_PREP': 0,
     'LOCKING_ALS_XY': 1,
     'ALS_XY_LOCKED': 145,
     'SET_LASER_POWER_NORM': 5,
     'ENGAGE_ALS_CARM': 42,
     'ALS_CARM_LOCKED': 1,
     'ENGAGE_FNC_XY': 5,
     'ENGAGE_ALS_DARM': 9,
     'ALS_DARM_LOCKED': 0,
     'FIND_IR_RESONANCES': 6,
     'ENGAGE_MICH_3F': 0,
     'MICH_3F_LOCKED': 0,
     'HANDOVER_ALS_TO_IR': 2,
     'FPMI_LOCKED_WITH_3F': 0,
     'TRANSITION_TO_1FSIG': 0,
     'FPMI_LOCKED': 0,
     'TRANSITION_TO_LOW_NOISE': 0,
     'OBSERVATION': 913
  • where the left name is the state name of LSC guardian and the right number is how many times the lock trial failed at that state.
  • From these numbers, the bottleneck of the LSC guardian seems the `ALS_XY_LOCKED` and `ENGAGE_ALS_CARM`.
  • I will prepare the list of date and time when the lock trial failed for the deeper investigation.

• Graph of livetimes in each state.
  • the x-axis represents a state of Guardian
  • the y-axis represents a cumulative livetime [hour]
• The part that took the longest to pass the state is ‘FIND_IR_RESONANCES’.
  • The second longest is ‘LOCK_PREP’.
  • The third longest is ‘ENGAGE_ALS_DARM’.
  • The forth longest is ‘HANDOVER_ALS_TO_IR’.

I outputed the list of the date and the time when the lock trial failed.  You can find the csv file on JGW doc.

Next, I will check the behaviour of Green-X/Y power just before moving the Down state.

• Histogram of Time Duration in each state.
  • In almost all state, most values are in one bin, which indicates the control worked correctly.
• ‘FIND_IR_RESONANCES’ state, which took the longest  to pass, sometimes took more than 10 min.
  • This state was reached 921 times, and the number of times it took more than 10 min was 7.
  • the probability to took long time = 0.76 [%]

I attach two pdf files.

• first pdf
  • list of lock loss befor touching `OBSERVATION` state.
  • The lock trial failed at specific state. I sorted the list by `stay time` which is how long the guardian stays at that state during lock trial.
  • Longest five trials are `FIND_IR_RESONANCE`. This is a well-known fact as I heard from Ushiba-san.
• second pdf
  • list of lock loss including all states (from OBSERVATION and from others).
  • When I check `previous_state_s` on the list, I can see the series of failures for the lock trials at
    • 12/29 1:54 JST ~ 2:00 JST
    • 12/29 17:22 JST ~ 17:23 JST
    • 1/2 3:41 JST ~ 3:54 JST
  • Before 1/2 3:30 JST, the interferomter can reach `OBSERVATION` state with 1~4 lock trials.
    • It might be informative to know the typical value of how long we need to recover the lock after lossloss from OBSERVATION state. (Probably that value depends on the weather or the seismic activity...)
  • But, after 1/2 3:30 JST, the lock trial failed at the state_n >= 110, such as FIND_IR_RESONANCE, ENGAGE_FNC_XY, ENGAGE_ALS_DARM.
    • I'm wondering this is due to the bad alignment.

I made histograms of time duration with all events and the events of when the lockloss occurred at the state. The green bars are made with the former, and the red bars with the latter.
“N”, which is in the label, represents the number of events. Y-axis is log scale.

• in ENGAGE_ALS_CARM state, I can see that when the lockloss occurred at this state, the time durations were short.
• similar signs are seen in SET_LASER_POWER_NORM, ENGAGE_FNC_XY, ENGAGE_ALS_DARM, and HANDOVER_ALS_TO_IR state, although the number of events is smaller.
• in FIND_IR_RESONANCE state, there was one event that occurred lockloss after taking a lot of time.

I created a histogram of recovery time, which is the time from the lockloss at the ‘OBSERVATION’ state to the next ‘OBSERVATION’ state.

• mean = 257.4 [sec] = 4.29 [min]
• median = 220.3 [sec] = 3.67 [min]

This is an investigation of laser powers (GRX/Y and IRX/Y) just before the lockloss

• I updated the csv file to include the normalized power of GreenX/Y and IR X/Y. Previously I included the data of NOT normalized power. See pdf.
• I checked the laser powers (GRX/Y and IRX/Y) which were averaged between 2 seconds ~ 5 seconds just before the lockloss. I attach pdf of histogram.

[Yamamura, Yuzurihara]

We are invesgating the correlation or coincident drift between laser powers(GR-X/Y, IR-X/Y) and the temperatures, during the observation state. I attach one example.

• We checked the data which lost the lock at 2022/12/29 12:7:46 UTC. The lock continues more than 2000 s.
• We can see the drop of IR laser just before the lockloss. But, the temperature data doesn't change during the lock.
• As I heard from Oshino-san, we should use the PT100 data for PSL room. We will replace the channel name.
• As a next step, we will add more temperature data for this comparison.

I updated the plot to compare laser powers(GR-X/Y, IR-X/Y) and the temperatures during 12/28 ~ 1/3 UTC. I attach plot.

From quick look,

• the powers of lasers are decreasing in time
  • Especially, GreenY power was ~0.6 on 1/3
• the temperatures in the several clean booth (such as SR2, SR3, PR2, BS, MCE) are decreasing in time.
  • this drift might be related to decreasing the laser power.
  • the other temperature looks no-drift and looks just osilating.
• I guess the cause of decreasing the laser power is due to getting the bad alignment. But, the cause might be due to the mixture of bad alignment and the effect of temperature drift.

I checked long term trend of laser powers(GR-X/Y, IR-X/Y), temperatures, and oplev signals. See image.

Comment (see commented image)

• Most of oplev signal are no-drift and stable
• MCI_TM_WIT_P and MCO_TM_WIT_P have drifting. The trend direction is opposite.
  • Does this trend affect the magunitude of lase powers?
  • I checked the temperatures which are coincident with trend of MEI and MCE. But, temperatures of MCE and MCF are not coincident.
• MCE_TM_WIT_Y started the fluctuation after 12/30.
  • Is it related to ASC? Hirose-san, do you have a comment?
• IMMT2_TM_WIT_P and IMMT1_TM_WIT_P have sudden changes.

[Yokozawa, Yuzu]

We investigated the cause of sudden chenge on IMMT2 pitch. See image.

Two big changes happend...

• at 2022/12/29 8:21:50 UTC.
  • LSC guardian was in OBSERVATION state. Just after that, it went to DOWN state.
  • After this, the IMMT2-pitch changed from -22.2 to -26.8.
  • Coincident glitch happened at MCI, MCE, MCO, IMMT1, IMMT2-yaw, OMMT1, OMMT2. They are type-C suspension.
• at 2023/01/01 7:01:51 UTC.
  • LSC guardian was in OBSERVATION state. Just after that, it went to DOWN state.
  • After this, the IMMT2-pitch changed from -26 to -33.
  • Coincident glitch happend at MCI, MCO, OMMT1, OMMT2. They are type-C suspension.

Cause investigation

• In the seismometer, we can find the coincident ground motion. [12/29] [1/1]
  • Frequency band are relatively high (f>1Hz). So, we guess this happened due to fault offset (Dansoh-no-zure, in Japanese) at local area (called Do-area), not earthquake. About the fault around KAGRA site, see Miyoki-san's slide (page 7).
  • I attach the timeseries of seismometer around new-year. [image]

• Note that we observed the big drift on IMMT1, IMMT2, OMMT1, OMMT2 (especially PITCH direction) at the glitch time. We guess these suspension might be weak to the this kind of sesmic motion.

Interesting resutls, thanks.

Did you also check if there are no such glitch-like features in the other environment channels than the ground accelerometers?? For example, if the power supply ground changes, the similar glitches might appear most of the channels. Hopefully this is not the case this time.

Akutsu-san, thank you for your comment.

I checked the timeseries data (raw one and whitened one) of the other environment sensors such as microphone, accelerometer, voltage meter, by Pastavi.

• On microphones, there were no glitch-like features at the glitch times.
• On all the seismometers, we can see coincident glitches. (see [12/29] and [1/1])
• On voltage sensors (PSL_TABLE, IMCREFL_TABLE, REFL_TABLE, ISS_TABLE), I found the strange transition (up and down).  (see [12/29] and [1/1])
  • When we compare occurred times of glitch on IMMT2 and voltage sensor, the glitch on IMMT2 is earlier.
  • I guess the cause of transition on valtage came from the transition of IFO status, which was reported at [klog#23639]. 
• On one accelerometer, I found the coincident glitches around both time (see [12/29] and [1/1]). The location of accelerometer is around MCF table.
  • This glitch on accelerometer seems coincident with the transition of LSC_LOCK guardian (IFO state).

Order of occurrence

1. seismic motion (frequency is higher than 1Hz)
2. glitch or drift on Type-C suspension
3. (almost same time) interferometer went to Down (LSC_LOCK == Down). The voltage sensor transition happened (up and down). The glitch on accelerometer around MCF table occured

Related to klog#23492.

I was asked oftern how was the lockloss recover time during O3GK. So, I checked it.

When we removed the longest recover time (Due to stormy day, lockloss continued one day), the median = 726 s (12 min) and the mean = 998 s (16.5 min). [histogram is here]

The histogram with all the data is here.