Analisi dati
nell’esperimento LHCb
U. Marconi, INFN Bologna
CSN1, 16/5/06
1
Flusso dei dati in LHCb
Rivelazione (40 MHz)
Trigger (2 kHz)
Monte Carlo
RAW
60 MB/s RAW
10 MB/s rDST (B esclusivi)
25KB/evt
Ricostruzione
rDST
Ricostruzione e preselezione
sono gestite centralmente
Preselezione
DST, TAG
Ridurre la taglia dei campioni
a livello di
106 ÷ 107 eventi
per ogni tipologia prevista
Analisi utente
ntuple
2
Modello di calcolo
DST x 7
Analisi dei dati al Tier1
DST replicati in ciascun Tier1
3
Tier1 e Tier2 al CNAF
Risorse di calcolo di LHCb
1° anno di presa
dati
Tier2
15% delle
risorse LHCb
al CNAF
Tier1
1/6 delle
risorse LHCb
al CNAF
LHCb Computing TDR, CERN/LHCC 2005-019
4
Scenario di analisi

5105 job di analisi all’anno, corrispondenti a 103 job concorrenti al
giorno, della durata media di 3 ore ciascuno.


Risorse dedicate all’analisi:



LHCb ha raggiunto picchi di 5500 job attivi simultaneamente su LCG,
con 3000 job attivi in media durante i periodi di produzione Monte Carlo.
~ 20% delle risorse di CPU.
~ 10% delle risorse di disco.
Parametri di riferimento:





25% della collaborazione attiva nell’analisi.
80% dell’analisi su campioni di 106 eventi.
20% dell’analisi su campioni di 107 eventi.
Dimensione di un evento DST+RAW: ~(100 + 25) kB.
Tempo di calcolo per job di analisi 0.3 kSI2k·s/evento,
5
Modello di analisi (1/2)


Al momento l’orientamento della collaborazione sarebbe
quello di non sottoporre le richieste di esecuzione di job
di analisi direttamente a LCG.
I job di analisi debbono essere sottoposti ad una sistema
di gestione delle richieste della collaborazione (DIRAC).
Da questo i job sono poi inviati alla Grid mediante il WMS
di LCG.


I job di ciascun utente vanno in esecuzione secondo l’ordine di
inserimento nella coda di DIRAC e secondo priorità determinate.
Le priorità e le eventuali restrizioni relative a ciascuna richiesta di
esecuzione di job di analisi sono gestite dalla collaborazione
all’interno di questo modello.
6
Modello di analisi (2/2)





L’utente invia il job di analisi a
DIRAC
DIRAC produce un Pilot Agent come
job di LCG.
Il Pilot Agent raggiunto il Worker
Node, effettuati tutti i controlli del
caso, recupera un job di analisi dalla
task queue di DIRAC.
Lo stato di esecuzione del job può
essere seguito sia mediante il WMS,
sia mediante DIRAC stesso.
Per recuperare l’output ci sono due
tecniche:


File di piccole dimensioni tornano
indietro mediante il WMS come
sandboxes.
Altrimenti essi sono trasmessi dal
job verso gli Storage Element.
7
DIRAC
per la sottoposizione dei job
Job di analisi
from DIRAC.Client.Dirac import *
dirac = Dirac()
job = Job()
job.setApplication('DaVinci', 'v12r15')
job.setInputSandbox(['DaVinci.opts', 'lib '])
job.setInputData(['/lhcb/production/DC04/v2/DST/
00000742_00003493_10.dst'])
job.setOutputSandbox(['DVNtuples.root',
'DaVinci_v12r15.log'])
jobid = dirac.submit(job,verbose=1)
print "Job ID = ",jobid
DIRAC Python script
8
Interfaccia utente per l’analisi
(Ganga)
http://ganga.web.cern.ch/ganga
Codice Python
~20k linee di codice
Dataset
Application
Job definition
Backend
Job submission
Job cancellation
Job monitoring
and output retrieval
9
Test di analisi distribuita
Test di analisi distribuita sono in corso da alcuni mesi
http://lhcb01.pic.es/DIRAC/Monitoring/Analysis/
10
LHCb DIRAC Monitoring
11
Risultati (1/3)

Analisi distribuita realizzata utilizzando il
sistema DIRAC-LCG.
L’efficienza è del 95%.

Tier1 site
Errori dovuti ad inconsistenze nei cataloghi.

Sottoposizione diretta dei job di analisi alla
Grid, senza restrizioni sui centri di calcolo.
L’efficienza è del 50%.

Sottoposizione diretta ai soli Tier1.
L’efficienza è del 91%.
Piccole differenze con il caso DIRAC-LCG
sono dovute alla sottoposizione ripetuta in
caso di insuccesso.
12
Risultati (2/3)




Sistema di analisi DIRAC-LCG utilizzando solo Tier1.
Un sito Tier1 con problemi allo SE.
75% di successi al primo tentativo di sottoposizione.
95% di successi eliminando il Tier1 non operativo e
riprovando.
13
Risultati (3/3)

Analisi su un campione di 5 Meventi.
Tempo di attesa per
l’invio dei job di analisi
Tempo di recupero
dell’output
90% entro 3 ore
95% entro 4 ore
100% entro 10 ore
Problemi di accesso ai
dati al Tier1
14
Contributi INFN

Sviluppo del software di esperimento.




Realizzazione dell’interfaccia per l’invio dei job di analisi al RB di LCG.
Implementazione del meccanismo di policy enforcement per la sottoposizione dei job.
Librerie per il Data Management.
Attività di interesse generale in collaborazione con il Tier-1





Collaudo delle soluzioni per lo storage e collaudo delle SRM.
Workshop sullo storage al CNAF
https://grid-it.cnaf.infn.it/cdsagenda/fullAgenda.php?ida=a068
sommario disponibile a
http://gridit.cnaf.infn.it/cdsagenda/askArchive.php?base=agenda&categ=a068&id=a068s8t1/doc
ument (per accedere al sommario, user: guest, password: susy)"
Replica dei cataloghi al Tier1 mediante Oracle Data Base.
Controllo remoto dei server di calcolo mediante IPMI.
Soluzioni per High Availability.
15
Conclusioni





Le esigenze di LHCb sul fronte dell’analisi sono sostanzialmente
chiare.
Il software per la gestione dell’analisi distribuita è già oggi piuttosto
evoluto.
L’accesso dei job ai dati è questione delicata. È previsto avere i dati
stripped su disco al Tier1: la selezione della preselezione consente di
avere campioni di taglia contenuta.
Il personale INFN dedicato a LHCb è impiegato efficacemente, sia nella
integrazione del software LCG sia a supporto delle attività di interesse
generale presso il CNAF.
Il CNAF per LHCb è fondamentale


Ospiterà sia il centro Tier1 sia le risorse di calcolo Tier2.
Il CNAF ha sviluppato buone competenze tecniche e ha compiuto
evidenti progressi. Difetta ancora gravemente di mano d'opera, e
necessita di migliore organizzazione delle risorse umane.
Manca personale di esperienza qualificato nella gestione del lavoro.
16