Diapositiva 1

Il Computing di ATLAS
(aspetti interessanti per chi fa analisi)
Tommaso Lari
INFN Milano
Tutorial sull’analisi
distribuita
Roma3, 20-21 Febbraio 2008
Il Computing Model di ATLAS
Il modello di calcolo per l’offline e l’analisi di ATLAS è quello
gerarchico multi-Tier.
Modello a cloud: ad ogni Tier-1 sono associati alcuni (3 o 4) Tier-2
spesso in base a considerazioni geografiche.
Tier-0 (CERN)
~PB/s
Event Builder
10 GB/s
Event Filter
• Archivio dei RAW data e distribuzione ai Tier1
• Prompt Reconstruction dei dati in 48 ore
• 1st pass calibration in 24 ore
• Distribuzione output ricostruzione ai Tier-1: ESD, AOD e TAG
Tier-1 (10)
320 MB/s
Tier0
~ 150 MB/s
Tier1
~10
~50 Mb/s
Tier2
~34/Tier1
• Accesso a lungo termine e archivio di un subset di RAW data
• Copia dei RAW data di un altro Tier-1
• Reprocessing della ricostruzione dei propri RAW data con parametri
di calibrazioni e allineamenti finali 2 mesi dopo la presa dati
• Distribuzione AOD ai Tier-2
• Archivio dati MC prodotti nei Tier-2
• Analisi dei gruppi di fisica
Tier3
• Simulazione Monte Carlo
• Analisi utenti
Roma, 20-21 Febbraio 2008
Tier-2
T. Lari: Analisi distribuita
2
Event Data Model: tipi di dati
Nelle varie fasi di ricostruzione e analisi ATLAS utilizza diversi formati di dati:
1.6 MB
target
500 KB
attualmente
900 kB
target
100 kB
attualmente
300 kB
10% di AOD
Roma, 20-21 Febbraio 2008
RAW
Raw Data: dati in output dal sistema di trigger in
formato byte-stream
ESD
Event Summary Data: output della ricostruzione
(tracce e hit, celle e cluster nei calorimetri,
combined reconstruction objects etc...).
Per calibrazione, allineamento, refitting …
AOD
Analysis Object Data: rappresentazione ridotta
degli eventi per l’analisi: oggetti “fisici” ricostruiti
(elettroni, muoni, jet, missing Et ...)
DPD
Derived Physics Data: informazioni ridotte per
analisi specifiche in ROOT.
T. Lari: Analisi distribuita
3
Event Data Model: replica e distribuzione dati
Per rendere efficiente l’accesso ai dati per ricostruzioni (nei Tier-1) e analisi (nei
Tier-1/2) è previsto un certo livello di ridondanza, con repliche dei dati in più Tier.
RAW
• Dati originali al Tier0
• Replica completa nell’insieme dei Tier-1
ESD
• Gli ESD prodotti con la ricostruzione primaria risiedono al Tier-0 e
vengono esportati in due copie ai Tier-1
• Versioni successive degli ESD prodotte nei Tier-1 (ognuno riprocessa i
suoi RAW) e replicate in due copie agli altri Tier-1
• Frazioni a richiesta nei Tier-2
AOD
• Gli AOD prodotti con la ricostruzione primaria risiedono al Tier-0 e
sono replicati in ogni Tier-1
• Replicati parzialmente nei Tier-2 (~1/3 – 1/4 in ciascun Tier-2) in
modo da avere almeno un insieme completo fra i Tier-2 della cloud
 ogni Tier-2 specifica i dataset più interessanti per la comunità di
riferimento
DPD
Roma, 20-21 Febbraio 2008
• DPD dei gruppi di analisi prodotti nei Tier1 in maniera schedulata
• repliche nei Tier-2 e Tier-3
• In fase di definizione le procedure di produzione
T. Lari: Analisi distribuita
4
L’Analisi:
•L’ Analysis Model
•L’ Analisi Distribuita
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
5
Analysis Model
Formato di Analisi - Lo stato per le note CSC (v12)
Con il CSC è iniziato il processo di definizione del modello e dei formati di

