The same enhancement happened around 01:20 UTC on September 27th. The enhancement feature, duration (~ 20 minutes) are almost the same with the recent two events.

Also ~ 5K level temporal enhancement at the 1st head of the cryocooler for the BRT side happened in EXC about 53 days ago from now.

They fortunately recovered.

According to Kimura-san, any detected errors result in the stop of the cryocooler and no automatic restart even when the error sources are recovered. The water supply system shows no errors according to the remote webcam image. So, water supply system seems to be healthy. 

In this time in IXC, the warming up time by 15K took 20 minutes. While, it took a shorter time of 15 minutes when the cryocoolers stopped because of the power outage in the EX area on October 28th. So in IXC, the cryocooler itself kept working, but lost its cooling power because of something. 

The same warm-up happened again on Sunday mid-night.

The temp change of the 1st cryocooler head was a very smooth enhancement like a natural warmup. Did a temporal stop of something happen?

[Komori, KYamamoto]

We started the frequency scan to identify IY resonant frequencies.
We found several resonant frequencies as follows:

- 15.795 kHz
- 16.1928 kHz
- 16.2536 kHz

- 21.0635 kHz
- 21.0757 kHz

[Komori, KYamamoto]

We performed the EX Q-measurement as follows:

Resonant frequency: 23.9261 kHz
Q: (2.41 ± 0.13) x 10^5

This is the final Q-measurement for EX low frequencies.

From this measurement, I began using the improved Python code for Q-measurement (/users/Commissioning/Q_meas/Qmeasfit.py).
The main difference is a reduction in the number of fitted parameters.

In the previous code, the excitation period was included in the fitting, and the moment when the ringdown starts was one of the fitted parameters.
This setup led to frequent fitting errors due to the fluctuating excited amplitude.
Therefore, I excluded the excitation period from the fitting region and removed the moment when the ringdown starts from the fitted parameters.

