P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica & INFN, Bologna I termini del problema Attivita (e persone.

Presentazione sul tema: "P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica & INFN, Bologna I termini del problema Attivita (e persone."— Transcript della presentazione:

1 P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica & INFN, Bologna I termini del problema Attivita (e persone coinvolte) Supporto necessario Il Computing off-line di CMS al CERN Il Modello di Computing: MONARC e CMS Risorse R&D e Conclusioni

2 P.Capiluppi 2 Padova Luglio 1999 LHC Experiments ATLAS, CMS, ALICE, LHCb Higgs and New particles; Quark-Gluon Plasma; CP Violation

3 P.Capiluppi 3 Padova Luglio 1999 I termini del problema CMS Italia: Ba, Bo, Ct, Fi, Pd, Pv, Pg, Pi, Rm1, To. La complessita non ha precedenti: –1 PByte/anno di dati –Risorse di calcolo: disk storage di centinaia di TByte e CPU power di centinaia di KSpecInt95 –Migliaia di anni uomo per lo sviluppo del Software (dalla complessita del Rivelatore e della Analisi) –Decine di anni di vita del Progetto –Migliaia di partecipanti distribuiti in centinaia di Istituzioni in tutto il Mondo –Distribuzione delle risorse da coordinare e necessita della Collaborazione a distanza Il software, tutto, sara ad Oggetti (Object Oriented), codificato in C++ (per ora?) Quindi DataBase ad Oggetti per i dati (TUTTI?!!!): Objectivity, per ora. èIl Computing di CMS e a tutti gli effetti (pregi e difetti) un SUBDETECTOR

4 P.Capiluppi 4 Padova Luglio 1999 è Geographical dispersion: of people and resources è Complexity: the detector and the LHC environment è Scale: Petabytes per year of data 1750 Physicists 150 Institutes 32 Countries Major challenges associated with: Communication and collaboration at a distance Distributed computing resources Remote software development and physics analysis R&D: New Forms of Distributed Systems LHC Computing Challenges

5 P.Capiluppi 5 Padova Luglio 1999 Events: èBunch crossing time of 25 ns is so short that (parts of) events from different crossings overlap èSignal event is obscured by 20 overlapping uninteresting collisions in same crossing Challenges: Complexity

6 P.Capiluppi 6 Padova Luglio 1999 Growth Rates Per Five Years* Major Experiment Bandwidth Requirements Major Experiment Bandwidth Requirements è For the next generation of experiments: ~100 times greater than in 1999 è ~1000 times increase in the next decade è Similar to the 1000- fold increase of the last ten years * The largest experiments tend to be at the upper end of this range HEP Bandwidth Growth Rates

7 P.Capiluppi 7 Padova Luglio 1999 LHC Challenges: Scale èData written to tape ~5 Petabytes/Year and UP (1 PB = 10 9 MBytes) èProcessing capacity 100 - TIPS and UP (1 TIPS = 10 6 MIPS) èTypical networks 0.5 - Few Gbps Per Link èLifetime of experiment 2-3 Decades èUsers ~ 5000 physicists èSoftware developers ~ 300 (Four Experiments) è 0.1 to 1 Exabyte (10 18 Bytes) (~2010) (~2020 ?) Total for the LHC (~2010) (~2020 ?) Total for the LHC

8 P.Capiluppi 8 Padova Luglio 1999 Le Dimensioni del Computing ad LHC Storage di ~10 Pbyte (raw data) : Tape robot + HPSS? Ricostruzione di un evento :250-500 SpecInt95 ·sec 5.0 10 4 SpecInt95 di CPU power/esperimento (~ 2 TIPS !) ovvero ~ 500 CPU da 100 SpecInt95 luna Simulazione completa di un evento :~2-5 kSpecInt95 ·sec Il MC e` una delle incognite, ma non e` la CPU il problema… Dimensione di un evento ricostruito :0.1 Mbytes Gli eventi ricostruti occupano 100 TB/esperimento allanno I/O delle Farm di Ricostruzione :100 Mbytes/sec Running time per anno :10 7 sec (1/3 di anno) 1 SPECint95 = 40 SPECint92 = 10 CERN units = 40 MIPS

9 P.Capiluppi 9 Padova Luglio 1999 Analysis Model CPU totale stimata per lanalisi fisica dei dati : 1.5-2.0 10 5 SpecInt95 1500-2000 CPU da 100 SpecInt95 Ogni analisi utilizza un campione di dati dellordine di 10 7 - 10 8 eventi 20 different analysis groups in the Collaboration 25 physicists/group (500 total CMS) 30% accessing the data at the same time (40% working time x different time zones x..., ~ 8 hours/day ) (150 total CMS) 7.5 physicists/group active at the same time 4-6 Regional Centres each dedicated to 5 Analysis groups (as an example)

10 P.Capiluppi 10 Padova Luglio 1999 Un possibile Processo di Analisi (1998!!!) Physics analysisCMS 2x10 5 SPECint95 1)Reduction of the analysis sample from 10 9 events to 10 7, on the basis of the tag database, for each group. {2)Each analysis group goes through the 10 7 events once per month, response time of 3 days, in order to rebuild the Rec. Obj. info.} Not in the CMS CTP, its the ODBMS that does it, when necessary! 3)Each physicist in a group goes through the 10 7 events every day to create the Analysis Objects with a reduction factor of 10 in size and 10 in number of events (10KB Anal. Obj./event, 10 6 events sample) 4)Each physicist in a group goes through the Anal.Obj. in 4 hour to produce plots, etc. Distribuito o centralizzato ? Individuale o coordinato ? (Ruolo dei Desk Top!) Ruolo ed impatto della Rete