analisi. Primo utilizzo delle tecniche di analisi distribuita
Prodotti della Ricostruzione: ESD, AOD analizzabili in Athena, CBNT (Athena

Aware flat NTuples) e SAN (ntuple strutturate) analizzabili in ROOT
Varie flat ntuples prodotte dagli AOD con codici personali o EventView

(prototipi di DPD)

Proliferazione della tipologia di DPD
Athena
Reconstruction
ESD
AOD
Athena
AODcode, EventView
CBNT Ntuple
Roma, 20-21 Febbraio 2008
Private Ntuple
HighPtView Nt
T. Lari: Analisi distribuita
groupEVNtuple
6
Analysis Model
La velocità, la portabilità e le ridotte dimensioni dei file sono le principali
caratteristiche richieste dell’utente
Soluzioni:
1.
Ridurre il numero di formati di DPD
2.
Aver accesso diretto ai dati nel formato AOD con la velocità tipica dell’analisi in
ROOT e la possibilità di sfruttare la potenza di Athena
Nuovo formato di AOD
La separazione tra i dati in formato transiente utilizzato in Athena e persistente
(file) permette di produrre un nuovo formato di una versione persistente di AOD
3.

La versione persistente (POOL file) puà essere letta direttamente in Root (p_AOD)
grazie a appositi dizionari che definiscono le caratteristiche degli oggetti

La versione transiente non è modificata: nessun impatto per l’utilizzo in Athena

Questa nuovo formato di AOD è la versione di default del DPD nella v13 e rende inutile la
produzione di ntuple
Ridurre la dimensione dei DPD
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
7
Analysis Model
Formato di Analisi - La soluzione verso cui si convergere (v13, FDR)

Unico Formato di Analisi: DPD

Deve essere leggibile da ROOT e deve poter utilizzare i tool e i servizi di Athena
AOD
Athena
AODDPD code
Part of AOD
User/MetaData
needed for H4l
Part of AOD
User/MetaData
needed for Hγγ
AOD
Caratteristiche dei DPD

Stesso formato degli AOD


Athena
Dimensioni ridotte (thin AOD):


AOD “general purpose”, DPD specializzati per la singola analisi
selezione delle informazioni essenziali
thinAOD
Introduzione di Userdata e Metadata (lumi info …)
Desktop
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
8
Analysis Model
Necessità di ridurre il numero dei file e la dimensione degli eventi
Uso più efficiente delle risorse di calcolo

Più spazio disco e CPU a disposizione

Velocizzazione dell’analisi

Strategie di filtro
1.
Skimming: selezione degli eventi interessanti
 Con i TAG (dBase o File)
 Con filtri agenti sulle variabili degli AOD (funziona !)
2.
3.

Numero di muoni

Missing Et
Thinning: rimozione di container o oggetti non interessanti

Muoni con pt < 20 GeV

Muoni ricostruiti con MOORE
Slimming: rimozione di propriet’ non interessanti di un oggetto
Roma, 20-21 Febbraio 2008

alcune info calorimetriche dall’oggetto elettrone o muone

alcune informazioni sulla qualità della traccia dei muoni
T. Lari: Analisi distribuita
9
Analysis Model
Definizione di DPD comuni:

Quanti DPD produrre?

Uno per physics group?

Uno per analisi o analisi simili
variando solo la userdata part?

Quanto spesso?

Chi produce i DPD?

E’ necessaria una
coordinazione precisa se
bisogna rigirare la produzione
sull’intera collezione gli AOD

Accesso schedulato: “train
model” per la produzione ai
Tier-1
L’esperienza dell’ FDR aiuterà a
dare un risposta a questi quesiti
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
10
Analysis Model
AOD
Metodi di Analisi (si usano gli stessi file!)


Skimming
Thinning
Slimming
Athena

User-Data
Interattivo o Batch via python o in batch
via C++
compilato (richiede alcuni minuti per compilazione)

Accesso totale ai tool e servizi di Athena

Necessaria una installazione completa di Athena

Si può sottomettere lo stesso codice in Grid
DPD =
thinAOD+UD
Analisi
ROOT (ARA)

Interattivo via CINT, python o batch via C++ compilato

Vantaggi:

