DetChar MTG =========== Author: Yuzurihara Date: 2014/10/21 11時25分38秒 Table of Contents ================= 1 参加者 2 announce 2.1 aLOG 2.2 Interesting papers 3 daily work 4 special topics 4.1 MBLT 4.2 NHA 4.3 SRMon/RayleighMon 4.4 Correlation Monitor 4.5 間野 4.6 提案 1 参加者 ~~~~~~~~ 端山, 山本, ゆずりはら, 上野, 浅野, 間野, 宮本, 横澤, 間野 2 announce ~~~~~~~~~~ 来週のDetchar MTGは端山さんが神岡にいるためキャンセル 神岡に行く理由は、磁場測定の下見のため 磁場測定は去年の今頃にも行われたが、そのときは装置の雑音によってlimitされ、 神岡の磁場にupper limitを設定するにとどまった 今回はもっと感度のよい装置を用いて測定を行う、そのための下見を行う KAGRA PABが10/31, 11/1に富山大学で行われる 2.1 aLOG ======== (山本) [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DET/Meet/Agenda201401021?action=AttachFile&do=view&target=141021_aLog.pdf] DetCharとしての更新は滞っている 10/15にメキシコで地震があったが影響なし 2.2 Interesting papers ====================== (端山) [http://arxiv.org/abs/1410.3852] [http://arxiv.org/abs/1410.3835] 彼らの以前やっていた研究は LISAで連星合体からの重力波が逆にノイズになる -> Binary Confusion Noise それをsubtractして引き抜く この研究によりMCMCが重力波業界で有意義だと認識され始める LISAプロジェクトからNSAAが撤退したことにより、彼らはLIGOに合流した 今回の論文ではBayse統計を用いた 2. BayseLine spectrum推定 -> LINEの特定について 間野さんにレビューしてもらう 1. BayseWave 重力波と検出器雑音を区別する方法を提案 Bayse統計を使っている 現状、非常に時間がかかるため全天探査は無理だが、 parameter estimationに用いられるだろう 端山さんがレビューを行う 3 daily work ~~~~~~~~~~~~~~ HsaKAL開発状況 (端山) filter周りを並列化しようとしている 計算時間の削減をしようとしている (山本)自分でスレッドの振り分けなどができるのか？ (端山)可能、それをしないと使えるリソースを最大限利用しようとする (端山)REPAというパッケージを用いている サンプルコードはGitHUBのatticに置いてある 関数名の一部をs -> pで並列化できる・・・・が、簡単ではなかった 4 special topics ~~~~~~~~~~~~~~~~ 各モニターの計算コストの再見積もり 4.1 MBLT ======== (浅野) [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DET/Meet/Agenda201401021?action=AttachFile&do=view&target=computationCost_asano.txt] 4kHz 100秒分のデータを解析するのに、MacBook airを用いて約25秒 1本のラインについて解析するのに、 (山本) 100本のラインがあると100倍かかる？ (浅野) おそらくもっと早くなるだろう (端山) 情報が不足している ラインが5本あるときで計算すれば良いだろう 非常に計算時間が早いだろうという印象 (横澤)Q値依存性はないのか？ (横澤)一番計算時間がかかるものを1度やれば良い (浅野) IOをのぞくと20秒程度 (端山)周波数を分けて重力波探索が行われるだろう 20Hz~2kHzの間にいくつラインがあるのか？ 100本抜くことを目標にして再計算してみて 4.2 NHA ======= (上野) [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DET/Meet/Agenda201401021?action=AttachFile&do=view&target=ueno-detchar141021.pdf] NHAの説明 FFTをして、周波数のあたりを付ける コストファンクションを最小化するようにデータをcos関数でfittingする たとえばラインについてfocusするともっと計算時間を早くできる 400Hzならサンプリングレートを落とし、シフトする数も多くできる そうすると2分のデータを2分で解析できた (CPU 32コアの計算機で) 電源によるラインノイズ(60Hz)はしょっちゅう飛ぶので NHAで追うのは意味があるだろう 4.3 SRMon/RayleighMon ===================== (山本) [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DET/Meet/Agenda201401021?action=AttachFile&do=view&target=141014_DCMTG_yama.pdf] 見積もりよりも多く時間がかかっている 4000秒の解析は1200秒で終わる 見積もりでは、1秒あたり2^21の計算を行う (~2MHz) 4.4 Correlation Monitor ======================= (譲原) [http://gwwiki.icrr.u-tokyo.ac.jp/JGWwiki/KAGRA/Subgroups/DET/Meet/Agenda201401021?action=AttachFile&do=view&target=yuzurihara_result_measure_v3.txt] (端山) 式にしてほしい 現状 32秒のデータを2channel解析するのに、3.7秒かかっている 4.5 間野 ======== クラスターマシンの仕様 4core * 8 =32core 2.8GHz Xeon E5-2680 cash 4Gb shared memory 32Gb, HDD 5Tb MCMC(nonparametric Bayesian clustering 26139個のglitch) 1000loop 40sec * 50 parameterの計算だと2000secかかる 32coreだと1.04minかかる (端山)以前のVirgoの観測だとglitchの出現率は1秒あたり~1個 今回の計算にかかった時間をそれに焼き直すと 3時間のデータを1分で解析可能ということになる (端山)64core欲しい Virgoのdetcharマシンだと64core 今、我々が持っているのは20core 4.6 提案 ======== (横澤) さまざまなモニターで16秒のデータを1秒ずつに区切ってFFTをしている 事前にこれをやっておくという手はないか？ Detcharではデータが流れてくるものを加工してFrameとしてパッキングする そこに1秒ずつにSFTしてパッキングしたchannelを作っておく