ATLAS実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化

Presentation on theme: "ATLAS実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化"— Presentation transcript:

1 ATLAS実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化
千葉英誉, 木村直樹，寄田浩平 早稲田大学 ATLAS FTK Group 日本物理学会　2010年　春季大会 ３月２１日　岡山大学津島キャンパス　21aBE会場

2 ATLAS Trigger System ＆ ＦＴＫ(Fast TracKer)
飛跡検出器 Input＆Process 飛跡検出器内部の Pixel/SCTからHit情報のみ貰い，Trackを再構成する。 FTK Output Pixel 3Layer Barrel SCT 8Layer １GeV以上(|η|<2.5)の全てのTrackのPt,φ,η,Z,d をLVL2に渡す。 数週間前　Technical Proposal(p.93)を提出 現在TDAQ(USG)でレビュー中 2 1

3 FTKの目的 現行のデザイン b quark light quark LVL2以降のPCファームで
WH(120)3×1034 PILEUP Black→OffLIneRed→FTK Impact Parameter light quark b quark 現行のデザイン LVL2以降のPCファームで 領域を選択し(RoI),Trackを再構成 FTK挿入後 100μsec以下の処理速度で事象中の 全てのTrack　(1GeV以上)　を再構成 Track情報の使用　 35 L=1034[cm-2 FTK有 FTK無 ⇒QCD事象をより多く破棄することできる。 ⇒マルチジェットトリガーのPｔ閾値を下げられるなど。（右図） 2.RoI以外のオブジェクトをLVL2トリガーに加えられる 3. eやμトリガーにも応用可能　　など 高ルミノシティ下でも安定したTrack情報の供給 LVL2でより洗練されたAlgorithmが使用可能に 3 2

4 FTKの基本動作原理 2. Super Strip単位での 1. Hit情報をどの”Super Strip”に
Pattern Recognition →　”Road” (Associative Memory) 1. Hit情報をどの”Super Strip”に 位置するか分ける。(Data Organizer) Layer4 Layer3 Road1 Road2 Layer2 Layer1 モジュール Super Strip Hit位置 ＜FTKの重要なパラメータ＞ 3. Track Fitting Stage 素早く処理できる構成方法 Full ResolutionのHit情報を使用 Super Strip size pattern sizeに影響 Layerの組み合わせ 現状の方法　２つ提案中 今回はコチラのみ SCT8Layer Fit ⇒ Pixel+SCT 11Layer Fit Pixel 3L+SCT 4L Fit ⇒ 11Layer Fit 3

5 Φ 16等分×η 4等分⇒64 Processor Unit
ＦＴＫシステム FTK overlap regions Processor Unit Pixel & SCT cluster finding split by layer Super Strip Data Organizer (DO) Associative Memory (AM) Data Formatter (DF) RODs S-links Hit Road Hit Road Input 50kHz～100kHz Track Fitter (TF) 1st Stage SCT8Layerのみ計算 Hit Warrior (HW) Raw data ROBs １等分に１Board Ｘ64 (each region) Processor Unit 2nd Stage　11Layer全てにおいて計算 Φ 16等分×η 4等分⇒64 Processor Unit 8(16) Processor Unit ⇒ 1 VME Crate Track Data ROB 但し,十分なOverlapを含んだRegion分け 5 4

6 Data Organizer / 1Board=1分割分
☆LVL1のOutputは100kHzを仮定 １Regionにおける Layerごとの平均Hit数 Pixel 1 868.1 ± 6.4 Pixel 2 687.3 ± 4.2 Pixel 3 627.3 ± 4.2 SCT 4 411.1 ± 2.0 SCT 5 410.8 ± 2.0 SCT 6 446.0 ± 2.1 SCT 7 441.1 ± 2.1 SCT 8 404.0 ± 1.8 SCT 9 404.6 ± 1.9 SCT 10 387.4 ± 1.7 SCT 11 386.2 ± 1.7 1Evを10μsで処理が必要 WHbb L=3×1034[cm-2・s-1] Pile-up ☆Input＆OutputはPipelineで100MHz 　１Layer辺り，１０００Hitまでなら 処理可能 (Input OK) ☆1つのDO に対し100MHzのClockで処理　 #SS<#HitなのでOK Hits of SCT11 Hits of SCT 4 Hits of SCT 5 Hits of SCT 6 Hits of SCT 7 Hits of SCT 8 Hits of SCT 9 Hits of SCT10 100 MHz 100MHz DO hit SCT8L SS 5

7 Associative Memory "Pattern Recognition"
Road AM 100 MHz SS 200 Input　100MHz #SS<#HitからOK LAMB 200MHz AM From DO DOから全てのSS情報を 得てから処理開始!! 平均Road数　3.1k →Output　OK WHbb L=3×1034[cm-2・s-1] Pile-up <スペック> AMは４枚(LAMB)で処理する 1LAMB 200MHzの処理能力 4LAMB=4×200MHz=800MHz　 →　8k Roadまで耐える！ 6

8 Road内のHitをFull ResolutionでFitする
Track　Fitter / 1Board 100 MHz DO road & hit 100MHz TF 500MHz Fit1 Fit3 2ndDO⇒TF Road HitとRoadをTFに送る From AM 転送速度100MHz×4 4k以内のデータ量 3.1kRoadから転送可能 Road内のHitをFull ResolutionでFitする TF 平均Fit数　12.8k → OK WHbb L=3×1034[cm-2・s-1] Pile-up <スペック> 0.5GHz×4=2GHz 20kのFit　Combination まで時間Lossなしに 処理することが可能 7

9 Timing Simulation <目的>
処理すべきInputの平均値が，各段階の平均処理速度を超えると処理が追いつかず，次のイベントの処理が遅れ続ける。 最初の1Hit情報が駆け抜ける時間 処理時間が遅れることによりTriggerのDead timeを生まないか確認のために ＜変数＞ ・Hit数 ・Boardの処理速度 ・Input，Output，Delay time Total時間を計算する！！ パイプラインなので，それぞれで 時間かかるところが全体の出力時間に影響！ Input Output DF DO AM DO TF HW 処理されてOutputの時間が延びる 全Hitを待つのでパイプラインではなくなる⇒時間がかかる 1data Fitも時間がかかる 8

10 Timing Simulationの式 DO AM SecDO TF
i=0-8(DO 8CPU) , ProcTime(ClockTime)=10nsec , InTime(Input time)=10nsec , Delay=40nsec FwIn(i)=max[ 0, max(Pre_EwOut(i))-10μsec , max(Pre_Pre_SecDO_EwOut(I)) - 20μsec) ] EwIn(i)= #Hit(i)×InTime + FwIn(i) FwOut(i)= FwIn(i) + Delay EwOut(i)=max[ FwOut(i)+ProcTime×#Hit(i) , EwIn(i)+Delay ] AM j=0-4(LAMB4枚) , ProcTime(ClockTime)=5nsec , InTime(Input time)=10nsec , Delay=500nsec FwIn(i)=max[ min(DO_FwOut(i)) , max(Pre_EwOut(j))-10μsec , max(Pre_Pre_EwOut(j)) - 20μsec] EwIn(i)= max[ max(DO_EwOut(i)) , max(#SS(i))×InTime + max(DO_FwOut(i)) , max(Pre_EwOut(j)) - 10μsec , max(#SS(i))×InTime+max(Pre_EwIn(j)) - 10μsec max(#SS(i))×InTime+max(Pre_Pre_EwOut(j)) - 20μsec ] FwOut(i)= EwIn(j) + Delay EwOut(i)=FwOut(j)+max(ProcTime×#Road(j)) SecDO I=0-4(DO 4枚) , ProcTime(ClockTime)=5nsec , InTime(Input time)=5nsec , Delay=200nsec FwIn(I)=max[ min(AM_FwOut(j)) , max(Pre_EwOut(I)) - 10μsec) ] EwIn(I)= max[ max(AM_EwOut(j)) , max(#Road(j))×InTime + FwIn(I) ] FwOut(I)= FwIn(i) + Delay EwOut(I)=max[ FwOut(I)+ProcTime×#Road(j) , EwIn(I)+Delay ] TF k=0-4(TF 4枚) , ProcTime(ClockTime)=2nsec , InTime(Input time)=5nsec , Delay=300nsec FwIn(k)=max[ min(SecDO_FwOut(I)) , max(Pre_EwOut(k)) - 10μsec) ] EwIn(k)= max[ max(SecDO_EwOut(I)) , max(#Hit(i))×InTime + FwIn(k) ] FwOut(k)= FwIn(k) + Delay EwOut(k)=max[ FwOut(k)+ProcTime×#Fit(k) , EwIn(k)+Delay ] FwIn→最初のデータが処理部分に入る時 FwOut→最初のデータが処理部分から出る時 EwIn→最後のデータが処理部分に入る時 EwOut→最後のデータが処理部分から出る時 9

