K.Tokushuku1 ATLAS 検出器の講義 Trigger DAQ Trigger と DAQ の一般論 LHC 実験の Trigger/DAQ LVL1 トリガー HLT KEK 徳宿 克夫.

Presentation on theme: "K.Tokushuku1 ATLAS 検出器の講義 Trigger DAQ Trigger と DAQ の一般論 LHC 実験の Trigger/DAQ LVL1 トリガー HLT KEK 徳宿 克夫."— Presentation transcript:

1 K.Tokushuku1 ATLAS 検出器の講義 Trigger DAQ Trigger と DAQ の一般論 LHC 実験の Trigger/DAQ LVL1 トリガー HLT KEK 徳宿 克夫

2 K.Tokushuku2 トリガー信号 不感時間 S1 S2 トリガー・ DAQ ： 簡単なシステム Trigger: 数多くの測定器情報から 作る、１ Bit 情報＋タイミング情報 （「今来たイベントを取れ」という 信号） Deadtime: 多くのシステムでは、 一つのトリガーが入るとその処理の 間、次が受付けられないので、 しばらくトリガーを止める必要がある。 LHC 実験のトリガー・ DAQ も基本は同じ

3 K.Tokushuku3 違いは、 トリガーのレートと読み出す チャンネルの量 LHC: pp 反応レート →1GHz バンチ交差間隔 25nS → 40MHz ： ヒッグス生成頻度 → 0.1Hz 測定器の読出しチャンネル Liq CAL ～ 10k チャンネル ミューオン ～１ M チャンネル ATLAS のデータサイズ：～１.5MB トリガーレートをどう設定するかは 物理とお金による。 例えば、全部シグナルで、 Operation cost >> Storage cost なら、すべて取るという解もある。 (1.5MBx40MHz なら DVD15000 枚 / 秒 ) （ cf. ALICE ） Trigger decision の前に次の衝突が起こる → パイプライントリガー 低い S/N → マルチレベルトリガー

4 K.Tokushuku4

5 5 Detector Readout Electronics 96ns p e Component A readout Trigger Component Z GFLT ZEUS FLT Synchronous pipeline system Deadtime-free trigger HERA clock 96nS clock 0S0S 4.6  S 4.6  S+prop.delay TOF+Detector response <2.6  S Timing Pipeline Trigger ZEUS の場合

6 K.Tokushuku6 ZEUS DAQ The main trigger comes from proton-beam related background.  pp >>  ep bad vacuum (activated by synchrotron radiation) bunch crossing rate : 10.41 MHz ( 96nS) It is not possible to make a trigger decision of a crossing before the next crossing (96nS) --> Pipeline trigger beam-gas rate : ~ 100 kHz (10000nS) 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 TLT: Software trigger in a single processor starts data storage

7 K.Tokushuku7 ATLAS/CMS は ZEUS の 100 倍の LVL1 レート

8 K.Tokushuku8 Moore’s law 半導体集積度は、 18~24 ヶ月で倍増する。 Gordon Moore 計算機を買いだめするのは 愚か。 計算機を自分で作るのも 開発している間に古くなる。 （ Commodity product を使う） 表にはないが、大容量の アーカイブシステム（テープ など）の発展は遅い → データの取り溜めは 高くつく 計算機を使って Online 解析 をし、ゴミをできるだけ減らす のが得策。（ HLT) 近年はネットワークの進歩 が目覚ましい。 → これによって DAQ の 設計方針が変わってく る。

9 K.Tokushuku9 Detector Readout Control (ZEUS) Simple handshake method is adopted No risk of event loss DAQ dead time after a FLT GFLT CAL CTD Trigger (accept flag) busy “event” GFLT accept Busy A Busy B Busy Z Busy OR (GFLT internal) Dead time One of the important task of the GFLT is to measure the dead time -> LUMI calculation

