Nuove Tecnologie: Trigger, Computing & Software Massmimo Caccia, Luca Lista Uni. Insubria & INFN Milano, INFN, Napoli.

Luca Lista, INFN2 Agenda del 12 Aprile Tecniche di trigger di primo livello ad LHCFrancesca Pastore Trigger di alto livello ad LHCSimone Gennai Esperienza sul calcolo di CDFGabriele Compostella Il modello di calcolo di AtlasAlessandro De Salvo Il modello di calcolo di CMSDaniele Bonacorsi Infrastrutture di calcolo su GRID in ItaliaVincenzo Miccio Tecnologie software per l'analisi off-lineLeonardo Carminati

Trigger di L1 & HLT ad LHC

Luca Lista, INFN4 LHC Event Rates Acceptable storage rate: Hz Max DAQ 100 kHz Machine Rate: 40 MHz pp interactions Particle mass (GeV/c 2 ) nominal LHC luminosity Pile-up On-line trigger selection Select 1:4x10 5 Decide every 25 ns! Off-line analysis Signals L = anno = collisioni = ~ 2 PByte

Luca Lista, INFN5 Atlas/CMS: Trigger overview Different division of resources for processors and bandwidths 75 kHz ~ 2 kHz ~ 200 Hz Rate ~ 10 ms 2.5 s ATLAS: 3 physical levels 100 kHz ~100 Hz Level decision latency Level output rate Legenda: 3.2 s 40 MHz (200 GB each) (Event builder) 500 Gb/s (Event filter) Gbit/s PetaB archive Region of interest: 2/event HLT partial event reconstruction Level-1 Hardware High Level Triggers (HLT) Software Event: 1 MB (1 TB/day)

Luca Lista, INFN6 L1 Trigger Table (Atlas) High luminosity trigger table GeV cut: 95% at 31 GeV, 1.9 kHz expected Selezione su uno o pochi oggetti fisici di chiara segnatura –Le soglie possono dipendere dalle condizioni di luminosità Selezione raffinata in HLT con la ricostruzione tipo off-line

Luca Lista, INFN7 Trigger del Tau a CMS (H +, …) Isolamento (HLT): ricostruzione regionale e parziale delle tracce Pattern calorimetrici (L1) Rate finale < 3 Hz Alcuni aspetti inizialmente trascurati potrebbero essere molto importanti Es.: decodifica delle informazioni del tracker solo a livello regionale?

Modelli di calcolo: CDF, Atlas, CMS

Luca Lista, INFN9 Volume di dati di CDF ~ 2 ~ 5.5 ~ 9 ~ 20 ~ 23 Estimated CPU needs Collected Data 30 mA/hr 25 mA/hr 20 mA/hr 15 mA/hr Integrated Luminosity (fb -1 ) ) By FY07: Double data up to FY06 By FY09: Double data up to FY /30/03 9/30/04 9/30/05 9/30/06 9/30/07 9/30/08 9/30/09 oggi

Luca Lista, INFN10 Evoluzione del calcolo di CDF Modello di calcolo inizialmente pensato per un ambiente centralizzato (FNAL) Successivamente evoluto verso un modello distribuito (compreso CNAF) Uso di GRID integrato nel sistema in corso dopera Superati autonomamente da CDF una serie di limiti di GRID dovuti alla fase di sviluppo –Es.: protezione da job falliti (pilot job)

Luca Lista, INFN11 CDF Usage of LCG resources Sites accessed trough LcgCAF INFN-PadovaItaly INFN-CataniaItaly INFN-BariItaly INFN-LegnaroItaly INFN-Roma1Italy INFN-Roma2Italy INFN-PisaItaly FZK-LCG2Germany IFAESpain PICSpain IN2P3-CCFrance UKI-LT2-UCL-HEUK LiverpoolUK CDF

Luca Lista, INFN12 Uso di GRID ad LHC CDF può usare la GRID –approfittando delle risorse quando non sono usate da LHC LHC DEVE usare la GRID –Modello di calcolo disegnato come distribuito sin dallinizio La tecnologia GRID non può fallire!

Luca Lista, INFN MB/s The ATLAS Computing Model Tier2 Centre ~200kSI2k Event Builder Event Filter ~159kSI2k T0 ~5MSI2k US Regional Centre Spanish Regional Centre (PIC) UK Regional Centre (RAL) Institute 4Institute 3Institute 2 Workstations 10 GB/sec 450 Mb/sec Some data for calibration and monitoring to institutes Calibrations flow back Average Tier 2 has ~25 physicists working on one or more channels Roughly 3 Tier 2s should have the full AOD, TAG & relevant Physics Group summary data Tier 2 do bulk of simulation Physics data cache ~Pb/sec ~ 300MB/s/T1 /expt Tier2 Centre ~200kSI2k 622Mb/s Tier 0 Tier 1 Desktop Tier2 Centre ~200kSI2k Tier 2 Analysis Simulation Reprocessing Group analysis Calibration First processing 622Mb/s Italian Regional Centre (CNAF) Institute 1 Modello gerarchico a Tier

Luca Lista, INFN14 CMS Computing model Il problema della gerarchia è stato superato nel modello di calcolo di LHC…

Luca Lista, INFN15 Infrastruttura GRID oggi in Italia più di 40 centri di ricerca coinvolti le risorse sono raggiungibili attraverso servizi specifici per ciascuna VO la maggior parte di essi (~30) sono coinvolti anche a livello internazionale (EGEE/LCG) gli altri sono accessibili attraverso servizi di grid su scala nazionale

