CMS Computing
Paolo Capiluppi
Dept. of Physics and INFN Bologna
P. Capiluppi - CSN1 Perugia
11/11/2002
Outline
Organizzazione
Modello di Calcolo
Software baseline e tools comuni
Coinvolgimento in Progetti “Grid”
Data Challenges
Come usare i dati del DC04?
Verso il Physics TDR e computing TDR
Conclusioni
2
P. Capiluppi - CSN1 Perugia
11/11/2002
Legenda
CPT : Progetto CMS per il “Calcolo”
 C = CCS (Core Computing and Software)
 P = PRS (Physics and Reconstruction Software)
 Studi
di HLT (High Level Trigger)
 T = TriDAS (Trigger and Data Acquisition Systems)
PRS Groups ( Physics Groups)
 Muons (Muon Detector)
 B/Tau (Tracker)
 E/Gamma (ECAL)
 Jet/MissingEt (HCAL)
ORCA : Programma di ricostruzione (e analisi)
OSCAR : Programma di simulazione (Geant4)
CMSIM : Programma di simulazione (Geant3)
IGUANA : Programma di visualizzazione
IMPALA : Tool di sottomissione job di produzione
BOSS : Tool di logging/bookkeeping dei job di produzione
RefDB : Data Base di riferimento per le produzioni
P. Capiluppi - CSN1 Perugia
11/11/2002
3
CPT & CCS
CCS PM
David Stickland
Technical Coordinator
Lucas Taylor
Resource Manager
Ian Willers
Regional Center
Coordination
Lothar Bauerdick
Architecture
Frameworks
&Toolkits
Vincenzo Innocente
Production
Processing
& Data Mgmt
Tony Wildish
Computing
& Software
Infrastructure
Nick Sinanis
GRID
Integration
Claudio Grandi
CMS
Librarian
Shaun Ashby
CMS CB
CMS MB
CMS SC
CPT Managers
CCS PM
(Deputy)
PRS PM
(Deputy)
TriDAS PM
Deputy
4
P. Capiluppi - CSN1 Perugia
11/11/2002
Computing Model TDR
TDR sul Computing: Ottobre 2004
 Basato sui risultati del DC04 e sui Computing e Physics Models
 Planning Draft
 Risorse
e “cost-book”
 Data Types, Rates, Flow
 Calibration and Analysis
 Core software: architettura e scelte concrete
 On-line and Off-line tasks
 Grid tools
 Rapporti con LCG
 Etc.
 Richiede il commitment “da ora”
 Per
la partecipazione e la definizione del modo di operare
 Per attivita’ legate ad esso (es. DC04)
 NON e’ il TDR per la costruzione di un Detector.
 Il
Calcolo e’ in troppo rapida evoluzione
 Ma deve essere una possibile e realizzabile soluzione
 Input di CMS per il TDR di LCG ( 9 mesi dopo)
 Base del Computing MoU ? (All’interno di LCG ?)
5
P. Capiluppi - CSN1 Perugia
11/11/2002
Modello di Calcolo
come arrivarci ? (1/2)
CMS Italia ha scelto uno schema di “calcolo” distribuito sulle Sedi:
 con differenziazione delle responsabilita’
 valorizzazione degli “interessi” e “competenze” locali
Questo sistema ha dimostrato di funzionare
Compresa l’analisi (LNL, Bo, Pd, Pi, …) 
Alcune funzioni e specificita’ (chiamate in gergo “services”) sono
tipiche di una gerarchia
 Modello di Tier0, Tier1, Tier2, Tier3 …
Altre sono tipiche di una distribuzione paritaria
 Modello distribuito alla “GRID”
Queste due cose NON sono incompatibili
 I “services” possono essere differenziati in funzione delle responsabilita’,
competenze e tecnologia software/middleware
CMS (tutta) ha intrapreso questa strada ed in particolare ha un forte
commitment in LCG
 Per l’infrastruttura comune e il software comune
 Speranza di ottenere “2” spendendo “1” (sinergia tra gli Esperimenti LHC) 6
