P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica &...

P.Capiluppi PadovaLuglio 1999

Il “Computing” di CMS ad Il “Computing” di CMS ad LHCLHC

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

2

PadovaLuglio 1999LHC Experiments

ATLAS, CMS, ALICE, LHCbATLAS, CMS, ALICE, LHCb

Higgs and New particles; Quark-Gluon Plasma; CP ViolationHiggs and New particles; Quark-Gluon Plasma; CP Violation

P.Capiluppi

3

PadovaLuglio 1999

I termini del problemaI 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) unSUBDETECTOR

P.Capiluppi

4

PadovaLuglio 1999

Geographical dispersion:Geographical dispersion: of people and resources of people and resources Complexity:Complexity: the detector and the LHC environment the detector and the LHC environment Scale:Scale: Petabytes per year of data Petabytes per year of data

1750 Physicists 150 Institutes 32 Countries

Major challenges associated with:Major challenges associated with:Communication and collaboration at a distanceCommunication and collaboration at a distance

Distributed computing resources Distributed computing resources Remote software development and physics analysisRemote software development and physics analysis

R&D: New Forms of Distributed SystemsR&D: New Forms of Distributed Systems

LHC Computing Challenges

P.Capiluppi

5

PadovaLuglio 1999

Events:Events:Bunch crossing time of 25 ns is so short that (parts of) Bunch crossing time of 25 ns is so short that (parts of)

events from different crossings overlapevents from different crossings overlapSignal event is obscured by 20 overlapping uninteresting Signal event is obscured by 20 overlapping uninteresting

collisions in same crossingcollisions in same crossing

Challenges: Complexity

P.Capiluppi

6

PadovaLuglio 1999

Data Rateto Storage

Data VolumeStored Annually

LANBandwidth

CPUPower

3-10 2-10 10-30 10-30

Growth Rates Per Five Years*Growth Rates Per Five Years*

Major Experiment Bandwidth RequirementsMajor Experiment Bandwidth Requirements For the next generation of experiments: For the next generation of experiments: ~100 ~100 times greater than in 1999times greater than in 1999

~1000 times increase in the next decade~1000 times increase in the next decade

Similar to the 1000- fold increase of the last ten years Similar to the 1000- fold increase of the last ten years

* * The largest experiments tend to be at the The largest experiments tend to be at the upper end of this rangeupper end of this range

HEP Bandwidth Growth Rates

P.Capiluppi

7

PadovaLuglio 1999

LHC Challenges: Scale

Data written to tapeData written to tape ~5 Petabytes/Year and UP ~5 Petabytes/Year and UP (1 PB = 10 (1 PB = 1099 MBytes) MBytes)

Processing capacityProcessing capacity 100 - TIPS and UP 100 - TIPS and UP (1 TIPS = 10 (1 TIPS = 1066 MIPS) MIPS)

Typical networks Typical networks 0.5 - Few Gbps Per Link 0.5 - Few Gbps Per Link

Lifetime of experimentLifetime of experiment 2-3 Decades 2-3 Decades

Users Users ~ 5000 physicists ~ 5000 physicists

Software developers ~ 300 (Four Experiments)Software developers ~ 300 (Four Experiments) 0.1 to 1 Exabyte (100.1 to 1 Exabyte (101818 Bytes) Bytes)

(~2010) (~2020 ?) (~2010) (~2020 ?)

Total for the LHCTotal for the LHC

P.Capiluppi

8

PadovaLuglio 1999

Le Le DimensioniDimensioni del Computing ad LHC del Computing ad LHC

• 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

P.Capiluppi

9

PadovaLuglio 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)

P.Capiluppi

10

PadovaLuglio 1999

Un possibile Processo di Analisi (1998!!!)

Physics analysis CMS 2x105 SPECint951) 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 eventsevery day to create the Analysis Objects with a reductionfactor 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

P.Capiluppi

11

PadovaLuglio 1999

Attivita’ e Persone (1)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!

P.Capiluppi

12

PadovaLuglio 1999


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 sviluppatoresviluppatore sul Desktop (anche H323?!)garantiti! [distributed collaborative tools]

P.Capiluppi

13

PadovaLuglio 1999

Core Software Milestones (L2)

Proof ofConcept

FunctionalPrototype

FullyFunctional

ProductionSystem

GEANT4Simulation ofCMS

June 1998 Dec 1999 June 2001 Dec 2003

