Reports of 33901
VIS (General)
ryutaro.takahashi - 20:52 Monday 09 March 2026 (36534) Print this report
Comment to Offload of GAS filters and IPs (36516)

I offloaded the following GAS filters with the FRs.

  • ITMX: F0 GAS
  • ITMY: F0 and BF GAS
  • ETMX: F0 and BF GAS
  • ETMY: F0, F1, F3, and BF GAS
MIF (General)
kentaro.komori - 19:49 Monday 09 March 2026 (36533) Print this report
Investigation of mysterious GR-IR coupling: Day 1

[Tanaka, Ushiba, Komori]

Abstract:

We started investigating a mysterious coupling between the IR flashing and the green PDH signals.
Our initial tests suggest that the coupling is likely mediated through the RF signals of the IR RFPDs.

Detail:

The issue of the mysterious IR–GR coupling has persisted for a long time.
Due to this issue, we cannot open the shutter in front of the REFL QPDs or increase the power at the out-of-loop CARM PD, and we frequently suffer from lock losses during the IR handover stage.
If this issue can be resolved, a significant improvement in several operational aspects is expected.

To investigate the origin of this issue, we compared the power spectrum of the ALS DARM signal under several configurations, as shown in the figure.
The reference spectra are the blue and green lines, where the PRM is misaligned and aligned after the IR finds resonance with the conventional cable connections, respectively.
IR flashing clearly produced a noisy DARM spectrum, consistent with the noisy behavior observed in the time-series data.

First, we turned off all REFL PDs by switching off the PD power supply board, and we did not observe the additional noise (brown).
Next, we focused on one of the problematic PDs, REFL PDA3, with the PD power supplies for PDA1 and PDA2 turned off and only PDA3 powered on, while the RF output signal was terminated (magenta).
We did not observe additional noise in either case.
This result suggests that the issue is not caused by a simple cable connection without the power supply, but rather by the connection between an operating PD and the demodulator.

Next, we measured the noise with PDA3 connected using a different cable instead of the conventional one.
In this case, the noise reappeared (green), indicating that the issue does not depend on the cable routing.

Tomorrow, we will test the effect of inserting an RF transformer (T1CA made by R&K), which isolates the ground and blocks the DC signal between the input and the output.

Images attached to this report
VIS (SRM)
naoatsu.hirata - 19:27 Monday 09 March 2026 (36531) Print this report
IRM damper installation

[Takahashi, Washimi, Hirata]

 

We did preparation for installation of SRM IRM dampers.Today, we locked suspension, and Breadboard. After that we removed Mid-size baffles from the breadboard.

1. Lock IP and Topfilter
After opening the top flange of chamber, we locked IP and Topfilter. We covered suspension by Seiden-sheet. (Guardian status was already SAFE mode.)

2. Check the mirror height
We checked the mirror height by laser leveler. Beam height is indicated on SRM chamber(Main mark is on +Y+X side. Copy is on -Y+X side. pic1, pic2 )
Unfortunately, Beam height is close to the edge of side flange. So laser leveler could only be used near the center.(pic3) We put green laser leveler at the +X side, and align to the Beam height mark on the chamber.
And put red laser leveler at -X side, and align it to the +X side green laser leveler(pic4). Recoilmass front ring has center mark. We can see the laser leveler height and the recoilmass center line.

・+X side (Green line) looks same as recoilmass center line.(pic5)
・-X side (Red line) looks 3 millimeters away from the recoilmass.(pic6)

3. Check the Bread board height
Laser leveler can only used around center of side flanges. So we can only check the height near the center.

・+X side (Green line) is 380.5mm.(pic7)
・-X side (Red line) is 383.0mm.(pic8)

4. Lock the Breadboard
Turn 4 foot screws to lower  that until they touch the block. After that, added 4 masses(Total 20kg) on the breadboard for locking. (pic9)

5. Lock the Suspention
Bottomfilter, IMR, IM, RM and TM were locked.

