Current thresholds are as follows.
- [BS] KGRVAC:CCG_BSY_01:VAL:PRESS = 8.0e-6
- [IX] KGRVAC:CCG_X00_01:VAL:PRESS = 6.5e-6
- [EX] KGRVAC:CCG_X30_01:VAL:PRESS = 1.0e-4
- [IY] KGRVAC:CCG_Y00_01:VAL:PRESS = 5.5e-6
- [EY] KGRVAC:CCG_Y30_01:VAL:PRESS = 8.2e-6
Behavior of each readout value is as follows (see also https://gwdet.icrr.u-tokyo.ac.jp/~controls/capture/img/k1mon10-1920x0.jpg).
- [BS] readout value fluctuates between 7.8e-6 ~ 7.9e-6 Pa.
- It’s probably a numerical rounding of the actual value around 7.85e-6 Pa (?)
- [IX] readout value shows 6.3e-6 Pa in almost time.
- But large value sometimes appears like as glitch (roughly once per hour?)
- If notification is annoying, I’ll set more large value as temporal.
- [EX] readout value fluctuates a lot (6.5e-6 ~ 2.0e-5 Pa)
- So I will wait to set proper threshold until a problem will be fixed.
- [IY] readout value is stably 5.3e-6 Pa.
- [EY] readout value fluctuates between 8.0e-6 ~ 8.1e-6 Pa.
- It’s probably a numerical rounding of the actual value around 8.05e-6 Pa (?)
Notification with strict threshold seems to work well for BS, IY and EY.
On the other hand, we need to remove strange behavior on readout for IX and EX in order to set meaningful threshold.
Now I set a strict threshold for BS, IY, EY and IX. So the notification about IX may become annoying because of glitch like behavior.
If it will become an interruption of catching up another important notification, I'll disable the notification for IX.
-----
As I reported in klog#32112, because channel name doesn't follow KAGRA convention, ezca on guardian cannot be used.
For this reason it's implemented by using caget which requires much higher CPU cost than ezca.
So it's difficult to increase a number of channel that are monitored by guardian. After converting them as proper name (K1:***), all caget must be replaced to ezca.