ATLAS Distributed Analysis Lamberto Luminari CSN1 – Roma, 16 Maggio 2006

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis2 Sommario Event Data Model: tipi di dati, streaming, distribuzione Distributed Data Management (DDM): gestione dataset, replica dei dati Distributed Analysis: schema generale, data selection and processing interfaccia utente job submission tool Virtual Organization (VO): organizzazione degli utenti ATLAS: Stato dei tool necessari per l’analisi Situazione manpower INFN Conclusioni

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis3 Event Data Model: Tipi di dati Nelle varie fasi di ricostruzione e analisi ATLAS utilizza diversi tipi di dati: RAW Data: sono i dati in output dal sistema di trigger e acquisizione formato “Byte-Stream” ~1.6 MB/evento Event Summary Data (ESD): dati prodotti dal processo di ricostruzione (tracce ricostruite e hit relativi, celle e cluster nei calorimetri, combined reconstruction objects etc...) rappresentazione object-oriented (POOL/ROOT) ~0.5 MB/evento (nominale; attualmente > 1. MB) Analysis Object Data (AOD): rappresentazione ridotta degli eventi, contenente gli oggetti “fisici” ricostruiti (elettroni, muoni, jet, etc...) e altri elementi utili per l’analisi rappresentazione object-oriented (POOL/ROOT) ~100. KB/evento Tag Data (TAG): informazioni sintetiche per identificazione e selezione degli eventi formato DB relazionale per ricerche veloci + formato ROOT per istogrammazione veloce ~1. KB/evento ~15. kSI2k*s /evento ~0.5 kSI2k*s /evento

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis4 Event Data Model: Flusso di dati da TDAQ La rate di eventi in uscita dal sistema di Trigger e Data AcQuisition è di ~200 Hz, all’incirca indipendente dalla luminosità Gli eventi vengono suddivisi in stream e scritti in file di <2. GB (~1000 eventi * ~1.6 MB/evento) Attualmente sono previste 4 classi di stream: express stream, con gli eventi “più interessanti” calibration stream, con i dati necessari per le calibrazioni dei detector debugging stream, contenente eventi che presentano problemi event stream, suddivisa (secondo le prime indicazioni) nelle seguenti sotto- stream inclusive: Muon triggers Electromagnetic triggers (electrons and photons) Hadronic triggers (jets, taus, missing energy) B-physics triggers Minimum bias e altri prescaled triggers per monitoring I file vengono organizzati in dataset, collezioni di eventi con caratteristiche simili (statisticamente equivalenti) da processare solitamente insieme.

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis5 Event Data Model: Replica e distribuzione dati Per rendere efficiente l’accesso ai dati per ricostruzioni (nei Tier-1) e analisi (nei Tier-1/2) è previsto un certo livello di ridondanza, con repliche dei dati in più Tier. RAW:   Dati originali al Tier0   Replica completa nell’insieme dei Tier-1 (~1/10 per Tier-1) ESD:   Gli ESD prodotti con la ricostruzione primaria risiedono al Tier-0   Versioni successive degli ESD prodotte nei Tier-1 (~1/10 per Tier- 1) e replicate in due copie (alla fine in ogni Tier-1 1/5 degli ESD ) AOD:   Replicati completamente in ogni Tier-1   Replicati parzialmente nei Tier-2 (~1/3 – 1/4 in ciascun Tier-2) TAG:   I database dei TAG sono replicati in tutti i Tier-1 (ORACLE)   Repliche parziali/totali dei database TAG nei Tier-2 (MySQL)   In ciascun Tier-2 risiedono i file ROOT/POOL dei TAG corrspondenti agli AOD ospitati nel sito. Campioni di eventi di tutti i tipi possono essere memorizzati nei vari Tier per studi particolari o sviluppo software. Event Builder Event Filter Tier3 10 GB/s 320 MB/s ~ 150 MB/s ~10 ~50 Mb/s ~PB/s Tier2~3-4/Tier1 Tier0 Tier1

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis6 Distributed Data Management Model Nel 2005 ATLAS ha rivisto il suo Grid distributed systems (data management, production, analysis), in accordo con il Baseline Service Working Group LCG Attualmente il Distributed Data Management (DDM) system di ATLAS (DQ2) si basa su: Cataloghi di dataset centrali, suddivisi (replicati?) in vari DB per facilitare l’accesso Dataset Repository, Dataset Content Catalog, Dataset Location Cat., Dataset Subscription Cat. Cataloghi di file distribuiti (locali) Non ci sono cataloghi globali di file: la risoluzione dei file fisici è fatta localmente a partire dai dataset su cataloghi (specifici per ogni Grid) che contengono solo i file salvati i quel sito Sistema automatico di trasferimento dati: dataset subscription system Subscriptions phys.esd.001: CERN, CNAF, BNL phys.aod.001: CERN, CNAF CERN phys.raw.001 phys.esd.001 phys.aod.001 CNAF phys.esd.001 phys.aod.001 BNL phys.esd.001 Automatic updates

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis7 Distributed Data Management System Nel mondo ideale (network “trasparente”) non ci sarebbe bisogno di definire associazioni default Tier-1 – Tier-2 In pratica, risulta conveniente partizionare la Grid cosi’ da avere data path preferenziali tra Tier-1 e Tier-2 da utilizzare per le operazioni privilegiate I canali per File Transfer Service sono definiti solo per i data path preferenziali Tutti gli altri trasferimenti dati avvengono attraverso le normali network routes La clusterizzazione facilita la suddivisione delle varie operazioni di analisi, a seconda delle loro caratteristiche, tra Tier-1 e Tier-2 associati Inoltre in questo modello, un certo numero di data services sono installati solo nei Tier-1 (ma servono anche per i Tier-2“associati”): FTS channel server (per entrambe le direzioni) Local File Catalog unico per il cluster (ache per i file residenti nei Tier-2) Channel T1-T2 Tier-1 Tier-0 Tier-2 Local File Catalog LFC Tier-1 FTS server FTS server FTS server LFC Channel T0-T1 Channel T1-T1

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis8 Distributed Analysis: Schema generale Lo schema descritto è quello ad oggi più probabile per l’analisi distribuita: Non tutte le sue parti sono allo stesso livello di maturità e “ufficialità” Non è stato ancora testato su scala significativa Scenario di riferimento attuale: Le attività di analisi vanno in parallelo alla produzione Necessità di Job Priorities, Short Queues, Fair Share delle risorse, … I dati per l’analisi saranno (parzialmente) disponibili su tutti i Tier-1 e i Tier-2 AOD & ESD (AOD completi di 1 anno = ~200 TB) I Tier-1 possono accogliere scheduled (group) analysis jobs I Tier-2 ospitano individual analysis jobs La procedura standard prevede la selezione degli eventi da TAG e l’analisi sugli AOD degli eventi selezionati. Gli utenti (tramite Grid tools) invieranno jobs dove sono i dati ed estrarranno le informazioni più rilevanti: Tipicamente nella forma di NTuple o simili Queste informazioni saranno usate localmente in modo interattivo

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis9 Distributed Analysis: Data selection L’utente apre una sessione di analisi tramite un’interfaccia che gli permette di eseguire tutte le operazioni connesse all’analisi. I passi logici da compiere (manualmente uno alla volta o in modo automatico via script o form) sono: Interrogazione del Dataset Content Catalog che contiene i metadata per ogni dataset del tipo desiderato per trovare quelli che gli interessano Esempio di query: dammi la lista dei dataset TAG con trigger 2  del 2009, versione x.y.z Tramite il Dataset Location Catalog viene localizzato il sito dove risiede il dataset In ogni Tier1 è poi disponibile un catalogo locale (Local File Catalog) per passare dai dataset ai singoli files residenti sul cluster Tier1 + Tier2-associati Applicazione dell’ algoritmo di selezione sui dataset scelti e produzione di una lista di eventi accettati Dataset Content Catalog Dataset C “TAG, 2 , 2009,…” Event 1, Event 3, Event 6 Selection criteria Dataset Location Catalog LFC Dataset C: File 1 File2 CNAF

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis10 Distributed Analysis: Data processing Selezionati gli eventi, l’utente sottomette alla Grid i suoi job di analisi tramite il Work Load Manager (WLM), interfacciato ai cataloghi Tramite il Dataset Location Catalog vengono localizzati i siti dove risiedono i dataset contenenti gli eventi accettati In ogni Tier1 è poi disponibile un catalogo locale (Local File Catalog) per passare dai dataset ai singoli files residenti sul cluster Tier1 + Tier2-associati Un job può dare come output una nuova collezione di eventi, che può essere registrata come nei cataloghi e acceduto successivamente Un job può dare come output una nuova collezione di eventi, che può essere registrata come nuovo dataset nei cataloghi e acceduto successivamente Il singolo utente può anche estrarre dall’insieme dei dati analizzati (ad es. in formato AOD) dei file di Derived Physics Data (tipo n-tupla o altro formato privato) che potrà poi analizzare interattivamente in locale. Submission tool Event 1, Event 3, Event 6 Dataset A: File 1 File 2 LFC Dataset B: File 3 File 4 LFC Dataset C: File 5 File 6 Work Load Manager Job 3 Computing Element Job 2 Job 1 Computing Element DPD/N-tuple: File 5 File 6 DPD/N- tuple: File 3 File 4 DPD/N- tuple: File 1 File 2 Dataset Location Catalog CNAF CERN

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis11 Distributed Analysis: Interfaccia utente Dal punto di vista implementativo, GANGA: permette di accedere a risorse locali o remote (Grid) in modo uniforme; essendo sviluppato nel contesto di ATLAS e LHCb, offre supporto built-in per applicazioni basate sul framework Gaudi/Athena; ha una architettura a componenti che ne permette agevolmente l’estensione ad altre funzionalità; è scritto in Python. GANGA (Gaudi/Athena and Grid Alliance) è un’interfaccia utente easy-to-use per le operazioni connesse all’analisi: la selezione degli eventi e la identificazione dei siti dove trovare i dataset relativi lo splitting del job di analisi in job più piccoli da eseguire in parallelo sulla Grid e il merging dei risultati

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis12 Distributed Analysis: Job Submission Il sistema di sottomissione dei job assolve alle seguenti funzioni: Individua le risorse ottimali (CPU vs dati) sulle infrastrutture di calcolo Stabilisce i parametri corretti per l’esecuzione a seconda del flavour di Grid Esegue single job o bulk submission Esistono vari tool, in genere legati ad uno o più flavour di middleware di Grid; l’obiettivo è quello di usare ProdSys, il tool già utilizzato con successo per sottomettere job a tutte le infrastrutture Grid utilizzate da ATLAS (LCG, OSG, NorduGrid) per il Data Challenge 2: 20 nazioni 69 siti ~ job per il Physics Rome Workshop: 22 nazioni 84 sites > job

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis13 VO (Virtual Organization): Attributi utente L’analisi distribuita comporta l’accesso da parte di molti utenti a grandi quantità di risorse e dati in vari siti necessità di regolamentare le modalità di accesso, per poter assicurare che lo share di risorse allocato alle diverse attività e a disposizione dei vari utenti sia coerente con le priorità decise dall’esperimento A seconda dell’attività, gli utenti di ATLAS sono caratterizzati da alcuni attributi, in base ai quali vengono assegnati privilegi e disponibilità di risorse: Ruoli: Grid software administrator Production manager Normal user Gruppi: Physics Combined performance Trigger Computing & central productions Funding: Countries and funding agencies

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis14 VO: Gruppi I gruppi (e sottogruppi) di attività attualmente previsti sono: Physics: phys-beauty, phys-top, phys-sm, phys-higgs, phys-susy, phys-exotics phys-hi, phys-gener, phys-lumin Combined performance perf-egamma, perf-jets, perf-flavtag, perf-muons, perf-tau Trigger:trig-pesaDetectors: det-indet, det-larg, det-tile, det-muon Computing: soft-test, soft-valid, soft-prod, soft-admin Gen-user E’ prevista, almeno inizialmente, una situazione conservativa: la maggior parte di questi gruppi (e relative priorità) saranno riservate solo ai Group production managers i Software installers saranno in soft-admin tutti gli altri utenti saranno in gen-user

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis15 Stato dei tool (1) Il Distributed Data Management consiste di tools sviluppati da ATLAS (DQ2) e di tool comuni LCG DQ2 è ora in corso di integrazione col PRODuction SYStem test di produzione realistici nel corso del Computing System Commissioning in autunno Per quando riguarda il management dei Jobs (WLM, sviluppato da INFN in EGEE) le funzionalità di base sono presenti: Gli sviluppi ancora necessari sono abbastanza contenuti e ben identificati Occorre ancora lavoro di integrazione, test, distribuzione sui siti, debugging Bisogna verificare che il sistema scali e sia sufficientemente robusto I test fin qui fatti sono positivi (rate standard di 4000 jobs da 20 ore con errori WMS dell’ordine di qualche %) Gli esperti, sia ATLAS che EGEE, sono INFN, in contatto molto stretto ed efficiente Il mantenimento e una limitata evoluzione del WLM devono essere garantiti nel tempo C’è competizione con altri sistemi: CondorG, usato con successo assieme a WLM nelle produzioni su LCG, e PANDA oggi usato solo in US ma che potrebbe tentare espansione Dal punto di vista ATLAS la competizione aiuta Dal punto di vista INFN siamo in buona posizione nella competizione

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis16 Stato dei tool (2) Per l’accounting e la prioritizzazione delle attività a livello di utente e gruppo si stanno sviluppando tool basati sul sistema di autenticazione e autorizzazione VOMS, sviluppato da INFN Un accounting con la granularità richiesta non è ancora disponibile in produzione La combinazione di due tool, APEL (sviluppato in UK) + DGAS (sviluppato da INFN e installato in test su GRID INFN), sembra offrire tutte le funzionalità richieste e un accordo sembra raggiunto in questo senso E’ urgente un sistema che permetta almeno una coesistenza efficiente fra job di simulazione, di analisi e di servizio (tipo installazione sw), superando il completo “egualitarismo” attuale Un WG EGEE sta elaborando soluzione comune per i diversi esperimentiin 2 step: 1. 1.Sistema con componenti quasi tutti disponibili ora, ma con funzionalità limitata all’urgenza Si conta che sia disponibile in produzione in un paio di mesi 2. 2.Sistema pi ù completo per autunno 2006 Unico candidato è gPbox (sviluppato da INFN), che però deve ancora passare per tutta la sequenza integrazione-certificazione-installazione distribuita, test intensivo… La capacità del sistema di accounting di trattare in modo completo i dati dell’enorme numero di job previsti deve essere dimostrata entro la primavera 2007

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis17 Situazione manpower INFN Sul DDM (DQ2), che potrebbe essere la parte più critica dell’intero sistema di analisi distribuita, sarebbe desiderabile avere un ruolo maggiore; Oggi solo S.Campana (al CERN) ha un buon contatto con gli sviluppatori e G. Negri (al CNAF) conosce DQ2 Per quanto riguarda l’interfaccia ad ATLAS del WLM, gli esperti ci sono (E.Molinari, D.Rebatto, S. Resconi a Milano, S.Campana al CERN e G. Negri al CNAF) ma sono overloaded dalla responsabilità concorrente dei nuovi sviluppi e loro tests e dalla produzione corrente su LCG + EGEE… Si sta cercando di trasferire almeno in parte la produzione, ma non è facile data la incompleta automazione del sistema Per quanto riguarda l’interfaccia ad ATLAS di VOMS, la situazione è buona: A. De Salvo (Roma1) è il VO manager di ATLAS e il massimo esperto disponibile (in estremo overload); ci sono inoltre A. Barchiesi (Roma1) e new entries da CNAF e Bologna Il nuovo fellow LCG al CERN da affiancare a S.Campana, un nuovo assegno di ricerca al CNAF (al posto di Negri) e un nuovo contratto a G.Negri (AR CNAF scade in gennaio) sono il minimo indispensabile per continuare a funzionare bene con WLM e VOMS, acquisendo ulteriore competenza in DDM. Si lavora per inserire nuove forze (ad es., da Udine avremo un dottorando informatico che concorre a una borsa tecnologica INFN e da Bologna c’è qualche possibilità ulteriore) ma non è facile avere maggiore coinvolgimento dei gruppi quando il sistema è ancora “per esperti”