Luca Lista, INFN16 Uso di GRID da parte di LHC Production + Analysis jobs over last 3months

Luca Lista, INFN17 Trasferimento dati 2006/2007 CMS CSA06: ~1 PB in 1 months to numerous sites CMS LoadTest 2007: ~2.5 PB in 1.5 months to numerous sites

Luca Lista, INFN18 La vita di un Job su GRID Chi si avvicina per la prima volta allanalisi in LHC può aver bisogno di uniniziazione –per quanto esistano layer software intermedi…

Modelli di Analisi

Luca Lista, INFN20 Punti chiave di un modello di analisi Modello di calcolo centralizzato o distribuito Formato ed accessibilità dai dati –Possibilità di aggiungere nuovi contenuti ai dati dellevento (User Data) –Accessibilità interattiva (via ROOT) Frameworks di analisi vs analisi ROOT- based privata –portabilità e condivisione del codice di analisi e uso di tools comuni

Luca Lista, INFN21 Formati dati: Data Tiers

Luca Lista, INFN22 Lesperienza di BaBar E stata la prima esperienza reale di un esperimento che funziona in factory mode Primo modello di calcolo (CM1): –Difficoltà ad accedere ai dati Reco oltre agli AOD (… Objectivity a parte …) –Uso sub-ottimale di risorse di CPU e disco impegnate in produzione di dati in formati specifiche per lanalisi (ntuple) –Scarsa connessione tra codici di analisi e ricostruzione difficoltà a trasportare codice di analisi come tool comune Computing Model II (CM2, 2003) –Migliore integrazione tra Reco e AOD (mini/micro) –Skim di analisi prodotti in modo centralizzato e poi distribuiti Uso ottimizzato delle risorse –Aggiunta agli AOD di User Data –Accesso interattivo ai dati Usati limitatamente in BaBar, ma con grosse potenzialità …

Luca Lista, INFN23 Tutti i formati, dai RAW data agli AOD e anche i dati definiti dall'utente sono accessibili sia in batch (framework) che in interattivo (ROOT). L Event Data Model può essere usato come formato finale di analisi: niente ntuple! CMS ha raccolto appieno lesperienza di BaBar e CDF gSystem->Load("libFWCoreFWLite") AutoLibraryLoader::enable() TFile f("reco.root") Events.Draw("tracks.phi() – tracks.outerPhi(): tracks.pt()", "tracks.pt()<10") Interfacce uniformi agli oggetti ricostruiti ovunque (reco/aod) : dovunque si definisce pt() (non getPt() ) per accedervi Luniformità permette di scrivere algoritmi generici (selettori, filtri…) validi per oggetti diversi via templates in modo molto semplice. Un modello a Candidati Particella rende omogenei una serie di strumenti di alto livello (analisi combinatoriale, constrained fit, etc.) Il modello di analisi di CMS ptpt

Luca Lista, INFN24 Electron TauJet Muon PJet TrackP Cluster TruthP ME T AOD Photon El_p_T[]Ph_p_T[]Mu_p_T[] El_eta[]Ph_eta[]Mu_eta[] MissingEtTop_mass[]M_eff DPD (Ntuple) AOD Building Copy select info Slim: make lighter objects. Thin (eg remove some truth particles). 1. Framework Analysis Recalibrate Select Obj/Remove overlap Complicated Tasks Calculate DPD Athena Athena/EV ROOT 2. Out-of-Framework Analysis Further Analysis Make plots Event Data + User Data Histograms egamma TauObj CMuon Jet TTrack Cells Cluster Hits Truth ESD ME T 2 Stage User Analysis Il modello di analisi di Atlas

Luca Lista, INFN25 Nel modello di analisi attuale AOD non sono leggibili da ROOT ATLAS ha scelto un modello per sostenere la schema evolution basato sulla separazione Transient & Persistent difficile da esportare in ROOT D0 ha già evidenziato limiti di questo approccio per lanalisi Possibilità di leggere gli AOD da ROOT: accesso alle classi transienti a partire da quelle persistenti. I vantaggi sono evidenti: No ntuple centralizzate: lAOD è già ROOT readable (CM è al sicuro). Lutente può usare direttamente ROOT senza usare il framework… Oppure usare il framework e avere molti benefici: Costruire DPD più semplici e usare un set di tool comuni Modello di analisi elegante dove input/output sono unificati simile a CMS e BaBar mantenendo la schema evolution: ESD Athena AOD AOD Athena DPD AOD or DPD ROOT Plots DPD Athena DPD Prossime evoluzioni in Atlas

Luca Lista, INFN26 Conclusioni La complessità degli esperimenti LHC si riscontra anche in trigger, computing e software Il modello di calcolo di LHC dipende criticamente dal funzionamento di GRID –Ed in Italia è fondamentale il ruolo del Tier1 al CNAF –CDF ci ha mostrato che si può usare GRID (e il CNAF) efficacemente per fare analisi Il software è in continua evoluzione, con rapide ri- ingegnerizzazioni e sostituzioni di parti fondamentali –CMS : Framework, Event Data Model, Data Management –ATLAS: Importanti evoluzioni nel modello AOD Lintegrazione di tutti i componenti è un aspetto fondamentale per scoprire rapidamente problemi –I Data/Service Challenge sono test importanti dellintera catena