Download
1 / 14
140 likes | 363 Views
ATLAS 実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化. 千葉英誉 , 木村直樹，寄田浩平 早稲田大学 ATLAS FTK Group. 日本物理学会 2010 年 春季大会 ３月２１日 岡山大学津島キャンパス 21aBE 会場. FTK. Barrel SCT 8Layer. Pixel 3Layer. ATLAS Trigger System ＆ ＦＴＫ (Fast TracKer). 飛跡検出器. Input ＆ Process.
E N D
ATLAS実験における高速トラッキングトリガーシステムのシミュレーションによる最適化ATLAS実験における高速トラッキングトリガーシステムのシミュレーションによる最適化 千葉英誉, 木村直樹，寄田浩平 早稲田大学 ATLAS FTK Group 日本物理学会 2010年 春季大会 ３月２１日 岡山大学津島キャンパス 21aBE会場
FTK Barrel SCT 8Layer Pixel 3Layer ATLAS Trigger System ＆ ＦＴＫ(Fast TracKer) 飛跡検出器 Input＆Process 飛跡検出器内部の Pixel/SCTからHit情報のみ貰い，Trackを再構成する。 Output １GeV以上(|η|<2.5)の全てのTrackのPt,φ,η,Z,dをLVL2に渡す。 数週間前 Technical Proposal(p.93)を提出 現在TDAQ(USG)でレビュー中 1
FTKの目的 現行のデザイン L=1034[cm-2･s-1]@Atlfast WH(120)3×1034 PILEUP Impact Parameter Black→OffLIneRed→FTK 35 FTK有 FTK無 LVL2以降のPCファームで 領域を選択し(RoI),Trackを再構成 FTK挿入後 100μsec以下の処理速度で事象中の 全てのTrack(1GeV以上) を再構成 • Track情報の使用 • bジェット同定,τ同定を飛躍的に向上 @LVL2 ⇒QCD事象をより多く破棄することできる。 ⇒マルチジェットトリガーのPｔ閾値を下げられるなど。（右図） 2.RoI以外のオブジェクトをLVL2トリガーに加えられる 3. eやμトリガーにも応用可能 など b quark • 高ルミノシティ下でも安定したTrack情報の供給 • LVL2でより洗練されたAlgorithmが使用可能に light quark 2
2. Super Strip単位での Pattern Recognition → ”Road” (Associative Memory) FTKの基本動作原理 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
ＦＴＫシステム FTK overlap regions Processor Unit Pixel & SCT cluster finding split by layer Super Strip Data Organizer (DO) Associative Memory (AM) Data Formatter (DF) S-links RODs 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 Stage11Layer全てにおいて計算 Φ 16等分×η 4等分⇒64 Processor Unit 8(16) Processor Unit ⇒ 1 VME Crate Track Data ROB 但し,十分なOverlapを含んだRegion分け 4
DataOrganizer / 1Board=1分割分 SCT8L DO Hits of SCT 4 100MHz 100 MHz hit Hits of SCT 5 SS Hits of SCT 6 Hits of SCT 7 Hits of SCT 8 Hits of SCT 9 Hits of SCT10 Hits of SCT11 ☆LVL1のOutputは100kHzを仮定 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 5
AssociativeMemory "Pattern Recognition" AM WHbb L=3×1034[cm-2・s-1] Pile-up Road SS 100 MHz 200 200 平均Road数 3.1k →OutputOK 200 200 Input100MHz #SS<#HitからOK AM LAMB 200MHz From DO DOから全てのSS情報を 得てから処理開始!! <スペック> AMは４枚(LAMB)で処理する 1LAMB 200MHzの処理能力 4LAMB=4×200MHz=800MHz → 8k Roadまで耐える！ 6
DO From AM 100 MHz TF Road内のHitをFull ResolutionでFitする WHbb L=3×1034[cm-2・s-1] Pile-up <スペック> 0.5GHz×4=2GHz 平均Fit数 12.8k → OK road & hit 100MHz Fit2 TrackFitter / 1Board TF 500MHz Fit1 Fit3 2ndDO⇒TF Road HitとRoadをTFに送る 転送速度100MHz×4 4k以内のデータ量 3.1kRoadから転送可能 20kのFitCombination まで時間Lossなしに 処理することが可能 7
Timing Simulation <目的> 処理すべきInputの平均値が，各段階の平均処理速度を超えると処理が追いつかず，次のイベントの処理が遅れ続ける。 最初の1Hit情報が駆け抜ける時間 処理時間が遅れることによりTriggerのDead timeを生まないか確認のために ＜変数＞ ・Hit数 ・Boardの処理速度 ・Input，Output，Delay time Total時間を計算する！！ パイプラインなので，それぞれで 時間かかるところが全体の出力時間に影響！ Output Input DF DO DO TF HW AM 処理されてOutputの時間が延びる 全Hitを待つのでパイプラインではなくなる⇒時間がかかる 1data Fitも時間がかかる 8
Timing Simulationの式 DO 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→最初のデータが処理部分から出る時 EwOut→最後のデータが処理部分から出る時 EwIn→最後のデータが処理部分に入る時 9
End Word Out Time End Word Out Time １イベント内の最後のデータがOutputされる時の時間と定義 WHbb L=3×1034[cm-2・s-1] Pile-up • 処理できない場合 • 処理が蓄積して時間が増加する • 処理できる場合 • 蓄積した処理時間はリセットされる 平均Hit数＜Spec上限Hit数 処理時間は 蓄積され続けることはない (Deadtimeがない) 100KHzで100ev分走らせた結果 10
WHbb L=3×1034[cm-2・s-1] Pile-up Event example (Total Process Time) AMは全LayerのSSを全て使うので SSを待つ時に時間がかかる。 最大処理時間がかかっているEvent 前のイベントの処理によって遅れている WHbb L=3×1034[cm-2・s-1] Pile-up 8つのリージョンのうち最も遅いリージョンを最終的な事象プロセス時間とした 11
FTK processing time 現状のLVL2を想定したTrack再構成にかかる時間 ⇒RoIのみを1PC(Intel Core 2 Duo E84003.0GHz) でTrack計算しても 1RoIにmsecオーダーかかる。 μsecオーダーで処理することが可能！ WHbb L=3×1034[cm-2・s-1] Pile-up WHbb with Pile-up 平均24μsec 1RoI/1PC msec 12
ルミノシティ3×1034[cm-2・s-1]でも,現在のFTKのデザインでは平均Hit数，ルミノシティ3×1034[cm-2・s-1]でも,現在のFTKのデザインでは平均Hit数， Road数，Fit数がBoardの許容範囲内であることが分かった。 → その結果、100μsec以下で処理が可能である。 100Evで確かめた結果，Dead Timeなしに処理することが可能である。 纏め 展望 Time Simulationとしての予定 • DF，HWのデザイン最適化はまだ詰める必要がある。 • ⇒ DFやHWの処理時間を考慮し，デザインの最適化に反映。 • 2ndStageに関しても最適化を行う。 • シミュレーションの統計数を増やす必要あり。 FTK 全体としての予定 • 全領域のEfficiencyを高めるために記憶パターンやSuperStrip sizeの最適化 • RealDataの有効利用 • 2012年のShutdown時での挿入(プロトタイプ版)を想定して開発・制作中！ 13