The results of the investigation of scattered light noise conducted on 12/08 (klog#27877) are summarized in a slide.

Please see JGWdoc.

[Komori, KYamamoto]

We measured the Q-value of an EX mechanical mode and reconfirmed the resonant frequency and Q-value of the fundamental drumhead mode.
The results, based on 10 measurements, are as follows:

- Resonant frequency: 21.07462 kHz
- Q: (1.84 ± 0.23) x 10^5

- Resonant frequency: 23.6928 kHz
- Q: (1.07 ± 0.04) x 10^5

For the time being, please use this frequency as the beacon sideband.
This frequency differs by 2.6 Hz from the previous report (klog:27634).

This discrepancy might be due to the fact that the peak of the transfer function does not precisely indicate the resonant frequency because of beating with the injection frequency.
However, the actual resonant frequency might indeed be changing, as reported in klog:27893.

Figure 1 shows the generated C code of a part of k1visetmxp before (left) and after (right) fixing the problem.

As shown in the highlight line, the input to the 16th bit of bit2word was "sum4" instead of a proper input signal. "sum4" is a summation of yaw contorl signals from ASC, ADS, and BPC. And the 16th bit is assigned to switch the coil driver input as Drive-In or Test-In for the control signal on 4-9 pin. So the model-compile script generated a very nice code which disabled the output to one coil when yaw control signal became non-zero value.

I tried to modify the conversion script from the matlab code to the C code as shown below. After this modification, real-time models were re-compiled and worked fine.

--- Bit2Word.pm.bak 2016-11-09 09:33:17.000000000 +0900
+++ Bit2Word.pm 2023-12-09 18:25:19.000000000 +0900
@@ -75,7 +75,7 @@ sub frontEndCode {
         for (0 .. $::partInCnt[$i]-2) {
            $calcExp .= "\t$::fromExp[$_],\n";
         }
-        $calcExp .= "\t$::fromExp[$partInCnt[$i]-1]\n";
+        $calcExp .= "\t$::fromExp[$::partInCnt[$i]-1]\n";
         $calcExp .= "};\n";
         $calcExp .= "\L$::xpartName[$i] = 0;\n";
         $calcExp .= "for (ii = 0; ii < $::partInCnt[$i]; ii++)\n{\n";

ETMY suddenly tripped (went to PAY_TRIPPED) at 19:46:28 JST because IM_H3 sensor detected larger RMS than the watchdog threshold as shown in Fig.1. V3 and H2 also detected similar behavior but they were much smaller than the threshold.

On the MN stage, no strange behavior was detected on local damp control signals before ETMY was tripped. Large changes in Fig.2 came from the state transition from LOCK_ACQUISITION to TRIPPED. So it shouldn't be caused by local control. I also couldn't find any coincident behavior on PEM channels around EY. The behavior detected on local sensors is so fast for a pendulum motion that it may be an electrical issue.

Because there was no strange behavior on IM local sensors after ETMY was tripped, I cleared the DACKILL and watchdogs and recovered LOCK_AQUISITION state.

 

[Yamamoto, Ushiba]

We found the exact reason why PRFPMI cannnot be locked with ASC: it is not due to CPU load but the problem in C code of the real-time model.
Somehow, ISC_Y signals send to 16th bit of BO instead of real BO signal and change the coil driver setting when VIS model obtained ISC_Y signals from ASC, BPC, and ADS models.
So, we could not use any alignment controls with ISC_Y signals including initial alignment, and please do not use ISC_Y controls until fixing the bug.

To reduce filter banks further, I deleted the following filter banks:
K1:VIS-{ITMX,ITMY,ETMX,ETMY}_TM_ADD_{L,P,Y}
Figure 1 and 2 show the part of models before and after modification.

During the work, I restarted DAQ at around 16:00.

To reduce the CPU load, I cleaned up filter baks of Type-A payload.
So, please see the archive at 2023/12/09 00:00:00 UTC, if you want to see the filters befroe the clean up.

The 1st head temp of the cryocooler for the BS side duct shield in IXC showed ~15K enhancement and recovery around the early morning today.

The vacuum level at BS seems to show no remarkable enhancement.

Temp enhancement in the BS side duct shield seemed to be within ~1K around 90K~100K.

[kTanaka, Hirose]

We checked f3 signal to go to EOM2b. We found that the f3 signal was coming to the input of the EOM with the same modulation index as f1. We noticed that the N-SNA conversion adapter was loose during the process. We would like to measure the modulation depth again in this condition.

## Detail

• The RFamp inputs for each of f1, f2, and f3 were measured with Moku-lab's Spearna. 
  The RFamp input for each of f1, f2, and f3 was about 6 dBm. This was after lowering the attennator -2dBm from the multiplier's output of 13dBm, so it is lower than that.
  We then measured the RFamp output of f3 and it was about 6 dBm.
  Fig1: Noise level before measurement.
  Fig2: The blue and red results are for f1 and f3. There are the same 6 dBm peaks at f1 (about 16.8 MHz) and f3 (56.8 MHz), respectively.
  Fig3: The red result is for f2. The bule result is the output of the f3 RFamp.
   
• The input for f1 and f3 of EOM2b was about 13 dBm. It indicates that the f3 signal is coming to the input of the EOM with the same modulation index as f1. (However, the RFamp output results are just different, so it is strange.)
  During the previous modulation depth measurement, the f3 signal was not visible. During the course of this measurement, we noticed that the N-SNA conversion adapter (attached between the output of the f3 RFamp and the SMA cable) was loosened. Since we could not take measurements to compare before and after tightening the adapter, we cannot determine why we could not see the f3 modulation depth. Now we found that the f3 signal is coming to the input of the EOM2b through this work, so we would like to measure the modulation depth again.
  Fig4,Fig5 : The photo around EOM2a and EOM2b. The current situation is that light does not pass through EOM2a, but light does pass through EOM2b.
  Fig6: Noise level before measurement.
  Fig7: The red and blue results are for f1 and f3. 

## Process

This time we checked the RFamp input and output, taking care not to unplug the cable while the signal was going from Seed's function generator. We summarized for future use.

1. Turn off "RF output" on the seed function generator.
   --->> The seed function generator was in remote mode, but we switched to local mode using a dedicated web page. we could not find out how to switch back to remote mode, so it is still in local mode.
2. Turn off the DC power to the multiplier.
3. Turn off DC power to the RFamps(f1, f2, 2f2, f3 in the IOO rack, f1, f2 in the ALS1 rack, f1, f2 in the LSC rack, f1 rack in the OMC rack) connected from the multiplier.
   -->> If we want to see the output of a circuit, we should turn off the power to that circuit, but RFamp can be corrupted by glitches, so we have included this step.
4. Connect the spare to the signal to be acquired using an SMA cable.
5. Turn on DC power to the RFamps.
6. Turn on the DC power to the multiplier.
7. Turn on "RF output" on the seed function generator.

Maybe due to the real-time model update (klog27894), CPU over load occured when we engaged {D,C}HARD_Y loops and PRFPMI lost lock.
Now, we cannot reach PRFPMI_RF_LOCKED state, so please do not request PRFPMI_RF_LOCKED state to LSC_LOCK guardian until the issue will be solved.
I will try to fix the issue but If you want to use IFO before that, please use PRFPMI_TRANSITION_TO_1FSIG state.

We tried measuring the Q-value of a mode that we couldn't measure previously, and we succeeded in doing so for one mode.
This records the highest mirror Q-value ever in KAGRA.

Resonant frequency: 23.92353 kHz
Q: 4.3x10^6 and 4.0x10^6

We made 5 attempts, but the interferometer was down for the last 3 measurements, so we only succeeded in the first 2 attempts.

Interestingly, the resonant frequency differed by 0.14 Hz compared to that of yesterday, while the mirror temperature remained almost the same (0.02 K defference).
Particularly from the viewpoint of the beacon frequency, we should keep this in mind.

We finished the Q-measurement of IX mechanical modes below 30 kHz.

Ushiba-san, ikeda

Glitch was caused by a change in K-Log#27894.

Therefore, some filter banks of Type-A were deleted.
Deleted: 
 K1:VIS-{ETMX,ETMY,ITMX,ITMY}_IM_OPTICALIGN
 K1:VIS-{ETMX,ETMY,ITMX,ITMY}_IM_PSD
 K1:VIS-{ETMX,ETMY,ITMX,ITMY}_TM_OPTICALIGN
 

I removed the GigE camnera at the PR2 and used another camera ASI294MC which is being used as Tcam and has a good sensitivity for IR.

I could see the IR spot. The white area in Fig.1 circled by Magenta lines comes from IR light since RGB has the same response above IR wavelength. Today, all the suspensions are in safe mode, so the IR spot was hitting somewhere from the center of the mirror.

The purpose of this new camera is to see the scattering IR light clipped by baffles or something during lock. In this meaning, This camera meets the requirements.

I saw a lot of red light from Oplev, but I did not see green light coming from the green laser. Even direct watching by my eye, I saw only red light and I did not see the green light at all.

The focal length of this lens was a bit too long, so the area we can see is a bit small. Comparing Fig.2 and Fig.3 can help to identify where it is. Both are exactly the same angle.

Today's camera and lens are just a test version, I need to prepare another filter or shorter focal length lens. I will order a proper camera and lens and some adapters. I put the GigE camera back today. When the new camera is ready, I will install it.

[Yamaguchi, Nakagaki]

We installed Wi-Fi access points in the Xend and Yend machine rooms.

The SSIDs are

  EX-MachineRoom and

  EY-MachineRoom.

We have identified additional resonant frequencies for ETMX through differential excitation as follows:

• 23.9262 kHz
• 24.253 kHz
• 24.780 kHz

We could not detect mechanical modes around 27 kHz.

We have completed the scanning for EX low resonances.

kTanaka-san, ikeda

Continuing from last week, we installed PMC pico motor cables in the PSL room.
From the PSL room mesh shelves to the back side of the PSL room.

It is not yet connected to a motor driver.
It will be connected at the next PMC mount replacement work.

start time: 2023/12/08 10:34:50(JST), 1386034508
End Time: 2023/12/08 11:12:03(JST), 1386036741