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