Reconstruction/AnalysisFramework

June 1998 Dec 1999 Dec 2001 Dec 2003

DetectorReconstruction Dec 1998 Dec 1999 June 2002 June 2004

Physics ObjectReconstruction Mar 1999 June 2000 Dec 2002 Dec 2004

User AnalysisEnvironment Dec 1998 June 2000 Dec 2002 Dec 2004

P.Capiluppi

14

PadovaLuglio 1999

Database Milestones (L2)

Use of DBMS for testbeam Dec 1997

Event storage/retrieval ODBMS June 98, Dec/99, Dec/01, Dec/03

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

Functional prototype

P.Capiluppi

15

PadovaLuglio 1999


Sviluppo Software 2: Attivita’ “centrali” (CORE Software)(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

P.Capiluppi

16

PadovaLuglio 1999

Reconstruction PRO ject M anagem ent

R.W ilkinsonDeputy

Object Persistancy

L.SilvestrisDeputy

Testbeam s

V.InnocenteArchitect

V.InnocenteFram ew ork

V.InnocenteUtilities

T.CoxM uon endcap

A.VitelliM uon barrel

F.BehnerCalorim etry

L.TaylorVisualization

E.M eschiTrigger

L.SilvestrisTestbeam

C.SeezElectron PG

U.GaspariniM uon PG

T.TodorovTracker

S.W ynhoffExam ples

S.EnoJet PG

A.Canerb/tau PG

Sub-System Coordinators

C.W illiam sLibrarian

H-P.W ellischSW Process M anager

D.SticklandProject Manager


6-7 persone coinvolte (staff e non) in queste attivita’, 6-7 persone coinvolte (staff e non) in queste attivita’, spesso non a pieno tempo(FTEs): occorrono persone!spesso non a pieno tempo(FTEs): occorrono persone!

P.Capiluppi

17

PadovaLuglio 1999


Filter WBS for only the professional software personnel

CMS Software Professional Personnel Requirements

0

5

10

15

20

25

30

35

40

1998 1999 2000 2001 2002 2003 2004 2005 2006

Year

So

ftw

are

Pro

fessio

nals

(F

TE

's)

CMS WBS (May 1999)

CMS WBS (Nov 1998)

CMS (actual)

0

40

80

120

160

200

1998 2000 2002 2004 2006

Year

Pe

rso

nn

el (

FT

E's

)

CMS Software Professionals

CMS Physicist Developers(projected)

CMS Physicist Developers(Actual)

Shortfall: 7 FTE’s

P.Capiluppi

18

PadovaLuglio 1999


Professional Manpower CMS Core Computing

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

Years

FT

Es

Computing Professionals

INFN (13%)

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

1999 2000 2001 2002 2003 2004 2005

P.Capiluppi

19

PadovaLuglio 1999


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)

P.Capiluppi

20

PadovaLuglio 1999


Simulazioni per lo studio dei Trigger e dei Processi Fisici identificabili

Working Groups: Muon, b-tau, electron, jetsWorking 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 produzioneproduzione di CMS

P.Capiluppi

21

PadovaLuglio 1999


Simulazioni per lo studio dei Trigger e dei Processi Fisici identificabili

Working Groups: Muon, b-tau, electron, jetsWorking 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)

P.Capiluppi

22

PadovaLuglio 1999

Just to be clear ----Just to be clear ----

AIXWNTIrix

Sola

ris

Digital Unix

HP-

UX

MAC-

OS

Linu

x

Windows

95

SPARC

MIPS Inte

l IA-3

2

PA-RISCPower

PC

Alpha LinuxWindows 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

P.Capiluppi

23

PadovaLuglio 1999


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!]

P.Capiluppi

24

PadovaLuglio 1999

CMS MILESTONESCORE SOFTWAREEnd of Fortran developmentGEANT4 simulation of CMS 1 2 3 4Reconstruction/analysis framework 1 2 3 4Detector reconstruction 1 2 3 4Physics object reconstruction 1 2 3 4

User analysis environment 1 2 3 4DATABASEUse of ODBMS for test-beamEvent storage/retrieval from ODBMS 1 2 3 4Data organisation/access strategyFilling ODBMS at 100 MB/sSimulation of data access patternsIntegration of ODBMS and MSSChoice of vendor for ODBMSInstallation of ODBMS and MSS

1 Proof of concept 3 Fully functional

2 Functional prototype 4 Production system

