Computing Model ATLAS & CMS Federica Fanzago (CMS) & Monica Verducci (ATLAS) III Workshop Italiano della Fisica di ATLAS e CMS Bari, 20-22 Ottobre 2005

Computing Model Atlas & CMS Sommario Introduzione ad LHC Descrizione del Computing Model Data Flow Trigger e Streams Work Flow Data e service challenges Conclusioni Items di discussione Fanzago-Verducci Computing Model Atlas & CMS

Large Hadron Collider LHC Collisioni protone-protone Energia fascio: 7 TeV Luminosita': 1034 cm-2 s-1 (2007: 0.5*1033 cm-2 s-1; 2008/09: 2*1033 cm-2 s-1) Sezione d’urto totale anelastica pp stot(pp) = 70 mb Frequenza bunch-crossing : 40 MHz ~ 20 collisioni p-p per bunch crossing Sistema gerarchico di trigger per riduzione dati Sistema gerarchico di calcolo per gestione dati 109 eventi/s =>1GHz 1 evento ~ 1MB ~PB/sec ~MB/sec ~PB/anno raw data Fanzago-Verducci Computing Model Atlas & CMS

Computing Model: perche’ Per far fronte ai problemi di gestione di questa grande quantita’ di dati archiviarli (grande capacita’ di storage) distribuirli per garantire l’accesso ai dati ai fisici della collaborazione indipendentemente dalla loro locazione definire policy locali e globali per l’utilizzo delle risorse per avere sufficiente capacita’ di calcolo processing dati analisi produzioni dati simulati Gli esperimenti LHC hanno deciso di utilizzare una architettura distribuita basata sulla grid. I servizi grid sono forniti da World Wide LCG Computing Grid (WLCG) che utilizza software di EGEE (Enabling Grids for E-sciencE), di American Open Science Grid (OSG) e NorduGrid Fanzago-Verducci Computing Model Atlas & CMS

Computing Model: cos’e’ Il Computing Model definisce: Modello dei dati e come questi vengono distribuiti dalla presa dati all’analisi finale Architettura e gerarchia delle risorse Policies di accesso dati e risorse dislocati geograficamente nei vari centri Procedure di calibrazione e allineamento, Processing e reprocessing dati reali Come fare la produzione dei dati simulati in ambiente distribuito Come fare l’analisi in ambiente distribuito Tools che si interfacciano ai servizi grid Come e quando fare i test dell’architettura, dei servizi e del modello dati Il Computing Model stabilisce inoltre le performances che si vogliono ottenere dal Computing System in ambiente distribuito, per permettere un accesso veloce sia ai dati ricostruiti per effettuare le analisi durante la presa dati sia ai RawData per servizi di monitoring, calibrazione e allineamento. Fanzago-Verducci Computing Model Atlas & CMS

Computing Model: architettura distribuita CMS ATLAS 40 Mhz (1000 TB/s) 40 Mhz (1000 TB/s) Online System “bunch crossing” 25 nsecs. 1 evento ~ 1 MB Offline Processor Farm Alcuni dati usati per la calibrazione e il monitoring vanno ai centri Tier1 dedicati, e poi ritornano al Tier0 1 TIPS is ~ 25,000 SpecInt95 equivalents Tier 0 CERN Computer Centre Tier 1 France Regional Centre ~4 TIPS Italy Regional Centre ~4 TIPS US Regional Centre ~4 TIPS LNL ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier 2 I Tiers comunicano fra di loro attraverso la GRID! Institute ~0.25TIPS Tier 3 Institute Institute Institute 100-1000 MB/s Physicist workstations Fanzago-Verducci Computing Model Atlas & CMS

Online system: il Trigger Scopo: ridurre la quantita' di dati filtrando gli eventi “non interessanti” ~PB/sec ATLAS CMS Detectors 40 MHz 25ns 25ns 40 MHz LVL 1 Front end pipelines LVL 1 Primary stream (tutto l’evento dall’EF) Stream calibrazione ed allineamento Physics trigger (tuning- express line) Pathological events (evts non accettati dall’EF) 105 Hz 105 Hz µsec µsec 10 Primary stream (50 dataset) Stream di calibrazione Express-line stream (contiene dati da processare con alta priorita’) LVL 2 Readout buffers ms 103 Hz Switching network Processor farms LVL 3 HLT 102 Hz 102 Hz sec ~MB/sec ~PB/anno sec Fanzago-Verducci Computing Model Atlas & CMS

