CSN1 27/11/06 - Istituto Nazionale di Fisica Nucleare

Computing LHCb
Umberto Marconi
CSN1, 27/11/2006
Sommario

Aggiornamenti sul Data Challenge 2006.

Nuovi piani di acquisizione delle risorse.


Considerazioni sul modello di analisi
distribuita.
Brevi annunci.
2
Obiettivi DC06
Collaudare il modello di calcolo dell’esperimento impiegando i servizi
LCG. Realizzazione delle seguenti fasi:





Simulazione con produzione dati RAW, impiegando tutte le risorse LCG
accessibili.
Ricostruzione presso i centri Tier-1 di LHCb, con produzione degli
eventi rDST, come se i dati provenissero dal rivelatore.
Selezione degli eventi rDST presso i centri Tier-1 con produzione degli
eventi DST utili all’analisi.
Il trasferimento dei dati interviene:

Nella distribuzione dei dati RAW dai siti di produzione MC al CERN.

Nella distribuzione dei dati RAW dal CERN a tutti i centri Tier-1.

Nella distribuzione degli eventi DST da ciascun centro Tier-1 ad almeno 3
centri Tier-1 (compreso il CERN) per la successiva fase di analisi.
I centri Tier-1 di LHCb che partecipano al DC06 sono:


CERN, CNAF, GridKa, IN2P3, NIKHEF, PIC, RAL
3
DC06 Simulazione MC
Produzione MC
CERN
Tier-0
DIGI (RAW)
CNAF
PIC
RAL
IN2P3
GRIDKA
Produzione MC
NIKHEF
Tier-1
Produzione MC
Tier-2


I dati RAW prodotti sono trasferiti e accumulati al CERN.
La procedura, totalmente automatizzata, funziona in modo
soddisfacente.
4
Contributi alla produzione MC per sito
Site
Events (%)
LCG.CERN.ch
19.17
LCG.CNAF.it
11.60
LCG.RAL.uk
7.59
LCG.Manchester.uk
7.54
LCG.NIKHEF.nl
7.34
LCG.LPC.fr
5.74
DIRAC.Lyon.fr
4.77
LCG.HG-06.gr
3.35
LCG.USC.es
2.93
LCG.Barcelona.es
2.49
LCG.RAL-HEP.uk
2.34
LCG.GRIDKA.de
1.62
LCG.PIC.es
1.48
Eventi (fondo)
b incl. low lumi(*)
7.4·107
b incl. high lumi
5.0·107
MB low luminosity
2.7·108
MB high luminosity
1.7·108
(*) low lumi: 2·1032 cm-2s-1
high lumi: 5·1032 cm-2s-1
prodotti utilizzando
circa 100 siti
5
DC06 Simulazione MC
Tutti i siti

Circa 5000 job di
simulazione attivi in
media, con picchi di
7000 job.
CNAF
CERN
RAL

Variabilità del numero dei job, a
causa della allocazione dinamica
delle risorse, operata dagli
scheduler che implementano
l’algoritmo di fair-share.
6
DC06 Ricostruzione
CERN
T0&T1
DIGI (RAW)
CNAF
PIC
RAL
IN2P3
T1
GRIDKA
NIKHEF
I dati RAW, precedentemente accumulati al CERN, sono distribuiti ai
Tier1, come se provenissero dal rivelatore in presa dati.



Se il trasferimento ad un sito Tier-1 avviene con successo, con copia su
tape e registrazione nei cataloghi, allora il software di LCHb (DIRAC) invia
automaticamente, presso il sito, i job di ricostruzione.
L’ouput di ogni job di ricostruzione (dati rDST) è mantenuto presso il sito,
per essere successivamente elaborato dagli algoritimi di pre-selezione e
analisi.
7
LHCb data flow
Detection (40 MHz)
60 MB/s RAW
Trigger (2 kHz)
RAW
Reconstruction
10 MB/s RAW
al CNAF
rDST
Stripping
DST, TAG
User Analysis
ntuple
8
Trasferimento dati per la ricostruzione
CERN-Ovunque
CERN-CNAF
9
Ricostruzione. Considerazioni


La ricostruzione richiede l’impiego del MSS per
l’accesso ai dati RAW in lettura.
L’accesso ai dati avviene mediante connessioni
remote.



I dati non sono copiati nel WN ove è in esecuzione il job di
ricostruzione.
Quando il job di ricostruzione arriva su un WN della
farm i dati RAW da elaborare sono già su disco.
I soli centri di calcolo che hanno utilizzato Castor2
in produzione, per il DC06, sono il CERN e il CNAF.

