Date :
2023/04/22(Sat)
8:35 - 8:55 (JST)(No beacon control)
10:55 - 14:06(JST)(With beacon control)
I checked the Gaussianty, and I found that there are many Non-Gaussian times in the latter silent run.
(https://gwdet.icrr.u-tokyo.ac.jp/~controls/Gauch/day/20230422/index.html )
Because the Non-Gaussians appear in all frequencies, I thought these are similar phenomena to klog24795.
In fact, I found the whitend timeseries data has many peaks (Fig.1) and there are gaps in timeseries data (Fig.2 ~ 4 ) as same as the above report. (I investigated only three gliches from the first. I will examine more later.)
However, it seems a bit different because of the following reasons.
1. These phenomena occurred many times in a short period.
2. The gap occurred twice in each of them(after the first gap, it seems the data almost recovers with the second gap).
I don't know if these are the same as klog24795, so I hope someone helps me.
A shortage of machine power for the k1lsc model makes a timing delay on k1lsc model
for writing down the signal value on the shared memory region.
The signal value on the shared memory region is read by other models.
This works as a data sharing between the different real-time models (different programs).
Due to delays of the data writing to the shared memory,
other models cannot read a correct value from the shared memory.
This is cause of the glitch like signal.
A simple way to detect them is
where x(t) is K1:CAL-DARM_{ERR,CTRL}_DBL_DQ, y(t) is K1:LSC-DARM_{IN1, OUT}_DQ.
These channels as K1:CAL-*** and K1:LSC-*** are same signals with one sample delay in 16kHz sampling rate.
But when data gap is occurs, these signal shows different waveform as shown in Fig.1.
CAL-DARM_CTRL_DBL_DQ is "doube" and LSC-DARM_OUT_DQ is "float" converted from "double" by DAQ.
So a numerical rounding error occurs as 1e-6~1e-7.
For this reason, threshold as 1e-5 is proper to detect them.
I understood very well.
This channel indicates an integer number of GPS time measured on each model.
In Fig.1, error and feedback signal on CAL model and feedback signal on ETMX model have gaps.
At the same time, TIME_DIAG channel of CAL model (FEC-11) and ETMX model (FEC-103) shows a decrement of GPS time.
In order to detect this kind of gaps, using TIME_DIAG seems to be the most efficient because they are sampled as 16Hz and they works even signals shows continuous digital zero such as feedback signal in the DOWN state as shown in Fig.2.
Detection condition can be described as
where x(t_i) is K1:FEC-*_TIME_DIAG.
According to this method, event rate in recent one week is ~30gaps/day.
And also most of gaps occurs during 10:00-14:00 JST as shown in Fig.3.
It doesn't seem to depend on the IFO situation (lock or unlock).
This may become a hint about instability of trouble rate.
Though the 1st priority is removing this problem, I'm not sure that it's possible until O4a start.
So I prepared a script (/users/DET/tools/Segments/Script/DAQ_IPC_ERROR.py)
for making segment information as the next best solution for observing runs.
