Reports 1-1 of 1 Clear search Modify search
DGS (General)
takahiro.yamamoto - 19:17 Saturday 24 May 2025 (33893) Print this report
Proposal about data reduction to mitigate IPC glitches

After O4a, we succeeded to reduce IPC glitches drastically in klog#29110.
But glitch rate increased gradually with many updates of real-time model after O4a.
Reduction of data rate is one of the most simple solution for this issue.
(I have some other ideas but they probably need a down time of DAQ system in several weeks.)
So I listed up fast channels and show channels which may be unnecessary during observing run.
After the end of O4 they can be backed to the channel list.

-----
A current number of channels of each sampling rate is as follows. The 1st and 2nd columns are the sampling rate and a number of channels, respectively. A channel number equivalent to the 16Hz sampling is also shown in the 3rd column.
 

fsample[Hz] # of chan 16​​​​​​Hz equiv.
16 179826 179826
32 0 0
64 0 0
128 0 0
256 2044 32704
512 1309 41888
1024 592 37888
2048 888 113664
4096 29 7424
8192 0 0
16384 203 207872
32768 0 0
65536 10 40960

 


Below is a list of those that may be removable (I only checked 1024-65536Hz sampling). If we can remove all of them, it becomes ~15% reduction of data rate. Attached file is all channels for each sampling rate.

65kHz channels
They are related to the beacon system and they are mainly used for Q-value measurements. Q-value measurements will not be done during observing runs probably. We can removed them during O4c. When we will do these measurements in post-commissioning, they can be restored.

16kHz channels
14 GIF related channels:
Fringe analysis on GIF model is no longer working for a long time due to an absence of management people. So they should be removed.

6 OPS related channels:
They are the test channel for calibration stream. So they are sometimes used during non-observing period but not used during observing period. There is no problem to remove them.

5 PSL-REFCAV and PSL-TTFSS related channels:
There is no longer REFCAV. We may be better to ask IOO team to remove the model itself after O4c. Anyway these channels can be removed form DAQ list.

