ALICE Computing

1. ALICE Computing F.Carminati/CERN Commissione Scientifica Nazionale I Perugia, 11-12 novembre 2002 Commissione Nazionale I

2. sistema online il trigger multi-livellofiltra il fondo eriduce il volume dei dati Peso totale 10.000t Diametro esterno 16,00m Lunghezza totale 25m Campo magnetico 0.4Tesla 8 kHz (160 GB/sec) livello 0 – hardware specializzato 200 Hz (4 GB/sec) livello 1 – processori embedded 30 Hz (2.5 GB/sec) livello 2 - PCs La collaborazione ALICE include 1223 collaboratori da 85 istituti in 27 nazioni 30 Hz (1.25 GB/sec) registrazione dati & analisi offline Commissione Nazionale I, Perugia

3. Framework ROOT cinematica in C++ Geant3 ALICE geometria in C++ Hits Digits ROOT Trees Decisione strategica nel 1998 GEANT3, PAW FORTRAN Hits Zebra/RZ/FZ Commissione Nazionale I, Perugia

4. risultati fisici macro in C++ macro in C++ macro in C++ tracce di ROOT strutture digits di ROOT strutture hits di ROOT Visualizazione di dati con ROOT Schema di sviluppo di AliRoot Infrastruttura offline di ALICE File di output di ROOT Commissione Nazionale I, Perugia

5. 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 Commissione Nazionale I, Perugia

6. Struttura di AliRoot G4 G3 FLUKA ISAJET HIJING AliRoot AliEn Virtual MC EVGEN MEVSIM HBTAN STEER PYTHIA6 PDF PMD EMCAL TRD ITS PHOS TOF ZDC RICH HBTP STRUCT CRT START FMD MUON TPC RALICE ROOT Commissione Nazionale I, Perugia

7. La complessità del detettoreALICE è simile ad ATLAS o CMS 1/100 di un evento ALICE • GEANT3 • Sviluppato in 1981 • Tuttora usato dalla maggioranza degli esperimenti • GEANT4 • Un investimento enorme • Adozione molto lenta da parte della FAE • FLUKA • Fisica state-of-the-art, adronica, elettromagnetica e neutronica • Difficile da usare per simulazioni di tutto il detettore Commissione Nazionale I, Perugia

8. Geant3.tar.gz include una versione migliorata di Geant3 con una intefaccia C++ Geant4_vmc.tar.gz include le classi di interfaccia TVirtualMC <--> Geant4 G3 Trasporto G3 Codice utente VMC G4 Trasporto G4 Trasporto FLUKA FLUKA Ricostruzione Modellatore geometrico Visualizzazione Generatori Il Virtual MC Commissione Nazionale I, Perugia

9. 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 • Stepping action (aka GUSTEP, in sviluppo) • Stacking (discussione in corso) I.Gonzàlez E.Futo Commissione Nazionale I, Perugia

10. 3 milioni di volumi ALICE Commissione Nazionale I, Perugia

11. Parametrizzazione Test Geant4.4.1 50cm concrete(n,Xn)@68MeV Commissione Nazionale I, Perugia

12. 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) Commissione Nazionale I, Perugia

13. 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 Commissione Nazionale I, Perugia

14. 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 Commissione Nazionale I, Perugia

15. 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 Commissione Nazionale I, Perugia

