1                                   DetChar MTG
   2                                   ===========
   3 
   4 Author: Yuzurihara <yuzurihara@Deneb-no-MacBook-Air.local>
   5 Date: 2014/11/11 11時12分17秒
   6 
   7 
   8 Table of Contents
   9 =================
  10 1 参加者
  11 2 announce
  12     2.1 チーフ会議からの報告
  13     2.2 aLOG
  14     2.3 来週以降の案内
  15 3 Daily
  16     3.1 Noise monitorの開発
  17     3.2 動的plot
  18     3.3 Haskellの並列化処理
  19     3.4 Noise modeling
  20 4 special topic
  21     4.1 Littenberg & Cornish arXiv:1410.3852の紹介
  22 
  23 1 参加者
  24 ~~~~~~~~
  25   端山, 山本, ゆずりはら, 上野, 宮本, 横澤, 間野, 西澤
  26   
  27 
  28 2 announce
  29 ~~~~~~~~~~
  30 
  31 2.1 チーフ会議からの報告
  32 ========================
  33    (端山)昨日(11/10)のチーフ会議でKAGRAの安全管理が議題にあがった
  34    以前あったKAGRA PABでも厳しいコメントをいただいた
  35 
  36    KAGRAの現状の安全を管理する組織図
  37    [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Meeting/Reviews/PAB?action=AttachFile&do=view&target=safety_organization_chart.pdf]
  38    
  39    サイトマネージャである大橋さんが現在の責任者
  40    何かあれば大橋さんとPIである梶田さんに連絡する(まだ確定はしていない)
  41    現地の人は作業を一度止めて、サイトマネージャーに連絡する
  42    
  43    KAGRA safety control officeの長は黒田さん
  44    これは安全管理のルールを作るところ
  45    しかし実質の責任者はサイトマネージャーの大橋さん(図参照)
  46 
  47    4ページ目は連絡網のようなもの(あくまでDRAFT)
  48    覚えておくべきは何かあったときはサイトマネージャーに連絡をする
  49 
  50    他にもヒヤリハットも議題にあがった
  51 
  52    Detcharメンバーが読んで理解すべきものはKAGRA安全マニュアル(まだ完成はしていない？)
  53    坑内に入る方は一読しておくこと
  54    
  55    ヒヤリハット : 事故にはいたらなかったが、ヒヤリやハッとしたこと
  56    ヘルメットのことではない
  57    KAGRA坑内では重機を使うことが多いので、気をつけるべき
  58 
  59 
  60 2.2 aLOG
  61 ========
  62    (間野) [https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15529]
  63    CBCの波形をハードウェアインジェクションに成功した
  64    インジェクションのための新しいソースコードを開発した
  65    8秒間隔のglitchをinjectionした
  66    8秒の終わり(glitchの切れ目)が原因で何か悪さをしているのではないか
  67    という疑いがあったが影響はなさそう
  68    (端山)これはバグと考えてよいか？
  69    (間野)おそらくそう
  70 
  71 
  72    (間野)crab killerの説明
  73    [https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15411]
  74    電源の消費量が急激に変化する時間にglitchが現れるのではないか、と思っていたが
  75    実際に調べてみると正午付近に集まっていた
  76    原因はまだ不明
  77        
  78 
  79 
  80 
  81 2.3 来週以降の案内
  82 ==================
  83    来週は阿久津さんがAOSのチャンネルリストをたたき台として持ってきてくれる
  84    どのようなチャンネルをモニターすべきなのかを議論する予定
  85 
  86    
  87    11/25(火)はPintoさんが来るので
  88    拡張detchar meetingを行う予定
  89    
  90 
  91    12/18(木)は日韓ワークショップの前日に富山で議論を行う予定
  92    端山, 長岡技大の高橋さんが参加する
  93    参加希望者は端山さんに連絡をすること
  94    
  95 
  96 3 Daily
  97 ~~~~~~~
  98 
  99 3.1 Noise monitorの開発
 100 =======================
 101    (横澤) あとで気づいたが、図2が間違っているかもしれない
 102    現在修正中
 103    [http://gwclio.icrr.u-tokyo.ac.jp/lcgtsubgroup/detectorcharacterization/2014/11/noise-monitor2.html]
 104 
 105 3.2 動的plot
 106 ============
 107    (山本) 現在の環境をアップデートして、動的plotができるかもしれない
 108    まだ可能性を模索中
 109    できそうなら、また記事にして報告する
 110 
 111 
 112 3.3 Haskellの並列化処理
 113 =======================
 114    repaを用いて、Haskellの並列化処理を行おうとしている
 115    特にFIRフィルターの並列化を考えているが、まだうまくいっていない
 116    githubにはまだアップロードしていない
 117 
 118    コードは再帰的に書かれている
 119    そのせいで並列化がうまくいかない -> 実行速度が早くならない
 120    [https://github.com/gw-analysis/detector-characterization/blob/master/attic/repa/fir_repa.hs]     
 121    Note これはかなり古いversion
 122 
 123 3.4 Noise modeling
 124 ==================
 125    現在進めているのは、student t分布とガウス分布の違いを解析に取り入れようと試みている
 126    1sigmaが2つの分布で異なるので、ノイズモニターから計算したそれらの数値を解析に組み込む
 127    まだ結果が出ていない...
 128 
 129 
 130    
 131 
 132 4 special topic
 133 ~~~~~~~~~~~~~~~
 134 
 135 4.1 Littenberg & Cornish arXiv:1410.3852の紹介
 136 ==============================================
 137    [http://arxiv.org/abs/1410.3852]
 138    (間野)
 139    cubic spline (narrow band, line付近以外) + コーシー(ローレンツ)分布(narrow band, ラインノイズ周辺)
 140    を使ってノイズパワースペクトルを推定をする
 141    
 142    以前の方法だと、推定の長時間のデータが必要
 143    10Hzまでの周波数のデータを解析したいときは~1000秒程度が必要
 144    
 145    図1 : 青線がdesign sensitivity 赤線が推定した値
 146    
 147    図2 : 16, 32, 64秒で推定を行った場合
 148 
 149    図3 : 64Hzのpower lineの周波数変動を見ている
 150    
 151    MCMCを使ってPSDを推定するためのposteriorを得る
 152    broad band noise と narrow band noise で推定方法を分ける
 153    2つのノイズモデルを使う2つのパラメーター(分布の次元が変わる)が必要
 154 
 155    解析の途中で,パラメーターの個数が変わるようなMCMCを行う
 156    そのためにはReversible Jump MCMC(RJMCMC)を使う
 157    M_i -> M_j
 158    (余分なランダムな変数を加えて、次元を一緒にする？) -> Dimension matching
 159    例(green 1995)
 160 
 161    Reversibility は Stationarity よりも強い要請
 162    
 163    (山本)パラメーターの個数が異なるが、計算自体はパラメーターの個数を同数にして行っているのか？
 164    (間野)そういう風にも理解できる
 165    (山本)では解析を始める前に、変数の上限値を決める必要があるのか？
 166    (間野)その通り
 167    
 168    図4 : 推定結果  1024秒(~17分)のデータの推定には1時間くらいかかった
 169    
 170    図5 : ホワイトニングすると、ガウス分布のtailが取り除かれていることがわかる
 171 
 172    (間野)全体的に負の方にずれていないか？ biasがあるのではないか？
 173 
 174    原理的にはsignalもfitしそうな気がするが、実際はそうではない
 175    
 176    (端山)計算リソースはどのようなものだったか？
 177    (間野)わからない 書いていない
 178 
 179    (端山)burst解析の場合、スペクトル推定をしてデータのホワイトニングを行う
 180    その際はリニアなfittingを行う
 181    代替手段があまりないので、それを用いているが
 182    このような新しい手法は計算時間的にオンライン解析は可能か？
 183    (間野)厳しそう
 184    この論文の趣旨は、長時間のデータの安定性を求めるのは厳しいということだろう
 185 
 186    (端山)あるデータの推定はきちんとできるが、別のデータでは厳しいとかはありえるか？
 187    (間野)推定時の安定性は低いかもしれない
 188    シャープにクリアに出ているラインノイズはきちんとフィッティングできているが
 189    そうではないようなラインノイズは厳しそう
 190    
 191    (譲原)データに実信号が入っていても、推定した結果は実信号に引っ張られないというのがわからない
 192    (間野)signalがないと思ってfittingを行う
 193    全データはノイズだと思って解析を行う
 194    modelの自由度が高いので...
 195 
 196    (山本)10回〜20回の平均を行って平均スペクトルを計算する
 197    その中に実信号が入っていた場合は平均スペクトルは引っ張られる
 198    その場合、事前にその時刻に実信号が入っていると判断する必要があるのではないか？
 199    (間野)running averageの場合はfitingする基準点がない
 200    こちらはmodel baseなので、modelという基準点をもとにlikelihoodを計算できる
 201