10 K.Tokushuku10 kHzMHz kHz Dead time (%) Input Trigger rate (Hz) Output rate ZEUS 実験の場合： １イベントあたりの デッドタイム＝ 60μS ZEUS 目標レート 5% デットタイム LHC 目標レート LHC バンチレート このとき、入力ト リガーレート R in に 対して、実際に取 れるレート R out はど んな式で表せる か？ ーー＞宿題 100kHz で Deadtime を 5% 以下にするには、１事象 あたりの読出しを 600nS で行う必要がある。 → ここまできたら、全 く Deadtime のないシステ ムを作るのと手間は同じ => トリガーが来たデー タをすぐにバッファーに 入れて次の準備。 → ハンドシェークは不 要 ATLAS 規則： 2 つのトリ ガーの間隔は最低でも 5 バンチ（ 125nS) は保証す る。 HERA バンチレート

11 K.Tokushuku11 75 kHz ~ 2 kHz ~ 200 Hz Rate Target processing time ~ 2 s ~ 10 ms 2 μs High Level Triggers (HLT) Level-2 + Event Filter Software trigger Level-1 Hardware trigger

12 K.Tokushuku12 ATLAS LVL1 subsystems Calorimeter trigger Muon trigger Central Trigger Processor (CTP) Timing, Trigger, Control (TTC) Germany, Sweden, UK ItalyJapan, Israel Cluster Processor (e/ ,  /h) Pre-Processor (analogue  E T ) Jet / energy-sum Processor CERN Muon Barrel Trigger Muon End-cap Trigger Muon-CTP Interface (MUCTPI) ~7000 calorimeter trigger towers O(1M) RPC/TGC channels TGC RPC +Mip in TileCAL

13 K.Tokushuku13 CMS ATLAS も CMS も LVL1 は基本的にカロリメータとミューオンのみ ミューオンについては CMS は RPC と（ DT+CSC ）で redandant → Tracking トリガーなし ← 1 バンチに 25 のｐｐ事象があるので、必ず衝突点 からのトラックがあり、あまり意味がない。 SuperLHC では、電子トリガーにトラックを要求できるとよい。

14 K.Tokushuku14 ATLAS Calorimeter Trigger Overview DAQ RODs Input/output data To DAQ e/ ,  /had Clusters (CP) 0.2 x 0.2 Jet /  E T (JEP) 0.1 x 0.1 Pre- Processor (PPr) Analogue tower sums 0.1 x 0.1 (~7200) (>300 Gbyte/s) RoI RODs To L2 Feature types/ positions Fibre F/O TTC CTP Slow Control CANbus DCS To CTP Real-time path (<1  s) 8 PPr crates 4 CP crates 2 JEP crates 2 ROD crates どうやって Electron を見つけるのだろうか ? タウトリガー、ジェットはどう定義されているか？ オフラインでの Electron, ジェットとどう違うか？ 解析をする人は、一度調べてみよう。 （ LVL1 TDR)

15 K.Tokushuku15 沢山の遠く離れた TGC チェンバーから、どうやって ミューオンが通ったことがわかるのだろう？ どうやってタイミングがわかるのだろう？ 偽のミューオンはどうやってできるのだろう？ 解析をする人は、一度調べてみよう。 （ LVL1 TDR)

16 K.Tokushuku16 ATLAS LVL1 subsystems Calorimeter trigger Central Trigger Processor (CTP) Timing, Trigger, Control (TTC) Cluster Processor (e/ ,  /h) Pre-Processor (analogue  E T ) Jet / energy-sum Processor Muon Barrel Trigger Muon End-cap Trigger Muon-CTP Interface (MUCTPI) TGC RPC +Mip in TileCAL LVL1 Trigger decision

17 K.Tokushuku17 Central Trigger Processor (CTP) ミューオン CAL, ミューオン から合計 128bit の情報 programmable logic prescaler 96 のサブトリガー OR LVL1 トリガー ZEUS 64bits ZEUS 864bits 入力が 128bit しかないということは、 エネルギーの値とか、 Position とかは CTP まで来ない。その前段で（それぞれの Object ごとに Threshold が決められてその結果だけが来る。） この方式では、ミューオン、 CAL cluster （ Electron,Tau),CAL Jet/Et 、間の詳細なロジック は作れない。 ( 例えば、 FWD にジェットがあって、バレルに low-pt μ とかいうトリガーはできない。 ) electron, tau Jet, Et, xEt

