ALICE Computing F.Carminati/CERN Commissione Scientifica Nazionale I Perugia, 11-12 novembre 2002 Commissione Nazionale I 1 sistema online il trigger multi-livello filtra il fondo e riduce il volume dei dati /sec) B G 0 (16 z zato z H i l k a i 8 c spe e r a w hard – sec) 0 / o B l l G e (4 liv z dded e H b m 0 e 20 ssori e c o r –p ec) 1 s / o B l l G e liv (2.5 z H 30 PCs 2 La collaborazione ALICE livello include 1223 collaboratori da 85 istituti in 27 nazioni 11-12 novembre 2002 Peso totale Diametro esterno Lunghezza totale Campo magnetico 10.000t 16,00m 25m 0.4Tesla 30 Hz/sec) GB (1.25 ti & a d e n razio fline t s i g e r i of analis Commissione Nazionale I, Perugia 2 Decisione strategica nel 1998 Framework ROOT GEANT3, PAW FORTRAN Hits Zebra/RZ/FZ cinematica in C++ Geant3 ALICE geometria in C++ Hits Digits ROOT Trees 11-12 novembre 2002 Commissione Nazionale I, Perugia 3 Schema di sviluppo di AliRoot Infrastruttura offline di ALICE strutture hits di ROOT macro in C++ File di output di ROOT 11-12 novembre 2002 strutture digits di ROOT macro in C++ tracce di ROOT risultati fisici macro in C++ Visualizazione di dati con ROOT Commissione Nazionale I, Perugia 4 L’infrastruttura L’infrastruttura di AliRoot C++: 450kLOC + 225kLOC (generate) + macros: 77kLOC FORTRAN: 13kLOC (ALICE) + 914kLOC (programmi esterni) Mantenuto su Linux (g++ e icc), HP-UX, DEC Unix, Solaris Usato per tutti i TDR’s Due pacchetti da installare (ROOT+AliRoot) Meno di 1 secondo per linkare (grazie a 37 librerie shared) Installazione “1-click-away”: scarica e make AliEn Perl5: 25kLOC (ALICE), ~1.5MLOC (componenti open source) Installata in più di 30 siti da fisici (!!) Più di 50 fisici dei differenti sotto-detettori partecipano allo sviluppo di AliRoot Il 70% del codice è sviluppato all’esterno, il 30% dal gruppo di Offline del CERN 11-12 novembre 2002 Commissione Nazionale I, Perugia 5 Struttura di AliRoot G4 G3 FLUKA HIJING AliRoot Virtual MC HBTAN AliEn ISAJET EVGEN STEER MEVSIM PYTHIA6 PDF PMD STRUCT EMCAL CRT TRD ITS START PHOS FMD TOF MUON ZDC TPC RICH HBTP RALICE ROOT 11-12 novembre 2002 Commissione Nazionale I, Perugia 6 1/100 di un evento ALICE La complessità del detettore ALICE è simile ad ATLAS o CMS GEANT3 Sviluppato in 1981 Tuttora usato dalla maggioranza degli esperimenti GEANT4 Un investimento enorme Adozione molto lenta da parte della FAE FLUKA 11-12 novembre 2002 Commissione Nazionale I, Perugia Fisica state-of-the-art, adronica, elettromagnetica e neutronica Difficile da usare per simulazioni di tutto il detettore 7 Il Virtual MC Geant4_vmc.tar.gz include le classi di interfaccia TVirtualMC <--> Geant4 Codice utente VMC Geant3.tar.gz include una versione migliorata di Geant3 con una intefaccia C++ G3 Trasporto G3 G4 Trasporto G4 FLUKA Trasporto FLUKA Ricostruzione Modellatore geometrico Visualizzazione Generatori 11-12 novembre 2002 Commissione Nazionale I, Perugia 8 Stato di TFluka/VMC Interfaccia ai generatori (OK) Tutti i generatori di AliRoot sono accessibili Hijing(Param), Herwig, GEVSIM, ISAJET, PYTHIA… Geometria (OK via FLUGG, sotto test) Tracking tramite FLUGG e l’interfaccia virtuale I.Gonzàlez E.Futo Stepping action (aka GUSTEP, in sviluppo) Stacking (discussione in corso) 11-12 novembre 2002 Commissione Nazionale I, Perugia 9 3 milioni di volumi ALICE 11-12 novembre 2002 Commissione Nazionale I, Perugia 10 Test Geant4.4.1 50cm 50cm concrete(n,Xn)@68MeV concrete(n,Xn)@68MeV Pa ram etr izz azi on e 11-12 novembre 2002 Commissione Nazionale I, Perugia 11 Sviluppo della ricostruzione Efficienza di tracking per TPC+ITS a dN/dy 8000 La definizione standard delle tracce buone verso le false richiede che tutti i 6 hits dell’ITS siano corretti La maggior parte delle tracce false hanno solo un punto sbagliato Quando la condizione è rilassata a 5 hits buoni su 6 l’efficienze migliora del 7 - 10 % (e la probabilità di tracce sbagliate è corrispondentemente più bassa) 11-12 novembre 2002 Commissione Nazionale I, Perugia 12 Perchè il calcolo distribuito? I bisogni del calcolo LHC sono enormi, per esempio per ALICE 1.25 GB/s durante i runs di ioni pesanti ~3 PB/anno di nastri, ~1.5 PB di dischi ~1800 kSI95 (~70,000 PC2000) ~ 8MEuro di solo hardware Milioni di linee di codice da sviluppare e mantenere per >20 anni Tecnicamente, politicamente e sociologicamente non si può concentrare al CERN Le “funding agencies” preferiscono investimenti nazionali che al CERN La competenza è naturalmente distribuita Una struttura centralizzata costringerebbe la gente a viaggiare fisicamente Ma il modello distribuito è tecnicamente più difficile da realizzare e in principio globalmente più costoso La sfida è quindi massimizzare l’efficienza minimizzando i costi 11-12 novembre 2002 Commissione Nazionale I, Perugia 13 Il modello di calcolo distribuito Idea di base Ogni fisico deve avere in principio uguale accesso ai dati e alle risorse di calcolo Il sistema finale sarà molto complesso a causa del numero dei siti e dei componenti in ogni sito delle diverse operazioni da effettuare in parallelo: simulazione, ricostruzione, analisi coordinata e caotica La cattiva notizia è che gli strumenti di base mancano Gestione di risorse distribuite Spazio virtuale distribuito dei nomi dei files e degli oggetti Autenticazione e autorizzazione distribuita Gestione di grandi cluster locali Replicazione e caching dei dati Monitoraggio e diagnostica delle reti WAN/LAN La buona notizia è che non siamo soli Tutti i problemi sopra sono al centro degli sviluppi che in Europa e US vanno sotto il nome collettivo di GRID 11-12 novembre 2002 Commissione Nazionale I, Perugia 14 Il problema da risolvere Offrire un uso naturale di risorse distribuite … Una persona (production manager, utente) sottomette i jobs a una coda I files (output e data) finiscono su un file system dove possono essere manipolati Lo stato delle code e delle risorse è monitorato … nascondendo (per quanto possibile) il fatto che siano distribuite … Ovviamente all’utente, il sistema risultante sarà più complesso … e ottimizzando il loro uso … Rispetto al sistema equivalente non distribuito … con un software a livello di produzione … Cioè basato il più possibile su standard e software esistente e solido Magari con uno scopo limitato alla FAE 11-12 novembre 2002 Commissione Nazionale I, Perugia 15 AliEn: una GRID leggera AliEn (http://alien.cern.ch) è unaresource alternativa leggera a una soluzione di The “Grid problem” is about sharing & coordinated griglia completa, ed è basato su componenti standard (SOAP, Web services, componenti e architettura OGSA) che comprende problemCatalogo solving virtual dei in filesdynamic, visto come unmulti-institutional file system globale via tavole RDB Catalogo dei TAG come estensione Autenticatione sicura organizations Gestore di coda centrale (modello "pull" invece che "push") Infrastruttura di monitoring P.Messina Installazione automatica del software via AliKit La funzionalità di base della GRID !! AliEn è usato da ALICE per tutte le produzioni, in particolare per il PPR AliEn è la componente GRID per MammoGRID, un progetto di mammografia di 3 anni e 2M€ sponsorizzato dalla UE e partito in settembre 11-12 novembre 2002 Commissione Nazionale I, Perugia 16 AliEn (P.Buncic, P.Saiz, J-E.Revschbak) Accesso ai dati Architettura Catalogo files Bookkeeping Autenticazione DISK Perl5 Tier1 alien DISK SOAP Server ALICE ALICE allien LOCAL allien(shell,Web) D0 (shell,Web)Client path char(255) Client allien | | | | | | | |--b/ | | API | | |--barbera/ |--./ USERS --./ | |--cern.ch/ dir integer(11) | |--r3418_01-01.ds (shell,Web) hostIndex integer(11) <fk> User Application | | |--user/ Client | |--r3418_02-02.ds entryId | | | |--a/ | |--36/integer(11) <pk> (C/C++/Java/Perl) SOAP Client | |--r3418_03-03.ds | | | | |--admin/ | | |--stderr ALICE Authorisation | |--r3418_04-04.ds | | | | | | Service | |--stdin SIM T2526 Authorisation DBI | | | | |--aliprod/ | | |--stdout DBI | |--r3418_05-05.ds type char(4) Service Proxy server dir| | Proxy server | | | | Servizi integer(8) T2527 | |--r3418_06-06.ds DB DB name char(64) (trasporto files, | | | |--f/ | |--37/ type char(4) Servizio di Driver Driver | |--r3418_07-07.ds char(8) DBIowner dir|--stderr integer(8) | | | | |--fca/ sincronizzazione | | char(16) ctime autenticazione sicuro | |--r3418_08-08.ds name char(64) Proxy server |--simulation/ | | | | comment char(80) | | owner |--stdin ecc) char(8) DB indipendente dalla | |--r3418_09-09.ds content char(255) | |--2001-01/ | | | |--p/ | | ctime |--stdout char(16) Driver method char(20) base di dati | | |--V3.05/ char(80) | | | | |--psaiz/File transport| |--r3418_10-10.ds | ADMIN | comment methodArg char(255) content char(255) | | | |--Config.C sottostante | | | | | |--as/ Service | |--r3418_11-11.ds | |--38/ gowner char(8) ADMIN method char(20) size integer(11) | | | |--grun.C | | | | | | | | methodArg |--stderr char(255) | |--r3418_12-12.ds File Catalogue File Catalogue PROCESSES gowner | | | | | |--dos/ | | |--stdin char(8) | |--r3418_13-13.ds size integer(11) File transport | | | | | | | | |--stdout File Catalogue |Service |--r3418_14-14.ds File Catalogue | | | | | |--local/ SOAP | |--r3418_15-15.ds File(specifiche Catalogue dei job) input e Catalogo dei files: fileFiles, comandi system globale su output dei jobs, tags e anche DB Synci tar file File Catalogue nel catalogo base dati relazionale binari sono immagazzinatiService 11-12 novembre 2002 Commissione Nazionale I, Perugia Coda di task centrale 17 Physics Data Challenges con AliEn AliEn Stato Produzione @GRID Produzioni ALICE 100% 90% Total jobs 0% per site 80% CERN 70% Torino 60% LBL Lyon 50% Catania 40% OSC 30% 20% FZK Padova 10% CNAF 0% 500 GSI Utrecht 450 Zagreb 400 Budapest350 Prague 300 0% 0% 0% 0% 2% 4% 1% 6% 42% 5% 17% 15% 15100 jobs, ~12CPUh/job ~1GB output/job fino a 450 jobs simultanei #of jobs CPU 8% 2001-02 2002-03 2002-04 Numero dei jobs simultanei Series1 250 200 150 100 50 0 2001-02 11-12 novembre 2002 2002-02 2002-02 2002-03 Production round Commissione Nazionale I, Perugia 2002-04 18 La GRID di ALICE http://www.to.infn.it/activities/experiments/alice-grid OSU/OSC LBL/NERSC Birmingham Nantes Saclay GSI CERN Merida Lyon 37 persone 21 instituzioni In Italia: Tier1: CNAF Tier2 di riferimento: Torino Dubna NIKHEF Torino Padova Bologna IRB Bari Cagliari Yerevan Catania Kolkata, India Capetown, ZA 11-12 novembre 2002 Commissione Nazionale I, Perugia 19 AliEn & PROOF TagDB Parametri di selezione CPU Procedura PROOF RDB Proc.C Proc.C Portare il kiloByte al PetaByte e non il PetaByte al kiloByte 11-12 novembre 2002 DB1 Locale CPU Remoto DB2 Proc.C DB3 CPU Proc.C DB4 CPU Proc.C DB5 CPU DB6 CPU Commissione Nazionale I, Perugia 20 ALICE & testbed EDG Intensa attività di test Valutazione del testbed Script per sottomettere periodicamente job di AliRoot su tutti i EDG/CE via il EDG/RB Site web per monitorare lo stato e la statistica Interoperabilità AliEn/EDG Portaggio EDG UI su RH7.2 and Solaris Portaggio EDG/CE e EDG/SE su RH7.2 Test preliminari dell’EDG/RC per un uso eventuale in parallelo con AliEn L’esperienza di ALICE con EDG (e AliEn) ha costituito l’essenza dell’input di ALICE a HEPCAL 11-12 novembre 2002 Commissione Nazionale I, Perugia 21 11-12 novembre 2002 Commissione Nazionale I, Perugia 22 GENIUS (aka R.Barbera) 11-12 novembre 2002 Commissione Nazionale I, Perugia 23 Integrazione AliEn-EDG EDG RB RB EDG Server Server Comune: In comune: JDL JDL Autenticazione Autenticazione Requires: Richiede: al RC di EDG AliEn AliEn gateway SE on EDG nodes WN al Accesso Accesso dall’EDG all’AliEn Data Data Catalogue di AliEn Catalogue dal WN EDG Data Data Catalogue Catalogue 11-12 novembre 2002 EDG CE CE EDG AliEn/EDG AliEn CE CE EDG UI UI EDG AliEn/EDG SE EDG RC Commissione Nazionale I, Perugia WNs WNs AliEn SE Local mass storage or EDG SE EDG SE 24 ALICE (computing) Data Challenges AliRoot Dati raw Verificare la scalabilità del sistema acquisizione dati Dati simulati DAQ ROOT I/O GEANT3 GEANT4 FLUKA Verificare l’integrazione online – offline – HLT Seguire l’evoluzione della tecnologia TIER 1 TIER 2 Regionali ROOT CASTOR GRID CERN TIER 0 TIER 1 11-12 novembre 2002 Commissione Nazionale I, Perugia 25 Configurazione hardware della ADC IV 3 switches Gigabit 4 switches Gigabit TBED00 01-12 13-24 3 25-36 3 3 37-48 LXSHARE 3 01D-12D 13D-24D 2 2 TBED0007D TOTAL: 32 ports 25D-36D 2 TOTAL: 18 ports 6 CPU servers on FE 2 3 49-60 3 61-72 3 7376 3 Fibers 77-88 89-112 Backbone (4 Gbps) 10 TAPE servers Totale: 192 CPU servers (96 su Gbe, 96 su Fe), 36 DISK servers, 10 TAPE servers (distribuiti) 4 switches Gigabit 11-12 novembre 2002 2 switches Fastethernet Commissione Nazionale I, Perugia 26 Prestazioni Generazione dei dati negli LDC, event building, niente scrittura 5 giorni non-stop • 1800 MBytes/s continui (milestone: 1000 Mbytes/s) Generazione dei dati negli LDC, event building, scrittura su disco 4.5 giorni non-stop ✑ volume totale : ~ 140 Tbytes ✑ 350 MBytes/s continui (milestone 300 MBytes/s) 11-12 novembre 2002 Commissione Nazionale I, Perugia 27 Piani per le PDC di ALICE Verificare il modello e l’infrastruttura di calcolo Ridurre il “rischio tecnologico” Comprendere le potenzialità fisiche del detettore Mettere a punti codici di simulazione, ricostruzione e analisi Periodo (milestone) Frazione della capacità finale (%) 06/01-12/01 1% 06/02-12/02 5% 01/04-06/04 10% 01/06-06/06 20% 11-12 novembre 2002 Obiettivi fisici Studi pp, ricostruzione TPC e ITS Primi test della catena completa dalla simulazione alla ricostruzione per il PPR. Semplici tools di analisi. Digits in formato ROOT. Catena completa usata per studi di trigger. Prototipo dei tools di analisi. Confronto con il MonteCarlo parametrizzato. Raw data simulati. Test del sistema finale per ricostruzione e analisi. Commissione Nazionale I, Perugia 28 Modello di calcolo e distribuzione risorse ALICE sta definendo il modello di calcolo Il Tier0 registra i dati Niente elaborazione I Tier1 si dividono la ricostruzione Probabilmente in modo asimmetrico, nel senso che il Tier1 del CERN dovrebbe averne fino al 30% Però uno sharing diverso è possibile E questo sarà verificato nelle data challenges I Tier2 si dividono la simulazione e l’analisi Tranne quella parallela, dove probabilmente i vari centri parteciperanno più simmetricamente Punto da verificare 11-12 novembre 2002 Commissione Nazionale I, Perugia 29 Sharing risorse LCG / esperimento La questione dello sharing tra LCG e risorse specifiche di esperimento è da definire Se LCG fosse stabile, sarebbe sensato includervi tutte le risorse Però questo impedirebbe la necessaria attività R&D E gli esperimenti hanno bisogno di risorse garantite per le Physics Data Challenges L’integrazione può essere solo progressiva All’inizio sarà necessaria una certa “ridondanza” nella dotazione totale (esperimento + LCG) Per poi “integrare” le dotazioni di esperimento man mano che l’efficienza di LCG aumenta Un vigoroso e coerente lavoro comune di test è la condizione perché questo succeda rapidamente e in modo efficace 11-12 novembre 2002 Commissione Nazionale I, Perugia 30 Necessità di calcolo per la PDC III Year,Quarter CPU Total Requirement for Simulation Total Requirement for reconstruction Total Requirement for analysis Total CPU Requirement STORAGE Total Requirement for Simulation Total Requirement for reconstruction Total Requirement for analysis Total Storage requirements LOAD BALANCE CPU CERN TIER-1s OUT CERN Tier-2s Total CPU Requirement (check) LOAD BALANCE STORAGE CERN TIER-1s OUT CERN Tier-2s Total Storage requirements (check) 11-12 novembre 2002 04Q1 ksi95 month 65 124 249 438 04Q2 ksi95 month TB 21 63 84 TB 21 187 13 220 ksi95 month 131 175 131 438 ksi95 month 140 187 140 467 TB 25 34 25 84 TB 66 88 66 220 156 311 467 Flessibilità del modello di calcolo distribuito Scenari alternativi Year,Quarter LOAD BALANCE CPU CERN TIER-1s OUT CERN Tier-2s Total CPU Requirement (check) LOAD BALANCE STORAGE CERN TIER-1s OUT CERN Tier-2s Total Storage requirements (check) Commissione Nazionale I, Perugia 04Q1 ksi95 month 66 241 131 438 04Q2 ksi95 month 70 257 140 467 TB 13 46 25 84 TB 33 121 66 220 31 Costo calcolo ALICE 2001-2005 Progetto di massima per un centro regionale di calcolo per l'INFN costi valutati nel piano triennale ALICE (02-04): 1652 kEU Costi CPU (kEU/kSI95) Costi dischi (kEU/TB) Costi tapes in kEU (unità da 18 GB/h) CPU (kSI95) (2001 assegnati) Dischi (TB) (2001 assegnati) Tape capacity (TB) (2001 assegnati) Costi CPU kEU (2001 assegnati) Costi dischi kEU (2001 assegnati) Costi tapes kEU (2001 assegnati) Totale kEU Totale kEU (integrati) 2001 2002 2003 2004 2005 53 34 21 13 8 29 14 7 4 2 TOT 15 15 15 63 2 6 12 20 23 11 12 19 28 35 105 4 58 78 70 210 95 195 249 266 189 994 300 172 136 100 63 772 30 0 60 60 120 270 425 367 446 427 371 2036 425 792 1237 1664 2036 Capacità prevista nel 2005 = 15% di quella finale 11-12 novembre 2002 Commissione Nazionale I, Perugia 32 Il processo di sviluppo del software ALICE ha un piccolo gruppo offline al CERN… Concentrato su infrastruttura, distribuzione del software e manutenzione …più 10-15 persone distribuite Coordinazione GRID (Cerello, Torino), World Computing Model (Nantes), Base di dati dei detettori (Varsavia) Un ciclo di sviluppo adattato ad ALICE è stato sviluppato Gli sviluppatori lavorano sui soggetti più importanti in ciascun momento Una versione stabile di produzione esiste sempre Il codice è posseduto collettivamente Il ciclo di release è flessibile e l’installazione molto semplice Micro-cicli di sviluppo hanno luogo continuamente Macro-cicli avvengono due-tre volte l’anno Discussi e implementati durante settimane offline e “code review” In corrispondenza di release maggiori 11-12 novembre 2002 Commissione Nazionale I, Perugia 33 Manutenzione di AliRoot Pianificazione uniforme delle release Una release maggiore ogni sei mesi Una release minore (tag) ogni mese Manutenzione e supporto continui Ci sono molto pochi bug nella release di produzione perché la versione di sviluppo è sempre disponibile Enfasi sulla qualità del codice di produzione Correzioni, protezioni, pulizia del codice, controllo della geometria Ogni notte sono prodotti diagrammi UML, listing del codice, violazioni delle coding rules, build e tests Un singolo repository con il codice di produzione e di sviluppo 11-12 novembre 2002 Commissione Nazionale I, Perugia 34 ALICE Offline Computing Structure Software Projects Management Board EC DataGRID WP8 Coordination Detector Projects International Computing Board A.Masoni Regional Tiers Offline Board Chair F.Carminati DAQ P.Vande Vyvre Production Environment & Coordination ROOT FrameWk Data Challenges HLT algorithms P.Buncic • Simulation production • Reconstruction production • Production farms • Database organisation • Relations with IT & other comp. centres Framework & Infrastructure F.Rademakers • • • • • • • • Framework development Database technology HLT Farm Distributed computing (GRID) Data Challenge Industrial joint Projects Tech. Tracking Documentation 11-12 novembre 2002 Simulation A.Morsch • • • • • • • Detector Simulation Physics simulation Physics validation GEANT 4 integration FLUKA integration Radiation Studies Geometrical modeller Commissione Nazionale I, Perugia Reconstruction & Physics K.Safarik • • • • • • • Tracking Detector reconstruction HLT algorithms Global reconstruction Analysis tools Analysis algorithms Calibration & alignment algorithms 35 ROOT, ALICE & LCG LCG ha come obiettivo la costruzione dell’infrastruttura di calcolo per LHC ALICE ha esercitato forti pressioni perché LCG fosse basato su ROOT e AliEn Gli altri esperimenti hanno scelto un relazione cliente-fornitore con ROOT e ignorato AliEn Svilupperanno alternative per alcuni elementi esistenti di ROOT o li nasconderanno dietro interfacce astratte e useranno i risultati dei progetti GRID ALICE ha espresso le sue preoccupazioni Manca il tempo per sviluppare e “dispiegare” un nuovo sistema Duplicazione e dispersione di attività Divergenza con il resto della comunità della FAE ALICE continuerà a sviluppare la sua infrastruttura E a fornire tecnologie di base come il VMC o il modellatore geometrico … e cercherà di collaborare con LCG il piú possibile 11-12 novembre 2002 Commissione Nazionale I, Perugia 36 Conclusione ALICE ha soluzioni che stanno evolvendo in una solida infrastruttura per il calcolo Le maggiori decisioni sono state prese e gli utenti le hanno di fatto adottate La collaborazione tra fisici ed “informatici” è eccellente La stretta integrazione con ROOT permette una grande rapidità di prototipaggio e di sviluppo AliEn fornisce una soluzione GRID completa adattata ai bisogni della FAE che ci ha permesso di effettuare enormi produzioni con solo due persone “ai comandi” Molte delle soluzioni sviluppate da ALICE hanno un alto potenziale di diventare soluzioni comuni ad altri esperimenti (magari anche esperimenti LHC) 11-12 novembre 2002 Commissione Nazionale I, Perugia 37