Upload
tia
View
70
Download
6
Embed Size (px)
DESCRIPTION
ATLAS 実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化. 千葉英誉 , 木村直樹,寄田浩平 早稲田大学 ATLAS FTK Group. 日本物理学会 2010 年 春季大会 3月21日 岡山大学津島キャンパス 21aBE 会場. FTK. Barrel SCT 8Layer. Pixel 3Layer. ATLAS Trigger System & FTK (Fast TracKer). 飛跡検出器. Input & Process. - PowerPoint PPT Presentation
Citation preview
ATLAS 実験における高速トラッキングトリガーシステム
のシミュレーションによる最適化
千葉英誉 , 木村直樹,寄田浩平早稲田大学
ATLAS FTK Group
日本物理学会 2010 年 春季大会
3月21日 岡山大学津島キャンパス 21aBE 会場
FTKFTKFTKFTK
1
1 GeV 以上 (|η|<2.5) の全てのTrack の Pt,φ,η,Z,d を LVL2 に渡す。
Output
飛跡検出器内部の Pixel/SCT からHit 情報のみ貰い, Track を再構成する。
Input & Process
飛跡検出器
Pixel 3Layer
Barrel
SCT 8Layer
ATLAS Trigger System & FTK (Fast TracKer)
数週間前 Technical Proposal(p.93) を提出
現在 TDAQ(USG) でレビュー中
FTK の目的現行のデザイン
1. Track 情報の使用
b ジェット同定 ,τ 同定を飛躍的に向上 @LVL2
高ルミノシティ下でも安定した Track 情報の供給
LVL2 でより洗練された Algorithm が使用可能に
100μsec 以下の処理速度で事象中の
全ての Track (1GeV 以上 ) を再構成
35
L=1034[cm-2 ・ s-1]@Atlfast
FTK有
FTK無
FTK 挿入後
2.RoI 以外のオブジェクトを LVL2 トリガーに加えられる
⇒QCD 事象をより多く破棄することできる。⇒ マルチジェットトリガーの P t閾値を下げられるなど。(右図)
2
WH(120)3×1034 PILEUP
Black→OffLIneRed→FTK
Impact
Parameter
light quark
b quark
3. e や μ トリガーにも応用可能 など
領域を選択し (RoI),Track を再構成
LVL2 以降の PC ファームで
FTK の基本動作原理1. Hit 情報をどの” Super Strip” に
モジュール Super Strip
Layer4
Layer3
Layer2
Layer1
Hit 位置
Road1 Road2
3. Track Fitting Stage< FTK の重要なパラメータ>
Super Strip size
3
素早く処理できる構成方法
1. SCT8Layer Fit Pixel+SCT 11Layer Fit⇒
2. Pixel 3L+SCT 4L Fit 11Layer Fit⇒
今回はコチラのみ
現状の方法 2つ提案中
2. Super Strip 単位でのPattern Recognition → ” Road” (Associative Memory)
Full Resolution の Hit 情報を使用
Layer の組み合わせpattern size に影響
位置するか分ける。 (Data Organizer)
FTKシステム
4
Pixel & SCT
RODs
Raw dataROBs
Data Organizer(DO)
Associative Memory(AM)
Track Fitter(TF)
FTK
Track DataROB
Hit
Super Strip
Road
X 64 (each region)
DataFormatter
(DF)
cluster findingsplit by layer
overlap regions
S-links
Processor Unit
Hit RoadInput
50kHz ~ 100kHz
1st Stage
SCT8Layer のみ計算
Processor Unit
2nd Stage 11Layer 全てにおいて計算Φ 16 等分 ×η 4 等分⇒ 64 Processor Unit
1等分に1 Board
Hit Warrior(HW)
8(16) Processor Unit 1 VME Crate⇒
但し , 十分なOverlap を含んだRegion 分け
Data Organizer / 1Board=1 分割分
☆1 つの DO に対し 100MHz の Clock で処理
☆Input & Output は Pipeline で 100MHz
☆LVL1 の Output は 100kHz を仮定
1 Layer 辺り,1000 Hit までなら
処理可能 (Input OK)
1 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
5Hits 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 MHz100MHz
DO
hit
SCT8L
SS
#SS<#Hit なので OK
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
1Ev を 10μs で処理が必要
Associative Memory "Pattern Recognition"
DO から全ての SS 情報を
得てから処理開始 !!
AM は4枚 (LAMB) で処理する
1LAMB 200MHz の処理能力
4LAMB=4×200MHz=800MHz
→ 8k Road まで耐える! 6
Road
AM
100 MHz
SS 200
200
200
200
From
DO
< スペック >
Input 100MHz #SS<#Hit から OK
平均 Road 数 3.1k
→Output OK
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
LAMB200MHz
AM
Track Fitter / 1Board
20k の Fit Combination
まで時間 Loss なしに
処理することが可能 7
Hit と Road を TF に送る2ndDO TF⇒
Road 内の Hit を Full Resolution で Fit する
TF
Fit1Fit2
Fit3
< スペック >
0.5GHz×4=2GHz
転送速度 100MHz×4
4k 以内のデータ量
3.1kRoad から転送可能
平均 Fit 数 12.8k → OK
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
From
AM
Road
100 MHz
DO
road & hit100MHz
TF 500MHz
Timing Simulation
処理すべき Input の平均値が,各段階の平均処理速度を超えると処理が追いつかず,次のイベントの処理が遅れ続ける。
Total 時間を計算する!!
<変数>・ Hit 数
・ Board の処理速度
・ Input , Output , Delay time
最初の 1Hit情報が駆け抜ける時間
DF DO AM DO TF HW
全 Hit を待つのでパイプラインではなくなる⇒時間が
かかる
パイプラインなので,それぞれで
時間かかるところが全体の出力時間に影響!Input
1data
Output
処理されてOutput の時間が延びる
Fit も時間がかかる
8
< 目的>
処理時間が遅れることにより Trigger の Dead timeを生まないか確認のため
に
9
Timing Simulation の式DO
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) + DelayEwOut(i)=max[ FwOut(i)+ProcTime×#Hit(i) , EwIn(i)+Delay ]
i=0-8(DO 8CPU) , ProcTime(ClockTime)=10nsec , InTime(Input time)=10nsec , Delay=40nsec
AM FwIn(i)=max[ min(DO_FwOut(i)) , max(Pre_EwOut(j))-10μsec , max(Pre_Pre_EwOut(j)) - 20μsec]
max(Pre_EwOut(j)) - 10μsec , max(#SS(i))×InTime+max(Pre_EwIn(j)) - 10μsecEwIn(i)= max[ max(DO_EwOut(i)) , max(#SS(i))×InTime + max(DO_FwOut(i)) ,
FwOut(i)= EwIn(j) + DelayEwOut(i)=FwOut(j)+max(ProcTime×#Road(j))
j=0-4(LAMB4 枚 ) , ProcTime(ClockTime)=5nsec , InTime(Input time)=10nsec , Delay=500nsec
max(#SS(i))×InTime+max(Pre_Pre_EwOut(j)) - 20μsec]
SecDO 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) + DelayEwOut(I)=max[ FwOut(I)+ProcTime×#Road(j) , EwIn(I)+Delay ]
I=0-4(DO 4 枚 ) , ProcTime(ClockTime)=5nsec , InTime(Input time)=5nsec , Delay=200nsec
TF 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) + DelayEwOut(k)=max[ FwOut(k)+ProcTime×#Fit(k) , EwIn(k)+Delay ]
k=0-4(TF 4 枚 ) , ProcTime(ClockTime)=2nsec , InTime(Input time)=5nsec , Delay=300nsec
FwIn→ 最初のデータが処理部分に入る時EwIn→ 最後のデータが処理部分に入る時
FwOut→ 最初のデータが処理部分から出る時EwOut→ 最後のデータが処理部分から出る時
End Word Out Time
処理できない場合
処理が蓄積して時間が増加する
処理できる場合
蓄積した処理時間はリセットされる
平均 Hit 数< Spec 上限 Hit数
10
処理時間は
蓄積され続けることはない
(Deadtime がない )
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
1イベント内の最後のデータが Output される時の時間と定義
End Word Out Time
100KHz で 100ev 分走らせた結果
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
AM は全 Layer の SS を全て使うので
SS を待つ時に時間がかかる。
11
最大処理時間がかかっている Event
前のイベントの処理によって遅れている
8 つのリージョンのうち最も遅いリージョンを最終的な事象プロセス時間とした
Event example (Total Process Time)
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
μsec オーダーで処理することが可能!
平均24μsec
12
WHbb L=3×1034[cm-2 ・ s-1] Pile-up
現状の LVL2 を想定した Track 再構成にかかる時間⇒RoI のみを 1PC(Intel Core 2 Duo E8400 3.0GHz)
で Track 計算しても 1RoI に msec オーダーかかる。
FTK processing time
msec
1RoI/1PC
WHbb with Pile-up
• ルミノシティ 3×1034[cm-2 ・ s-1] でも , 現在の FTK のデザインでは平均 Hit 数,
Road 数, Fit 数が Board の許容範囲内であることが分かった。 → その結果、 100μsec 以下で処理が可能である。• 100Ev で確かめた結果, Dead Time なしに処理することが可能であ
る。
• DF , HW のデザイン最適化はまだ詰める必要がある。 ⇒ DF や HW の処理時間を考慮し,デザインの最適化に反映。• 2nd Stage に関しても最適化を行う。• シミュレーションの統計数を増やす必要あり。
13
Time Simulation としての予定
FTK 全体としての予定• 全領域の Efficiency を高めるために記憶パターンや SuperStrip size の最適化
• Real Data の有効利用
2012 年の Shutdown 時での挿入 (プロトタイプ版 ) を想定して開発・制作中!
纏め
展望