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