Il Computing di ATLAS (aspetti interessanti per chi fa analisi) Tommaso Lari INFN Milano Tutorial sull’analisi distribuita Roma3, Febbraio 2008

T. Lari: Analisi distribuita Roma, Febbraio Il Computing Model di ATLAS Tier-0 (CERN) Tier-0 (CERN) Archivio dei RAW data e distribuzione ai Tier1 Prompt Reconstruction dei dati in 48 ore Prompt Reconstruction dei dati in 48 ore 1 st pass calibration in 24 ore 1 st pass calibration in 24 ore Distribuzione output ricostruzione ai Tier-1: ESD, AOD e TAG Distribuzione output ricostruzione ai Tier-1: ESD, AOD e TAG Il modello di calcolo per l’offline e l’analisi di ATLAS è quello gerarchico multi-Tier. Modello a cloud: ad ogni Tier-1 sono associati alcuni (3 o 4) Tier-2 spesso in base a considerazioni geografiche. 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 Tier-1 (10) Tier-1 (10) Accesso a lungo termine e archivio di un subset di RAW data Copia dei RAW data di un altro Tier-1 Copia dei RAW data di un altro Tier-1 Reprocessing della ricostruzione dei propri RAW data con parametri di calibrazioni e allineamenti finali 2 mesi dopo la presa dati Reprocessing della ricostruzione dei propri RAW data con parametri di calibrazioni e allineamenti finali 2 mesi dopo la presa dati Distribuzione AOD ai Tier-2 Distribuzione AOD ai Tier-2 Archivio dati MC prodotti nei Tier-2 Archivio dati MC prodotti nei Tier-2 Analisi dei gruppi di fisica Analisi dei gruppi di fisica Tier-2 Tier-2 Simulazione Monte Carlo Simulazione Monte Carlo Analisi utenti Analisi utenti

T. Lari: Analisi distribuita Roma, Febbraio Event Data Model: tipi di dati Nelle varie fasi di ricostruzione e analisi ATLAS utilizza diversi formati di dati: 1.6 MB target 100 kB attualmente 300 kB RAW ESD AOD DPD 10% di AOD target 500 KB attualmente 900 kB Raw Datadati in output dal sistema di trigger in formato byte-stream Raw Data: dati in output dal sistema di trigger in formato byte-stream Event Summary Dataoutput della ricostruzione (tracce e hit, celle e cluster nei calorimetri, combined reconstruction objects etc...). Event Summary Data: output della ricostruzione (tracce e hit, celle e cluster nei calorimetri, combined reconstruction objects etc...). Per calibrazione, allineamento, refitting … Analysis Object Datarappresentazione ridotta degli eventi per l’analisi: oggetti “fisici” ricostruiti (elettroni, muoni, jet, missing Et...) Analysis Object Data: rappresentazione ridotta degli eventi per l’analisi: oggetti “fisici” ricostruiti (elettroni, muoni, jet, missing Et...) Derived Physics Datainformazioni ridotte per analisi specifiche in ROOT. Derived Physics Data: informazioni ridotte per analisi specifiche in ROOT.

T. Lari: Analisi distribuita Roma, Febbraio Event Data Model: replica e distribuzione dati RAW ESD AOD DPD Dati originali al Tier0 Replica completa nell’insieme dei Tier-1 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. Gli ESD prodotti con la ricostruzione primaria risiedono al Tier-0 e vengono esportati in due copie ai Tier-1 Versioni successive degli ESD prodotte nei Tier-1 (ognuno riprocessa i suoi RAW) e replicate in due copie agli altri Tier-1 Versioni successive degli ESD prodotte nei Tier-1 (ognuno riprocessa i suoi RAW) e replicate in due copie agli altri Tier-1 Frazioni a richiesta nei Tier-2 Frazioni a richiesta nei Tier-2 Gli AOD prodotti con la ricostruzione primaria risiedono al Tier-0 e sono replicati in ogni Tier-1 Replicati parzialmente nei Tier-2 (~1/3 – 1/4 in ciascun Tier-2) in modo da avere almeno un insieme completo fra i Tier-2 della cloud Replicati parzialmente nei Tier-2 (~1/3 – 1/4 in ciascun Tier-2) in modo da avere almeno un insieme completo fra i Tier-2 della cloud ogni Tier-2 specifica i dataset più interessanti per la comunità di riferimento ogni Tier-2 specifica i dataset più interessanti per la comunità di riferimento DPD dei gruppi di analisi prodotti nei Tier1 in maniera schedulata repliche nei Tier-2 e Tier-3 repliche nei Tier-2 e Tier-3 In fase di definizione le procedure di produzione In fase di definizione le procedure di produzione

