Il modello di calcolo distribuito per gli esperimenti di Fisica delle Alte Energie Workshop su GRID computing e calcolo avanzato Napoli, 6 maggio 2003 Leonardo Merola Dipartimento di Scienze Fisiche - Università di Napoli “Federico II” Istituto Nazionale di Fisica Nucleare - Sezione di Napoli

La Fisica delle Particelle delle Alte Energie studia i costituenti fondamentali della materia (privi di struttura interna ?), che costituiscono i “mattoni” della Natura e le loro interazioni. (1 m) (10 -10 m) (< 10 -18 m) (10 -15 m) (10 -14 m)

(c = velocità della luce nel vuoto La tecnica più usata è la collisione di particelle ad altissima energia prodotte in acceleratori. L’energia della collisione viene “spesa” per la produzione di centinaia di particelle la cui natura e le cui caratteristiche dinamiche dipendono dal tipo di interazione, dall’energia totale, dalla natura delle particelle collidenti. E = mc2 (c = velocità della luce nel vuoto = 300.000 km/s)

Alte Energie significano anche alte temperature equivalenti e conseguentemente riproduzione in laboratorio di condizioni esistenti nel “lontano passato dell’Universo” 3 secondi 3 minuti 300.000 anni 1 miliardo di anni 15 miliardi di anni Big Bang Energia e protoni e nubi di atomi stelle e l’universo particelle neutroni di idrogeno e di galassie in oggi esotiche elio formazione

O G I Tempo Temperatura 10 32 10 15 10 13 10 9 6000 18 3 gradi Kelvin Adroni Nuclei Atomi -> Molecole Galassie O G I 10 32 10 15 10 13 10 9 6000 18 3 gradi Kelvin 1 Mld Tempo Temperatura

CERN LEP : Large Electron Positron collider (1989-2000) Centro Europeo per la Fisica delle Particelle LEP/ LHC SPS CERN GINEVRA LEP/ LHC SPS CERN GINEVRA 27 km LEP : Large Electron Positron collider (1989-2000) LHC: Large Hadron Collider (2007-2020)

LEP : elettroni positroni (ECM fino a 210 GeV) LHC : protoni protoni (ECM = 14000 GeV) LEP / LHC SPS CERN PS Aeroporto di Ginevra FRANCIA SVIZZERA

Parametri della macchina LHC F = 0.9, v = rev freq., N = Prot/bunch, s= transv beam size

Gli Esperimenti a LHC CMS ATLAS LHCb p-p p-p p-p Pb-Pb

Molteplici SFIDE VASTE COLLABORAZIONI INTERNAZIONALI: Decine di migliaia di fisici, tecnologi, tecnici Centinaia di Istituzioni e Università in decine di Paesi e vari Continenti

APPARATI SPERIMENTALI GIGANTESCHI: Peso: 12500 ton Diametro: 15 m Lunghezza: 21,6 m Campo magnetico: 4 Tesla C M S

FISICA DIFFICILE: Sezioni d’urto di produzione di eventi interessanti (ad es. Ricerca del bosone di HIGGS) molto basse e molto difficili da riconoscere in modo non ambiguo: dN/dt = s L N = N. eventi = Sezione d’urto del processo L = Luminosità della macchina tot = 70 mbarn =>109 interazioni al secondo Higgs 10-2 - 10-1 Hz Top 10 Hz W 2 kHz

calcolatore di un evento di collisione protone - protone Simulazione al calcolatore di un evento di collisione protone - protone (14 TeV) a LHC con produzione e decadimento di un bosone di Higgs: H  ZZ  4 m Simulazione di un evento: 3000 SpecInt95*sec  > 1 min su PIV 1GHz

Rivelatori,Trigger, DAQ, Computing SISTEMI DI RIVELAZIONE, ACQUISIZIONE DATI E SELEZIONE ON-LINE E OFF-LINE SOFISTICATI: Rivelatori,Trigger, DAQ, Computing Frequenza di Bunch-crossing = 40 MHz Frequenza di Interazione ~109 Hz @ L = 1034 cm-2 s-1 1° livello di Trigger 75-100 kHz Combina informazioni dai calorimetri e dallo spettrometro μ. Identificazione del Bunch Crossing ID 2° livello di Trigger ~1kHz Utilizza le ROI formate dal LVL1 Criteri di selezione piu’ stringenti 3° livello di trigger (EF) ~100 Hz Utilizzo software offline

109 eventi/s con incroci dei fasci a 40MHz (bunch-crossing 25 ns) 100 eventi/s su memoria di massa 1 MByte/evento  100MB/s 107 s tempo di raccolta dati/anno GRANDE MOLE DI DATI: ~ 1 PetaByte/anno di dati “RAW”+ ~ 1 PetaByte/anno di dati simulati INGENTI RISORSE DI CALCOLO: ~ 1 MSI95 (PIII 500 MHz ~ 20SI95) ~ 100.000 PC

CMS Situazione analoga per l’esperimento CMS ~ PetaByte/anno di dati “RAW”

COMPLESSITA’ DEI DATI DA TRATTARE: Ricostruzione di vertici di interazione e di decadimento, ricostruzione di tracce, identificazione di particelle, misura delle loro energie e degli impulsi: Ricca gerarchia di centinaia di tipi di dati complessi (classi) Molte relazioni fra essi Differenti tipi di accesso Uso della Tecnologia OO (Object Oriented) per il software di simulazione e ricostruzione di vertici e tracce, per il database degli eventi, per l’analisi dei dati Uso degli strumenti più avanzati SW e calcolo/analisi C++, JAVA, PERL, ROOT, GEANT4, PAW, … Event TrackList Tracker Calorimeter Track HitList Hit

Il problema non è l’hardware che è sempre più potente e costa sempre meno: CPU Nastri Dischi

Il problema è il software (e il middleware): Scientist MIDLEWARE Experiment Computing Storage Analysis Il fisico HEP (High Energy Physics) non deve vedere le differenze degli ambienti di calcolo a cui accede. Il “Middleware”, una via di mezzo tra hardware e software, deve assicurare la compatibilità fra i vari ambienti. CLRC Daresbury

Le “griglie computazionali” << GRID >> World Wide GRID Gli esperimenti di Fisica delle Alte Energie stanno sperimentando una soluzione su scala mondiale per: a) Calcolo intensivo distribuito b) Accesso veloce e flessibile a grandi moli di dati Le “griglie computazionali” << GRID >> World Wide GRID

