Calcolo per LHCb Italia Domenico Galli e Umberto Marconi Dipartimento di Fisica e INFN Bologna Napoli, 15 giugno 2000

Calcolo per LHCb Italia

Domenico Galli e Umberto Marconi

Dipartimento di Fisica e INFN Bologna

Napoli, 15 giugno 2000

Calcolo per LHCb ItaliaDomenico Galli e Umberto Marconi

Produzione di dati reali e Monte Carlo


Produzione di dati reali e Monte Carlo I RAW Tag contengono una classificazione degli eventi operata dal

codice del trigger di alto livello.

I RAWmc contengono anche la storia fisica dell’evento che viene tramandata fino agli AOD e che può essere usata nell’analisi. I dataset di eventi MC sono perciò più grandi di quelli reali.

La ricostruzione degli eventi RAW (100 TB/a reali + 200 TB/a MC) produce i dati ESD (100 TB/a reali + 100 TB/a MC) e TAG di ricostruzione.

Il CERN è il centro di produzione dei dati reali.

Centri di produzione dei dati Monte Carlo sono i centri periferici (RAL, Lyon, INFN, Liverpool, …) e non il CERN.

Potenza di calcolo richiesta in un centro di produzione Monte Carlo: 100000 SI95 (= 5000 CPU99).


Requisiti per la produzione di eventi Monte Carlo Segnale: numero di eventi simulati pari a 10 volte il numero di

eventi reali del medesimo canale (106 reali 107 MC).

Fondo bb: tanti eventi simulati quanti eventi reali registrati (109 reali 109 MC).

Tempo di CPU richiesto per segnale 3 1012 SI95 s.

Tempo di CPU richiesto per fondo (anticipando il più possibile i tagli e riciclando i dati di generazione): 1.2 1013 SI95 s.

Tempo di CPU totale produzione Monte Carlo: 1.5 1013 SI95 s.

Produzione entro un anno (3 107 s) ” potenza di CPU richiesta: 5 105 SI95 (25000 CPU99) distribuiti tra i centri regionali Tier-1.

1 CPU99 = 20 SPECint95


Tempo di CPU richiesto per la produzione di eventi Monte Carlo(107 eventi di segnale BD*)

eventi Tempo di CPU/evento Tempo totale di CPU

# [SI95 s/evt] [CPU99 s/evt] [SI95 s] [CPU99 s]

Generazione 1010 200 10 2 1012 1011

Tracciamento 109 1000 50 1012 5 1010

Digitalizzazione

109 100 5 1011 5 109

Triggering 109 100 5 1011 5 109

Ricostruzione 108 250 13 2.5 1010 109

Stati finali 107 20 1 2 108 107

Totale 1670 84 3 1012 1.5 1011



Tempo di CPU richiesto per la produzione di eventi Monte Carlo(109 eventi di fondo filtrati come BD*)

eventi Tempo di CPU/evento Tempo totale di CPU

# [SI95 s/evt] [CPU99 s/evt] [SI95 s] [CPU99 s]

Generazione 1012 200 10 2 1014 1013

Tracciamento 1011 1000 50 1014 5 1012

Digitalizzazione 1011 100 5 1013 5 1011

Triggering 1011 100 5 1013 5 1011

Ricostruzione 109 250 13 2.5 1011 1.3 1010

Totale 1650 83 3 1014 1.5 1013



Analisi di produzione


Analisi di produzione Ricostruzione stati finali: i dati ESD (tracce, cluster, particle id.)

sono analizzati per determinare i 4-impulsi corrispondenti alle tracce, per localizzare i vertici, per calcolare le masse invarianti e per identificare le risonanze (J/, 0, ecc.). Eseguita una sola volta per tutti i tipi di analisi utente nel centro di produzione. Richiesti 2000 SI95 (100 CPU99).

Individuazione dell’analisi appropriata per il singolo evento sulla base dei TAG di ricostruzione: più di un algoritmo di analisi può essere eseguito per il singolo evento, in quanto può essere soddisfatta più di una delle condizioni richieste sui TAG di ricostruzione (p. es.: 2 muoni, 2 adroni, ecc.).