P. Capiluppi - CSN1 Perugia
11/11/2002
Production in the RCs
RC name
CMSIM (K) 2x1033 (K)
1034 (K)
Objy size (TB)
CERN
870
1670
1970
10.4
Bristol/RAL
547
60
20
0.4
Caltech
214
146
Fermilab
345
251
332
2.5
INFN (9 sites)
1545
719
709
3.0
IN2P3
200
Moscow (4 sites)
425
UCSD
338
278
288
1.8
UFL
540
40
40
0.2
Wisconsin
67
54
Imperial College
878
147
0.5
0.2
0.3
121
1.4
Thanks to: Giovanni Organtini (Rm), Luciano Barone (Rm), Alessandra Fanfani (Bo),
Daniele Bonacorsi (Bo), Stefano Lacaprara (Pd), Massimo Biasotto (LNL), Simone
Gennai (Pi), Nicola Amapane (To), et al.
P. Capiluppi - CSN1 Perugia
11/11/2002
7
Modello di Calcolo,
come arrivarci ? (2/2)
CMS Italia ha scelto fin dall’inizio di avere una propria Sede di
riferimento (con le competenze e interessi locali):
Tier2 di riferimento a Legnaro
 50% delle produzioni 2002
Il Disegno globale a breve termine:
Ruolo del Tier1 (comune per l’INFN)




~40% del commitment italiano
Assorbimento dei picchi di CPU (shared con gli altri Esperimenti)
Mass Storage e accentramento dei dati di simulazione e analisi
Riferimento core software (supporto)
Ruolo dei Tier2 (incluso il Tier2 di riferimento)
 ~40% del commitment italiano
 CPU e storage (solo dischi e/o archive) per l’analisi (distributa, non solo
plots!)
 Dimensionamento delle attivita’ in funzione delle competenze ed
interessi locali (dal farming alla analisi)
Ruolo dei Tier3
 ~20% del commitment italiano
 Punto di forza in item specifici sia di analisi che di software e/o supporto
e/o middleware
8
P. Capiluppi - CSN1 Perugia
11/11/2002
Spring02: CPU Resources
11 RCs (~20 sites)
About 1000 CPUs and 30 people CMS-wide
Some new sites & people, but lots of experience too
UFL 5%
Wisconsin
18%
UCSD 3%
Bristol 3%
RAL 6%
Caltech 4%
Moscow
10%
FNAL 8%
HIP 1%
INFN 18%
CERN 15%
IN2P3 10%
IC 6%
MA non erano ancora entrati in gioco i Tier1 !
P. Capiluppi - CSN1 Perugia
11/11/2002
9
Cosa si e’ ottenuto?
Coinvolgimento e partecipazione di tutte le Sedi
 Attraverso i vari interessi e le varie competenze
 Diffusione della conoscenza delle problematiche di calcolo ed
analisi
Produzione ed Analisi in Italia in modo consistente
Risultati dei PRS anche per il DAQ TDR
 Il Software di ricostruzione e’ un “deliverable” dei Rivelatori
(Il Computing e’ compreso nei commitments)
10
P. Capiluppi - CSN1 Perugia
11/11/2002
Software Baseline
and Common Tools
Cosa puo’ esserci in comune con gli altri esperimenti LHC (o
HEP tutta)? (LCG Application Area e HEPCAL…)
 Prodotti software che non hanno a che fare con “Dati e Calcolo
distribuiti” (Grid independent): es. Generatori di Fisica, (Detector
Description DataBase), …
 Prodotti software (middleware) che gestiscono la distribuzione dei
dati e del calcolo (Grid dependent): es. Brokering dei job, Data
replication, Information System, Monitoring, …
 Prodotti software che sono influenzati dalla caratteristica
distribuita del Calcolo (Grid-aware): es. Persistenza, meta-data
structure, Bookkeeping…
Ovviamente ci sono Prodotti che NON “possono” essere
comuni:
 programmi di ricostruzione dei vari detector, tools di gestione
specifici dell’architettura del Computing Model, …
In attesa dello sviluppo delle parti “comuni”, CMS ha
sviluppato propri tools, oltre alle parti specifiche “non-comuni”
11
P. Capiluppi - CSN1 Perugia
11/11/2002
Software Baseline e
Tools comuni
Persistenza:
 Da Objectivity a Pool/ROOT 
 First public release foreseen before Xmas 02
Simulazione :
 Da CMSIM (Geant3) a OSCAR (Geant4) 