11 P.Capiluppi 11 Padova Luglio 1999 Attivita e Persone (1) Sviluppo Software 1: Attivita locali Software per lo sviluppo e costruzione dei Detector (database Cristal, simulazione delle celle delle camere a muoni, microstrip detector design, CAE, etc). Sofware per la simulazione del comportamento dei detector: codifica dellapparato. Software per la ricostruzione: codifica e studio degli algoritmi legati alle possibilita dei Detector e alla Fisica dei processi. Software per la definizione dei trigger (fondamentale in un Collisionatore adronico come LHC): codifica, simulazione ed analisi fisica del segnale/fondo. Software per lanalisi e la valutazione di quanto sopra!

12 P.Capiluppi 12 Padova Luglio 1999 Attivita e Persone (2) Sviluppo Software 1: Attivita locali è>30 persone (staff e non) coinvolte in queste attivita: Oggi! (occorre potenziare) Con responsabilita nel Tracker (silici e Msgc), camere a muoni e calorimetro elettromagnetico. èHardware specifico: risorse dedicate ad ogni sviluppatore (non serve molto: singola CPU, ~10GByte disco, grande memoria e I/O). èSoftware specifico: piattaforma comune con gli altri sviluppatori e licenze (talvolta singole!) particolari. [Solaris e Linux!?] sviluppatore èNetwork e tools di network (AFS, update istantaneo delle release, common space, Web servers personali/comuni, etc.) per ogni sviluppatore sul Desktop (anche H323?!)garantiti! [distributed collaborative tools]

13 P.Capiluppi 13 Padova Luglio 1999 Core Software Milestones (L2)

14 P.Capiluppi 14 Padova Luglio 1999 Database Milestones (L2) Functional prototype

15 P.Capiluppi 15 Padova Luglio 1999 Attivita e Persone (3) (CORE Software) Sviluppo Software 2: Attivita centrali (CORE Software) Simulazione CMSIM in FORTRAN (in attesa di Geant4). Software Process: Cyclic Life Cycle Model per il software di CMS. Software Support: sistema di gestione del codice, delle versioni, del rilascio, della distribuzione e della costruzione. Information System: news, meetings, documents, agendas, minutes, videoconferences booking... Analysis and Reconstruction Framework: CARF Event Generators Detector Description Fast Simulation OSCAR: Detector simulation ORCA: Detector reconstruction Physiscs Object reconstruction and High Level Triggers User analysis environment Test Beam Calibration ODBMS

16 P.Capiluppi 16 Padova Luglio 1999 Attivita e Persone (4) è6-7 persone coinvolte (staff e non) in queste attivita, spesso non a pieno tempo(FTEs): occorrono persone!