Costituiremo VIRTUAL ORGANIZATIONS (VO) per la collaborazione e la condivisione delle risorse: Esperimenti: ATLAS, CMS, ALICE, LHCb, BABAR, CDF, …

Utilizzeremo i SERVIZI DI GRID Application Distributed Computing synchronous processing High-Throughput Computing asynchronous processing On-Demand Computing dynamic resources Data-Intensive Computing databases Collaborative Computing scientists User Application Internet Protocol Architecture Collective; es. RM Resource; es.CE,SE Connectivity;es IP Transport Internet Fabric; es. LSF.. Link

Su RETI VELOCI

Modello di calcolo distribuito per gli esperimenti a LHC Gerarchia “funzionale” a più livelli (Tier-x) Data Server CPU Server desktop CERN Tier 0 Tier 2 (Centri Nazionali e Regionali) Tier 3-4 (Dip. e Istituti) Tier 1 (Centri Nazionali

Struttura a Tiers di ATLAS Italy-INFN CNAF-BO US MI RM1 NA PV GE …

Tipo di dati da produrre e conservare: RAW DATA: 2 MB/evento, 100 Hz (Data acquisition, Reprocessing, Event Reconstruction) MC RAW DATA: 2 MB/evento, 3000 SI95*s ESD, Event Summary Data, output della ricostruzione: 500 KB/evento, 640 SI95*s (Reprocessing, Event Reconstruction, MC simulation) AOD, Analysis Object Data, formato "pubblico" di analisi: 10 KB/evento, 25 SI95*s (MC simulation, Physics Analysis) DPD, Derived Physics Data, formato “privato” di analisi, tipo n-pla: 1 KB/evento, 5 SI95*s (Physics Analysis) CERN Tier 0/1 Tier 1 Regional Centers Y Z X Lab a Uni n Tier2 Regional/National Centers Lab b Uni c Tier3/4 Departments    Desktop PHYSICS ANALYSIS

Risorse HW ATLAS a regime (2007) CPU (MSI95) Tape (PB) Disk (PB) CERN (T0+T1) @ 1/3 del totale 0,5 10 0,8 Each RC T1+T2 (6 RC in totale) S T1+T2 @ 1/3 del totale 0,2 2 0,4 Each T3 S T3+T4 @ 1/3 del totale 0,010 x 0,05 Total > 2 > 20 24 MCHF 8 MCHF/RC 1 T2: @ 10% RC 2003/4: @ 10% delle risorse a regime @ 50 CPU + 4 TB

Data Challenges DC0 – 2001/2002 DC1 - 2002/2003 DC2 - 2003/2004 Motivated by need to test scaling of solutions: Hardware, Middleware and Experiment Software) DC0 – 2001/2002 Tests of the ATLAS software DC1 - 2002/2003 Pile-Up Production (High and Low Luminosity) Large scale Grid test for reconstruction Reconstruction start March 2003 ~ 10**7 fully simulated events DC2 - 2003/2004 Geant4 replacing Geant3 Pile-up in Athena Use LCG common software Use widely GRID middleware Perform large scale physics analysis As for DC1: ~ 10**7 fully simulated events DC3 - 2004/2005 scale: 5 x DC2 DC4 - 2005/2006 scale: 2 x DC3

