La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "Computing Model ATLAS & CMS Federica Fanzago (CMS) & Monica Verducci (ATLAS) III Workshop Italiano della Fisica di ATLAS e CMS Bari, 20-22 Ottobre 2005."— Transcript della presentazione:

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

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

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

4 Fanzago-Verducci Computing Model Atlas & CMS4 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

5 Fanzago-Verducci Computing Model Atlas & CMS5 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.

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

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

8 Fanzago-Verducci Computing Model Atlas & CMS8 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: 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 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 ”

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

10 Fanzago-Verducci Computing Model Atlas & CMS10 CMS Databases Conditions Calibration Online Master Data Storage Online Master Data Storage 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 Configuration Offline Reconstruction Conditions DB ONline subset Offline Reconstruction Conditions DB ONline subset Sincronizzazione sulle conditions Conditions Offline Reconstruction Conditions DB OFFline subset Master Copy no “event data” al Tier0

11 Fanzago-Verducci Computing Model Atlas & CMS11 Ruolo dei Tiers 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 Tier-1: archiviano i dati e forniscono servizi per la simulazione, ricostruzione, calibrazione e skimming (AOD). Gli AOD vengono trasferiti ai Tier2 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 CER N Trigger Event Filter Trigger Event Filter CNAF TIER 0 TIER 1 TIER 2 TIER 3 Tier-3: Analisi dati utenti Rate [Hz] RAW [MB] ESD RECO [MB] AOD [kB] Monte Carlo [MB/evt] ATLAS CMS ATLAS ~ 10 CMS ~ 6 ATLAS ~ 40 CMS ~ 25

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

13 Fanzago-Verducci Computing Model Atlas & CMS13 In via di sviluppo 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 CMSATLAS DATA MANAGEMENT Data Transfer service PhEDExDDM e DQ2 Data Publication service RefDB/PubDB->DBS/DLSAMI PRODUCTION Production Job Submission Tool MCRunJobAtCom, GANGA, RAT ANALYSIS Distributed Software Installation XCMSINo UI, ProdSys Analysis Job Submission Tool CRABAtCom, GANGA, RAT MONITORING Application Monitoring BOSSMDS, AtCom Dashbord MonalisaP. manager, Monalisa

14 Fanzago-Verducci Computing Model Atlas & CMS14 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

15 Fanzago-Verducci Computing Model Atlas & CMS15 Data Challenges Passati: ATLAS ATLAS DC 1Lug 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.

16 Fanzago-Verducci Computing Model Atlas & CMS16 ATLAS DC 2Mag 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 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 files al giorno, 50 GB/giorno, che è stata poi portata a 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)

17 Fanzago-Verducci Computing Model Atlas & CMS17 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) -> jobs Jobs per day on the LCG-2 infrastructure DC2 Rome prod Rome Workshop & Test Beam (2004)

18 Fanzago-Verducci Computing Model Atlas & CMS18 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

19 Fanzago-Verducci Computing Model Atlas & CMS19 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 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)

20 Fanzago-Verducci Computing Model Atlas & CMS20 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

21 Fanzago-Verducci Computing Model Atlas & CMS21 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.

22 Fanzago-Verducci Computing Model Atlas & CMS22 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.

23 Fanzago-Verducci Computing Model Atlas & CMS23 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! Tier1 Tier 1: CNAF Tier 2: Milano, Roma 1, Frascati, Napoli

24 Fanzago-Verducci Computing Model Atlas & CMS24 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

25 Fanzago-Verducci Computing Model Atlas & CMS25 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 

26 Fanzago-Verducci Computing Model Atlas & CMS26 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?

27 Fanzago-Verducci Computing Model Atlas & CMS27 Back up

28 Fanzago-Verducci Computing Model Atlas & CMS28

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

30 Fanzago-Verducci Computing Model Atlas & CMS30 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

31 Fanzago-Verducci Computing Model Atlas & CMS31 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

32 Fanzago-Verducci Computing Model Atlas & CMS32 CRAB analisi distribuita...

33 Fanzago-Verducci Computing Model Atlas & CMS33 CMS:analisi distribuita…come sara’ 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. 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 CRAB

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

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

36 Fanzago-Verducci Computing Model Atlas & CMS36 Data Management System ATLAS


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

Presentazioni simili


Annunci Google