Il risultato sono gli AOD (20 TB/a reali) e i TAG di analisi (1 TB/a reali).

Soltanto AOD e TAG di analisi vengono esportati sistematicamente dai centri di produzione ai centri di analisi (a differenza di altri esperimenti LHC).


Analisi utente


Analisi utente

Gli AOD che corrispondono a eventi con TAG di analisi di interesse (selezione) vengono processati e viene ricostruito il canale di decadimento del B in studio.

Questo processo produce dati privati (n-ple) che possono essere interrogati interattivamente per produrre risultati fisici.

Poiché il numero di canali in studio è molto alto, si può supporre che ogni fisico esegua un’analisi separata su di un canale specifico (non esistono gruppi di analisi come in altri esperimenti LHC).

Potenza di calcolo richiesta: 10000 SI95 (=500 CPU99) nei centri regionali e 20000 SI95 (=1000 CPU99) al CERN.


Differenze rispetto al modello MONARC L’architettura di base del modello di calcolo di LHCb corrisponde al

modello MONARC. Tuttavia alcuni dettagli distinguono LHCb dai maggiori esperimenti LHC:

Il numero di canali di analisi in studio è molto grande e si presume che i fisici lavorino in maniera molto indipendente sui diversi canali di analisi. Non vengono identificati gruppi di analisi.

Il primo stadio dell’analisi è eseguito in comune per tutte le analisi che seguono nei centri di produzione. I centri di produzione esportano sistematicamente soltanto AOD e TAG (vengono distribuiti piccoli campioni di RAW ed ESD soltanto su richiesta).

Non vi è una netta distinzione tra Tier1 e Tier2. Il trasferimento di dati è tale da potere essere realizzato esclusivamente

su WAN. Il CERN agisce soltanto come centro di produzione di dati reali. I dati

Monte Carlo vengono prodotti esclusivamente nei centri di produzione periferici (RAL, Lyon, INFN, …).


Server dipartimental

e


e


e

Centro regionale

Il movimento dei dati

Centro regionale

Centro regionale

Centro regionale

Centro regionale

Centro di produzion

eAOD e TAG sistematicamente

Reali: 80 TB/aMonte Carlo: 120 TB/a

AOD e TAG su richiestaReali:10 TB/a

Monte Carlo: 30 TB/a

Dati reali: CERN

Dati Monte Carlo: RAL, Lyon, INFN, …


Ruolo del middleware di GridScenario 1: analisi dati reali Un fisico di Ferrara vuole analizzare la reazione B0

JK0s.

Gli AOD e i TAG per tutti i 109 eventi prodotti in un anno sono distribuiti sistematicamente dal CERN a tutti i Tier-1 (tra cui il Tier-1 INFN).

Le procedure di selezione sono eseguite al Tier-1 INFN e identificano 107 candidati di interesse in base ai TAG.

Gli AOD e i TAG corrispondenti ai 107 eventi selezionati (200 GB AOD + 10 GB TAG) sono copiati dal Tier-1 INFN al Tier-3 di Ferrara (alcune ore su WAN).

I job di analisi utente sono eseguiti sul Tier-3 di Ferrara più volte sugli eventi selezionati.

Evitare copie multiple degli stessi data set (diversi fisici eseguono analisi diverse sugli stessi dati). Il software di data caching & replication, in maniera trasparente per l’utente, deve gestire un database dei TAG per tenere traccia degli eventi disponibili localmente.


Ruolo del middleware di GridScenario 2: analisi dati reali (canale molto popolato)

Un fisico di Ferrara vuole analizzare la reazione B0 D*.

È simile allo scenario 1.

In questo caso gli AOD selezionati (108 eventi, 2 TB) sono più grandi di un ordine di grandezza rispetto al caso precedente e non possono essere trasferiti su WAN in tempi ragionevoli.

L’analisi utente sarà eseguita presso un Tier-1 (possibilmente con load balancing), invece che al Tier-3 di Ferrara.

Spostamento dei job verso i dati invece di spostamento dei dati verso le macchine.


Ruolo del middleware di GridScenario 3: analisi fondo simulato

Un fisico di Cagliari vuole analizzare la reazione B0 JK0s

