CMS Computing

1
CMS Computing

• Paolo Capiluppi
• Dept. of Physics and INFN Bologna

2
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

3
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

4
CPT CCS
5
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 ? (Allinterno di LCG ?)

GOAL di CPT, CMS Computing
6
Modello di Calcolocome 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 lanalisi (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 linfrastruttura comune e il software comune
• Speranza di ottenere 2 spendendo 1 (sinergia
  tra gli Esperimenti LHC)

7
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 0.5
Fermilab 345 251 332 2.5
INFN (9 sites) 1545 719 709 3.0
IN2P3 200
Moscow (4 sites) 425 0.2
UCSD 338 278 288 1.8
UFL 540 40 40 0.2
Wisconsin 67 54 0.3
Imperial College 878 147 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.
8
Modello di Calcolo,come arrivarci ? (2/2)

• CMS Italia ha scelto fin dallinizio 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 lINFN)
• 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
  lanalisi (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

9
Spring02 CPU Resources

• 11 RCs (20 sites)
• About 1000 CPUs and 30 people CMS-wide
• Some new sites people, but lots of experience
  too

Wisconsin
UFL 5
18
Bristol 3
UCSD 3
RAL 6
Caltech 4
Moscow
FNAL 8
10
HIP 1
INFN 18
CERN 15
IN2P3 10
IC 6
MA non erano ancora entrati in gioco i Tier1 !
10
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)

11
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 dellarchitettura del
  Computing Model,
• In attesa dello sviluppo delle parti comuni,
  CMS ha sviluppato propri tools, oltre alle parti
  specifiche non-comuni

12
Software Baseline eTools 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) ?

13
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
• 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

POOL
CMS Data Challenge DC04
14
Test-Beam and data-handling
Analysis and simulation of both Test-beam and
simulated data Fully integrated in
ORCA/OSCAR framework
Calibration of FED parameterswith
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 Pionin G4/ORCA
15
OSCAR/Geant4 Simulation
OSCAR/G4 v1.3 ok for the Tracker validated by
detailed comparison with Cmsim
position of SimHits
simulated hits per track
Cmsim
OSCAR 1
tracking efficiency
tracking resolution
DDD OSCAR2
OSCAR 2 complete rewriting of the framework, same
physics part
16
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
Print information for selected module
2D selection maps display a module in a 3D
window.
17
CMS common or specific products
Job Scripts Generator
Central Input Parameters DB
Monitoring Schema Scripts
RefDB
Local Job Monitoring DB
Central Output Metadata DB
Job Scheduler
18
GRID cose?
Non solo per CMS !
19
Logical components diagram
Experiment Software
Dataset Definition
Data Materializer
Job Definition
Computing Service
Job Monitoring Definition
By Claudio Grandi
20
Spring 2002 diagram
CMKIN/SIM ORCA
Software release
Dataset Algorithm Specification
Dataset Input Specification
Copy data
?
Dataset Definition
New dataset request
Data management operations
?
Write data
?
SW download installation
Fetch request parameters
Retrieve Resource status
?
Write dataset summary
Publish Resource status
IMPALA
Input data location
?
Job creation
Read data
IMPALA scripts
Job assignment to resources
Farm node (or GRAM)
Job submission
Job output filtering
Production monitoring
Job submission
Schema Filter files
Job type definition
By Claudio Grandi
21
Proposal for a DC04 diagram
Experiment Software
Software release
Dataset Algorithm Specification
Dataset Input Specification
Copy data
Dataset Definition
Data management operations
New dataset request
Write data
SW download installation
Production on demand
Retrieve Resource status
Publish Resource status
Update dataset metadata
VDT Planner IMPALA/MOP
Input data location
Job creation
EDG UI VDT Client
Read data
DAG/JDL scripts
Job assignment to resources
EDG CE VDT server
Job submission
Job output filtering
Production monitoring
Job Monitoring Definition
Job type definition
By Claudio Grandi
22
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
• LIntegrazione e la Interoperabilita sono
  essenziali per CMS
• Es di Legnaro ?

23
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...

24
IMPALA/BOSSStress Test implementation
CE
SE
BOSS DB
RefDB
Job output filtering Runtime monitoring
RC
parameters
UI IMPALA
data registration
JDL
WN
JobExecuter dbUpdator
Write data
SE
GRID SERVICES
CE
SE
SE
By Alessandra Fanfani
25
Layout farm LNL 2002 production analysis
grid
grid enabled element
N24
N24
N1
N24
N1
N1
Productioncomputing nodes
Analysiscomputing nodes
FastEth
FastEth
FastEth
SWITCH
SWITCH
SWITCH
To WAN 34 Mbps 2001 1Gbps 2002
32 GigaEth 1000 BT
S12
GW
UI
S10
S11
G1
G2
S1
S9
Analysisservers
Productionservers
Production control
Remote login Analysis
Grid enabled Analysis
26
Verso il Computing di CMSData 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
  lANALISI 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
  lanalisi. 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

27
Verso il Computing di CMSData 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 (L0.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 lanalisi
• 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 (L0.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.

28
DC04 Two Phases

• Pre-Challenge (2003 Q3, Q4) (Must be successful)
• Large scale simulation and digitization
• 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) (Must be able to fail)
• Reconstruction at T0(CERN)
• Distribution to T1s
• Subsequent distribution to T2s
• 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

Introduce GRID tools As available and tested
Make full use of LCG-1 GRID. Test the
functionality they deliver
29
DC04 Setting the Scale

• 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 CPUs 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 _at_ 50SI95/CPU)
• Analysis at T1-T2s
• Design a set of tasks such that offsite
  requirement during challenge is about twice that
  of the T0

Pre-Challenge
Challenge
30
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)

31
Resource Needs vs Pledged 04
Q how many FTE are available for CMS production
at the RCs?
32
Risorse CMS Italia
tasca Computing 2003?
33
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!

34
Pool off the Grid
Collections
MySQL or RootIO Collection
User Application
File Catalog
XML / MySQL Catalog
RootI/O
Meta Data
MySQL
LCG POOL
Disconnected Laptop
By Vincenzo Innocente
35
Pool on the Grid
Collections
Grid Dataset Registry
User Application
File Catalog
Replica Location Service
Grid Resources
Replica Manager
RootI/O
Meta Data
Meta Data Catalog
LCG POOL
Grid Middleware
By Vincenzo Innocente