per la fisica delle alte energie GRID per la fisica delle alte energie Nicola De Filippis Dipartimento di Fisica dell’Università degli Studi e del Politecnico di Bari e INFN

Sommario I progetti GRID GRID per gli esperimenti HEP ad LHC L’esperienza di CMS in GRID: Il Data challenge 2004 L’analisi di utente finale

Perchè GRID? Quando si collega una qualunque apparecchiatura alla rete elettrica non ci si preoccupa della locazione della sorgente di energia e della distribuzione di questa su aree geografiche. ….allo stesso modo immaginiamo di collegare il computer alla presa di casa e di avere a disposizione immediatamente tutte le risorse di calcolo di cui si ha bisogno, senza preoccuparsi di dove esse siano e come vi ci si accede.

Perchè GRID? La fisica, l’ingegneria, l’analisi medica, le biotecnologie, l’informatica, etc. procedono attraverso: risorse di calcolo, sistemi di informazione e strumenti eterogenei; le interazioni delle persone; tutte geograficamente e organizzativamente sparse. Lo scopo principale delle “Grid”: di fornire un insieme di risorse di calcolo fisicamente distribuite in un numero di siti geograficamente separati, su scala mondiale; di facilitare le interazioni di queste risorse.

Che cosa è GRID? GRID è un sistema costituito da: “ Grid computing [is] distinguished from conventional distributed computing by its focus on large-scale resource sharing, innovative applications, and, in some cases, high-performance orientation...we review the "Grid problem", which we define as flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and resources - what we refer to as virtual organizations.“ From "The Anatomy of the Grid: Enabling Scalable Virtual Organizations" by Foster, Kesselman and Tuecke GRID è un sistema costituito da: risorse di calcolo: server di dati, nodi di calcolo, strumenti distribuiti geograficamente e accessibili attraverso una rete molto efficiente software che fornisce interfacce uniformi e standard in modo da garantire un utilizzo trasparente e capillare delle risorse distribuite possibilità di creazione di potenti sistemi di calcolo virtuali (virtual organization), aggregando risorse distribuite.

Applicazioni di GRID Mediche e biomediche: Chimica: Studi sul Clima Processing delle immagini (digital X-ray image analysis) Simulazione per le terapie di radiazione Protein folding Chimica: quantistica organica modello dei polimeri Studi sul Clima Scienza spaziale Fisica: Fisica delle alte energie e degli acceleratori Fisica teorica, calcoli su reticolo Fisica del neutrino Genomica Scienze dei materiali BARI

GRID per la fisica delle alte energie Gli esperimenti di HEP ad LHC (Large Hadron Collider) useranno la GRID come soluzione per il calcolo intensivo e la gestione di enormi quantità di dati. CMS ATLAS LHCB ALICE

I numeri per la HEP Il passato al LEP: collisore e+e- Rivelatore: ALEPH Dati in 10 anni: qualche TB (1012Bytes) CPU: qualche centinaio al CERN utenti di analisi: 200 Collaborazione 500 persone Il presente ad LHC:collisore pp Rivelatore: CMS Dati in 1 anno: 1 PB (1015Bytes) CPU: 4000 CPU per il DAQ al CERN utenti di analisi: 1000 Collaborazione: 1500 persone

GRID per l’HEP: funzionalità richieste Gestione di decine di PetaByte di dati per anno, storage, risorse di rete Gestione del calcolo su grandi quantità di dati: tempi di processing lunghi, utilizzo di grande memoria, esecuzione di applicazioni intense di I/O Definizione di policy locali e globali per la gestione delle risorse cioè per stabilire che cosa può essere usato per che cosa, da chi e dove… Alte prestazioni per l’accesso ai dati remoti in termini di velocità ed affidabilità Controllo sull’accesso ai dati e sugli utenti Elaborazione di software per cataloghi di dati Gestione delle repliche dei dati e discovery della copia “migliore” di questi Coordinazione, sincronizzazione e autenticazione del sistema LCG L’architettura distribuita è necessaria e vitale