•
Non richiede l’installazione completa di Athena (~1 GB)
•
Per “laptop use” e facile da usare: accesso interattivo ai
dati, sviluppo veloce dell’analisi
Svantaggi:
•
255 kb/ev – Rate 134 Hz
 Skimmed/Thinned (w MCTruth)
•
40 kb/ev – Rate 628 Hz
 Skimmed/Thinned (w/o MCTruth)

Accesso limitato ai metadata nel file (lumi, trigger)

No geometry e conditions db: niente tracce, cluster dei
calorimetri, e tool che fanno uso di questi database
Roma, 20-21 Febbraio 2008
Esempio H4l in ARA
(standard cuts in C++)
 Full AOD
•
14 kb/ev – Rate 1380 Hz
T. Lari: Analisi distribuita
~ 10 volte più veloce!
11
Analisi Distribuita

Gli utenti di ATLAS stanno finalmente prendendo confidenza con l’uso delle
tecniche di Analisi Distribuita
 Il CSC ha determinato un significativo passaggio dall’analisi locale all’analisi in Grid

Il Computing Model si basa sul principio che i job devono girare dove risiedono i
dati per ottimizzare l’efficienza del processamento e non trasferire localmente gli
enormi volumi di dati previsti da LHC (operazione praticamente impossibile)
1. Selezione degli eventi da TAG

Supporta la navigazione diretta agli eventi (RAW, ESD, AOD)

Procedura molto veloce: la selezione del 5% di eventi con query alle TAG è 20 volte più
veloce della lettura di tutti I dati rigettandone il 95%
2. Determinazione dei migliori siti dove i dati sono memorizzati
3. Invio in questi siti (tramite i tool di Analisi Distribuita) dei jobs e recupero degli
output: DPD e logfiles

Tool di Analisi Distribuita (job submission):
 GANGA in EGEE
 PAthena in OSG

Con l’avvicinarsi della presa dati, occorre essere preparati all’utilizzo dei tool
di analisi distribuita per essere in grado di gestire il volume di dati che
avremo fin dalle prime collisioni (200 Hz, indipendentemente dalla luminosità )
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
12
Trasferimento files

L’utente può facilmente scaricare dalla griglia i files di un certo dataset,
usando DQ2
 dq2_ls *PythiaZmumu.recon.AOD.v12*
Questo fornisce la lista dei dataset con questo nome (* = wildcard). E’ naturalmente
possibile farsi dare la lista dei files del dataset ed i siti dove sono distribuiti, sia
con opzioni da linea di comando sia da un’interfaccia web.
 dq2_get –r –d <localdir> <nomedataset>
Questo scarica dalla griglia il dataset e lo mette nella directory locale

Tuttavia non si suppone che l’utente si scarichi grosse (molti TB) quantità di
dati. Ogni Tier-2 italiano dovrebbe ricevere circa un quarto degli AOD della
produzione mediante il meccanismo delle sottoscrizioni.


Ogni Tier-2 puo’ scegliere (sottoscrivere) gli AOD a cui è interessato.
Tipicamente quelli più interessati per la comunità che fa riferimento a quel Tier2,
col vincolo che ogni Tier-2 ha un (diverso) quarto del totale.
Con i dati, gli utenti non potranno scaricare tutti i dati cui sono interessati
per mancanza di spazio disco: l’analisi distribuita sui dati arrivati con le
sottoscrizioni deve funzionare quando avremo i dati (e quindi occorre farla
funzionare adesso…)
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
13
Ganga e panda



Sono i due tool per fare analisi distribuita
Panda è il tool americano. Anche noi lo possiamo usare, spedendo i job sia su
siti americani che europei
Il feedback degli utenti è che è facile da usare e funziona molto bene




Ganga è il tool europeo. Il feedback degli utenti è che funziona bene quando
esiste una copia completa del dataset su un sito europeo, altrimenti dà
molti problemi



