Reports of 25660
CAL (YPcal)
Shingo Fujii - 17:02 Sunday 10 December 2023 (27917) Print this report
Comment to Modifications in PCAL Model and Guardian (27790)
12/10

I added some STATE to inject PCAL line and verified that the STATE works correctly.
While not yet a finished version of GUARDIAN (Decorator etc.), it is at least ready to be adapted for Xpcal.
CRY (Cryostat IX)
shinji.miyoki - 16:21 Sunday 10 December 2023 (27918) Print this report
Comment to One od Cryocooler 50K Head showed strange temp enhencement (27720)

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.

Images attached to this comment
CRY (Cryostat IX)
shinji.miyoki - 9:23 Sunday 10 December 2023 (27916) Print this report
Comment to One od Cryocooler 50K Head showed strange temp enhencement (27720)

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. 

CRY (Cryostat IX)
shinji.miyoki - 7:29 Sunday 10 December 2023 (27915) Print this report
Comment to One od Cryocooler 50K Head showed strange temp enhencement (27720)

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?

Images attached to this comment
MIR (IY)
kentaro.komori - 1:23 Sunday 10 December 2023 (27914) Print this report
IY resonant frequencies search

[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

Images attached to this report
MIR (EX)
kentaro.komori - 23:37 Saturday 09 December 2023 (27913) Print this report
EX Q-measurement at 23.9 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.

Images attached to this report
Non-image files attached to this report
MIR (EX)
kentaro.komori - 23:24 Saturday 09 December 2023 (27912) Print this report
Comment to EX Q-measurement (27902)

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.

DetChar (General)
Shunsei Yamamura - 23:17 Saturday 09 December 2023 (27911) Print this report
Summary of results of scattered light noise investigation

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

Please see JGWdoc.

MIR (EX)
kentaro.komori - 22:49 Saturday 09 December 2023 (27902) Print this report
EX Q-measurement

[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.

Images attached to this report
Non-image files attached to this report
Comments to this report:
kentaro.komori - 23:24 Saturday 09 December 2023 (27912) Print this report

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.

MIF (General)
takahiro.yamamoto - 21:18 Saturday 09 December 2023 (27909) Print this report
Comment to PRFPMI cannot be locked due to CPU load (27901)

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";

Images attached to this comment
DGS (General)
takahiro.yamamoto - 20:51 Saturday 09 December 2023 (27907) Print this report
bug fixed in GigE server code
When I tried to change the config files for GigE, the config-reload button on the MEDM screen didn't work.
Because it's caused by a bug in the camera server code, I fixed it.
In order to apply this change for each camera, each camera service must be restarted once. But I haven't done it.

-----
When ones push the config-reload button, camera_server.py looks at K1:CAM-***_CONFIG_FILE. But it wasn't defined in camera_pcas.py. So the reload process was always failure. After adding a channel definition of K1:CAM-***_CONFIG_FILE in camera_pcas.py, the reload process works fine.
VIS (EY)
takahiro.yamamoto - 20:34 Saturday 09 December 2023 (27910) Print this report
ETMY suddenly tripped due to IM_H3

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.

 

Images attached to this report
MIF (General)
takafumi.ushiba - 18:26 Saturday 09 December 2023 (27908) Print this report
Comment to PRFPMI cannot be locked due to CPU load (27901)

[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.

VIS (General)
takafumi.ushiba - 16:00 Saturday 09 December 2023 (27906) Print this report
Comment to Model file update (27311)

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.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 15:16 Saturday 09 December 2023 (27905) Print this report
Power supply replacement for ALS0
[Kamiizumi, Tomura, YamaT]

We replaced the power supply board for the IO chassis in ALS0 rack.
Remaining IO chassis driven with AC source are IOO0, IOO1, EX0, and EY0.

-----
In this rack, DC24V is used for both IO chassis and some analogue circuits. Now digital 24V and analog 24V are separated each other for ALS0 rack. But there is no enough power supply units for doing same things for IOO0 and IOO1. So we need to stop IOO0, IOO1, ALS0, ALS1 at the same time and re-arrange the power distribution in order to remove AC equipment from all IOO0, IOO1, ALS0, and ALS1. This is a next (too heavy) task for reducing AC equipment around REFL. (On the other hand, we have lots of AC instruments e.g. function generators around REFL. So there may be no improvement from the view point of noise by changing from AC to DC only for IO chassis.)
VIS (General)
takafumi.ushiba - 14:27 Saturday 09 December 2023 (27904) Print this report
Clean up Type-A payload filter banks

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.

CRY (Cryostat IX)
shinji.miyoki - 11:00 Saturday 09 December 2023 (27903) Print this report
Comment to One od Cryocooler 50K Head showed strange temp enhencement (27720)

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.

Images attached to this comment
MIF (General)
hirose.chiaki - 22:41 Friday 08 December 2023 (27900) Print this report
Checked f3 signal to go to EOM2b from the multiplier.

[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.
Images attached to this report
MIF (General)
takafumi.ushiba - 22:27 Friday 08 December 2023 (27901) Print this report
PRFPMI cannot be locked due to CPU load

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.

Comments to this report:
takafumi.ushiba - 18:26 Saturday 09 December 2023 (27908) Print this report

[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.

takahiro.yamamoto - 21:18 Saturday 09 December 2023 (27909) Print this report

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";

Images attached to this comment
MIR (IX)
kentaro.komori - 18:23 Friday 08 December 2023 (27893) Print this report
IX records the highest mirror Q~4e6

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.

Images attached to this report
Non-image files attached to this report
VIS (General)
satoru.ikeda - 17:54 Friday 08 December 2023 (27899) Print this report
Comment to Model file update (27311)

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
 

Images attached to this comment
Non-image files attached to this comment
MIF (General)
osamu.miyakawa - 17:11 Friday 08 December 2023 (27898) Print this report
Comment to PR2 image throgh baffle hole from PR3 vacuum tank -X side. (27860)

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.

Images attached to this comment
FCL (Network)
koji.nakagaki - 16:53 Friday 08 December 2023 (27897) Print this report
Installation of Wi-Fi access points in machine rooms at Xend and Yend

[Yamaguchi, Nakagaki]

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

The SSIDs are

  EX-MachineRoom and

  EY-MachineRoom.

Images attached to this report
MIR (EX)
kentaro.komori - 16:32 Friday 08 December 2023 (27896) Print this report
EX scan from 24 kHz to 27 kHz

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.

Images attached to this report
IOO (Laser Bench)
satoru.ikeda - 16:07 Friday 08 December 2023 (27895) Print this report
Comment to PSL pico motor installation (26965)

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

Images attached to this comment
Non-image files attached to this comment
Search Help
×

Warning

×