1 TrigMoore: Presente e Futuro

2 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  (  ) e soglia di pt RoI definita con (  ) = (0.2x0.2) Efficienza rispetto al LVL1 wrappedseeded Moore e MuId come algoritmi di Event Filter in High Level Trigger (HLT)

3 Moore e MuId come EF: test dei tempi di esecuzione P4 2.4GHz, RAM 1 Gb Seeded mode Approccio conservativo (accesso ai dati incluso) Escludendo il 5% nelle code con alto tempo di esecuzione p T = 8 GeV p T = 50 GeVp T = 300 GeV Muonbox p T = 10 GeV no pileup ~ 2 sec Tmax < 1 sec Time (ms) Time seeded ms average(rms) Time wrapped ms average(rms) Sample GeV/c

4 Reiezione di  da decadimenti di K/  A bassi pt i decadimenti in volo da K/  sono la sorgente dominante di   gli algoritmi in HLT hanno il compito di ridurre la il rate di tali  process Rate (KHz) 6 GeV threshold Rate(KHz) 20 GeV threshold  /K b 41.1 c W Single  LVL1 rates bb->mu6X per  prompt K-> ,  ->  Analisi ‘’offline’’ Tagli di reiezione  Pt  > 4.3 GeV     ID del  identificato: il kink di decadimento produce un fit nell’ID peggiore     del match : match cattivo tra l’inner detector e le tracce dello spettrometro per un  da un decadimento  | 1./ Pt  – 1./ Pt ID | :  da decadimenti di K/   ha un Pt più basso rispetto al mesone rivelato nell’inner tracker  2 match | 1./ Pt  – 1./ Pt ID |

5 Curve di vertice Atlas phy TDR (‘99) Reiezione di  da decadimenti di K/ 

6 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)

7 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 LVL1 LVL2 (muFast) Moore

8 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)

9 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/  (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)

10 Da fare Ancora sulla velocità di esecuzione e sul miglioramento delle performances Utilizzo informazioni di LVL2 per ora non utilizzate, es. p T 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

11 Note Lo sviluppo di TrigMoore avviene parallelamente a Moore (molto del codice è oggettivamente condiviso) Le continue migrazioni all’interno del software Atlas Event Data Model- Geometry 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.