Le istallazioni di Castor2, nei due centri, sono differenti.
10
Ricostruzione. Risultati
Sito
Ricostruiti (106)
Ricostruiti (%)
RAL
17
24
CERN (*)
16
22.5
PIC
15
21
IN2P3
13
18
CNAF (*)
6
8.5
GridKA
3.8
5.4
(*) Castor2
Raggiunto il limite di 200 job di ricostruzione attivi
simultaneamente al CNAF
11
(dopo avere individuato un problema di configurazione di Castor).
Ricostruzione al CNAF. Stato di Castor2.

La situazione di Castor2 al CNAF, rispetto a quanto riferito alla
CSN1 a Settembre, è molto migliorata.

Castor2 può ora essere utilizzato, ma con limitazioni.

Sono necessari potenziamenti e configurazioni adeguate.




Castor2 non può gestire un numero di Castor-job (processi interni e
richieste esterne) arbitrariamente elevato, altrimenti si blocca. È un
problema intrinseco, che richiede una soluzione da parte degli
sviluppatori.
Per poter milgiorare la prestazioni di Castor è necessario comunque
aumentare il numero di disk-server per VO: È quanto è stato fatto al
CERN.
Per scoprire eventuali altri limiti dobbiamo sollecitando il sistema con
carichi sostenuti.
Un secondo MSS, oltrché funzionare da buffer, in caso di necessità,
allegerirebbe il lavoro di Castor, ampliando i margini di sicurezza.
12
DC06 Pre-selezione
CERN
T0&T1
DST
CNAF
PIC
RAL
IN2P3
GRIDKA
dati pre-selezionati DST distribuiti tra i vari T1
NIKHEF
T1
Quando sul sito sono presenti sufficienti quantità di dati
rDST, automaticamente sul sito Tier-1 viene inviato un job
di pre-selezione



I dati rDST sono analizzati dove prodotti.
L’output (DST) delle preselezione viene distribuito ai T1 in modo da
avere su “disco” 3 copie

Prime prove in corso di realizzazione.

Tecnicamente è una procedura analoga alla ricostruzione.
13
Analisi dati


Il software di gestione di LHCb, ideato per la gestione automatizzata
della produzione, della ricostruzione e della preselezione, può essere
utilizzato anche per l’analisi dati.
È sufficiente aggiungere un meccanismo di prioritizzazione
centralizzata, al quale stiamo già lavorando.


Vantaggi:

Impiego di un sistema collaudato.

Le risorse di calcolo sono usate in modo ottimale, sono utilizzate in modo
coordinato perché tutte collegate al sistema centrale.

Richiediamo una sola coda per sito che gestiamo automamente. La tracciabilità delle
attività è garantità. ll lavoro degli amministratori di sistema locali è semplificato.
Svantaggi:



Si ricorre alla centralizzazione delle richieste (single point of failure).
È possibile qualche forma di controllo da parte della collaborazione (la priorità del
job di analisi è definita in base al ruolo nell gruppo di analisi e in base dati ai
account.
Compromesso:

Fornire alla collaborazione risorse INFN per analisi, riservandone una parte ad
eslusivo uso dei connazionali.
14
Accesso indiretto alle risorse LCG
15
Tier1 e Tier2 al CNAF (TDR)
LHCb Computing TDR, CERN/LHCC 2005-019
Tier2
15% delle
risorse LHCb
al CNAF
Tier1
1/6 delle
risorse LHCb
al CNAF
16
Nuovo piano LHCb (totale collaborazione)
Tier1s
2007
2008
2009
2010
CPU (kSi2k)
710
1770
4870
6740
DISK (TB)
410
1025
2580
3250
TAPE (TB)
340
860
3070
5860
Tier2s
2007
2008
2009
2010
CPU (kSi2k)
1820
4550
11400
11400
DISK (TB)
10
10
30
30
TAPE (TB)
0
0
0
0
17
Avvisi (I)
A cura di:
P. Campana
U. Marconi
C. Matteuzzi
V. Vagnoni
Stato attuale
B-factories, Tevatron
Futuro prossimo
LHCb, ATLAS-CMS
Futuro
Super-LHCb, super-B
18
Conclusioni

DC06 di LHCb è stato condotto negli ultimi mesi con risultati
soddisfacenti.




La ricostruzione e la pre-selezione richiedono ancora lavoro di
adattamento e sperimentazione per la messa a punto.
L’analisi pensiamo possa essere convenientemente ricondotta al
problema precedente, mediante la priotitizzazione dei job
centralizzata. Altre soluzioni di accesso diretto alle risorse
nazionali sono possibili.
La collaborazione con il CNAF del gruppo di Bologna è sempre
molto stretta. LHCb continuerà a colladuare il sistema Castor2
al CNAF.


La produzione MC procede regolarmente.
Siamo interessati al collaudo della soluzione stoRM, basata su file
system paralleli GPFS, lavoro cui pensiamo di avviare a breve.
Siamo consapevoli della opportunità di contestualizzare il
programma di fisica di LHCb, avvalendoci del supporto dei
teorici e fenomelogi.
19