LHC Computing Grid Project – LCG Les Robertson – LCG Project Leader CERN – European Organisation for Nuclear Research Geneva, Switzerland LCG Scopo del progetto: Preparare, testare e rendere operativi: l’ambiente di calcolo per analizzare i dati raccolti dai rivelatori ad LHC l’ambiente di sviluppo di applicazioni, strumenti comuni e framework GRID è solo uno strumento per raggiungere questo scopo

BARI Total: 78 Sites ~9000 CPUs 6.5 PByte LCG-2/EGEE-0 Status 24-09-2004

Componenti e flusso dei job in LCG Replica Catalogue (RC) UI JDL Information Service (IS) Resource Broker (RB) Working Node (WN) Storage Element (SE) Logging & Bookkeeping (LB) Job Submission Service (JSS) Computing Element (CE)

Componenti del sistema LCG (1) Il sistema LCG è organizzato in: Virtual Organizations (cms,atlas, ecc.): insiemi di individui e istituzioni che condividono risorse in maniera flessibile, sicura e coordinata. Infrastruttura di sicurezza grid per l’autenticazione tramite certificato utente in forma criptata. UserInterface (UI): macchina dove l’utente LCG ha un account personale e dove il certificato utente è installato; la UI fa da gateway ai servizi grid per le operazioni di base: a) sottomettere un job per l’esecuzione su un nodo di calcolo; b) listare tutte le risorse adatte per eseguire il job; c) Replicare e copiare file; d) Monitorare lo stato di job, cancellare job; e) recuperare l’output dei job finiti Computing element (CE): è la macchina che fa da server delle code di batch come front-end al resto della grid; al CE è associato un cluster di nodi di calcolo Worker Nodes (WN).

Componenti del sistema LCG (2) Storage element (SE): macchina che fornisce un accesso uniforme ed i servizi per grandi spazi di storage: array di dischi, sistemi di storage di massa. Resource Broker (RB): il RB è la macchina dove girano i servizi di workload management che risolvono il matching fra le richieste del job di un utente e le risorse disponibili, selezionando quelle più opportune per il job. Replica Location Service (RLS) and Replica Manager: forniscono i servizi e gli strumenti client di management dei dati; in ambiente grid, i file di dati sono replicati in differenti siti e gli utenti o le applicazioni non hanno bisogno di sapere dove sono localizzati i dati. Software installation: l’esigenza di un ambiente software omogeneo per gli esperimenti ad LHC ha portato alla creazione di una procedura di installazione e di management del software tramite strumenti grid. Un software manager per ogni esperimento è responsabile dell’installazione di software specifico di experimento in tutti i siti LCG.

La farm CMS/GRID di Bari Hardware: 1 server di batch (2 CPU 1.2 Ghz) 25 WN (biproc. da 1.2 a 3.2 GHz) 6 code (4 per grid 2 in locale) 5 TB per i dati di Input/Output 650 Gb per le home degli utenti Servizi: Batch System: Torque Scheduler: Maui File access: RFIO e NFS Database server: MySQL Sistema operativo: Scientific Linux

Modello di calcolo di CMS in LCG Tier2 Centre ~1 TIPS Online System Offline Processor Farm ~20 TIPS CERN Computer Centre FermiLab ~4 TIPS France Regional Centre Italy Regional Centre Germany Regional Centre Institute Institute ~0.25TIPS Physicist workstations ~100 MBytes/sec ~622 Mbits/sec ~1 MBytes/sec There is a “bunch crossing” every 25 nsecs. There are 100 “triggers” per second Each triggered event is ~1 MByte in size Physicists work on analysis “channels”. Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server Physics data cache ~PBytes/sec ~622 Mbits/sec or Air Freight (deprecated) Caltech ~1 TIPS Tier 0 Tier 1 Tier 2 Tier 4 1 TIPS is approximately 25,000 SpecInt95 equivalents Bari Tier 3