Calibrazione ed Allineamento I processi di calibrazione e allineamento generano “non-event data” necessari per la ricostruzione degli “event-data”. Esistono diversi processi di calibrazione ed allineamento: ATLAS Input Raw data possono provenire direttamente dall’event stream o essere processati nel sub-detector read-out system. A livello dei RODs (sub-detector read-out system) All’interno dell’event filter Dopo l’event filter ma prima della “prompt reconstruction” Offline dopo la “prompt reconstruction” CMS Test di precalibrazione al Local DAQ Dagli event data: A livello di sub-detector Dopo DDU (Detector Dependent Unit ) Readout system Dopo event-filter farm Off-line Fanzago-Verducci Computing Model Atlas & CMS

Configuration Database ATLAS Databases Configuration Database e Condition Database ATLAS Detector DCS Detector Con. Sys. HV, LV Temperatura Allinemaneto Front- End Event Filter Level2 Trigger ROSs Level1 VME Crate RODs ATHENA code Configuration Database Conditions Database ByteStream Files Manual Input TCord db ROD HLT/DAQ DCS System Online Calib. farm CONFIGURATION DB CONDITION DB Geom. Monitor data Geom. Setup Setup DCS Calib Calib ROD HLT/ DAQ DCS System Monitor queries Reco. farms Offline analysis Fanzago-Verducci Computing Model Atlas & CMS

Offline Reconstruction Offline Reconstruction CMS Databases Calibrazione / allineamento Stima = 90 TB /anno Dati da usare nell’HLT Poi copiati sul Tier 0 e replicati ai Tier1: necessari nei riprocessamenti e nell’analisi Offline Reconstruction Conditions DB ONline subset Online Master Data Storage Sincronizzazione sulle conditions Calibration Configuration Conditions Conditions Master Copy no “event data” al Tier0 Offline Reconstruction Conditions DB OFFline subset Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Ruolo dei Tiers TIER 0 Trigger Event Filter CERN Tier-0 al CERN: archivia tutti i dati dell'online (RAW) e ne fa una prima ricostruzione (RECO/ESD). Conserva i dati per la calibrazione. Dal Tier 0 i RECO+RAW vengono distribuiti ai Tier-1’s ATLAS ~ 10 CMS ~ 6 TIER 1 CNAF Tier-1: archiviano i dati e forniscono servizi per la simulazione, ricostruzione, calibrazione e skimming (AOD). Gli AOD vengono trasferiti ai Tier2 ATLAS ~ 40 CMS ~ 25 TIER 2 TIER 3 Tier-2: simulazione per computing system commissiong, copia degli AOD per analisi con diversi sistemi di streaming, campioni di eventi in formato RAW e ESD per calibrazioni e sviluppo algoritmi di ricostruzione, calibration centers Rate [Hz] RAW [MB] ESD RECO [MB] AOD [kB] Monte Carlo [MB/evt] ATLAS 200 1.6 0.5 100 2 CMS 150 1.5 0.25 50 Tier-3: Analisi dati utenti Fanzago-Verducci Computing Model Atlas & CMS

La grid: middleware LCG UI Job submission tools Principali componenti del middleware lcg Virtual Organizations (CMS,ATLAS,ecc) Resource Broker (RB) Replica Manager (RLS) Computing Elements (CEs) Storage Elements (SEs) Worker nodes (WNs) User Interfaces (UIs) Query for matchmaking Information Service collector Workload Management System Query for data Data location system Resource Broker (RB) CE SE SE SE Fanzago-Verducci Computing Model Atlas & CMS

Tool di esperimento interfacciati ai servizi grid Gli esperimenti stanno sviluppando i propri tools per la produzione dei dati simulati (MC) e per l'analisi distribuita interfacciandosi ai servizi forniti dalla grid CMS ATLAS DATA MANAGEMENT Data Transfer service PhEDEx DDM e DQ2 Data Publication service RefDB/PubDB->DBS/DLS AMI PRODUCTION Production Job Submission Tool MCRunJob AtCom, GANGA, RAT ANALYSIS Distributed Software Installation XCMSI No UI, ProdSys Analysis Job Submission Tool CRAB MONITORING Application Monitoring BOSS MDS, AtCom Dashbord Monalisa P. manager, Monalisa In via di sviluppo Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Commissioning E’ importante per gli esperimenti verificare più volte nel tempo la fattibilità e la scalabilità dell’intero sistema (infrastruttura, software, data management, data workflow), con livelli di complessità via via sempre più prossimi alle condizioni che si avranno allo startup di LHC. Gli esperimenti, con i data e service challenges, vogliono valutare la robustezza e la scalabilita' dell'intero sistema Data Challenges Service Challenges Fanzago-Verducci Computing Model Atlas & CMS