4 CAL-INJ related channels:
There is no HW injection plan during science-mode (at least I haven't heard). So we can remove all data with the excitation flag from science-mode. In this situation, we don't need to record injection waveform itself and recording excitation flag is enough.

4 CARM, SRCL IN/OUT channels:
They don't use and can be removed during observing-mode. When we will do RSE trial in the post-commissioning, we can restore SRCL related channels.

4 Type-B BF_LOCK_L channels:
We don't have BF damper for TypeB.

3 PEM-PORTABLE channels:
If no sensor is connected to these channels we may be able to remove some of them. I'm not sure the current status of PORTABLE channels. So we need to ask PEM team.

2kHz channels
89 PEM-PORTABLE channels:
Same situation as 16KHz PEM-PORTABLE channels.

22 AOS-NAB channels:
They seems to be old informations. Current NAB has only baffle PDs and the are recorded as K1:NAB-.*

11 VIS-GIF channels:
Same situation as 16kHz GIF channels.

2 SRCLFF channels:
Same situation as 16kHz SRCL IN/OUT channels.

1kHz channels
45 Type-B BF related channels except BF_GAS:
Same situation as 2kHz BF_L channels.
 

 

Non-image files attached to this report
Comments to this report:
tomotada.akutsu - 20:44 Saturday 24 May 2025 (33894) Print this report

Should be seriously looked at.

NAB-related channels should be removed if they would be pushing out to the critical line --- so far, it seems the other channels should be the ones to be best considered at first.

takahiro.sawada - 9:21 Monday 26 May 2025 (33899) Print this report

Removing all OPS-related channels during the observation period is acceptable.

ryutaro.takahashi - 9:55 Monday 26 May 2025 (33900) Print this report

This is a comment for the candidate's channels on VIS.

  • 16kHz Type-B BF_LOCK_L channels: not necessary

  • 1kHz Type-B BF related channels except BF_GAS: not necessary

takaaki.yokozawa - 9:35 Thursday 29 May 2025 (33945) Print this report
For PEM portable channels, we decided most portable channels were removed from DQ channels, except for the four channels around IFI area and OMC area.
We will perform the model restart at next maintenance day.

Next : we will check the PEM channels were working well, turned off the PEM injection tools, check un-installed channel
Images attached to this comment
satoru.ikeda - 17:41 Friday 30 May 2025 (33973) Print this report

model Update

Request from YamaT-san (Representative)

This task is related to K-Log#33893.

As a countermeasure, we reduced the data volume in the hope of decreasing the frequency of IPC glitches.
However, it is still unclear whether reducing the data volume will actually lead to improvement.

GIF-related
[K1PX1]

model: k1gifx
detail:
 Path: gif/k1/models/
 k1gifx.mdl
 => Backup: archive/k1gifx_beforeO4c_20250528.mdl

 deletions:
  K1:GIF-X_{ANGLE,DD,LAMP,P_AMP,PHASE,P_OFFSET,PPOL,ROTATION,S_AMP,S_OFFSET,SPOL,STRAIN,ZABS}_IN1_DQ
  K1:GIF-X_STRAIN_OUT_DQ

IOO-related
[K1IOO]
model: k1psl
detail:
 psl/k1/models/k1psl.mdl
 => Backup: archive/k1psl_beforeO4c_20250528.mdl
 psl/common/models/fss.mdl
 => Backup: archive/fss_beforeO4c_20250528.mdl

 deletions:
  K1:PSL-REFCAV_{REFL,TRANS}_OUT
  => Since cavity/cavity is also used in k1imc.mdl, the link was disabled and deleted from k1psl.
  K1:PSL-TTFSS_{EOM_MON,MIXER_MON,PZT_MON,TEMP_FILTER,TEMP_MON}_OUT
  => fss/TTFSS is not used elsewhere, so DAQ channels were deleted from fss/TTFSS.

[K1IOO1]
model: k1psliss
detail:
 psl/k1/models/k1psliss.mdl
 => Backup: archive/k1psliss_beforeO4c_20250528.mdl

 deletions:
 K1:PSL-ISS_FIRST_SERVO_PDB_{INF,RIN}_OUT
 => No link, deleted from k1psliss.mdl (PDA remains)

MIF-related
[K1LSC0]
model: k1lsc, k1lsc2
detail:
 lsc/k1/models/k1lsc.mdl
 => Backup: backup/k1lsc_beforeO4c_20250528.mdl
 k1lsc2.mdl
 => Backup: backup/k1lsc2_beforeO4c_20250528.mdl
 lsc/common/models/lsc.mdl
 => Backup: backup/lsc_beforeO4c_20250528.mdl (Unchanged, backup just in case)

 Planned to restore after O4:
  K1:LSC-{SRCLFF1,SRCLFF2}_OUT
  K1:LSC-SRCL_{IN1,OUT}
  K1:LSC-CARM_{IN1,OUT}

 deletions:
  K1:LSC-CARM_CTRL_256
  K1:LSC-CARM_RESIDUAL_OUT
  K1:LSC-{XARM,YARM}_{IN1,OUT}
  => Since these were already handled by breaking links in response to K-Log#32920, the DAQ channels were deleted from k1lsc.mdl.

VIS-related
[K1BS/K1SR2/K1SR3/K1SRM]
model: k1visbst, k1vissr2t, k1vissr3t, k1vissrmt
detail:
 vis/common/models/TOWER_MASTER.mdl
 => Backup: archive/TOWER_MASTER_beforeO4c_20250528.md
 Copied TOWER_MASTER/common_blocks/TYPEBP_BFMASTER and created TYPEB_BFMASTER
 Replaced the BF in TOWER_MASTER/TYPEB_TOWER_MASTER with TYPEB_BFMASTER and deleted DAQ channels
 (k1visbst.mdl, k1vissr2t.mdl, k1vissr3t.mdl were not modified)
 vis/k1/models/
 k1visbst.mdl => Backup: archive/k1visbst_beforeO4c_20250528.mdl (Unchanged, backup just in case)
 k1vissr2t.mdl => Backup: archive/k1vissr2t_beforeO4c_20250528.mdl (Unchanged, backup just in case)
 k1vissr3t.mdl => Backup: archive/k1vissr3t_beforeO4c_20250528.mdl (Unchanged, backup just in case)
 k1vissrmt.mdl => Backup: archive/k1vissrmt_beforeO4c_20250528.mdl

 deletions:
  Common to Type-B
  K1:VIS-{BS,SR2,SR3,SRM}_BF_ADD_{L,P,Y,R,T,V}_OUT
  K1:VIS-{BS,SR2,SR3,SRM}_BF_DAMP_{L,P,Y,R,T,V}_{IN1,OUT}
  K1:VIS-{BS,SR2,SR3,SRM}_BF_LOCK_L_IN1
  K1:VIS-{BS,SR2,SR3,SRM}_BF_LVDTINF_{H1,H2,H3,V1,V3,V3}_{IN1,OUT}
  K1:VIS-{BS,SR2,SR3,SRM}_BF_MASTER_OUT_{H1,H2,H3,V1,V3,V3}
  K1:VIS-{BS,SR2,SR3,SRM}_BF_OLDAMP_{L,P,Y}_{IN1,OUT}

  Only for BS, SR2, SR3
  K1:VIS-{BS,SR2,SR3}_BF_SUMOUT_{L,P,Y,R,T,V}_OUT

  Only for SRM
  K1:VIS-SRM_BF_MNOLDAMP_{L,P,Y,R,T,V}_{IN1,OUT}
  K1:VIS-SRM_BF_PFOLDAMP_{L,P,Y}_{IN1,OUT}

 Addition (SRM only)
  K1:VIS-SRM_BF_SUMOUT_BF_OUT

CAL-related
[K1ASC0]
model: k1calinj
detail:
 cal/k1/models/k1calinj.mdl => Backup: archive/k1calinj_beforeO4c_20250528.mdl
 cal/common/models/CAL_INJ_MASTER.mdl => Backup: archive/CAL_INJ_MASTER_beforeO4c_20250528.mdl

 deletions:
  K1:CAL-INJ_{CW,MASTER,STATUS,TRANSIENT}_OUT

OPS-related
[K1TEST0]
model: k1opssim
detail:
 sys/common/models/k1opssim.mdl => Backup: archive/k1opssim_beforeO4c_20250528.mdl

 deletions:
  K1:OPS-SIM_{AUX1,C00_STRAIN_DBL,C10_STRAIN,FLOOR_OUT,GAUSS1_IN1,GAUSS1_OUT}

AOS-related
[K1IY0]
models: k1aosiyanab, k1aosiycwab
detail:
 aos/k1/models/k1aosiyanab.mdl => Backup: archive/k1aosiyanab_beforeO4c_20250528.mdl
 aos/k1/models/k1aosiycwab.mdl => Backup: archive/k1aosiycwab_beforeO4c_20250528.mdl
 vis/k1/models/k1vists.mdl => Backup: archive/k1vists_beforeO4c_20250528.mdl

 Targeted Channels:
  K1:AOS-HPBD_IFI_TEMPERATURE_OUT
  K1:AOS-IYA_NAB_OL_{PIT,YAW,SUM}_OUT
  K1:AOS-IYA_NAB_OL_{SEG1,SEG2,SEG3,SEG4}_IN1
  K1:AOS-IYC_WAB_OL_{PIT,YAW,SUM}_OUT
  K1:AOS-IYC_WAB_OL_{SEG1,SEG2,SEG3,SEG4}_IN1
  K1:AOS-IYC_WAB_OUTF_{PIT,YAW,X,Y,Z}_OUT
  K1:AOS-IYC_WAB_PS_INF_{S1,S2,S3}_IN1

Unknown
[K1OMC0]
model: k1ascbeacon
detail:
 omc/k1/models/k1ascbeacon.mdl => Backup: archive/k1ascbeacon_beforeO4c_20250528.mdl

 deletions:
  K1:ASC-OMC_REFL_{QPDA1,QPDA2}_RF17_{I1,I2,I3,I4}_ERR
  K1:MIR-AS_PDA1_RF17_{I,Q}_OUT

[K1EX1, K1EY1, K1IX1, K1IY1, K1BS, K1SR2, K1SR3, K1SRM, K1PR2, K1PR0, K1PRM]
models: k1visetmxt, k1visetmyt, k1visitmxt, k1visitmyt, k1visbst, k1vissr2t, k1vissr3t, k1vissrmt, k1vispr2t, k1vispr3t, k1visptmt
detail:
 vis/common/models/TOWER_MASTER.mdl => Backup: archive/TOWER_MASTER_beforeO4c_20250528.md
 vis/k1/models/k1vissrmt.mdl => Backup: archive/k1vissrmt_beforeO4c_20250528.mdl

 deletions:
  K1:VIS-{ETMX,ETMY,ITMX,ITMY,BS,SR2,SR3,SRM,PR2,PR3,PRM}_GIF_ARM_L_OUT

OMC-related
[K1OMC0]
model: k1omc
detail:
 k1omc.mdl => Backup: archive/k1omc_beforeO4c_20250528.mdl

 deletions:
  K1:OMC-AS_PDA1_DC_OUT
  K1:OMC-POS_{SPOL,PPOL}_DC_OUT
 

Images attached to this comment
Non-image files attached to this comment
takahiro.yamamoto - 21:50 Friday 30 May 2025 (33979) Print this report
Amount of data transfer rate between each modified model and k1dc0 is shown in Fig.1.
A timing of the data reduction is probably depending on a timing of a model restart, so it's different in models.
Though I didn't accurate check for all models, reduction of data rate is almost consistent with expected one from sampling rate and number of channels.
File size of frames was also reduced from ~550MB to ~450MB. So CPU load on k1fw0,1 were also improved though downstream of k1dc0 should not to be related to IPC glitches.
Images attached to this comment
Search Help
×

Warning

×