6. Mark the Mid-size baffle position
To record the current baffle positions, 3 blocks(AL clamps) were set on each baffle.(pic10)

7. Remove Mid-size baffles
We removed 4 fixed clamps, and removed mid-size baffles(AR side and HR side). Clamps for the mid-size baflles remain on the bread board.(Note that those positions have been changed.) (pic11)
Removed Mid-size baffles are on the tables have 4 pillars, and wrapped by plastic films. 4 pillars preventing plastic film touch baffles. (pic12)

*We weighed removed baffles.

・HR side : 4.94kg
・AR side : 4.931kg

Today's pictures are https://www.dropbox.com/scl/fo/1dw0adstbz35z85i0vd91/AJlOguQbuxD332fX1ZaIiYE?rlkey=xv1ztcd0wli70ukd0hxlslcl0&st=sfhiadap&dl=0

Images attached to this report
MIF (General)
kenta.tanaka - 18:23 Monday 09 March 2026 (36532) Print this report
Comment to LO for GRX PDH was out of order (36530)

Ushiba, Komori, Tanaka

We tempolary replaced the LO to the other one, which was used PLL before (fig.1). Now, GRX could be locked.

Images attached to this comment
MIF (General)
kenta.tanaka - 13:07 Monday 09 March 2026 (36530) Print this report
LO for GRX PDH was out of order

Ushiba, Yokozawa, Tanaka

This morning, we found that GRX could not be locked even though the flash amount seemed to be large enough (> 0.8 from the view of K1:LSC-TR_GRX_NORM_OUT_DQ ). According to the GRX PDH error signal channel (K1:ALS-X_PDH_MIXER_DAQ_OUT),  Any PDH-like signals seem to be not observed. However, since the DC power on the PD has some responce whenever GRX was flashed, the PD for PDH itself seems to be turned on. Also, CMS seems to be turned on because K1:ALS-X_PDH_MIXER_DAQ_OUT has some responses when we operated some switches on the CMS. So we suspected that the LO has something wrong.

Yokozawa-san and I entered mine and confirmed the LO and the CMS for PDH were turned on. Then, we checked whether the LO emitted the 33 MHz signal or not by using Moku:lab. However, we could not obsered any signal at 33 MHz. (This time, we confimed Moku:lab could be observed the output of GRY LO which emited the signal with the almost same amplitude at different frequencies.)

We tried to solve it by restarting the LO but the situation was not changed. After this, we found that the "UNLOCK" and "ERR" sign were shown on the display. we checked the error messages. There are many error messages (fig.1).

According to the manual, we need to ask the manufacturer to fix the LO in the case that their messages are shown. This afternoon, we will bring the other RF generator from Mozumi and try to solve this issue by replacing the LO.      

Images attached to this report
Comments to this report:
kenta.tanaka - 18:23 Monday 09 March 2026 (36532) Print this report

Ushiba, Komori, Tanaka

We tempolary replaced the LO to the other one, which was used PLL before (fig.1). Now, GRX could be locked.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 11:53 Monday 09 March 2026 (36529) Print this report
Comment to Compatibility check of a2A5328-4gmPRO camera and pylon-camera-server (36390)
This camera cannot be found in the CAM network now.
A PoE function might not be enabled at an used network port on that switch.

I can have a time to check it in next week.
If early restoration is required, please connect it to the CAM switch at IOO0 rack or return it back to one at OMC fire alarm rack.