Tuttavia di default tutti i job sono spediti su BNL, dove ci sono praticamente
tutti gli AOD (l’analisi non è poi tanto distribuita…)
Non è ovvio che la facilità di utilizzo scali…
Nè che con i dati gli europei avranno le code libere per i loro job a BNL
Purtroppo pochi dataset CSC erano completi per i problemi di trasferimento dati
ricordati (sperabilmente ora risolti)
Le lamentele degli utenti sono comunque state recepite da gli sviluppatori, che
hanno fornito (qualche giorno fa) una nuova versione di ganga che migliora la
gestione di dataset incompleti
Non c’è niente di male ad usare panda, ma occorre anche lavorare perchè
ganga fornisca le prestazioni richieste da gli utenti – ne avremo bisogno coi
dati
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
14
Backup
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
15
Final Dress Rehearsal (FDR)
Esercizio completo dell’intera catena, dall’ on-line/trigger all’analisi distribuita,
per integrare i test svolti fino ad ora indipendetemente











Generazione e simulazione di eventi MC e mix di tutti i canali di fisica, in proporzione alle sezioni
d’urto, per riprodurre un campione il più possibile simile ai dati reali
Riproduzione della tipologia di dati in output all’HLT: simulazione del trigger, produzione del byte
stream e streaming degli eventi. Tabelle di Trigger realistiche
Input dei dati al P1 come dati reali
Trasmissione dei RAW data dal P1 al Tier-0
Data quality monitoring, calibrazioni e allineamento al Tier-0
Ricostruzione in tempo reale al Tier0  produzione di ESD, AOD, TAG
Distribuzione di ESD, AOD, TAG ai Tier-1 e Tier-2
Produzione del TAG database e dei DPD
Riprocessamento dei RAW data ai Tier1 e redistribuzione di AOD
Processamento dell’analisi distribuita
Simulazione continua in parallelo ai Tier-2 (~ 100k jobs/day)
In rosso gli step sincroni come durante il data taking
Lo scopo è testare l’intero computing system come se si trattasse di dati reali per
trovare in tempo i problemi che si potrebbero verificare durante il data taking
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
16
Final Dress Rehearsal (FDR)
Round 1:

Utlizzo dati simulati con la v12

Simulazione di un fill (10 hr) a 1031





Luminosità istantanea decrescente durante il fill

Menu di Trigger a 1031 fisso durante il fill

~ 400 nb-1 in tatale

Output rate di 200 Hz  ~7 M eventi
Simulazione di un fill corto (1 h) a 1032

Menu di Trigger a 1032

~ 400 nb-1 in tatale  ~0.7 M eventi
Replica numerose volte di questi fill in giorni
consecutivi simulando le condizioni di data taking
Introduzione dell’express e calibrations streams
Luminosità integrata bassa  analisi di canali ad alta
sezione d’urto (b physics, min bias, standard model)
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
17
Final Dress Rehearsal (FDR)
Round 2:

dati simulati con la v13 e ricostruiti con la v14

100 M eventi da simulare a partire da Nov 07

Fill con luminosità 1033 (50 – 100 pb-1)

Menu di trigger sempre più complicati

L2 muon calibration stream, calibrazione ai Tier-2

Produzione centrale di DPD mediante le procedure di
slimming degli AOD

Tuning dei tool di analisi distribuita

Analisi dai DPD attaverso il framework ARA
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
18
Common Computing Readiness Challange (CCRC08)
Nel 2008:



LHC finalmente sarà operativo e tutti gli esprimenti
prenderanno dati
Tutti gli esperimenti useranno le infrastrutture di computing
simultaneamente
Il Tier-0, molti Tier-1 e alcuni Tier-2 gestiscono l’attività di più
esperimenti e devono garantire le funzionalità previste dai
singoli Computing Model
per cui …
Il challenge combinato deve dimostrare la capacità delle infrastrutture di
computing a funzionare anche in situazioni di concorrenza tra tutti gli
esperimenti LHC prima dell’inizio della presa dati ad una scala comparabile
ai volumi previsti nel 2008
Tutto deve essere svolto in tempo per evidenziare imperfezioni,
bottlenecks e permettere le neccessarie correzioni
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
19
Data Taking
Quando sarà? In ogni caso bisogna essere pronti
17 settimane di fisica
Live time = 4·106 secondi
Rate = 200 Hz
Raw Data = 8·108 eventi
Dati simulati ~ 40% dei dati reali: 3·108 eventi
Roma, 20-21 Febbraio 2008
T. Lari: Analisi distribuita
20