Dec-00Dec-01

Dec-02

Dec-03Dec-98

Jun-99Dec-00

Dec-97Jun-98 Dec-99 Dec-01

Dec-98 Jun-00 Dec-02 Dec-04Mar-99 Jun-00 Dec-02 Dec-04

Dec-98 Dec-99 Jun-02 Jun-04

Jun-98 Dec-99 Dec-01 Dec-03

2005

Jun-98Jun-98 Dec-99 Jun-01 Dec-03

2001 2002 2003 20041998 1999 2000

June 1999


P.Capiluppi

25

PadovaLuglio 1999

Supporto Necessario (1)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.

P.Capiluppi

26

PadovaLuglio 1999


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

P.Capiluppi

27

PadovaLuglio 1999


Servizi di “alto”“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”“dinamico” dai Servizi: AFS/DFS, NT, Linux, Unix specifico, DNS, WAN, Security, Backup, Mail, Licnze, Web, Videoconferenze, Installazioni, LAN, ….

• Manualistica e DocumentazioneManualistica e Documentazione.

P.Capiluppi

28

PadovaLuglio 1999


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?, ...

P.Capiluppi

29

PadovaLuglio 1999

Computing Off-line al CERN (1)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?

P.Capiluppi

30

PadovaLuglio 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

P.Capiluppi

31

PadovaLuglio 1999


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

P.Capiluppi

32

PadovaLuglio 1999

• Rough Sizing Estimates for a Large LHC Experiment Facility

Year 2004 2005 2006 2007

Total cpu (SI95) 70’000 350’000 520’000 700’000

Disks (TB) 40 240 540 740

LAN throughput(GB/sec)

6 31 46 61

Tapes (PB) 0.2 1 3 5

Tape I/O(GB/sec)

0.2 0.3 0.5 0.5

Approx boxcount

250 900 1400 1900


P.Capiluppi

33

PadovaLuglio 1999

Comparison with LHC sized experiment

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) ~1400CDF - 2 12,000 20 800 1 Gb/s 18 MB/s ~250D0 - 2 7,000 20 600 300 Mb/s 10 MB/s ~250

Babar ~6000 8 ~300

Mix of Gb/sec, 100 Mb/sec Ethernet to

servers ~400 GB/day ~400 D0 295 1.5 65 300 Mb/s ? 180CDF 280 2 100 100 Mb/s ~100 GB/day ?ALEPH 300 1.8 30 1 Gb/s ? 70DELPHI 515 1.2 60 1 Gb/s ? 80L3 625 2 40 1 Gb/s ? 160OPAL 835 1.6 22 1 Gb/s ? 220NA45 587 1.3 2 1 Gb/s 5 GB/day 30

P.Capiluppi

34

PadovaLuglio 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?)

P.Capiluppi

35

PadovaLuglio 1999


CMS Computing Common Fund

0.00

100.00

200.00

300.00

400.00

500.00

600.00

700.00

800.00

Years

KC

HF File servers

Information Servers

Computing Pow er

Spares

System Assembly

SW Licences

SystemManagementINFN

TotalFile 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

1998 1999 2000 2001 2002 2003 2004 2005

P.Capiluppi

36

PadovaLuglio 1999

Modello di Computing: Monarc CMS (1)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.

P.Capiluppi

37

PadovaLuglio 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/

P.Capiluppi

38

PadovaLuglio 1999MONARC

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 Model’s

performance: throughputs, latenciesDevelop “Baseline Models” in the

“feasible” categoryVerify 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

Mbi

ts/s 622 M

bits/s

Desktops

CERN6.107 MIPS2000 Tbyte

Robot

Universityn.106MIPS100 Tbyte

Robot

FNAL4.106 MIPS200 Tbyte

Robot

622

Mbi

ts/s

622

Mbi

ts/s

622Mbits/s

622 Mbits/s

Desktops

Desktops

Model Circa 2006Model Circa 2006

P.Capiluppi

39

PadovaLuglio 1999MONARC

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 handlingresources likely to be available at LHC startup

• Computing power and transport speeds neededfor an effective data analysis

• Features, performance of the distributed database system• Strategy for data distribution, processing and analysis

P.Capiluppi

40

PadovaLuglio 1999MONARC 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 eachworld region, in the data analysis and the physics

P.Capiluppi

41

PadovaLuglio 1999MONARC 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

P.Capiluppi

42

