ppt - INFN - Sezione di Padova

P.Capiluppi
Padova
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
P.Capiluppi
LHC Experiments
Padova
Luglio 1999
ATLAS, CMS, ALICE, LHCb
Higgs and New particles; Quark-Gluon Plasma; CP Violation
2
P.Capiluppi
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

3
P.Capiluppi
Padova
Luglio 1999
LHC Computing Challenges
 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
4
P.Capiluppi
Padova
Luglio 1999
Challenges: Complexity
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
5
P.Capiluppi
Padova
Luglio 1999
HEP Bandwidth Growth Rates
Growth Rates Per Five Years*
Data Rate
to Storage
Data Volume
Stored Annually
LAN
Bandwidth
CPU
Power
3-10
2-10
10-30
10-30
* The largest experiments tend to be at the
upper end of this range
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
6
P.Capiluppi
Padova
Luglio 1999
LHC Challenges: Scale
Data written to tape
~5 Petabytes/Year and UP
(1 PB = 109 MBytes)
Processing capacity
100 - TIPS and UP
(1 TIPS = 106 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 (1018 Bytes)
(~2010) (~2020 ?)
Total for the LHC
7
P.Capiluppi
Le Dimensioni del Computing ad LHC
Padova
Luglio 1999
• Storage di ~10 Pbyte (raw data) : Tape robot + HPSS?
• Ricostruzione di un evento :
250-500 SpecInt95 ·sec
 5.0  104 SpecInt95 di CPU power/esperimento
(~ 2 TIPS !)
 ovvero ~ 500 CPU da 100 SpecInt95 l’una
• 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 all’anno
• I/O delle Farm di “Ricostruzione” :
100 Mbytes/sec
• Running time per anno :
107 sec (1/3 di anno)
1 SPECint95 = 40 SPECint92 = 10 CERN units = 40 MIPS
8
P.Capiluppi
Padova
Luglio 1999
Analysis Model
 CPU totale stimata per l’analisi fisica dei dati :
1.5-2.0  105 SpecInt95
 1500-2000 CPU da 100 SpecInt95
 Ogni analisi utilizza un campione di dati dell’ordine di 107 - 108 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)
9
P.Capiluppi
Padova
Luglio 1999
Un possibile Processo di Analisi (1998!!!)
Physics analysis
CMS 2x105 SPECint95
1) Reduction of the analysis sample from 109 events to 107 ,
on the basis of the tag database, for each group.
{2) Each analysis group goes through the 107 events once
per month, response time of 3 days, in order to rebuild the Rec. Obj.
info.} Not in the CMS CTP, it’s the ODBMS that does it, when
necessary!
3) Each physicist in a group goes through the 107 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, 106 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
10
P.Capiluppi
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
dell’apparato.
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 l’analisi e la valutazione di quanto sopra!
11
P.Capiluppi
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!?]
 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]