17 P.Capiluppi 17 Padova Luglio 1999 Attivita e Persone (5) Filter WBS for only the professional software personnel Shortfall: 7 FTEs

18 P.Capiluppi 18 Padova Luglio 1999 Attivita e Persone (6)

19 P.Capiluppi 19 Padova Luglio 1999 Attivita e Persone (7) Analisi dei dati dai Test Beam Software specifico dipendente dai setup dei prototipi. Occorre simulare questi particolari apparati e costrure il software di analisi. Riportare il data recording e lanalisi nel Framework generale del software (Objectivity, ORCA, OSCAR,…). Lo scopo e ovviamente di comprendere gli apparati, ma anche per capire come codificare questultimi nel Software di CMS. è>30 persone (staff e non) coinvolte in queste attivita: Oggi! èHardware specifico: potenza di CPU (non molta in verita, ma dedicata), storage su disco (decine di GByte) e unita di backup/archive. èSoftware specifico: qualche pacchetto particolare, i tools della collaborazione e piattaforma la piu efficiente in Sezione. èNetwork: AFS in condizioni normali e devices per lo scambio dati (da concordare con i collaboratori ed il CERN)

20 P.Capiluppi 20 Padova Luglio 1999 Attivita e Persone (8) Simulazioni per lo studio dei Trigger e dei Processi Fisici identificabili Working Groups: Muon, b-tau, electron, jets Software di simulazione del giorno dopo (CMSIM116). Software di ricostruzione in continua evoluzione (ORCA 2.1.0_1,…ORCA3) Simulatori di processi fisici da selezionare/configurare. Codifica degli algoritmi di Trigger, legati alle prestazioni dei detector! produzioneOccorre tutto lambiente software di sviluppo e produzione di CMS

21 P.Capiluppi 21 Padova Luglio 1999 Attivita e Persone (9) Simulazioni per lo studio dei Trigger e dei Processi Fisici identificabili Working Groups: Muon, b-tau, electron, jets è~20 persone (staff e non) coinvolte in queste attivita atempo parziale. Limpegno crescera nel tempo ed occorre un supporto ulteriore (richiesta di personale dedicato) èHardware necessario: enorme potenza di CPU (CONDOR?), macchine dedicate sulle quali compilare la versione corrente allineata alle ultime release (sotto il controllo di CMS), grandi capacita di storage dedicate (centinaia di GByte) e devices per lo scambio/backup dei dati prodotti. èSoftware: essenziale AFS, ma anche LHC++, Condor, compilatori giusti, piattaforme adatte [Linux e Solaris!?]. èNetwork: capacita (banda o DiffServ) di comunicazione tra le macchine Condor e quelle dedicate in ogni Sezione, trasferimento delloutput ad un unico punto e banda capace di permettere la collaborazione per le simulazioni tra Sezioni diverse e diversi WGs (es. muon e b-tau) in Italia (sinergie e collaborazione)

22 P.Capiluppi 22 Padova Luglio 1999 Just to be clear ---- AIX WNT Irix Solaris Digital Unix HP-UX MAC-OS Linux Windows 95 SPARC MIPS Intel IA-32 PA-RISC Power PC Alpha Linux Windows 2000 Intel IA-32/64 - - - ? This is a proposal for a convergence policy –which looks realistic now –and will provide a single starting point for LHC computing but we can be sure that the business will not stand still, and we shall sooner or later have to expand the systems and architectures supported

23 P.Capiluppi 23 Padova Luglio 1999 Attivita e Persone (10) Un esempio dal Muon Working Group (by U. Gasparini) þMilestone November 1999 with 10% stat. Accuracy for Level 2 trigger momentum resolution: –~120 GByte disk storage –~150 CPU days on a 10 SI95 CPU þMilestone End 2000, complete Level 3 studies (10-20 Hz output for Muon), same accuracy: –~1TByte disk storage –~150 CPU days on a 100 SI95 CPU [o si hanno le possibilita di farlo o si e fuori dallanalisi! Vanificando lo sforzo e la competenza sui Detector!]

