MIF (General)shun.saito - 16:39 Saturday 25 April 2026 (36821)
Print this reportConstruction of the optical layout for the PLL
[Hirose, Saito]
We constructed the optical layout for the PLL.
For the PLL, we built an optical system to inject both the sub-laser IR beam and the IR beam coming from the interferometer into the RFPD simultaneously (Photo 1). The current optical configuration is shown in Fig. 1. Next, we adjusted the HWP to maximize the power of the sub-laser beam entering the interferometer. Under this condition, the power of the sub-laser beam incident on the RFPD was measured with a power meter to be 1.78 mW without the ND filter, and 8.9 μW with the ND filter. The power of the beam coming from the interferometer was 3.8 μW. In total, 12.7 μW of light is incident on the RFPD, which is well below the maximum allowable input power of 1 mW, so this is not an issue. The next step is to check the signal from the RFPD.
Images attached to this report
DGS (General)takahiro.yamamoto - 14:51 Saturday 25 April 2026 (36819)
Print this reportInvestigation of IRIG-B synchronization issue at EY0[Ikeda, YamaT]
IO chassis for K1EY0 was replaced as V2 one in klog#36692. IRIG-B synchronization issue appeared by using V2 IO chassis and disappeared by replacing a proper optical fiber for K1IX1, K1IY1, and K1EX0 in klog#36705. Only for K1EY0, this issue still remains even though an optical fiber was already replaced. So we tried to narrow down problematic points but we haven't identified a cause of this issue yet. It doesn't seemed to be caused by a specific equipment and might be related to the environment around EY0 rack.
----- During the IO chassis replacement, both the IO chassis and the real-time front-end were replaced with new hardware. The IO chassis was equipped with new V2 hardware. On the other hand, the real-time front-end utilized hardware that had been in use on the IXV until just prior to the replacement. Therefore, we do not believe that the real-time front-end or the PCIe IRIG-B interface board attached to it is the direct cause of this issue. And also, we guess that a cause of this issue is V2 IO chassis itself or a compatibility between it and other equipment.
We have been testing various combinations of V2 IO chassis and other equipments on the SK test bench in order to reproduce the issue, but so far we have been unable to reproduce it. On the other hand, we have obtained a specific IO chassis unit that has been confirmed not to exhibit this issue on the SK test bench, so we decided to bring it to EY0 for testing. As a result, even when using units that did not cause issues on the test bench, problems still occurred with the EY0. It appears that this is not an issue specific to the IO chassis alone, but rather likely a compatibility issue between the IO chassis and other devices within the EY0 environment. We also checked other components that are relatively easy to test, such as timing optical fibers, fanout ports, IRIG-B ports, IRIG-B breakout connectors, the timing slave board which was used in the V1 IO chassis, easing a current limitation of DC24V power supply and minor changes on BIOS settings related to PCIe slots, but none of them helped resolve the issue.
Untested component is around Fanout and IRIG-B chassis. These units are at the end of a four-unit daisy chain that includes o(10km)-long fiber connection from the Timing Master. Conducting fiber tests on a 10km scale in the SK server room is not practical, and we do not have enough spare units to replicate a four-unit daisy chain. Therefore, ongoing on-site troubleshooting at EY0 will likely be necessary going forward.
MIF (General)takaaki.yokozawa - 13:17 Saturday 25 April 2026 (36820)
Print this reportComment to TCam photo image ETMY and ETMX (36785)I also checked the 1 month history using the beam spot captures. As you can see in gif.1., the pcal beam moved a lot at the 25th Mar.
I checked 1 hour trend in gif.2., the beam moved at morning time.
Maybe klog36656 work may affect to the EYA tilting, not come from the duct shield cooling. Anyway, next step is updating the fitting tool of the mirror position.
Images attached to this comment
DGS (General)takahiro.yamamoto - 19:27 Friday 24 April 2026 (36818)
Print this reportHang-up of k1tw1k1tw1 hung up just after 9am today.
This is probably same issue as klog#35733 coming from a bug of used versions of kernel and/or gentoo. So it wasn't able to be accessed remotely. And also in this time, video output was unavailable both on KVM and BMC consoles. For this reason, an actual cause of this hang-up was not identified. After visual inspection of hardware, k1tw1 finally came back online by performing a cold boot. After then, I checked a status of NFS for minute_raw region on all NFS clients (k1nds* and k1script*).
A downtime of the stream#1 (k1tw1 - k1nds1) due to this issue was 9am - 11am. Missed data on the stream#1 is available on the stream#0 (k1tw0 - k1nds0).
VAC (SRM)hiromi.yasui - 17:30 Friday 24 April 2026 (36817)
Print this reportComment to Pressurization of SRM to atmospheric pressure (36813)
[mTakahashi, hSawada, Nakagaki, Yasui]
1. Vacuum evacuation by DSP We tightened top- and +X-side- flanges of SRM, and started pumping down by the Dry Pump.
10:20
Turned ON the dry pump
10:26
Opened the angle valve: 270 degrees
10:38
6.8×10^4Pa
11:06
2.9×10^4Pa
11:14
Opened the angle valve: 450 degrees
11:30
9.2×10^3 ->Opened the angle valve fully
11:36
6.6×10^3Pa
11:47
3.7×10^3Pa
13:25
6.6x10Pa
13:37
5.3x10Pa
13:56
4.0x10Pa
14:09
3.3x10Pa
2. Leak check of Q-mass Also, we had a leak test around Q-mass that installed yesterday. Since the leak level was less than 1×10^-13Pam^3/s, we opened the valve and connected to the OMMT chamber.
3. Vacuum evacuation by TMP After rough pumping by the dry pump, I started evacuating by the TMP.
SRM[Pa]
OMMT[Pa]
14:38
2.4x10
5.3x10^-1
14:39
GVommt OPEN
1.3x10
1.4x10
14:40
TMP START
14:44
1.2x10
1.3x10
14:51
1.8x10^-2
2.2x10^-2
CAL (Pcal general)Misato Onishi - 13:38 Friday 24 April 2026 (36816)
Print this reportWSK calibration at UToyama
Date: 2026/04/24
Member: Dan Chen, Misato Onishi, Seiya Matsuo
We performed our usual WSK calibration at UToyama.
The results look no problem.
Results
Case
Alpha (Main Value)
Alpha (Uncertainty)
Front WSK, Back GSK
-0.911552
0.000128
Front GSK, Back WSK
-0.910757
0.000131
Comparison with Previous Results
Comparing with previous results, no significant issues were found. Attached graph is the result summary including the latest measured data.
Images attached to this report
VAC (SRM)nobuhiro.kimura - 8:58 Friday 24 April 2026 (36814)
Print this reportComment to Vacuum leak test for SRM (36792)
[Kimura, Tomaru, M. Takahashi, H. Sawada and R. Takahashi] "Inspection results for the sealing surface of the +X side flange" A vacuum leak in the range of 1×10⁻⁹ Pa·m³/s was detected, so we inspected the sealing surface of the side flange on the +X side. As a result, we found a slight scratch on the elastomer surface. Based on the location of the scratch, we believe it is the cause of the vacuum leak. After installing a new elastomer on the sealing surface of the +X side flange, the flange was closed. The flange fastening bolts are currently in a temporarily secured state.
"Inspection results for the sealing surface of the SRM top flange" After removing the SRM top flange, the condition of the flange sealing surface was inspected. No dirt or scratches were found on the surface of the elastomer. Therefore, it was decided to reuse the SRM top flange as a seal.
VAC (SRM)nobuhiro.kimura - 6:35 Friday 24 April 2026 (36813)
Print this reportPressurization of SRM to atmospheric pressure
Date of work: 23, Apr, 2026
Workers: Kimura and Tomaru
Abstract: We pressurized SRM atmospheric pressure for the investigation of outgassing source in SRM (k-log 36811). The following is a record of the opening and closing of valves and the pressure of the pressurization process. The same process is used for k-log 26030. It is noted here for reference.
~9:50 GVoomt Close Set safety valve to SRM vacuum pump unit Turn on main SW of TPM (Not acceration, only raise the rotor blades to protect the TMP) 9:55 Pressurization was started by G-2class grade air (klog-25912). Cylinder is filled with 7 m³ of compressed dry air. Pressure inside SRM was 1.7 x 10^1 Pa Cylinder pressure 15.2 MPaG 10:00 " 2.1 x 10^3 Pa 10:22 " 3.7 x 10^3 Pa 10:33 " 4.2 x 10^3 Pa Cylinder pressure 14.2 MPaG 10:40 " 7.8 x 10^3 Pa 10:55 " 1.6 x 10^4 Pa Cylinder pressure 11.9 MPaG 11:21 " 3.3 x 10^4 Pa " 8.9 MPaG 11:30 " 3.9 x 10^4 Pa " 7.9 MPaG Increased air flow (Secondary pressure 1.1 kg/cm^2G) 11:34 " 4.1 x 10^4 Pa " 7.5 MPaG 11:54 " 5.3 x 10^4 Pa 12:12 " 6.4 x 10^4 Pa 12:12 " 6.4 x 10^4 Pa 12:19 " 6.9 x 10^4 Pa 12:27 " 7.4 x 10^4 Pa Cylinder pressure 2.0 MPaG 12:34 " 7.8 x 10^4 Pa " 1.1 MPaG Change to a new cylinder filled with 7 m³ of compressed dry air 12:41 " 7.9 x 10^4 Pa Cylinder pressure 15.2 MPaG 12:45 " 8.1 x 10^4 Pa " 15.1 MPaG 12:53 " 8.4 x 10^4 Pa 12:58 " 8.9 x 10^4 Pa 13:02 " 9.0 x 10^4 Pa " 13.2 MPaG 13:04 " 9.1 x 10^4 Pa 13:07 " 9.4 x 10^4 Pa " 12.6 MPaG 13:10 " 9.6 x 10^4 Pa 13:11 " 9.7 x 10^4 Pa The pressurization process is terminated because the pressure in the SRM has reached almost atmospheric pressure at 13:11. Based on the volume of dry air, the internal volume of the SRM was estimated to be approximately 9 m³.
Comments to this report:
hiromi.yasui - 17:30 Friday 24 April 2026 (36817)
Print this report
[mTakahashi, hSawada, Nakagaki, Yasui]
1. Vacuum evacuation by DSP We tightened top- and +X-side- flanges of SRM, and started pumping down by the Dry Pump.
10:20
Turned ON the dry pump
10:26
Opened the angle valve: 270 degrees
10:38
6.8×10^4Pa
11:06
2.9×10^4Pa
11:14
Opened the angle valve: 450 degrees
11:30
9.2×10^3 ->Opened the angle valve fully
11:36
6.6×10^3Pa
11:47
3.7×10^3Pa
13:25
6.6x10Pa
13:37
5.3x10Pa
13:56
4.0x10Pa
14:09
3.3x10Pa
2. Leak check of Q-mass Also, we had a leak test around Q-mass that installed yesterday. Since the leak level was less than 1×10^-13Pam^3/s, we opened the valve and connected to the OMMT chamber.
3. Vacuum evacuation by TMP After rough pumping by the dry pump, I started evacuating by the TMP.
SRM[Pa]
OMMT[Pa]
14:38
2.4x10
5.3x10^-1
14:39
GVommt OPEN
1.3x10
1.4x10
14:40
TMP START
14:44
1.2x10
1.3x10
14:51
1.8x10^-2
2.2x10^-2
PEM (Center)takaaki.yokozawa - 5:45 Friday 24 April 2026 (36812)
Print this reportOndotori maintenance 260424I performed the temperature monitor (ondotori) maintenance.
mcrack, iya, ixc They are AC power supply, but the no signals in display, I touched the AC tap, they are recovered. Maybe after the blackout, the AC tap connected unstable
sr3, srm After changed the battery, they recovered.
VIS (SRM)ryutaro.takahashi - 19:24 Thursday 23 April 2026 (36810)
Print this reportComment to Health check (36669)
I checked the IM transfer functions after closing the chamber. The behavior did not change after opening the chamber to remove the geophone pods.
Images attached to this comment
VIS (SRM)ryutaro.takahashi - 19:19 Thursday 23 April 2026 (36809)
Print this reportComment to Health check (36669)
I checked the IM transfer functions after the pressure reached 8E4 Pa. The behavior returned to the situation before starting the evacuation.
Images attached to this comment
VIS (SRM)ryutaro.takahashi - 17:38 Thursday 23 April 2026 (36811)
Print this reportInvestigation of outgassing source
We opened the X+ side hatch and the top belljar. We could not find any dirty items inside the chamber. Pictures are here.
We removed the geophone pods. The weight of each pod was 12.6kg. After closing the chamber, we measured the IP transfer functions. The resonant frequencies became 0.16Hz for L and T, and 0.4Hz for Y.
Images attached to this report
CAL (YPcal)Misato Onishi - 14:08 Thursday 23 April 2026 (36808)
Print this reportYPcal calibration
KAGRA Pcal-Y updates (2026/04/23)
Workers: Dan Chen, Misato Onishi
We performed monthly Pcal-Y calibration on 2026/04/23.
After the calibration, we updated EPICS parameters related to the Pcal-Y system. No issues were found.
EPICS Key
Before
After
Δ (After − Before)
K1:CAL-PCAL_EY_1_OE_R_SET
0.98977
0.98970
-0.00006
K1:CAL-PCAL_EY_1_OE_T_SET
0.98977
0.98970
-0.00006
K1:CAL-PCAL_EY_1_PD_BG_RX_V_SET
-0.00492
-0.00468
0.00024
K1:CAL-PCAL_EY_1_PD_BG_TX_V_SET
0.01218
0.02250
0.01032
K1:CAL-PCAL_EY_1_RX_V_R_SET
0.50276
0.50286
0.00010
K1:CAL-PCAL_EY_2_INJ_V_GAIN
0.51836
0.52009
0.00173
K1:CAL-PCAL_EY_2_OE_R_SET
0.98609
0.98588
-0.00020
K1:CAL-PCAL_EY_2_OE_T_SET
0.98609
0.98588
-0.00020
K1:CAL-PCAL_EY_2_PD_BG_TX_V_SET
0.01466
0.02476
0.01011
K1:CAL-PCAL_EY_2_RX_V_R_SET
0.49724
0.49714
-0.00010
K1:CAL-PCAL_EY_WSK_PER_RX_SET
1.84228
1.84385
0.00156
K1:CAL-PCAL_EY_WSK_PER_TX1_SET
0.33354
0.33366
0.00012
K1:CAL-PCAL_EY_WSK_PER_TX2_SET
0.90266
0.90553
0.00287
Images attached to this report
MIF (General)takaaki.yokozawa - 8:28 Thursday 23 April 2026 (36807)
Print this reportComment to TCam photo image ETMY and ETMX (36785)After the Takahashi-san work, I performed the TCam photo session again. For the ETMY, actually, the mirror position changed, but smaller than the difference from Feb. to Apr. gif.1. And oplev scattering image moved with the mirror position.
Images attached to this comment
MIF (General)takaaki.yokozawa - 8:12 Thursday 23 April 2026 (36806)
Print this reportETMX TCam gray image againI noticed that the TCam image was gray scale again in ETMX, I fixed it using https://klog.icrr.u-tokyo.ac.jp/osl/?r=31281
CAL (YPcal)dan.chen - 6:09 Thursday 23 April 2026 (36805)
Print this reportPcal-Y beam alignment adjustment
Thank to klog36803, the picos are available. So I adjusted the Pcal-Y beam position.
The TM positions on the Tcam photo as the ref for Pcal were also updated:
[pixel]
Pcal-X horizontal
Pcal-X vertical
Pcal-Y horizontal
Pcal-Y vertical
Before
1938
1420
2240
1035
After
1942
1410
2250
1000
The factor converting mm to dot is 11.3[pixel/mm]
Through this work: the Pcal-Y path 1 was moved down by ~4 mm on ETM = by ~8 mm on RxPD, and the Pcal-Y path 2 was moved down by ~2 mm on ETM = by ~4 mm on RxPD, and the RxPD output recovered by ~1.5%.
Images attached to this report
VAC (SRM)nobuhiro.kimura - 5:42 Thursday 23 April 2026 (36804)
Print this reportComment to Vacuum leak test for SRM (36792)
[Kimura, M.Takahashi, H. Sawada, R. Takahashi and Tomaru] On April 22, we continued conducting leak tests on the SRM vacuum vessel. Since vacuum leaks were suspected due to cracks in the weld lines, we performed leak tests by blowing helium gas onto the weld lines and using the hood method; however,we were unable to locate the leak. (See attached photo.) The build-up test was conducted with the SRM and OMMT sharing a common vacuum, and the pressure was recorded using the OMMT’s pressure gauge. The plot of the build-up test is attached. The total duration of the build-up test was 935 minutes. The estimated leak rate from the build-up test was 9.7 × 10⁻⁴ Pa·m³/s. The slope of the pressure rise was approximately 1.
Images attached to this comment
DGS (General)takahiro.yamamoto - 19:42 Wednesday 22 April 2026 (36803)
Print this reportDowngrade of k1script1[Ikeda, YamaT]
As reported in klog#36789, Pcal picomotors didn't work. We found that it somehow occurs by the communication error between picomotors in the old PICO network and the Debian13 system.
Pcal picomotors are required for proceeding tomorrow's calibration of the integration sphere in YPcal. So I downgraded k1script1 which is the secondary script server and processes for Pcal picomotors were moved back to it as the first-aid. Another processes which works fine also on the Debian13 system are still on k1script0 which is the primary server.
Modification of the picomotor script, moving Pcal picomotors to the PICO network and/or update of picomotor driver firmware is required to make old script server retired.
----- A reason why Pcal picomotors didn't work was a mismatch of the communication mode of Telnet between the picomotor script and its driver. Though picomotor drivers seem to support the char-mode, the picomotor script on the Debian13 system tries to connect as the line-mode for picomotors in the old PICO network in some reason. This issue didn't occur for picomotors in the PICO network. Script servers can access the PICO network directly. On the other hand, the old PICO network can be accessed only via k1gate. This is an only difference between these two networks. But a difference in L3 connection doesn't affect a mode negotiation of Telnet in normal. Because all picomotors had worked fine on the old script server and picomotor drivers in the old PICO network was able to be accessed from k1ctr which was the Debian12 system, it seems an issue only on the Debian13 system.
Although we haven’t identified the exact cause of this issue yet, I downgraded k1script1 which was the secondary script server and moved only the problematic picomotors on that server because Pcal picomotors are required for tomorrow's integration sphere calibration at YPcal. Another all processes which have no issue are still on k1script0 which is the primary script server.
The picomotor script connect picomotor drivers by using python3-socket package instead of telnet package. So IAC negotiation which is done at the beginning of Telnet connection must be implemented by ourselves. I'm not sure the firmware on picomotor drivers are kept modern ones, but anyway a versions of socket libraries and a python3-socket package on the Debian13 system is bumped up from ones on the old Debian systems. For this reason, some kind of incompatibility on a specification of Telnet negotiation expected by Debian13 and picomotor drivers. To make the old script server retired, this issue must be solved.
VIS (IY)ryutaro.takahashi - 18:10 Wednesday 22 April 2026 (36802)
Print this reportComment to Height adjustment of GAS filters (31360)
I changed the setpoint for the F1 GAS from -3170 to -3700, and the F2 GAS from 1280 to 1240, so that the MN V Oplev can be zero.
VIS (IX)ryutaro.takahashi - 17:54 Wednesday 22 April 2026 (36801)
Print this reportComment to Height adjustment of GAS filters (31359)
I changed the setpoint for the F2 GAS from -1109 to -1198 so that the MN V Oplev can be zero.
VIS (SRM)ryutaro.takahashi - 17:45 Wednesday 22 April 2026 (36799)
Print this reportComment to Health check (36669)
I checked the IM transfer functions after the TMP stopped. The situation was not changed (The DC gain of transfer functions is smaller than the reference, except for L).
Images attached to this comment
MIF (General)shun.saito - 17:31 Wednesday 22 April 2026 (36800)
Print this reportAlignment of the sub-laser and preparation for PLL
[Tanaka, Hirose, Saito]
To align the optical path of the sub-laser beam with the IR beam on the POS table, we reinstalled two irises and performed alignment. In addition, we prepared mirrors, a BS, lenses, and ND filters to combine the sub-laser beam and the IR beam on the POS table and inject them simultaneously into the RFPD.
Since the alignment in klog:36773 was not successful, we changed the positions of the irises and the mirrors used for alignment (Photo 1). To more precisely match the optical path of the sub-laser beam with the IR beam on the POS table, we moved the position of the second iris (in klog:36773) to 2125 mm from the sub-laser. We adjusted the setup so that the IR beam on the POS table hit the center of the mirror located after the second iris, and then fine-tuned the iris so that the beam passed through its center. Using the second and third mirrors after the second iris, we aligned the sub-laser beam so that it passed through both irises.
We prepared mirrors, a BS, lenses, and ND filters to combine the sub-laser beam and the IR beam on the POS table and inject them into the RFPD. The lenses are used to make the beam diameter smaller than the RFPD sensor diameter and to match the beam sizes of the sub-laser and the IR beam on the POS table at the RFPD location. The ND filters are used to reduce the sub-laser power entering the RFPD, since the maximum allowable input power to the RFPD is 1 mW.
Images attached to this report
DGS (General)takahiro.yamamoto - 16:40 Wednesday 22 April 2026 (36798)
Print this reportMinute trend rotationOld minute frames were removed on the storage for k1fw0. Removed time segment is [1300000000, 1350000000)
These data is available on Kashiwa. There was no undelivered data to Kashiwa in that time segment.
MIF (General)takaaki.yokozawa - 14:34 Wednesday 22 April 2026 (36795)
Print this reportComment to TCam photo image ETMY and ETMX (36785)I also generated the ETMY before duct shield cooling down(Feb) and after (Apr.) gif.1.
From my eye, 1. TCam itself became upper direction (and some rotation?) This issue come from the image of the beam duct shadow and oplev scattered signal.
2. Mirror itself became upper direction Due to the cooling down the duct shield, mirror position would be upper direction, but the amount of movement would be smaller than movement of 1. We will wait the Takahashi-san work.
3. PCal beam became more upper direction Compared with the movement of 1. and 2. both PCal beams became more upper direction. Dan-san described that the beam position of the Rx PD became upper position from hardware condition.
We should consider again after the Takahashi-san work, one possibility is that "the EYA chamber tilted due to the duct shield cooling". We will search the past log around the cooling of the previous EYC duct shield cooling -> I summarized the previous TCam image klog31367, start the duct shield cooling 18th Oct., 2024 gif.2. gif.3. showed the 296 K -> 250 K small rotating?? by checking the oplev scattered beam
Images attached to this comment
VIS (EX)ryutaro.takahashi - 13:49 Wednesday 22 April 2026 (36797)
Print this reportComment to Height adjustment of GAS filters (31357)
I changed the setpoint for the BF GAS from 3860 to 3490 so that the MN V Oplev can be zero. The BF GAS was offloaded with the FR.