12
P.Capiluppi
Padova
Luglio 1999
Core Software Milestones (L2)
Proof of
Concept
Functional
Prototype
Fully
Functional
Production
System
GEANT4
Simulation of
CMS
June 1998
Dec 1999
June 2001
Dec 2003
Reconstruction/
Analysis
Framework
June 1998
Dec 1999
Dec 2001
Dec 2003
Detector
Reconstruction
Dec 1998
Dec 1999
June 2002
June 2004
Physics Object
Reconstruction
Mar 1999
June 2000
Dec 2002
Dec 2004
User Analysis
Environment
Dec 1998
June 2000
Dec 2002
Dec 2004
13
P.Capiluppi
Padova
Luglio 1999
Database Milestones (L2)
Use of DBMS for testbeam
Dec 1997
Event storage/retrieval ODBMS June 98, Dec/99, Dec/01, Dec/03
Functional prototype
Data Org./Access Strategy
Dec 1998
Filling ODBMS at 100MB/sec
June 1999
Sim. of data access patterns
Dec 2000
Integration of ODBMS and MSS
Dec 2000
Choice of Vendor of ODBMS
Dec 2001
Installation of ODBMS and MSS
Dec 2002
14
P.Capiluppi
Padova
Luglio 1999
Attivita’ e Persone (3)
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
15
P.Capiluppi
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!
Reconstruction PROject Management
D.Stickland
Project Manager
V.Innocente
Architect
Sub-System Coordinators
H-P.Wellisch
SW Process Manager
R.Wilkinson
Deputy
Object Persistancy
V.Innocente
Framework
V.Innocente
Utilities
T.Cox
Muon endcap
A.Vitelli
Muon barrel
L.Silvestris
Deputy
Testbeams
F.Behner
Calorimetry
L.Taylor
Visualization
E.Meschi
Trigger
L.Silvestris
Testbeam
C.Seez
Electron PG
U.Gasparini
Muon PG
T.Todorov
Tracker
S.Wynhoff
Examples
C.Williams
Librarian
S.Eno
Jet PG
16
P.Capiluppi
Padova
Luglio 1999
Attivita’ e Persone (5)
Filter WBS for only the professional software personnel
200
40
160
30
25
20
Shortfall:
7 FTE’s
15
10
5
Personnel (FTE's)
Software Professionals (FTE's)
35
CMS Software Professionals
CMS Software Professional
Personnel Requirements
CMS Physicist Developers
(projected)
CMS Physicist Developers
(Actual)
120
80
CMS WBS (May 1999)
CMS WBS (Nov 1998)
40
CMS (actual)
0
1998 1999 2000 2001 2002 2003 2004 2005 2006
Year
0
1998
2000
2002
2004
2006
Year
17
P.Capiluppi
Padova
Luglio 1999
Attivita’ e Persone (6)
Professional Manpower CMS Core Computing
35.0
30.0
FTEs
25.0
20.0
15.0
Computing Professionals
10.0
INFN (13%)
5.0
0.0
1999
2000
2001
2002
2003
2004
2005
Computing Professionals
21.5
25.0
27.0
31.3
33.3
33.3
33.3
INFN (13%)
2.8
3.3
3.5
4.1
4.3
4.3
4.3
Years
18
P.Capiluppi
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 l’analisi nel Framework generale del software
(Objectivity, ORCA, OSCAR,…).
Lo scopo e’ ovviamente di “comprendere” gli apparati, ma anche per capire
come codificare quest’ultimi 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)
19
P.Capiluppi
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!
Occorre tutto l’ambiente software di sviluppo e produzione di CMS
20
P.Capiluppi
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.
L’impegno 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 dell’output 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)
21
P.Capiluppi
Padova
Luglio 1999
Just to be clear ---• 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
- - - ?
22
P.Capiluppi
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 dall’analisi!
Vanificando lo sforzo e la competenza sui Detector!]
23
P.Capiluppi
Padova
Luglio 1999
Attivita’ e Persone (11)
June 1999
CMS MILESTONES
CORE SOFTWARE
End of Fortran development
GEANT4 simulation of CMS
Reconstruction/analysis framework
Detector reconstruction
Physics object reconstruction
User analysis environment
DATABASE
Use of ODBMS for test-beam
Event storage/retrieval from ODBMS
Data organisation/access strategy
Filling ODBMS at 100 MB/s
Simulation of data access patterns
Integration of ODBMS and MSS
Choice of vendor for ODBMS
Installation of ODBMS and MSS
1998
1999
2000
2001
Jun-98
1 Jun-98
2 Dec-99
1 Jun-98
2 Dec-99
1 Dec-98 2 Dec-99
1 Mar-99
2 Jun-00
1 Dec-98
2 Jun-00
Dec-97
1 Jun-98
Dec-98
2002
2003
3 Jun-01
3 Dec-01
3 Jun-02
3 Dec-02
3 Dec-02
2 Dec-99
3 Dec-01
2004
2005
4 Dec-03
4 Dec-03
4 Jun-04
4 Dec-04
4 Dec-04
4 Dec-03
Jun-99
Dec-00
Dec-00
Dec-01
Dec-02
1 Proof of concept
3 Fully functional
2 Functional prototype
4 Production system
24
P.Capiluppi
Padova
Luglio 1999
Supporto Necessario (1)
Personale dedicato
• Physicist Computing Professionals: i Fisici che sono “esperti” di computing.
Sono quelli che l’INFN dovrebbe “far crescere”, attraverso anche contratti
temporanei, ma che l’investimento in risorse dell’INFN 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” nell’INFN, ma la
cui presenza deve essere garantita per l’arco 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.
25
P.Capiluppi
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”.
26
P.Capiluppi
Padova
Luglio 1999
Supporto Necessario (3)
•
•
•
•
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.
Supporto “dinamico” dai Servizi: AFS/DFS, NT, Linux, Unix specifico,
DNS, WAN, Security, Backup, Mail, Licnze, Web, Videoconferenze,
Installazioni, LAN, ….
Manualistica e Documentazione.
27
P.Capiluppi
Padova
Luglio 1999
Supporto Necessario (4)
•
•
•
•
•
•
•
Software Dedicato
il software specifico e’ responsabilita’ dell’Esperimento, 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?, ...
28
P.Capiluppi
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 all’On-line.
Data rate di scrittura a 100 MB/sec, e la lettura?
29
P.Capiluppi
Padova
Luglio 1999
Hardware Milestones (L2)
Regional Centers:
Identify initial candidates
June 2000
Turn on functional centers
Dec 2002
Fully operational centers
June 2005
Central Systems:
Functional Prototype
Dec 2002
Turn on initial systems
Dec 2003
Fully operational system
June 2005
30
P.Capiluppi
Padova
Luglio 1999
Computing Off-line al CERN (2)
Stime di Les Robertson (CERN/IT) nell’ambito di Monarc,
basate su proiezioni di CMS (1998):
Ricostruzione e supporto all’analisi per ~100 Fisici.
Quanto costa?
Il CERN non ha previsto (ancora) i costi nel Budget!
Anno
2002
2003
2004
2005
2006
Tot(02-06)
CPU (KSI95) (tot)
20
20
70
350
520
980
Dischi (TByte) (tot)
10
25
40
240
540
855
Costo CPU (GLit)
2.8
1.7
2.5
8.5
4.0
20
Costo Dischi (GLit) 0.5
0.8
0.3
2.9
3.0
7.6
31
P.Capiluppi
Padova
Luglio 1999
Computing Off-line al CERN (3)
• Rough Sizing Estimates for a Large LHC Experiment Facility
Year
2004
2005
2006
2007
70’000
350’000
520’000
700’000
Disks (TB)
40
240
540
740
LAN throughput
(GB/sec)
Tapes (PB)
6
31
46
61
0.2
1
3
5
0.2
0.3
0.5
0.5
250
900
1400
1900
Total cpu (SI95)
Tape I/O
(GB/sec)
Approx box
count
32
P.Capiluppi
Comparison with LHC sized
experiment
Padova
Luglio 1999
Experiment Onsite CPU (Si95) onsite disk (TB) onsite tape (TB) LAN capacity Data Import/Export Box Count
LHC
520,000
540
3000
46 GB/s 10 TB/day (sustained) ~1400
CDF - 2
12,000
20
800
1 Gb/s
18 MB/s
~250
D0 - 2
7,000
20
600
300 Mb/s
10 MB/s
~250
Babar
D0
CDF
ALEPH
DELPHI
L3
OPAL
NA45
~6000
295
280
300
515
625
835
587
8
1.5
2
1.8
1.2
2
1.6
1.3
~300
65
100
30
60
40
22
2
Mix of Gb/sec, 100
Mb/sec Ethernet to
servers
300 Mb/s
100 Mb/s
1 Gb/s
1 Gb/s
1 Gb/s
1 Gb/s
1 Gb/s
~400 GB/day
?
~100 GB/day
?
?
?
?
5 GB/day
~400
180
?
70
80
160
220
30
33
P.Capiluppi
Computing Off-line al CERN (4)
Padova
Luglio 1999
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 dall’INFN
 Quale correlazione con la Farm Off-line ? (corretto dal punto di vista politico?
e di gestione?)
34
P.Capiluppi
Padova
Luglio 1999
Computing Off-line al CERN (5)
CMS Computing Common Fund
800.00
700.00
600.00
KCHF
500.00
File servers
400.00
Information Servers
300.00
Computing Pow er
Spares
200.00
System Assembly
100.00
0.00
SW Licences
1998
1999
2000
2001
2002
2003
2004
2005
File servers
94.84
131.00
131.00
110.00
120.00
145.00
185.00
100.00
Information Servers
13.80
65.00
65.00
50.00
70.00
80.00
90.00
50.00
Computing Pow er
55.50
105.00
105.00
90.00
100.00
110.00
150.00
80.00
Spares
0.00
15.00
15.00
10.00
15.00
55.00
60.00
30.00
System Assembly
1.30
15.00
15.00
10.00
10.00
20.00
20.00
10.00
SW Licences
4.20
40.00
40.00
40.00
60.00
60.00
90.00
10.00
System Management
8.60
105.00
105.00
90.00
100.00
100.00
100.00
50.00
INFN
60.00
60.00
60.00
70.00
70.00
70.00
80.00
30.00
Total
178.24
476.00
476.00
400.00
475.00
570.00
695.00
330.00
System
Management
INFN
Total
Years
35
P.Capiluppi
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 dell’LCB.
• 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.
36
P.Capiluppi
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/
37
P.Capiluppi
Padova
Luglio 1999
MONARC
Models Of Networked Analysis
At Regional Centers
Caltech, CERN, FNAL, Heidelberg,
Desk
INFN,
tops
KEK, Marseilles, Munich, Orsay, Oxford,
Desk
Tufts, …
tops
GOALS
University
Specify the main parameters
n.10 MIPS
characterizing the Model’s
100 Tbyte
performance: throughputs, latencies
Robot
Develop “Baseline Models” in the
“feasible” category
Verify resource requirement
Desk
baselines:
(computing, data
tops
handling, networks)
COROLLARIES:
 Define the Analysis Process
 Define RC Architectures and
