1 2013 May 28 10:00 Detchar Meeting
   2 端山、譲原、山本、宗宮、関口、伊藤
   3 
   4 アジェンダ
   5 |Announce
   6 |• ６月１０日、１１日 第４回Japan-Korea workshopでのKorea detcharグループとの議論について。
   7 [端山説明]
   8 現在進行中の共同研究トピック（添付資料参照）大きくわけて４つある。
   9 (1) 韓国側がやりたいと言っているevent detection pipeline(韓国側がメインのプロジェクト)
  10 ・多チャンネル解析によるイベント解析とそれによるCBCイベントのVetoを考えている。
  11 ・補助チャンネル解析のためのglitch探索パイプライン( = バースト探索の単一検出器版)
  12 を新規開発したい意向。
  13 (2) future selection statistics（韓国）
  14 ・データから情報を要約する統計量の研究
  15 ・彼らはt or z-statisticsと読んでいるが、何を使っているのか不明。
  16 (3) 雑音ともっとも相関しているチャンネルを探す。（日本）
  17 ・noise classificationと呼ばれる分野。
  18 ・多チャンネル解析によってノイズ源を特定する。
  19 (4) 以上の手法でCLIO Hardware Injectionを、データのみから検出できるかどうかを調べる。
  20 (5) 他に、LVCデータを用いて、LVCでノイズと分かっているイベントを検出できるかどうかを
  21 テストする。
  22  
  23 日韓ワークショップ中のdetchar ミニワークショップ
  24 今のところ１０日１３：００−１５：００開催の予定だが、変更の可能性あり。
  25 韓国側がHHTを用いて、山本君が作ったCLIO h(t)データを解析した結果を韓国側が示す。
  26 韓国側が、以前LVCで使われていたKWトリガーと、今回のHHTトリガーのパフォーマンス比較を話すとのこと。
  27 ただし、LVCではKWはすでに使われていない。Omicron( = Omegaの高速バージョン)が使われている。
  28  
  29 |Special Topic
  30 |• LVCのメジャーライブラリへのKAGRA detcharび主体的貢献の可能性の検討(Haskellスタディ)（山本、端山）
  31 [端山説明]
  32 ・現在検討段階の事項。KとLVCでデータ共有された段階のことを考える。
  33 ・メインで利用されるであろう解析ソフトはLALだろう。
  34 ・日本からの貢献がまったく無い状況で共同研究をすすめるのは避けたい。
  35 ・detcharとして貢献できるのは何か？
  36 ・スクリプト(Matlab, Python-PyLAL, ...)に対するLALラッパーの開発で貢献するのはどうか検討する。
  37 ・LALが利用しているソフトウェアについては、端山資料参照。
  38 ・Detcharに関係するのは、DMT( 資料２ページ目だとエンドユーザーソフトウェア )
  39 ・ラッパーを通してC, C++ライブラリをMatlab/Pythonなどから利用するケースが非常に多い。
  40 ・SWIG：ラッパーを構築するソフトウェア
  41 http://www.swig.org/
  42  
  43 ・Haskellへのラッパーはどうか検討中。
  44 ・京大の村主さんがHaskellのエキスパートで、興味を持ってくれている。
  45 ・柴田大研究室とCBCテンプレートのHaskellによる実装について研究している。
  46 ・大阪市立大でHaskell勉強会をしている。以下山本成果報告。
  47  
  48 [山本報告]
  49 ・Haskellの特徴：純粋な関数型言語
  50  
  51 [端山]
  52 他人が書いたHaskellは読みやすいのか？
  53  
  54 [山本]
  55 CやC++よりも、簡潔に書けるので、読みやすい。
  56  
  57 [端山]
  58 Haskellでないとできないこと、実装が大変なこと、ソフトウェアとして実装しにくいものが
  59 あると良い。
  60  
  61 [端山]
  62 遅延評価とは何？
  63  
  64 [山本]
  65 計算が必要になったときに初めてその評価をおこなう。
  66 すべてのデータを常に評価するわけではない。計算量の低減ができると期待している。
  67  
  68 [伊藤]
  69 ・lispとの違い。
  70 ・Haskellのユーザー数と将来性。
  71 ・遅延評価は、Mathematicaでもできるが、何が違うのか？
  72 ・将来重力波データ解析も大量のデータを扱う。
  73 大量のデータを効率的に処理する機構があるのか？
  74  
  75 [端山]
  76 ・lispよりも速い。（Cの１〜1/3倍程度の速さ）
  77 ・将来性は不明。
  78 ・Haskellにどれくらいマンパワーを割くかも含めてまだ検討段階。
  79  
  80  
  81 |• バイオリンモードスタディ（端山）
  82 [端山]資料提示、現状説明：
  83 ・それほど進展は無し。
  84 ・関口が以前計算した感度曲線（緑）は、100Hz以下がviolin modeで支配されてしまう。
  85 ・これは関口の以前のパラメータと宗宮のパラメータの相違による。
  86 ・関口がQを3x10^5にしたときに計算してくれたのが赤い線。
  87 ・鏡の大きさが宗宮オフィシャルよりも少し小さくなった影響が残る。
  88 ・パワーを下げることはしていない。
  89  
  90 [宗宮]
  91 宗宮が
  92 やったのは、鏡の大きさが少し小さくなってパワーを下げること。
  93 加えてコーティングロス、タングステンのロスなど何点か変更している。
  94 それで230Mpcぐらいで、CQGに発表しているもの。
  95 パワーを下げないと240Mpcぐらいになる。
  96 宗宮・関口の計算している感度は、
  97 今はパワー250で計算している。400までできるが、山元さんのところでどれくらい
  98 冷やせるかによる。400なら240Mpcまでいける。
  99  
 100 [端山]
 101 宗宮からもらったMatlabスクリプトをそのまま使って
 102 鏡を小さくするだけでよいのか？
 103  
 104 [宗宮]
 105 今はそれで良いが、新しいものができたら送る。
 106  
 107 [端山]
 108 関口が当初計算したviolin modeが4 ~ 16に分裂する話。
 109  
 110  
 111 [関口]
 112 通常の半分のテンションの場合、通常の２倍テンションがかかった場合で計算した。
 113 100数十Hz - 260Hzぐらいまで分裂する。
 114 １つ１つ分裂を計算するのは大変なので、ピークをフィッティングしてもらって、ピークの取りうる範囲内で
 115 適当に分裂させてもらった。
 116  
 117 [宗宮]
 118 赤い１本と、分裂した青いライン１本の振幅の関係は良いのか。
 119  
 120 [端山]
 121 ４本に分裂した場合、４分の１にしている。
 122  
 123 [端山]
 124 １６分裂すると、関口に許された範囲で適当にパラメータを振ってもS/Nは
 125 あまり変わらない。219Mpcぐらい。
 126  
 127 [宗宮]
 128 110Hzの縦振動変わらない？
 129  
 130 [関口]
 131 あまり変わらない。
 132 ファイバーの太さにばらつきがある場合に変わるが、現状ファイバーの太さなどは分からない。
 133  
 134 [端山]
 135 100Hz - 300 Hzのviolin modeはバーストに影響を与える。
 136 感度曲線と超新星爆発の特徴的周波数（数値計算結果）を示した資料提示。
 137  
 138 [関口]
 139 超新星爆発ということはバーストに近いもの。
 140 ブロードバンドなのでは？
 141  
 142 [端山]
 143 特徴周波数を示している。
 144 検出のときに一番影響を受ける周波数を示している。
 145 リコイルマスのQ値がどんな値になっているのかが心配。
 146  
 147 [宗宮]
 148 １６本分裂は非常に最悪のケースだと思われる。
 149 ４本分裂ですでにあまりないのではないか？
 150 分裂しても、４本の周波数は関口計算よりも近いところに
 151 分布するのではないか？
 152  
 153 [関口]
 154 ワイヤーがものすごく硬いのでワイヤーの長さを数ミクロンであわせないと
 155 周波数空間でかなり広がる可能性がある。現在の技術では、関口計算結果ぐらいは広がりうる。
 156  
 157 [端山]
 158 １６本はありうるのか？
 159  
 160 [関口]
 161 ありうる。
 162  
 163 [宗宮]
 164 問題提起すべきである。
 165 縦バネなど、解決策は考えられるはず。
 166  
 167 [関口]
 168 縦バネを入れることで改善する可能性ある。
 169  
 170 [宗宮]
 171 縦バネを入れることができない場合のことを考えて、
 172 ２本吊りも検討されているが、どうか？
 173  
 174 [関口]
 175 ２本吊りだと、ピッチのコントロールをすべてテストマスでやらなくては
 176 ならなくて、テストマス上のアクチュエータですべてやる必要がある。
 177 アクチュエータのパワーを考えると難しいのでは。コントロールがやっかい。
 178  
 179 [宗宮]
 180 分裂だけで見ると、２本吊りの方が良いのではないか？
 181  
 182 (以下議論)
 183