T. Lari: Analisi distribuita Roma, Febbraio L’Analisi: L’ Analysis ModelL’ Analysis Model L’ Analisi DistribuitaL’ Analisi Distribuita

T. Lari: Analisi distribuita Roma, Febbraio Athena AODcode, EventView AOD Athena Reconstruction groupEVNtuple HighPtView Nt Private Ntuple ESD CBNT Ntuple Analysis Model Formato di Analisi - Lo stato per le note CSC (v12)  Con il CSC è iniziato il processo di definizione del modello e dei formati di analisi. Primo utilizzo delle tecniche di analisi distribuita  Prodotti della Ricostruzione: ESD, AOD analizzabili in Athena, CBNT (Athena Aware flat NTuples) e SAN (ntuple strutturate) analizzabili in ROOT  Varie flat ntuples prodotte dagli AOD con codici personali o EventView (prototipi di DPD)  Proliferazione della tipologia di DPD

T. Lari: Analisi distribuita Roma, Febbraio La velocità, la portabilità e le ridotte dimensioni dei file sono le principali caratteristiche richieste dell’utente Soluzioni: 1.Ridurre il numero di formati di DPD 2.Aver accesso diretto ai dati nel formato AOD con la velocità tipica dell’analisi in ROOT e la possibilità di sfruttare la potenza di Athena Nuovo formato di AOD La separazione tra i dati in formato transiente utilizzato in Athena e persistente (file) permette di produrre un nuovo formato di una versione persistente di AOD  La versione persistente (POOL file) puà essere letta direttamente in Root (p_AOD) grazie a appositi dizionari che definiscono le caratteristiche degli oggetti  La versione transiente non è modificata: nessun impatto per l’utilizzo in Athena  Questa nuovo formato di AOD è la versione di default del DPD nella v13 e rende inutile la produzione di ntuple 3.Ridurre la dimensione dei DPD Analysis Model

T. Lari: Analisi distribuita Roma, Febbraio Athena AOD  DPD code AOD Part of AOD User/MetaData needed for H  4l Part of AOD User/MetaData needed for H  γγ Formato di Analisi - La soluzione verso cui si convergere (v13, FDR)  Unico Formato di Analisi: DPD  Deve essere leggibile da ROOT e deve poter utilizzare i tool e i servizi di Athena Caratteristiche dei DPD  Stesso formato degli AOD  AOD “general purpose”, DPD specializzati per la singola analisi  Dimensioni ridotte (thin AOD):  selezione delle informazioni essenziali  Introduzione di Userdata e Metadata (lumi info …) Analysis Model AOD thinAOD Athena Desktop

T. Lari: Analisi distribuita Roma, Febbraio Strategie di filtro 1. Skimming: selezione degli eventi interessanti Con i TAG (dBase o File) Con i TAG (dBase o File) Con filtri agenti sulle variabili degli AOD (funziona !) Con filtri agenti sulle variabili degli AOD (funziona !)  Numero di muoni  Missing Et 2. Thinning: rimozione di container o oggetti non interessanti  Muoni con pt < 20 GeV  Muoni ricostruiti con MOORE 3. Slimming: rimozione di propriet’ non interessanti di un oggetto  alcune info calorimetriche dall’oggetto elettrone o muone  alcune informazioni sulla qualità della traccia dei muoni Necessità di ridurre il numero dei file e la dimensione degli eventi  Uso più efficiente delle risorse di calcolo Più spazio disco e CPU a disposizione Più spazio disco e CPU a disposizione  Velocizzazione dell’analisi Analysis Model

T. Lari: Analisi distribuita Roma, Febbraio Definizione di DPD comuni:  Quanti DPD produrre? Uno per physics group? Uno per physics group? Uno per analisi o analisi simili variando solo la userdata part? Uno per analisi o analisi simili variando solo la userdata part?  Quanto spesso?  Chi produce i DPD? E’ necessaria una coordinazione precisa se bisogna rigirare la produzione sull’intera collezione gli AOD E’ necessaria una coordinazione precisa se bisogna rigirare la produzione sull’intera collezione gli AOD Accesso schedulato: “train model” per la produzione ai Tier-1 Accesso schedulato: “train model” per la produzione ai Tier-1 L’esperienza dell’ FDR aiuterà a dare un risposta a questi quesiti Analysis Model