DGS (General)
takahiro.yamamoto - 11:18 Monday 09 March 2026 (36527) Print this report
acA4112-8gm operation via pylon-camera-server
a2A5328-4gmPRO which was a candidate of a new TCam didn't work via pylon-camera-server due to a compatible issue of a SDF version and had limitation for a full-spec operation in the CAM network due to the traffic issue (klog#36390).
acA4112-8gm which works with a compatible version of SDK was installed as an alternative candidate (klog#36510).
It was able to work with pylon-camera-server.
On the other hand, there is still limitation for a full-spec operation in the CAM network though a traffic requirement of this camera is slightly lower than a2A5328-4gmPRO.
So we need to consider well that limited specifications are enough or not for TCam purposes.

-----
Though acA4112-8gm has 4096x3000 resolution as a full-specification, pylon-camera-server hung up with that resolution due a packet loss issue. So I reduced a resolution as 2048x1500 (1/2 scaling from a full-spec), then it was able to launched via pylon-camera-server.

Points to note and considerations are as follows:
1) I haven't checked an impact on the existing GigE camera system though a traffic with operating that resolution is too large for the CAM network. So more scaling (1/4 = 1024x750 or 1/8 = 512x375) is probably required for actual operation in the CAM network.

2) pylon-camera-server can be used only 'Mono8' format. Configuration file accepts various video formats in GStreamer such as Gray8, Gray12_LE, etc. and pylon-camera-server can receive various capture format such as Mono8, Mono12, etc. But an implementation of internal buffers are hard-coded as 1-Byte. So 8-bit format is actually available. When a format with more than 8bit, pylon-camera-server hangs up by inconsistency of a packet format.

3) Though a configuration file of pylon-camera-server has "width/height" parameters, they are for the resolution of a broadcast for downstream (client workstations). So a resolution of camera operation itself must be changed by a external script before launching pylon-camera-server.

4) Taking snapshot via pylon-camera-server is done with a resolution for the broadcast to the downstream. For this reason, when we want to change the resolution between broadcasted movies and taken snapshots, pylon-camera-server must be stopped via systemd during snapshot processes.

From these notes, we concluded that we need to confirm that Mono8 and limited resolution less than or equal to 1024x750 are enough or not if a new TCam rides on the current TCam network without any infrastructure and software upgrades.
MIF (General)
takafumi.ushiba - 10:44 Monday 09 March 2026 (36528) Print this report
Comment to Pause LSC_LOCK and INITIAL_ALIGNMENT guardian (36513)

I commented out all the request for SRM in te LSC_LOCK guardian and INITIAL_ALIGNMENT guardian.
These guardians can be used without conflicting SRM hardware work now, so I executed these guardians.

CAL (General)
dan.chen - 10:37 Monday 09 March 2026 (36526) Print this report
Comment to O4a Calibrated Reconstruction Data Verification (36096)

The Check 3 script has been developed and tested.
The comparison between the LL spectrum and the RAW-based reconstructed spectrum shows generally good agreement.

Detailed Working Logs:

 

PEM (EY)
takaaki.yokozawa - 8:30 Monday 09 March 2026 (36525) Print this report
Comment to PEM injection test 260225 (36444)
I also evaluated the coherence for each injections.
Images attached to this comment
VIS (General)
ryutaro.takahashi - 9:00 Sunday 08 March 2026 (36524) Print this report
Comment to Offload of GAS filters and IPs (36516)

I offloaded the F0 and F1 GAS filters in IX with the FRs.

VIS (General)
ryutaro.takahashi - 14:16 Saturday 07 March 2026 (36523) Print this report
Comment to Offload of GAS filters and IPs (36516)

I offloaded the following GAS filters and IP with the FRs.

  • ITMX: F0 GAS
  • ITMY: F0 GAS
  • ETMY: F0 GAS, H2 IP
PEM (EY)
takaaki.yokozawa - 10:13 Saturday 07 March 2026 (36522) Print this report
Comment to PEM injection test 260225 (36444)
I checked the PMC related channels (DQ channels).

There are two type of the channels
Type A :
K1:CAL-CS_PROC_PMC_FREQUENCY_DQ
K1:PSL-PMC_PZT_HV_MON_OUT_DQ
K1:PSL-PMC_PZT_SLOW_OUT_DQ

Type B :
K1:LAS-POW_PMC_OUT_DQ
K1:PSL-PMC_TRANS_DC_OUT_DQ


80 - 220 Hz :
No or very small excess in Type-A