Data Challenges Passati: ATLAS ATLAS DC 1 Lug 2002-Mag 2003 Organizzazione delle risorse disponibili (hardware e persone): primo approccio all’uso della grid Mostrato la necessità di un sistema integrato Richiesta di più manpower Tests sul software grid Massiccia produzione di dati per HLT e Physics Workshop Dimostrata la possibilità di poter simulare, ricostruire e salvare su disco all’interno di una struttura distribuita. Circa 15M eventi sono stati generati con Geant3 (fortran), 40 M di eventi ‘single-particle’ per un volume totale di 70TB. Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS ATLAS DC 2 Mag 2004-Gen 2005 SCOPO: Largo uso del GRID middleware e dei suoi tools (Tier 0 exercise) Analisi di fisica a grande scala Studio del computing model (fine 2004) Produzione intensiva su LCG-2 RISULTATI: Circa 15M eventi generati con Geant4, ovvero 40TB di dati raccolti in 200000 files. Sono state usate le tre GRIDS: LCG/Grid3/NorduGrid nel rapporto 40/30/30% con un’efficienza globale del 60%. Il trasferimento dati al CERN è stato effettuato via DQ, con una media di 2-3000 files al giorno, 50 GB/giorno, che è stata poi portata a 100000 files al giorno (1.5 TB/giorno). PROBLEMI: Tier 0 exercise ridotto per mancanza di risorse software Problemi di Stagein/out, trasferimenti di files Il Central Production database Oracle, lenta risposta Problemi con LCG information system, connessioni perse , lentezza del Resource Broker (limitati jobs per giorno) Fanzago-Verducci Computing Model Atlas & CMS

Rome Workshop & Test Beam (2004) Simulazione di ATLAS e 2004 Combined Test Beam Test delle procedure di calibrazione e allineamento Circa 9 M di eventi (50 kB per evento) per un totale di 4.5 TB collocati in Castor Produzione per l’ATLAS Physics Workshop Circa 5 M di eventi sono stati generati, simulati, digitizzati ed infine ricostuiti (AOD, ESD), 173 differenti canali di fisica alcuni con pile-up. Problemi umani connessi alla registrazione manuale all’interno del Production System, limitato trasferimento di files dovuto a Castor (mass storage system). Differenze con il DC2: Condor G (esecutore LCG) -> 12000 jobs Jobs per day on the LCG-2 infrastructure Rome prod DC2 Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS CMS EDG stress test 2002 Primo tentativo di produzione dati in ambiente grid (EDG 1.3.4) Scopo: valutare il livello di maturità del middleware EDG capire se EDG risponde alle esigenze di produzione dell’esperimento scoprire problematiche, misurare prestazioni valutare tool per interfaccia utente e per monitoring risorse e job Risultato: sono stati prodotti ~260K eventi MC in tre settimane (10500 job sottomessi). Efficienza grid ~50-90% a seconda del tipo di job (durata, input-output) Problemi evidenziati: il test è stato “difficile” perché il primo in ambiente distribuito. Molti parametri in gioco, persone non molto esperte Eccessivo bisogno di supporto alle risorse e servizi Particolarmente debole RB ed Information Service Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS CMS DC04 marzo-aprile 2004 Scopo: dimostrare la fattibilita’ della catena: Ricostruzione dati al T0, 25Hz (25% del rate previsto allo startup) 35 M ev.simulati (PCP) Registrazione dati nel Replica Catalog (RLS) Trasferimento dati ai T1 e T2 Analisi dati sincrona con il trasferimento Pubblicazione nel catalog degli output dell’analisi Risultato: DC04 ha raggiunto l’obiettivo della ricostruzione e dell’analisi sincrona al rate di 25Hz . In particolare: 25 M eventi ricostruiti (DST) ~6TB dati; 10M eventi analizzati 15000 job di analisi sottomessi in due settimane; 90-95% efficienza grid 20 minuti tra ricostruzione T0 e inizio analisi T1 2 minuti ritardo introdotto dalla grid nell’esecuzione job Problemi evidenziati: catalogo centrale (RLS) troppo lento in scrittura e lettura, non soddisfa le esigenze dell’esperimento. Risorse e servizi necessitano controllo costante. Sistema in generale complesso per essere utilizzato da un utente non esperto In ambiente grid (LCG) Fanzago-Verducci Computing Model Atlas & CMS

