Workshop su GRID computing e calcolo avanzato Napoli, 6 maggio 2003

Presentazione sul tema: "Workshop su GRID computing e calcolo avanzato Napoli, 6 maggio 2003"— Transcript della presentazione:

1 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

2 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) ( m) (< m) ( m) ( m)

3 (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 = km/s)

4 Alte Energie significano anche alte temperature equivalenti e conseguentemente riproduzione in laboratorio di condizioni esistenti nel “lontano passato dell’Universo” 3 secondi minuti anni miliardo di anni 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

5 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 gradi Kelvin 1 Mld Tempo Temperatura

6 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 ( ) LHC: Large Hadron Collider ( )

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

8

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

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

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

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

13 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 Hz Top Hz W kHz

14 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

15 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 L = 1034 cm-2 s-1 1° livello di Trigger 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

16 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) ~ PC

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

18 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

19

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

21 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

22 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

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

24 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

25 Su RETI VELOCI

26

27 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

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

29 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

30 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 1/3 del totale 0,2 2 0,4 Each T3 S 1/3 del totale 0,010 x 0,05 Total > 2 > 20 24 MCHF 8 MCHF/RC 1 10% RC 10% delle risorse a regime @ 50 CPU + 4 TB

31 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 DC /2003 Pile-Up Production (High and Low Luminosity) Large scale Grid test for reconstruction Reconstruction start March 2003 ~ 10**7 fully simulated events DC /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 DC /2005 scale: 5 x DC2 DC /2006 scale: 2 x DC3

32 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

33 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.

34 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.

35 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”

36 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

37 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, …

38 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

39 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

40 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

41 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

42 La GRID dei TIER per LHC

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

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

45 Esperimento BaBar a SLAC (California, USA)

46 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

47 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

48 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.