20 Ottobre 2005CCR - Roma1 I centri di calcolo distribuiti in LHC: motivazioni, funzioni, implementazione P. Morettini

20 Settembre 2005CSN1 - Roma2 I dati del problema Per capire l’organizzazione del calcolo a LHC bisogna partire dai dati del problema, ovvero dalle dimensioni degli eventi prodotti dai rivelatori e dalla quantità di calcolo necessaria ad elaborarli.

LCG Slide No. 3 LHC Computing Grid – Technical Design Report 3Jürgen Knobloch, CERN-IT The Eventflow Rate [Hz] RAW [MB] ESD rDST RECO [MB] AOD [kB] Monte Carlo [MB/evt] Monte Carlo % of real ALICE HI ALICE pp ATLAS CMS LHCb days running in seconds/year pp from 2008 on  ~10 9 events/experiment 10 6 seconds/year heavy ion

20 Settembre 2005CSN1 - Roma4 Raw Data: Raw Data: –eventi in formato “ByteStream” prodotti dalla catena di TDAQ; in genere costruiti dagli Event Builders e trasmessi in output dall’Event Filter (l’ultimo stadio degli High Level Trigger): 1.6 MB/evento nominali 1.6 MB/evento nominali Event Summary Data (ESD): Event Summary Data (ESD): –l’output completo della ricostruzione in formato POOL ROOT; sufficiente per quasi ogni applicazione (eccetto che per calibrazioni e sviluppo algoritmi di ricostruzione): obiettivo: 500 KB/evento obiettivo: 500 KB/evento Analysis Object Data (AOD): Analysis Object Data (AOD): –rappresentazione dell’evento ridotta, derivata dagli ESD, conveniente per l’analisi, in formato POOL ROOT; contiene gli oggetti fisici e altri elementi di interesse per l’analisi: obiettivo: 100 KB/evento obiettivo: 100 KB/evento Tag Data (TAG): Tag Data (TAG): –informazioni essenziali sugli eventi per permettere un’efficiente identificazione e selezione degli eventi di interesse per una data analisi; per facilitarne ed ottimizzarne l’accesso sono memorizzati in un database relazionale: obiettivo: 1 KB/evento obiettivo: 1 KB/evento Derived Physics Data (DPD): Derived Physics Data (DPD): –rappresentazione tipo n-tupla dei dati dell’evento per l’analisi e la istogrammazione dell’utente finale; inclusa nel data model per permettere un’analisi immediata e la visualizzazione dei risultati con i tanti tool standard di analisi (PAW, ROOT, JAS, …) Simulated Event Data (SIM): Simulated Event Data (SIM): –una gamma di tipi di dati, a cominciare dagli eventi generati (ad es., con Pythia o programmi simili) alla simulazione delle interazioni con l’apparato (ad es., hits di Geant4) e della risposta dei rivelatori (digitizzazione); possono anche includere il pileup e il fondo di caverna; memorizzati come file POOL ROOT (in genere) o in formato bytestream per studi di trigger: spesso  2 MB/evento spesso  2 MB/evento Event Data Model

20 Settembre 2005CSN1 - Roma5 Simulazione (includendo generazione dell’ evento, tracciamento con Geant4, digitizzazione): Simulazione (includendo generazione dell’ evento, tracciamento con Geant4, digitizzazione): –100 kSI2ksec/evento nominali attualmente 2-4 volte maggiore, a seconda dalla fisica, ma: attualmente 2-4 volte maggiore, a seconda dalla fisica, ma: –si assume di poter guadagnare un fattore 2 dal lavoro di ottimizzazione nel (questa è la prima reale implementazione con Geant4 della simulazione ATLAS) –si assume di poter guadagnare un ulteriore fattore 2 limitando il tracciamento a |η|< 3 invece che |η|< 6 quando non strettamente necessario Ricostruzione: Ricostruzione: –15 kSI2ksec/evento nominali a tutte le luminosità: attualmente 4 volte maggiore, ma: attualmente 4 volte maggiore, ma: –si assume di poter guadagnare un fattore 2 dal lavoro di ottimizzazione nel ; –attualmente si utilizzano 2 algoritmi in parallelo per Inner e Muon Detector; –le soglie possono essere accordate con la luminosità per compensare l’aumento dei tempi necessari per il pattern recognition Analisi: Analisi: –0.5 kSI2ksec/evento nominali per analisi sugli AOD stima basata sui tempi di accesso attuali agli AOD stima basata sui tempi di accesso attuali agli AOD –0.5 kSI2ksec totali per analisi su collezioni complete (tutti i dati di un anno) di DPD; (nella vita reale saranno piu’ frequenti analisi su campioni ridotti (1-10% dei dati) ma ripetute molte volte) stima basata sui tempi di accesso attuali alle n-tuple stima basata sui tempi di accesso attuali alle n-tuple Tempi di processamento