24 P.Capiluppi 24 Padova Luglio 1999 June 1999 Attivita e Persone (11)

25 P.Capiluppi 25 Padova Luglio 1999 Supporto Necessario (1) Personale dedicato Physicist Computing Professionals: i Fisici che sono esperti di computing. Sono quelli che lINFN dovrebbe far crescere, attraverso anche contratti temporanei, ma che linvestimento in risorse dellINFN dovrebbe portare a mantenerli in forma stabile. Computing Professionals: professionisti di Computing, necessari allo sviluppo dei vari progetti, necessari per il progetto che non necssitano (non sarebbe per altro possibile) di una posizione permanente nellINFN, ma la cui presenza deve essere garantita per larco del progetto. System Professionals: professionisti di sistemi, per la gestione efficiente di tutto il software e dei tools, fondamentali per il periodo di grande variabilita e specificita puntuale del software.

26 P.Capiluppi 26 Padova Luglio 1999 Supporto Necessario (2) Hardware dedicato CPU di riferimento e base per i Ricercatori CMS Piattaforme di sviluppo CPU power per simulazioni, anche condivise (Condor?) Storage locale e comune (alla collaborazione) Unita di scambio dati… o meglio Network tra tutte le Sezioni coinvolte in CMS (ed il CERN e Centri Regionali) di capacita garantita >155 Mbps. POSTI LAVORO ADEGUATI.

27 P.Capiluppi 27 Padova Luglio 1999 Supporto Necessario (3) alto Servizi di alto livello in Sede [non serve il basso livello: il toner da cambiare non e il problema…] Consulenza Sistemistica Supporto di Rete ed adeguamento alle bande necessarie, sui Server e sui Client. dinamicoSupporto dinamico dai Servizi: AFS/DFS, NT, Linux, Unix specifico, DNS, WAN, Security, Backup, Mail, Licnze, Web, Videoconferenze, Installazioni, LAN, …. Manualistica e DocumentazioneManualistica e Documentazione.

28 P.Capiluppi 28 Padova Luglio 1999 Supporto Necessario (4) Software Dedicato il software specifico e responsabilita dellEsperimento, ma: LHC++ (ed in particolare Objectivity!) Compilatori C++ e Java (incluse le JDK…) Networking e VRVS... Tools di Sviluppo (Rational Rose ad es.). Virus scan Librerie scientifiche extra LHC++ (NAG ad es.) CORBA, Distributed Computing, Distributed data access, Central storage Systems, HPSS?,...

29 P.Capiluppi 29 Padova Luglio 1999 Computing Off-line al CERN (1) Farm Off-line per la ricostruzione degli eventi: creazione degli ESD (ovvero riempimento/creazione degli oggetti di ricostruzione) Almeno la prima volta al CERN. Deve fornire anche la capacita di Analisi, almeno per un Gruppo ristretto di argomenti (un centinaio di users?). E fortemente correlata allOn-line. Data rate di scrittura a 100 MB/sec, e la lettura?

30 P.Capiluppi 30 Padova Luglio 1999 Hardware Milestones (L2)

31 P.Capiluppi 31 Padova Luglio 1999 Computing Off-line al CERN (2) Stime di Les Robertson (CERN/IT) nellambito di Monarc, basate su proiezioni di CMS (1998): Ricostruzione e supporto allanalisi per ~100 Fisici. Quanto costa? Il CERN non ha previsto (ancora) i costi nel Budget! Anno20022003200420052006Tot(02-06) CPU (KSI95) (tot)202070350520980 Dischi (TByte) (tot)102540240540855 Costo CPU (GLit)2.81.72.58.54.020 Costo Dischi (GLit)0.50.80.32.93.07.6

32 P.Capiluppi 32 Padova Luglio 1999 Rough Sizing Estimates for a Large LHC Experiment Facility Computing Off-line al CERN (3)

33 P.Capiluppi 33 Padova Luglio 1999 Comparison with LHC sized experiment

