TrigMoore: Presente e Futuro
1
Moore e MuId come algoritmi di Event
Filter in High Level Trigger (HLT)
Moore e MuId sono stati adattati per funzionare nel
framework di HLT
Due modalità di funzionamento:
Wrapped : pieno accesso all’evento, equivalente
al funzionamento offline
Seeded : ricostruzione a partire dalle RoIs
Non essendo ancora a disposizione l’output del
LVL2 e del LVL1 endcap, il seeding per
Moore/MuId è stato per il momento implementato a
partire dalle RoI passate dal LVL1 del barrel
MuRecoRoI  (h,f) e soglia di pt
RoI definita con (Dh,Df) = (0.2x0.2)
Efficienza
rispetto
al LVL1
wrapped
seeded
2
Moore e MuId come EF: test
dei tempi di esecuzione
pT = 8 GeV
Time (ms)
pT = 50 GeV
Time (ms)
Escludendo il 5% nelle code
con alto tempo di esecuzione
Sample
GeV/c
Time seeded
ms
average(rms)
P4 2.4GHz, RAM 1 Gb
Seeded mode
Approccio
conservativo (accesso
ai dati incluso)
pT = 300 GeV
Time (ms)
Muonbox
Time wrapped
ms
average(rms)
~2 sec
Tmax < 1 sec
pT = 10 GeV
no pileup
3
Reiezione di m da decadimenti di
K/p
Single m LVL1 rates
A bassi pt i decadimenti in volo da
process
K/p sono la sorgente dominante di m
 gli algoritmi in HLT hanno il compito di ridurre la
p/K
il rate di tali m
b
bb->mu6X per m prompt
c
K->mn, p->mn
Analisi ‘’offline’’
Tagli di reiezione
W
c2
match
Rate (KHz)
6 GeV
threshold
Rate(KHz)
20 GeV
threshold
16.8
2.1
4
1.1
2.4
0.5
0.009
0.08
| 1./Ptm – 1./PtID |
 Ptm > 4.3 GeV


c2 ID
del m identificato: il kink di
decadimento produce un fit nell’ID
peggiore
c2
del match : match cattivo tra l’inner
detector e le tracce dello spettrometro per
un m da un decadimento
 | 1./Ptm – 1./PtID | : m da decadimenti di
K/p ha un Pt più basso rispetto al
mesone rivelato nell’inner tracker
4
Reiezione di m da decadimenti di
K/p
Curve di efficienza
Atlas phy TDR (‘99)
@ vertice
5
Moore HLT- stato
Package in Trigger/TrigAlgorithms/TrigMoore
Interfaccia tra online ed ricostruzione offline
Funzionante nel framework HLT
Trigger menu, ipotesi da confermare (o escludere)
Due modi di funzionamento
Seeded
Ricostruzione a partire dalle RoI dei livelli precedenti
Wrapped
Full reconstruction, equivalente al funzionamento offline
Uso del package MuonIdentification per la ricostruzione al
vertice (MuID standalone)
6
Stiamo lavorando nel debug di:
Muon vertical slice
Uso delle “Muon features”
Finora il funzionamento
seeded ha fatto uso solo
delle informazioni del LVL1
Utilizzo di informazioni del
secondo livello di trigger
Moore
LVL2 (muFast)
LVL1
7
Da fare
In ordine di priorità almeno per i primi passi
Ricostruzione combinata
Uso dell’inner detector e di MuidCombined (lavoro cominciato)
Ricostruzione a partire dal formato ByteStream (in progress)
Moore nel testbed
Combined testbeam (milestone ?)
Steering
Valutazione delle rates di trigger di muone singolo LVL1-LVL2-EF
Mappe per il RegionSelector estese ad Endcaps ed alle tecnologie
TGC/CSC
Miglioramento della velocità di esecuzione
Feedback per migliorare la ricostruzione offline
Isolamento di possibili punti di iterazione (loop per migliorare la
ricostruzione)
8
Da fare
Valutazione della degradazione della ricostruzione e della
probabilità di ricostruire fakes in funzione dell’intensità del
background
Studi preliminari “OFFLINE” con il pile-up e i fakes da K/p (fatto con
campione 100GeV + bkg)
Studi in TrigMoore (ONLINE)
Feedback per migliorare la ricostruzione offline
Utilizzo delle informazioni LVL2 del Tile (A livello offline c’è del
lavoro in progress nel gruppo Moore)
9
Da fare
Ancora sulla velocità di esecuzione e sul miglioramento delle
performances
Utilizzo informazioni di LVL2 per ora non utilizzate, es. pT stimato, per
ottimizzare i tagli effettuati dal CombinationMaker.
Accesso ai dati calibrati (Valutazione tempi di accesso e impatto sulle
performances di ricostruzione)
EndCaps impatto- estensione
STACO quando il package sarà disponibile – dopo febbraio?
Valutazione rates per eventi complessi
Ottimizzazione trigger menu e strategie di ricostruzione in funzione
del rapporto tempi/performances
Cosmici – Task molto scoperta! E’ stato espresso interesse (scorso
maggio, ma non ancora operativo) da parte di alcune persone di
Nickef, almeno per la versione offline
10
Note
Lo sviluppo di TrigMoore avviene parallelamente a Moore (molto del
codice è oggettivamente condiviso)
Le continue migrazioni all’interno del software Atlas Event Data ModelGeometry Model – G3->G4 – Unificare le interfaccie di tracciamento –
Cambio di unità di misura – ecc… impongono continue migrazioni,
adattamenti, tests del codice.
Fine-tuning anche a livello di performances del package offline deve
essere fatto.
Physics validation Non esiste un ufficiale gruppo di analisi all’interno del
gruppo Moore. In ATLAS questo gruppo esiste! Ci sono stati finora
sforzi volontari su alcuni canali volti a riprodurre, fornire dei plots di
riferimento in termini di efficienze, risoluzioni, ricostruzione di massa
invariante, ecc.
Personalmente non ritengo che all’interno del gruppo sviluppo debba
avvenire l’analisi ufficiale di un canale di fisica ATLAS, ma nulla toglie
che una persona che collabora nello sviluppo partecipi o collabori ai
gruppi di Physics Analysis. Questo di fatto sta succedendo per alcuni
casi. Non ancora per il Trigger, del resto la full slice comincia ora.
11