6 CSN1 - Roma 20 Settembre 2005 Data Tiers u RAW  Detector data + L1, HLT results after online formatting  Includes factors for poor understanding of detector, compression, etc  <200Hz; ~ 5.0PB/year (two copies) u RECO  Reconstructed objects with their associated hits  250kB/evt; ~2.1PB/year (incl. 3 reproc versions) u AOD  The main analysis format; objects + minimal hit info  50kB/evt; ~2.6PB/year - whole copy at each Tier-1 u TAG  High level physics objects, run info (event directory); <10kB/evt u Plus MC in ~ 1:1 ratio with data

7 CSN1 - Roma 20 Settembre 2005 Data Flow u Prioritization will be important  In 2007/8, computing system efficiency may not be 100%  Cope with potential reconstruction backlogs without delaying critical data  Reserve possibility of ‘prompt calibration’ using low-latency data  Also important after first reco, and throughout system è E.g. for data distribution, ‘prompt’ analysis u Streaming  Classifying events early allows prioritization  Crudest example: ‘express stream’ of hot / calib. events  Propose O(50) ‘primary datasets’, O(10) ‘online streams’  Primary datasets are immutable, but è Can have overlap (assume ~ 10%) è Analysis can draw upon subsets and supersets of primary datasets

The LHCb Computing TDR. 8 Domenico Galli Streaming CERN computing centre HLT b-exclusive 200 Hz di-muon 600 Hz D * 300 Hz b-inclusive 900 Hz rDST (25 kB/evt) 200 Hz 2 kHz RAW (25 kB/evt) 60 MB/s 2x10 10 evt/a 500 TB/a 2 streams 1 a = 10 7 s over 7-month period rDST 25 kB/evt RAW 25 kB/evt TAG b-inclusive DST+RAW 100 kB/evt b-exclusive DST+RAW 100 kB/evt D * rDST+RAW 50 kB/evt di-muon rDST+RAW 50 kB/evt pre-selection analysis 0.2 kSi2ks/evt

The LHCb Computing TDR. 9 Domenico Galli LHCb rDST: a Trick to Save Resources rDST is an intermediate format (final format is DST). rDST contains the information needed in the next analysis step. Missing quantities must be re-calculated at next analysis step: More CPU resources; Less Disk resources. Convenient, since additional CPU resources needed to re-calculate these quantities are cheaper than disk needed to store them. Quantities to be written on rDST chosen in order to optimize costs.

The LHCb Computing TDR. 10 Domenico Galli Event Sizes & Processing Requirements AimCurrent Event Size[kB] RAW2535 rDST258 DST7558 Event processing[kSI2k.s/evt] Reconstruction Stripping Analysis0.3?? Simulation (bb-incl)50

20 Ottobre 2005CCR - Roma11 Il modello gerarchico Visto il volume dei dati prodotti, sembra ovvio accettare che il primo centro di raccolta ed analisi sia al CERN. In principio tutta l’analisi potrebbe essere concentrata al CERN. Ci sono però alcuni buoni motivi per scegliere un modello distribuito: è inverosimile accentrare tutte le analisi al CERN, quindi un modello distribuito semplifica la distribuzione dei dati per le analisi (DST) da un punto di vista socio-economico, è più semplice ottenere cooperazione dai diversi enti distribuendo anche geograficamente il carico di lavoro. i problemi infrastrutturali legati alla gestione di un unico centro “collettivo” non ovvi da risolvere la presenza di centri di calcolo distribuiti semplifica sinergie con progetti non-LHC l’interazione con GRID è a due vie: da un lato GRID è lo strumento che consente di realizzare il calcolo distribuito, dall’altro la scelta di un modello di calcolo distribuito rende possibile l’accesso alle risorse GRID