18 K.Tokushuku18 入力データのリスト （ TDR の時期） ８つの Energy Threshold での Multipicity 情報が主な内容

19 K.Tokushuku19 CMS GT (=ATLAS CTP) CMS では、 GT に Object の位置と エネルギーを送る CAL 16x24 = 384bits mu 24x4=96bits 原理的に GT 上でどんな トリガーでも作れる。 （ただし、実際に作れるか は不明。また、複雑なトリガー が本当に必要かも不明） CMS は正反対のアプローチ Local には Decision させず、 すべてを Central で決める。

20 K.Tokushuku20 ATLAS LVL1-LVL2 Calorimeter trigger Central Trigger Processor (CTP) Timing, Trigger, Control (TTC) Cluster Processor (e/ ,  /h) Pre-Processor (analogue  E T ) Jet / energy-sum Processor Muon Barrel Trigger Muon End-cap Trigger Muon-CTP Interface (MUCTPI) TGC RPC +Mip in TileCAL LVL1 Trigger decision ROI (Region of Interest) ここに詳しい (E,P) 情報が 送られる。 これが LVL2 で使われる。

21 K.Tokushuku21 ATLAS LVL2 のキーポイント： ROI の情報によって、 LVL1 がどこの Detector から作られたかがわかるので、その領域のデータだけもらって解析する。

22 K.Tokushuku22 Event Builder トリガーが来て取った データは、各測定器の 各読出し単位（クレート、 ROD,ROB) 上に次々 に溜まる。 イベントビルダーはその 断片データを集めてすべて の測定器のデータを いっしょにした “Event” にする。 多対多のデータ転送。 （ただし一方向） → 最近のネットワーク スイッチの発展で

23 K.Tokushuku23 EVB 512x512 現実に扱うべきシステムは 512 ｘ 512 （ CMS) 144x136 （ ATLAS) の多対多ネットワーク 今（ 2004 年）の技術で 64 ｘ 64 はテストでき、所定の性能を出すことがわかっている。 それを 512 ｘ 512 に拡張してそのまま性能がでるか？（ scalability ）

24 K.Tokushuku24 CMS の方法 64x64 を 8 つ立体的に並べ、頭に 8x8 のネットワークをつける

25 K.Tokushuku25 DAQ basic unit: 1 Readout Builder (12.5 kHz) Readout Builder: EVB technology : Open RU/BU/FU: PC servers Installation : 2006- 2009 Readout Builder: EVB technology : Open RU/BU/FU: PC servers Installation : 2006- 2009 RB Myrinet layout

26 K.Tokushuku26 RB GbitEthernet layout DAQ basic unit: ２ Readout Builder (25 kHz)

27 K.Tokushuku27 DAQ basic unit: ４ Readout Builder (50 kHz)

28 K.Tokushuku28 e.g. D2S and RB Myrinet layout D2S and RB GbEthernet layout DAQ basic unit: 8 Readout Builder (100 kHz) CMS は LVL1 トリガーすべてを EventBuild できるシステムを作るこ とに した。 → LVL2 の撤廃

29 K.Tokushuku29 8-fold DAQ system Front ViewSide View

30 K.Tokushuku30 ここまでのまとめ ALTAS/CMS は、 PP の高い反応レートの中から 重要な事象を選択するために、多段のトリガー システムを採用した。 LVL1 はハードウェアのト リガー、それ以降の HLT は市販の PC を （ O(1000) 台）使ったファームでのソフトウェ アトリガーである。 CMS は LVL1 のあと直接 EVB し、一段の HLT 。 ATLAS は EVB の前に、 LVL1 でどの領域でトリ ガーが生じたかの情報を使って（ ROI), その領域 のデータだけを解析して LVL ２トリガーを得る。 LVL2 の後 EVB する。 トリガーは、主にカロリメータとミューオンの 情報から作る。