11 End Word Out Time 平均Hit数＜Spec上限Hit数 処理時間は 蓄積され続けることはない (Deadtimeがない)
１イベント内の最後のデータがOutputされる時の時間と定義 WHbb L=3×1034[cm-2・s-1] Pile-up 処理できない場合 　処理が蓄積して時間が増加する 処理できる場合 　蓄積した処理時間はリセットされる 平均Hit数＜Spec上限Hit数　 処理時間は 蓄積され続けることはない (Deadtimeがない) 100KHzで100ev分走らせた結果 10

12 Event example (Total Process Time)
AMは全LayerのSSを全て使うので SSを待つ時に時間がかかる。　　 最大処理時間がかかっているEvent 前のイベントの処理によって遅れている WHbb L=3×1034[cm-2・s-1] Pile-up WHbb L=3×1034[cm-2・s-1] Pile-up 8つのリージョンのうち最も遅いリージョンを最終的な事象プロセス時間とした 11

13 1RoI/1PC msec FTK processing time 平均24μsec μsecオーダーで処理することが可能！
現状のLVL2を想定したTrack再構成にかかる時間 ⇒RoIのみを1PC(Intel Core 2 Duo E GHz) でTrack計算しても　1RoIにmsecオーダーかかる。 μsecオーダーで処理することが可能！ msec WHbb L=3×1034[cm-2・s-1] Pile-up WHbb with Pile-up 平均24μsec 1RoI/1PC 12

14 Time Simulationとしての予定
纏め ルミノシティ3×1034[cm-2・s-1]でも,現在のFTKのデザインでは平均Hit数， Road数，Fit数がBoardの許容範囲内であることが分かった。 　　→　その結果、100μsec以下で処理が可能である。 100Evで確かめた結果，Dead Timeなしに処理することが可能である。 展望 Time Simulationとしての予定 DF，HWのデザイン最適化はまだ詰める必要がある。 　　⇒　DFやHWの処理時間を考慮し，デザインの最適化に反映。 2nd　Stageに関しても最適化を行う。 シミュレーションの統計数を増やす必要あり。 FTK 全体としての予定 全領域のEfficiencyを高めるために記憶パターンやSuperStrip sizeの最適化 Real　Dataの有効利用 　　 2012年のShutdown時での挿入(プロトタイプ版)を想定して開発・制作中！ 13