34 P.Capiluppi 34 Padova Luglio 1999 Computing Off-line al CERN (4) CMS ha un Common Project Computing (CORE Common Fund) sono 3.6 MCHF per il supporto allo sviluppo del progetto di Computing di CMS (al CERN) 500 KCHF dallINFN èQuale correlazione con la Farm Off-line ? (corretto dal punto di vista politico? e di gestione?)

35 P.Capiluppi 35 Padova Luglio 1999 Computing Off-line al CERN (5)

36 P.Capiluppi 36 Padova Luglio 1999 Modello di Computing: Monarc CMS (1) I Computing Technical Proposals di ATLAS e CMS (Dec 96) hanno/avevano differenze significative, ponendo comuni interrogativi di Architettura. Monarc e un R&D per definire delle linee guida attraverso la simulazione di diversi scenari di Risorse ed Analisi distribuiti (o concentrati in pochi punti) per il Computing ad LHC (o per il futuro di HEP?). ATLAS, CMS, LHCb, e ora anche ALICE(?) partecipano a questa attivita comune, insieme ovviamente al CERN/IT, sotto sponsorizzazione dellLCB. Monarc e una conseguenza necessaria della complessita del Computing ad LHC e della rivoluzione Object Oriented del Calcolo in HEP. Il Porgetto ha due fasi approvate (9 mesi conclusi nel Luglio 1999 e 6 mesi successivi) per fornire una baseline ai Computing Technical Proposal Reviews di ATLAS e CMS, previsti per la fine del 1999 (qualche mese in piu?), ed una terza fase proposta per fornire supporto ai Technical Design Reports sul Computing degli Esperimenti previsti per il 2002.

37 P.Capiluppi 37 Padova Luglio 1999 MONARC Models Of Networked Analysis at Regional Centres Status Report Harvey B. Newman (CIT) LCB, CERN June 22, 1999 http://www.cern.ch/MONARC/

38 P.Capiluppi 38 Padova Luglio 1999 MONARC Models Of Networked Analysis At Regional Centers Caltech, CERN, FNAL, Heidelberg, INFN, KEK, Marseilles, Munich, Orsay, Oxford, Tufts, … GOALS è Specify the main parameters characterizing the Models performance: throughputs, latencies è Develop Baseline Models in the feasible category è Verify resource requirement baselines: (computing, data handling, networks) COROLLARIES: è Define the Analysis Process è Define RC Architectures and Services è Provide Guidelines for the final Models è Provide a Simulation Toolset for Further Model studies 622 Mbits/s Desk tops CERN 6.10 7 MIPS 2000 Tbyte Robot University n.10 6 MIPS 100 Tbyte Robot FNAL 4.10 6 MIPS 200 Tbyte Robot 622 Mbits/s Desk tops Desk tops Model Circa 2006

39 P.Capiluppi 39 Padova Luglio 1999 MONARC PRIMARY GOALS Identify Baseline Computing Models: Viable Cost-effective solutions for LHC Data Analysis Deliver a simulation toolset to enable further Model studies Provide guidelines on the architecture and services of Regional Centres GOVERNING CRITERIA Network bandwidth, computing and data handling resources likely to be available at LHC startup Computing power and transport speeds needed for an effective data analysis Features, performance of the distributed database system Strategy for data distribution, processing and analysis

40 P.Capiluppi 40 Padova Luglio 1999 MONARC Regional Centre Concept Matched to the Worldwide-Distributed Collaboration Structure Best Suited for the Multifaceted Balance Between Proximity of the data to centralized processing resources Proximity to end-users for frequently accessed data Efficient use of limited network bandwidth (especially transoceanic) Appropriate use of regional and local computing and data handling resources Effective involvement of scientists and students in each world region, in the data analysis and the physics

41 P.Capiluppi 41 Padova Luglio 1999 MONARC Phases Phase 1: ~9 Months – Define set of models (site and network architecture, analysis process, event and data access submodels) – Choose and develop modelling (+ analysis, performance, monitoring) tools – Make use of evaluations of ODBMS (and HPSS) Performance – Assess requirements for computing and network resources and architecture Phase 2: ~6 Months – Further Simulation cycles to establish the baseline models – Develop guidelines for feasible models – Refine Modelling tools: provide a toolkit – Information in time for the Computing Technical Progress Report Phase 3: Possible proposal for extension by year-end