Data and Service Challenges Futuri: ATLAS Durante questo autunno, si testerà (SC3) il Production System Produzione nel Tier0 con trasferimento dati ai Tier1 Produzione MonteCarlo distribuita che permetterà di testare il trasferimento dal tier1 al Tier2 in entrambe le direzioni. DQ->DQ2: Dataset Selection Catalog + Logical Replica Catalog A fine anno, comincerà la “pre-production” per il DC3 (CSC) La mole di dati sarà di un ordine di grandezza maggiore di quella del DC2 Tests su: scalabilità del Tier-0, distribuzione dei dati, e analisi distribuita, offline trigger software Molti users Ultima possibilità per validare il software e il computing system prima dei dati veri Cosmic rays a fine anno: Test di calibrazione e accesso ai database Simulazione di eventi di cosmici per analisi Fanzago-Verducci Computing Model Atlas & CMS

CMS e LCG SC3: challenge in corso LCG SC3 e’ un service challenge a cui partecipano tutti gli esperimenti LHC. E’ divisa in due fasi: fase “throughput” (luglio 05): test trasferimento dati tra T0 - T1 - T2. CMS usa PhEDEx come tool di trasferimento PhEDEx si interfaccia con diversi protocolli di trasferimento:GSIFTP e SRM (nasconde varie tecnologie di storage, dpm, castor, dcache) PhEDEx scrive su un LCG-POOL catalog locale,backend MySQL, per creare cataloghi file fase “service” (da settembre fino fine anno): non solo trasferimento dati ma anche test sui tools e sul computing model di esperimento data management con pubblicazione dati su PubDB e RefDB workload management con creazione e sottomissione job analisi (via CRAB) e produzione test integrazione PhEDEx con LFC (catalogo grid) per pubblicazione dati Problemi: e’ stato necessario debugging del servizio castor-2 al CERN. Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS CMS Challenge futuri Cosmic challenge (06):servirà a testare i moduli installati acquisendo i dati dei cosmici. Dal punto di vista del computing: Verra’ usato il nuovo framework Possibile test sul data management e job workflow  ricostruzione dati, trasferimento ai Tiers e pubblicazione sui DB per futura analisi. L’obiettivo principale è il test dei rivelatori. SC4 (06): service challenge di tutti i servizi che verranno usati allo startup. Le produzioni MC e l’analisi fatte nel challenge serviranno per il P-TDR. CSA (06) Computing, Software, Analysis: test completo di tutta la catena del computing dalla presa dati all’analisi finale. Si vuole verificare che software e servizi siano pronti per la presa dati. Verranno prodotti milioni di eventi. I Tier1e2 dovranno girare job di analisi sui dati trasferiti e calibrazioni. Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Attività prevista nei centri italiani (ATLAS) Ricostruzione: Muon Detector (LE, NA, PV), Calorimetri (MI, PI), Pixel Detector (MI) Calibrazioni/allineamento/detector data: MDT (LNF, RM1-3), RPC (LE, NA, RM2), Calorimetri (MI, PI), Pixel Detector (MI) Cond. DB (CS), Det. Descr. DB (LE, PI), Det. Mon. (CS, NA, UD) Studi di performance: Muoni (CS, LE, LNF, NA, PI, PV, RM1-2-3) Tau/jet/EtMiss/egamma (GE, MI, PI) Analisi: Higgs sia SM che MSSM (CS, LNF, MI, PI, PV, RM1) Susy (LE, MI, NA) Top (PI, UD) Fisica del B (CS, GE, PI) Simulazioni connesse alle attività suddette Studi sul modello di analisi VOMS e Lexor sono prodotti italiani! Tier 1: CNAF Tier 2: Milano, Roma 1, Frascati, Napoli Tier1 Fanzago-Verducci Computing Model Atlas & CMS