Visualizzazione :
 IGUANA (basato su Oggetti) 
Test beam software :
 ORCA + OSCAR (stessi programmi) 
12
P. Capiluppi - CSN1 Perugia
11/11/2002
Dependencies on LCG and
External Software
EDG/VDT
Catalog
ROOT
 Objectivity/DB was not just a
persistency solution
 Catalog, Replication, Shallow
Copying, AMS, Request
Redirection, etc
POOL
 We must establish the explicit
dependencies so as to ensure full
bidirectional understanding with
these projects on detailed
implementation schedules
 CCS Preparations for DC04
 LCG/GDB work-plan for this
Autumn
CMS Data
Challenge
DC04
13
P. Capiluppi - CSN1 Perugia
11/11/2002
Test-Beam and data-handling
Analysis and simulation of both
Test-beam and simulated data
Fully integrated in ORCA/OSCAR
framework
Calibration of FED parameters
with ORCA/ApvAnalysis
• Simulation of FED algorithms (Zero
Suppression, Noise evaluation, Pedestal
subtraction)
•Study different FED algorithms in the
whole Tracker, data rates and calibration
of the FEDs in a real data taking
•Test different alignment algorithms on
real data
•Integrated with Geant4 simulation
Simulated Pion
in G4/ORCA
14
P. Capiluppi - CSN1 Perugia
11/11/2002
OSCAR/Geant4 Simulation
OSCAR/G4 v1.3 ok for the Tracker: validated by detailed comparison with
Cmsim
position of
SimHits
Cmsim
simulated
hits per
track
OSCAR 1
tracking
resolution
tracking
efficiency
DDD + OSCAR2
OSCAR 2 complete
rewriting of the
framework, same
physics part
15
P. Capiluppi - CSN1 Perugia
11/11/2002
PRS Tracker Contributions to IGUANA
Tracker selection map:
display a layer/ring in a 3D
window;
open a 2D map of a layer/ring.
Detector units
along sim tracks
Draw sim hits
for selected modules
Custom tracker selection
Vertex visualisation
Tracker reconstruction geometry
2D selection maps:
display a module in a 3D window.
P. Capiluppi - CSN1 Perugia
Print information
for selected module
16
11/11/2002
CMS common or specific
products
“IMPALA”
Interface
Job Scripts Generator
Web Interface for
Production Requests
Central
Input Parameters DB
Interface
Monitoring
Schema & Scripts
“RefDB”
“BOSS”
Web Interface for
Browsing of Metadata
& Data Location
Interface
Local
Job Monitoring DB
Central
Output Metadata DB
Interface
Job Scheduler
Plus: Executables Distribution
=“DAR”; Data Transfer Tools
= “Tony’s scripts”;
Data Storage
17
P. Capiluppi - CSN1 Perugia
11/11/2002
GRID cose’?
Non solo per CMS !
18
P. Capiluppi - CSN1 Perugia
11/11/2002
Logical components diagram
Software release
Experiment
Software
Software
Repository
New dataset
request
Data Management
System
Data
Materializer
Job
Definition
Job
Monitoring
Definition
Data management operations
Storage
Service
Dataset
Catalogue
Input data
location
Dataset
Definition
Software
Release Manager
Data
Resource Monitoring
System
Retrieve
Resource
status
Workload
Management System
Job submission
Resource
Directory
Job assignment to resources
Job
Catalogue
Publish
Resource
status
Computing
Service
Job Monitoring
System
Job type definition
By Claudio Grandi
P. Capiluppi - CSN1 Perugia
Job
Book-keeping
11/11/2002
Push data
or info
Pull info
19
Spring 2002 diagram
Software release
CMKIN/SIM
ORCA
DAR files
CVS repository
Production
web portal
New dataset
request
AMS POSIX
Data management operations
GDMP

RefDB
Input data
location
Dataset
Definition
SCRAM/DAR
IMPALA

Data
Web page with links
to RC home pages
 