42 P.Capiluppi 42 Padova Luglio 1999 MONARC Working Groups Analysis Process P. Capiluppi (Bologna, CMS) Architectures Joel Butler (FNAL, CMS) Simulation Krzysztof Sliwa (Tufts, ATLAS) Testbeds Lamberto Luminari (Milan, ATLAS) Steering Laura Perini (Milan, ATLAS) Harvey Newman (Caltech, CMS)

43 P.Capiluppi 43 Padova Luglio 1999 Modello di Computing: Monarc CMS (2) Simulation, Analysis Design, Architecture, Test bed.Il progetto nella prima fase e stato organizzato in 4 Working Groups: Simulation, Analysis Design, Architecture, Test bed. La seconda fase verda una sinergia tra i WGs per via della forte correlazione tra i cicli di produzione dei Gruppi. –I risultati ottenuti nella prima fase ed altre info: www.cern.ch/MONARC Il Modello di Computing e basato su due pilastri: –Le risorse hardware (incluso il Network), software e programming non possono essere basate solo e principalmente al CERN. Distributed Computing –La dispersione dei partecipanti agli Esperimenti richiede una organizzazione di collaboration at a distance, implicando (anche politicamente) un Distributed Computing di portata e complessita senza precedenti (anche per gli Informatici). commodity –[Terzo pilastro!: occorre fare uso il piu possibile della realta della commodity (budget and availability)]

44 P.Capiluppi 44 Padova Luglio 1999 Modello di Computing: Monarc CMS (3) Monarc e una Collaborazione Italo-Americana, non a caso, anche se con diverse tradizioni e organizzazione sono i maggiori investitori in LHC. Modello diAnalisiIl Modello diAnalisi sembra tradizionale, ma non lo e! Forte gerarchia e tentativo di liberta nelle fasi finali.

