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.