Retrieve
Resource
status
Resource
Directory
Publish
Resource
status
Local Batch System
(or Grid Scheduler)
IMPALA
scripts
Job assignment to resources
Farm node
(or GRAM)
Scheduler
Job catalog
BOSS
Schema
Filter files
Push data
or info
Pull info
Job type definition
By Claudio Grandi
P. Capiluppi - CSN1 Perugia
BOSS DB
20
11/11/2002
Proposal for a DC04 diagram
Software release
Experiment
Software
Dataset
Definition
REPTOR/Giggle?
PACMAN?
Dataset
Catalogue
New dataset
request
REPTOR/Giggle +
Chimera?
EDG SE
Data management operations VDT Server
Dataset
Catalogue
Data
Input data
location
MDS
VDT Planner
IMPALA/MOP
EDG UI
VDT Client
DAG/JDL
+scripts
Retrieve
Resource
status
EDG Workload
Management System
Publish
Resource
status
LDAP
Job assignment to resources
Job submission
EDG L&B
EDG CE
VDT server
BOSS&R-GMA
Job
Monitoring
Definition
Push data
or info
Pull info
Job type definition
By Claudio Grandi
P. Capiluppi - CSN1 Perugia
BOSS-DB
21
11/11/2002
Grid in CMS oggi
Vedi le presentazioni su Grid
Produzione ufficiale in corso in US su Grid
 MOP Production 
Produzione ufficiale in partenza in EU su Grid
 Stress Test per provare la compatibilita’ dei prodotti CMS con
EDG/EDT (~1 M eventi) 
 CMS/EDG Task Force ufficiale, con la partecipazione di personale
LCG e EDT
L’Integrazione e la Interoperabilita’ sono essenziali per CMS
 Es di Legnaro 
22
P. Capiluppi - CSN1 Perugia
11/11/2002
IGT E-Gamma Production
Production progressing –
 Disk on Master Filled over the weekend 
 Magically Data continues to come in after space was cleared without
explicit restarting ???
 Still
exploring this... Condor DAGMAN model of fault tolerance and/or
use of ftsh suspected...
23
P. Capiluppi - CSN1 Perugia
11/11/2002
IMPALA/BOSS
Stress Test implementation
CE
RefDB
BOSS
DB
parameters
UI
IMPALA
SE
Job output filtering
Runtime monitoring
RC
data
registration
JDL
CE
JobExecuter
dbUpdator
WN
Write data
CMS sw
SE
GRID
SERVICES
CE
CE
CMS sw
SE
SE
By Alessandra Fanfani
24
P. Capiluppi - CSN1 Perugia
11/11/2002
Layout farm LNL 2002:
production + analysis + grid
= grid enabled element
Production N1
computing
nodes
N24
N24
N1
N24
N1
FastEth
FastEth
FastEth
SWITCH
SWITCH
SWITCH
To WAN
34 Mbps 2001
~ 1Gbps 2002
Analysis
computing
nodes
32 – GigaEth 1000 BT
GW
S1
S9
Production
servers
Production
control
P. Capiluppi - CSN1 Perugia
CE
SE
S10 S11 S12
G1
Analysis
servers
Remote login
Analysis
UI
G2
Grid enabled
Analysis 25
11/11/2002
Verso il “Computing” di CMS:
Data Challenges
I Data Challenges servono a:
 Provare le soluzioni proposte nella realta’ (hardware e software)
 Coordinare lo sviluppo e garantirne la mantenibilita’
(commitments) selezionando i partecipanti ed il personale
 Verificare la scalabilita’ delle soluzioni dai prototipi al Sistema
finale (iniziale, in verita’. Evolvera’ per la vita di CMS)
 Programmare gli investimenti (monetari e di personale)
 Distribure e preparare la conoscenza per l’ANALISI FISICA
CMS ha gia’ realizzato almeno un paio di Data Challenges
 2000-01: pre-produzioni e sviluppo del software secondo il
Computing Technical Proposal(1998?). Usato per gli studi di
Trigger.
 2002: Full deployment del Software e delle risorse distribuite nei
pre-Regional Centres. “Spring Production” (6 M events),
compresa l’analisi. Usato per gli studi di HLT del DAQ TDR.
Le Sezioni (Tiers) CMS Italia hanno contribuito per circa il
20% dello sforzo totale di CMS
26
P. Capiluppi - CSN1 Perugia
11/11/2002
Verso il “Computing” di CMS:
Data Challenges di CPT!
I prossimi Data Challenge di CMS (con LCG-1, LCG-3)
DC04 (detto 5% DC): finito per Aprile 2004
 Scopo e dimensioni, vedi dopo