LCG Slide No. 12 LHC Computing Grid – Technical Design Report 12Jürgen Knobloch, CERN-IT The Hierarchical Model  Tier-0 at CERN  Record RAW data (1.25 GB/s ALICE)  Distribute second copy to Tier-1s  Calibrate and do first-pass reconstruction  Tier-1 centres (11 defined)  Manage permanent storage – RAW, simulated, processed  Capacity for reprocessing, bulk analysis  Tier-2 centres (>~ 100 identified)  Monte Carlo event simulation  End-user analysis  Tier-3  Facilities at universities and laboratories  Access to data and processing in Tier-2s, Tier-1s  Outside the scope of the project

20 Settembre 2005CSN1 - Roma13 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Replica e distribuzione dei dati ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1 RAW:  Una replica completa dei raw data risiede nei Tier1 (~1/10 per Tier1)  Campioni di eventi sono memorizzati anche nei Tier2 e, in misura minore, nei Tier3 ESD:  Tutte le versioni degli ESD sono replicate e risiedono in almeno due dei Tier1  Gli ESD primari sono spediti dal Tier0 a un Tier1; in caso di successo, possono essere cancellati dal Tier0 (riprocessing solo ai Tier1)  Gli ESD primari e i RAW data asswociati sono assegnati ai ~10 Tier1 con un meccanismo di roundrobin  La replica degli ESD su un secondo Tier1 è un compito Tier1 -> Tier1 che può essere eseguito con comodo (ad es., quando non c’è data taking?); in ogni caso, il Tier0 non è coinvolto.  Campioni di eventi sono memorizzati anche nei Tier2 e, in misura minore, nei Tier3 AOD:  Sono replicati completamente in ogni Tier1 e parzialmente nei Tier2 (~1/3 – 1/4).  Alcune stream possono essere memorizzate nei Tier3 TAG:  I database dei TAG sono replicati in tutti i Tier1 e Tier2 DPD:  Nei Tier1, Tier2 e Tier3 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

20 Settembre 2005CSN1 - Roma14 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Data Flow: Streaming ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1 Stream di dati principali dagli High Level Trigger (LV2 + EF): Stream primario, contenente tutti gli eventi di fisica Express line Eventi di calibrazione: processamento veloce (risorse dedicate in situ) calibrazione fine (Tier2) Stream per debugging e diagnostica Obiettivi principali dello streaming: Ridurre la latenza per un sottoinsieme di eventi (in particolare quelli di calibrazione) Processare lo stream primario con i risultati ottenuti dallo stream di calibrazione Risorse necessarie: La calibrazione veloce e la express line dovrebbero occupare ~20% di bandwidth e CPU LV2 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

20 Settembre 2005CSN1 - Roma15 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Modelli di analisi ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1 Produzione centrale schedulata di AOD, n-tuple e TAG dagli ESD: Si assume che ci saranno ~20 gruppi di analisi Ogni canale di analisi può richiedere varie iterazioni, accedendo a: TAG di tutti gli eventi sottocampioni di AOD eventuali (pochi) ESD pochissimi eventi RAW Una riduzione al 10% di tutti gli AOD per gruppo, 2 versioni 125 TB ad ogni Tier1 Produzione in quasi real time di DPD 13 MSI2k Analisi caotica di singoli utenti di AOD e n-tuple, nuove selezioni, simulazioni particolari, etc.: Si assume che ci siano 600 utenti offsite (+100 al CERN), ciascuno dei quali analizza il 10% dei campioni dei gruppi di analisi (quindi 1% del totale degli AOD + pochissimi ESD) tiene su disco due versioni dei suoi DPD 15 kSI2k and 2.1 Tb per utente Uno scenario di analisi: Si invia una query a un dataset di TAG (es., l’ultimo) residente su DB Il risultato della query serve ad individuare gli AOD relativi agli eventi selezionati Un ulteriore algoritmo di selezione può essere applicato agli eventi e il risultato puo’ essere un dataset ridotto di AOD o DPD (piu’ raramente di ESD o RAW) o direttamente una n-tupla. L’analisi di grandi campioni di eventi sarà distribuita (Grid)! Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

