Reports of 33836
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
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.
MIF (ASC)
kenta.tanaka - 3:54 Friday 27 February 2026 (36452) Print this report
High-Bandwidth ARM ASC

Komori, Dan, Tanaka

Finally, we succeeded in closing the High-Bandwidth ASC loops for ARM DoFs in both P and Y directions. On the other hands, We found some issues in HB ASCs which are the causes of lock loss. The detail will be posted tomorrow.  

Comments to this report:
kenta.tanaka - 16:25 Friday 27 February 2026 (36459) Print this report

## 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
MIF (General)
yuta.michimura - 2:48 Friday 27 February 2026 (36451) Print this report
Comment to Interferometer loss investigations (36231)

Now that we have calibrated POP90 into PRG for f2 (klog #36340), and have updated finesse results (klog #36297), I redid the estimate of the losses in the IFO.

The loss in PRC probed by f2 has increased from ~10% in March 2025 to ~25% in November 2025.
(These numbers do not incude the losses from f2 detuing in PRC and Schnupp asymmetry mismatch to f2.)
Assuming that loss in PRC probed by carrier is smaller by a factor of ~6 (consistent with measured Lawrence effect klog #36283), round-trip loss in the arm cavity has increased from ~80 ppm to ~100 ppm during O4abc.
The drop in the finesse during cryogenic operation is mostly due to ITM transmission increase.

Method:
 - Assume PRM transmission T_PRM is constant.
 - As described previously (klog #36233), T_RTL*4/T_ITM+T_PRCc can be estimated from normalized arm cavity transmission. T_PRCs can be estimated from the power recycling gain for f2, as measured by POP90. Here, T_RTL is arm cavity round-trip loss (including ETM transmission), T_ITM is ITM transmission, and T_PRCc and T_PRCs are PRC loss for carrier and sideband, respectively.
 - First, POP90 sqrt(I^2+Q^2)/Pin was multiplied by 1.88(9) (see klog #36340) to get f2 PRG (bottom left, blue dots). The value was corrected into non-detuned value by multiplying the PRG with (1+(det/HWHMprc)**2). From the corrected PRG value, T_PRCs=1-rloss**2 can be estiated because PRG = tp/(1-rp*rmi*rloss). Note that rmi**2=0.97445(15), so the loss from Schnupp asymmetry mismatch is ~3% and is non-negligible. See bottom right, yellow dots for the estimated T_PRCs. As a sanity check, the estimated value is consistent with recent measurements (klog #36340).
 - T_PRCc cannot be measured independently from arm cavity transmission. Assuming that the PRC losses are mainly from birefringence, T_PRCc can be guessed from T_PRCs. Assuming T_PRCc = T_PRCs / 6(2), T_RTL*4/T_ITM can be estimated from normalized arm cavity transmission (bottom right, cyan and megenta).
 - Finesse measurements (top right) gives you 2*pi/(T_RTL+T_ITM), so by combining the two, T_RTL and T_ITM can be estimated (middle right).
 - The assumed ratio T_PRCs/T_PRCc=6(2) comes from the amount of reduction in p-pol observed for ITM single bounce and arm locked (klog #36283). This might not be true if the loss is not dominated by birefringence. But this ratio gives the estimated T_RTL in March 2025 consistent with the measured T_RTL in August 2024 (klog #30823), so it seems not to far from what's happening.

Discussion:
 - We have time-varying T_ITM, T_RTL, T_PRCc, T_PRCs. But we measure only have arm cavity transmission, POP90 and occasional finesse measurements. If we can also occasionally measure T_RTL with the method described in klog #36283, we can estimate the 4 parameters independently. We should have measured T_RTL at least once at cryogenic temperatures.
 - The reason why the loss in PRC probed by f2 has increased from ~10% to ~25% is unclear. Increase by ~15% is not seen by carrier, so it is not a simple loss common to f2 and carrrier. It could be due to increased birefringence at cryogenic temperatures or birefringence in ice layers?
 - Updated finesse values (klog #36297) seems to be lower by ~50.

Next:
 - Make a script to measure arm cavity round-trip loss occasionally
 - Check if the rate of ITM transmission change is consistent with ice layer formation

Images attached to this comment
DGS (General)
takahiro.yamamoto - 18:37 Thursday 26 February 2026 (36448) Print this report
An update test of client workstations to Debian13
Alternative softwares for deprecated ones were reported in 35128.
Script updates of a compatibility improvement for these alternative softwares were done in klog#35113.

In this time, many CDS tools were tested because they became available as Debian13 packages.
I found no issues on major tools such as ndscope, dtt, and so on. Only guardian still needs a new release to fix an compatibility issue (#96). The compatibility fix itself was already merged to origin/master (!13). So I made a patch file and apply it, then guardctrl works fine as a Guardian client. For the easy deployment, it's better to wait a new release of guardian. But the new workstation can be used for daily works.

In addition, matlab compatibility issue was newly found.
Apparently, MATLAB 2022a or earlier versions do not work on Debian 13 (#724). It seems to come from the version difference of libc. This issue was resolved in LIGO for 2019a by setting the environment variable GLIBC_TUNABLES=glibc.rtld.execstack=2. Though I tried to do same thing for 2016b which is still used as a real-time model editor in KAGRA and is compatible with rcg-3.1.1, it didn't allow to use 2016b on Debian13. Matlab 2016b itself can be launched by setting GLIBC_TUNABLES=glibc.rtld.execstack=2, but the simulink browser crashed when the model files are opened. So as an another solution, I tried to launch 2016b in the Docker container based on the Debian12 image and finally, it works well. These Docker compose files are stored in /users/DGS/docker. And also, we can launch it by 'matlab' command by the wrapper function defined in /kagra/apps/etc/client-user-env_deb13.sh. So users doesn't need to consider this differences. Of course, the ultimate goal is to migrate to the new versions of RCG and MATLAB and the 2nd best is to consider the compatibility improvement between RCG-3.1.1 and the new version of MATLAB. But using Docker gives a time to consider and upgrade them.
Comments to this report:
takahiro.yamamoto - 21:51 Friday 27 February 2026 (36463) Print this report
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.
VIS (SRM)
ryutaro.takahashi - 17:57 Thursday 26 February 2026 (36450) Print this report
Comment to Preparation for SRM installation (36327)

I started the reassembly of the broken FLDACCs. #4 folded pendulum block was replaced with #7 block (Picture #1), which was transported with the special box (Picture #2) from NAOJ (Mitka). The assembled pendulum looks fine (Picture #3). The FLDACCs for SRM moved to the BS area temporarily to prevent troubles due to the cleaning of the SR-OMC booth (Picture #4).

I installed the poles to cover the table to store the MSBs removed from the SRM chamber (Picture #5).

 

Images attached to this comment
VIS (PR3)
dan.chen - 16:35 Thursday 26 February 2026 (36449) Print this report
Comment to Investigation of Large PR3 Motion Observed (36437)

[Kenta Tanaka, Dan Chen]

Follow-up Investigation of PR3 Glitches (2026/02/26)

Following the previous report on intermittent large motion of PR3, we performed an additional investigation today during a period when the interferometer was unavailable due to an earthquake.

Summary

  • We investigated the PR3 glitches, but the root cause has not been identified.
  • We suspected possible origins related to the oplev sensors and/or the oplev laser source; however, we found no evidence supporting these hypotheses.

Time-Series Observation

From the time-series data, the glitches appear to be correlated between the TM P and Y directions.

PR3 TM P and Y glitch correlation (overview)

In the figure below, the red circles indicate periods where glitches are present, while the blue circles indicate quieter periods.

PR3 TM P and Y glitch correlation (annotated)

Oplev QPD Signals

We examined the QPD segment signals:

PR3 TM oplev QPD segment signals

The glitches are visible in all four QPD segments and appear consistent across them. No abnormal behavior is observed in any single segment. Since the glitches do not appear in the SUM signal, they are unlikely to originate from the oplev laser source.

Spectral Comparison (PAY_FLOAT)

We compared the spectrum in PAY_FLOAT with data taken during a previously quiet period(2024/11/28):

PR3 spectrum comparison (PAY_FLOAT)

  • No significant spectral differences were observed compared to the earlier quiet dataset.
  • Although the previous dataset appears to have had the loop manually closed, the high-frequency region should still be comparable.
  • Note: during the present measurement the system was in PAY_FLOAT, so it is unclear whether glitches were actively occurring at that time.

Current Status

Despite these investigations, no clear cause of the PR3 glitches has been identified. The spectral shape is largely unchanged compared to the earlier quiet period, and the QPD behavior does not indicate a sensor- or laser-origin issue.

Images attached to this comment
PEM (EY)
takaaki.yokozawa - 9:26 Thursday 26 February 2026 (36447) Print this report
Comment to PEM injection test 260225 (36444)
I performed the 80 - 220 Hz injection again (relatively silent below 100 Hz)
09:24:00 - 09:25:30
Images attached to this comment
PEM (EY)
takaaki.yokozawa - 8:32 Thursday 26 February 2026 (36446) Print this report
Comment to PEM injection test 260225 (36444)
I performed the injection test at PSL room on the PMC.

Shaker : K1:PEM-EXCITATION_MCF0_RACK_11_EXC
ACC : K1:PEM-ACC_PSL_PORTABLE_1_OUT_DQ

07:20:00 - 07:40:00
Sweep injection 900 - 1 Hz, 600 s, 10 cnt, 2 times measurement

07:41:00 - 07:46:00
white injection 80 - 220 Hz, 500 cnt
Fig.1. showed the result

07:46:00 - 07:51:00
white injection 180 - 320 Hz, 500 cnt
Fig.2. showed the result

07:51:00 - 07:56:00
white injection 280 - 420 Hz, 500 cnt
Fig.3. showed the result

07:56:00 - 08:01:00
white injection 380 - 520 Hz, 500 cnt
Fig.4. showed the result

08:01:00 - 08:06:00
white injection 480 - 620 Hz, 500 cnt
Fig.5. showed the result

08:06:00 - 08:11:00
white injection 580 - 720 Hz, 500 cnt
Fig.6. showed the result

08:11:00 - 08:16:00
white injection 680 - 820 Hz, 500 cnt
Fig.7. showed the result

08:16:00 - 08:21:00
white injection 780 - 920 Hz, 500 cnt
Fig.8. showed the result
Images attached to this comment
PEM (Center)
takaaki.yokozawa - 7:28 Thursday 26 February 2026 (36445) Print this report
Installed the shaker and portable accelerometer on the PMC
[Tanaka, Yokozawa]

Discussion with Tanaka-san, we installed the shaker and portable accelerometer on the PMC (output side)

Shaker : K1:PEM-EXCITATION_MCF0_RACK_11_EXC
ACC : K1:PEM-ACC_PSL_PORTABLE_1_OUT_DQ
Images attached to this report
PEM (EY)
takaaki.yokozawa - 7:14 Thursday 26 February 2026 (36444) Print this report
PEM injection test 260225
I performed the PEM injection test, TMSY viewport with white injection test.

I put the accelerometer on the shaker, but (may be dropped) no response of the accelerometer
K1:PEM-PORTABLE_TMSY_BOOTH_TMS_BNC3_OUT
So as a reference, I used the accelerometer on the TMSY optica table
K1:PEM-ACc_TMSY_TABLE_TMS_Z_OUT_DQ

- 05:40:00 Silent run

06:13:00 - 06:18:00
white injection 80 - 220 Hz, 1000 cnt
Fig.1. showed the result
No significant excess in spectrum

06:18:00 - 06:23:00
white injection 180 - 320 Hz, 1000 cnt
Fig.2. showed the result
very small excess in 250 an 280 Hz?

06:23:00 - 06:28:00
white injection 280 - 420 Hz, 1000 cnt
Fig.3. showed the result
No significant excess in spectrum

06:28:00 - 06:33:00
white injection 380 - 520 Hz, 1000 cnt
Fig.4. showed the result
very small excess in 380 an 465 Hz?

06:33:00 - 06:38:00
white injection 480 - 620 Hz, 1000 cnt
Fig.5. showed the result
No significant excess in spectrum

06:38:00 - 06:40:00
white injection 580 - 720 Hz, 1000 cnt
Fig.6. showed the result
No significant excess in spectrum
During this measurement locked loss happened

Images attached to this report
Comments to this report:
takaaki.yokozawa - 8:32 Thursday 26 February 2026 (36446) Print this report
I performed the injection test at PSL room on the PMC.

Shaker : K1:PEM-EXCITATION_MCF0_RACK_11_EXC
ACC : K1:PEM-ACC_PSL_PORTABLE_1_OUT_DQ

07:20:00 - 07:40:00
Sweep injection 900 - 1 Hz, 600 s, 10 cnt, 2 times measurement

07:41:00 - 07:46:00
white injection 80 - 220 Hz, 500 cnt
Fig.1. showed the result

07:46:00 - 07:51:00
white injection 180 - 320 Hz, 500 cnt
Fig.2. showed the result

07:51:00 - 07:56:00
white injection 280 - 420 Hz, 500 cnt
Fig.3. showed the result

07:56:00 - 08:01:00
white injection 380 - 520 Hz, 500 cnt
Fig.4. showed the result

08:01:00 - 08:06:00
white injection 480 - 620 Hz, 500 cnt
Fig.5. showed the result

08:06:00 - 08:11:00
white injection 580 - 720 Hz, 500 cnt
Fig.6. showed the result

08:11:00 - 08:16:00
white injection 680 - 820 Hz, 500 cnt
Fig.7. showed the result

08:16:00 - 08:21:00
white injection 780 - 920 Hz, 500 cnt
Fig.8. showed the result
Images attached to this comment
takaaki.yokozawa - 9:26 Thursday 26 February 2026 (36447) Print this report
I performed the 80 - 220 Hz injection again (relatively silent below 100 Hz)
09:24:00 - 09:25:30
Images attached to this comment
VIS (PR3)
kenta.tanaka - 0:52 Thursday 26 February 2026 (36443) Print this report
Comment to Investigation of Large PR3 Motion Observed (36437)

Fig.1 shows the time series of the oplev signals in the optical path from IMMT2 to X-arm when PR3 was glitchy. Glitch size seems to be 1.9 urad in P, 0.97 urad in Y, respectively. These sizes are much larger than the usual RMS.

Even though the glitch was occuring, HANDOVER from ALS to IR seems to be fine (but not easy). However, the fluctuation of POP90 was terrible. Fig.2 show the timeseries including to POP90, PRC and MICH error/feedback. Between the cursors, there seems to be no glitch in PR3 oplev. in the out of this region, POP90 dropped to the less than half of the maxlmun.

Images attached to this comment
Search Help
×

Warning

×