bunch/train 192 2820

Calorimeter for Warm/Cold LC
2004/05/19 KEK
GLCCAL meeting
K. Kawagoe / Kobe-U
#bunch/train 192 2820
東北大山本さんのコメント(4/7)


Calorimeter の積分時間が300nsほどなら、coldは他の
バンチからのbackgroundを受けませんが（自分自身の
み）warmだと200バンチからのヒットが入ってきます。バ
ンチ当たりのbackgroundがluminosityに比例すると考え
るとcoldはwarmの３倍で、最終的にwarmはcoldの70倍
のnoise hitを受けることになります。
藤井（Y）さんによれば、barrelではそれでもまったく問題
はないとのことですが、end-capでは問題になるか知れ
ませんし、barrelもしっかりMC studyをしておく必要があ
ります。
藤井さんからの補足(4/7)


『藤井（Y）によれば「barrelではそれでもまっ
たく問題はない」』の前提は300nsの積分で
はありません。お茶部屋で検討した時の内
容は、「最近の早い光検出器を用いれば数
十ｎｓのゲート幅での積分は可能であって、
この場合はオーバーラップは殆ど問題にな
らないだろう」ということです。
むろんこの場合でもsimulationによる
validationが不可欠です。
竹下さんからのコメント (4/7)

学会でも杉本さんに質問をうけましたが、カロリメータとしての問題点
を整理しようとおもいます。

calorimeterとしては、衝突点からはなれており、beam beam
backgroundは違いはないだろう。

一番大きな問題は1.4ns (warm)と337ns(cold)というbunch
separation。

とすればカロリメータ−は1.4nsのbunchを区別できるかが問題。

もしsilicon/Wの場合はどうでしょうか？ 杉本さん？？？

シンチーdetectorなら実証はしていませんが、できるし、問題は少
ないとおもいます。

また RPCでも測定器自体は速いのでエレキの実装さえすればで
きると思います。

シリコンーecalの難しさが、今イチ解らないので、ご指摘をおねが
いします。
来週の予定


5/25 (Tue.) ITRP Open session
5/26 (Wed.) GLC detector meeting

Download Report