16 CSN1 - Roma 20 Settembre 2005 Tiered Architecture Not all connections are shown - for example flow of MC data from Tier-2’s to Tier-1’s or peer-to-peer connections between Tier-1’s.

The LHCb Computing TDR. 17 Domenico Galli Computing Model

The LHCb Computing TDR. 18 Domenico Galli The LHCb Dataflow On-line Farm CERN Tier-1s CERN Tier-1s Tier-2s reconstruction pre-selection analysis RAWmc dataRAW data rDST DST+RAWTAG calibration data MC On-line Farm Physics Analysis Local Analysis n-tuple User TAG User DST TAGSelected DST+RAW Paper CERN Tier-1s Tier-3s CERN Scheduled job Chaotic job

20 Ottobre 2005CCR - Roma19 Il Tier ~6000 CPU servers x 8000 SPECINT2000 (2008) ~2000 Tape and Disk servers Campu s networ k Experimenta l areas Experimenta l areas WAN Gigabit Ethernet Ten Gigabit Ethernet Double ten gigabit Ethernet 10 Gb/s to 32×1 Gb/s ….…. 2.4 Tb/s CORE Distribution layer

20 Settembre 2005CSN1 - Roma20 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo del Tier0 ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1  Il Tier0 è responsabile dell’archiviazione e della distribuzione ai Tier1 (e Tier2) dei dati RAW, ricevuti dalla catena di TDAQ.  Processa velocemente gli stream di calibrazione e espressi.  Ricostruisce gli eventi (utilizzando le costanti di calibrazione calcolate) e produce i dataset derivati (ESD, AOD e TAG “primari”).  Distribuisce i dataset derivati ai Tier1.  In caso di problemi di processamento o trasmissione, memorizza i dati in un disk buffer che corrisponde a ~ 5 giorni di presa dati. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

21 CSN1 - Roma 20 Settembre 2005 Tier-0 Center u Functionality  Prompt first-pass reconstruction è NB: Not all HI reco can take place at Tier-0  Secure storage of RAW&RECO, distribution of second copy to Tier-1 u Responsibility  CERN IT Division provides guaranteed service to CMS è Cast iron 24/7  Covered by formal Service Level Agreement u Use by CMS  Purely scheduled reconstruction use; no ‘user’ access u Resources  CPU 4.6MSI2K; Disk 0.4PB; MSS 4.9PB; WAN 5Gb/s

LCG Slide No. 22 LHC Computing Grid – Technical Design Report 22Jürgen Knobloch, CERN-IT CPU Requirements CERN Tier-1 Tier-2 58% pledged

LCG Slide No. 23 LHC Computing Grid – Technical Design Report 23Jürgen Knobloch, CERN-IT Disk Requirements CERN Tier-1 Tier-2 54% pledged

LCG Slide No. 24 LHC Computing Grid – Technical Design Report 24Jürgen Knobloch, CERN-IT Tape Requirements CERN Tier-1 75% pledged

20 Ottobre 2005CCR - Roma25 I Tier-1 Tier-1 Centre Experiments served with priority ALICEATLASCMSLHCb TRIUMF, CanadaX GridKA, GermanyXXXX CC, IN2P3, FranceXXXX CNAF, ItalyXXXX SARA/NIKHEF, NLXXX Nordic Data Grid Facility (NDGF)XXX ASCC, TaipeiXX RAL, UKXXXX BNL, USX FNAL, USX PIC, SpainXXX

20 Settembre 2005CSN1 - Roma26 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo dei Tier1 ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1  Il modello prevede circa 10 Tier1.  Ogni Tier1 tiene in archivio 1/10 dei RAW data e ne garantisce l’accesso a lungo termine.  Ogni Tier1 tiene copia di 1/5 degli ESD e di tutti gli AOD e TAG (la versione più recente su disco, le precedenti eventualmente su mass storage a più lento accesso).  I Tier1 ospitano e rendono velocemente accedibili i campioni di eventi simulati prodotti nei Tier2 che a loro fanno riferimento.  I Tier1 devono garantire la capacità ci calcolo necessaria a riprocessare ed analizzare tutti i dati ivi residenti (Grid!).  Le risorse dichiarate devono essere disponibili a tutta la Collaborazione (ancora Grid!).  Il livello dei servizi, in termini di affidabilità e tempi di risposta, deve essere elevato; non dovrebbero verificarsi interruzioni superiori alle 12 ore e, in caso di periodi più lunghi, è previsto che un altro dato Tier1 fornisca almeno accesso agli stessi dati. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

