Reports of 34239
MIF (ITF Control)
Hiroki Fujimoto - 3:40 Thursday 14 May 2026 (36891) Print this report
Further investigation of carrier buildup/reduction in SRY

[Takano, Tanaka, Fujimoto]

Summary

We measured the carrier buildup factor (ratio of on-resonance to off-resonance power) and the carrier reduction factor (ratio of off-resonance to single-path power) for the four SRY transmission ports: REFL, POP, POS, and AS.
In particular, the measured carrier buildup factors were:

  • Design value: 7.3
  • REFL: 5.0
  • POP: 1.3
  • POS: 1.6
  • AS: 5.0

The REFL and AS values are somewhat lower than the design value, and POP and POS show significantly larger mismatches.
These mismatches could be caused by additional losses inside the SRY or optical offsets in the PD signals.
One possible origin is s-pol to p-pol conversion caused by birefringence in the ITMY substrate.

Details

As described in our previous klog (#36881), the true reflection port of the SRY is the port transmitted toward the ITMX side, while the interferometer REFL port acts as a transmission port for the SRY. Therefore, the currently available transmission ports for monitoring the SRY carrier buildup are REFL,POP, POS and AS.
For these ports, we performed:

  • Measurement of the carrier buildup factor (ratio of on-resonance to off-resonance)

  • Check for offsets in the PD outputs

  • Measurement of the carrier reduction factor (ratio of off-resonance to single-path)

We also discussed the discrepancies between the measured values and the design values.

Measurement of carrier buildup

Fig. 1 shows the DCPD time-series data for each transmission port (REFL, POP, POS, AS) of the freely swinging SRY.
From these data, the carrier buildup factor (ratio of resonant to non-resonant power) for each transmission port was obtained.
The measured values are:

  • Carrier buildup factor:
  • REFL: 5.0
  • POP: 1.3
  • POS: 1.6
  • AS: 5.0
  • Design value: 7.3 (considering R_{BS}=0.5, R_{IY}=0.996, R_{SRM}=0.85)

Check of PD offsets

Fig. 2 shows the PD outputs with the laser shutter closed and no laser injected into the interferometer.
The offsets of all PDs are nearly zero compared to the on-resonance and off-resonance signals, indicating that they do not contribute significantly to the underestimation of the carrier buildup factor.

Measurement of carrier reduction

Fig. 3 shows the time-series data when the SRM was misaligned and the carrier entered each transmission port (REFL, POP, POS, AS) through a single path.
The cursors in the figure indicate the on-resonance and off-resonance levels.
From these data, the carrier reduction factor (ratio of off-resonance to single-path power) for each transmission port was obtained.

  • Measured carrier reduction factor:
  • REFL: 0.55
  • POS: ~1
  • POP: ~1
  • AS: 0.57
  • Design value: 0.47

Discussion

First, the carrier buildup/reduction factors observed at AS and REFL are generally consistent with each other. However, they still show discrepancies from the design values.

One possible explanation is additional losses inside the SRY.
Additional loss decreases the carrier buildup factor while increasing the reduction factor, which is consistent with the observed trend.
Additional loss can be estimated from the measurement results as follows. The buildup factor b and reduction factor q are given by:

b = ((1+r)/(1-r))^2
q = 1/(1+r)^2

where r is the product of all amplitude reflectivities inside the cavity.
Using the measured values and these equations, the additional loss can be estimated.
However, for the AS results, the additional loss estimated from the buildup factor is 31%, and that estimated from the reduction factor is 50%, which seem too large and also are inconsistent with each other.
Therefore, the discrepancy from the design value cannot be explained solely by additional cavity loss.

Another possible explanation is some offset in the PD outputs.
From the present measurements, we confirmed that there is no significant PD offset when no laser is injected into the interferometer.
However, if there exists an offset that appears only when the laser is injected, it would lead to underestimation of the buildup factor and overestimation of the reduction factor.
As a possible source of such an offset, Tanaka-san pointed out p-pol. light generated by birefringence in the ITMY substrate.
The p-pol. light generated inside the SRY does not interfere with the main s-pol. carrier and can therefore appear as a PD offset.
Moreover, this p-pol. light directly enters the POS and POP ports, while it is rejected at AS and REFL by the OFI and IFI, respectively.
This could also explain why the mismatches observed at POS and POP are particularly large.

This hypothesis can be tested by placing PBSs at POS and POP to remove the p-polarized light and checking whether the buildup/reduction factors improve.
A similar effect should also appear in the PRY, so investigating the buildup/reduction factors at the PRY POS and POP ports may also be useful.

Images attached to this report
MIF (ITF Control)
Hiroki Fujimoto - 3:34 Thursday 14 May 2026 (36892) Print this report
Comment to SRM OPLEV QPD Centering (36880)

For additional information, I attached the photograph of the current SRM OPLEV QPD layout below.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 21:25 Wednesday 13 May 2026 (36890) Print this report
Comment to Test of a new guardian server (36860)
GStreamer plugins were installed to k1grd1 for the mode analysis by OMC_LSC guardian.
Added plugins can be found in JGW-T2617316.

A standalone script to take DCPD images worked fine on k1grd1, so OMC_LSC guardian should also works fine.
(I haven't checked it yet because the Guardian server cannot be stopped today.)

Next step is migration test of all nodes at the same time with stopping all nodes on k1grd0 which is the production server.
VIS (SRM)
kenta.tanaka - 20:13 Wednesday 13 May 2026 (36888) Print this report
Comment to Implementation of hierarchical control for TM (36870)

I modified the ALIGNED state's script of the SRM guardian to engage this hierarchical control. I confirmed that this control was engaged by the guardian and that the guardian could transit between ALIGNED and DAMPED states.

Note:

I have not implemented "LOCK_ACQUISITION" state for SRM. So please do not request SRM guardian to go to "LOCK_ACQUISITION" state. Also, MISALIGNED state has not been implemented.

MIF (General)
dan.chen - 17:16 Wednesday 13 May 2026 (36887) Print this report
Initial alignment

[Tanaka, Takano, Dan]

After the work reported at klog 36886, we started initial alignment procedure.

Summary

We redid the initial alignment following klog36759. This log summarizes the work up to the X-arm and Y-arm alignment.

What we did

We started the initial alignment again following klog36759.

X-arm alignment

At first, the beam position on ETMX was largely displaced, so we manually adjusted ITMX and ETMX while keeping TR_GRX.

  • ITMX: P, Y = 4.5, -12.1 -> -5.4, -15.0
  • ETMX: P, Y = -2.7, -5.6 -> -9.3, -5.5

The transmitted power did not increase easily. The PR3 dither seemed to have been disengaged because its signal exceeded the threshold(?).

We also found that K1:LSC-PSL_PWR_SCALE_OFFSET had changed from 1 to 2.9 around the DAQ restart, so we set it back to 1. After repeating the X-arm alignment, it worked well.

Y-arm alignment

The beam position on ETMY was also largely displaced, so we adjusted the BS alignment.

  • BS: P, Y = 3.4, -40.4 -> 8.0, -44.7

After this adjustment, the Y-arm alignment looked good.

DGS (General)
satoru.ikeda - 16:53 Wednesday 13 May 2026 (36886) Print this report
Update to the k1lsc Model

Request from Tanaka-san

We have added two DAQ channels to the k1lsc model.
SRCL_IN1 16384
SRCL_OUT 16384
 

Images attached to this report
Non-image files attached to this report
MIF (ITF Control)
dan.chen - 16:44 Wednesday 13 May 2026 (36885) Print this report
Comment to SRM OPLEV QPD Centering (36880)

[Tanaka, Fujimoto, Saito, Dan]

Summary

We checked the SRM OPLEV QPD signals after yesterday's centering work. The OPLEV beam was incident on both the TILT and LEN QPDs, but the environmental light and IR contribution were relatively large. We installed an IR filter also in front of the LEN QPD, centered both QPDs, and confirmed that the LEN OPLEV mainly responds to SRM longitudinal motion.

What we did

We first checked whether the OPLEV beam was incident on the QPDs. The environmental light level was large, so we reduced it as much as possible during the measurements.

For the TILT QPD, the sum signal was about 90 counts with the OPLEV beam and about 10 counts when the beam was blocked. Removing the IR filter increased the sum from about 90 to 230 counts, corresponding to an attenuation factor of about 2.6.

For the LEN QPD, no IR filter was installed at first. The sum signal was about 317 counts with the OPLEV beam and about 307 counts when the beam shutter was closed. After inserting an IR filter, the sum decreased to about 130 counts, corresponding to an attenuation factor of about 2.4. Opening the green shutter did not significantly change either QPD signal.

These checks showed that the OPLEV beam was already incident on both QPDs, but the IR contribution was non-negligible. Therefore, we decided to install/keep IR filters in front of both the TILT and LEN QPDs.

IR filter installation and QPD centering

We installed an IR filter in front of the LEN QPD using a right-angle clamp because of the limited space around the QPD.

After reducing the environmental light, with the OPLEV beam on, the IR shutter closed, (and the green shutter open,) the final sum values were:

  • TILT sum: 90.5 counts
  • LEN sum: 130 counts

We then centered both QPDs using the micrometer stages while monitoring the QPD signals.

LEN OPLEV response check

Finally, we excited the SRM in longitudinal and yaw at 10 Hz and checked the LEN OPLEV response. (Attached)

When the SRM was excited in the longitudinal direction, the response appeared in the LEN OPLEV signal. When the SRM was excited in yaw, the response clearly appeared in the TILT OPLEV signal. Therefore, we judged that the present oplev position is acceptable.

Files: `/users/VIS/TypeB/SRM/LogNotes/260513_oplev/`

Images attached to this comment
VAC (SRM)
nobuhiro.kimura - 15:22 Wednesday 13 May 2026 (36883) Print this report
Comment to Vacuum leak test for SRM (36792)

[Kimura, Yasui and Uchiyama]
 On the afternoon of May 12, we shut down the Q-mass unit that had been temporarily installed on the OMMT's exhaust line.
 Data on residual gas distribution up to May 12 is stored in a folder within the KAGRA Dropbox.
Going forward, we will consider temporarily operating the Q-mass unit to investigate the exhaust malfunction that occurred this time.
  Details on the operational method will be reported separately.
  

FCL (General)
shoichi.oshino - 15:19 Wednesday 13 May 2026 (36884) Print this report
Preparation for Air Conditioner Replacement Work
In preparation for the air conditioner replacement work in the mine computer room starting tomorrow, the items around the air conditioning units were cleared away.
As part of the work, the Ondotori data logger (AC DR2) for Air Conditioner No. 2 was stopped. Additionally, the Ondotori base unit was relocated to the top of Air Conditioner No. 1.
VIS (SRM)
ryutaro.takahashi - 14:03 Wednesday 13 May 2026 (36882) Print this report
Comment to Implementation of hierarchical control for TM (36870)

I modified the servo filter "int" (FM10) in the OLDAMP FILTERS in the IM loop. The cross-frequency between the TM and IM loops was set to 0.1Hz for both pitch and yaw directions. I offloaded the IM pitch with the picomotor.

MIF (General)
satoru.takano - 11:30 Wednesday 13 May 2026 (36881) Print this report
SRC buildup explained (partially)

Summary

We found that the power budget with SRY on resonance is not so weird after all. We misunderstood what is the 'reflection light' from SRY.

Detail

As reported shortly in this post, we observed an unfamiliar power change when SRY flashed. Fig.1 shows the DC power signal in several ports: REFL, AS, POP, POP s-pol, POP p-pol, and POS (newly installed on Monday). Surprisingly, the power at both REFL and AS ports increased. Another concern was that the buildup evaluated at POS was smaller than expected from the mirrors' reflectivity: it should be ~7, but it was just 1.6.

Hiroki pointed out that the REFL port in SRY (also SRX) is actually not the cavity reflection in the usual term. Fig. 2 shows the cavity mirror layout, and thinking of it carefully, the 'normal' cavity reflection for SRY is the beam going to ITMX (for SRX it's ITMX), and the REFL port is one of the cavity transmissions. In that sense, REFL and AS are equivalent for SRX/Y, and we should see the built-up power at both ports.

The buildup ratio at REFL and AS is 5.2 and 12, respectively. It seems consistent (but a bit low) at REFL, but at AS it is overestimated for some reason. On the other hand, the other ports show smaller buildup: 1.6 at POS (as mentioned above), 1.7 at POP, 1.5 at POP s-pol, and 2.3 at POP p-pol. We don't have any clear answer for them now.

Images attached to this report
MIF (ITF Control)
satoru.takano - 1:15 Wednesday 13 May 2026 (36879) Print this report
SRCL control imnplementation

[Dan, Fujimoto, Tanaka, Takano]

Summary

After adjusting SRM yaw, we successfully implemented the SRCL control with POP f1 signal. Currently the UGF is ~ 18 Hz. Also, SRM ADS worked with AS DC power.

Detail

After the PRM alignment (and the QPD centring work, which was found to be a failure later, though), we tried to close the SRCL control loop. Looking at several RF signals, we decided to use POP f1 I signal, which seemed to have a decent SNR. We copied all the filter banks from PRCL1 and PRCL2 and implemented them into SRCL1 and SRCL2. After tweaking the gain in SRCL2, SRY was stably locked with the setting below:

  • SRCL1: FM9 (pole: 0 Hz, zero: 8 Hz)
  • SRCL2: FM6 (an elliptic low pass with a cutoff at 300 Hz)
  • Gain: -800

With these filter bank settings, the open loop gain was measured as shown in Fig. 1. The UGF was ~ 18 Hz, and the phase margin was 43°.

Following the success of the SRCL control, we implemented a dithering control loop to improve SRM alignment. The dithered frequencies were 4.3 Hz for SRM pitch and 6.3 Hz for SRM yaw, and we demodulated the AS_PDA1_DC signal. The demodulation phase was set as shown in Fig. 2; I set it to 8° for pitch and 13° for yaw. The loops were closed with the gain of -1000 for both pitch and yaw control.

Even though the alignment was improved by SRM ADS, the intracavity buildup was only 1.5, which should be ~ 7, considering the BS and SRM transmission. It was also found that the REFL power increased when SRY was locked, which should be decreased. It might be that we locked SRY to higher-order modes, but judging from the camera images at AS and POP Spol, the fundamental mode appeared to be on resonance. Yesterday, we confirmed that the buildup factor for PRY was ~7, close to the expected value, so the birefringence loss does not seem to limit amplification. We need more information to investigate the reason.

 

Images attached to this report
MIF (ITF Control)
Hiroki Fujimoto - 0:40 Wednesday 13 May 2026 (36880) Print this report
SRM OPLEV QPD Centering

[Dan, Takano, Tanaka, Fujimoto]

Summary

From the previous SRC flash searches, it was found that a large yaw offset of the SRM is required to observe SRC flashes. Under such conditions, the SRM OPLEV beam went out of range of the QPD.
To address this issue, we performed centering of the OPLEV QPDs (TILT QPD and LEN QPD) for the aligned SRM.
Although the centering onto the QPDs were confirmed while we were in the mine, after returning to the control room we found that the beam was no longer incident on the TILT QPD. We plan to check the situation and recover the alignment tomorrow.

What we did

After obtaining a reasonable SRM alignment during the SRC flash search in the morning (klog #36876), we carried out the SRM OPLEV centering work in the mine in the afternoon.
Inspection around the QPD revealed that the beam was clipping on the holder of the first steering mirror. Therefore, we decided that rearrangement of all the optics, including the steering mirror, BS, TILT QPD, lens, folding mirror, and LEN QPD, was necessary.

First, we adjusted the position of the first steering mirror and aligned the beam onto the TILT QPD. After coarse alignment, fine adjustment was performed using the micrometer stage of the QPD while monitoring the QPD signals.

Next, alignment onto the LEN QPD was performed. For the LEN QPD, the distance relationships between the SRM and lens, and between the lens and LEN QPD, are important. Therefore, the downstream optics (BS, lens, folding mirror, and LEN QPD) were repositioned and aligned so that these distances matched the previous setup (klog #7952).

Fig. 1 shows a photograph of the final layout. The distances between optics are as follows:

  • TM to upper viewport: 990 mm (assumed to be the same as the previous setup)

  • Viewport to first steering mirror: 305 mm

  • First steering mirror to BS: 40 mm

  • BS to lens: 45 mm

  • Lens to folding mirror: 110 mm

  • Folding mirror to LEN QPD: 273 mm

After repositioning, final centering onto the QPD was performed using the micrometer stages of the QPD.


After the adjustment, the optical table was covered with aluminum foil, and we returned to the control room. At that point, we noticed that the beam was no longer incident on the TILT QPD. It is possible that the aluminum foil blocked the beam path or disturbed the alignment during covering. We plan to check the situation tomorrow and recover the alignment.

Images attached to this report
Comments to this report:
dan.chen - 16:44 Wednesday 13 May 2026 (36885) Print this report

[Tanaka, Fujimoto, Saito, Dan]

Summary

We checked the SRM OPLEV QPD signals after yesterday's centering work. The OPLEV beam was incident on both the TILT and LEN QPDs, but the environmental light and IR contribution were relatively large. We installed an IR filter also in front of the LEN QPD, centered both QPDs, and confirmed that the LEN OPLEV mainly responds to SRM longitudinal motion.

What we did

We first checked whether the OPLEV beam was incident on the QPDs. The environmental light level was large, so we reduced it as much as possible during the measurements.

For the TILT QPD, the sum signal was about 90 counts with the OPLEV beam and about 10 counts when the beam was blocked. Removing the IR filter increased the sum from about 90 to 230 counts, corresponding to an attenuation factor of about 2.6.

For the LEN QPD, no IR filter was installed at first. The sum signal was about 317 counts with the OPLEV beam and about 307 counts when the beam shutter was closed. After inserting an IR filter, the sum decreased to about 130 counts, corresponding to an attenuation factor of about 2.4. Opening the green shutter did not significantly change either QPD signal.

These checks showed that the OPLEV beam was already incident on both QPDs, but the IR contribution was non-negligible. Therefore, we decided to install/keep IR filters in front of both the TILT and LEN QPDs.

IR filter installation and QPD centering

We installed an IR filter in front of the LEN QPD using a right-angle clamp because of the limited space around the QPD.

After reducing the environmental light, with the OPLEV beam on, the IR shutter closed, (and the green shutter open,) the final sum values were:

  • TILT sum: 90.5 counts
  • LEN sum: 130 counts

We then centered both QPDs using the micrometer stages while monitoring the QPD signals.

LEN OPLEV response check

Finally, we excited the SRM in longitudinal and yaw at 10 Hz and checked the LEN OPLEV response. (Attached)

When the SRM was excited in the longitudinal direction, the response appeared in the LEN OPLEV signal. When the SRM was excited in yaw, the response clearly appeared in the TILT OPLEV signal. Therefore, we judged that the present oplev position is acceptable.

Files: `/users/VIS/TypeB/SRM/LogNotes/260513_oplev/`

Images attached to this comment
Hiroki Fujimoto - 3:34 Thursday 14 May 2026 (36892) Print this report

For additional information, I attached the photograph of the current SRM OPLEV QPD layout below.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 19:26 Tuesday 12 May 2026 (36878) Print this report
Live patching for a new vulnerability
A new vulnerability different from klog#36851 was addressed via live patching on gateway and web servers.
This is a temporary workaround without stopping any systems and services, not a vendor patch.
A formal fix will be implemented after the vendor patch will be released.
VIS (SRM)
ryutaro.takahashi - 16:27 Tuesday 12 May 2026 (36877) Print this report
Comment to Health check (36669)

I checked the behavior of the OSEM gains when the Type-B/Bp chambers were evacuated in June, 2024. The gains of some OSEMs in any IMs (PRM, PR2, PR3, BS, SRM, SR2, SR3) were reduced in vacuum.

MIF (ITF Control)
dan.chen - 16:09 Tuesday 12 May 2026 (36876) Print this report
Comment to SRC flash search (36873)

Takano, Fujimoto, Tanaka, Dan

Summary

We performed the initial alignment of the IFO by following the procedure in klog36759. After that, we tried to find the SRC flash by shaking SRM and moving SRM IP in yaw direction. Finally, we observed clear SRC flashes.

What we did

Initial alignment of IFO

First, we performed the initial alignment of the IFO. Since the transmissivity of SRM was changed, the usual initial alignment procedure cannot be used for the AS side alignment. Therefore, we adjusted the alignment by referring to klog36759.

For X-arm and Y-arm, we used the usual initial alignment procedure. After that, we continued the alignment according to the procedure described in klog36759. As written in the klog, we moved OMMT1 while monitoring OMMT1_TRAS_QPD1. When the beam position on OMMT1_TRAS_QPD1 became almost centered, we regarded the AS side alignment as good.

Search for SRC flash

Next, we tried to find the SRC flash by adjusting the alignment of SRM. We set only ITMY to LOCK_ACQUISITION and misaligned the other Type-A suspensions. We also restored the SRM IM OPTICALIGN pitch value to yesterday’s value of 3825. In this condition, we largely moved only the yaw alignment of SRM. We used the stepping motor and moved SRM IP F0_Y from about -12073 to -27073. Then the flash could be seen. After that, we continued the alignment while monitoring the flash signal. Finally, we found good SRC flashes with the following SRM IM OPTICALIGN values:

  • P: 3900
  • Y: 480

The flash signal was monitored with K1:LSC-POS_PPOL_DC_OUT_DQ. This is the signal from the temporary PD installed yesterday on the POS table, and the flash appeared clearly in this channel.

However, since the suspension was still oscillating, it was difficult to further optimize the alignment at this moment.

Next, we entered the mine, center the QPDs, and try to turn on the local controls.

Images attached to this comment
VIS (SRM)
takahiro.yamamoto - 11:30 Tuesday 12 May 2026 (36875) Print this report
Comment to Implementation of hierarchical control for TM (36870)

This foton error occurred because a filter bank block with one or more filter modules defined was removed from the model.
It was fixed by removing filter module definition of the removed filter bank block manually.

-----
In such case, "File errors" is displayed on a red background, and the error details pop up in a separate window when foton is opened as shown in Fig.1. In many cases, this type of error occurs when a filter bank is removed from the model while its filter design remains. This is because, when the model is rebuilt after deleting a filter bank block, the module name definitions at the top of the foton file are generated based on the new filter bank list, but the filter coefficient definitions are not cleaned up. Normally, this specification should not become a problem, because filter bank blocks are not repeatedly added or removed without sufficient consideration and reviews. But it often becomes an issue within KAGRA’s management and operation framework.

Anyway, VIS-SRM_TM_SENSCORR_L was removed from the k1vissrmp model probably in klog#36457 though some filter module definition was remained on that filter bank. An only safe method is to clean up the filter modules on the filter bank that will be deleted before installing the updated model. But in this case, nobody probably noticed fact that some filter banks would be removed because it's not mentioned in the model update plan (klog#36374). The other method is to edit the foton file manually after installing the updated model. Though foton files are in plain text format, their formatting is so strict and they can very easily become unreadable from foton or models by a manual edit. So it's never recommended. But this is only way if we couldn't notice before installing updated models and I did it in this time. Removed filter modules are shown in Fig.2.

After manual fixing, all errors were cleared on foton. But a warning still remains related to the too low (but non-zero) zero/pole as shown in Fig.3. Though it's not a problem on reading filters by foton and models, numerical errors often occurs on that filter bank. Please remove it if it's unnecessary, or please change corner frequency as a higher value with a careful design of the control if it's used.

Images attached to this comment
MIF (ITF Control)
kenta.tanaka - 21:53 Monday 11 May 2026 (36873) Print this report
SRC flash search

Dan, Takano, Fujimoto, Saito, Tanaka

## Abstract

We tried to find the SRC flash by moving alignment SRM. Yaw alignment seems to be larger than the range of IM actuator. We observed SRC flash after moving SRM and SR3.

## What we did

This morning, we tried find the resonancre in SRC by moving the alignment of SRM largely in both P and Y directions. Unfortunately, SRM DC control seems not work well. So we stopped the any DC controls of payload parts, and we decided to use OPTICALIGN to move alignments. This time, we aligned ITMY and misaligned other Type-As, that is, we made up SRY cavity. Moreover, we increased IMC power up to 10 W. We used awggui and set the excitation amplitude ~1000 cnts and the frequnecy 0.05 Hz in Yaw and 0.04 Hz in Pit, respectively. In this parameters, SRM alignments moved largely enough TM oplev gots out of ranges. However, any flash could not be observed in AS RF34 IQ signals and DC power in AS PDs. Therefore, we put the additional PD at the POS table to observe the flash.

This afternoon, we entered the mine and installed the additional PD just after the 2 inch lens in main IR beam path on POS table. Also, we used the POS PPOL PD channel (K1:LSC-POS_PPOL_DC) for this PD tempolarly. After that, we tried again. However, any flash could not be observed. We used TCam to find the beam spot reflected SRM on ITMY. 

Then, we increased Yaw scan amlitude to ~5000 cnts, which is the almost maximum. Then, Saito-kun found that the scattering at the edge of the TCam image.So we adjusted the actuator output when we observed the scattered light. Then, we oscllated the SRM only in Yaw direction. During the oscillation, we adjusted PItch by applying the DC offset with monitoring TCam image. After adjusting, the scattered light could be observed in the edge of both ITMY and ITMX TCam images once per 20 seconds. This duration seems to be consistent with the Yaw excitaition frequency. Therefore, the beam reflected from SRM seems to be shifted largely in Yaw direction. The shift amounts seems to be larger than the IM actuator range. So, it is necessary to use IP to move SRM more largely.

This time, we tried to moved SR3 in Yaw direction with oscllating SRM in Yaw direction. When SR3 moved to -100 urad from initial good setpoint, we can see the beam spot refleted from SRM in POP-SPOL camera. Moreover, the flash signals were observed in the additional PD and REFL PD when the beam spot reflected from SRM was overlaped on the beam spot reflected from ITM. Then, we stopped the excitation and set the actuator output when flash signal is observed in PDs (fig.1). 

However, the beam went away from AS PDs and camera when SRC flashes.

Images attached to this report
Comments to this report:
dan.chen - 16:09 Tuesday 12 May 2026 (36876) Print this report

Takano, Fujimoto, Tanaka, Dan

Summary

We performed the initial alignment of the IFO by following the procedure in klog36759. After that, we tried to find the SRC flash by shaking SRM and moving SRM IP in yaw direction. Finally, we observed clear SRC flashes.

What we did

Initial alignment of IFO

First, we performed the initial alignment of the IFO. Since the transmissivity of SRM was changed, the usual initial alignment procedure cannot be used for the AS side alignment. Therefore, we adjusted the alignment by referring to klog36759.

For X-arm and Y-arm, we used the usual initial alignment procedure. After that, we continued the alignment according to the procedure described in klog36759. As written in the klog, we moved OMMT1 while monitoring OMMT1_TRAS_QPD1. When the beam position on OMMT1_TRAS_QPD1 became almost centered, we regarded the AS side alignment as good.

Search for SRC flash

Next, we tried to find the SRC flash by adjusting the alignment of SRM. We set only ITMY to LOCK_ACQUISITION and misaligned the other Type-A suspensions. We also restored the SRM IM OPTICALIGN pitch value to yesterday’s value of 3825. In this condition, we largely moved only the yaw alignment of SRM. We used the stepping motor and moved SRM IP F0_Y from about -12073 to -27073. Then the flash could be seen. After that, we continued the alignment while monitoring the flash signal. Finally, we found good SRC flashes with the following SRM IM OPTICALIGN values:

  • P: 3900
  • Y: 480

The flash signal was monitored with K1:LSC-POS_PPOL_DC_OUT_DQ. This is the signal from the temporary PD installed yesterday on the POS table, and the flash appeared clearly in this channel.

However, since the suspension was still oscillating, it was difficult to further optimize the alignment at this moment.

Next, we entered the mine, center the QPDs, and try to turn on the local controls.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 20:52 Monday 11 May 2026 (36874) Print this report
MTP fiber laying at EXV for V2 IO chassis
[Ikeda, Nakagaki, YamaT]

As the initial preparation of the IO chassis replacement, we laid the MTP-LC breakout cable from EX1 rack at the front-room of the 2nd floor to EXV1 rack.
The new cable is housed in the existing corrugated tube and will be used when IO chassis of K1EX1 will be replaced as V2 one.

V2 IO chassis for K1EX1 was also transported to the end station.
We will replace the IO chassis for K1EX1 on the maintenance day in near future.
DGS (General)
takahiro.yamamoto - 20:42 Monday 11 May 2026 (36872) Print this report
Comment to Deployment of V2 IO-chassis and the front-end computer for EX0 (36654)
[Ikeda, Nakagaki, YamaT]

Abstract

All the necessary items had been gathered just before holidays, so K1EX0 front-end computer was moved to EX1 rack at the 2nd floor.
Though some equipment which is no longer necessary such as Timing Fanout are still in the EX0 rack, replacement of EX0 IO chassis itself was completed.
Clean-up of unnecessary equipment will be able to be done not on the maintenance day because we don't need to stop anything for this work.

Because an IRIG-B issue (klog#36705, klog#36819) was reproduced on K1EX0, IRIG-B card was also replaced as one which has no problem on the test stand.
After then, the issue was removed, so we kept to use the new IRIG-B card for K1EX0.
Problematic one will be checked again on the test stand.

Details

Although the IO chassis had been replaced in klog#36654, the move of the front-end computer to the second floor had been postponed due to a shortage of necessary cables. Because the necessary cables were obtained just before holidays, we moved the front-end computer from U13-14 of EX0 rack around the EXC chamber to the U22-23 of EX1 rack at the 2nd floor. There were no major issues with this work, and we didn't encounter any problems around PCIe cards such as ADC and DAC. With this work completed, the replacement of the EX0 I/O chassis is now completed, and the equipment in the EX0 rack such as the timing fanout, IRIG-B chassis, KVM, and 12V DC power supply unit is no longer needed. However, this unnecessary equipment is still left at EX0. Since it can be removed without disrupting the digital system, we plan to remove it at an convenient time.

After moving the computer to the second floor, the IRIG-B issue reproduced during the first startup, and neither a reboot nor a cold boot resolved the problem. Though we have not identified a clear cause or solution for this issue yet, we replaced the IRIG-B card with one that has no problem on the test bench, and the issue was removed. So we kept to use the new IRIG-B card for K1EX0. We cannot conclude this issue is caused by an individual difference of IRIG-B card from today's result yet. If so, a problematic cards on another front-end computers also must be replaced (at least 3 cards). We faced this issue in 3 of 4 front-ends that we worked on recently. Though I'm not sure it comes from a problem rate or just bad luck, it’s possible that a certain percentage of the cards currently in use at the coner station have the same problem, which may require replacements for more units.

IOO (IMC)
satoru.ikeda - 17:34 Monday 11 May 2026 (36871) Print this report
Comment to IMC cannot be locked 260511 (36869)
Error: Permission denied, please try again.
Permission denied, please try again.

A permission error occurred during the callback process from the HWP control PC to k1script.

k1script0
The callback from HWP, which had been specified in .ssh/authorized_keys, was commented out.
Since this was an emergency response, we first restored the original settings. Because the callback for the final move command was malfunctioning, we first performed a command-line callback from the HWP control PC to k1script0 to restore the callback that had been causing the permission error.
After that, we confirmed that HWP was responding correctly to commands from Guardian and performing the necessary processing.

Non-image files attached to this comment
VIS (SRM)
ryutaro.takahashi - 15:39 Monday 11 May 2026 (36870) Print this report
Implementation of hierarchical control for TM

I implemented the hierarchical control for TM with the Oplev. To feed back the DC signals to the IM pitch and yaw, the transfer functions from the IM actuator to the TM Oplev were measured (Ptot 1 and 2). The "DC" (FM9) in the OLDAMP FILTERS in the TM loop was switched off, and the "int" (FM10) in the OLDAMP FILTERS in the IM loop was switched on. The cross-frequency between the TM and IM loops is now below 0.1Hz (I couldn't edit the filter modules in Foton due to the file errors).

Images attached to this report
Comments to this report:
takahiro.yamamoto - 11:30 Tuesday 12 May 2026 (36875) Print this report

This foton error occurred because a filter bank block with one or more filter modules defined was removed from the model.
It was fixed by removing filter module definition of the removed filter bank block manually.

-----
In such case, "File errors" is displayed on a red background, and the error details pop up in a separate window when foton is opened as shown in Fig.1. In many cases, this type of error occurs when a filter bank is removed from the model while its filter design remains. This is because, when the model is rebuilt after deleting a filter bank block, the module name definitions at the top of the foton file are generated based on the new filter bank list, but the filter coefficient definitions are not cleaned up. Normally, this specification should not become a problem, because filter bank blocks are not repeatedly added or removed without sufficient consideration and reviews. But it often becomes an issue within KAGRA’s management and operation framework.

Anyway, VIS-SRM_TM_SENSCORR_L was removed from the k1vissrmp model probably in klog#36457 though some filter module definition was remained on that filter bank. An only safe method is to clean up the filter modules on the filter bank that will be deleted before installing the updated model. But in this case, nobody probably noticed fact that some filter banks would be removed because it's not mentioned in the model update plan (klog#36374). The other method is to edit the foton file manually after installing the updated model. Though foton files are in plain text format, their formatting is so strict and they can very easily become unreadable from foton or models by a manual edit. So it's never recommended. But this is only way if we couldn't notice before installing updated models and I did it in this time. Removed filter modules are shown in Fig.2.

After manual fixing, all errors were cleared on foton. But a warning still remains related to the too low (but non-zero) zero/pole as shown in Fig.3. Though it's not a problem on reading filters by foton and models, numerical errors often occurs on that filter bank. Please remove it if it's unnecessary, or please change corner frequency as a higher value with a careful design of the control if it's used.

Images attached to this comment
ryutaro.takahashi - 14:03 Wednesday 13 May 2026 (36882) Print this report

I modified the servo filter "int" (FM10) in the OLDAMP FILTERS in the IM loop. The cross-frequency between the TM and IM loops was set to 0.1Hz for both pitch and yaw directions. I offloaded the IM pitch with the picomotor.

kenta.tanaka - 20:13 Wednesday 13 May 2026 (36888) Print this report

I modified the ALIGNED state's script of the SRM guardian to engage this hierarchical control. I confirmed that this control was engaged by the guardian and that the guardian could transit between ALIGNED and DAMPED states.

Note:

I have not implemented "LOCK_ACQUISITION" state for SRM. So please do not request SRM guardian to go to "LOCK_ACQUISITION" state. Also, MISALIGNED state has not been implemented.

IOO (IMC)
takaaki.yokozawa - 7:55 Monday 11 May 2026 (36869) Print this report
IMC cannot be locked 260511
In this morning, I noticed that the IMC was not locked for a long time.
Previous locked loss 9th May. 02:12 (JST)

From my eye, the HWP PSL didn't move, could someone check it?
Images attached to this report
Comments to this report:
satoru.ikeda - 17:34 Monday 11 May 2026 (36871) Print this report
Error: Permission denied, please try again.
Permission denied, please try again.

A permission error occurred during the callback process from the HWP control PC to k1script.

k1script0
The callback from HWP, which had been specified in .ssh/authorized_keys, was commented out.
Since this was an emergency response, we first restored the original settings. Because the callback for the final move command was malfunctioning, we first performed a command-line callback from the HWP control PC to k1script0 to restore the callback that had been causing the permission error.
After that, we confirmed that HWP was responding correctly to commands from Guardian and performing the necessary processing.

Non-image files attached to this comment
DGS (General)
shoichi.oshino - 15:24 Saturday 09 May 2026 (36868) Print this report
Installed new network switch at Control Room
As reported in klog21826, the daisy-chained network configuration of the workstations (WS) located at the front of the control room has been improved.
However, in March, an issue was observed on k1mon3 where the displayed positions of the GigE cameras became unstable. This phenomenon has not reoccurred since then, suggesting that its correlation with network speed may be limited.
Even so, the control room displays a large number of ndscope channels along with camera images. To further improve the network environment, a new network switch has been installed. This switch is connected to the upstream network at 10 Gbps, and the available bandwidth is currently considered sufficient.
The switch is installed on the PC wagon of k1mo10. It is connected via an optical fiber cable laid from the computer room next to the control room.
For installation, k1ctr2 and k1ctr3 were temporarily shut down to ensure accessibility. For k1mon[0–4,10] and k1ctr[4–5], the LAN cables were switched without shutting down the workstations. After the work, connectivity with all these WS was confirmed.
To be safe, the previous LAN cables and network switch have been retained in case any issues arise. If no problems are observed after a period, removal of the old equipment will be carried out.
DGS (General)
takahiro.yamamoto - 21:29 Friday 08 May 2026 (36867) Print this report
Comment to Applying critical security patch (36851)
Same security patches were applied also to k1cam[0-2] and k1script0.

Though a mitigation measures for this issue were applied all affected DGS servers including intranet ones, a temporal solution is still used for k1gate and gwdet because vendor's patches for Red Hat like OS hadn't been released yet in last time. Today vendor's patches were released but there was no enough time to test and apply them because of HDD trouble on k1script0. So I will apply them to k1gate and gwdet in next time and will remove a temporal solution applied in klog#36851.
Search Help
×

Warning

×