180 - 220 Hz :
Continuously larger excess above 240 Hz
Large peak at 218 Hz
Small peak at 278 Hz

280 - 420 Hz :
Continuously larger excess
Several peaks in 328, 336, 345, 348, 358, 370, 388 and 397 Hz

380 - 520 Hz :
Continuously larger excess
Several peaks in 430, 448, 467 and 492 Hz

480 - 620 Hz :
Continuously larger excess
Only very small peaks

580 - 720 Hz :
Continuously larger excess
Only very small peaks
715 Hz peak

If we can perform the whitening filter to Type-B channels, we can see more interesting results
Images attached to this comment
CRY (Cryostat EY)
nobuhiro.kimura - 8:37 Saturday 07 March 2026 (36521) Print this report
Registered temperature calibration data to Y-end Cryocon

[Kimura and Yasui]
 Temperature calibration data was registered to Y-end Cryocon.
The registration date and time were March 6, 2026, 11:00 AM to 11:30 AM.
The name of the Cryocon to which the temperature calibration data was registered is EY2: Duct Shield 1.
The registered temperature calibration data is the resistance/temperature curve for a platinum-cobalt resistance thermometer (PtCO).
After registering this temperature data, the temperature calibration data for channels D to H channels of EY2: Duct Shield 1 were changed from platinum resistance thermometer (Pt100) to PtCO.
The resulting temperature difference at room temperature was +2 K.
This temperature difference increases significantly at cryogenic temperatures.

VAC (SRM)
nobuhiro.kimura - 7:53 Saturday 07 March 2026 (36520) Print this report
Pressurized SRM up to 87 kPa by air

[Kimura and Yasui]
 From 13:30 to 16:30 on March 6, the SRM was pressurized to 87 kPa with compressed air below the dew point of -40 Celsius degrees.
It will continue to be pressurized to atmospheric pressure on March 9 morning.

DGS (General)
takahiro.yamamoto - 21:42 Friday 06 March 2026 (36519) Print this report
Migrating scripts from k1script1 to k1script0.
In klog#36430, the new script server with the latest OS was prepared as k1script0.
So I started to migrate scripts on k1script1 running as the old OS to k1script0.

Today, EPICS DAQ systems (CC-10, GM-10 and Cryocon) were moved to k1script0.
They works fine without any code modification.

There were still more than 20 processes on k1script1.
So they will also be moved one-by-one.
MIF (General)
takafumi.ushiba - 18:16 Friday 06 March 2026 (36518) Print this report
GR flashes were recovered

Soon after Type-A suspensions are aligned, both GRX and GRY flashes inside the arm cavities.
So, no serious misalignment happens during the blackout.

VIS (General)
takafumi.ushiba - 18:14 Friday 06 March 2026 (36511) Print this report
All VIS seems to be recovered

Though saturation of the actuators occured, all VIS finaly reached the LOCK_ACQUISITION state after offloading actuators.
Since ITMX F0 GAS and ETMY IP H2 actuators are saturating, they should be offloaded again.

VIS (SRM)
ryutaro.takahashi - 17:51 Friday 06 March 2026 (36517) Print this report
Comment to Preparation for SRM installation (36327)

I glued the magnets to the side plates for the IRM damper. 

Images attached to this comment
VIS (General)
ryutaro.takahashi - 17:27 Friday 06 March 2026 (36516) Print this report
Offload of GAS filters and IPs

I offloaded the following GAS filters and IPs with the FRs for the recovery from the power outage.

  • SRM: F0 GAS, H1 IP
  • SR2: F0 GAS
  • SR3: F0 GAS
  • BS: F0 and F1 GAS
  • ITMX: F0, F1, F2, and BF GAS
  • ITMY: F0, F1, F2, F3, and BF GAS
  • ETMX: F0, F3, and BF GAS
  • ETMY: F0, F1, F2, F3, and BF GAS, H1 and H2 IP
  • PR3: SF and BF GAS (FR for SF GAS reached SW limit)
