ATLAS検出器の講義 Trigger DAQ • TriggerとDAQの一般論 • LHC実験のTrigger/DAQ • LVL 1トリガー • HLT K. Tokushuku KEK 徳宿 克夫 1
トリガー・DAQ： 簡単なシステム S 1 S 2 トリガー信号 不感時間 Trigger: 数多くの測定器情報から 作る、１ Bit情報＋タイミング情報 （「今来たイベントを取れ」という 信号） Deadtime: 多くのシステムでは、 一つのトリガーが入るとその処理の 間、次が受付けられないので、 しばらくトリガーを止める必要がある。 K. Tokushuku LHC実験のトリガー・DAQも基本は同じ 2
違いは、 トリガーのレートと読み出す チャンネルの量 Trigger decisionの前に次の衝突が起こる → パイプライントリガー LHC: pp反応レート → 1 GHz バンチ交差間隔 25 n. S → 40 MHz ： ヒッグス生成頻度 → 0. 1 Hz 測定器の読出しチャンネル Liq CAL ～ 10 k チャンネル ミューオン ～１ M チャンネル ATLASのデータサイズ：～１. 5 MB 低いS/N → マルチレベルトリガー K. Tokushuku トリガーレートをどう設定するかは 物理とお金による。 例えば、全部シグナルで、 Operation cost >> Storage cost なら、すべて取るという解もある。 3 (1. 5 MBx 40 MHzならDVD 15000枚/秒)
K. Tokushuku 4
p Pipeline Trigger 0 m. S ZEUSの場合 96 ns Component A readout Detector e TOF+Detector response 96 n. S clock Readout Electronics Trigger 4. 6 m. S+prop. delay Component Z <2. 6 m. S Timing GFLT 4. 6 m. S HERA clock K. Tokushuku ZEUS FLT • Synchronous pipeline system 5 • Deadtime-free trigger
ZEUS DAQ The main trigger comes from proton-beam related background. • spp >> sep • bad vacuum (activated by synchrotron radiation) bunch crossing rate : 10. 41 MHz ( 96 n. S) It is not possible to make a trigger decision of a crossing before the next crossing (96 n. S) --> Pipeline trigger beam-gas rate : ~ 100 k. Hz (10000 n. S) It is not possible to pick up low rate physics event in one step Three-Level Trigger FLT : Hardware trigger starts the readout system SLT: Software trigger with distributed processors starts event building K. Tokushuku TLT: Software trigger in a single processor 6 starts data storage
ATLAS/CMSは K. Tokushuku ZEUSの 100倍の LVL 1レート 7
Moore’s law 半導体集積度は、18~24ヶ月で倍増する。Gordon Moore • 計算機を買いだめするのは 愚か。 • 計算機を自分で作るのも 開発している間に古くなる。 （Commodity productを使う） • 表にはないが、大容量の アーカイブシステム（テープ など）の発展は遅い →データの取り溜めは 高くつく • 計算機を使ってOnline解析 をし、ゴミをできるだけ減らす のが得策。（HLT) • 近年はネットワークの進歩 が目覚ましい。 →これによってDAQの 設計方針が変わってく る。 K. Tokushuku 8
Detector Readout Control (ZEUS) Simple handshake method is adopted • No risk of event loss • DAQ dead time after a FLT Trigger (accept flag) GFLT busy Dead time CAL Dead time “event” GFLT accept busy CTD Busy A Busy B Busy Z busy Busy OR (GFLT internal) One of the important task of the GFLT is to measure the dead time K. Tokushuku 9 -> LUMI calculation
Output rate ZEUS実験の場合： １イベントあたりの デッドタイム＝ 60μS このとき、入力トリ ガーレートRinに対し て、実際に取れる レートRoutはどんな 式で表せるか？ ーー＞宿題 k. Hz Dead time (%) 100 k. HzでDeadtimeを 5% 以下にするには、１事象あ たりの読出しを 600 n. Sで行 う必要がある。 ZEUS 目標レート LHC バンチレート LHC 目標レート HERA バンチレート 5%デットタイム k. Hz MHz K. Tokushuku →ここまできたら、全く Deadtimeのないシステム を作るのと手間は同じ =>トリガーが来たデータ をすぐにバッファーに入れ て次の準備。 →ハンドシェークは不要 ATLAS規則： 2つのトリ ガーの間隔は最低でも5バ ンチ（125 n. S)は保証する。 Input Trigger rate (Hz) 10
Level-1 75 k. Hz 2 μs Target processing time Hardware trigger ~ 10 ms ~2 s High Level Triggers (HLT) ~ 2 k. Hz Level-2 + Event Filter Software trigger ~ 200 Hz Rate K. Tokushuku 11
ATLAS LVL 1 subsystems O(1 M) RPC/TGC channels ~7000 calorimeter trigger towers Italy Calorimeter trigger Muon Barrel Trigger Pre-Processor (analogue ET) Jet / energy-sum Processor RPC Cluster Processor (e/g, t/h) Japan, Israel Muon trigger Muon End-cap Trigger Muon-CTP Interface (MUCTPI) TGC +Mip in Tile. CAL Germany, Sweden, UK Central Trigger Processor (CTP) Timing, Trigger, Control (TTC) K. Tokushuku CERN 12
CMS ATLASもCMSも LVL 1は基本的にカロリメータとミューオンのみ ミューオンについてはCMSはRPCと（DT+CSC）でredandant → Trackingトリガーなし ← 1バンチに 25のｐｐ事象があるので、必ず衝突点 からのトラックがあり、あまり意味がない。 Super. LHCでは、電子トリガーにトラックを要求できるとよい。 K. Tokushuku 13
ATLAS Calorimeter Trigger Overview Real-time path (<1 s) DAQ RODs Input/output data To DAQ 2 ROD crates 0. 2 x 0. 2 Jet / SET (JEP) Ro. I RODs • どうやってElectronを見つけるのだろうか? To L 2 2 JEP crates Feature Pretypes/ • タウトリガー、ジェットはどう定義されているか？ Processor positions e/g, t/had (PPr) • オフラインでのElectron, ジェットとどう違うか？ Analogue Clusters To CTP 8 PPr crates 0. 1 x 0. 1 tower sums (CP) 解析をする人は、一度調べてみよう。 0. 1 x 0. 1 4 CP crates (~7200) （LVL 1 TDR) (>300 Gbyte/s) CTP TTC Fibre F/O To CTP DCS K. Tokushuku Slow Control CANbus 14
• 沢山の遠く離れたTGCチェンバーから、どうやって ミューオンが通ったことがわかるのだろう？ • どうやってタイミングがわかるのだろう？ • 偽のミューオンはどうやってできるのだろう？ 解析をする人は、一度調べてみよう。 （LVL 1 TDR) K. Tokushuku 15
ATLAS LVL 1 subsystems Calorimeter trigger Muon Barrel Trigger Pre-Processor (analogue ET) Jet / energy-sum Processor RPC Cluster Processor (e/g, t/h) Muon End-cap Trigger Muon-CTP Interface (MUCTPI) TGC +Mip in Tile. CAL Central Trigger Processor (CTP) Timing, Trigger, Control (TTC) K. Tokushuku LVL 1 16 Trigger decision
Central Trigger Processor (CTP) prescaler ミューオン prescaler electron, tau programmable logic prescaler OR LVL 1トリガー Jet, Et, x. Et CAL, ミューオン から合計128 bit の情報 prescaler 96のサブトリガー 入力が128 bitしかないということは、 ZEUS エネルギーの値とか、PositionとかはCTPまで来ない。その前段で（それぞれの 864 bits ObjectごとにThresholdが決められてその結果だけが来る。） この方式では、ミューオン、CAL cluster（Electron, Tau), CAL Jet/Et、間の詳細なロジック は作れない。 K. Tokushuku 17 (例えば、FWDにジェットがあって、バレルにlow-pt μ とかいうトリガーはできない。)
入力データのリスト （TDRの時期） ８つのEnergy ThresholdでのMultipicity情報が主な内容 K. Tokushuku 18
CMS GT (=ATLAS CTP) CMSは正反対のアプローチ LocalにはDecisionさせず、 すべてをCentralで決める。 CMSでは、GTに Objectの位置と エネルギーを送る CAL 16 x 24 = 384 bits mu 24 x 4=96 bits 原理的にGT上でどんな トリガーでも作れる。 （ただし、実際に作れるか は不明。また、複雑なトリガー が本当に必要かも不明） K. Tokushuku 19
ATLAS LVL 1 -LVL 2 Calorimeter trigger Pre-Processor (analogue ET) Jet / energy-sum Processor Cluster Processor (e/g, t/h) Muon Barrel Trigger RPC Muon End-cap Trigger Muon-CTP Interface (MUCTPI) TGC +Mip in Tile. CAL ROI (Region of Interest) Central Trigger Processor (CTP) ここに詳しい (E, P)情報が Timing, Trigger, 送られる。 Control (TTC) これがLVL 2 で使われる。 K. Tokushuku LVL 1 20 Trigger decision
ATLAS LVL 2のキーポイント： ROIの情報によって、LVL 1がどこのDetector K. Tokushuku 21 から作られたかがわかるので、その領域のデータだけもらって解析する。
Event Builder トリガーが来て取った データは、各測定器の 各読出し単位（クレート、 ROD, ROB)上に次々 に溜まる。 イベントビルダーはその 断片データを集めてすべて の測定器のデータを いっしょにした“Event” にする。 多対多のデータ転送。 （ただし一方向） →最近のネットワーク スイッチの発展で K. Tokushuku 22
EVB 512 x 512 現実に扱うべきシステムは 512ｘ 512（CMS) 144 x 136（ATLAS)の多対多ネットワーク 今（2004年）の技術で 64ｘ 64はテストでき、所定の性能を出すことがわかっている。 それを 512ｘ 512に拡張してそのまま性能がでるか？（scalability） K. Tokushuku 23
CMSの方法 64 x 64を 8つ立体的に並べ、頭に 8 x 8のネットワークをつける K. Tokushuku 24
DAQ basic unit: 1 Readout Builder (12. 5 k. Hz) RB Myrinet layout Readout Builder: EVB technology : Open RU/BU/FU : PC servers K. Tokushuku 25 Installation : 2006 -2009
DAQ basic unit: ２ Readout Builder (25 k. Hz) RB Gbit. Ethernet layout K. Tokushuku 26
DAQ basic unit: ４ Readout Builder (50 k. Hz) K. Tokushuku 27
DAQ basic unit: 8 Readout Builder (100 k. Hz) CMSはLVL 1トリガーすべてをEvent. Buildできるシステムを作ることに した。 → D 2 S and RB RB e. g. D 2 S and K. Tokushuku Gb. Ethernet layout Myrinet layout LVL 2の撤廃 28
8 -fold DAQ system Side View Front View K. Tokushuku 29
ここまでのまとめ • ALTAS/CMSは、PPの高い反応レートの中から重 要な事象を選択するために、多段のトリガーシステ ムを採用した。LVL 1はハードウェアのトリガー、それ 以降のHLTは市販のPCを（O(1000)台）使ったフ ァームでのソフトウェアトリガーである。 • CMSはLVL 1のあと直接EVBし、一段のHLT。 • ATLASはEVBの前に、LVL 1でどの領域でトリガー が生じたかの情報を使って（ROI), その領域のデー タだけを解析してLVL２トリガーを得る。LVL 2の後 EVBする。 • トリガーは、主にカロリメータとミューオンの情報から 作る。 K. Tokushuku 30
(1992 -) ZEUS FLT (2006 -) ATLAS LVL 1 HW trigger 500 Hz (buffer limited) SLT HW trigger 100 k. Hz CMS LVL 1 HW trigger 100 k. Hz LHCb LVL 0, 1 HW trigger 40 k. Hz LVL 2 distributed CPU 100 Hz ((old) CPU limited) EVB TLT farm ~30 Hz (10 Hz) Offline Data storage limited ($!) LVL 3 LVL 0, 1 HW trigger 1 k. Hz LVL 2 farm 1 k. Hz EVB ALICE HW 100 Hz EVB LVL 3 EVB LVL 2, 3 farm 100 Hz farm 200 Hz 1. 5 MBx 1 k. Hz =1. 5 GB/s 1 MBx 100 k. Hz =100 GB/s 100 k. Bx 40 k. Hz =4 GB/s EVB LVL 3 farm ~100 Hz EVB rate 100 k. Bx 100 Hz =10 MB/s 80 MBx 100 Hz =8 GB/s output rate 100 k. Bx 10 Hz =1 MB/s 1. 5 MBx 200 Hz =0. 3 GB/s K. Tokushuku 1 MBx 100 Hz =0. 1 GB/s 200 k. Bx 200 Hz =40 MB/s 1. 3 GB/s 31
何でトリガーするか? • ある程度高いエネルギーの電子、ミューオンがあれば取る。（inclusive） （「ある程度」とは? ← W, Zの崩壊からのレプトン） • missing ET はジェットや“タウ”と組み合わせる （そうでないとレートが高すぎる） K. Tokushuku 32 • ジェット単独は非常に高いThresholdが必要。 • ここにないものが自分の物理解析に必要なら、しっかりしたプロポーザルが必要
LVL 1のメニューとレート K. Tokushuku 33 CMSのsafety factorは 3
HLT(LVL 2+LVL 3)のメニュー （LVL 2単独でどれだけ落ちるかを見せてくれたことはない） LVL 1のThreshold EM 25 i 2 EM 15 i 2 mu 6 j 200 3 j 90, 4 j 65 j 60+x. E 60 t 25+x. E 30 • ElectronはLVL 1のThresholdを維持 • Photonのレートを落とすのは難しい （沢山のπ0） ←Th. を上げる。 • LVL 1の 2ミューオンのTh. が低かったのはBの物理のため。 しかしHLTではψ、Υしか残せない。 K. Tokushuku 34 • LVL 1のジェットはHLTで見てもジェット。レートを下げるにはTh. を上げるしかない。
K. Tokushuku 35
K. Tokushuku 今はずっとよくなっている 36
K. Tokushuku 37
Trigger selection chains Electron Muon LVL 1 muon LVL 1 calo LVL 2 muon LVL 2 calo isol LVL 2 tracking EF calo EF muon EF tracking EF calo isol EF tracking K. Tokushuku 38
K. Tokushuku 39
K. Tokushuku 40
HLTのトリガーアルゴリズムの研究は まだまだ始まったばかり。 参入の余地は大きい。物理をやる上でも重要。 どこで議論するか。 → PESA Physics and Event Selection Architecture K. Tokushuku 41
K. Tokushuku 42 この後の詳細な比較でATLAS CMSトリガーともほぼ同様の性能を持つことがわかった。
最後に • LHC実験では、ｐｐ衝突レートが非常に高いので、 実験の最初から「とりたいEventを取る」というトリ ガーになる。（HERAの初期は「とりたくないEventを 殺す」という論理を使えた。）したがって、自分がほし いEventがちゃんとトリガーされていることを確認す ることが重要である。 • ただし、余分なEventをとると、Offlineの資源を無駄 に使うことになるので、「とりあえず取っておこう」と いう発想は避ける。 K. Tokushuku 43
Скачать презентацию ATLAS検出器の講義 Trigger DAQ TriggerとDAQの一般論 LHC実験のTrigger DAQ
82b927dc88a873a1dc9423e73fbacf78.ppt