CSN1 - Roma 16/05/2006Lamberto Luminari - ATLAS Distributed Analysis18 Conclusioni Le componenti necessarie per l’analisi distribuita di ATLAS sono disponibili fra ora (la maggior parte) e l’autunno Una frazione consistente dei tools sono stati sviluppati da INFN GRID e ne deve essere assicurata nel tempo la manutenzione e limitate evoluzioni Ci sarà molto lavoro da fare per portare il sistema di analisi a completa maturità Qualche componente potrebbe rivelarsi non adatta e/o non scalare bene Il modello di analisi è prudente e ammette vari scenari di fall-back La distribuzione dei dati e dei cataloghi permette di evitare ingorghi in vari modi L’INFN ha il maggior coinvolgimento e la maggiore esperienza dopo il CERN Ma gli esperti in queste tecnologie sono pochi, in overload, e precari Imperativo non perderli e fare acquisire esperienza nel campo a più persone “stabili” EGEE-2 finisce fra 2 anni e se non si trovano soluzioni alternative ATLAS-INFN perde più della metà dei suoi esperti N.B. Pur non essendo oggetto di questa presentazione, va sottolineato che prerequisito per il successo della comunità italiana nell’analisi di ATLAS è una infrastruttura di calcolo (Tier-1 + Federazione Tier-2) in grado di fornire risorse e servizi in modo affidabile ed efficiente.