Post on 26-Jan-2016
description
1
Analisi dati nell’esperimento LHCb
CSN1, 16/5/06
U. Marconi, INFN Bologna
2
Flusso dei dati in LHCb
Ricostruzione
Preselezione
Analisi utente
Trigger (2 kHz)
Rivelazione (40 MHz)
Monte Carlo
Ridurre la taglia dei campionia livello di
106 ÷ 107 eventi per ogni tipologia prevista
Ricostruzione e preselezionesono gestite centralmente
RAW
rDST
DST, TAG
ntuple
60 MB/s RAW10 MB/s rDST (B esclusivi)
25KB/evt
3
Modello di calcolo
DST x 7
Analisi dei dati al Tier1DST replicati in ciascun Tier1
4
Tier1 e Tier2 al CNAF
LHCb Computing TDR, CERN/LHCC 2005-019
Tier11/6 delle
risorse LHCbal CNAF
Risorse di calcolo di LHCb
Tier215% delle
risorse LHCb al CNAF
1° anno di presa dati
5
Scenario di analisi
5105 job di analisi all’anno, corrispondenti a 103 job concorrenti al giorno, della durata media di 3 ore ciascuno.
LHCb ha raggiunto picchi di 5500 job attivi simultaneamente su LCG, con 3000 job attivi in media durante i periodi di produzione Monte Carlo.
Risorse dedicate all’analisi: ~ 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,
6
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.
7
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.
8
DIRAC
per la sottoposizione dei job
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
Job di analisi
DIRAC Python script
9
Interfaccia utente per l’analisi
(Ganga)
Job definition
Job submission
Job cancellation
Job monitoringand output retrieval
Application
Backend
Dataset
Codice Python~20k linee di codice
http://ganga.web.cern.ch/ganga
10
Test di analisi distribuita
http://lhcb01.pic.es/DIRAC/Monitoring/Analysis/
Test di analisi distribuita sono in corso da alcuni mesi
11
LHCb DIRAC Monitoring
12
Risultati (1/3)
Analisi distribuita realizzata utilizzando il sistema DIRAC-LCG. L’efficienza è del 95%.
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.
Tier1 site
13
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.
14
Risultati (3/3)
Analisi su un campione di 5 Meventi.
Tempo di attesa perl’invio dei job di analisi
Tempo di recupero dell’output
90% entro 3 ore95% entro 4 ore
100% entro 10 oreProblemi di accesso ai
dati al Tier1
15
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=a068sommario disponibile a
http://grid-it.cnaf.infn.it/cdsagenda/askArchive.php?base=agenda&categ=a068&id=a068s8t1/document (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.
16
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.