Requesting OBSERVATION to VIS guardians except ETMX was moved from ENGAGE_SUS_LINES to ENGAGE_WHITENING_FILTERS. But requesting LOW_NOISE to VIS guardians was still in DISENGAGE_SUS_LINES. For this reason, states of VIS guardians depend on the transition history of LSC_LOCK guardian. For removing this problem, we need to remove LOW_NOISE requests to VIS guardians except ETMX from DISENGAGE_SUS_LINES.
It probably occurrs only when we did the calibration measurements. So it's not so an urgent bug. But it's better to fix it until next calibration measurements in order to reduce human mistakes in the updates of calibration.
On today's calibration work (klog#34090), we requested OBSERVATION to VIS guardians manually for going back to OBSERVATION without guardian modification. A same issue should be occur in the morning calibration measurements (I haven't found a repot yet). It's better to check there is no wrong acceptance of SDF during the morning activities or not.
After the calibration parameter updates, we confirmed only changes are foton filters for optical gain and actuator efficiencies (Fig.1) and SDF tables (Fig.2-3) for pcal beam position (klog#34095) and line tracking (klog#34096) parameters.
There is no update in guardians (Fig.4) and models (Fig.5), so we skipped the check with lockloss-relock cycles by guardian. After then, we raised CFC_LATCH in order to move from CALIB_NOT_READY to READY.
Following differences were accepted (Fig.1) related calibration updates and were reverted (Fig.2) for removing numerical error issue.
k1calcs
K1:CAL-CS_TDEP_{PCAL,SUS}_LINE{1,2,3}_*
Please find them in JGW-L2314962. They are the parameters for tracking calibration lines with latest calibration parameters in klog#34090.
Pcal SFDs were accepted.
Related report: klog34094
K1:CAL-PCAL_{EX,EY}_TCAM_{MAIN,PATH1,PATH2}_{X,Y}
CAL group
We did the calibration measurements and haven't found strange results.
Estimated parameters in the Pre-maintenance measurements are as follows.
H_etmxtm = 3.87175e-14 @10Hz ( -0.1% from previous measurements)
H_etmxim = 1.55407e-14 @10Hz ( -5.5% from previous measurements)
Optical_gain = 2.187716e12 ( -0.5% from previous measurements)
Cavity_pole = 17.99656 Hz ( -0.4% from previous measurements)
Previous values are listed in klog#34048.
Fig1. shows the fitting results of pre measurements.
Estimated parameters in the Post-maintenance measurements are as follows.
H_etmxtm = 3.878432e-14 @10Hz ( 0.17% from pre-maintenance measurements)
H_etmxim = 1.589672e-14 @10Hz ( 2.3% from pre-maintenance measurements)
Optical_gain = 2.191044e12 ( 0.15% from pre-maintenance measurements)
Cavity_pole = 18.04787 Hz ( 0.28% from pre-maintenance measurements)
Fig2. shows the fitting results of post measurements.
After the calibration parameter updates, we confirmed only changes are foton filters for optical gain and actuator efficiencies (Fig.1) and SDF tables (Fig.2-3) for pcal beam position (klog#34095) and line tracking (klog#34096) parameters.
There is no update in guardians (Fig.4) and models (Fig.5), so we skipped the check with lockloss-relock cycles by guardian. After then, we raised CFC_LATCH in order to move from CALIB_NOT_READY to READY.
Here is a update of the 7 blasting between 2025/05/30 18:10:00 UTC and 2025/06/05 13:26:35 UTC.
- no time: the interferometer survived the blasting at OBSERVATION state
- suvival ratio: 0% = 0/7
- 6 times: lockloss occurred from OBSERVATION state
- The amplitude of the seismic motion was large enough to make the lockloss.
- The bomb size were 25.2, 39.6, 28.4, 26.8, 27.2, 20.2. The plots are available at DAC wiki.
- 1 times: interferometer was not in observation state.
Note that sometimes the reported time and blasting execution time are different. In maximum, the blasting happened 4 minutes earlier than the reported time.
A CAL Tcam session was performed to obtain beam position information necessary for Pcal. The parameters have already been updated, and SDF is expected to be accepted.
Operator: Dan Chen
Update Time: 2025/06/06 16:14:20
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EX_TCAM_PATH1_X | 2.39397 mm | 2.61720 mm | +0.22323 mm |
| K1:CAL-PCAL_EX_TCAM_PATH1_Y | 62.83238 mm | 62.33808 mm | -0.49430 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_X | -0.77319 mm | -0.54384 mm | +0.22935 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_Y | -64.56790 mm | -65.08563 mm | -0.51773 mm |
Update Time: 2025/06/06 16:16:04
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EX_TCAM_MAIN_X | 3.85852 mm | 3.62544 mm | -0.23307 mm |
| K1:CAL-PCAL_EX_TCAM_MAIN_Y | 10.68901 mm | 10.71490 mm | +0.02588 mm |
Update Time: 2025/06/06 16:17:08
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EY_TCAM_PATH1_X | -0.07254 mm | -0.37174 mm | -0.29920 mm |
| K1:CAL-PCAL_EY_TCAM_PATH1_Y | 61.06124 mm | 60.86531 mm | -0.19593 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_X | -0.05695 mm | -0.33094 mm | -0.27399 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_Y | -70.29661 mm | -70.46008 mm | -0.16347 mm |
Update Time: 2025/06/06 16:18:02
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EY_TCAM_MAIN_X | 5.06633 mm | 6.12295 mm | +1.05662 mm |
| K1:CAL-PCAL_EY_TCAM_MAIN_Y | -3.20391 mm | -3.00409 mm | +0.19982 mm |
[Kimura]
Technical staff reported that the air compressor next to the IXC (see attached photo) is in operating condition.
Since the temperature around the IXC will change if it is stopped, we discussed the matter with Ushiba-san and decided to leave it as it is until next week.
　We need to discuss about stopping the air compressor early next week.
I changed the segment file that Hveto is using from K1GRD_LOCKED to K1-GRD_SCIENCE_MODE.
- Omicron
I changed the threshold of the 15 minute segment script for Omicron from "K1:GRD-IFO_STATE_N == 100" to "K1:GRD-LSC_LOCKED_STATE_N == 10000".
We checked the shapes of 1st violin peaks before and after the cooling down the payload.
(Calibration accuracy of the 4/26 was unclear..., so this is just the comparison)
Before cooling (Blue, 4/26 12:00 UTC)
IX 91.8 K
IY 91.0 K
EX 84.5 K
EY 81.2 K
After cooling (Red, 6/5 16:00 UTC)
IX 90.1 K
IY 43.1 K
EX 43.2 K
EY 59.2 K
I can see several peaks became something narrow, but we need to investigate more (Fitting and/or ring down measurements?)
Note : the identification of violin peaks
https://klog.icrr.u-tokyo.ac.jp/osl/?r=32643
I performed the lockloss investigation for the recent lockloss from the OBSERVATION state of the LSC_LOCK guardian, between 2025-06-05 01:22:05.687500 UTC and 2025-06-06 01:49:44.812500 UTC. The previous lockloss investigation was posted in klog34073. During this period, there were 10 lockloss from the OBSERVATION state. The plots are listed in DAC wiki.
1~10Hz seismic motion made the IMC lockloss
For 4 lockloss, we saw the excess of the seismic motion with 1~10 Hz, which made the oscillation of the IMC length control and caused the IMC lockloss.
- 2025-06-05 13:26:37.312500 UTC (2399s)
- 2025-06-05 14:52:34.562500 UTC (2889s)
- 2025-06-05 21:01:22.062500 UTC (925s)
- 2025-06-06 01:21:00.312500 UTC (4432s)
Excess of OMC DCPD and coincidence with ETMY MN oplev transient
For 1 lockloss, we saw the excess of OMC DCPD (K1:OMC-TRANS_DC_SUM_OUT_DQ and K1:OMC-TRANS_DC_{A, B}_IN1_DQ) from -10 s, as shown in Figure 1. We are not sure the origin of this excess.
Separately, Figure 2 shows the excess of OMMT2 TRANS at -23, 19, and -5 s. These excess has a coincidence with the transient behavior of K1:VIS-ETMY_MN_OPLEV_TILT_SUM_OUT_DQ.
Memo1: Transient of ITMY and ETMY MN oplev sum
Note that this will not be related to the lockloss.
Figure 3 shows the oplev sum of ITMY and ETMY over a four hours. Sometimes we can see the transient behavior in the oplev sum of ETMY MN. It has a coincidence with the OMMT2 TRANS, as shown in Figure 4. And also, we can see the transient shift of the oplev sum of ITMY MN. As I heard from Yokozawa-san, this seems to be a mode hop.
Memo2
The duty cycle of June 5 was 71 %.
And I found when the oscillation of the SR2 TM Y became more than +/- 2urad, this scattered light happened as shown in Fig.1.,
The threshold(+/- 2urad) exceeded around 2nd June. and when the oscillation became relatively smaller, the scattered light noise at MICH also became smaller.
And actually, the oscillation of the SR2 yaw was about 0.2 Hz.
We don't know the noise path from SR2 to MICH scattered light, the reason of scattered light may come from the SR2 yaw oscillation.
[Shih-Hong, Yuzurihara]
As a continuous analysis of klog34029, we checked the Gauch page and found the MICH channel shows the non-Gaussian behavior in 10~20 Hz. Figure 1 shows an example of the Gauch. This phenomenon began on 6/2 at 14:00 UTC (Gauch).
Figures 2~4 show today's sensitivity and noise projection from MICH. The spectral shape of the sensitivity around 15 Hz is similar to the MICH shape.
In the summary page, you can see the time variation of the MICH spectrum. (This shoulder-ish shape looks like the scattered light noise.)
Figure 5 shows the Q-spectrogram (by Pastavi) of the MICH error signal. This noise is a scattered light noise. By rough eye check, the frequency of the scattered object seems to be 0.2 Hz. (= ~12 period/60 s)
Yokozawa-san will report his continuous analysis.
And I found when the oscillation of the SR2 TM Y became more than +/- 2urad, this scattered light happened as shown in Fig.1.,
The threshold(+/- 2urad) exceeded around 2nd June. and when the oscillation became relatively smaller, the scattered light noise at MICH also became smaller.
And actually, the oscillation of the SR2 yaw was about 0.2 Hz.
We don't know the noise path from SR2 to MICH scattered light, the reason of scattered light may come from the SR2 yaw oscillation.
[YamaT-san, Miyakawa-san, Ikeda]
Since the TIM and ADC error lights were on for the following model, We performed a DiagReset.
We performed the reset with the intention of confirming whether the issue recurs during future observations.
13:39 DiagReset
Error
k1iopmcf0 TIM, ADC
k1pemmcf0 TIM
k1iopiy0 TIM, ADC
k1pemiy0 TIM
k1ioppx1 TIM, ADC
1154 mine in
1157 server room in
1158 disk array open
1200 forced fail
1201 disk replace
1202 add hot spare
1203 disk array close
1204 fix ntp TZ
1206 server room out
1208 mine out
[YamaT-san, Ikeda]
This is work related to K-Log#33393.
We have replaced the HDD on Disk9 Pod1.
Disk6 Pod1 will not be replaced now.
If the number of errors increases, it will be replaced.
I changed the segment file that Hveto is using from K1GRD_LOCKED to K1-GRD_SCIENCE_MODE.
- Omicron
I changed the threshold of the 15 minute segment script for Omicron from "K1:GRD-IFO_STATE_N == 100" to "K1:GRD-LSC_LOCKED_STATE_N == 10000".
The fowlloing paramters were updated based on the CAL Tcam session reported klog34078.
K1:CAL-PCAL_{EX,EY}_TCAM_{MAIN,PATH1,PATH2}_{X,Y}
Pcal Tcam sesion was performed before today's maintenance works.
Beam position information channels were updated and the SDF was accepted.
We plan to update them again after maintenance works.
[Kimura and Yasui]
We turned on #33, #37, #39, and #31 ion pumps in EX area.
After the ion pumps were turned on, the GV between the T-pipe and TMP was closed except for the #39 TMP.
#39 TMP has an interlock circuit (K-log 33547) and the pump unit is pumped in parallel with the TMP and ion pump.
Miyoki-san informed me that remote desktop is not working on k1ctr17.
I tried to reboot from remote, but k1ctr17 hung up, so we went into the mine and force restarted WS.
After restarting, we confirmed that k1ctr17 works fine.
Sawada, Takahashi, Uchiyama
We closed the GV between TMP(#36) and the T-shape duct to isolate TMP from the vacuum system. Since this TMP does not have the interlock system, it could cause serious trouble.
On the other hand, we did not want to change the temperature condition in the Yend area, so we decided not to stop the TMP and to close the GV to separate the TMP from the IFO.
CAL lines in high frequency for the cross-check purpose doesn't seem to be enabled.
Attachment shows the comparison plots at calibration lines between DARM and witnesses below 100Hz (Fig.1) and above 100Hz (Fig.2).
Essential calibration lines shown below are enabled. So line tracking can be done in minimum.
- EXTM: 27.650Hz for actuator efficiency
- Px1: 28.670Hz for actuator efficiency
- Px2: 31.530Hz for optical gain and cavity pole
- Px3: 507.890Hz for optical gain and cavity pole
And also, a line for the cross-check between Pcal-X and Pcal-Y are also enabled.
- Py1: 32.790Hz for cross-check between Pcal-X and Pcal-Y
On the other hand, lines for checking HF doesn't seem to be enabled. Roughly 1-2hrs integration to see them on DARM. So it's difficult to see on the quick check. But now they are not seen also on RxPD. We need to consider permissions (is this change acceptable), procedures (how to enable them), and a schedule (when they can be enabled), etc.
- Px4: 2002.010Hz
- Px5: 2998.730Hz
Shift time: 9 - 17 (JST)
Summary:
Check Items:
VAC, CRY, TEMP: no problem
IFO state:
9:00 Ready　
9:45 lock loss (maybe due to the blasting of the tunnel excavation works)
10:17 Ready
10:22 lock loss
11:03 Ready
16:10 lock loss ("ISC_WD_L" by lock-loss monitor)
17:05 IFO was down during lock procedure ("1 Hz IMCL" by lock-loss monitor)
17:23 Ready
I performed the lockloss investigation for the recent lockloss from the OBSERVATION state of the LSC_LOCK guardian, between 2025-06-04 06:24:36.937500 UTC and 2025-06-05 00:44:39.437500 UTC. The previous lockloss investigation was posted in klog34054. During this period, there were 6 lockloss from the OBSERVATION state. The plots are listed in DAC wiki.
1~10Hz seismic motion made the IMC lockloss
For 2 lockloss, we saw the excess of the seismic motion with 1~10 Hz, which made the oscillation of the IMC length control and caused the IMC lockloss.
- 2025-06-04 10:35:49.562500 UTC
- 2025-06-05 00:44:39.437500 UTC
From my experience, their cause seems to be blasting. I will wait for the report on the actual blasting execution time.
Long-term stability of alignment
Thanks to the modification of the BPC for ETMY pitch (klog34016) on June 2, the lock duration is now longer and more stable. I focused on the drift of the alignment control, such as ASC or BPC.
Figure 1 shows the BPC error and feedback signals. It takes 2 hours to reach an equilibrium of BPC for PRM YAW. It takes 30 minutes to reach an equilibrium of BPC for ITMX YAW. Figure 2 shows the oplev signals. The amount of shifting the PRM seems ~2 urad.
Except for this, I didn't see a significant drift of the alignment control (ASC and BPC).
Oscillation of ASC control
Figure 3 shows the oscillation of IR trans and DHARD_P at -1 min. Coincidentally, we can see the excess of OMMT2 TRANS. This oscillation can be seen in other ASC and BPC (Figures 4 and 5).
Memo
Figure 6 shows the duty cycle on June 3 and June 4. They were 76% and 71%, respectively.