20 Settembre 2005CSN1 - Roma27 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Evoluzione risorse ai Tier1 ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

28 CSN1 - Roma 20 Settembre 2005 Tier-1 Centers u Functionality  Secure storage of RAW&RECO, and subsequently produced data  Later-pass reconstruction, AOD extraction, skimming, analysis è Require rapid, scheduled, access to large data volumes or RAW  Support and data serving / storage for Tier-2 u Responsibility  Large CMS institutes / national labs è Firm sites: ASCC, CCIN2P3, FNAL, GridKA, INFN-CNAF, PIC, RAL  Tier-1 commitments covered by WLCG MoU u Use by CMS  Access possible by all CMS users (via standard WLCG services) è Subject to policies, priorities, common sense, …  ‘Local’ use possible (co-located Tier-2), but no interference u Resources  Require six ‘nominal’ Tier-1 centers; will likely have more physical sites  CPU 2.5MSI2K; Disk 1.2PB; MSS 2.8PB; WAN >10Gb/s

29 CSN1 - Roma 20 Settembre 2005 Tier1-CNAF (CMS only) CPU Dischi Nastri

20 Ottobre 2005CCR - Roma30 I Tier-2 Nel modello di calcolo di LHC i Tier-2 rivestono un ruolo molto importante. Sono di fatto il punto di accesso di tutti i fisici delle collaborazioni ai dati; sono lo strumento primario per l’analisi dati, in particolare per la fase “caotica” dell’analisi. ATLAS prevede di usare i Tier-2 anche per compiti critici da un punto di vista dei tempi, come le calibrazioni. Per LHCB sono i centri di produzione Montecarlo. Inoltre l’insieme dei Tier-2 costituisce circa la metà delle risorse di calcolo degli esperimenti. È ovvio quindi che il ruolo dei Tier-2 è tutt’altro che marginale, e che la pressione che gli esperimenti eserciteranno sui Tier-2 per ottenere le migliori prestazioni sarà sempre crescente.

20 Settembre 2005CSN1 - Roma31 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo dei Tier2 ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1  I Tier2 assumono un ampio spettro di ruoli e funzioni, in particolare per le calibrazioni, la simulazione e l’analisi.  La loro dimensione e il tipo di risorse può variare sensibilmente a seconda delle attività e della dimensione dei gruppi di fisica che vi fanno riferimento.  Un Tier2 ospiterà tipicamente 1/3 degli AOD correnti e tutti i TAG. Ospiterà anche i DPD di interesse locale e campioni di RAW data e ESD per analisi e sviluppo algoritmi.  I Tier2 forniscono tutta la capacità di simulazione necessaria alla collaborazione; a meno che un Tier2 non riesca a garantirne esso stesso l’accesso in modo veloce e affidabile, i dati simulati saranno migrati al Tier1 di riferimento (si ipotizzano circa 4 Tier2 per ogni Tier1).  Alcuni centri, a seguito del coinvolgimento della comunità locale in un rivelatore, potranno avere un ruolo rilevante nelle procedure di calibrazione e allineamento. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

20 Settembre 2005CSN1 - Roma32 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Attività prevista nei centri italiani ~PB/se c Tier2 ~1.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 8. MSI2k - 2 PB/y 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

20 Settembre 2005CSN1 - Roma33 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Risorse necessarie nei Tier-2/3 italiani ~PB/se c Tier2 ~1.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 8. MSI2k - 2 PB/y Nei Tier-2: Simulazioni per computing system commissioning Copia degli AOD (10 8 eventi * 100KB = 10 TB) con diversi sistemi di streaming (esclusivi e inclusivi) per (studi del modello di) analisi Campioni di eventi in formato RAW e ESD per calibrazioni e sviluppo algoritmi di ricostruzione Calibration centers Attività di analisi organizzate 450 KSI2K (250 già disponibili a fine 2005) 80 TB (30 già disponibili a fine 2005) Nei Tier-3: Attività di analisi individuali e caotiche 40 KSI2K 10 TB

