Reports of 33703
VIS (SRM)
ryutaro.takahashi - 16:48 Tuesday 10 February 2026 (36327) Print this report
Preparation for SRM installation

I checked the condition around the SRM chamber.

Feedthrough flanges: The D-sub cables were put from the flanges to the cable rack (Picture #1) on the side of the booth.

  • ICF203 on the bottom chamber for the IRM damper. The present flange with one D-sub 9pin port will be replaced with the flange with four D-sub 9pin ports (Picture #2).
  • ICF203(P6) on the top chamber for the FLDACC H2 (Picture #3).
  • ICF203(P3) on the top chamber for the FLDACC H1 and H3 (Picture #4).

SRM mirror holder: I checked the mirror holder in the decicator for OMC. The holder was assembled with the jig (Pictures #5 and #6).

IRM damper: The parts for the IRM damper were delivered and checked in the booth (Picture #7).

 

Images attached to this report
MIF (ASC)
kenta.tanaka - 15:43 Tuesday 10 February 2026 (36325) Print this report
SOFT mode controll phase margin got small

Komori, Tanaka

We found that phase margins of the SOFT mode controll, especially Yaw controll, got small. Fig.1-4 show the OLTFs of SOFT mode controll. (Note:Soft mode controll filtters were not changed yet. So the controlls are the same as the O4c ones) 

We considered that the PY coupling in TMS QPDs become larger than before. So we check the PY coupling by injection.

First, we started to check Y2P coupling in CSOFT mode. we injected a 50 mHz sine wave into the loop from the K1:ASC-CSOFT_Y_SM_EXC port and measured the error signal spectra of the CSOFT P and Y respectively. fig. 5 shows the result. The error signal spectra are shown in the left upper panel.  As you can see, 50 mHz peak is in both CSOFT_{P,Y} error even though only Yaw was excited. 

Second, we checked P2Y coupling in CSOFT mode. Fig.6 shows the results. There seems to be 50 mHz peak in CSOFT_P but the peak cannot be seen in CSOFT_Y.  

Similarly, we checked Y2P, P2Y couplings in DSOFT mode. Fig. 7 and Fig. 8 show the results when P and Y was excited, respectively. Like CSOFT mode, Y2P coupling can be seen but P2Y coupling cannot be seen.

 

Images attached to this report
PEM (Center)
takaaki.yokozawa - 13:37 Tuesday 10 February 2026 (36326) Print this report
Installation of the accelerometers at the PSL room
I installed two portable accelerometers near the Shaker 1 and Shaker 4.
During this work, I kept the LSC_LOCK guardian with observation state, and IFO kept locking(Turned on the light, work on the optical table).

ACC1 (near the shaker1, Left plot)
K1:PEM-ACC_PSL_PORTABLE_1_OUT (no DQ channel...)

ACC2 (near the shaker2, Right plot)
K1:PEM-ACC_PSL_PORTABLE_2_OUT (no DQ channel...)

If possible, I would like to restart the DAQ after changing the k1pemmcf0 model (add them to DQ channel)
at the early morning 2/11(Wed)
Images attached to this report
PEM (Center)
takaaki.yokozawa - 9:04 Tuesday 10 February 2026 (36324) Print this report
PEM injection test 260210
I performed the PEM injection test, mini shaker injection test at the PSL room.
We need to install two accelerometers near the pedestal (periscope, shaker 1) and shaker 4

04:30 - 05:15 silent run

05:17:00 - 05:27:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, sweep injection, 900 - 1 Hz, 600 s, 10 cnt

05:27:00 - 05:37:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1,sweep injection, 900 - 1 Hz, 600 s, 20 cnt

05:38:00 - 05:48:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_10_EXC
Shaker 2, sweep injection, 900 - 1 Hz, 600 s, 10 cnt

05:48:00 - 05:58:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_10_EXC
Shaker 2, sweep injection, 900 - 1 Hz, 600 s, 20 cnt

06:03:00 - 06:13:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_11_EXC
Shaker 3, sweep injection, 900 - 1 Hz, 600 s, 10 cnt

06:13:00 - 06:23:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_11_EXC
Shaker 3, sweep injection, 900 - 1 Hz, 600 s, 20 cnt

06:28:00 - 06:38:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_12_EXC
Shaker 4, sweep injection, 900 - 1 Hz, 600 s, 10 cnt

06:38:00 - 06:48:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_12_EXC
Shaker 4, sweep injection, 900 - 1 Hz, 600 s, 20 cnt

06:51:00 - 08:00:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, swept sine injection, 400 - 50 Hz, 1 Hz resolution, 10 s in each frequency, 20 cnt

08:08:00 - 08:13:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 80 - 220 Hz, 2000cnt
Fig.1. showed the PSL, IMC related channels

08:13:00 - 08:18:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 180 - 320 Hz, 2000cnt
Fig.2. showed the PSL, IMC related channels

08:18:00 - 08:28:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 280 - 420 Hz, 2000cnt
Fig.3. showed the PSL, IMC related channels

08:28:00 - 08:33:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 380 - 520 Hz, 2000cnt
Fig.4. showed the PSL, IMC related channels

08:33:00 - 08:39:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 480 - 620 Hz, 2000cnt
Fig.5. showed the PSL, IMC related channels

08:39:00 - 08:44:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 580 - 720 Hz, 2000cnt
Fig.6. showed the PSL, IMC related channels

08:44:00 - 08:49:00
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC
Shaker 1, white noise injection, 680 - 820 Hz, 2000cnt
Fig.7. showed the PSL, IMC related channels

8:40 - 8:55 silent run

The detail investigation would be performed later
All xml files during the white noise injection can be found in
/users/PEM/diaggui/PEMInjection/Shakerinj_postO4/260210/
Images attached to this report
MIF (ASC)
kentaro.komori - 4:33 Tuesday 10 February 2026 (36323) Print this report
Comment to First trial of high bandwidth control of DHARD Yaw (36299)

[Tanaka, Ushiba, Komori]

Today, we tried a hierarchical control scheme for the yaw modes.
We measured the transfer function from the input of DHARD yaw to each TM oplev signal with the newly designed filter, as shown in the figure.
Assuming that the optical gain is flat, this is regarded as the estimated openloop transfer function.

We designed this filter to achieve a similar response for each suspension, in particular by inserting additional gains in the TM lock filters to match the high-frequency response.
The crossover frequency between the MN and TM is approximately 0.8 Hz, and the overall unity gain frequency is 2 Hz.

We found significant coupling from the pitch mode into DSOFT Y.
Therefore, we will apply this new filter after further decoupling of the pitch and yaw degrees of freedom.

Images attached to this comment
MIF (General)
takafumi.ushiba - 19:03 Monday 09 February 2026 (36322) Print this report
X arm cavity scan

Similar measurement with klog33306.

[Komori, Ushiba]

Abstract:

To measure the FSR of arm cavity, we conducted the cavity scan for X arm.
Analysis will be done tomorrow.

Detail:

To obtain the latest X arm and Y arm length, we tried to perform cavity scan of arms.
Today, we only finished X arm measurement but if the scan method is fine, we plan to perform Y arm scan with the same configuration tomorrow.

Followings are the procedure of the cavity scan.
1. Misaligned ITMY and PRM (request MISALIGNED state for ITMY guardian and MISALIGNED_BF state for PRM guardian).
2. Lock GRX by using XARM guardian (request ALS_LOCKED state).
3. Feedback ALS signals to IMC manually.
4. Increase laser power by rotating HWP at PSL.
5. Scan laser frequency by turning on/off FM1 of K1:ALS-SUM_OFS_SLOWOUT_CALI filter bank.

We modified the ramp time of FM1 of K1:ALS-SUM_OFS_SLOWOUT_CALI filter bank to make the scan speed about 1 kHz/s (100 seconds for ~2 FSR).
The start time of the scan is 8:20:04 UTC and 8:29:10 UTC for forward and backward scans, respectively.
Figure 1 and 2 shows the scan results when increasing and decreasing the offsets, respectively.

It is hard to see the sideband signals in transmission but PDH signals can be seen clearly, so probably this scan can be used for the analysis.
The analysis will be done tomorrow.

Note:

First, I tried to perform cavity scan for X and Y arm at the same time by closing laser shutter for GRY and did not misalign ITMY.
However, maybe due to the coupling between MICH fringes and photosensor signals, ITMX and ITMY were kicked a lot when increasing IMC output power.
So, we gave up scaning X and Y arm at the same time.

Followings are the detailed procedure to feedback ALS signals to IMC manually.
1. change K1:LSC-MCL_GAIN to 1.
2. Turn on FM4 of K1:LSC-MCL filter bank.
3. Close K1:IMC-SERVO_IN2EN switch.
4. Turn off FM2 of K1:LSC-MCL filter bank.
5. Increase K1:LSC-CARM_SERVO_IN2GAIN to 15.
6. Turn on 1st and 2nd K1:IMC-SERVO_COMBOOST.
7. Turn on FM5 of K1:LSC-MCL filter bank.

Diaggui files are stored at /users/Commissioning/data/XARM/2026/0209/.

Images attached to this report
MIF (General)
takaaki.yokozawa - 14:04 Monday 09 February 2026 (36321) Print this report
Comment to Mysterious GRX behavior 260208 morning (36316)
I checked the timing of recovering the IR and GR PDAs.

Fig.1. showed the time series
Blue : the timing of turning on the whitening filter circuit for the p/s pol signal
Orange : The timing of turning on the whitening filter circuit for the GR QPDs
green : The timing of turning on the whitening filter circuit for the IR QPDs

Obviously, the timing is same with the whitening filter circuit for the p/s pol signal.
We need to check some ground connection between BNC-Dsub converter and whitening filter circuit (and TMSX optical table???)
Images attached to this comment
IOO (OMC)
takafumi.ushiba - 13:45 Monday 09 February 2026 (36320) Print this report
Comment to OMC_LSC guardian stops due to the camera error (36311)

It is difficult to confirm the exact cause of user code errors, but it is very ikely that the problem was happened due to the very unfortune timing of the subprocess to remove the snapshot files.
To avoid this error, I deleted the function to remve the snapshot files during the OMC scan from the FIND_RESONANCE, FIND_RESONANCE_FOR_10W, and FIND_RESONANCE_FOR_IAL_WITH_RF states while adding this function at DOWN state.

Figure 1 shows the script I modified at DOWN state.
Figure 2 shows the script I commented out at FIND_RESONANCE state, which is same for the other FIND_RESONANCe states.

Images attached to this comment
MIF (General)
takaaki.yokozawa - 13:41 Monday 09 February 2026 (36319) Print this report
Comment to Mysterious GRX behavior 260208 morning (36316)
[Komori, Yokozawa]

Conclusion :
We can recovered the TMSX signals and initial alignment and PRFPMI RF LOCKED succeeded.
And I forgot to turn off the floor light, sorry...

Detail :
When we arrived the Xend station, we checked both EX0 rack and TMSX rack.
No problem in EX0 rack.
In the TMSX rack, we noticed that "the display of the power supply -18 V was off" (Left side of kikusui power supply)
Fig.1. showed the front panel of analog circuits.
Two coil driver (+15V LED on, -15 V LED off)
LVDT driver / LVDT ACT DISTRIBUTOR (unknown from front panel)
geophone distributor (+15V LED on, -15 V LED off ?)
whitening filter circuits (all turned off)
Michmura-san logger (on)
function generator (on)
+18 V power supply (on)
-18 V power supply (off)

We called YamaT-san how to recover the power supply, but during calling, "The power supply for -18 V suddenly recovered"
(Komori-san said, he touched the AC adaptor, but no turned on/off work, his mysterious power??)

After then, LVDT and Geophone value became several values
(We didn't check those value is significant value or not)

But, the IRX. GRX PDA signal didn't recover.
Even I injected the LED light signal, the response of the PDA value in the DGS system didn't change so much.
(At this time, both IRX and GRX PDA was turned on (green LED lumped),
my guess was PDA working well, but several trouble in BNC-Dsub converter analog circuits)

We cannot know why the whitening filter circuits were turned off, we called Ushiba-san.
Ushiba-san replied that there would be the safety trigger (some logic to turned off automatically)
Today, there is no analog circuit expert, we need to ask then the logic of turning off the analog circuits.
Anyway, we turned on the three whitening filter analog circuits, GR QPD values recovered.
For IR QPD value, we need to check after PRFPMI RF LOCK recovered.
For Xend transmission s/p-pol, I would like ask someone to check values.

This is a mysterious point, after turning on the three whitening filter, the IR and GR PDAs recovered automatically.

Then, initial alignment and LSC_LOCK trial performed, and finally PRFPMI RF LOCKED state succeeded.

Summary :
We found the power supply of the -18 V was turned off (no display and no LED on circuits) : Mysterious point 1
The power supply of the -18 V was suddenly recovered : Mysterious point 2
Whitening filter circuits were turned off : Checking point 1 (Ask analog circuit experts)
When whitening filter circuits were turned on, the IR and GR PDA suddenly recovered : Mysterious point 3
LVDT signal, geophone signal, coil output, p/s pol signal were not checked by Yokozawa and Komori-san : Checking point 2
Images attached to this comment
PEM (Center)
takahiro.yamamoto - 12:23 Monday 09 February 2026 (36318) Print this report
Comment to Cabling for the shaker injection at PSL room (36270)
I restarted all models on k1mcf0, because models downed around 2:40am on Feb. 8th due to probably timing glitches.
The Front-end computer was alive at this time.

MIF (General)
takafumi.ushiba - 11:20 Monday 09 February 2026 (36317) Print this report
LSC_LOCK guardian modification

As reported in klog36315, current LSC_LOCK guardian does not stop even when OMC_LOCK guardian stops and DC PD protection is no more working.
So, I modified the LSC_LOCK guardian so that LSC_LOCK guardian stops at the LOCK_PREP state if the latch switches for OMC is closed (fig1).

Images attached to this report
MIF (General)
takaaki.yokozawa - 10:19 Sunday 08 February 2026 (36316) Print this report
Mysterious GRX behavior 260208 morning
In this morning, I noticed that the LSC_LOCK state stopped the LOCKING_ALS_XY state.

By checking it, several strange behavior detected.

1. Mysterious TMSX signals
As shown in Fig.1., after the locked loss happened, the TMSX GR PD became lerger value (Four times larger than normal)
And SUM values of the GR QPD1,2 became minus value
After the 2nd locked loss, all PD, QPD SUM values became almost zero.
For those locked loss may not caused by the earthquake.

2. No change by turned on/off GRX shutter.
Those values didn't change the value even turned on/off the GRX shutter

3. gigE camera image
I backed the beam spot image of screen capture, the GRX beam image shifted from Fig.2. to Fig.3. (To left)
(Also GRY??)

4. TCam image
TCam image didn't change so muchas shown in Fig.4.

Anyway I requested DOWN state for LSC_LOCK guardian

More detail QPD signals can be found in Fig.5.
ALS-X input value didn't change during this lock
all QPD1,2 SEG1,2,3,4 values changed to -2000 ~-3000 (minus value was mysterious)
Fig.6. showed the Xarm ndscope

Some trouble in TMSX rack?
Fig.7. showed showed the PD, QPD, LVDT, ACC signals, and as a reference PEM channel and LSC_LOCK state.
At the same timing (-4h,52m), the behavior changed.
Fig.8. showed the very last stage of the 2nd locked loss (LSC_LOCK was ALS_DARM_LOCKED)
Also, the change of value occurred at the same time.
No significant change can be detected in PEM channel. (How about CAL channel?)

I checked all PEM channels around this lock loss.
K1:PEM-ACC_EXA_TABLE_TX,RX_Z_INMON and K1:PEM-MIC_EXA_BOOTH_EXA_Z_INMON had several offset?
(And MAG Y direction had some glitch??)
Images attached to this report
Comments to this report:
takaaki.yokozawa - 13:41 Monday 09 February 2026 (36319) Print this report
[Komori, Yokozawa]

Conclusion :
We can recovered the TMSX signals and initial alignment and PRFPMI RF LOCKED succeeded.
And I forgot to turn off the floor light, sorry...

Detail :
When we arrived the Xend station, we checked both EX0 rack and TMSX rack.
No problem in EX0 rack.
In the TMSX rack, we noticed that "the display of the power supply -18 V was off" (Left side of kikusui power supply)
Fig.1. showed the front panel of analog circuits.
Two coil driver (+15V LED on, -15 V LED off)
LVDT driver / LVDT ACT DISTRIBUTOR (unknown from front panel)
geophone distributor (+15V LED on, -15 V LED off ?)
whitening filter circuits (all turned off)
Michmura-san logger (on)
function generator (on)
+18 V power supply (on)
-18 V power supply (off)

We called YamaT-san how to recover the power supply, but during calling, "The power supply for -18 V suddenly recovered"
(Komori-san said, he touched the AC adaptor, but no turned on/off work, his mysterious power??)

After then, LVDT and Geophone value became several values
(We didn't check those value is significant value or not)

But, the IRX. GRX PDA signal didn't recover.
Even I injected the LED light signal, the response of the PDA value in the DGS system didn't change so much.
(At this time, both IRX and GRX PDA was turned on (green LED lumped),
my guess was PDA working well, but several trouble in BNC-Dsub converter analog circuits)

We cannot know why the whitening filter circuits were turned off, we called Ushiba-san.
Ushiba-san replied that there would be the safety trigger (some logic to turned off automatically)
Today, there is no analog circuit expert, we need to ask then the logic of turning off the analog circuits.
Anyway, we turned on the three whitening filter analog circuits, GR QPD values recovered.
For IR QPD value, we need to check after PRFPMI RF LOCK recovered.
For Xend transmission s/p-pol, I would like ask someone to check values.

This is a mysterious point, after turning on the three whitening filter, the IR and GR PDAs recovered automatically.

Then, initial alignment and LSC_LOCK trial performed, and finally PRFPMI RF LOCKED state succeeded.

Summary :
We found the power supply of the -18 V was turned off (no display and no LED on circuits) : Mysterious point 1
The power supply of the -18 V was suddenly recovered : Mysterious point 2
Whitening filter circuits were turned off : Checking point 1 (Ask analog circuit experts)
When whitening filter circuits were turned on, the IR and GR PDA suddenly recovered : Mysterious point 3
LVDT signal, geophone signal, coil output, p/s pol signal were not checked by Yokozawa and Komori-san : Checking point 2
Images attached to this comment
takaaki.yokozawa - 14:04 Monday 09 February 2026 (36321) Print this report
I checked the timing of recovering the IR and GR PDAs.

Fig.1. showed the time series
Blue : the timing of turning on the whitening filter circuit for the p/s pol signal
Orange : The timing of turning on the whitening filter circuit for the GR QPDs
green : The timing of turning on the whitening filter circuit for the IR QPDs

Obviously, the timing is same with the whitening filter circuit for the p/s pol signal.
We need to check some ground connection between BNC-Dsub converter and whitening filter circuit (and TMSX optical table???)
Images attached to this comment
MIF (General)
takafumi.ushiba - 11:01 Saturday 07 February 2026 (36315) Print this report
Request PRFPMI_RF_LOCKED state for LSC_LOCK guardian

Due to the trouble of OMC_LSC guardian, the protection function of DC PDS are not working well.
So, I requested PRFPMI_RF_LOCKED state to LSC_LOCK guardian  not to increase the laser power.

VAC (Valves & Pumps)
nobuhiro.kimura - 8:38 Saturday 07 February 2026 (36314) Print this report
Installation of an interlock circuit in the #3 pumping unit near GVbsx

[Kimura and Yasui]
 On Feb. 06, we installed an interlock circuit in the #3 pumping unit near GVbsx.
After installation, we confirmed that the interlock circuit works in the event of a power failure and that the shutoff valve between the dry pump and the TMP is closed.
 Additionally, an air-cooling fan unit was installed on the pump unit's TMP to enable air cooling.

Images attached to this report
MIF (ASC)
kentaro.komori - 3:40 Saturday 07 February 2026 (36313) Print this report
Comment to First trial of high bandwidth control of DHARD Yaw (36299)

[Tanaka, Komori]

Abstract:

We are continuing the implementation of a new filter to enhance the unity gain frequency (UGF) of DHARD yaw.
Our next approach is to implement a moderate-bandwidth filter that controls only the first and second yaw resonances, while avoiding control of the third resonance.

Details:

In the first trial, we observed oscillations above 10 Hz immediately after enabling the new filter.
This is likely because the gain at high frequencies was too large due to the use of multiple phase compensation filters, causing amplified signals to couple into other degrees of freedom.
Therefore, we decided to abandon, for now, the strategy of controlling all three yaw resonances and instead focus on controlling only the first (0.3 Hz) and second (1.8 Hz) resonances.

We designed the openloop transfer function as shown in the figure.
Phase compensation was implemented using four zero–pole filters, and a notch filter was added to prevent the third resonance at 3.1 Hz from surpassing the unity gain.
When we enabled the new filter, we again encountered oscillations above 10 Hz on several occasions, so additional notch filters were implemented accordingly.

We have not yet successfully closed the DHARD yaw loop.
This is likely because the CHARD yaw loop is still using the conventional low-gain filter.
In the next step, we will apply the same new filter to CHARD yaw and attempt to close the {D, C}HARD yaw loops simultaneously using the new filter.

Images attached to this comment
IOO (OMC)
takahiro.yamamoto - 3:04 Saturday 07 February 2026 (36312) Print this report
Comment to OMC_LSC guardian stops due to the camera error (36311)
An error itself comes from an implementation of the get_latest_file function which was not changed in today's update.
This function makes a run-time error when the picture file cannot be found in some reason.

I have no idea now why the picture file couldn't be found.
When I started to investigate this issue (maybe around 1:30?), there was no image file in any directories.
Did you remove taken pictures by manually?
I want to know whether a picture was taken but couldn't be found or a picture wasn't taken at all.

Investigation memo
According to the guardian logs, following procedure was executed.
1. FM4 of OMC-LSC_FB_FLT was turned ON.
2. CAM-OMC_TRANS_ARCHIVE_INTERVAL was changed to 1.
3. It takes 2-second long as waiting time by 'OMC_snapshot_timer'.
4. CAM-OMC_TRANS_ARCHIVE_INTERVAL was reverted to 0.
5. The get_latest_file function was called and it made a run-time error.

This condition is satisfied by executing
 933         elif ezca['OMC-TRANS_DC_SUM_OUTPUT'] >= ezca['OMC-LSC_TRIG_THRESHOLD_LO']:
934 ezca['OMC-LSC_TRIG_THRESHOLD_LO'] = 1
935 ezca.switch('OMC-LSC_FB_FLT','FM4', 'ON')
936 #Check the mode shape
937 ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 1
938 self.timer['OMC_snapshot_timer'] = 2
939 self.taking_snapshot = True
940
941 pattern = '/opt/rtcds/userapps/trunk/omc/k1/guardian/sounds/' + ezca['SYS-SOUND_OMC_LOCK_GLOB']
942 # kagralib.play_random_wavefile(pattern)
after then, executing
 891         if self.taking_snapshot:
892 if self.timer['OMC_snapshot_timer']:
893 ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 0
894 fname = get_latest_file('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*')
895 log(fname)
896 self.p = sp.Popen(['/opt/rtcds/userapps/trunk/cds/common/scripts/mode', fname],
897 stdout=sp.PIPE)
898 self.analyzing_mode = True
899 self.taking_snapshot = False

I simulated this condition as follows. But there was no problem to take a picture and to find it.
>>> from ezca import Ezca                                                                                                                                                                                                                                                                                                                                                   
>>> import glob
>>> ezca = Ezca()
>>> import time
>>> def func():
... ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 1
... time.sleep(2)
... ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 0
... print( glob.glob('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*') )
...
>>> print( glob.glob('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*') )
[]
>>> func()
K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 1
K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 0
['/kagra/camera/images/2026/02/06/OMC_TRANS_2026-02-06-17-04-53.tif']


Another possibility is very rare timing issue between two self.timer and a delay of subprocess.
According to the following logs, 'snapshot clean up timer' was activated just ~1.5s before taking picture.
2026-02-06_13:26:37.230904Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['snapshot clean up timer'] done
2026-02-06_13:26:37.405732Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:37.406907Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4780.0
2026-02-06_13:26:37.473963Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['snapshot clean up timer'] = 120
2026-02-06_13:26:37.726469Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:37.727160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4790.0
2026-02-06_13:26:38.019507Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.021371Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4800.0
2026-02-06_13:26:38.285156Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.286160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4810.0
2026-02-06_13:26:38.594727Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.600320Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4820.0
2026-02-06_13:26:38.646883Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_TRIG_THRESHOLD_LO => 1
2026-02-06_13:26:38.647217Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT_SW1 => 1024
2026-02-06_13:26:38.898631Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => ON: FM4
2026-02-06_13:26:38.899212Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 1
2026-02-06_13:26:38.900160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['OMC_snapshot_timer'] = 2
2026-02-06_13:26:40.901117Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['OMC_snapshot_timer'] done
2026-02-06_13:26:40.948043Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 0
2026-02-06_13:26:40.966347Z OMC_LSC W: Traceback (most recent call last):
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/worker.py", line 494, in run
2026-02-06_13:26:40.966347Z retval = statefunc()
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/state.py", line 246, in __call__
2026-02-06_13:26:40.966347Z main_return = self.func.__call__(state_obj, *args, **kwargs)
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/state.py", line 246, in __call__
2026-02-06_13:26:40.966347Z main_return = self.func.__call__(state_obj, *args, **kwargs)
2026-02-06_13:26:40.966347Z File "/opt/rtcds/userapps/release/omc/k1/guardian/OMC_LSC.py", line 894, in run
2026-02-06_13:26:40.966347Z fname = get_latest_file('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*')
2026-02-06_13:26:40.966347Z File "/opt/rtcds/userapps/release/omc/k1/guardian/OMC_LSC.py", line 42, in get_latest_file
2026-02-06_13:26:40.966347Z return file_name
2026-02-06_13:26:40.966347Z UnboundLocalError: local variable 'file_name' referenced before assignment

This time launched the "rm" command by the background subprocess as follows.
 886         elif self.timer['snapshot clean up timer']:
887 if not (self.analyzing_mode or self.taking_snapshot):
888 self.p2 = sp.Popen(['/bin/rm /kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*'], shell=True)
889 self.timer['snapshot clean up timer'] = 120
If the subprocess is delayed by merely ~1 second in some reason, taken picture was removed by delayed subprocess before finding picture file by the get_latest_file function. (It is not surprising that there is a slight delay due to the process crossing multiple networks such as NFS.) It still remains imagination. But now, there is no enough information and reproducibility of this issue.
IOO (OMC)
takafumi.ushiba - 22:53 Friday 06 February 2026 (36311) Print this report
OMC_LSC guardian stops due to the camera error

I found that OMC_LSC guardian stops due to the camera errors.
I'm not so sure what happens but is it related to the maintenance work today?

Images attached to this report
Comments to this report:
takahiro.yamamoto - 3:04 Saturday 07 February 2026 (36312) Print this report
An error itself comes from an implementation of the get_latest_file function which was not changed in today's update.
This function makes a run-time error when the picture file cannot be found in some reason.

I have no idea now why the picture file couldn't be found.
When I started to investigate this issue (maybe around 1:30?), there was no image file in any directories.
Did you remove taken pictures by manually?
I want to know whether a picture was taken but couldn't be found or a picture wasn't taken at all.

Investigation memo
According to the guardian logs, following procedure was executed.
1. FM4 of OMC-LSC_FB_FLT was turned ON.
2. CAM-OMC_TRANS_ARCHIVE_INTERVAL was changed to 1.
3. It takes 2-second long as waiting time by 'OMC_snapshot_timer'.
4. CAM-OMC_TRANS_ARCHIVE_INTERVAL was reverted to 0.
5. The get_latest_file function was called and it made a run-time error.

This condition is satisfied by executing
 933         elif ezca['OMC-TRANS_DC_SUM_OUTPUT'] >= ezca['OMC-LSC_TRIG_THRESHOLD_LO']:
934 ezca['OMC-LSC_TRIG_THRESHOLD_LO'] = 1
935 ezca.switch('OMC-LSC_FB_FLT','FM4', 'ON')
936 #Check the mode shape
937 ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 1
938 self.timer['OMC_snapshot_timer'] = 2
939 self.taking_snapshot = True
940
941 pattern = '/opt/rtcds/userapps/trunk/omc/k1/guardian/sounds/' + ezca['SYS-SOUND_OMC_LOCK_GLOB']
942 # kagralib.play_random_wavefile(pattern)
after then, executing
 891         if self.taking_snapshot:
892 if self.timer['OMC_snapshot_timer']:
893 ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 0
894 fname = get_latest_file('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*')
895 log(fname)
896 self.p = sp.Popen(['/opt/rtcds/userapps/trunk/cds/common/scripts/mode', fname],
897 stdout=sp.PIPE)
898 self.analyzing_mode = True
899 self.taking_snapshot = False

I simulated this condition as follows. But there was no problem to take a picture and to find it.
>>> from ezca import Ezca                                                                                                                                                                                                                                                                                                                                                   
>>> import glob
>>> ezca = Ezca()
>>> import time
>>> def func():
... ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 1
... time.sleep(2)
... ezca['CAM-OMC_TRANS_ARCHIVE_INTERVAL'] = 0
... print( glob.glob('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*') )
...
>>> print( glob.glob('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*') )
[]
>>> func()
K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 1
K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 0
['/kagra/camera/images/2026/02/06/OMC_TRANS_2026-02-06-17-04-53.tif']


Another possibility is very rare timing issue between two self.timer and a delay of subprocess.
According to the following logs, 'snapshot clean up timer' was activated just ~1.5s before taking picture.
2026-02-06_13:26:37.230904Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['snapshot clean up timer'] done
2026-02-06_13:26:37.405732Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:37.406907Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4780.0
2026-02-06_13:26:37.473963Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['snapshot clean up timer'] = 120
2026-02-06_13:26:37.726469Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:37.727160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4790.0
2026-02-06_13:26:38.019507Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.021371Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4800.0
2026-02-06_13:26:38.285156Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.286160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4810.0
2026-02-06_13:26:38.594727Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => OFF: FM4
2026-02-06_13:26:38.600320Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-PZT_HV1_OFFSET => 4820.0
2026-02-06_13:26:38.646883Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_TRIG_THRESHOLD_LO => 1
2026-02-06_13:26:38.647217Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT_SW1 => 1024
2026-02-06_13:26:38.898631Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:OMC-LSC_FB_FLT => ON: FM4
2026-02-06_13:26:38.899212Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 1
2026-02-06_13:26:38.900160Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['OMC_snapshot_timer'] = 2
2026-02-06_13:26:40.901117Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] timer['OMC_snapshot_timer'] done
2026-02-06_13:26:40.948043Z OMC_LSC [FIND_RESONANCE_FOR_IAL_WITH_RF.run] ezca: K1:CAM-OMC_TRANS_ARCHIVE_INTERVAL => 0
2026-02-06_13:26:40.966347Z OMC_LSC W: Traceback (most recent call last):
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/worker.py", line 494, in run
2026-02-06_13:26:40.966347Z retval = statefunc()
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/state.py", line 246, in __call__
2026-02-06_13:26:40.966347Z main_return = self.func.__call__(state_obj, *args, **kwargs)
2026-02-06_13:26:40.966347Z File "/usr/lib/python3/dist-packages/guardian/state.py", line 246, in __call__
2026-02-06_13:26:40.966347Z main_return = self.func.__call__(state_obj, *args, **kwargs)
2026-02-06_13:26:40.966347Z File "/opt/rtcds/userapps/release/omc/k1/guardian/OMC_LSC.py", line 894, in run
2026-02-06_13:26:40.966347Z fname = get_latest_file('/kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*')
2026-02-06_13:26:40.966347Z File "/opt/rtcds/userapps/release/omc/k1/guardian/OMC_LSC.py", line 42, in get_latest_file
2026-02-06_13:26:40.966347Z return file_name
2026-02-06_13:26:40.966347Z UnboundLocalError: local variable 'file_name' referenced before assignment

This time launched the "rm" command by the background subprocess as follows.
 886         elif self.timer['snapshot clean up timer']:
887 if not (self.analyzing_mode or self.taking_snapshot):
888 self.p2 = sp.Popen(['/bin/rm /kagra/camera/images/[0-9]*/[0-9]*/[0-9]*/OMC_TRANS*'], shell=True)
889 self.timer['snapshot clean up timer'] = 120
If the subprocess is delayed by merely ~1 second in some reason, taken picture was removed by delayed subprocess before finding picture file by the get_latest_file function. (It is not surprising that there is a slight delay due to the process crossing multiple networks such as NFS.) It still remains imagination. But now, there is no enough information and reproducibility of this issue.
takafumi.ushiba - 13:45 Monday 09 February 2026 (36320) Print this report

It is difficult to confirm the exact cause of user code errors, but it is very ikely that the problem was happened due to the very unfortune timing of the subprocess to remove the snapshot files.
To avoid this error, I deleted the function to remve the snapshot files during the OMC scan from the FIND_RESONANCE, FIND_RESONANCE_FOR_10W, and FIND_RESONANCE_FOR_IAL_WITH_RF states while adding this function at DOWN state.

Figure 1 shows the script I modified at DOWN state.
Figure 2 shows the script I commented out at FIND_RESONANCE state, which is same for the other FIND_RESONANCe states.

Images attached to this comment
VIS (PR2)
ryutaro.takahashi - 15:15 Friday 06 February 2026 (36310) Print this report
Offload of IM

I offloaded the IM V OSEMs with the picomotors for pitch. It was performed in ALIGNED mode.

PEM (Center)
tatsuki.washimi - 15:08 Friday 06 February 2026 (36309) Print this report
Shakers installation in the PSL room

[Miyakawa, YokozaWashimi]

We installed 4 ahakers installation in the PSL room.

  1. Near the final periscope
  2. Near the ACC3 and the Laser source
  3. & 4. Near the suspect mirrors
Images attached to this report
PEM (Center)
takaaki.yokozawa - 15:00 Friday 06 February 2026 (36308) Print this report
Installation of the mini shakers to the PSL room
[Miyakawa, YokozaWashimi]

After the discussion with Miyakawa-san, we decided the position of the installation of the mini shakers at the PSL room and actually installed.

1. Near the periscope
EXC channel : K1:PEM-EXCITATION_SR3_RACK_9_EXC

2. Near the ACC3 (and master laser)
EXC channel : K1:PEM-EXCITATION_SR3_RACK_10_EXC

3. Near the weak mirror1 (after the PMC)
EXC channel : K1:PEM-EXCITATION_SR3_RACK_11_EXC

4. Near the weak mirror2 (after the PMC)
EXC channel : K1:PEM-EXCITATION_SR3_RACK_12_EXC
MIF (General)
takaaki.yokozawa - 14:54 Friday 06 February 2026 (36307) Print this report
Comment to Lock failed 260206 (36300)
It started the 02:08:24 2026/02/06 JST, and all MN and IM H and V photo sensor can be seen.
(IFO kept locked. LSC_LOCK =9998)
Images attached to this comment
IOO (OMC)
takahiro.yamamoto - 14:05 Friday 06 February 2026 (36306) Print this report
Comment to Proposal of compatibility update of OMC_LSC guardian for the new pylon-camera-server (36226)
DGS (General)
takahiro.yamamoto - 14:02 Friday 06 February 2026 (36305) Print this report
Migration of OMC_TRANS camera
OMC_TRANS camera which was still running as the old camlan camera-server was migrated to the pylon-camera-server.
OMC_LSC guardian was updated for compatibility fixes with the new pylon-camera-server, which was proposed in klog#36226.
With this work, all cameras have been migrated to pylon-camera-server.

Past related works
- k1cam2 as pylon-camera-server was newly installed (klog#36182).
- Cameras on k1cam0 as camlan camera-server were moved to k1cam2 (klog#36212).
- k1cam0 was upgraded to pylon-camera-server and cameras on k1cam1 except OMC_TRANS were moved to k1cam0 (klog#36284).

Remaining tasks
- Uninstall of old k1cam1
- Rename of k1cam2 as k1cam1
- Hardware replacement of k1cam0
PEM (Center)
tatsuki.washimi - 12:51 Friday 06 February 2026 (36304) Print this report
Comment to PEM injection test 260206 (36301)

Spectrograms for the  large shaker tests.

Images attached to this comment
PEM (Center)
tatsuki.washimi - 12:36 Friday 06 February 2026 (36303) Print this report
Comment to PEM injection test 260206 (36301)

Spectrograms for the  small shaker tests.

Images attached to this comment
Search Help
×

Warning

×