Attività prevista nei centri italiani (CMS) Ricostruzione: Muon DT - Torino, Padova, Bologna Muon RPC - Bari, Napoli Ecal - Roma1, MilanoB Tracker - Pisa, Firenze, Perugia, Catania, Bari Calibrazioni/allineamento/detector data: Muon DT - Padova, Torino Muon RPC - Ecal - Roma1, MilanoB Tracker - Bari, Pisa, Firenze Condition DBs : ECAL - Roma1 Detector monitoring :Tracker - Pisa, Bari : Muon - Bologna  : Ecal - Trieste, MilanoB Studi di performance: Muon (DT + RPC) - Padova, Torino, Bologna, Bari, Napoli Ecal - Roma1, MilanoB Tracker - Pisa, Firenze, Bari, Perugia Analisi: Higgs sia SM che MSSM - Firenze, Bari, Roma1, Padova, Bologna, MilanoB, Perugia, Napoli, Pavia, Pisa, Torino Susy - Catania, MilanoB, Bari, Pisa Top - Pisa, Bologna b-physics - Firenze, Napoli, Pisa, Perugia SM Z/W - MilanoB, Roma1 QCD - Perugia, Bologna Tier 1: CNAF Tier 2: Legnaro, Pisa, Roma, Bari Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Conclusioni L’enorme quantità di dati che verranno prodotti dagli esperimenti LHC quando entreranno in funzione richiederanno un sistema di calcolo gerarchico e distribuito basato sulla grid. Gli esperimenti stanno testando con challenges di complessità crescente la solidità e la maturità del computing model per arrivare pronti allo startup. I challenges finora fatti, mettendo in evidenza problematiche e colli di bottiglia, hanno permesso al sistema di evolvere e di ridurre gli errori di sistema ed umani che avevano caratterizzato i primi tests. Alcuni aspetti sono ancora in fase di studio … Discussione  Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Items di discussione CMS ed ATLAS sono due progetti molto simili fra loro, le differenza esistenti appartengono ai diversi usi che hanno fatto della grid: CMS ha sviluppato alcuni propri tools, soprattutto interfaccia utente, contrariamente ad ATLAS che si affida ‘quasi’ completamente ad LCG Da un punto di vista dell’utente finale: e’ veramente ‘user-friendly’ usare la grid? Alla luce dei risultati dei challenges, un punto problematico per entrambi gli esperimenti sembra essere il data-discovery. Come viene affrontato nelle due realtà. Quanto devono essere associati i challenges di computing con quelli di fisica, ad esempio nel prossimo cosmic challenge? Quando e’ giusto fare un service challenge? A che livello di maturità dei tools, per evitare debugging o vero e proprio sviluppo? Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Back up Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS Fanzago-Verducci Computing Model Atlas & CMS

CMS data movement RefDB Data vengono spostati dal Tier 0 ai Tier 1 e Tier 2 con PhEDEx ~100 MBytes/sec CERN Computer Centre Tier 0 PhEDEx France Regional Centre Germany Regional Centre Italy Regional Centre (CNAF) FermiLab PhEDEx ValidationTools Bari Bologna LNL Padova Tier 2 PubDB Local catalogues Una volta trasferiti i dati vengono validati e pubblicati nei catalogo locale Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS What is PhEDEx? A data distribution management system Used by CMS Blends traditional HEP data distribution practice with more recent technologies Grid and peer-to-peer filesharing Scalable infrastructure for managing dataset replication Automates low-level activity Allows manager to work with high level dataset concepts rather than low level file operations Technology agnostic Overlies Grid components Currently couples LCG, OSG, NorduGrid, standalone sites Two principle use cases- push and pull of data Raw data is pushed onto the regional centres Simulated and analysis data is pulled to a subscribing site By T.Barrass Fanzago-Verducci Computing Model Atlas & CMS

ruolo dei tiers negli esperimenti CMS CAF Functionality: CERN Analysis Facility: development of the CERN Tier-1 / Tier-2 Integrates services associated with Tier-1/2 centers Primary: provide latency-critical services not possible elsewhere Detector studies required for efficient operation (e.g. trigger) Prompt calibration ; ‘hot’ channels Secondary: provide additional analysis capability at CERN By P.Capiluppi Fanzago-Verducci Computing Model Atlas & CMS

CRAB analisi distribuita... Fanzago-Verducci Computing Model Atlas & CMS

CMS:analisi distribuita…come sara’ CRAB CRAB: tool per la creazione e la sottomissione di job di analisi.Permette agli utenti di girare il proprio codice di analisi su dati remoti come se fossero in locale Dataset Bookkeeping System: sa che dati esistono. Contiene descrizione dati specifiche di CMS. Non contiene informazioni sulla locazione dei dati Completa responsabilita di CMS Data Location Service: sa dove sono I dati. Mappaggio tra file-blocks (data location unit) e SE. Local File Catalog: sa dove sono fisicamente i dati e con quale protocollo accederli. Fanzago-Verducci Computing Model Atlas & CMS

Computing Model Atlas & CMS CMS Production System Yes! Here’s what I want: Cross section N events Ntpl size Ntpl location RefDB I want to monitor Cross section N events Ntpl size Ntpl location Template.sh So, here’s my template Script generator (MCRunJob) Job Monitoring Std output CE By M.Corvo Fanzago-Verducci Computing Model Atlas & CMS

ATLAS production System AMI ProdDB Data Man. System Don Quijote2 Eowyn LCG exe Condor exe NG exe OSG exe LSF exe Panda Dulcinea Lexor RLS RLS RLS (Grid3) OSG LCG NG LSF Fanzago-Verducci Computing Model Atlas & CMS

Data Management System ATLAS Fanzago-Verducci Computing Model Atlas & CMS