Differences between revisions 59 and 85 (spanning 26 versions)
⇤ ← Revision 59 as of 2019-08-14 10:15:07 →
Size: 11393
Editor: chihiro.kozakai
Comment:
← Revision 85 as of 2020-12-16 18:00:59 → ⇥
Size: 7846
Editor: chihiro.kozakai
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
This project is for glitch and lock loss study. Also applicable to event validation of GW candidate. You can see the result [[https://gwdet.icrr.u-tokyo.ac.jp/~controls/GlitchPlot/index.html|here]].
Line 7: Line 8:
This project is for glitch and lock loss study. You can see the result on [[https://www.icrr.u-tokyo.ac.jp/~yuzu/bKAGRA_summary/html/|Yuzu Summary]]. Original developer: Chihiro Kozakai (production of plots), Hirotaka Yuzurihara (web page).
Line 9: Line 10:
Feedback from users are very welcome ! Please inform C. Kozakai and H. Yuzurihara.

== Recent update ==
 *8/14 Only main channel trigger is used.
 
 *8/10 For daily run, both glitch and lockloss are monitored during nightly data taking. Trigger list is updated to adapt X-arm configuration.

 *7/24 For daily run, only lock loss events will be monitored.


Old information is more below.
Line 23: Line 13:
8/15~ (X-arm nightly, only time with K1:MIF-WE_ARE_DOING_NOTHING == 1)
Line 25: Line 14:
||<:>'''Channel'''||'''SNR threshold'''||
||CAL-CS_PROC_XARM_FREQUENCY_DQ||<:> 21 ||
||<:>'''Lock state : X-arm'''||		 4/7~4/20 O3GK
||<style="text-align:center">'''Channel''' ||'''SNR threshold''' ||
||K1:CAL-CS_PROC_DARM_DISPLACEMENT_DQ ||<style="text-align:center">100 ||
||<style="text-align:center">'''Lock state : Observation mode (K1:GRD-IFO_STATE_N == 1000)''' ||
Line 29: Line 19:
8/10~ (X-arm nightly, only time with K1:MIF-WE_ARE_DOING_NOTHING == 1)

||<:>'''Channel'''||'''SNR threshold'''||
||CAL-CS_PROC_XARM_FREQUENCY_DQ||<:> 21 ||
||LSC-CARM_SERVO_MIXER_DAQ_OUT_DQ||<:> 15 ||
||AOS-TMSX_IR_PD_OUT_DQ||<:> 15 ||
||IMC-SERVO_SLOW_DAQ_OUT_DQ||<:> 12 ||
||IMC-CAV_TRANS_OUT_DQ||<:> 45 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:> 35 ||
||<:>'''Lock state : X-arm'''||

7/25~ (only 0:00~8:00)

||<:>'''Channel'''||'''Requirement'''||
||IMC-CAV_TRANS_OUT_DQ||<:> Lock loss ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>Lock loss ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||CAL-CS_PROC_IMC_FREQUENCY_DQ||<:> Lock loss ||
||<:>'''Lock state : MICH'''||

7/13 (MICH ER)

||<:>'''Channel'''||'''SNR threshold'''||
||IMC-CAV_TRANS_OUT_DQ||<:> 35 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>30 ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:>6 ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:>8 ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:>15 ||
||CAL-CS_PROC_IMC_FREQUENCY_DQ||<:>15 ||
||<:>'''Lock state : LSC'''||

6/8 (X-arm ER)

||<:>'''Channel'''||'''SNR threshold'''||
||LSC-CARM_SERVO_MIXER_DAQ_OUT_DQ||<:> 10 ||
||AOS-TMSX_IR_PD_OUT_DQ||<:> 10 ||
||IMC-MCL_SERVO_OUT_DQ||<:> 30 ||
||IMC-SERVO_SLOW_DAQ_OUT_DQ||<:> 7 ||
||IMC-CAV_TRANS_OUT_DQ||<:> 10 ||
||IMC-CAV_REFL_OUT_DQ||<:> 10 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:> 30 ||
||PSL-PMC_MIXER_MON_OUT_DQ||<:> 10 ||
||<:>'''Lock state : IMC'''||

Old information is more below.
Line 78: Line 21:
The main purpose is to study glitches and lock loss by visual inspection. Also, collecting information for glitch database is done through voting form for each glitch event. Using the result, we aim to do noise hunting, glitch characterization, and labeling for machine learning application. Here is slides describing how to use: [[https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=10371|slides]]
Line 79: Line 23:
The main purpose is to study glitches and lock loss by visual inspection. Also, collecting information for glitch database is done through voting form for each glitch event.
Using the result, we aim to do noise hunting, glitch characterization, and labeling for machine learning application.
Here is slides describing how to use: [[https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=10371|slides]]		 GlitchPlot uses trigger information provided by Omicron. GlitchPlot does clustering of the triggers and summarize the trigger information for each events based on the Omicron output.
Line 83: Line 25:
GlitchPlot uses trigger information provided by Omicron. GlitchPlot does clustering of the triggers and summarize the trigger information for each events based on the Omicron output. Also, GlitchPlot uses lock loss information based on lock state information of guardian.
Line 85: Line 27:
For each events, plots for triggered channel and relevant channels are provided on [[https://www.icrr.u-tokyo.ac.jp/~yuzu/bKAGRA_summary/html/|Yuzu Summary]].
The relevant channels are basically chosen from 		For each events, plots for triggered channel and relevant channels are provided [[https://gwdet.icrr.u-tokyo.ac.jp/~controls/GlitchPlot/index.html|here]]. The relevant channels are basically chosen from
Line 94: Line 36:
Line 99: Line 42:
Line 101: Line 45:
There is channel list of 2 types of suggestion. The intent of this list is to pick up suspicious channels which is related to noise source.
 * Suggestion 1: picked up by higher coherence than usual
 * Suggestion 2: picked up by high SNR in Q-transform

The event web page shows the result in the following order.
1. Lock state
2. Trigger channel plots
3. Suggestion 1 channel plots
4. Suggestion 2 channel plots
5. Channels affected by DARM DoF
6. Other channels
Line 102: Line 58:
Line 112: Line 67:
 *Time series
  *GPS start time ($gpsstart), end time ($gpsend)		  * Time series
  * GPS start time ($gpsstart), end time ($gpsend)
Line 116: Line 71:
  *Output directory ($outdir)
  *Channel ($chlist[@])
  *Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
  *Data file type ($data)     *Full data is used.
  *If time span is too long, down sample is applied.		   * Output directory ($outdir)
  * Channel ($chlist[@])
  * Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
  * Data file type ($data)
   * Full data is used.
  * If time span is too long, down sample is applied.
Line 123: Line 78:
 *Spectrum
  *List of GPS start time ($gpsstarts30[@]), end time ($gpsend30[@])
   * Trigger time and 2sec before and after the trigger is avoided. 		  * Spectrum
  * List of GPS start time ($gpsstarts30[@]), end time ($gpsend30[@])
   * Trigger time and 2sec before and after the trigger is avoided.
Line 128: Line 83:
  *Output directory ($outdir)
  *Channel ($chlist[@])
  *FFT length ($fft30)		   * Output directory ($outdir)
  * Channel ($chlist[@])
  * FFT length ($fft30)
Line 133: Line 88:
 *Spectrogram, coherencegram
  *GPS start time ($gpsstart), end time ($gpsend)		  * Spectrogram, coherencegram
  * GPS start time ($gpsstart), end time ($gpsend)
Line 138: Line 93:
  *Output directory ($outdir)
  *Channel ($chlist[@])
  *Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel) 
  *Stride ($stride)		   * Output directory ($outdir)
  * Channel ($chlist[@])
  * Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
  * Stride ($stride)
Line 143: Line 98:
  *FFT length ($fft)   * FFT length ($fft)
Line 145: Line 100:
  *With and without whitening (Spectrogram)   * With and without whitening (Spectrogram)
Line 147: Line 102:
 *Q-transform (Under testing. GWpy default parameter is used.)
  *GPS start time ($gpsstart), end time ($gpsend)
  *Output directory ($outdir)
  *Channel ($chlist[@])
  *Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)		  * Q-transform (Under testing. GWpy default parameter is used.)
  * GPS start time ($gpsstart), end time ($gpsend)
  * Output directory ($outdir)
  * Channel ($chlist[@])
  * Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
Line 153: Line 108:
 *Lock segment summary
  *GPS start time ($gpsstart), end time ($gpsend)		  * Lock segment summary
  * GPS start time ($gpsstart), end time ($gpsend)
Line 156: Line 111:
  *Output directory ($outdir)
  *Channel ($channel)
  *Trigger time ($gpstime) and duration ($max_duration)		   * Output directory ($outdir)
  * Channel ($channel)
  * Trigger time ($gpstime) and duration ($max_duration)
Line 160: Line 115:

=== Suggestion channel list ===
It is generated event by event. {{{GlitchPlot/Script/suggestion.py}}} is used. Please refer p3,4 in [[https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=10987|slides]].
Line 164: Line 122:
Master branch: On Kamioka server, plotter.sh runs by crontab every 15 min. plotter.py is called. it gives clustered Omicron trigger information as a text file. The text files are sent to Kashiwa server by rsync.  Master branch: On Kamioka server, plotter.sh runs by crontab every 15 min. plotter.py is called. it gives clustered Omicron trigger information as a text file. The text files are sent to Kashiwa server by rsync.
Line 166: Line 124:
kashiwa branch: On Kashiwa sercer, GlitchPlot.sh runs by crontab every 15 min. Using text file sent from Kamioka, condor_jobfile_plotter.sh runs to throw jobs into condor to make plots.  kashiwa branch: On Kashiwa server, GlitchPlot.sh runs by crontab every 15 min. Using text file sent from Kamioka, condor_jobfile_plotter.sh runs to throw jobs into condor to make plots.
Line 168: Line 126:
= Info log = === Job structure ===
O3GK configuration (2020/12/16: It is stopped.)
Line 170: Line 129:
== Trigger channel list log == 1. On k1sum1: From the Omicron result, triggered event and the parameters are summarized as text files. The files are rsync-ed to Kashiwa server.
Line 172: Line 131:
7/25~ (only 0:00~8:00) By crontab, {{{4-59/15 * * * * /users/DET/tools/GlitchPlot/Script/plotter.sh > /tmp/GlitchPlot.log 2>&1}}}
Line 174: Line 133:
||<:>'''Channel'''||'''Requirement'''||
||IMC-CAV_TRANS_OUT_DQ||<:> Lock loss ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>Lock loss ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:> Lock loss ||
||CAL-CS_PROC_IMC_FREQUENCY_DQ||<:> Lock loss ||
||<:>'''Lock state : MICH'''||		 2. On chihiro.kozakai@m31-02: Based on text file sent from k1sum1, plots are produced using condor.
Line 183: Line 135:
7/19~ (only 0:00~8:00) By crontab,
{{{
4-59/15 * * * * /home/chihiro.kozakai/detchar/KamiokaTool/tools/GlitchPlot/Script/GlitchPlot.sh > /tmp/GlitchPlot.log 2>&1
10 */3 * * * /home/chihiro.kozakai/detchar/KamiokaTool/tools/GlitchPlot/Script/plotter_lockloss.sh > /tmp/GP_lockloss.log 2>&1
}}}
Line 185: Line 141:
||<:>'''Channel'''||'''SNR threshold'''||
||IMC-CAV_TRANS_OUT_DQ||<:> 45 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>40 ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:>16 ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:>18 ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:>25 ||
||CAL-CS_PROC_IMC_FREQUENCY_DQ||<:>25 ||
||<:>'''Lock state : LSC'''||		 3. On k1det0: Plots on Kashiwa server is rsync-ed. Then html for the web page is generated and accessible on GWDET server.
Line 194: Line 143:
7/13 (MICH ER) By crontab, {{{30 */3 * * * /users/DET/tools/GlitchPlot/Script/GlitchPlot_html.sh > /tmp/GlitchPlot.log}}}
Line 196: Line 145:
||<:>'''Channel'''||'''SNR threshold'''||
||IMC-CAV_TRANS_OUT_DQ||<:> 35 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>30 ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:>6 ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:>8 ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:>15 ||
||CAL-CS_PROC_IMC_FREQUENCY_DQ||<:>15 ||
||<:>'''Lock state : LSC'''||


7/12~ and 7/13 11:30~24:00

||<:>'''Channel'''||'''SNR threshold (8:00~24:00)'''||'''SNR threshold (0:00~8:00 and 7/13 11:30~24:00)'''||
||IMC-CAV_TRANS_OUT_DQ||<:> veto ||<:> 10 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>veto ||<:> 30 ||
||LSC-REFL_PDA1_RF17_Q_ERR_DQ||<:>veto ||<:> 30 ||
||LSC-POP_PDA1_RF17_Q_ERR_DQ||<:>veto ||<:> 30 ||
||LSC-AS_PDA1_RF17_Q_ERR_DQ||<:>veto ||<:> 30 ||
||CAL_CS_PROC_IMC_FREQUENCY_DQ||<:>veto ||<:> 30 ||
||<:>'''Lock state : MICH'''||

7/10~

||<:>'''Channel'''||'''SNR threshold (8:00~24:00)'''||'''SNR threshold (0:00~8:00)'''||
||IMC-CAV_TRANS_OUT_DQ||<:> veto ||<:> 20 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>veto ||<:> 40 ||
||PEM-ACC_MCF_TABLE_REFL_Z_OUT_DQ||<:>veto ||<:> 40 ||
||PEM-ACC_PSL_PERI_PSL1_Y_OUT_DQ||<:>veto ||<:> 20 ||
||PEM-MIC_PSL_TABLE_PSL4_Z_OUT_DQ||<:>veto ||<:> 20 ||
||<:>'''Lock state : IMC'''||

7/5~7/9 (buggy setting)

||<:>'''Channel'''||'''SNR threshold (8:00~24:00)'''||'''SNR threshold (0:00~8:00)'''||
||IMC-CAV_TRANS_OUT_DQ||<:> 100 ||<:> veto ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:>100 ||<:> veto ||
||PEM-ACC_MCF_TABLE_REFL_Z_OUT_DQ||<:>100 ||<:> veto ||
||PEM-ACC_PSL_PERI_PSL1_Y_OUT_DQ||<:>100 ||<:> veto ||
||PEM-MIC_PSL_TABLE_PSL4_Z_OUT_DQ||<:>100 ||<:> veto ||
||<:>'''Lock state : IMC'''||


6/8 during ER

||<:>'''Channel'''||'''SNR threshold'''||
||LSC-CARM_SERVO_MIXER_DAQ_OUT_DQ||<:> 10 ||
||AOS-TMSX_IR_PD_OUT_DQ||<:> 10 ||
||IMC-MCL_SERVO_OUT_DQ||<:> 30 ||
||IMC-SERVO_SLOW_DAQ_OUT_DQ||<:> 7 ||
||IMC-CAV_TRANS_OUT_DQ||<:> 10 ||
||IMC-CAV_REFL_OUT_DQ||<:> 10 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:> 30 ||
||PSL-PMC_MIXER_MON_OUT_DQ||<:> 10 ||
||<:>'''Lock state : IMC'''||

6/12~7/5

||<:>'''Channel'''||'''SNR threshold'''||
||IMC-CAV_TRANS_OUT_DQ||<:> 100 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:> 100 ||
||PEM-ACC_MCF_TABLE_REFL_Z_OUT_DQ||<:> 100 ||
||PEM-ACC_PSL_PERI_PSL1_Y_OUT_DQ||<:> 100 ||
||PEM-MIC_PSL_TABLE_PSL4_Z_OUT_DQ||<:> 100 ||
||<:>'''Lock state : IMC'''||

6/7~6/12

||<:>'''Channel'''||'''SNR threshold'''||
||LSC-CARM_SERVO_MIXER_DAQ_OUT_DQ||<:> 100 ||
||AOS-TMSX_IR_PD_OUT_DQ||<:> 100 ||
||IMC-MCL_SERVO_OUT_DQ||<:> 30 ||
||IMC-SERVO_SLOW_DAQ_OUT_DQ||<:> 7 ||
||IMC-CAV_TRANS_OUT_DQ||<:> 10 ||
||IMC-CAV_REFL_OUT_DQ||<:> 10 ||
||PSL-PMC_TRANS_DC_OUT_DQ||<:> 30 ||
||PSL-PMC_MIXER_MON_OUT_DQ||<:> 10 ||
||<:>'''Lock state : X-arm'''||

== Update log ==
 *8/14 Only main channel trigger is used.

 *8/10 For daily run, both glitch and lockloss are monitored during nightly data taking. Trigger list is updated to adapt X-arm configuration.

 *7/24 For daily run, only lock loss events will be monitored.

 *7/19 Glitch events in ER on 7/13 are reprocessed. [[https://www.icrr.u-tokyo.ac.jp/~yuzu/bKAGRA_summary/html/20190713_GlitchPlot.html|Yuzu summary]]

 *7/13 SNR thresholds are optimized ER trigger rate.

 *7/12 Trigger channel is changed for MICH optimized set.

 *7/10 Changed SNR threshold.

 *7/9 Bug fix for SNR threshold lowering.

 *7/5 SNR threshold is lowered during 0am-8am. Instead, daytime events are all rejected.

 *7/5 Missing plot for PEM trigger channel is fixed.

 *7/4 ER events are reprocessed.

 *7/4 Started this wiki.		 === Note for developer ===
 * Please modify output directory.
 * Job structure should be modified. Step 2 should be moved to detchar account. If web server is implemented on Kashiwa server, Step 1 and 3 also have to be moved to Kashiwa server.
 * It is better to use low-latency pipeline result for RRT. CBC and burst pipeline configuration is under constructing.
  * For cWB offline result: {{{GlitchPlot/Script/urst_automation}}}
 * Please reconsider channel list. At least, SRCL related channels will be required. ASC maybe also important.
 * Top page maybe better to start from the latest date.
 * manual code introduction (they are under GlitchPlot/Script/)
  * checkOmicron.py: To check if Omicron

GlitchPlot

This project is for glitch and lock loss study. Also applicable to event validation of GW candidate. You can see the result here.

Original developer: Chihiro Kozakai (production of plots), Hirotaka Yuzurihara (web page).

The latest trigger channel list

4/7~4/20 O3GK

Channel

SNR threshold

K1:CAL-CS_PROC_DARM_DISPLACEMENT_DQ

100

Lock state : Observation mode (K1:GRD-IFO_STATE_N == 1000)

Overview

The main purpose is to study glitches and lock loss by visual inspection. Also, collecting information for glitch database is done through voting form for each glitch event. Using the result, we aim to do noise hunting, glitch characterization, and labeling for machine learning application. Here is slides describing how to use: slides

GlitchPlot uses trigger information provided by Omicron. GlitchPlot does clustering of the triggers and summarize the trigger information for each events based on the Omicron output.

Also, GlitchPlot uses lock loss information based on lock state information of guardian.

For each events, plots for triggered channel and relevant channels are provided here. The relevant channels are basically chosen from

  • Trigger channel
  • Unsafe channels
  • Important upstream channels
  • Relevant VIS channels
  • PEM near the trigger channel sensor

Using Kozapy batch codes, following plots are provided:

  • Time series
  • Spectrum before trigger and after trigger
  • Spectrogram
  • Coherencegram with trigger channel
  • Q-transform (Under testing)

The parameter for plots are determined based on trigger information. Also, lock state summary around the trigger time is provided.

There is channel list of 2 types of suggestion. The intent of this list is to pick up suspicious channels which is related to noise source.

  • Suggestion 1: picked up by higher coherence than usual
  • Suggestion 2: picked up by high SNR in Q-transform

The event web page shows the result in the following order. 1. Lock state 2. Trigger channel plots 3. Suggestion 1 channel plots 4. Suggestion 2 channel plots 5. Channels affected by DARM DoF 6. Other channels

Specification detail

Trigger clustering

For the trigger clustering method, please refer p3 of slides.

Plot channel list

For the exact channel list for each trigger, please refer $channelname.dat in GlitchPlot github.

Plot parameter

For the exact method for plot parameter determination, please refer plotter.py and condor_jobfile_plotter.sh in GlitchPlot github. The intent and the variable name in the shell script is as follows.

  • Time series
    • GPS start time ($gpsstart), end time ($gpsend)
      • The center is the trigger time.
      • Time span is roughly larger one of [4sec, trigger duration * 10]. (Adjusted to fit the spectrogram requirement)
    • Output directory ($outdir)
    • Channel ($chlist[@])
    • Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
    • Data file type ($data)
      • Full data is used.
    • If time span is too long, down sample is applied.
  • Spectrum
    • List of GPS start time ($gpsstarts30[@]), end time ($gpsend30[@])
      • Trigger time and 2sec before and after the trigger is avoided.
      • About 30 sec is used each before trigger and after trigger spectrum.
      • The length is adusted to the multiple of the FFT length.
    • Output directory ($outdir)
    • Channel ($chlist[@])
    • FFT length ($fft30)
      • 1/band width (Adjusted to the nearest 2^n sec.)
  • Spectrogram, coherencegram
    • GPS start time ($gpsstart), end time ($gpsend)
      • The center is the trigger time.
      • Time span is roughly larger one of [4sec, trigger duration * 10].
      • The length is adjusted to be Stride * n
    • Output directory ($outdir)
    • Channel ($chlist[@])
    • Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
    • Stride ($stride)
      • To have enough time resolution to see the glitch.
    • FFT length ($fft)
      • stride = FFT length * n
    • With and without whitening (Spectrogram)
  • Q-transform (Under testing. GWpy default parameter is used.)
    • GPS start time ($gpsstart), end time ($gpsend)
    • Output directory ($outdir)
    • Channel ($chlist[@])
    • Lock state segment bar: flag($lock), guardian channel($lchannel), guardian value($lnumber), segment bar title($llabel)
  • Lock segment summary
    • GPS start time ($gpsstart), end time ($gpsend)
      • Same as time series
    • Output directory ($outdir)
    • Channel ($channel)
    • Trigger time ($gpstime) and duration ($max_duration)
      • Taken from Omicron information

Suggestion channel list

It is generated event by event. GlitchPlot/Script/suggestion.py is used. Please refer p3,4 in slides.

Source code

GlitchPlot github.

Master branch: On Kamioka server, plotter.sh runs by crontab every 15 min. plotter.py is called. it gives clustered Omicron trigger information as a text file. The text files are sent to Kashiwa server by rsync.

kashiwa branch: On Kashiwa server, GlitchPlot.sh runs by crontab every 15 min. Using text file sent from Kamioka, condor_jobfile_plotter.sh runs to throw jobs into condor to make plots.

Job structure

O3GK configuration (2020/12/16: It is stopped.)

1. On k1sum1: From the Omicron result, triggered event and the parameters are summarized as text files. The files are rsync-ed to Kashiwa server.

By crontab, 4-59/15 * * * * /users/DET/tools/GlitchPlot/Script/plotter.sh > /tmp/GlitchPlot.log 2>&1

2. On chihiro.kozakai@m31-02: Based on text file sent from k1sum1, plots are produced using condor.

By crontab, 

4-59/15 * * * * /home/chihiro.kozakai/detchar/KamiokaTool/tools/GlitchPlot/Script/GlitchPlot.sh > /tmp/GlitchPlot.log 2>&1
10 */3 * * * /home/chihiro.kozakai/detchar/KamiokaTool/tools/GlitchPlot/Script/plotter_lockloss.sh > /tmp/GP_lockloss.log 2>&1

3. On k1det0: Plots on Kashiwa server is rsync-ed. Then html for the web page is generated and accessible on GWDET server.

By crontab, 30 */3 * * * /users/DET/tools/GlitchPlot/Script/GlitchPlot_html.sh > /tmp/GlitchPlot.log

Note for developer

  • Please modify output directory.
  • Job structure should be modified. Step 2 should be moved to detchar account. If web server is implemented on Kashiwa server, Step 1 and 3 also have to be moved to Kashiwa server.
  • It is better to use low-latency pipeline result for RRT. CBC and burst pipeline configuration is under constructing.

    • For cWB offline result: GlitchPlot/Script/urst_automation

  • Please reconsider channel list. At least, SRCL related channels will be required. ASC maybe also important.
  • Top page maybe better to start from the latest date.
  • manual code introduction (they are under GlitchPlot/Script/)
    • checkOmicron.py: To check if Omicron

KAGRA/Subgroups/DET/GlitchPlot (last edited 2020-12-16 18:00:59 by chihiro.kozakai)