20 Settembre 2005CSN1 - Roma34 Risorse complessive dei Tier-2 ATLAS (Comp. TDR)

20 Settembre 2005CSN1 - Roma35 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Risorse ai Tier0/1/2 + CAF necessarie per il solo 2008 ~PB/se c Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y Se i Tier2 devono supportare anche analisi “private”, aggiungere circa 1 TB e 1 kSI2 per utente

36 CSN1 - Roma 20 Settembre 2005 Tier-2 Centers u Functionality  The ‘visible face’ of the system; most users do analysis here  Monte Carlo generation  ‘Specialized CPU-intensive tasks, possibly requiring RAW data u Responsibility  Typically, CMS institutes; Tier-2 can be run with moderate effort  We expect (and encourage) federated / distributed Tier-2’s u Use by CMS  ‘Local community’ use: some fraction free for private use  ‘CMS controlled’ use: e.g., host analysis group with ‘common resources’ è Agreed with ‘owners’, and with ‘buy in’ and interest from local community  ‘Opportunistic’ use: soaking up of spare capacity by any CMS user u Resources  CMS requires ~25 ‘nominal’ Tier-2; likely to be more physical sites  CPU 0.9MSI2K; Disk 200TB; No MSS; WAN > 1Gb/s  Some Tier-2 will have specialized functionality / greater network cap

37 CSN1 - Roma 20 Settembre 2005 Tier2s CMS Italy CPU Dischi

38 CSN1 - Roma 20 Settembre 2005 Average Numbers: 6 Tier1s, 22.5 Tier2s