L’esperienza di CMS in GRID L’attivita del calcolo di CMS nel 2003-2005 è stata di: a) simulazione su larga scala di eventi di fisica a CMS con tecniche Monte Carlo e simulazione dell’apparato sperimentale c) messa a punto degli strumenti di calcolo per la gestione dei dati attraverso step successivi di complessità crescente: Data Challenges d) Messa a punto e test della intera catena di analisi che comprende: Ricostruzione degli eventi al Tier-0 Data Management al Tier-0 e distribuzione ai Tier-1 Trasferimento di campioni di dati ai Tier-2 dai Tier-1 Analisi dei dati in real-time ai Tier-1 e Tier-2 Analisi di utente finale di CMS per studi di fisica Il gruppo di Bari ha fortemente contribuito a tutti gli step.

Il Data Challenge 2004 – DC04 E’ stata una sperimentazione su larga scala dei modelli di calcolo e analisi con 50 milioni di eventi simulati, corrispondenti a circa il 25 % del numero di eventi acquisiti dall'apparato CMS in un mese (a LL): Simulation Generation Pre-Challenge Production (PCP) nel 2003/2004 Simulazione e digitizzazione di 70 milioni di eventi come input per il DC04 750K job, 3500 KSI2000, 700 K file,80 TB di dati 2 milioni di eventi simulati a Bari Produzioni fatte su farm locali e via GRID-LCG (40 %) Data Challenge (DC04) Ricostruzione di dati per un periodo continuato a 25Hz Distribuzione dei dati ai siti Tier-1,Tier-2 Analisi dei dati in siti remoti in real-time (Bari) Dimostrazione della fattibilità della catena (Bari) PCP Digitization DC04 25Hz Tier-0 Tier-1 Reco Data Tier-2 Reconstruction Analysis

Produzione di CMS in LCG: risultati  2.6 Milions of events ( 10K job lunghi), 2TB data Efficienza globale tra il 70% ed il 90% La rate di failure variabile a causa di alcuni problemi: Non disponibilità dell’RLS poche volte, →la rate di failure dei job poteva crescere sino al 25-30% Instabilità dovuta a errata configurazione di un sito, problemi di rete, problemi di scheduler locale, failure dell’hardware con inefficienza totale di circa 5-10% Pochi % dovuti a failure dei servizi La rate di successo su LCG-1 era più bassa rispetto a CMS/LCG-0 (efficienza  60%) minore controllo sui siti, minore supporto per siti e servizi (anche per Natale 2003) Difficoltà maggiori identificate nella configurazione dei siti Buone efficienze e condizioni stabili del sistema wrt con quelle dei challenges precedenti che dimostravano la maturità del middleware e dei servizi, purchè un continuo e rapido supporto fosse garantito dai fornitori del middleware e dagli amministratori di sito

La real-time analysis per il DC04 Goal della real-time analysis per il DC04: dimostrare che i dati potevano essere analizzati non appena erano trasferiti ai Tier-1 e misurare il ritardo temporale tra la ricostruzione al Tier-0 e l’analisi ai Tier-1/Tier-2 stabilire la replica automatica di dati ai Tier-2 per l’analisi valutare la robustezza del middleware LCG2 per l’analisi dei dati, i successi, le failure ed i colli di bottiglia Strategia: Sviluppare dei codici per permettere la preparazione di job di analisi e la sottomissione sincrona con l’arrivo dei dati (BARI) Usare il Resource Broker e le risorse CMS in LCG-2 (Tier-1/2 in Italia e Spagna)

DC04: Statistica temporale dei job Analisi tTH eseguita su un campione mu03_W1mu Tempo di esecuzione totale ~ 7 minuti Tempo di esecuzione di ORCA ~ 5 minuti Tempo di attesa dei job sulla GRID ~ 2 min. Tempo per copiare i file di input e output ~ 110 secondi Overhead di GRID