31 K.Tokushuku31 ZEUS FLT HW trigger 500Hz (buffer limited) SLT distributed CPU 100Hz ((old) CPU limited) TLT farm ~30Hz (10Hz) Offline Data storage limited ($!) ATLAS LVL1 HW trigger 100 kHz LVL2 farm 1kHz LVL3 farm 100Hz CMS LVL1 HW trigger 100 kHz LVL3 farm 100Hz LHCb LVL0,1 HW trigger 40 kHz LVL2,3 farm 200Hz ALICE LVL0,1 HW trigger 1 kHz LVL2 HW 100Hz LVL3 farm ~100 Hz EVB EVB rate 100kBx100Hz =10MB/s1.5MBx1kHz =1.5GB/s1MBx100kHz =100GB/s100kBx40kHz =4GB/s80MBx100Hz =8GB/s output rate 100kBx10Hz =1MB/s1.5MBx200Hz =0.3GB/s200kBx200Hz =40MB/s1.3GB/s 1MBx100Hz =0.1GB/s (1992-)(2006-) EVB

32 K.Tokushuku32 何でトリガーするか ? ある程度高いエネルギーの電子、ミューオンがあれば取る。（ inclusive ） （「ある程度」とは ? ← W,Z の崩壊からのレプトン） missing E T はジェットや “ タウ ” と組み合わせる （そうでないとレートが高すぎる） ジェット単独は非常に高い Threshold が必要。 ここにないものが自分の物理解析に必要なら、しっかりしたプロポーザルが必要

33 K.Tokushuku33 LVL1 のメニューとレート CMS の safety factor は 3 問題はこれを、どうやって HLT で ~200Hz に落とすか？ （ファクター ~100 の Rejection ） 特に ATLAS では LVL2 で 2kHz に落とさないといけない （ただしこの数字は Flexible ）

34 K.Tokushuku34 HLT(LVL2+LVL3) のメニュー （ LVL2 単独でどれだけ落ちるかを見せてくれたことは ない） 2mu6 2EM15iEM25i j2003j90,4j65 j60+xE60 t25+xE30 Electron は LVL1 の Threshold を維持 Photon のレートを落とすのは難しい （沢山の π 0 ） ←Th. を上げる。 LVL1 の 2 ミューオンの Th. が低かったのは B の物理のため。 しかし HLT では ψ 、 Υ しか残せない。 LVL1 のジェットは HLT で見てもジェット。レートを下げるには Th. を上げるしかない。 LVL1 の Threshold

35 K.Tokushuku35

36 K.Tokushuku36 今はずっとよくなっている

37 K.Tokushuku37

38 K.Tokushuku38 Trigger selection chains LVL1 calo LVL2 calo LVL2 tracking EF calo EF tracking LVL1 muon LVL2 calo isol LVL2 tracking EF muon LVL2 muon ElectronMuon EF calo isol EF tracking

39 K.Tokushuku39

40 K.Tokushuku40

41 K.Tokushuku41 HLT のトリガーアルゴリズムの研究は まだまだ始まったばかり。 参入の余地は大きい。物理をやる上でも重要。 どこで議論するか。 → PESA Physics and Event Selection Architecture

42 K.Tokushuku42 この後の詳細な比較で ATLAS CMS トリガーともほぼ同様の性能を持つことがわかった。

43 K.Tokushuku43 最後に LHC 実験では、ｐｐ衝突レートが非常に高いの で、実験の最初から「とりたい Event を取る」と いうトリガーになる。（ HERA の初期は「とり たくない Event を殺す」という論理を使えた。） したがって、自分がほしい Event がちゃんとトリ ガーされていることを確認することが重要であ る。 ただし、余分な Event をとると、 Offline の資源を 無駄に使うことになるので、「とりあえず取っ ておこう」という発想は避ける。