45 P.Capiluppi 45 Padova Luglio 1999 MONARC Analysis Design Working Group DAQ -------------- Raw Slow C -------------- Calibration Reconstruction ---------------------- ESD/Rec. Obj +TAG DB Selection --------------- AOD/Anal. Obj Selection --------------- AOD/Anal. Obj Analysis ------------- Selected AOD/Anal. Obj & TAG DB Analysis ------------- Selected AOD/Anal. Obj & TAG DB Trigger Info x n WG x n Users in the WG 1st time at CERN (then at RC? ==> Parameters? Different WG at different site? ==> Parameters? RC or Desktop? ==> Parameters? 4 times per Year? (per Exp.) Once per Month? (per WG) 4 times per Day? (per User) Raw Data : On Tape, at CERN and at RC ESD/Rec.Obj : On Tape at CERN, on Disk at RC (Including CERN RC) for the samples needed by analysis at a given RC AOD/Anal. Obj : On Disk Selected AOD/Anal. Obj : On Disk TAG DB : On Disk Analysis Process

46 P.Capiluppi 46 Padova Luglio 1999 MONARC Analysis Design Working Group Data Model Raw Data Slow control Calibration data Trigger Tag Simulation Data Reconstruction ESD/Rec.Obj. Data Tag Data Selection Anal.Obj. Data AOD (2 steps) Data 1 PB/Year + 0.001 PB/Year? + ~0.5 PB/Year? Input of Analysis Local DB and/or Histograms Input of Input of 1.1 PB/Year + 100 GB/Year or 0.1 PB/Year + 100 GB/year CMS ATLAS Off-Line Farm (and other resources for Simulation) RCs (including CERN) 0.2 TB/Year x 2 using TAG CMS 20 TB/Year x 2 using TAG 2 TB/Year x 2 using TAG ATLAS pass1 ATLAS pass2 RC (including CERN) and/or Desktops Huge amount of Data! But negligible for Users (if DB is out of Global Objy DB)

47 P.Capiluppi 47 Padova Luglio 1999 Modello di Computing: Monarc CMS (5)

48 P.Capiluppi 48 Padova Luglio 1999 Modello di Computing: Monarc CMS (6) La simulazione e stata sviluppata al CERN con contributo CERN, Caltech, KEK (da una sola persona, di fatto, Iosif Legrand)

49 P.Capiluppi 49 Padova Luglio 1999 Modello di Computing: Monarc CMS (7) urgenti ArchitetturaTest bedAttualmente piu rilevanti ed urgenti per lINFN le prospettive dellArchitettura e dei Test bed. –Necessari per capire come arrivare alle milestones del Database e delle Risorse di Computing [Centri Regionali in particolare] –Milestones hardware CMS

50 P.Capiluppi 50 Padova Luglio 1999 Modello di Computing: Monarc CMS (8) Test Bed di Monarc tesi a misurare alcuni parametri di prestazioni per la simulazione del Computing Model ad LHC, ma importanti anche per lINFN: –Crescita delle competenze nelle Sezioni sui database ad oggetti distribuiti –Sperimentazione di collaborazioni, tra Sezioni, di risorse comuni e coordinate E il nuovo modo di Distributed Computing che HEP puo creare! –Base di partenza per una Analisi dei dati veramente distribuita tra Sezioni con risorse hardware, software e umane locali [E il nuovo modo di Distributed Computing che HEP puo creare!] Centro Regionale (non troppo) distribuito –Puo essere linizio di un Centro Regionale (non troppo) distribuito, realizzando eventualmente la gerarchia Tier1--> Tier2. Ma bisogna provare che funziona! Ed occorre rapidamente passare a prototipi di scala ragionevole èFase 3 di Monarc e Panda!

51 P.Capiluppi 51 Padova Luglio 1999 MONARC Testbeds WG (2)

52 P.Capiluppi 52 Padova Luglio 1999 Modello di Computing: Monarc CMS (9) Centri RegionaliArchitecture di Monarc e teso a stabilire le funzioni e la dimensione degli elementi realizzativi per il Computing ad LHC. Il punto piu rilevante per lINFN e quello dei Centri Regionali (senza dimenticare la Off-line Farm al CERN). Technical ServicesData Services –Un Centro Regionale deve essere integrato nellarchitettura di Computing di CMS (non facile!), capace di fornire tutti i Technical Services e tutti i Data Services per lanalisi: ha dimensioni dellordine del 10-20% della Off-line Farm al CERN per CMS (vedi il documento di Monarc Architecture redatto da L. Barone) decisa –Un Centro Regionale per lINFN in CMS e ormai cosa decisa: Presso i Consorzi di Calcolo: opzione ad oggi scartata. maggioriUn Centro Regionale Distribuito presso le maggiori Sezioni di CMS. base maggiore maggioriUn Centro con una base maggiore in un sito (eventualmente per tutto LHC?) e concentrazioni secondarie (Tier2?) presso le maggiori Sezioni di CMS. Un Centro completamente distribuito in tutte le Sezioni di CMS. Cose meglio?

53 P.Capiluppi 53 Padova Luglio 1999 Modello di Computing: Monarc CMS (9) Se il Centro regionale e il 10-20% del CERN allora: èRisorse e Costi èPersonale necessario alla realizzazione e mantenimento (programmare per tempo!) èIl Centro Regionale Italiano di CMS puo essere condiviso con gli altri Esperimenti ad LHC?

54 P.Capiluppi 54 Padova Luglio 1999 Modello di Computing: Monarc CMS (10)

55 P.Capiluppi 55 Padova Luglio 1999 Modello di Computing: Monarc CMS (11)

56 P.Capiluppi 56 Padova Luglio 1999 Modello di Computing: Monarc CMS (12)

57 P.Capiluppi 57 Padova Luglio 1999 Modello di Computing: Monarc CMS (13)

58 P.Capiluppi 58 Padova Luglio 1999 Modello di Computing: Monarc CMS (14) soluzionesceltaMonarc dara delle indicazioni, non la soluzione o la scelta che e giustamente lasciata alle Collaborazioni ed alle Agenzie di Finanziamento, ovvero INFN per noi. Monarc fase3 o PANDA possono essere dei prototipi di Testbed a scala reale per il Centro Regionale con gerarchia coordinata!

59 P.Capiluppi 59 Padova Luglio 1999 MONARC Possible Phase 3 TIMELINESS and USEFUL IMPACT Facilitate the efficient planning and design of mutually compatible site and network architectures, and services – Among the experiments, the CERN Centre and Regional Centres Provide modelling consultancy and service to the experiments and Centres Provide a core of advanced R&D activities, aimed at LHC computing system optimisation and production prototyping Take advantage of work on distributed data-intensive computing for HENP this year in other next generation projects [*] – For example The Particle Physics Data Grid of DoE/NGI; and joint proposal to NSF by ATLAS/CMS/LIGO in the US [*] See H. Newman, http://www.cern.ch/MONARC/progress_report/longc7.html

60 P.Capiluppi 60 Padova Luglio 1999 MONARC Phase 3 Possible Technical Goal: System Optimisation Maximise Throughput and/or Reduce Long Turnaround Include long and potentially complex decision-processes in the studies and simulations – Potential for substantial gains in the work performed or resources saved Phase 3 System Design Elements RESILIENCE, resulting from flexible management of each data transaction, especially over WANs FAULT TOLERANCE, resulting from robust fall-back strategies to recover from abnormal conditions SYSTEM STATE & PERFORMANCE TRACKING, to match and co- schedule requests and resources, detect or predict faults Synergy with PPDG and other Advanced R&D Projects. Potential Importance for Scientific Research and Industry: Simulation of Distributed Systems for Data-Intensive Computing.

61 P.Capiluppi 61 Padova Luglio 1999 Risorse (1) Hardware (CPU, disk, tape, support) –Posti lavoro –Attivita di R&D: Centro Regionale/Monarc, Siluppo software –Simulazioni: Working Groups di Fisica –Centro Regionale: realizzazione –Off-line Farm Network –LAN in Sede sia per R&D che per la Simulazione –WAN per Centro Regionale + Sezioni connesse (compreso R&D) e per Simulazione + Sviluppo Software –Licenze quotidiane –Licenze stile LHC++ –Tools di sviluppo –Senza dimenticare i Sistemi Operativi ed i Compilatori Man Power –Attivita di supporto –Attivita di sviluppo –Attivita di produzione –Centro Regionale

62 P.Capiluppi 62 Padova Luglio 1999 Risorse (3) Man Power Fte attuali Simulazione/ricostruzione~15 Sviluppo~10 Core software~2 Analisi Testbeam e detector~8 Monarc (Centro Regionale)~4 ~39 Totali Richieste199920002001>=2002 Physiscist computing256 8? Computing125 7? System567 7? Totale81318 22 + RC!

63 P.Capiluppi 63 Padova Luglio 1999 Software and Computing Reviews `99 (LHCC referees review in summer) (positive rev. in January)(LHCC referees review in summer) (positive rev. in January) Internal CMS review of SW&C project:Internal CMS review of SW&C project: –CERN October 25 LCB WorkshopLCB Workshop –Marseilles Sept 29 - Oct 1 Technical Progress Report (Update of CTP)Technical Progress Report (Update of CTP) –End of 1999 Computing Conceptual Review from September 1999 --> Spring 2000 at CERN (Computing Conceptual Review from September 1999 --> Spring 2000 at CERN (including TPRs)

64 P.Capiluppi 64 Padova Luglio 1999 Conclusioni Riconoscimento e supporto alle attivita di Computing attraverso: –Finanziamenti certi –Man power professional aggiuntivo sperimentazione e formazioneIl processo di definizione della strategia di calcolo per CMS (LHC) passa attraverso le attivita di sperimentazione e formazione (senza non si fara nulla!) CMS Italia intende elaborare una propria strategia per il Computing (ed il Centro Regionale) entro la fine del 1999. LINFN (Commissione Calcolo e CNTC e Esperimenti e Teorici stanno preparando un documento INFN per il Calcolo futuro!(1999) Occorre fare un salto di almeno un ordine di grandezza, SU TUTTO!

65 P.Capiluppi 65 Padova Luglio 1999 Cost Evolution

66 P.Capiluppi 66 Padova Luglio 1999 US Data Grid: Hierarchical Regional Centres Concept A Tier2 RC in Each US Region for Each Experiment, and One US Center at CERN Each for CMS and ATLAS