T. Lari: Analisi distribuita Roma, Febbraio Analysis Model Metodi di Analisi (si usano gli stessi file!)  Athena Interattivo o Batch via python o in batch via C++ compilato (richiede alcuni minuti per compilazione) Interattivo o Batch via python o in batch via C++ compilato (richiede alcuni minuti per compilazione) Accesso totale ai tool e servizi di Athena Accesso totale ai tool e servizi di Athena Necessaria una installazione completa di Athena Necessaria una installazione completa di Athena Si può sottomettere lo stesso codice in Grid Si può sottomettere lo stesso codice in Grid  ROOT (ARA) Interattivo via CINT, python o batch via C++ compilato Interattivo via CINT, python o batch via C++ compilato Vantaggi: Vantaggi: Non richiede l’installazione completa di Athena (~1 GB)Non richiede l’installazione completa di Athena (~1 GB) Per “laptop use” e facile da usare: accesso interattivo ai dati, sviluppo veloce dell’analisiPer “laptop use” e facile da usare: accesso interattivo ai dati, sviluppo veloce dell’analisi Svantaggi: Svantaggi: Accesso limitato ai metadata nel file (lumi, trigger) Accesso limitato ai metadata nel file (lumi, trigger) No geometry e conditions db: niente tracce, cluster dei calorimetri, e tool che fanno uso di questi database No geometry e conditions db: niente tracce, cluster dei calorimetri, e tool che fanno uso di questi database Esempio H  4l in ARA (standard cuts in C++)  Full AOD 255 kb/ev – Rate 134 Hz255 kb/ev – Rate 134 Hz  Skimmed/Thinned (w MCTruth) 40 kb/ev – Rate 628 Hz40 kb/ev – Rate 628 Hz  Skimmed/Thinned (w/o MCTruth) 14 kb/ev – Rate 1380 Hz14 kb/ev – Rate 1380 Hz ~ 10 volte più veloce! AOD DPD DPD =thinAOD+UD User-Data Analisi Analisi SkimmingThinningSlimming

T. Lari: Analisi distribuita Roma, Febbraio  Gli utenti di ATLAS stanno finalmente prendendo confidenza con l’uso delle tecniche di Analisi Distribuita  Il CSC ha determinato un significativo passaggio dall’analisi locale all’analisi in Grid  Il Computing Model si basa sul principio che i job devono girare dove risiedono i dati per ottimizzare l’efficienza del processamento e non trasferire localmente gli enormi volumi di dati previsti da LHC (operazione praticamente impossibile) 1.Selezione degli eventi da TAG  Supporta la navigazione diretta agli eventi (RAW, ESD, AOD)  Procedura molto veloce: la selezione del 5% di eventi con query alle TAG è 20 volte più veloce della lettura di tutti I dati rigettandone il 95% 2.Determinazione dei migliori siti dove i dati sono memorizzati 3.Invio in questi siti (tramite i tool di Analisi Distribuita) dei jobs e recupero degli output: DPD e logfiles  Tool di Analisi Distribuita (job submission):  GANGA in EGEE  PAthena in OSG  Con l’avvicinarsi della presa dati, occorre essere preparati all’utilizzo dei tool di analisi distribuita per essere in grado di gestire il volume di dati che avremo fin dalle prime collisioni (200 Hz, indipendentemente dalla luminosità ) Analisi Distribuita

T. Lari: Analisi distribuita Roma, Febbraio Trasferimento files l L’utente può facilmente scaricare dalla griglia i files di un certo dataset, usando DQ2 ndq2_ls *PythiaZmumu.recon.AOD.v12* Questo fornisce la lista dei dataset con questo nome (* = wildcard). E’ naturalmente possibile farsi dare la lista dei files del dataset ed i siti dove sono distribuiti, sia con opzioni da linea di comando sia da un’interfaccia web. ndq2_get –r –d Questo scarica dalla griglia il dataset e lo mette nella directory locale l Tuttavia non si suppone che l’utente si scarichi grosse (molti TB) quantità di dati. Ogni Tier-2 italiano dovrebbe ricevere circa un quarto degli AOD della produzione mediante il meccanismo delle sottoscrizioni. nOgni Tier-2 puo’ scegliere (sottoscrivere) gli AOD a cui è interessato. Tipicamente quelli più interessati per la comunità che fa riferimento a quel Tier2, col vincolo che ogni Tier-2 ha un (diverso) quarto del totale. l Con i dati, gli utenti non potranno scaricare tutti i dati cui sono interessati per mancanza di spazio disco: l’analisi distribuita sui dati arrivati con le sottoscrizioni deve funzionare quando avremo i dati (e quindi occorre farla funzionare adesso…)