D US CERN J F I grid tools used at 11 sites CPUs Italia: 46 RM1 40 CNAF 16 NA 10 LNF J F I

La farm di ATLAS-Napoli 7 nodi diskless con 2 CPU PIII a 1 GHz, RAM 512 MB, 2 schede di rete a 100 Mb/s. Server con 2 CPU PIII a 1 GHz, 1 GB RAM, 2 schede di rete a 100 Mb/s, 1 scheda di rete a 1 GB/s 2 TB storage ATLAS SW e primi tools di GRID 1 Gb/s 100 Mb/s CPU Server Disk E’ in corso l’evoluzione dal ruolo di Tier-3 a quello di Tier-2, con l’estensione delle risorse della farm: 25 biprocessori e 4 TB disco.

Obiettivi GRID a breve termine della Farm di ATLAS Napoli Prendere parte ai test di ricostruzione con il Middleware EDG che già coinvolgono RAL, Lione, CNAF (e in seguito Milano, Cambridge e Roma). Registrare le risorse nella Virtual Organization di ATLAS e configurare diverse macchine della Farm come elementi della griglia mediante l'installazione del middleware di EDG. Istallare un Computing Element (che gestisce localmente l’allocazione del lavoro), uno Storage Element (che gestisce lo storage) e diversi Worker Nodes (che girano i job). Pubblicare le informazioni relative alle risorse dela Farm sulla GRID in modo che mediante un Resource Broker i job vengano assegnati alla Farm.

Il Modello di CMS Il Modello di calcolo di CMS Italia è un modello integrato di Funzionalità dei Tier1, Tier2 e Tier3. Tier2 di riferimento a Legnaro Schema di “calcolo” distribuito sulle Sedi. Alcune funzioni e specificita’ (chiamate in gergo “services”) sono tipiche di una gerarchia Modello di Tier0, Tier1, Tier2, Tier3 … Altre sono tipiche di una distribuzione paritaria Modello distribuito alla “GRID”