PadovaLuglio 1999MONARC 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)

P.Capiluppi

43

PadovaLuglio 1999


• Il progetto nella prima fase e’ stato organizzato in 4 Working Groups: Simulation, Analysis Design, Architecture, Test bed.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 Distributed ComputingComputing di portata e complessita’ senza precedenti (anche per gli “Informatici”).

– [Terzo pilastro!: occorre fare uso il piu’ possibile della realta’ della commoditycommodity (budget and availability)]

P.Capiluppi

44

PadovaLuglio 1999


• Monarc e’ una Collaborazione “Italo-Americana”, non a caso, anche se con diverse tradizioni e organizzazione sono i “maggiori investitori” in LHC.

• Il Modello diAnalisiModello diAnalisi sembra tradizionale, ma non lo e’! Forte gerarchia e tentativo di liberta’ nelle fasi finali.

P.Capiluppi

45

PadovaLuglio 1999MONARC Analysis Design

Working Group

DAQ--------------

RawSlow 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

TriggerInfo

x n WG

x n Users in the WG

1st time at CERN(then at RC? ==> Parameters?

Different WGat different site?==> Parameters?

RC or Desktop?==> Parameters?

4 times per Year?(per Exp.)

Onceper Month?(per WG)

4 timesper Day?(per User)

Raw Data : On Tape, at CERN and at RCESD/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 DiskSelected AOD/Anal. Obj : On DiskTAG DB : On Disk

Analysis Process

P.Capiluppi

46

PadovaLuglio 1999MONARC Analysis Design

Working Group

Data ModelRawData

Slow controlCalibration data

Trigger TagSimulation

Data

Reconstruction

ESD/Rec.Obj.Data

TagData

Selection

Anal.Obj.Data

AOD (2 steps)Data

1 PB/Year +0.001 PB/Year? +~0.5 PB/Year?

Input of

Analysis

Local DBand/or

Histograms

Input of

Input of

1.1 PB/Year +100 GB/Year or0.1 PB/Year +100 GB/year

CMS

ATLAS

Off-Line Farm(and “other” resources

for Simulation)

RCs (including CERN)

0.2 TB/Year x 2using TAG CMS

20 TB/Year x 2using TAG

2 TB/Year x 2using TAG

ATLAS pass1ATLAS pass2

RC (including CERN)and/or Desktops

Huge amount of Data!But negligible for Users(if DB is out of Global Objy DB)

P.Capiluppi

47

PadovaLuglio 1999

PARAMETER VALUE RANGE

Frequency 4/ Year 2-6/ YearInput Data 1 PB 0.5-2 PBCPU/event 350 SI95.Sec 250-500 SI95.SecData Input Storage Tape (HPSS?) Disk-TapeOutput Data 0.1 PB 0.05-0.2 PBData Output Storage Disk Disk-TapeTriggered by Collaboration 1/2 Collab. - 1/2

Anal. WGsData InputResidence

CERN CERN + some RC

Data OutputResidence

CERN + someRC

CERN + RCs

Time response 1 Month 10 Days - 2 MonthsPriority (if possible) High -


P.Capiluppi

48

PadovaLuglio 1999


• La simulazione e’ stata sviluppata al CERN con contributo CERN, Caltech, KEK (da una sola persona, di fatto, Iosif Legrand)

P.Capiluppi

49

PadovaLuglio 1999


• Attualmente piu’ rilevanti ed urgentiurgenti per l’INFN le prospettive dell’ArchitetturaArchitettura e dei Test bedTest bed.– Necessari per capire come arrivare alle milestones del Database e delle Risorse

di Computing [Centri Regionali in particolare]

– Milestones hardware CMS

P.Capiluppi

50

PadovaLuglio 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!E’ il nuovo modo di Distributed Computing che HEP puo’ creare!]

– Puo’ essere l’inizio di un Centro Regionale (non troppo) distribuitoCentro 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!Fase 3 di Monarc e Panda!

P.Capiluppi

51

PadovaLuglio 1999MONARC Testbeds WG (2)

P.Capiluppi

52

PadovaLuglio 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 RegionaliCentri 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 ServicesTechnical Services e tutti i Data Data ServicesServices 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 decisadecisa:• Presso i Consorzi di Calcolo: opzione ad oggi scartata.

• Un Centro Regionale Distribuito presso le maggiorimaggiori Sezioni di CMS.