16. AliEn: una GRID leggera The “Grid problem” is about resource sharing & coordinated problem solving in dynamic, multi-institutional virtual organizations P.Messina • AliEn (http://alien.cern.ch) è una alternativa leggera a una soluzione di griglia completa, ed è basato su componenti standard (SOAP, Web services, componenti e architettura OGSA) che comprende • Catalogo dei files visto come un file system globale via tavole RDB • Catalogo dei TAG come estensione • Autenticatione sicura • Gestore di coda centrale (modello "pull" invece che "push") • Infrastruttura di monitoring • 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 Commissione Nazionale I, Perugia

17. Architettura Bookkeeping Accesso ai dati Catalogo files --./ | |--r3418_01-01.ds | |--r3418_02-02.ds | |--r3418_03-03.ds | |--r3418_04-04.ds | |--r3418_05-05.ds | |--r3418_06-06.ds | |--r3418_07-07.ds | |--r3418_08-08.ds | |--r3418_09-09.ds | |--r3418_10-10.ds | |--r3418_11-11.ds | |--r3418_12-12.ds | |--r3418_13-13.ds | |--r3418_14-14.ds | |--r3418_15-15.ds Tier1 Autenticazione Perl5 |--./ | |--cern.ch/ | | |--user/ | | | |--a/ | | | | |--admin/ | | | | | | | | | |--aliprod/ | | | | | | | |--f/ | | | | |--fca/ | | | | | | | |--p/ | | | | |--psaiz/ | | | | | |--as/ | | | | | | | | | | | |--dos/ | | | | | | | | | | | |--local/ | | | | | | | |--b/ | | | | |--barbera/ API ALICE LOCAL | |--36/ | | |--stderr | | |--stdin | | |--stdout | | | |--37/ | | |--stderr | | |--stdin | | |--stdout | | | |--38/ | | |--stderr | | |--stdin | | |--stdout Servizi (trasporto files, sincronizzazione ecc) ALICE ALICE USERS SIM Servizio di autenticazione sicuro indipendente dalla base di dati sottostante D0 SOAP path char(255) |--simulation/ | |--2001-01/ | | |--V3.05/ | | | |--Config.C | | | |--grun.C T2526 dir integer(11) hostIndex integer(11) <fk> type char(4) entryId integer(11) <pk> dir integer(8) T2527 name char(64) type char(4) owner char(8) dir integer(8) ctime char(16) name char(64) comment char(80) owner char(8) content char(255) ctime char(16) method char(20) comment char(80) methodArg char(255) content char(255) gowner char(8) Catalogo dei files: file system globale su base dati relazionale method char(20) size integer(11) • Files, comandi (specifiche dei job) input e output dei jobs, tags e anche i tar file binari sono immagazzinati nel catalogo methodArg char(255) gowner char(8) Coda di task centrale size integer(11) AliEn(P.Buncic, P.Saiz, J-E.Revschbak) Commissione Nazionale I, Perugia

18. AliEn Stato Produzione Produzioni ALICE @GRID 100% 90% Total jobs per site 0% 80% CERN 0% 0% 0% 4% 0% Torino 70% 2% LBL 60% 8% Lyon CPU 50% 1% Catania 40% OSC 6% 30% 42% FZK 20% Padova 5% 10% CNAF 0% 2001-02 2002-02 2002-03 2002-04 GSI 500 Utrecht Numero dei jobs simultanei 450 Zagreb 17% 400 Budapest 350 Prague 300 15% #of jobs Series1 250 15100 jobs, ~12CPUh/job ~1GB output/job fino a 450 jobs simultanei 200 150 100 50 0 2001-02 2002-02 2002-03 2002-04 Production round Physics Data Challenges con AliEn Commissione Nazionale I, Perugia

19. OSU/OSC LBL/NERSC Dubna Birmingham NIKHEF Saclay GSI Nantes CERN Padova Merida IRB Bologna Lyon Torino Bari Cagliari Yerevan Catania Kolkata, India Capetown, ZA La GRID di ALICE http://www.to.infn.it/activities/experiments/alice-grid 37 persone21 instituzioniIn Italia:Tier1: CNAFTier2 di riferimento: Torino Commissione Nazionale I, Perugia

20. Parametri di selezione TagDB CPU Procedura PROOF DB1 RDB CPU Proc.C DB2 Proc.C DB3 CPU Proc.C DB4 CPU Proc.C DB5 CPU Proc.C DB6 CPU AliEn & PROOF Locale Remoto Portare il kiloByte al PetaByte e non il PetaByte al kiloByte Commissione Nazionale I, Perugia

21. 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 Commissione Nazionale I, Perugia

22. Commissione Nazionale I, Perugia

23. GENIUS (aka R.Barbera) Commissione Nazionale I, Perugia

24. EDG RB EDG RB Server Server EDG CE EDG CE • In comune: • JDL • Autenticazione • Comune: • JDL • Autenticazione AliEn CE AliEn/EDG CE WNs Local mass storage or EDG SE WNs • Richiede: • AliEn SE on EDG nodes • Accesso all’AliEn Data Catalogue dal WN EDG • Requires: • AliEn gateway al RC di EDG • Accesso dall’EDG WN al Data Catalogue di AliEn EDG UI EDG UI AliEn SE AliEn/EDG SE EDG RC EDG SE Data Catalogue Data Catalogue Integrazione AliEn-EDG Commissione Nazionale I, Perugia

25. Verificare la scalabilità del sistema acquisizione dati Verificare l’integrazione online – offline – HLT Seguire l’evoluzione della tecnologia AliRoot GEANT3GEANT4FLUKA ALICE (computing) Data Challenges Datiraw Dati simulati DAQ ROOT I/O TIER 1 TIER 2 Regionali CERN TIER 0 TIER 1 ROOT CASTOR GRID Commissione Nazionale I, Perugia

26. Configurazione hardware della ADC IV 3 switches Gigabit 4 switches Gigabit TBED00 01-12 13-24 25-36 37-48 LXSHARE 01D-12D 13D-24D 25D-36D 3 3 3 3 2 2 2 TBED0007D TOTAL: 18 ports TOTAL: 32 ports 6 CPU servers on FE 2 Fibers 3 3 3 3 49-60 61-72 73-76 77-88 89-112 Backbone (4 Gbps) 4 switches Gigabit 2 switches Fastethernet 10 TAPE servers (distribuiti) Totale: 192 CPU servers (96 su Gbe, 96 su Fe), 36 DISK servers, 10 TAPE servers Commissione Nazionale I, Perugia

27. 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) Commissione Nazionale I, Perugia

