1 ・Daily summaryですが、
   2 　・指定のチャンネルに対し等しく各種処理を施しているように見えるが、これだと必要な情報にアクセスしにくい。
   3   とくに今後干渉計の方まで進出していくとチャンネル数が雪だるま式に増えていき、どこをどう見ればいいのか
   4 　　分からなくなってくると思われる。
   5 
   6 　・Summaryには
   7 	・動作状況の確認　=> 所定条件によってON/OFFを確認、duty比の算出など
   8 	・ドリフト => 低レートの信号の時系列表示
   9 	・雑音状況の確認 => スペクトル、非定常性など。時系列はあまり情報を運ばない
  10 　　などの機能があるので、ある程度用途に応じて複数のテンプレートを用意するか、コンフィギュレーションを
  11 　　かなり自由度の高い物にするかなどの工夫がいるのではないか。また似た信号のグルーピングなどはIOO内
  12 　　でも必要になってくる。
  13 
  14 　・スペクトルの計算は測定の全時間域に適用しても仕方がない。LIGOのsummary pagesでは"State"という
  15 　　条件付け（あるチャンネルがこの条件を満たすと"Locked"など）を施して、各State内のみで計算した
  16 　　スペクトルを表示させることができる。これにより、unlock時などのぐちゃぐちゃになったスペクトルを
  17 　　除外することなどが可能となる。
  18 
  19 　・現在は各チャンネルのプロットが独立して生成されているように見えるが、ものによっては複数チャンネルの
  20 　　時系列やスペクトルを同時に表示したい、という要望があるので、それをどう実現するか。
  21 
  22 　・似たような話で、「静かなとき」や「ベスト感度」などのリファレンスと現在値を比べたかったりする。
  23 　　どう実装するか？
  24 
  25 　・信号によってはホワイトニングの補正などのキャリブレーションが必要。
  26 
  27 　・これらの作業は干渉計ユーザーレベルの細かい知識を必要とする。一律では適用できない。
  28 　　=> 干渉計屋の要望を逐一聞いてそれを実現するか
  29      干渉計屋でも設定できるように簡便なインターフェースを用意するか
  30      DetCharでsensibleな情報を出せるように干渉計の勉強をするか
  31 
  32 ・Web tool
  33  ・Single channel analysis
  34 　　上でsummary channelについて言ったことと似た話：キャリブレーション、プロットの重ね書き、リファレンス、など
  35 　・一応言っておくと、時系列・スペクトルに関してはdataviewerやDTT (コマンド名diaggui)の方がinteractiveで使いやすい。
  36 　・相関解析についてはまあ、あまり言うことはない。コヒーレンスから推定されたAチャンネルへのBチャンネルの寄与(もしくは定義が逆か？)
  37 　　を表示してはどうか。チャンネルリストをテキストファイルから指定、もしくはテキストボックスにコピーペーストできると良いかも。
  38 　・相関Map。周波数域を指定できたりするのは良い。チャンネル指定法については上記のとおり。試しにやったらNaNが
  39 　　表示される行・列があったけどなんでだろう。
  40 　・Brucoの有用性の一つに、source->targetの相関を調べた後、そのコヒーレンスに応じて、targetのスペクトルの
  41 　　どれくらいにsourceからのノイズが寄与しているかを推定する機能がある。いわば擬似的な伝達関数推定。
  42 　　この機能はあった方がいい。
  43 
  44 
  45 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
  46 ・Gabrieleが以前デモンストレートしてくれたのだが：
  47 　ある信号の非定常性の原因推定。その信号のband limited RMSの時系列を、各種アラインメント誤差信号（たとえば光てこの信号）
  48 　でフィッティング(線形？二次？)して、どのミラーの角度揺れが非定常性に寄与しているかを求める。
  49 
  50 以下はLIGOでアイデアは出されているがまだ実現されていない機能
  51 ・Plotlyなどを使えばインタラクティブなプロットを作ることができる。これをSummary Pageに埋め込むと
  52 　ものすごく便利だと思うが。
  53 
  54 どこが具体的にどう、ということではないのだが：
  55 ツールはマインドを実現する物であって、ツールがマインドを作ることはあまりない。
  56 つまり、ユーザーが何をしたいかを把握して、それをどう実現してあげられるかを考えて実装することが
  57 重要で、しかもその要望は開発のステージが変わって行くに従って変化していくので、実際問題として
  58 開発やコミッショニングをしている横に行って彼らが何を必要としているかを把握して、実現する
  59 ということを延々とし続ける、という努力が必要になってくるんだろうと思う。
  60 
  61 detcharのもう一つの重要な仕事として、PEM injectionの仕事がある。ツールを作るだけではなく
  62 実際に地面振動や音響振動や、磁場変動などを干渉計に注入し、これが所望の信号にどれくらいでるか、
  63 を相関解析で
  64 日本ではこの手の仕事をシステマティックに行った実績がないので、~Mpcのレンジを出そうと思うと
  65 必要になってくるでしょう。IMCで十分に訓練を積んで、bKAGRAが部分的にでも動き出したら、
  66 すぐに仕事に取りかかれるようにしておいた方がいいと思います。注入のためのハードウェアと
  67 センサー類が各種必要になってくるでしょう。
  68 
  69 とりあえず、こんなところかと思います。
  70 
  71 新井