• Un Centro con una base maggiorebase maggiore in un sito (eventualmente per tutto LHC?) e concentrazioni secondarie (Tier2?) presso le maggiorimaggiori Sezioni di CMS.

• Un Centro completamente distribuito in tutte le Sezioni di CMS.

Cos’e’ meglio?Cos’e’ meglio?

P.Capiluppi

53

PadovaLuglio 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 Il Centro Regionale Italiano di CMS puo’ essere condiviso con gli altri Esperimenti ad LHC?Esperimenti ad LHC?

P.Capiluppi

54

PadovaLuglio 1999


John WomersleyMarch 1999

Scope of the Tier 1 Regional Centre

• Taken from Les Robertson’s presentation to MONARChttp://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

P.Capiluppi

55

PadovaLuglio 1999



Cost estimation

• Costs de-escalated at CMS rates (Ian Willers, Feb 99)

• Actual costs for cpu and disk are higher than CMS has assumedand 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 useof expensive SMP machines in Run II vs. commodity priceestimates

• 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

P.Capiluppi

56

PadovaLuglio 1999



Scope buildup 2003-6

• So that costs are roughly equal in 2003, 2004 and 2005acquire 10% of disk and CPU in 2003, 30% in 2004, 60% in 2005

2003 2004 2005 2006

– CPU: 0.4 1.44 3.6 4.8 TIPS

– disk: 11 43 108 148 GB

– tape: 0.03 0.05 0.4 0.6 PB

– robots: 1 0.33 robots

P.Capiluppi

57

PadovaLuglio 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 thehardware costs. $7M to implement seems low to me based onwhat 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?


P.Capiluppi

58

PadovaLuglio 1999


• Monarc dara’ delle indicazioni, non la soluzionesoluzione o la sceltascelta 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!

P.Capiluppi

59

PadovaLuglio 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 experimentsand 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 computingfor 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

P.Capiluppi

60

PadovaLuglio 1999MONARC Phase 3

Possible Technical Goal: System OptimisationMaximise Throughput and/or Reduce Long Turnaround

• Include long and potentially complex decision-processesin 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.

P.Capiluppi

61

PadovaLuglio 1999

Risorse (1)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

P.Capiluppi

62

PadovaLuglio 1999

Risorse (3)Risorse (3)

Man PowerMan PowerFte attualiFte attuali

Simulazione/ricostruzioneSimulazione/ricostruzione ~15~15SviluppoSviluppo ~10~10Core softwareCore software ~2~2Analisi Testbeam e detectorAnalisi Testbeam e detector ~8~8Monarc (Centro Regionale)Monarc (Centro Regionale) ~4~4

~39 Totali~39 Totali

RichiesteRichieste 19991999 20002000 20012001 >=2002>=2002

Physiscist computingPhysiscist computing 22 55 66 8? 8?

ComputingComputing 11 22 55 7? 7?

SystemSystem 55 66 77 7? 7?

TotaleTotale 88 1313 1818 22 + RC! 22 + RC!

P.Capiluppi

63

PadovaLuglio 1999

Software and Computing Reviews `99

• (LHCC referees review in summer)(LHCC referees review in summer) (positive rev. in January)(positive rev. in January)

• Internal CMS review of SW&C project:Internal CMS review of SW&C project:– CERN October 25CERN October 25

• LCB Workshop LCB Workshop – Marseilles Sept 29 - Oct 1Marseilles Sept 29 - Oct 1

• Technical Progress Report (Update of CTP)Technical Progress Report (Update of CTP)– End of 1999 End of 1999

• Computing Conceptual Review from September 1999 --> Computing Conceptual Review from September 1999 --> Spring 2000 at CERN (Spring 2000 at CERN (including TPRs)

P.Capiluppi

64

PadovaLuglio 1999

ConclusioniConclusioni

• 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 formazionesperimentazione 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 Teoricistanno preparando un documento INFN per il Calcolo futuro!(1999)

Occorre fare un salto di almeno un ordine di grandezza,Occorre fare un salto di almeno un ordine di grandezza,SU TUTTO!SU TUTTO!

P.Capiluppi

65

PadovaLuglio 1999

Cost Evolution

P.Capiluppi

66

PadovaLuglio 1999US 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

P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica &...

Documents

Transcript of P.CapiluppiPadova Luglio 1999 Il Computing di CMS ad LHC Paolo Capiluppi CMS - Dip. di Fisica &...