DetChar MTG =========== Author: Yuzurihara Date: 2014/11/11 11時12分17秒 Table of Contents ================= 1 参加者 2 announce 2.1 チーフ会議からの報告 2.2 aLOG 2.3 来週以降の案内 3 Daily 3.1 Noise monitorの開発 3.2 動的plot 3.3 Haskellの並列化処理 3.4 Noise modeling 4 special topic 4.1 Littenberg & Cornish arXiv:1410.3852の紹介 1 参加者 ~~~~~~~~ 端山, 山本, ゆずりはら, 上野, 宮本, 横澤, 間野, 西澤 2 announce ~~~~~~~~~~ 2.1 チーフ会議からの報告 ======================== (端山)昨日(11/10)のチーフ会議でKAGRAの安全管理が議題にあがった 以前あったKAGRA PABでも厳しいコメントをいただいた KAGRAの現状の安全を管理する組織図 [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Meeting/Reviews/PAB?action=AttachFile&do=view&target=safety_organization_chart.pdf] サイトマネージャである大橋さんが現在の責任者 何かあれば大橋さんとPIである梶田さんに連絡する(まだ確定はしていない) 現地の人は作業を一度止めて、サイトマネージャーに連絡する KAGRA safety control officeの長は黒田さん これは安全管理のルールを作るところ しかし実質の責任者はサイトマネージャーの大橋さん(図参照) 4ページ目は連絡網のようなもの(あくまでDRAFT) 覚えておくべきは何かあったときはサイトマネージャーに連絡をする 他にもヒヤリハットも議題にあがった Detcharメンバーが読んで理解すべきものはKAGRA安全マニュアル(まだ完成はしていない？) 坑内に入る方は一読しておくこと ヒヤリハット : 事故にはいたらなかったが、ヒヤリやハッとしたこと ヘルメットのことではない KAGRA坑内では重機を使うことが多いので、気をつけるべき 2.2 aLOG ======== (間野) [https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15529] CBCの波形をハードウェアインジェクションに成功した インジェクションのための新しいソースコードを開発した 8秒間隔のglitchをinjectionした 8秒の終わり(glitchの切れ目)が原因で何か悪さをしているのではないか という疑いがあったが影響はなさそう (端山)これはバグと考えてよいか？ (間野)おそらくそう (間野)crab killerの説明 [https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15411] 電源の消費量が急激に変化する時間にglitchが現れるのではないか、と思っていたが 実際に調べてみると正午付近に集まっていた 原因はまだ不明 2.3 来週以降の案内 ================== 来週は阿久津さんがAOSのチャンネルリストをたたき台として持ってきてくれる どのようなチャンネルをモニターすべきなのかを議論する予定 11/25(火)はPintoさんが来るので 拡張detchar meetingを行う予定 12/18(木)は日韓ワークショップの前日に富山で議論を行う予定 端山, 長岡技大の高橋さんが参加する 参加希望者は端山さんに連絡をすること 3 Daily ~~~~~~~ 3.1 Noise monitorの開発 ======================= (横澤) あとで気づいたが、図2が間違っているかもしれない 現在修正中 [http://gwclio.icrr.u-tokyo.ac.jp/lcgtsubgroup/detectorcharacterization/2014/11/noise-monitor2.html] 3.2 動的plot ============ (山本) 現在の環境をアップデートして、動的plotができるかもしれない まだ可能性を模索中 できそうなら、また記事にして報告する 3.3 Haskellの並列化処理 ======================= repaを用いて、Haskellの並列化処理を行おうとしている 特にFIRフィルターの並列化を考えているが、まだうまくいっていない githubにはまだアップロードしていない コードは再帰的に書かれている そのせいで並列化がうまくいかない -> 実行速度が早くならない [https://github.com/gw-analysis/detector-characterization/blob/master/attic/repa/fir_repa.hs] Note これはかなり古いversion 3.4 Noise modeling ================== 現在進めているのは、student t分布とガウス分布の違いを解析に取り入れようと試みている 1sigmaが2つの分布で異なるので、ノイズモニターから計算したそれらの数値を解析に組み込む まだ結果が出ていない... 4 special topic ~~~~~~~~~~~~~~~ 4.1 Littenberg & Cornish arXiv:1410.3852の紹介 ============================================== [http://arxiv.org/abs/1410.3852] (間野) cubic spline (narrow band, line付近以外) + コーシー(ローレンツ)分布(narrow band, ラインノイズ周辺) を使ってノイズパワースペクトルを推定をする 以前の方法だと、推定の長時間のデータが必要 10Hzまでの周波数のデータを解析したいときは~1000秒程度が必要 図1 : 青線がdesign sensitivity 赤線が推定した値 図2 : 16, 32, 64秒で推定を行った場合 図3 : 64Hzのpower lineの周波数変動を見ている MCMCを使ってPSDを推定するためのposteriorを得る broad band noise と narrow band noise で推定方法を分ける 2つのノイズモデルを使う2つのパラメーター(分布の次元が変わる)が必要 解析の途中で,パラメーターの個数が変わるようなMCMCを行う そのためにはReversible Jump MCMC(RJMCMC)を使う M_i -> M_j (余分なランダムな変数を加えて、次元を一緒にする？) -> Dimension matching 例(green 1995) Reversibility は Stationarity よりも強い要請 (山本)パラメーターの個数が異なるが、計算自体はパラメーターの個数を同数にして行っているのか？ (間野)そういう風にも理解できる (山本)では解析を始める前に、変数の上限値を決める必要があるのか？ (間野)その通り 図4 : 推定結果 1024秒(~17分)のデータの推定には1時間くらいかかった 図5 : ホワイトニングすると、ガウス分布のtailが取り除かれていることがわかる (間野)全体的に負の方にずれていないか？ biasがあるのではないか？ 原理的にはsignalもfitしそうな気がするが、実際はそうではない (端山)計算リソースはどのようなものだったか？ (間野)わからない 書いていない (端山)burst解析の場合、スペクトル推定をしてデータのホワイトニングを行う その際はリニアなfittingを行う 代替手段があまりないので、それを用いているが このような新しい手法は計算時間的にオンライン解析は可能か？ (間野)厳しそう この論文の趣旨は、長時間のデータの安定性を求めるのは厳しいということだろう (端山)あるデータの推定はきちんとできるが、別のデータでは厳しいとかはありえるか？ (間野)推定時の安定性は低いかもしれない シャープにクリアに出ているラインノイズはきちんとフィッティングできているが そうではないようなラインノイズは厳しそう (譲原)データに実信号が入っていても、推定した結果は実信号に引っ張られないというのがわからない (間野)signalがないと思ってfittingを行う 全データはノイズだと思って解析を行う modelの自由度が高いので... (山本)10回〜20回の平均を行って平均スペクトルを計算する その中に実信号が入っていた場合は平均スペクトルは引っ張られる その場合、事前にその時刻に実信号が入っていると判断する必要があるのではないか？ (間野)running averageの場合はfitingする基準点がない こちらはmodel baseなので、modelという基準点をもとにlikelihoodを計算できる