Model Circa 2006
Services
 Provide Guidelines for the final
Models
 Provide a Simulation Toolset for
FNAL
4.106 MIPS
200 Tbyte
Robot
6
CERN
6.107 MIPS
2000 Tbyte
Robot
38
P.Capiluppi
MONARC
Padova
Luglio 1999
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
39
P.Capiluppi
•
•
•
•
•
MONARC Regional Centre Concept
Padova
Luglio 1999
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
40
P.Capiluppi
MONARC Phases
Padova
Luglio 1999
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
41
P.Capiluppi
MONARC Working Groups
Padova
Luglio 1999
“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)
42
P.Capiluppi
Padova
Luglio 1999
Modello di Computing: Monarc CMS (2)
• 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.
– 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”).
– [Terzo pilastro!: occorre fare uso il piu’ possibile della realta’ della commodity
(budget and availability)]
43
P.Capiluppi
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.
• Il Modello diAnalisi sembra tradizionale, ma non lo e’! Forte gerarchia e
tentativo di liberta’ nelle fasi finali.
44
P.Capiluppi
Padova
Luglio 1999
MONARC Analysis Design
Working Group
Analysis Process
DAQ
-------------Raw
Trigger
Info
Slow C
-------------Calibration
Reconstruction
---------------------ESD/Rec. Obj
1st time at CERN
(then at RC? ==> Parameters?
4 times
per Year?
(per Exp.)
+TAG DB
x n WG
Selection
--------------AOD/Anal. Obj
Analysis
------------Selected AOD/Anal. Obj
& TAG DB
Selection
--------------AOD/Anal. Obj
Different WG
at different site?
==> Parameters?
Once
per Month?
(per WG)
x n Users in the WG
Analysis
------------Selected AOD/Anal. Obj
& TAG DB
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
RC or Desktop?
==> Parameters?
4 times
per Day?
(per User)
45
P.Capiluppi
Padova
Luglio 1999
MONARC Analysis Design
Working Group
Data Model
Slow control
Calibration data
Trigger Tag
Raw
Data
Simulation
Data
Reconstruction
ESD/Rec.Obj.
Data
Tag
Data
Selection
Anal.Obj.
Data
AOD (2 steps)
Data
Analysis
Local DB
and/or
Histograms
1 PB/Year +
0.001 PB/Year? +
~0.5 PB/Year?
Input of
 Farm
Off-Line
(and “other” resources
for Simulation)
1.1 PB/Year +
CMS
100 GB/Year
or
0.1 PB/Year +
ATLAS
100 GB/year
Input of
RCs (including CERN)

0.2 TB/Year x 2
CMS
using TAG
20 TB/Year x 2
ATLAS
using TAG
pass1
ATLAS
2 TB/Year x 2
using TAG
pass2
Input of






RC (including CERN)
and/or Desktops
Huge amount of Data!
But negligible for Users
(if DB is out of Global Objy DB)
46
P.Capiluppi
Modello di Computing: Monarc CMS (5)
PARAMETER
Frequency
Input Data
CPU/event
Data Input Storage
Output Data
Data Output Storage
Triggered by
VALUE
4/ Year
1 PB
350 SI95.Sec
Tape (HPSS?)
0.1 PB
Disk
Collaboration
Data Input
Residence
Data Output
Residence
Time response
Priority (if possible)
CERN
CERN + some
RC
1 Month
High
Padova
Luglio 1999
RANGE
2-6/ Year
0.5-2 PB
250-500 SI95.Sec
Disk-Tape
0.05-0.2 PB
Disk-Tape
1/2 Collab. - 1/2
Anal. WGs
CERN + some RC
CERN + RCs
10 Days - 2 Months
47
P.Capiluppi
Modello di Computing: Monarc CMS (6)
Padova
Luglio 1999
• La simulazione e’ stata sviluppata al CERN con contributo CERN, Caltech,
KEK (da una sola persona, di fatto, Iosif Legrand)
48
P.Capiluppi
Modello di Computing: Monarc CMS (7)
Padova
Luglio 1999
• Attualmente piu’ rilevanti ed urgenti per l’INFN le prospettive
dell’Architettura 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
49
P.Capiluppi
Modello di Computing: Monarc CMS (8)
Padova
Luglio 1999
• Test Bed di Monarc tesi a misurare alcuni parametri di prestazioni per la
simulazione del Computing Model ad LHC, ma importanti anche per
l’INFN:
– Crescita delle competenze nelle Sezioni sui database ad oggetti distribuiti
– Sperimentazione di collaborazioni, tra Sezioni, di risorse comuni e coordinate
– 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!]
– Puo’ essere l’inizio 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!
50
P.Capiluppi
MONARC Testbeds WG (2)
Padova
Luglio 1999
51
P.Capiluppi
Modello di Computing: Monarc CMS (9)
Padova
Luglio 1999
• Architecture di Monarc e’ teso a stabilire le funzioni e la dimensione degli
elementi realizzativi per il Computing ad LHC.
Il punto piu’ rilevante per l’INFN e’ quello dei Centri Regionali (senza
dimenticare la Off-line Farm al CERN).
– Un Centro Regionale deve essere integrato nell’architettura di Computing di
CMS (non facile!), capace di fornire tutti i Technical Services e tutti i Data
Services per l’analisi:
ha dimensioni dell’ordine del 10-20% della Off-line Farm al CERN per CMS
(vedi il documento di Monarc Architecture redatto da L. Barone)
– Un Centro Regionale per l’INFN in CMS e’ ormai cosa decisa:
• Presso i Consorzi di Calcolo: opzione ad oggi scartata.
• Un Centro Regionale Distribuito presso le maggiori Sezioni di CMS.
• Un 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.
Cos’e’ meglio?
52
P.Capiluppi
Modello di Computing: Monarc CMS (9)
Padova
Luglio 1999
• 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?
53
P.Capiluppi
Modello di Computing: Monarc CMS (10)
Padova
Luglio 1999
Scope of the Tier 1 Regional Centre
•
Taken from Les Robertson’s presentation to MONARC
http://nicewww.cern.ch/~les/monarc/base_config.html
•
CPU
– in 2005: 3.6 TIPS
– 2006 on: 1.2 TIPS new + 1.2 TIPS replacement
disk
– in 2005: 108 TB
– 2006 on: 40 TB new + 27 TB replacement
serial storage
– in 2005: 1 robot + 0.4 PB
– 2006 on: 0.2 PB new + robot every 3 years
•
•
John Womersley
March 1999
54
P.Capiluppi
Modello di Computing: Monarc CMS (11)
Padova
Luglio 1999
Cost estimation
•
•
•
•
Costs de-escalated at CMS rates (Ian Willers, Feb 99)
Actual costs for cpu and disk are higher than CMS has assumed
and are based on our Run II experience:
– CPU
• $3.5M/TIPS in 2003 (cf. $1.35M)
– disk
• $26.90/GB in 2003 (cf. $10.71)
– my guess is that these differences are real and reflect the use
of expensive SMP machines in Run II vs. commodity price
estimates
Cost for serial storage also based on Run II
– $1.1M per robot plus $0.5M/PB for media
• total agrees reasonably with Ian’s
Networking and licences treated same way as Ian
John Womersley
March 1999
55
P.Capiluppi
Modello di Computing: Monarc CMS (12)
Padova
Luglio 1999
Scope buildup 2003-6
•
So that costs are roughly equal in 2003, 2004 and 2005
acquire 10% of disk and CPU in 2003, 30% in 2004, 60% in 2005
–
–
–
–
CPU:
disk:
tape:
robots:
2003
2004
2005
2006
0.4
11
0.03
1
1.44
43
0.05
3.6
108
0.4
4.8
148
0.6
0.33
TIPS
GB
PB
robots
John Womersley
March 1999
56
P.Capiluppi
Modello di Computing: Monarc CMS (13)
Padova
Luglio 1999
Bottom Line
•
•
•
Total hardware costs
– through 2005:
$13.5 M
Operating phase
– 2006 onward:
$7.4 M total per year
($3.9 M hardware + 35 people)
Note
– if I used Ian’s cost estimates I would approximately halve the
hardware costs. $7M to implement seems low to me based on
what it is costing to serve 400-500 people in CDF and DØ.
However, the numbers used here are rather conservative.
Maybe reality will be somewhere in between?
John Womersley
March 1999
57
P.Capiluppi
Modello di Computing: Monarc CMS (14)
Padova
Luglio 1999
• Monarc 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!
58
P.Capiluppi
MONARC Possible Phase 3
Padova
Luglio 1999
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
59
P.Capiluppi
MONARC Phase 3
Padova
Luglio 1999
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
coschedule 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.
60
P.Capiluppi
Risorse (1)
Padova
Luglio 1999
• 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
–
–
–
–
Attivita’ di supporto
Attivita’ di sviluppo
Attivita’ di produzione
Centro Regionale
• Man Power
61
P
.
C
a
p
i
l
u
p
p
i
Ma
Sim
Svi
Co
Monarc (Centro Regionale)
Richieste
~4
~39 Totali
1999 2000 2001 >=2002
Physiscist computing
2
Computing
1
System
5
6
8?
Analisi Testbeam e detector
2
5
7?
5
6
7
7?
~8
P.Capiluppi
Padova
Luglio 1999
Software and Computing Reviews `99
• (LHCC referees review in summer) (positive rev. in January)
• Internal CMS review of SW&C project:
– CERN October 25
• LCB Workshop
– Marseilles Sept 29 - Oct 1
• Technical Progress Report (Update of CTP)
– End of 1999
• Computing Conceptual Review from September 1999 -->
Spring 2000 at CERN (including TPRs)
63
P.Capiluppi
Conclusioni
Padova
Luglio 1999
• Riconoscimento e supporto alle attivita’ di Computing attraverso:
– Finanziamenti “certi”
– Man power “professional” aggiuntivo
• Il 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.
• L’INFN (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!
64
P.Capiluppi
Padova
Luglio 1999
Cost Evolution
65
P.Capiluppi
US Data Grid: Hierarchical
Regional Centres Concept
•
Padova
Luglio 1999
A Tier2 RC in Each US Region for Each Experiment, and One
“US” Center at CERN Each for CMS and ATLAS
66