T. Lari: Analisi distribuita Roma, Febbraio Ganga e panda l Sono i due tool per fare analisi distribuita l Panda è il tool americano. Anche noi lo possiamo usare, spedendo i job sia su siti americani che europei l Il feedback degli utenti è che è facile da usare e funziona molto bene nTuttavia di default tutti i job sono spediti su BNL, dove ci sono praticamente tutti gli AOD (l’analisi non è poi tanto distribuita…) nNon è ovvio che la facilità di utilizzo scali… nNè che con i dati gli europei avranno le code libere per i loro job a BNL l Ganga è il tool europeo. Il feedback degli utenti è che funziona bene quando esiste una copia completa del dataset su un sito europeo, altrimenti dà molti problemi nPurtroppo pochi dataset CSC erano completi per i problemi di trasferimento dati ricordati (sperabilmente ora risolti) nLe lamentele degli utenti sono comunque state recepite da gli sviluppatori, che hanno fornito (qualche giorno fa) una nuova versione di ganga che migliora la gestione di dataset incompleti l Non c’è niente di male ad usare panda, ma occorre anche lavorare perchè ganga fornisca le prestazioni richieste da gli utenti – ne avremo bisogno coi dati

T. Lari: Analisi distribuita Roma, Febbraio Backup

T. Lari: Analisi distribuita Roma, Febbraio Final Dress Rehearsal (FDR) Esercizio completo dell’intera catena, dall’ on-line/trigger all’analisi distribuita, per integrare i test svolti fino ad ora indipendetemente  Generazione e simulazione di eventi MC e mix di tutti i canali di fisica, in proporzione alle sezioni d’urto, per riprodurre un campione il più possibile simile ai dati reali  Riproduzione della tipologia di dati in output all’HLT: simulazione del trigger, produzione del byte stream e streaming degli eventi. Tabelle di Trigger realistiche  Input dei dati al P1 come dati reali  Trasmissione dei RAW data dal P1 al Tier-0  Data quality monitoring, calibrazioni e allineamento al Tier-0  Ricostruzione in tempo reale al Tier0  produzione di ESD, AOD, TAG  Distribuzione di ESD, AOD, TAG ai Tier-1 e Tier-2  Produzione del TAG database e dei DPD  Riprocessamento dei RAW data ai Tier1 e redistribuzione di AOD  Processamento dell’analisi distribuita  Simulazione continua in parallelo ai Tier-2 (~ 100k jobs/day) Lo scopo è testare l’intero computing system come se si trattasse di dati reali per trovare in tempo i problemi che si potrebbero verificare durante il data taking In rosso gli step sincroni come durante il data taking

T. Lari: Analisi distribuita Roma, Febbraio Final Dress Rehearsal (FDR) Round 1:  Utlizzo dati simulati con la v12  Simulazione di un fill (10 hr) a  Luminosità istantanea decrescente durante il fill  Menu di Trigger a fisso durante il fill  ~ 400 nb -1 in tatale  Output rate di 200 Hz  ~7 M eventi  Simulazione di un fill corto (1 h) a  Menu di Trigger a  ~ 400 nb -1 in tatale  ~0.7 M eventi  Replica numerose volte di questi fill in giorni consecutivi simulando le condizioni di data taking  Introduzione dell’express e calibrations streams  Luminosità integrata bassa  analisi di canali ad alta sezione d’urto (b physics, min bias, standard model)

T. Lari: Analisi distribuita Roma, Febbraio Final Dress Rehearsal (FDR) Round 2:  dati simulati con la v13 e ricostruiti con la v14  100 M eventi da simulare a partire da Nov 07  Fill con luminosità (50 – 100 pb -1 )  Menu di trigger sempre più complicati  L2 muon calibration stream, calibrazione ai Tier-2  Produzione centrale di DPD mediante le procedure di slimming degli AOD  Tuning dei tool di analisi distribuita  Analisi dai DPD attaverso il framework ARA

T. Lari: Analisi distribuita Roma, Febbraio Common Computing Readiness Challange (CCRC08) Nel 2008:  LHC finalmente sarà operativo e tutti gli esprimenti prenderanno dati  Tutti gli esperimenti useranno le infrastrutture di computing simultaneamente  Il Tier-0, molti Tier-1 e alcuni Tier-2 gestiscono l’attività di più esperimenti e devono garantire le funzionalità previste dai singoli Computing Model per cui … Il challenge combinato deve dimostrare la capacità delle infrastrutture di computing a funzionare anche in situazioni di concorrenza tra tutti gli esperimenti LHC prima dell’inizio della presa dati ad una scala comparabile ai volumi previsti nel 2008 Tutto deve essere svolto in tempo per evidenziare imperfezioni, bottlenecks e permettere le neccessarie correzioni

T. Lari: Analisi distribuita Roma, Febbraio Data Taking Quando sarà? In ogni caso bisogna essere pronti 17 settimane di fisica Live time = 4·10 6 secondi Rate = 200 Hz Raw Data = 8·10 8 eventi Dati simulati ~ 40% dei dati reali: 3·10 8 eventi