Computing Model ATLAS & CMS

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

Sommario • Introduzione ad LHC • Descrizione del Computing Model • Data Flow • Trigger e Streams • Work Flow • Data e service challenges • Conclusioni • Items di discussione 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 ~MB/sec ~PB/anno raw data ~PB/sec 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 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. Computing Model Atlas & CMS

Online System “bunch crossing” 25 nsecs. 1 evento ~ 1 MB LNL ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Computing Model: architettura distribuita CMS ATLAS 40 Mhz (1000 TB/s) 40 Mhz (1000 TB/s) 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 Tier 2 I Tiers comunicano fra di loro attraverso la GRID! Institute ~0.25TIPS Institute Institute Institute Tier 3 100-1000 MB/s Physicist workstations Computing Model Atlas & CMS

Online system: il Trigger Scopo:ridurre la quantita' di dati filtrando gli eventi “non interessanti” ~PB/sec CMS ATLAS 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 Switching network 103 Hz Processor farms LVL 3 HLT 102 Hz 102 Hz ~MB/sec ~PB/anno sec sec 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 Computing Model Atlas & CMS

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

CMS Databases • Calibrazione / allineamentoStima = 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 Master Copy no “event data” al Tier0 Conditions Conditions Offline Reconstruction Conditions DB OFFline subset Computing Model Atlas & CMS

CERN Ruolo dei Tiers TIER 0 Trigger Event Filter 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 Tier-3: Analisi dati utenti Computing Model Atlas & CMS

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) La grid: middleware LCG UI Job submission tools Query for matchmaking Information Service collector Workload Management System Query for data Data location system Resource Broker (RB) CE SE SE SE 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 In via di sviluppo 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 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. Computing Model Atlas & CMS

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 exerciseridotto 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) ATLAS DC 2 Mag 2004-Gen 2005 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 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 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 Mev.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: • 25M 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) 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 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. 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. 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 Computing Model Atlas & CMS

Attività prevista nei centri italiani (CMS) Tier 1: CNAF Tier 2: Legnaro, Pisa, Roma, Bari • 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 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  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? Computing Model Atlas & CMS

Back up Computing Model Atlas & CMS

Computing Model Atlas & CMS

Bari Bologna LNL Padova Local catalogues 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 Tier 2 PubDB Una volta trasferiti i dati vengono validati e pubblicati nei catalogo locale 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 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 Computing Model Atlas & CMS

CRAB analisi distribuita... 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. 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 Computing Model Atlas & CMS

ATLAS production System ProdDB AMI 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 Computing Model Atlas & CMS

Data Management System ATLAS Computing Model Atlas & CMS

Computing Model ATLAS & CMS