28. Periodo (milestone) Frazione della capacità finale (%) Obiettivi fisici 06/01-12/01 1% Studi pp, ricostruzione TPC e ITS 06/02-12/02 5% Primi test della catena completa dalla simulazione alla ricostruzione per il PPR. Semplici tools di analisi. Digits in formato ROOT. 01/04-06/04 10% Catena completa usata per studi di trigger. Prototipo dei tools di analisi. Confronto con il MonteCarlo parametrizzato. Raw data simulati. 01/06-06/06 20% Test del sistema finale per ricostruzione e analisi. 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 Commissione Nazionale I, Perugia

29. Modello di calcoloe 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 Commissione Nazionale I, Perugia

30. 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 Commissione Nazionale I, Perugia

31. Necessità di calcolo per la PDC III Flessibilità del modello di calcolo distribuito Scenari alternativi Commissione Nazionale I, Perugia

32. 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 Commissione Nazionale I, Perugia

33. 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 Commissione Nazionale I, Perugia

34. 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 Commissione Nazionale I, Perugia

35. Detector Projects Software Projects Production Environment & Coordination P.Buncic • Simulationproduction • Reconstructionproduction • Production farms • Databaseorganisation • Relations with IT & other comp. centres Reconstruction & Physics K.Safarik • Tracking • Detector reconstruction • HLT algorithms • Global reconstruction • Analysis tools • Analysis algorithms • Calibration & alignment algorithms ALICE Offline Computing Structure Management Board EC DataGRID WP8 Coordination International Computing Board A.Masoni Offline Board Chair F.Carminati Regional Tiers DAQ P.Vande Vyvre ROOT FrameWk Data Challenges HLT algorithms Framework & Infrastructure F.Rademakers • Framework development • Database technology • HLT Farm • Distributed computing (GRID) • Data Challenge • Industrial joint Projects • Tech. Tracking • Documentation Simulation A.Morsch • Detector Simulation • Physics simulation • Physics validation • GEANT 4 integration • FLUKA integration • Radiation Studies • Geometrical modeller Commissione Nazionale I, Perugia

36. 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 Commissione Nazionale I, Perugia

37. 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) Commissione Nazionale I, Perugia