I accepted the following differences of SDFs (see related klog34517, klog34518, and klog34519). SDF #25-27 were reverted because of misoperation.
[Takahashi, Ikeda]
I offloaded the F1 GAS with the FR. The stepper motor initially did not work due to a network switch problem, which was recovered at the site by Ikeda-san.
I offloaded the SF GAS with the FR, which reached the maximum limit (1360000 steps).
I offloaded the F0 GAS with the FR.
We exchanged k1tw0 SSD for the new one.
The data recorded on the previous SSD is currently being copied to the NFS server.
The data from the last six months is being temporarily loaded from an external disk. We plan to switch to a NAS storage space next week.
K1:CAL-MEAS_{CURRENT, LATEST}
I took the TCam photos for four mirrors at 9:30 ~ 9:37 this morning. The previous work is klog34453.
- ETMY
- 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.
CALEX, CALEY
K1:CAL-PCAL_{EX,EY}_TCAM_{MAIN,PATH1,PATH2}_{X,Y}
A CAL Tcam session was performed to obtain beam position information necessary for Pcal. The parameters have already been updated, and SDF is expected to be accepted.
Operator: Dan Chen, Shingo Hido
Update Time: 2025/07/11 09:16:29
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EX_TCAM_PATH1_X | 3.46849 mm | 3.20691 mm | -0.26158 mm |
| K1:CAL-PCAL_EX_TCAM_PATH1_Y | 62.58533 mm | 62.78539 mm | +0.20006 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_X | 0.06867 mm | -0.21958 mm | -0.28825 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_Y | -63.66836 mm | -63.36743 mm | +0.30093 mm |
Update Time: 2025/07/11 09:17:49
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EX_TCAM_MAIN_X | 3.73403 mm | 3.62390 mm | -0.11014 mm |
| K1:CAL-PCAL_EX_TCAM_MAIN_Y | 12.20820 mm | 11.89945 mm | -0.30875 mm |
Update Time: 2025/07/11 09:18:10
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EY_TCAM_PATH1_X | 0.92272 mm | 1.27965 mm | +0.35693 mm |
| K1:CAL-PCAL_EY_TCAM_PATH1_Y | 63.96127 mm | 63.48267 mm | -0.47860 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_X | -0.71031 mm | -0.34771 mm | +0.36260 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_Y | -70.49072 mm | -71.06132 mm | -0.57060 mm |
Update Time: 2025/07/11 09:18:46
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EY_TCAM_MAIN_X | 6.31424 mm | 8.78471 mm | +2.47048 mm |
| K1:CAL-PCAL_EY_TCAM_MAIN_Y | -3.21271 mm | -3.91830 mm | -0.70559 mm |
After this long lock, the BNS range seems to be sometimes degraded during locking. It is better to check the IFO conditions, especially those related to ASC and/or signal saturation. Some excess noise was visible around 60 Hz to 100 Hz.
Because of a small number of earthquakes, over 18 hours of continuous locking was realized.
However, the lock loss seemed not to be related to seismic noise shock.
After this long lock, the BNS range seems to be sometimes degraded during locking. It is better to check the IFO conditions, especially those related to ASC and/or signal saturation. Some excess noise was visible around 60 Hz to 100 Hz.
Because such phenomenon can be flagged as overflow segments, I checked them to see the overflow rate by this issue.
Overflows by these glitches were occurred in 28 times after starting observing run as below. Because overflow segments themselves contains the overflow due to the lockloss and during the lock acquisition, I picked up overflows only during science-mode by taking logical AND with the science mode.
Then, I tried to make some plot and found 1-second long time offset in the segment. Attached figures shows the DCPD signals and T-cursors represent overflow segment. In both cases, an overflow in 1-second before the start time of overflow segments is missed and there is no overflow in the last 1-second of the segments. So it suggests that served overflow segments has 1-second offset from the correct time. It might be better to reproduce the overflow segments.
-----
overflow list
1 1433745982 5 2025-06-12 06:46:04.000000 UTC
2 1433745990 3 2025-06-12 06:46:12.000000 UTC
3 1433851377 2 2025-06-13 12:02:39.000000 UTC
4 1433977698 2 2025-06-14 23:08:00.000000 UTC
5 1433989731 2 2025-06-15 02:28:33.000000 UTC
6 1433989734 2 2025-06-15 02:28:36.000000 UTC
7 1433992139 2 2025-06-15 03:08:41.000000 UTC
8 1433994501 2 2025-06-15 03:48:03.000000 UTC
9 1434030010 2 2025-06-15 13:39:52.000000 UTC
10 1434451083 2 2025-06-20 10:37:45.000000 UTC
11 1434457706 3 2025-06-20 12:28:08.000000 UTC
12 1435119032 7 2025-06-28 04:10:14.000000 UTC
13 1435403687 2 2025-07-01 11:14:29.000000 UTC
14 1435415639 3 2025-07-01 14:33:41.000000 UTC
15 1435443337 5 2025-07-01 22:15:19.000000 UTC
16 1435457242 8 2025-07-02 02:07:04.000000 UTC
17 1435457251 2 2025-07-02 02:07:13.000000 UTC
18 1435542275 7 2025-07-03 01:44:17.000000 UTC
19 1435545969 2 2025-07-03 02:45:51.000000 UTC
20 1435711455 7 2025-07-05 00:43:57.000000 UTC
21 1435801782 2 2025-07-06 01:49:24.000000 UTC
22 1435846619 5 2025-07-06 14:16:41.000000 UTC
23 1435846625 4 2025-07-06 14:16:47.000000 UTC
24 1435848511 2 2025-07-06 14:48:13.000000 UTC
25 1435984572 2 2025-07-08 04:35:54.000000 UTC
26 1435987016 3 2025-07-08 05:16:38.000000 UTC
27 1435989032 5 2025-07-08 05:50:14.000000 UTC
28 1436122577 2 2025-07-09 18:55:59.000000 UTC
I measured the coherence between DARM and IMC ASC signals with 128 average during the stable run today (fig1).
Some large coherence can be seen in IMC WFS signals and DARM.
To evaluate the noise comes from beam jitter, noise projection with IMC WFS might be helpful.
Modified time is 2025-07-10 14:50:13 JST and it's reported on #observation@slack at 15:01.
$ ls -l --full-time /opt/rtcds/kamioka/k1/chans/K1OMC.txt
-rw-r--r-- 1 controls 92841 2025-07-10 14:50:13.000000000 +0900 /opt/rtcds/kamioka/k1/chans/K1OMC.txt
$ stat /opt/rtcds/kamioka/k1/chans/K1OMC.txt
File: /opt/rtcds/kamioka/k1/chans/K1OMC.txt
Size: 92841 Blocks: 192 IO Block: 1048576 regular file
Device: 0,46 Inode: 47710247 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1001/controls) Gid: ( 1001/controls)
Access: 2025-07-10 14:50:16.000000000 +0900
Modify: 2025-07-10 14:50:13.000000000 +0900
Change: 2025-07-10 14:50:13.000000000 +0900
Birth: -
No change in filter modules was found on current foton filter from daily overwritten full backup at 2025-07-10 0:05 JST and from weekly differential backup at 2025-07-04 1:05 JST according to the diff command as follows.
$ diff /opt/rtcds/kamioka/k1/chans/K1OMC.txt /mnt/backup/rtcds/kamioka/k1/chans/K1OMC.txt
$ diff /opt/rtcds/kamioka/k1/chans/K1OMC.txt /mnt/diff_backup/opt-20250704/rtcds/kamioka/k1/chans/K1OMC.txt
There was no backup at corresponding time by There was no backup at corresponding time by foton GUI if modification was done on foton GUI. So this modification might be done on some kind of scripts, editors, etc. foton GUI makes a back up as foton file at the time of saving modification with a suffix of that time. If the modification in this time was done on foton GUI, there should be a backup file that timestam is around 7/10 14:50. But the latest backup file by foton GUI is on 6/27.
$ ls -lt --full-time /opt/rtcds/kamioka/k1/chans/filter_archive/k1omc/* | head -3
-rw-r--r-- 1 controls 92841 2025-06-27 09:36:42.000000000 +0900 /opt/rtcds/kamioka/k1/chans/filter_archive/k1omc/K1OMC_1435019820.txt
-rw-r--r-- 1 controls 92850 2025-06-27 09:36:41.000000000 +0900 /opt/rtcds/kamioka/k1/chans/filter_archive/k1omc/K1OMC_1435019819.txt
-rw-r--r-- 1 controls 92859 2025-06-27 09:36:35.000000000 +0900 /opt/rtcds/kamioka/k1/chans/filter_archive/k1omc/K1OMC_1435019813.txt
I'm not sure the behavior of foton GUI when we press SAVE without any modification. So I cannot conclude this modification was done NOT on foton GUI.
Because of no change in filter modules,
- there is no impact for current calibration.
- CFC bit of k1omc wasn't raised.
- CFC_LATCH wasn't also raised by CAL_PROC guardian.
- IFO guardian was able to keep staying in OBSERVING.
As reported in klog34442, there is a coincidence between glitches in OMC DC PD and sensitivity degradation.
So, I tried to systematically understand the kick of the suspension and sensitivity degradation.
As shown in Fig. 1, when glitches are very large, the OMC DC PD signals can become saturated.
In this case, the calibrated DARM signal is no longer reliable, so it should be excluded from the data analysis.
In other cases, the amplitude of each glitch is different, so I categorized them into four groups based on the maximum signal in each glitch: more than 25,000 counts (#1), between 20,000 and 25,000 counts (#2), between 15,000 and 20,000 counts (#3), and less than 15,000 counts (#4).
Figures 2-5 show the Q-transform around the glitch categorized as #1, #2, #3, and #4, respectively.
Even in category #4, some excess can be seen around 60–90 Hz.
So, it would be nice to evaluate the non-lnear effect in DARM sensitivity.
Figure 6 shows the comparison of the spectra when glitches happened (as a reference, spectrum without glitches are also shown with black lines).
Shift time: 9-17 (JST)
Check Items:
VAC: No issues were found.
CRY cooler: No issues were found.
Compressor: No issues were found.
IFO state (JST):
09:00 The shift was started. The status was OBSERVING.
17:00 This shift was finished. The status was OBSERVING.
The glitch from 60 to 90 Hz has coincidences with LSC-POP_PDA1_RF45_I_ERR.
The glitch around 40Hz had coincidences with LSC-AS_PDA1_RF17_Q_ERR.
The glitch from 300 to 400 Hz has coincidences with ASC-REFL_QPDA1_RF17_I_PIT, ASC-REFL_QPDA1_RF45_I_PIT, ASC-CHARD_P.
The glitch from 60 to 90 Hz has coincidences with LSC-POP_PDA1_RF45_I_ERR.
The glitch around 40Hz had coincidences with LSC-AS_PDA1_RF17_Q_ERR.
The glitch from 300 to 400 Hz has coincidences with K1:ASC-CHARD_P, ASC-REFL_QPDA1_RF17_I_PIT, ASC-DHARD_P, ASC-AS_QPDA1_RF17_Q_PIT, OMC-QPDV1_PIT, ASC-REFL_QPDA4_RF90_I_YAW.
The glitch around 30Hz and 60Hz had coincidences with ASC-DSOFT_P.
The glitch around 40Hz had coincidences mainly with LSC-AS_PDA1_RF17_Q_ERR.
The glitch from 300 to 400 Hz has many coincidence with ASC-REFL_QPDA1_RF17_I_PIT, ASC-POP_QPDA2_RF45_I_YAW, ASC-DHARD_P, ASC-CHARD_Y.
address Setting contents
0x00000000: used for leap second setting
0x00000080: DST setting
0x00000800: Time zone setting
The setting values were as follows.
0x00000000 0x08
0x00000080 0x80
0x00000800 0x08
All others were 0xFF.
From this, it seems that the area used by EEPROM is the above 3 bytes when considered together with the contents of the FPGA program.
Compared with the results tested with the new IRIG-B, there seems to be a discrepancy in the leap second, DST, and time zone settings on the test bench IRIG-B.
about leap second settings
0xFF (default): 255 seconds
0x00: no delay
0xF0: 15 seconds delay 11110000b
0x08: 16 seconds delay 00001000b
0x88: 17 seconds delay 10001000b
0x48: 18 seconds delay 01001000b
As of May 2025, the official leap second adjustment is 18.
As of February 2012, the official leap second adjustment is 15.
As of February 2015, the official leap second adjustment is 16.
Based on the time difference between the GPS and UTC times of the IRIG-B on the test bench, it is assumed that the leap seconds have not been adjusted.
The reason why the leap second deviation was 255 seconds in the new IRIG-B before was probably because the setting value was not included.
DST setting
0xFF (default): DST ON
0x80: DST ON
0x00: DST OFF
Time zone setting
0xFF (default): -0.5h
0x08: 8.0h
0x48: 9.0h
Local time is found to be apparently +9 hours (time zone +8.0h, daylight saving time +1.0h) from UTC in IRIG-B on the test bench.
Finally, tunnel blasting ended. In addition, the construction on the river by other contractors appears to have stopped for a while, as there were no heavy industry vehicles or workers.
Shift time: 9-17 (JST)
Check Items:
VAC: No issues were found.
CRY cooler: No issues were found.
Compressor: No issues were found.
IFO state (JST):
09:00 The shift was started. The status was OBSERVING.
09:09 Turned off OBS INTENT (klog 34494)
SR3 GAS offload work (klog34492)
10:49 Turned on OBS INTENT (klog 34494)
11:25 Lockloss
11:45 OBSERVING
15:41 Lockloss with IMCL label (human band EQ)
16:11 OBSERVING
17:00 This shift was finished. The status was OBSERVING.
Thank you for measuring the surface of sapphire parts.
Is it possible to mask the edge of 1.5mm from the measurement results of HCB surface of sapphire ears?
Our specification of the flatness for HCB surface is 77*27 area of 80*30 surface, so it would be helpful to compare the result with the data from the company.
The monitor page (https://gwdet.icrr.u-tokyo.ac.jp/~controls/slowmonitor/GAS/) maintained by Washimi-san might be helpful to find the saturation quickly. How about asking the daily (or weekly) check for the shift operator?