DC05 (detto 10% DC): finito per Aprile 2005
 Un mese a ~50 Hz (L=0.2x1034 cm-2 s-1) ~ 108 eventi
 Validazione del Grid Model realizzato da LCG (Tier0, Tier1s and Tier2s)
 In tempo per la fine della fase 1 di LCG (Dicembre 2005, LCG TDR) e per
MoU(s) sul Computing
 Catena completa dei prodotti per l’analisi
 In sincronia con il Physics TDR di CMS dovuto per la fine del 2005
DC06 (detto 20% DC): finito per Aprile 2006
 Un mese a ~100 Hz (L=0.2x1034 cm-2 s-1) ~ 2x108 eventi
 In tempo per comprendere ed eventualmente modificare la realizzazione
del Computing Model di CMS prima della presa dati nel 2007.
 Dimostrazione della scalabilita’, includendo tutte le possibili operazioni
in un sistema distribuito di Tiers alla Grid.
P. Capiluppi - CSN1 Perugia
11/11/2002
27
DC04: Two Phases
Pre-Challenge (2003 Q3, Q4)
(Must be successful)
Introduce GRID tools
 Large scale simulation and digitization
As available and tested
 Will prepare the samples for the challenge
 Will prepare the samples for the Physics TDR work to get fully underway
 Progressive shakedown of tools and centers
 All
centers taking part in challenge should participate to pre-challenge
 The Physics TDR and the Challenge depend on successful completion
 Ensure
a solid baseline is available, worry less about being on the cutting
edge
Challenge (2004 Q1, Q2)
 Reconstruction at “T0”(CERN)
 Distribution to “T1s”
 Subsequent
distribution to “T2s”
(Must be able to fail)
Make full use of LCG-1 GRID.
Test the functionality they deliver
 Assign “streams” and “pre-configured analyses” to people at T1 and T2
centers
 Some
will be able to work entirely within one center
 Others will require analysis of data at multiple-centers
 GRID tools tested for data movement and job migration
28
P. Capiluppi - CSN1 Perugia
11/11/2002
DC04 Setting the Scale
Challenge
Pre-Challenge
 Aim is 1 month of “running” at 25 Hz, 20 hours per day
 50 Million reconstructed events
 (passing L1 Trigger and mostly passing HLT, but some background
samples also required))
 Simulation (GEANT4!)
 100TB
 300 kSI95.Months


1GHz P3 is 50 SI95
Working assumption that most farms will be at 50SI95/CPU in late 2003
Six months running for 1000 CPUS (Worldwide)
(Actually aim for more CPU’s to get production time down)

 Digitization
 75TB
 15 kSI95.Months
 175MB/s Pileup bandwidth (if allow two months for digitization)
 Reconstruction at T0-CERN
 25TB
 23 kSI95 for 1 month (460 CPU @ 50SI95/CPU)
 Analysis at T1-T2s
 Design a set of tasks such that offsite requirement during challenge is
about twice that of the “T0”
29
P. Capiluppi - CSN1 Perugia
11/11/2002
CMS Italia e il DC04, e oltre
Partecipare al Challenge : contribuire per ~ 20%
 Possibilmente tutte le risorse parteciperanno al pre-challenge
Coordinare la partecipazione attraverso LCG
 Il Tier1/INFN deve essere “fully functional”
 ~70
CPU boxes e ~20 TB
 Le risorse conferite in LCG cresceranno in funzione del successo
 Inizialmente
Legnaro (gia’ “dinamico”) e il Tier1 gia’ “committed”
 A seguire le altre risorse
Definire i commitment delle Sedi Italiane
 Ruoli in funzione delle competenze del personale
 Definire la meteodologia
Definire il “data flow”
 E le “analisi pre-confezionate”
