1 # コミッショニングツールワーキンググループ
   2 2018/6/18 13:15-14:00  
   3 参加者：
   4 苔山，横澤，山本尚弘，佐々井，神田，伊藤，譲原，田越，大原，坂井，  
   5 記録：田越
   6 
   7 ## 進捗状況
   8 
   9 #### タスク
  10 
  11 - PythonからFrameデータを呼び出す(C)：大原，田越，神田，=> 未着手
  12    - 複数のCHを一度のファイルオープンで出来るほうが良い．
  13    - LIGOはFrameライブラリは使っていない．framecppを使っている．
  14 - Frameデータ　チャンネル一覧(KAGALI,Python)：FrChannelsを書き換え．譲原 
  15    - (譲原)FrChannelsを調べた．
  16    - (田越)kagaliappsにFrChannsle相当のプログラムを用意して欲しい
  17    - その他詳細は付録に記載
  18    
  19 - 時間指定をしてファイルを開くツール：田越 
  20    - 田越：主データ装置にインストールした，time\_to\_framedump.py, time\_to\_plotasd.pyでの実装方法について解説 (/usr/local/binにある)
  21      - pythonのargparseはコマンドライン引数の取り扱いに有用．
  22      - 時刻変換はLIGOtoolsにあるtconvertを使っている．非常に有用．シェルスクリプトなのでどこでも動く．
  23      - Frameデータの読み込みはlalframeのfrreadを使っている．
  24    - 今回の進展は無し．
  25 - 長期の時系列(Python)：佐々井 
  26    - histgram : pythonを勉強しながら進めている．乱数を振ってヒストグラムを書く．
  27    - betelgeuse, taurusで動かない．モジュールが入っていない．pygtk?  
  28    - rootでもモジュールがなくて出来ない．
  29 - 時系列のヒストグラム(Python)：佐々井 => 未着手
  30 - detrend(トレンド補正)(C)：大原  
  31   - 大原：Python, Matlabを調査した    
  32     - これらを参考に早急に作成する  
  33     - HHTのような新しい方法も作れるかも知れない．(研究テーマになる)   
  34   - 大原：pythonと同じものをCで作った． git へはまだ． 
  35 - window function(C)：大原  
  36   - 大原：トレンド補正の後にやる．
  37   - まだ．
  38 - high pass, low pass filter, band pass, band stop filter(C)，filtfilt(C)：坂井，大原  
  39   - 坂井：大原さん，酒井君がつくったものを発展させていく．  
  40   - 坂井：大原さんのコードを読んでいる．これらを改良してKAGALIに入れる．  
  41 - スペクトログラム(C,...)：佐々井 => 未着手
  42 - コヒーレンス(２つの信号のクロススペクトラム)(C,Python)：議論無し  
  43 - 1つのCHと多数のCHとのコヒーレンス(C,Python)：議論無し  
  44 - LIGO でやってるiDQのようなこともいずれする必要があるか． 
  45     - iDQ:多変量解析  
  46         - 伊藤：韓国Gがやっているらしい(John Ohと話をする)   
  47 
  48 #### GUI ツール  
  49 - 田越：PythonによるGUIツールを調べている．GWpyも調べる．  
  50 - 山本：三代君がGWpyで遊んでいる．GWpyを使ったツールがあれば，神岡で使える．  
  51 - 山本：GWpyは表示が速い．読み出し速度の問題解決に有効そうである．
  52 
  53 
  54 #### その他
  55 - 横澤：チャンネル名とその内容の説明のリストを作っている．
  56   - ８割方完成．phase-1の高サンプリングレートCHは完了．
  57   - PEM CHのリストアップをしている．イメージが固まった．
  58 - 山本：譲原　daily summary
  59   - 付録参照
  60 
  61 ## 次回
  62 2018年6月26日 12:15 - 13:00 (コミッショニング会議終了後)  
  63 
  64 ## 付録
  65 
  66 #### Frameデータ　チャンネル一覧(KAGALI,Python)：FrChannelsを書き換え(譲原)
  67 
  68    - ソースコードを読んだ (libframe-8.30/src/FrChannels.c)
  69    - 基本的にframe fileのなかにあるchannelでループを回して、channel名とサンプリングレートを出力している
  70    - FrChannelsコマンドと同じようなことをする関数を作りたい
  71    - KAGALI関数にしたときの引数の構想
  72 
  73 ```
  74 kglstatus status,
  75 int nChannels, 
  76 char cChannels[200][200],
  77 int *fs
  78 ```
  79 
  80    - みたいな感じか？
  81    - この引数だとチャンネル名が入る配列の個数を200個までと最初から決め打ちしているが，
  82 今のframe fileには20000くらいチャンネルがある
  83 1度ファイルを開いて、何チャンネルあるか調べないと配列の動的確保ができないのでどうしたらいいか思案中
  84    - そもそもこの関数の目的は、1ヶ月のスパンでchannel名の変動が知りたいということだと認識しているが正しいか？
  85    - => (横澤) 正しい
  86    - (田越) kagaliappsにFrChannsle相当のプログラムを用意して欲しい
  87 
  88 #### サマリーページ(譲原)
  89 
  90 今回やったこと
  91 
  92 - KAGALIに新しい関数を追加した．1つのframe fileを開いて複数のchannel名を与えると多次元配列にその結果を代入して返す．多次元配列の要素数は nChannel x (fs_max * duration)、最大サンプリングレートで制限される．
  93 - 実際にこの関数を動かすときは異なるfsで実行すると確保する配列に無駄ができてしまう．ちなみに90channelの内訳は16384Hzは4channel、2048Hzは82channel、16Hzが4channelなので16384Hzに合わせるとほとんどの配列の中身が無駄．
  94 - このKAGALI関数を使ってbetelgeuseで動作テストをした．やったことは1つのKAGALI関数でframe fileから複数のchannelを読み込むだけ(データの書き出しやプロットはまだなし、将来的にROOTのプロットを使うことにするのでデータ書き出しはしない)
  95 
  96 
  97 実行時間まとめ
  98 
  99 1. 90channelを1時間分読み込んだ(condorなし、betelgeuseでコンパイル) => 7分  
 100 2. 90channelを1時間分読み込んだ(condorなし、polluxでコンパイル) => 4分
 101 　=> 概算すると24時間データを読み込むのに312分かかる(まぁ許容範囲か？)
 102 　=> あとbetelgesuse, polluxどちらでコンパイルするかで計算時間が割と変わる、以下はすべてpolluxでコンパイルした
 103 3. condorでfs=16Hzの4channelを1時間分読み込んだ => 7分14秒(メモリ使用量は34GB)
 104 4. condorでfs=16Hzの4channelを24時間分読み込んだ => 1時間48分(メモリ使用量は94GB)
 105 5. condorでfs=2048Hzの82channelを24時間分読み込んだ => 2時間32分(メモリ使用量は94GB)
 106 6. condorでfs=16384Hzの4channelを24時間分読み込んだ => 今走らせてます
 107 
 108 一番メモリ容量を食う計算が(5)のパターンだと思うので、メモリ量的には動きそう
 109 
 110 使用したコードはbetelgeuseの ~yuzurihara/work/0612_comm/ にある．
 111 使用した関数は  
 112 kagali/kglcommon/frame/src/KGLFrameMultiIO.c
 113 にあるKGLGetMultiParameterOfFrameFile()とKGLReadFrameMultiData()  
 114 
 115 
 116 次の課題
 117 
 118 - 上記のKAGALI関数の引数でchannel名が入った配列を渡す方法が怪しい
 119 　=> まさかの文字列配列のポインターと文字列配列の配列の違いを理解できていないことが判明．
 120 　現在勉強中なので将来的に文字列配列のポインターになると思います．
 121 　今は固定長の文字列配列で代用してます．
 122 - 山本くんのROOTプロットコードを触る．
 123 - サマリーツールに取り込む．