Comments to this report:
ryutaro.takahashi - 14:16 Saturday 07 March 2026 (36523) Print this report

I offloaded the following GAS filters and IP with the FRs.

  • ITMX: F0 GAS
  • ITMY: F0 GAS
  • ETMY: F0 GAS, H2 IP
ryutaro.takahashi - 9:00 Sunday 08 March 2026 (36524) Print this report

I offloaded the F0 and F1 GAS filters in IX with the FRs.

ryutaro.takahashi - 20:52 Monday 09 March 2026 (36534) Print this report

I offloaded the following GAS filters with the FRs.

  • ITMX: F0 GAS
  • ITMY: F0 and BF GAS
  • ETMX: F0 and BF GAS
  • ETMY: F0, F1, F3, and BF GAS
DetChar (General)
hirotaka.yuzurihara - 16:26 Friday 06 March 2026 (36515) Print this report
Comment to Shutdown of detchar computers located in the mine (36480)

The detchar computers (k1det0, k1det1) came back online from the power outage. The regular production of the segment files at k1det1 restarted without issues.

MIF (General)
kenta.tanaka - 15:23 Friday 06 March 2026 (36514) Print this report
GRX/Y laser shutter recovery

Ushiba, Tanaka

Ushiba-san found that GR beams did not reach the input mirrors even though PR3(SR3) alignment was restored. According to each GR input monitor on POP/POS, GR beams seems to reach to POP/POS table. So I entered the mine and checked the GR laser shutters works or not.

At first, I checked the GRX laser shutter on the POP table. Since the display showed something, the driver itself seemed to be turn on. In this state, I tried to open and close the shutter by medm screen. However, the shutter did not work. Then, I tried to open and close the shutter manually by using the wheel on the driver. I confirmed that I could open and close the shutter manually. So the driver and shutter themselves seems to work. Again, I retried to open and close it by medm screen. Then, I could do so.

Similarly, the GRY shutter could be recovered by the same procedure.

We are not sure of the reason why. One of possibilities is that the current amount to work the shutter is not enough. We used Thorlabs SH1 as the GR shutter and  Thorlabs KSC101 as the GR shutter driver. However, KSC101 is designed for a half inch shutter but SH1 is a 1-inch shutter. So we used the driver to work the larger shutter than one that makers expect. Maybe while the driver keep working, we can move the shutter remotely. However, the driver is turned off once. we may need to move the shutter manually once in order to move it remotely .

MIF (General)
takafumi.ushiba - 12:51 Friday 06 March 2026 (36513) Print this report
Pause LSC_LOCK and INITIAL_ALIGNMENT guardian

I paused LSC_LOCK and INTIAL_ALIGNMENT guardian because they change SRM guardian state and would be dangerous during SRM hardware works.
Please do not use these guardians until properly managed their guardian state not to change SRM state or SRM work will be finished.

Comments to this report:
takafumi.ushiba - 10:44 Monday 09 March 2026 (36528) Print this report

I commented out all the request for SRM in te LSC_LOCK guardian and INITIAL_ALIGNMENT guardian.
These guardians can be used without conflicting SRM hardware work now, so I executed these guardians.

VAC (General)
takashi.uchiyama - 12:36 Friday 06 March 2026 (36512) Print this report
Comment to Recovery of vaccum system after the blackout (36500)
2026/03/06

We opened and actvated interlock systems for GVifi, GVbsx, GVitmx, GVetmx, GVbsy, GVitmy, and GVetmy in the moring on March 6, 2026.
We also opened GVtmsx and stopped TMP of TMSX.
PEM (Center)
takaaki.yokozawa - 11:29 Friday 06 March 2026 (36510) Print this report
Install the new test gigE camera to OMC area
For the test of the new TCam setup, we installed the new type of the gigE camera(acA4112-8gm).
The detail can be found in kagra wiki page.
Images attached to this report
Search Help
×

Warning

×