sugli eventi di fondo bb generati a Lyon. I 109 eventi (12 TB GEN, 200 TB RAW, 100 TB ESD, 20 TB AOD, 1 TB

TAG) sono archiviati a Lyon (centro di produzione). Gli AOD, i GEN e i TAG per tutti i 109 eventi prodotti (33 TB) sono distribuiti

sistematicamente da Lyon a tutti i Tier-1 (tra cui il Tier-1 INFN). Il fisico esegue al Tier-1 INFN il job di selezione che controlla i TAG e

identifica i candidati di interesse (circa 105 eventi). I 105 eventi di interesse (3.3 GB di AOD, TAG e GEN) sono copiati dal Tier-1

INFN al Tier-3 di Cagliari attraverso la WAN. I job di analisi utente sono eseguiti sul Tier-3 di Cagliari più volte sugli

eventi selezionati. Il software di data caching & replication, in maniera trasparente per

l’utente, deve gestire un database dei TAG per tenere traccia degli eventi disponibili localmente ed evitare copie multiple degli stessi data set.


Ruolo del middleware di Grid. Compiti Distribuzione sistematica AOD, TAG e GEN (per i dati MC) dai centri di

produzione (CERN per dati reali, RAL + Lyon + INFN + Liverpool + … per dati Monte Carlo) a tutti i centri regionali Tier-1: CERN + RAL + Lyon + INFN + Liverpool + … (200 TB/a).

Distribuzione selezione AOD (basata su TAG) da un centro regionale Tier-1 al server dipartimentale (Tier-3) che ne fa richiesta (per 107 eventi: 200 GB AOD e 10 GB TAG in alcune ore).

Aggiornamento di un database dei TAG per tenere traccia dei dati disponibili localmente nei Tier-3 onde evitare trasferimenti multipli degli stessi data set.

Distribuzione campioni ESD dai centri di produzione al Tier-3 che ne fa richiesta (per 105 eventi: 10 GB).

Distribuzione campioni RAW dai centri di produzione al Tier-3 che ne fa richiesta (per 100 eventi: 100 MB).

Per analisi su grandi campioni di eventi (BD*) spostamento dei job verso i dati (centri regionali Tier-1) e load balancing sui Tier-1.

Distribuzione del database delle calibrazioni.


Piano di produzione di eventi Monte Carlo dal 2000 al 2005

La collaborazione LHCb intende avviare immediatamente la produzione Monte Carlo, che richiede una potenza di calcolo notevole. Necessariamente il piano di sviluppo del sistema di calcolo segue perciò uno schema bottom-up (che parte dalle esigenze a breve termine).

2000-2001: produzione di ~3 106 evt/a simulati per l’ottimizzazione dei rivelatori e del trigger di primo livello, in preparazione dei TDR del rivelatore, attesi nel 2001 e all’inizio del 2002);

2002-2003: studi degli algoritmi del trigger di alto livello (~6106 evt/a);

2004-2005: produzione di grandi campioni di eventi di fondo (~107 evt/a).

L’attività di produzione di eventi Monte Carlo verrà utilizzata per collaudare l’infrastruttura di calcolo.


Piano di test su grande scala del modello di calcolo (Data Challenge) Dal 2002 al 2004 dovranno essere eseguiti i test per

convalidare il modello di calcolo di LHCb; 2002: DC 1 – verifica del middleware di grid e del software di

amministrazione della farm, utilizzando una simulazione reale e l’analisi di 107 eventi di decadimento del B. Parteciperanno: CERN, RAL, Lione/CCIN2P3, Liverpool, INFN.

Scritture di dati RAW e ESD su disco da parte di molti processi MC simultanei.

Accesso simultaneo al database di calibrazione da parte di molteplici job di ricostruzione.

2003: DC 2 – test del prototipo di grande scala di Tier-0 al CERN.

Amministrazione del sistema e delle applicazioni. Analisi: studio di accessi ai dati di tipo caotico. Prove di sforzo del modello dei dati e degli algoritmi


Requisiti globali dei centri Tier-1 di LHCb

Unità 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Eventi segnale a-1 106 106 2106 3106 5106 107

Eventi fondoa-1 106 1.51