Ruolo del Tier1 (comune per l’INFN) ~40% del commitment italiano Assorbimento dei picchi di CPU (shared con gli altri Esperimenti) Mass Storage e accentramento dei dati di simulazione e analisi Riferimento core software (supporto) Ruolo dei Tier2 (incluso il Tier2 di riferimento) CPU e storage (solo dischi e/o archive) per l’analisi (distribuita) Dimensionamento delle attivita’ in funzione delle competenze ed interessi locali (dal farming alla analisi) Ruolo dei Tier3 ~20% del commitment italiano Punto di forza in item specifici sia di analisi che di software e/o supporto e/o middleware

Software in comune con gli altri esperimenti LHC Prodotti software che non hanno a che fare con “Dati e Calcolo distribuiti” (Grid independent): es. Generatori di Fisica, (Detector Description DataBase), … Prodotti software (middleware) che gestiscono la distribuzione dei dati e del calcolo (Grid dependent): es. Brokering dei job, Data replication, Information System, Monitoring, … Prodotti software che sono influenzati dalla caratteristica distribuita del Calcolo (Grid-aware): es. Persistenza, meta-data structure, Bookkeeping… Prodotti che NON “possono” essere comuni: programmi di ricostruzione dei vari detector, tools di gestione specifici dell’architettura del Computing Model, …

Logical components diagram Software Release Manager Repository Experiment Software Software release SW download & installation Dataset Input Specification Dataset Algorithm Specification Copy data Data Management System Dataset Catalogue Storage Service Data Dataset Definition New dataset request Data management operations Retrieve Resource status Read data Write data Resource Monitoring System Resource Directory Production on demand Publish Resource status Update dataset metadata Input data location Data Materializer Production monitoring Job creation The grid is composed by Computing Services, that provide CPU power and Storage services, that provide disk or tape to store data. The user machine is not shown and is ideally locate on the left. In general the kind of operations that are needed on the data are read/write from/to the storage starting from the computing nodes and data movement (copy). All the operations are not done directly on the Computing and Storage Services, but through interfaces that provide the security infrastructure: the Workload Management System and the Data Management System. The former has a database that keep information about the tasks it was requested to perform (jobs), the latter has a catalogue of datasets (collection of files) that it controls. The Resource Monitoring System keeps a directory of all the available resources so that the DMS and DMS can optimize their operations. The WMS can also get info from the DMS about datasets to optimize its choices. The Software Release Manager controls the access to the Experiment software, so that it can me installed on the computing nodes. At this point a job can be submitted to the WMS. A component that is important for CMS is the Job Monitoring System, where the running jobs can write information about the task they’re performing. This provides the necessary book-keeping of the production system. The specific monitoring operations are defined by the user. When a new dataset is requested (by a user or a physics group) its definition is stored in the DMS catalogue (The catalogue is indexed by the dataset name). The definition includes at least the following information: The executable to be used for the production of that dataset, which is a reference to the Software Release Manager The list of parameters to be used to correctly configure the executable The list of input datasets (if any), which are referencies to other entries of the DMS catalogue The output dataset name is the parameter by which the catalogue is indexed When a dataset which has been requested (but not produced yet) is accessed, The DMS invokes a “Data Materializer” i.e. a component that can builds the jobs that produce the requested data. The Data Materializer can also interrogate the Job Monitoring System to get information about the status of the production and update the DMS. Workload Management System Job Catalogue Job Definition Job assignment to resources Computing Service Job submission Job output filtering Job Monitoring System Job Book-keeping Job Monitoring Definition Push data or info Pull info Job type definition By Claudio Grandi

Layout farm LNL 2002: production + analysis + grid = grid enabled element N1 N24 Production computing nodes N1 N24 N1 N24 N1 N24 Analysis computing nodes FastEth FastEth FastEth SWITCH SWITCH SWITCH To WAN 34 Mbps 2001 ~ 1Gbps 2002 32 – GigaEth 1000 BT CE GW S1 S9 S10 S11 SE S10 S11 S12 G1 UI G2 Analysis servers Production servers Production control Remote login Analysis Grid enabled Analysis