DC04: Analisi della timeline Il ritardo temporale tra la disponibilità al Tier-0 di un file e l’analisi a PIC è stato 20 minuti in media. Il tempo minimo è stato circa 5 minuti. I contributi più importanti: tempo di trasferimento del file dal Tier-0 al Tier-1 ~ 13 minuti in media. tempo di replica dallo SE CASTOR al SE disco ~ meno di 1 minuto. tempo per la preparazione del job~ circa 1.5 minuti il tempo per la sottomissione di job ~ 3 minuti overhead di sottomissione del job dovuto alla grid è ~ 2 minuti

La real-time analysis: risultati La real-time analysis è stata eseguita con successo ai Tier-1/2: due settimane di running quasi continuo in Italia! il numero totale di job sottomessi ~ 17500 la massima rate di eventi analizzati ~ 40 Hz L’efficienza della grid è risultata più grande del 90 % Il ritardo dalla ricostruzione dei dati al Tier-0 alla loro analisi è stato di 20 minuti in media La catena implementata ha soddisfatto i goal del DC04 della distribuzione di file su larga scala in alcuni siti e la successiva analisi.

L’analisi di utente finale Esempi: Ricerca del bosone di Higgs ad LHC Ricerca di particelle supersimmetriche ad LHC L’analisi consiste: nell’eseguire dei codici di selezione su campioni di eventi simulati o dati reali distribuiti in vari siti con job sottomessi da una user interface (laptop) e che girano in remoto. Nel recuperare i file di output ed eventualmente processarli per estrarre le variabili fisiche di interesse L’architettura attuale si basa sulle seguenti assunzioni: I dati risiedono in siti remoti e al CERN Cataloghi locali dei dati sono disponibili nei siti Il software di CMS è disponibile sui siti remoti Il gruppo di Bari sta contribuendo allo sviluppo degli strumenti di analisi di utente finale in GRID

Attività del gruppo di Bari Il gruppo di Bari per l’analisi di utente finale sta contribuendo a: sviluppo di strumenti di catalogazione dati sviluppo di strumenti di validazione dati sviluppo di strumenti di monitoraggio di job per applicazioni generiche su grid in tempo reale sviluppo di stumenti di output management

Gli strumenti di data management I dati sono spostati dal Tier 0 ai Tier 1 e ai Tier 2 sites via PhEDEx ~100 MBytes/sec CERN Computer Centre Tier 0 PhEDEx France Regional Centre Germany Regional Centre Italy Regional Centre (CNAF) FermiLab Tier 1 PhEDEx ValidationTools Bari Bologna LNL Padova Tier 2 PubDB La validazione dei dati è eseguita alla fine del trasferimento via ValidationTools (BARI) Local catalogues I dati sono pubblicati in un database locale, PubDB

Il flusso dei job di analisi di CMS L’utente fornisce: il nome del Dataset (runs,#event,..) codice di analisi UI DataSet Catalogue (PubDB/RefDB) CRAB Job submission tool CRAB ricerca ove risiedono i dati interrogando i database RefDB/ PubDB CRAB prepara, splitta e sottomette i job al Resource Broker Workload Management System Resource Broker (RB) Il RB manda i job ai siti ove risiedono i dati purchè il software di CMS è installato XCMSI Computing Element CRAB recupera automaticamente i file di output dei job Worker node Storage Element

Conclusioni Le applicazioni di HEP sono funzionanti in ambiente distribuito; il gruppo di Bari sta contribuendo alla attività di sviluppo e dei test dei componenti di GRID e di quelli condivisi da CMS Tutti gli esperimenti LHC stanno usando le implementazioni di molti progetti grid per i Data Challenge L’esempio di CMS: Produzione massiva di eventi simulati (LCG) L’intera catena di analisi è stata sperimentata con successo in LCG L’analisi distribuita di utente finale di CMS è funzionante ed è usata dagli utenti reali: 50 utenti, 10 milioni di eventi analizzati, 10000 job sottomessi Scalabilità e prestazioni sono gli elementi chiave del sistema