Reports of 33846
PEM (Center)
tatsuki.washimi - 17:57 Monday 02 March 2026 (36471) Print this report
Comment to Test the Magneticfield Measurements for the Power Outage (36393)

(Log for Friday's work)

To investigate the line noises and the low-frequency 1/f noise, whether they were actual magnetic field or sensing noise, I located the sensors at opposite direction (Y-direction) and checked their coherence and phase.
The spectrum shape is lmost the same for both channels.
There were large coherence (~1) for both the line noises and the low-frequency 1/f noise, and the phase was about 180 degree. So we can say these noises are actual magnetic field.

 

After these tests, I recoverd the sensor positions and directions to the original ones. (Hx for the X-direction, Hy for the Y-direction)

Images attached to this comment
VIS (SRM)
ryutaro.takahashi - 17:41 Monday 02 March 2026 (36477) Print this report
Comment to Preparation for SRM installation (36327)

The FLDACCs for SRM moved back to the SR-OMC area from the BS area. I went to the second reassembly of the broken FLDACCs. #2 folded pendulum block was replaced with #8 block (Picture #1). The assembled pendulum looks fine (Picture #2).

Images attached to this comment
DetChar (General)
takahiro.yamamoto - 15:46 Monday 02 March 2026 (36476) Print this report
Updates of makeCache script
As a part of migration work to the new script server prepared in klog#36430, I updated makeCache script and moved it from k1script1 to k1script0.

-----
Details of update
makeCache script had a duplication issue such as klog#34595 and we sometimes needed to fix cache files by manually. For future observing runs, I rewrote the makeCache script to remove this issue. And also, scatterred scripts for each frame type such as full, science, second, etc. were merged to one new script. Old makeCache.sh which can provide only full frames cache was renamed as makeCache_FullFrame.sh and the new script was added as makeCache.sh.

These changes was made in the origin/ir1-upgrade branch and haven't been merged to the origin/master branch. And also, it was deployed at Kamioka by switching a branch of /users/DET/tools. Now the old scripts on k1script1 was stopped and the new script is launched on k1script0. I haven't prepared a condor submission file, so the old scripts in the origin/master branch are still being used at Kashiwa. After preparing the condor submission file, we can use it at Kashiwa and merge origin/ir1-upgrade branch to the origin/master branch.

By the way, I added a 'O4c' tag to a current HEAD of the origin/master branch as a snapshot of softwares used during O4c.

A change in the mountpoint of DET servers
Some DET servers still mounted the hyades-1 disk and used the hyades-0 disk as a primary one. But hyades-1 has ready retired and is currently on standby as a backup server. So I chagend mountpoint from the hyades-1 disk to the hyades-2 disk and the hyades-2 disk is set as the primary disk because it can store files during longer term than the hyades-0 disk.
PEM (General)
takafumi.ushiba - 13:49 Monday 02 March 2026 (36475) Print this report
Comment to Modify the k1pemmanage model : add the snow monitor channel (35971)

Since newly added channels are not monitored by SDF, I started to monitor these channels as shown in fig1.

Images attached to this comment
MIF (ASC)
dan.chen - 13:46 Monday 02 March 2026 (36474) Print this report
ASC SDF accept

With Kenta Tanaka

We accepted SDFs caused by the works on klog36194.

 

Images attached to this report
VIS (General)
ryutaro.takahashi - 13:25 Monday 02 March 2026 (36473) Print this report
SDF check for VIS

[Takahashi, Ikeda]

We checked if the SDFs for VIS are 0. We attached MON flags to the SDFs that changed due to the model modification in SRM.

Images attached to this report
IOO (IMC)
takafumi.ushiba - 11:05 Monday 02 March 2026 (36472) Print this report
SDF accept for laser temp bias

SDF of K1:IMC-SERVO_NPRO_TEMP_BIAS_OFFSET was changed from 5 of January.
Though laser work was conducted at that time (klog36019), there is no description on the laser temp bias changes and according to the working log, there seems no need to change temp bias.
So, I'm not so sure this change is related to this laser work.

Anyway, we confirmed IFO can be locked with the current EPICS values, I accepted the SDF shown in fig1.

Images attached to this report
FCL (Inflastructure)
shinji.miyoki - 20:39 Sunday 01 March 2026 (36470) Print this report
SR-OMC area cleaning day3

[Miyoki]

The cleaning was done.

The water dropping above -X side of SRM continues. We put a wavy plastic plate and dust cloth to catch the water dropping. So we should be careful when  the top curtain will be opened.

Images attached to this report
DGS (General)
takahiro.yamamoto - 15:44 Sunday 01 March 2026 (36469) Print this report
Comment to Compatibility check of a2A5328-4gmPRO camera and pylon-camera-server (36390)

I tried using the a2A5328-4gmPRO camera while it was occupying k1cam1.
But high-resolution and/or high-bit-depth recording still failed.
So using dedicated camera server doesn't become a solution for this issue
And also, either an upgrade of the network capacity or an allocation of dedicated bandwidth seems to be necessary.

-----
Bottleneck investigation
To isolate a network capacity issue from a server capacity issue, I moved all acA640-120gm cameras to k1cam0 and k1cam2, then tested a2A5328-4gmPRO while k1cam1 exclusively occupied by it. But capturing high-resolution and/or high-bit-depth images was still failed. Increasing buffer size of NIC from 256kB to 4096kB (upper limit) by ethtool didn't change a situation. In this configuration, a25328-4gmPRO should be able to occupy 1Gbps band-width on the NIC of k1cam1. And also, this situation isn't probably improved by using 10GigE NIC for k1cam1 because NIC of a25328-4gmPRO is 1GbE.

These facts suggest that a current limitation is actual throughput of a network path which can be occupied by a2A5328-4gmPRO. (I haven't isolated just a bandwidth issue from buffer size issue of each network switch.) Current connection of the CAM network is shown in Fig.1. Though the core camera switch in the server room on which all traffic concentrates is 10GigE one, edge switches except at IOO and connections are 1GbE. (Because all cameras in the corner station were connected from IOO rack in the past, only the edge switch at IOO is 10GigE one.) acA640-120gm which is main cameras for KAGRA GigE system is used with 640x480 as resolution, 8bit depth (Mono8) and 25fps. So ~60Mbps per 1 camera is required and 1Gbps bandwidth is enough to stably use 12-13 cameras (corresponding to ~70% of full bandwidth) and managing 18 cameras with 2 camera servers and one 10GigE core switch is sufficient.

a2A5328-4gmPRO is designed as using almost full width of 1Gbps to send caputured images (It's natural behavior because if bandwidth is limited as slower than 1Gbps, a risk of a connection time-out increases for high-resolution cameras such as a2A5328-4gmPRO.) So sharing bandwidth of 1GbE with another devices is not proper configuration for a2A5328-4gmPRO. If network paths will be shared, the CAM network should be upgraded to 10GigE for at least the shared paths with a2A5328-4gmPRO. Another solution is connecting a2A5328-4gmPRO to the core switch in the server room directly. But it may be more tough work than preparing a dedicated TCam server physically near a2A5328-4gmPRO.

Simple camera server application for a2A5328-4gmPRO
To capture images easily for this investigation, I prepared a simple camera server application as /kagra/camera/test-a2A5328-4gmPRO/test_CameraServer.py. It runs on one of camera servers (currently k1cam1) and listens various requests from CDS-workstations via the client application as /kagra/camera/test-a2A5328-4gmPRO/test_CameraClient.py. Because this server application keeps a connection to camera devices (keeping camera.Open()) same as camlan- and pylon-camera-server, this server application must be stopped before another applications connect to same camera devices. This application is now managed by the systemd in the user slice. So it can be stopped by a following command on k1cam1.
> systemctl --user stop test_CameraServer.service

Images attached to this comment
FCL (Inflastructure)
shinji.miyoki - 18:36 Saturday 28 February 2026 (36468) Print this report
Comment to SR-OMC area cleaning day2 (36467)

2 FFUS were recoverd above SRM by reconnecting power/line cables near FFUs. 1FFU above SR3 and OMMT was still off maybe because of power/signal line disconnection.

Wrapped stainless steal floors near SR2 and SRM were repaired.

Images attached to this comment
FCL (Inflastructure)
shinji.miyoki - 14:00 Saturday 28 February 2026 (36467) Print this report
SR-OMC area cleaning day2

[Miyoki]

The Fujimi-sangyou member found a huge water pool on the ceiling just above the -X side of the SRM vacuum tanks. (Maybe Hayakawa-kun also noticed well before) (Photo.1)

Although the water drain pipe was set just around this pool, there seems to be no water flow in this drain pipe, maybe because something is stuck at some point. So we tried to drain this water along some possible paths by pushing up the water pool with several T-bars. Fortunately, about 70% water could be drained out. (Photo.2) We need to fix this drain system while the amount of water is small. 

Images attached to this report
Comments to this report:
shinji.miyoki - 18:36 Saturday 28 February 2026 (36468) Print this report

2 FFUS were recoverd above SRM by reconnecting power/line cables near FFUs. 1FFU above SR3 and OMMT was still off maybe because of power/signal line disconnection.

Wrapped stainless steal floors near SR2 and SRM were repaired.

Images attached to this comment
PEM (Center)
takaaki.yokozawa - 9:27 Saturday 28 February 2026 (36466) Print this report
Comment to PEM injection test 260220 (36400)
Sorry I missed the method of the calibration using the diaggui.
Transfer function of the OMC stack (V->V) can be found in JGWDoc17204

Fig.1. showed the unit of the (m/s^2) with the transfer function of the OMC stack (V->V)
Fig.2. showed the unit of the (m/s), multiplying 1/f with the transfer function of the OMC stack (V->V)
Fig.3. showed the unit of the (m), multiplying 1/f^2 with the transfer function of the OMC stack (V->V)
Images attached to this comment
FCL (Inflastructure)
shinji.miyoki - 8:34 Saturday 28 February 2026 (36465) Print this report
SR-OMC area cleaning day1

[Hayakawa, Uchiyama, Takahashi-m, Sawada, Yamaguchi, Takahashi-r]

Fujimi-sangyo started cleaning of the SR-OMC area. 

Images attached to this report
DGS (General)
takahiro.yamamoto - 0:08 Saturday 28 February 2026 (36464) Print this report
Taking system backup of camera servers
Backup of camera servers
Camera servers were upgraded from camlan camera-server on CentOS7 to pylon-camera-server on Debian12 (klog#36182 for k1cam2 and klog#36284 for k1cam0). Although OMC_TRANS was kept on k1cam1 as camlan camera-server due to the compatibility issue between the pylon-camera-server and the implementation of OMC_LOCK guardian, it was finally solved by the update of OMC_LSC guardian (klog#36311). Now all cameras can be migrated the new system, so I took a snapshot of the current system disk of camera servers.

Frozen console issue
After taking a backup of the system disk, I noticed k1cam2 couldn't reach the login console. I though at first the system disk was broken during the backup process. But according to the console logs, grub was alive and fsck at the beginning of booting up was completed. And also, SSH login was also available. So I could check the detailed system logs and found that tty1 couldn't be refreshed due to the compatibility between on-board graphics and ATEN KVM (When I tested it in Mozumi, I used console. But I always worked via SSH after installing in the mine. So I haven't noticed it.). So I tuned the kernel parameters to restore the console. Detailed parameters will be added to the installation manual. Tuned parameters were applied also for the backup disk.

Upgrade of k1cam1
And also, k1cam1 was migrated to the pylon-camera-server system. It's just a backup resources to compensate a shortage of CPU power of k1cam0 until the hardware replacement of k1cam0 in the next FY. After k1cam1 is retired, we can make a space to move the guardian server currently located in the Mozumi building, which was a long-standing task for DGS.
DGS (General)
takahiro.yamamoto - 21:51 Friday 27 February 2026 (36463) Print this report
Comment to An update test of client workstations to Debian13 (36448)
The LIGO CDS team was kind enough to work for the rapid release of the revised version.
The new release is now available as v1.5.3.
It worked well on the Debian13 test stand as the Guardian client.
A test of the Guardian server will be also started soon.
CAL (YPcal)
Misato Onishi - 18:21 Friday 27 February 2026 (36462) Print this report
YPcal new laser test

Dan Chen, Misato Onishi

 

We conducted tests of the new laser for YPcal at University of Toyama.

An operational test was carried out, and we confirmed that the script currently used at YPcal can be applied almost without modification.

We verified the output power up to 20 W, and no issues were observed.

Regarding the noise performance, sufficiently low noise was achieved even without noise suppression by the OFS loop.

Further details are available here.

MIF (ASC)
kenta.tanaka - 16:25 Friday 27 February 2026 (36459) Print this report
Comment to High-Bandwidth ARM ASC (36452)

## What we did on 2026.02.27

We engaged the high-bandwidth ASCs for both P and Y directions. As soon as engaging ASCs, DHARD_{P,Y} started oscillated at some high-frequecies, 15-18 Hz. We tried to solve the issue by implementing a bandstop filter between 14-20 Hz. Then, the oscillations at their frequencies seems to be stoppped but sometimes 15 Hz oscillation raise up like glitch (fig.1). If the glitch was large, IFO got down. We found that IM actuator was saturated at this timing (fig.2) (When I wrote this log, I found TM was also saturated). Since we just use IM to damp the 3 Hz mode in Yaw but the feedback to IM above 3 Hz was not cut at that time, we implemented 3 Hz bandpath filter in FM2 of IM_LOCK_Y. Thanks to this, we avoid the IM actuator saturation (but TM was still saturated.) (fig.3) We succeeded in enhance the lock duration from several minites to 10-15 minites. However, lock loss itself by 15 Hz seems to be remained (maybe due to TM saturarion). So we implemented the 15 Hz notch filter for {D,C]HARD_{P,Y} instead of the bandstop filter.

Next, we found that the 2 Hz oscillation grow up 10-15 minites after ASCs were engaged (fig.4). As the 2.2 Hz oscillation was larger, L_RMS seems to get larger. At last, L_RMS surpassed the thereshold and the the IFO got down (fig.5). We found that ETMY Y still oscilllated even though ASC was already disengaged. We found only ETMY had no 2.1 Hz mode NBDAMP for some reason. So we implemented the damping control for 2.1 Hz mode in ETMY_NBDAMP_Y4 (fig.6). Then, 2.1 Hz oscillation seems to disappeared (fig.7).

After that, we measured the OLTFs of ARM DoFs, except for {D,C}SOFT_P (Sorry, I gave up to measure them last night). Fig.8, 9, 10, and 11 show the results of Yaw loops.

  • As for C{HARD, SOFT}_Y, The gain in DC seems to be smaller than the ones when only Yaw HB ASCs were engaged.
  • As for DSOFT_Y, we could not measure it well.
  • As for DHARD_Y, the large 15 Hz peak appeared in the TF from OUT to IN1. Also, the shape of the TF above 10 Hz seems to be strange. 

Fig. 11 and 12 show the results of {D,C}HARD_P.

  • In the DHARD_P OLTF (cyan line), the gain shape around 10 Hz seems to be strange. I found that I forgot to turned off the ITMX_TM_LOCK_P path. After that, we obtained the red lines. The strange shape at 10 Hz disappeared.
    • This time, I did not remeasure DHARD_Y TFs to check the effect of TM_P path, especially 10 Hz. We need to check it later.
  • As for CHARD_P, TF structures seems to be changed. During the measurement, though we excited DHARD_Y but CHARD_P was excited more (fig.13).

Totally, some large couplings in the loops remains in the loops.

Now the causes of the lockloss are categorized to 2 topics; glitches, and 1.14 Hz oscillation.

  • The glitches remains even after the above adjustement. One of the possibilites is that the control noise kickes the suspension. The DARM spectrum from 10 Hz to 100 Hz got worse whole the HB ASCs were engaged (fig.14) maybe becasue the attenuation by roll off is not enough in the MN stage. According to the cryopayload eignemode list (JGWdoc), at 15.88 Hz, there is the TM V mode. The MN_P feedback kick this? 
    • Or PR3 glitches in klog36437 was observed?
  • As for 1.1 Hz oscillation, this oscillation appeared again after the above adjustement (fig.15). 

## Next (maybe after the achievement of the RSE LSC lock acquistion.)

  • decouple sensors and actuators more precisely
  • redesign hierarichal actuator including roll off in each stage to solve the glitch and oscillation issue.
Images attached to this comment
VIS (General)
kenta.tanaka - 16:15 Friday 27 February 2026 (36461) Print this report
Comment to ITMY and ETMY cannot be SAFE state by guardian (36455)

Sorry, they were used for High-Bandwidth ASCs. I forgot to turned off them.

For now, we do not plan to use High-Bandwidth ASCs until the RSE commissioning. I'm not sure whether they are used in nominal PRFPMI lock. However PRFPMI could be locked either with or without them. So They can be turned off for now.  

VIS (SRM)
ryutaro.takahashi - 15:36 Friday 27 February 2026 (36460) Print this report
Comment to Preparation for SRM installation (36327)

I installed the signal generator box for the LVDT driver in the SRM rack (Picture #1). The amplitude of the 10kHz output was set to 7Vp-p. The cables from the SRM chamber (Picture #2) were connected to the LVDT distributor and the coil driver.

Images attached to this comment
DGS (General)
satoru.ikeda - 11:25 Friday 27 February 2026 (36458) Print this report
Update to the k1lsc Model

Ushiba-san, Yokozawa-san, Yuzurihara-san, DanChen-san, Ikeda

The task of clearing SDF differences prior to the model update was performed, but some differences remain.
These must be cleared by the responsible personnel before the power outage work begins.
I've attached some SDF captures from the real-time model connected to Dolphin.

The connections of Q and I for ReflPda1_56{Q,I} in the k1lsc model were swapped, so this has been corrected.
At present, the signals are internally terminated and not in use, so there is no impact from this correction.

[K1LSC0]
 k1lsc
  K1:ALS_PLL_LSC_REFL_PDA1_56_{Q,I}

Images attached to this report
Non-image files attached to this report
VIS (SRM)
satoru.ikeda - 11:14 Friday 27 February 2026 (36457) Print this report
Comment to Preparation for SRM installation (36327)

Ushiba-san, R.Takahashi-san, Ikeda

The VIS model file described in K-Log#36374 has been installed.

[K1SRM]
 TOWER_MASTER
 PAYLOAD_MASTER
 k1vissrmt
 k1vissrmp
  The file prior to the modification was copied to the archive/ directory (20260216).
  Since the blocks were unified(related to K-Log#18595), resulting in a change in the DAQ data volume.

  DAQ_BYTE_COUNT
  k1vissrmt: 506 -> 398
  k1vissrmp: 422 -> 469
 

Images attached to this comment
Non-image files attached to this comment
IOO (General)
Carl Blair - 10:57 Friday 27 February 2026 (36456) Print this report
IMC REFL Whiteningfixed

[Tanaka, Alex, Carl]

Yesterday we checked the IMC whitening of IMC REFL QPDA2. The board was wobbly. Pressing the board more firmly into the socket resulted in the whitening working correctly.  Photo shows the whitening board digital switch breakout in question (next to 1302082, not the in focus board).  diaggui screen live traces show all channels showing 2 stages of whitening engaged as the switch positions request (we also checked the raw inputs).  Noise level is higher than the reference traces as interferometer was in observe with 5W input while the reference traces interferometer was not locked and input with 1W.  First 3 reference traces show old no whitening state, 4th reference shows whitening at 1W.

We prepared to do jitter injections to remeasure coupling functions with the fixed QPD as witness sensors but were not able to take any measurements due to the earthquake in Russia.

Images attached to this report
VIS (General)
takaaki.yokozawa - 9:02 Friday 27 February 2026 (36455) Print this report
ITMY and ETMY cannot be SAFE state by guardian
Since the one NBDAMP filter gain became non-zero value, both ITMY and ETMY guardian cannot be SAFE state.
If this changes were permanent state, please modify the guardian.
If this changes were not permanent sate, please back to nominal state after you use.
Images attached to this report
Comments to this report:
kenta.tanaka - 16:15 Friday 27 February 2026 (36461) Print this report

Sorry, they were used for High-Bandwidth ASCs. I forgot to turned off them.

For now, we do not plan to use High-Bandwidth ASCs until the RSE commissioning. I'm not sure whether they are used in nominal PRFPMI lock. However PRFPMI could be locked either with or without them. So They can be turned off for now.  

CAL (General)
hirotaka.yuzurihara - 9:00 Friday 27 February 2026 (36454) Print this report
TCam photo session 20260227

I took the TCam photos for commissioning at 08:39 ~ 08:43 this morning. The previous work is klog and klog

  • ITMY
  • For these mirrors, I updated the reference positions. I also re-draw the yellow line shown at the k1mon4. For the other mirrors, we don't need to update the reference positions.
FCL (Clean Area)
takashi.uchiyama - 8:31 Friday 27 February 2026 (36453) Print this report
Cleaning of SRM booth
2025/02/26

Sawada, Hayakawa, Uchiyama

We started FFUs at the OMC-SR3 clean booth and the SRC air cooler at 16:45 on 26 February.
Search Help
×

Warning

×