Il progetto LCG (LHC Computing Grid) The Goal of the LHC Grid To help the experiments’ computing projects prepare, build and operate the computing environment needed to manage and analyze the data coming from the detectors LCG

2003 – Establish the LHC grid as a reliable, manageable, permanently available service including the Tier 1 and many Tier 2 centres Serve as one of the computing facilities used for simulation campaigns during 2H03 2004 – Stable service for batch analysis Scaling and performance tests, commissioning of operations infrastructure Computing model tests – 4 collaborations Tier 0 – Tier 1 – Tier 2 – Tier 3  Computing TDRs at end 2004 2005 – Full prototype of initial LHC service – second generation middleware - validation of computing models (4 collaborations) - validation of physical implementation – technology, performance, scaling LCG TDR – sizing/cost/schedule for the initial LHC service – July 2005 2006–2008 acquire, build and operate the LHC computing service LCG-1 LCG-3

La GRID dei TIER per LHC

Le Capacità Richieste per LHC CERN (Somma di tutti gli esperimenti): Mass Storage: 10 Peta Bytes (1015 B)/anno disk: 2 PB (100.000 Dischi da 20GB) CPU: 20 MSPECint2000 (40.000 Pentium@1GHz) Per ogni Tier 1 Multi-esperimento : Mass Storage: 1 - 3 PB/anno disk: 1.5 PB CPU: 10 MSPECint2000 Networking Tier 0 (CERN) --> Tier 1: 2 Gbps (>4.000 connessioni ADSL)

Il Tier 1 dell’INFN CNAF Programma delle Installazioni NB: I numeri quotati sono aggiuntivi per anno

Esperimento BaBar a SLAC (California, USA)

Struttura a Tiers di BABAR Tier 0: SLAC Stanford CA, USA TierA/B : Lione IN2P3, RAL, INFN-PD, INFN-CNAF Tier C: NA, …. Role of Tier A sites: reduce significantly computing burden at SLAC Primarily analysis: IN2P3, RAL Production: INFN-Padova Issues: data replication at Tier A’s data partitioning at Tier A’s (micro, mini, beam data, MC) transparent access to data across Tier A’s (BabarGrid) specialization of Tier A’s: skimming, (re-)processing, etc. Role of Tier C sites: smaller sites at remote institutes main contribution so far in MC production (majority of MC events produced away from SLAC) analysis at Tier C’s has been difficult due to problems with data distribution  need to resolve with new Computing Model

Il processo di analisi Identificazione dei campioni di dati da analizzare con strumenti di bookkeeping Omogenei per dati e Monte Carlo Sottomissione (e monitaggio) job di l’analisi Analisi combinatoria (D, D*, B-reco, …) Calcolo delle quantità fisiche Scrittura nuovo micro-DST ridotto contenente le informazioni per l’analisi Working Group Produzione centralizzata per tutta la collaborazione (ogni 3 mesi) Riduzione dei micro-DST per le analisi specifiche Produzione dei risultati con accesso interattivo ai micro-DST (ROOT, …) Oppure produzione di ntuple ridotte e istogrammi nel formato finale per l’analisi Preparazione dei documenti di analisi

CONCLUSIONI Stiamo costruendo un prototipo di sistema di calcolo distribuito basato su GRID. Dobbiamo essere pronti per lo startup di LHC: 2007 Numerosi sono i progetti su GRID nazionali (es. INFN-GRID, FIRB GRID.IT) ed europei (es. DataTAG, LCG, EGEE) in cui noi fisici delle Alte Energie siamo coinvolti. Auspichiamo una collaborazione stretta anche con altri settori scientifici per la realizzazione di una infrastruttura comune di GRID anche a livello locale.