The LHCb Computing TDR. 39 Domenico Galli Computing Model - Resource Summary CPU power [MSi2k] [# 2.4 GHz PIV] CERN Tier-1s (6) Tier-2s (14) Total GHz PIV = 865 Si2k

The LHCb Computing TDR. 40 Domenico Galli Computing Model - Resource Summary (II) Disk [TiB] CERN Tier-1s Tier-2s71423 Total MSS [TiB] CERN Tier-1s Total

20 Ottobre 2005CCR - Roma41 La scala dei tempi SC3 LHC Service Operation Full physics run First physics First beams cosmics Sep05 - SC3 Service Phase May06 –SC4 Service Phase Sep06 – Initial LHC Service in stable operation SC4 Apr07 – LHC Service commissioned SC3 – Reliable base service – most Tier-1s, some Tier-2s – basic experiment software chain – grid data throughput 1GB/sec, including mass storage 500 MB/sec (150 MB/sec & 60 MB/sec at Tier-1s) SC4 – All Tier-1s, major Tier-2s – capable of supporting full experiment software chain inc. analysis – sustain nominal final grid data throughput (~ 1.5 GB/sec mass storage throughput) LHC Service in Operation – September 2006 – ramp up to full operational capacity by April 2007 – capable of handling twice the nominal data throughput

LCG Slide No. 42 LHC Computing Grid – Technical Design Report 42Jürgen Knobloch, CERN-IT Service Challenges  A series of Service Challenges (SC) set out to successively approach the production needs of LHC  While SC1 did not meet the goal to transfer for 2 weeks continuously at a rate of 500 MB/s, SC2 did exceed the goal (500 MB/s) by sustaining throughput of 600 MB/s to 7 sites.  SC3 will start now, using gLite middleware components, with disk- to-disk throughput tests, 10 Gb networking of Tier-1s to CERN providing SRM (1.1) interface to managed storage at Tier-1s. The goal is to achieve 150 MB/s disk-to disk and 60 MB/s to managed tape. There will be also Tier-1 to Tier-2 transfer tests.  SC4 aims to demonstrate that all requirements from raw data taking to analysis can be met at least 6 months prior to data taking. The aggregate rate out of CERN is required to be 1.6 GB/s to tape at Tier-1s.  The Service Challenges will turn into production services for the experiments.

LCG Slide No. 43 LHC Computing Grid – Technical Design Report 43Jürgen Knobloch, CERN-IT Data Challenges  ALICE  PDC04 using AliEn services native or interfaced to LCG-Grid. 400,000 jobs run producing 40 TB of data for the Physics Performance Report.  PDC05: Event simulation, first-pass reconstruction, transmission to Tier-1 sites, second pass reconstruction (calibration and storage), analysis with PROOF – using Grid services from LCG SC3 and AliEn  ATLAS  Using tools and resources from LCG, NorduGrid, and Grid3 at 133 sites in 30 countries using over 10,000 processors where 235,000 jobs produced more than 30 TB of data using an automatic production system.  CMS  100 TB simulated data reconstructed at a rate of 25 Hz, distributed to the Tier-1 sites and reprocessed there.  LHCb  LCG provided more than 50% of the capacity for the first data challenge The production used the DIRAC system.

20 Settembre 2005CSN1 - Roma44 Milestone Gennaio 2006: * production release per il commissioning del sistema di computing e studi iniziali sui raggi cosmici * completamento dell'implementazione dell'Event Data Model per la ricostruzione 2. Febbraio 2006: * inizio del Data Challenge 3, anche chiamato Commissioning del sistema di computing (Computing System Commissioning) 3. Aprile 2006: * integrazione dei componenti di ATLAS con il Service Challenge 4 di LCG 4. Luglio 2006: * production release per i run di raggi cosmici (autunno 2006) 5. Dicembre 2006: * production release per i primi data reali con i protoni.

45 CSN1 - Roma 20 Settembre 2005 Project Phases u Computing support for Physics TDR, -> Spring ‘06  Core software framework, large scale production & analysis u Cosmic Challenge (Autumn ‘05 -> Spring ‘06)  First test of data-taking workflows  Data management, non-event data handling u Service Challenges ( )  Exercise computing services together with WLCG + centres  System scale: 50% of single experiment’s needs in 2007 u Computing, Software, Analysis (CSA) Challenge (2006)  Ensure readiness of software + computing systems for data  10M’s of events through the entire system (incl. T2) u Commissioning of computing system ( )  Steady ramp up of computing system to full-lumi running P-TDR SC3-4 Cosmic CSA-06 Commissioning

The LHCb Computing TDR. 46 Domenico Galli LHCb Computing Milestones Analysis at all Tier-1’s - November 2005 Start data processing phase of DC’06 - May 2006 Distribution of RAW data from CERN. Reconstruction/stripping at Tier-1’s including CERN. DST distribution to CERN & other Tier-1’s. Alignment/calibration challenge – October 2006 Align/calibrate detector. Distribute DB slice – synchronize remote DB’s. Reconstruct data. Production system and software ready for data taking - April 2007

The LHCb Computing TDR. 47 Domenico Galli LHCb Computing Milestones (II) LHCb envisages a large scale MC production commencing January 2006 ready for use in DC06 in May. It will be order of 100's Mevents. Physics request will be planned by the end of October. Mainly for: Physics studies; HLT studies. MC production 2006 is not included in DC’06 (it is no more a real “challenge”). From now on, practically speaking, an almost continuous MC production is foreseen for LHCb: This support the request of a chunk of computing resources (mainly CPUs) permanently allocated to LHCb, the LHCb Italian Tier-2.

20 Ottobre 2005CCR - Roma48Conclusioni Il calcolo degli esperimenti LHC è basato su un modello gerarchico geograficamente distribuito. In questo modello ogni anello della catena di processamento svolge un ruolo chiave. La numerazione dei Tier può essere misleading: in realtà ogni livello è indispensabile per il funzionamento del sistema. I Tier-2 in particolare sono i centri per la fase finale dell’analisi dati, ovvero quella pilotata dalle specifiche esigenze dei gruppi durante la preparazione delle pubblicazioni. Visto il tipo di richieste non rigidamente programmate, è ragionevole pensare che per i Tier-2 conti, più che l’efficienza globale, la capacità di assorbire picchi di carico improvvisi. Nei periodi più tranquilli si farà produzione montecarlo. I tempi di preparazione sono stretti, specie per i centri che sono chiamati al processamento di stream di calibrazione o allineamento, che saranno critici allo startup di LHC.