06 2106 4106 107 109

CPU segnale SI95 104 104 2104 3104 5104 105

CPU fondoSI95

1.6104

2.4104

3.2104

6.4104 1.6105 4104

CPU analisi SI95 2500 2500 5000 7500 1.3104 2.5104

RAWmc disco TB 0.4 0.5 0.8 1.4 3 202

RAWmc nastroTB 0.4 0.5 0.8 1.4 3 202 404 606 808 1010

1212

ESDmc disco TB 0.2 0.25 0.4 0.7 1.5 101

AOD disco TB 0.06 0.1 0.1 0.3 0.5 50

TAG disco TB 0 0 0 0.01 0.015 2


Requisiti globali dei centri Tier-1 di LHCb

0

1000

2000

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Disco

Nastro

0

500000

1000000

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

CPU

SI95

TB


Piano di acquisti per un centro regionale Tier-1 di LHCb (valori incrementali)

Risorse divise tra 5 centri regionali.

Nel funzionamento a regime (a partire dal 2006) sostituzione ogni anno di 30% CPU e 20% dischi.

Unità 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

CPU SI95 5700 1600 4100 8900 24200 60500 31500

Disco TB 0.18 0.07 0.09 0.38 0.69 111.2 22.4

Nastro TB 0.08 0.02 0.06 0.12 0.32 39.8 40.4


Il Tier-1 INFN di LHCb LHCb-Italia intende adeguarsi alla pianificazione della

collaborazione entro la fine del 2001.

LHCb-Italia intende concentrare il Tier-1 in un unico sito, alloggiato in un “consorzio di calcolo”, scelto in base alla convenienza economica con una gara d’appalto.

Una sola istallazione. Architettura analoga agli altri Tier-1 europei. Assenza dei problemi connessi all’utilizzo della WAN (routing,

ottimizzazione dei trasferimenti per ovviare ai limiti della banda, ecc.).

Assenza di particolari esigenze di organizzazione e sincronizzazione.

Il controllo remoto delle risorse richiede meno bandwidth di quanta non ne richieda la distribuzione geografica di dati e CPU.

L’utilizzazione remota delle risorse di calcolo concentrate potrà essere trasparente per l’utente grazie al software di griglia.


Il Tier-1 INFN di LHCb (II)

Il consorzio si occupa dell’alloggiamento delle risorse di calcolo:

allacciamenti; condizionamento; continuità; custodia.

Al consorzio si intende dare in outsourcing il lavoro sistemistico:

partecipazione all’istallazione del sistema; gestione e monitoraggio; intervento in caso di hang; intervento per il ripristino della connettività LAN o WAN; procedure di backup; aggiornamento e patch del sistema operativo.


Piano di investimenti di LHCb-Italia

Unità 2001 2002 2003

CPU [kE] 316 110 150

Switch [kE] 24 6 6

Rack [kE] 20 10 10

Disco [kE] 5.5 1.2 3.9

Nastro [kE] 0.11 0.03 0.04

Lettori nastro [kE] 4 0 0

Totale hardware [kE] 370 127 170

Numero CPU # 158 213 288

Energia elettrica [kE] 33 45 61

Alloggiamento [kE] 20 25 32

Personale sistemistico [kE] 55 60 67

Totale spese generali [kE] 108 130 160

Gran totale [kE] 478 257 330


Gruppo nazionale computing di LHCb

Sezione Test-bedHEP

applications

DATAGRID Totale

Maurizio Bonesini MI 10% - - 10%Walter Bonivento CA 20% - - 20%Domenico Galli BO 50% - 30% 80%Alberto Gianoli FE 50% - - 50%Umberto Marconi BO 50% - 30% 80%Marco Paganoni MI 20% - - 20%Roberta Santacesaria

RM1 - 20% - 20%

Nicola Semprini Cesari

BO - 10% - 10%

Vincenzo Vagnoni BO 40% 20% - 60%Stefania Vecchi BO - 50% - 50%Totale 240% 100% 60% 400%

Documents

Calcolo per LHCb Italia Domenico Galli e Umberto Marconi Dipartimento di Fisica e INFN Bologna Napoli, 15 giugno 2000