1 # コミッショニングツール開発現状まとめ
   2 2018/06/24 譲原
   3 
   4 ## daily summary
   5 
   6 - [http://www.icrr.u-tokyo.ac.jp/~yuzu/bKAGRA_summary/html/](http://www.icrr.u-tokyo.ac.jp/~yuzu/bKAGRA_summary/html/) からアクセスできる
   7 	- user name : コラボレーション名を小文字で
   8 	- パスワード : いつもの
   9 
  10 
  11 
  12 ### やったこと
  13 
  14 - 1度の関数呼び出しでframe fileから複数のchannelのデータを取り出す関数を用意した
  15 - betelgeuseでのテストは先々週行った(プロットはなしでデータを読み込んだだけ)
  16 	- (4) condorでfs=16Hzの4channelを24時間分読み込んだ => 1時間48分(メモリ使用量は94GB)
  17 	- (5) condorでfs=2048Hzの82channelを24時間分読み込んだ => 2時間32分(メモリ使用量は94GB)
  18 	- (6) condorでfs=16384Hzの4channelを24時間分読み込んだ => 2時間32分(メモリ使用量は94GB)
  19 - 山本くんの作成したROOTライブラリを借りて、データのプロットもするようにした
  20 - 計算機をbetelgeuseではなく、m31(主データ保管装置)で行うように変更した
  21 - frame fileを700ファイルくらい開いたところで毎回計算が強制終了される  
  22 	=> 今回作った関数がメモリーリークしていた、↑の計算でメモリ使用量が同じだったのはメモリーリークしていたから
  23 - メモリーリーク箇所を特定し、コードを修正
  24 - 作業ディレクトリ `~hirotaka.yuzurihara/work/0612_comm`
  25 	- `kgl_frame_plot`が実行ファイル
  26 	- `run_kgl_frame_plot.sh`がジョブを投下したりするシェルスクリプト
  27 	- `gene_html_for_psd_v6.sh`がグラフを一覧にするhtmlを作成するシェルスクリプト
  28 	- 解析するchannelを変更したいときは`data/mod_ch_20180621.txt`を修正すれば良い
  29 	
  30 ### 計算時間
  31 
  32 - 計算機はm31を使った(betelgeuseのグルーバルにROOTが入っていない、自分でインストールしたROOTでは上手くいかない・・・)
  33 - condorを使ってジョブを管理しているので、同時に計算が走るはずだが、なぜか10分程度の待ち時間が出る
  34 - ジョブはchannelのサンプリングレートごとに分けて行った
  35 	- fs=16Hz(4channel以下) : ~50分  
  36 		メモリ量
  37 	- fs=2048Hz(82channel以下) : ~1時間10分  
  38 		メモリ量
  39 	- fs=16384Hz(4channel以下) : 50分でデータ読み込み後にクラッシュする  
  40 		メモリ量
  41 
  42 - 計算時間は計算機m31を使っているのでデータ読み込みが早い
  43 - この分だとchannel数を2倍にしても大丈夫そう
  44 
  45 - fs=16384Hzの計算についてはまだ上手く行っていない
  46 - 原因を調べてるところ、gdbで見てみたが不明
  47 
  48 ```
  49 *** Break *** segmentation violation
  50 
  51 ===========================================================
  52 There was a crash.
  53 This is the entire stack trace of all threads:
  54 ===========================================================
  55 #0  0x00002aea7c3c0dbc in waitpid () from /usr/lib64/libc.so.6
  56 #1  0x00002aea7c343cc2 in do_system () from /usr/lib64/libc.so.6
  57 #2  0x00002aea785a4ef2 in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.12
  58 #3  0x00002aea785a786c in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib64/root/libCore.so.6.12
  59 #4  <signal handler called>
  60 #5  0x00002aea7c44e79d in __memcpy_ssse3_back () from /usr/lib64/libc.so.6
  61 #6  0x00002aea794634cd in TGraph::TGraph(int, double const*, double const*) () from /usr/lib64/root/libHist.so.6.12
  62 #7  0x000000000040800f in plot1D(canvasStatus*, unsigned int, double*, double*, double, double, double, double, std::string, std::string, std::string, unsigned short, uns\
  63 igned short) ()
  64 #8  0x0000000000408fd2 in plotTimeSeries(canvasStatus*, std::string, unsigned int, double, double*) ()
  65 #9  0x0000000000406656 in main ()
  66 ===========================================================
  67 
  68 
  69 The lines below might hint at the cause of the crash.
  70 You may get help by asking at the ROOT forum http://root.cern.ch/forum.
  71 Only if you are really convinced it is a bug in ROOT then please submit a
  72 report at http://root.cern.ch/bugs. Please post the ENTIRE stack trace
  73 from above as an attachment in addition to anything else
  74 that might help us fixing this issue.
  75 ===========================================================
  76 #5  0x00002aea7c44e79d in __memcpy_ssse3_back () from /usr/lib64/libc.so.6
  77 #6  0x00002aea794634cd in TGraph::TGraph(int, double const*, double const*) () from /usr/lib64/root/libHist.so.6.12
  78 #7  0x000000000040800f in plot1D(canvasStatus*, unsigned int, double*, double*, double, double, double, double, std::string, std::string, std::string, unsigned short, uns\
  79 igned short) ()
  80 #8  0x0000000000408fd2 in plotTimeSeries(canvasStatus*, std::string, unsigned int, double, double*) ()
  81 #9  0x0000000000406656 in main ()
  82 ===========================================================
  83 ```
  84 
  85 - 山本くんによる考察
  86 
  87 ```
  88 何となく (double*) で与えたデータ列を TGraph class(実態はTH1 class)に渡す時のコピー(memcpy)で転けている感じに見えますね。
  89 
  90 考えられそうなのは
  91 1. 単純に16384 * 86400がmemcpyで扱えるデータ量の限界を超えている(過去扱えた例があることを考えるとm31の設定？unlimitとか)
  92 2. データ読み出し時点でメモリ領域の末尾が壊れていて、memcpyなど実際にアクセスしようとした瞬間に落ちる
  93 3. (double*)の実際のデータ点数に比べてunsigned intで与えている値が大きい
  94 くらいですかね。
  95 
  96 (double*)とTGraphそれぞれに対してx軸y軸のデータ領域を確保するので1チャンネルあたり16384 * 86400 * 4 * 8Byte 〜 42GB程必要なんですよね。
  97 多チャンネルを同時に扱う場合、calloc, realloc, freeのタイミングを考える必要があるやもしれません。
  98 
  99 因みに16kHz x 1チャンネルとか12時間データでも落ちますか？
 100 ```
 101 
 102 - 後日調査した
 103 	- 16384Hz x 4channel, 12時間データでは落ちなかった
 104 	- 16384Hz x 1channel, 24時間データではエラーで落ちた
 105 	- 必要なメモリ量では`16384Hz x 4channel, 12時間データ`の方が多い  
 106 		=> エラー原因はメモリ量が不足しているからではなさそう
 107 
 108 ### htmlソースの作成
 109 
 110 - ディレクトリにある画像の名前から適した場所にペタペタ貼り付けるスクリプト
 111 - 前の日、次の日、トップページへのリンクを作成した
 112 	- Previous day, list of date, Next dayというボタン
 113 	- 同じchannelの場所に飛ぶようにidを用意した
 114 - 横澤さんが現場の方からコメントをもらってくれるそうなので、コメント待機中
 115 
 116 
 117 ### 今後のタスク
 118 
 119 - 時系列グラフのxlabelに開始JST時刻を書く
 120 	- 画像だけ伝達された場合にも意味がわかるようにする
 121 - スペクトル、スペクトログラムもグラフを書くようにする
 122 	- 将来的に佐々井さんのスペクトログラム関数で置き換える
 123 - htmlに図だけじゃなくてchannel名をわかるように書く => 現状はchannel名で検索できないが、これによってユーザーがchannel名で検索できる
 124 
 125 - 自分のコードを見直していて、frame fileがない時刻の例外処理をしていないことに気づいた
 126 - frame fileがすべてあるとは限らないので、欠損しているファイルの時刻はすべて0を代入してファイルがあるようにして解析する
 127 	- ファイルが欠損している場合、自分のコードがどうなるのか理解しておく
 128 	- frame fileが86400秒間ずっとあるかどうかを調べるようなスクリプトも用意する
 129 
 130 - 昔、灰野さんが見せてくれたhtmlソースにあるjavascriptを借りてきて活用できないか模索する
 131 	- 1晩考えたがページを見るのにクリックしていくのは不便だと思うので採用は見送る
 132 
 133 
 134 
 135 ## チャンネルリストの更新を調べる関数orコードの作成
 136 
 137 - daily summary ページのバグ取りで時間を取られて進んでいない
 138 - Frame libraryにchannelを一覧する関数があった
 139 
 140 
 141 ```
 142 /*---------------------------------------------------FrFileIGetChannelList--*/
 143 char *FrFileIGetChannelList(FrFile *iFile, int gtime)
 144 /*--------------------------------------------------------------------------*/
 145 /* This function allocate the space and returns the pointer to a string with
 146 the channel list and frequency information. The user should free the space.
 147 If gtime == 0, the channel list is return for the current file position or
 148 for the beginning of the file if no frame has been read                     */
 149 /*—————————————————————————————————————*/
 150 ```