Aumento delle risorse di un fattore 3 per il DC05 (2004-05)
30
P. Capiluppi - CSN1 Perugia
11/11/2002
Resource Needs vs Pledged 04
Estimates for CPU and Storage Requirements for CMS Data Challenge DC04
Ye ar.Quarte r
03Q3
03Q4
04Q1
100
215
25
50
25
17
33
Com puting Pow e r (k SI95 M onths )
Total Require m e nt for Sim ulation, Pile -up, Re con
Total Require m e nt for Analys is / Challe nge Prope r
CERN T0 (1/3 s im ulation, all Re con)
CERN T1 (1/3 of Challe nge prope r)
Offs ite T1+T2 (Challe nge only), ass um i
33
Storage (Te raByte s )
Data Ge ne rated CERN
Data Ge ne rated Offsite
Data Trans ferre d to CERN
Sum Data Store d CERN
Active Data at CERN
Sum Data Store d Offs ite (3 T1)
72
67
143
19
39
17
36
25
39
39
78
33
108
75
117
04Q2
50
17
33
25
133
100
192
133
100
192
Estimated CMS resources outside CERN (prelim. & incompl.) at end of 2003
De
Es
Fi
CPU [kSI95]
Disk [TB]
Tape fast
Tape archive
6
10
2.5
5
2
1.2
30
5
1.2
Peak CPU(?)
12
7.5
Fr
It
10
0.5
20
10
30
15
20
20
Kr
7
30
Ru
2.5
1.2
15
5
UK
USA
CMS total
20
20
50
31
41
100
91 kSI95
139 Tbyte
200 Tbyte fast
40
60
160 kSI95 Peak
Q: how many FTE are available for CMS production at the RCs?31
P. Capiluppi - CSN1 Perugia
11/11/2002
Risorse CMS Italia
2003 CMS
Computing
+ “tasca” Computing 2003?
2003 resources status
#
#
Average Total TBs on Farm
CPUs Boxes
CPU
Si95
disk
(% of
(MHz)
servers use)
DC04
estimates
SI95
TB
Bari
Bologna
Catania
Firenze
Legnaro
Milano
Napoli
Padova
Perugia
Pisa
Roma1
Torino
28
34
16
42
160
14
14
17
8
21
80
7
1000
1100
1600
1000
1200
1800
1400
1870
1280
2100
9600
1260
2.7
3.3
1.1
1.6
9
1.6
100
100
100
30
100
50
1400
1870
1280
630
9600
2.7
3.3
1.1
1.6
9
40
16
30
24
22
20
8
15
14
11
900
1000
1000
1000
1180
1800
800
1500
1200
1298
0.4
1
2.5
2
2.6
100
90
100
100
100
1800
0.4
1500
1200
1298
2.5
2
2.6
Total
426
215
24108
27.8
20578
25.2
Tier1 CNAF
140
70
8400
11
7560
11
Grand
Tot
566
P. Capiluppi
- CSN1 Perugia
285
38.8 11/11/2002 28138
36.2
1200
32508
90
32
Conclusioni
Il “Sistema” di Calcolo di CMS Italia funziona (disegno
corretto)
 Non solo “Core Computing & Software”, ma anche “Physics
Reconstruction Software” e “Trigger & Data Acquisition”
Partecipazione sostanziale a LCG e ai progetti Grid
Commitment per partecipare al DC04
 Ufficialmente oggi in LCG-1 per CMS: Tier1 e Legnaro
 Partecipazione al pre-DC04 di tutti i Tier2/3
 Partecipazione al DC04 di Tier selezionati (interesse)
Contributo Italiano importante ( alla frazione INFN di CMS)
nei PRS, in Tridas, nella “Produzione / Analisi” e in GRID
… ma “scarso” nel CCS
 Occorre investire di piu’ sul “Core Software”!
33
P. Capiluppi - CSN1 Perugia
11/11/2002
“Pool” off the Grid
Experiment Framework
User Application
Collections
MySQL or RootIO
Collection
File Catalog
XML / MySQL
Catalog
RootI/O
Meta Data
LCG POOL
MySQL
Disconnected Laptop
By Vincenzo Innocente
34
P. Capiluppi - CSN1 Perugia
11/11/2002
Pool on the Grid
Grid Dataset
Registry
File Catalog
Replica Location
Replica Manager
Service
RootI/O
Meta Data
LCG POOL
Meta Data
Catalog
Grid Resources
Experiment Framework
User Application
Collections
Grid Middleware
By Vincenzo Innocente
35
P. Capiluppi - CSN1 Perugia
11/11/2002