ATLAS Distributed Analysis Lamberto Luminari CSN1 – Roma, 16 Maggio 2006.

ATLAS Distributed Analysis

Lamberto LuminariLamberto Luminari

CSN1 – Roma, 16 Maggio 2006CSN1 – Roma, 16 Maggio 2006

CSN1 - Roma 16/05/2006CSN1 - Roma 16/05/2006 Lamberto Luminari - ATLAS Distributed AnalysisLamberto Luminari - ATLAS Distributed Analysis 22

Sommario

Event Data Model:tipi di dati, streaming, distribuzione

Distributed Data Management (DDM):gestione dataset, replica dei dati

Distributed Analysis:schema generale, data selection and processinginterfaccia utentejob submission tool

Virtual Organization (VO):organizzazione degli utenti ATLAS:

Stato dei tool necessari per l’analisi

Situazione manpower INFN

Conclusioni


Event Data Model: Tipi di dati

Nelle varie fasi di ricostruzione e analisi ATLAS utilizza diversi tipi di dati:

RAW Data:sono i dati in output dal sistema di trigger e acquisizione

formato “Byte-Stream” ~1.6 MB/evento

Event Summary Data (ESD):dati prodotti dal processo di ricostruzione (tracce ricostruite e hit relativi, celle e cluster nei calorimetri, combined reconstruction objects etc...)

rappresentazione object-oriented (POOL/ROOT)~0.5 MB/evento (nominale; attualmente > 1. MB)

Analysis Object Data (AOD):rappresentazione ridotta degli eventi, contenente gli oggetti “fisici” ricostruiti (elettroni, muoni, jet, etc...) e altri elementi utili per l’analisi

rappresentazione object-oriented (POOL/ROOT)~100. KB/evento

Tag Data (TAG):informazioni sintetiche per identificazione e selezione degli eventi

formato DB relazionale per ricerche veloci +formato ROOT per istogrammazione veloce~1. KB/evento

~15.kSI2k*s/evento

~0.5kSI2k*s/evento


Event Data Model: Flusso di dati da TDAQ

La rate di eventi in uscita dal sistema di Trigger e Data AcQuisition è di ~200 Hz, all’incirca indipendente dalla luminosità

Gli eventi vengono suddivisi in stream e scritti in file di <2. GB (~1000 eventi * ~1.6 MB/evento)

Attualmente sono previste 4 classi di stream:express stream, con gli eventi “più interessanti”calibration stream, con i dati necessari per le calibrazioni dei detectordebugging stream, contenente eventi che presentano problemievent stream, suddivisa (secondo le prime indicazioni) nelle seguenti sotto-stream inclusive:

Muon triggersElectromagnetic triggers (electrons and photons)Hadronic triggers (jets, taus, missing energy)B-physics triggersMinimum bias e altri prescaled triggers per monitoring

I file vengono organizzati in dataset, collezioni di eventi con caratteristiche simili (statisticamente equivalenti) da processare solitamente insieme.


Event Data Model: Replica e distribuzione Event Data Model: Replica e distribuzione datidatiPer 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 Tier0Replica completa nell’insieme dei Tier-1 (~1/10 per Tier-1)

ESD:Gli ESD prodotti con la ricostruzione primaria risiedono al

Tier-0Versioni successive degli ESD prodotte nei Tier-1 (~1/10 per

Tier-1) e replicate in due copie (alla fine in ogni Tier-1 1/5 degli ESD)

AOD: Replicati completamente in ogni Tier-1Replicati parzialmente nei Tier-2 (~1/3 – 1/4 in ciascun Tier-

2)

TAG: I database dei TAG sono replicati in tutti i Tier-1 (ORACLE) Repliche parziali/totali dei database TAG nei Tier-2 (MySQL) In ciascun Tier-2 risiedono i file ROOT/POOL dei TAG

corrspondenti agli AOD ospitati nel sito.

Campioni di eventi di tutti i tipi possono essere memorizzati nei vari Tier per studi particolari o sviluppo software.

Event Builder

Event Filter

Tier3

10 GB/s

320 MB/s

~ 150 MB/s ~10~10

~50 Mb/s

~PB/s

Tier2 ~3-4/Tier1~3-4/Tier1

Tier0

Tier1


Distributed Data Management Model

Nel 2005 ATLAS ha rivisto il suo Grid distributed systems (data management, production, analysis), in accordo con il Baseline Service Working Group LCG

Attualmente il Distributed Data Management (DDM) system di ATLAS (DQ2) si basa su:

Cataloghi di dataset centrali, suddivisi (replicati?) in vari DB per facilitare l’accessoDataset Repository, Dataset Content Catalog, Dataset Location Cat., Dataset Subscription Cat.

Cataloghi di file distribuiti (locali)Non ci sono cataloghi globali di file: la risoluzione dei file fisici è fatta localmente a partire dai dataset su cataloghi (specifici per ogni Grid) che contengono solo i file salvati i quel sito

Sistema automatico di trasferimento dati:dataset subscription system

Subscriptionsphys.esd.001: CERN, CNAF, BNLphys.aod.001: CERN, CNAF

CERN

phys.raw.001phys.esd.001phys.aod.001

CNAF

phys.esd.001phys.aod.001

BNL

phys.esd.001Automatic

updates


Distributed Data Management System

Nel mondo ideale (network “trasparente”) non ci sarebbe bisogno di definire associazioni default Tier-1 – Tier-2

In pratica, risulta conveniente partizionare la Grid cosi’ da avere data path preferenziali tra Tier-1 e Tier-2 da utilizzare per le operazioni privilegiate

I canali per File Transfer Service sono definiti solo per i data path preferenzialiTutti gli altri trasferimenti dati avvengono attraverso le normali network routes

La clusterizzazione facilita la suddivisione delle varie operazioni di analisi, a seconda delle loro caratteristiche, tra Tier-1 e Tier-2 associati

Inoltre in questo modello, un certo numero di data services sono installati solo nei Tier-1 (ma servono anche per i Tier-2“associati”):

FTS channel server (per entrambe le direzioni)Local File Catalog unico per il cluster (ache per i file residenti nei Tier-2)

Channel T1-T2

Tier-1

Tier-0

Tier-2

Tier-2

LocalFileCatalog

LFC

Tier-1

FTSserver

FTSserver

FTSserver

LFC

Channel T0-T1 Channel T1-

T1


Distributed Analysis: Schema generale

Lo schema descritto è quello ad oggi più probabile per l’analisi distribuita:

Non tutte le sue parti sono allo stesso livello di maturità e “ufficialità”Non è stato ancora testato su scala significativa

Scenario di riferimento attuale:Le attività di analisi vanno in parallelo alla produzione

Necessità di Job Priorities, Short Queues, Fair Share delle risorse, …I dati per l’analisi saranno (parzialmente) disponibili su tutti i Tier-1 e i Tier-2

AOD & ESD (AOD completi di 1 anno = ~200 TB)I Tier-1 possono accogliere scheduled (group) analysis jobsI Tier-2 ospitano individual analysis jobs

La procedura standard prevede la selezione degli eventi da TAG e l’analisi sugli AOD degli eventi selezionati.Gli utenti (tramite Grid tools) invieranno jobs dove sono i dati ed estrarranno le informazioni più rilevanti:

Tipicamente nella forma di NTuple o similiQueste informazioni saranno usate localmente in modo interattivo


Distributed Analysis: Data selection

L’utente apre una sessione di analisi tramite un’interfaccia che L’utente apre una sessione di analisi tramite un’interfaccia che gli permette di eseguire tutte le operazioni connesse all’analisi.gli permette di eseguire tutte le operazioni connesse all’analisi.

I passi logici da compiere (manualmente uno alla I passi logici da compiere (manualmente uno alla volta o in modo automatico via script o form) sono:volta o in modo automatico via script o form) sono:

Interrogazione del Interrogazione del Dataset Content CatalogDataset Content Catalog che che contiene i metadata per ogni dataset del tipo contiene i metadata per ogni dataset del tipo desiderato per trovare quelli che gli interessanodesiderato per trovare quelli che gli interessano

Esempio di query: dammi la lista dei dataset TAG Esempio di query: dammi la lista dei dataset TAG con trigger 2con trigger 2 del 2009, versione x.y.z del 2009, versione x.y.z

Tramite il Tramite il Dataset Location CatalogDataset Location Catalog viene viene localizzato il sito dove risiede il datasetlocalizzato il sito dove risiede il dataset

In ogni Tier1 è poi disponibile un catalogo locale In ogni Tier1 è poi disponibile un catalogo locale ((Local File CatalogLocal File Catalog) per passare dai dataset ai ) per passare dai dataset ai singoli files residenti sul cluster Tier1 + Tier2-singoli files residenti sul cluster Tier1 + Tier2-associati associati

Applicazione dell’ algoritmo di selezione sui Applicazione dell’ algoritmo di selezione sui dataset scelti e produzione di una lista di eventi dataset scelti e produzione di una lista di eventi accettatiaccettati

DatasetContentCatalog

Dataset C

“TAG, 2, 2009,…”

Event 1,Event 3,Event 6

Selection

criteria

DatasetLocationCatalog

LFC

Dataset C:•File 1•File2

CNAFCNAF


Distributed Analysis: Data processing

Selezionati gli eventi, l’utente Selezionati gli eventi, l’utente sottomette alla Grid i suoi job di analisi sottomette alla Grid i suoi job di analisi tramite iltramite il Work Load Manager (WLM)Work Load Manager (WLM),, interfacciato ai cataloghiinterfacciato ai cataloghi

Tramite il Tramite il Dataset Location CatalogDataset Location Catalog vengono localizzati i siti dove risiedono i vengono localizzati i siti dove risiedono i dataset contenenti gli eventi accettatidataset contenenti gli eventi accettati

In ogni Tier1 è poi disponibile un In ogni Tier1 è poi disponibile un catalogo locale (catalogo locale (Local File CatalogLocal File Catalog) per ) per passare dai dataset ai singoli files passare dai dataset ai singoli files residenti sul cluster Tier1 + Tier2-residenti sul cluster Tier1 + Tier2-associatiassociati

Un job può dare come output una nuova Un job può dare come output una nuova collezione di eventi, che può essere registrata collezione di eventi, che può essere registrata come come nuovo dataset nei cataloghi e acceduto nei cataloghi e acceduto successivamentesuccessivamente

Il singolo utente può anche estrarreIl singolo utente può anche estrarre dall’insieme dei dati analizzati (ad es. in dall’insieme dei dati analizzati (ad es. in formato AOD) dei file di formato AOD) dei file di Derived Physics Derived Physics DataData (tipo n-tupla o altro formato privato) (tipo n-tupla o altro formato privato) che potrà poi analizzare interattivamente in che potrà poi analizzare interattivamente in localelocale..

Submissiontool

Event 1,Event 3,Event 6

Dataset A:•File 1•File 2

LFC

Dataset B:•File 3•File 4

LFC

Dataset C:•File 5•File 6

Work LoadManager

Job 3

ComputingElement

Job 2Job 1

ComputingElement

DPD/N-tuple:

•File 5•File 6

DPD/N-tuple:

•File 3•File 4

DPD/N-tuple:

•File 1•File 2

DatasetLocationCatalog

CNAFCNAF

CERN

CERN


Distributed Analysis: Interfaccia utente

Dal punto di vista implementativo, GANGA:

permette di accedere a risorse locali o remote (Grid) in modo uniforme;

essendo sviluppato nel contesto di ATLAS e LHCb, offre supporto built-in per applicazioni basate sul framework Gaudi/Athena;

ha una architettura a componenti che ne permette agevolmente l’estensione ad altre funzionalità;

è scritto in Python.

GANGA (Gaudi/Athena and Grid Alliance) è un’interfaccia utente easy-to-use per le operazioni connesse all’analisi:

la selezione degli eventi e la identificazione dei siti dove trovare i dataset relativilo splitting del job di analisi in job più piccoli da eseguire in parallelo sulla Grid e il merging dei risultati


Distributed Analysis: Job SubmissionIl sistema di sottomissione dei job assolve alle seguenti funzioni:

Individua le risorse ottimali (CPU vs dati) sulle infrastrutture di calcoloStabilisce i parametri corretti per l’esecuzione a seconda del flavour di GridEsegue single job o bulk submission

Esistono vari tool, in genere legati ad uno o più flavour di middleware di Grid; l’obiettivo è quello di usare ProdSys, il tool già utilizzato con successo per sottomettere job a tutte le infrastrutture Grid utilizzate da ATLAS (LCG, OSG, NorduGrid)

per il Data Challenge 2: 20 nazioni69 siti~ 260000 job

per il Physics Rome Workshop: 22 nazioni84 sites> 570000 job


VO (Virtual Organization): Attributi utente

L’analisi distribuita comporta l’accesso da parte di molti utenti a grandi quantità di risorse e dati in vari siti

necessità di regolamentare le modalità di accesso, per poter assicurare che lo share di risorse allocato alle diverse attività e a disposizione dei vari utenti sia coerente con le priorità decise dall’esperimento

A seconda dell’attività, gli utenti di ATLAS sono caratterizzati da alcuni attributi, in base ai quali vengono assegnati privilegi e disponibilità di risorse:

Ruoli:Grid software administrator Production managerNormal user

Gruppi:PhysicsCombined performanceTriggerComputing & central productions

Funding:Countries and funding agencies


VO: Gruppi

I gruppi (e sottogruppi) di attività attualmente previsti sono:Physics:

phys-beauty, phys-top, phys-sm, phys-higgs, phys-susy, phys-phys-beauty, phys-top, phys-sm, phys-higgs, phys-susy, phys-exoticsexoticsphys-hi, phys-gener, phys-lumin phys-hi, phys-gener, phys-lumin

Combined performanceperf-egamma, perf-jets, perf-flavtag, perf-muons, perf-tauperf-egamma, perf-jets, perf-flavtag, perf-muons, perf-tau

Trigger:Trigger:trig-pesatrig-pesa

Detectors:Detectors:det-indet, det-larg, det-tile, det-indet, det-larg, det-tile, det-muon det-muon

Computing:Computing:soft-test, soft-test, soft-valid, soft-valid, soft-prod, soft-adminsoft-prod, soft-admin

Gen-userGen-user

E’ prevista, almeno inizialmente, una situazione conservativa:E’ prevista, almeno inizialmente, una situazione conservativa:la maggior parte di questi gruppi (e relative priorità) saranno la maggior parte di questi gruppi (e relative priorità) saranno riservate solo ai riservate solo ai Group production managersGroup production managersi i Software installersSoftware installers saranno in saranno in soft-adminsoft-admintutti tutti gli altri utentigli altri utenti saranno in saranno in gen-usergen-user


Stato dei tool (1)

Il Distributed Data Management consiste di tools sviluppati da ATLAS (Il Distributed Data Management consiste di tools sviluppati da ATLAS (DQ2DQ2) ) e di tool comuni LCGe di tool comuni LCG

DQ2 è ora in corso di integrazione col DQ2 è ora in corso di integrazione col PRODPRODuction uction SYSSYStemtemtest di produzione realistici nel corso del Computing System Commissioning in test di produzione realistici nel corso del Computing System Commissioning in autunnoautunno

Per quando riguarda il management dei Jobs (WLM, sviluppato da INFN in EGEE) le funzionalità di base sono presenti:

Gli sviluppi ancora necessari sono abbastanza contenuti e ben identificatiOccorre ancora lavoro di integrazione, test, distribuzione sui siti, debuggingBisogna verificare che il sistema scali e sia sufficientemente robusto

I test fin qui fatti sono positivi (rate standard di 4000 jobs da 20 ore con errori WMS dell’ordine di qualche %)

Gli esperti, sia ATLAS che EGEE, sono INFN, in contatto molto stretto ed efficiente

Il mantenimento e una limitata evoluzione del WLM devono essere garantiti nel tempo

C’è competizione con altri sistemi: CondorG, usato con successo assieme a WLM nelle produzioni su LCG, e PANDA oggi usato solo in US ma che potrebbe tentare espansione

Dal punto di vista ATLAS la competizione aiutaDal punto di vista INFN siamo in buona posizione nella competizione


Stato dei tool (2)

Per l’accounting e la prioritizzazione delle attivitàPer l’accounting e la prioritizzazione delle attività a livello di utente e a livello di utente e gruppo si stanno sviluppando tool basati sul sistema di autenticazione e gruppo si stanno sviluppando tool basati sul sistema di autenticazione e autorizzazione autorizzazione VOMSVOMS, sviluppato da INFN, sviluppato da INFN

Un accounting con la granularità richiesta non è ancora disponibile in produzioneUn accounting con la granularità richiesta non è ancora disponibile in produzione

La combinazione di due tool, APEL (sviluppato in UK) + DGAS (sviluppato da INFN e installato in test su GRID INFN), sembra offrire tutte le funzionalità richieste e un accordo sembra raggiunto in questo senso

E’ urgente un sistema che permetta almeno una coesistenza efficiente fra job di simulazione, di analisi e di servizio (tipo installazione sw), superando il completo “egualitarismo” attualeUn WG EGEE sta elaborando soluzione comune per i diversi esperimentiin 2 step:

1. Sistema con componenti quasi tutti disponibili ora, ma con funzionalità limitata all’urgenza

Si conta che sia disponibile in produzione in un paio di mesi2. Sistema più completo per autunno 2006

Unico candidato è gPbox (sviluppato da INFN), che però deve ancora passare per tutta la sequenza integrazione-certificazione-installazione distribuita, test intensivo…

La capacità del sistema di accounting di trattare in modo completo i dati La capacità del sistema di accounting di trattare in modo completo i dati dell’enorme numero di job previsti deve essere dimostrata entro la primavera dell’enorme numero di job previsti deve essere dimostrata entro la primavera 20072007


Situazione manpower INFNSul DDM (DQ2), che potrebbe essere la parte più critica dell’intero sistema di analisi distribuita, sarebbe desiderabile avere un ruolo maggiore;

Oggi solo S.Campana (al CERN) ha un buon contatto con gli sviluppatori e G. Negri (al CNAF) conosce DQ2

Per quanto riguarda l’interfaccia ad ATLAS del WLM, gli esperti ci sono (E.Molinari, D.Rebatto, S. Resconi a Milano, S.Campana al CERN e G. Negri al CNAF) ma sono overloaded dalla responsabilità concorrente dei nuovi sviluppi e loro tests e dalla produzione corrente su LCG + EGEE…

Si sta cercando di trasferire almeno in parte la produzione, ma non è facile data la incompleta automazione del sistema

Per quanto riguarda l’interfaccia ad ATLAS di VOMS, la situazione è buona: A. De Salvo (Roma1) è il VO manager di ATLAS e il massimo esperto disponibile (in estremo overload); ci sono inoltre A. Barchiesi (Roma1) e new entries da CNAF e Bologna

Il nuovo fellow LCG al CERN da affiancare a S.Campana, un nuovo assegno di ricerca al CNAF (al posto di Negri) e un nuovo contratto a G.Negri (AR CNAF scade in gennaio) sono il minimo indispensabile per continuare a funzionare bene con WLM e VOMS, acquisendo ulteriore competenza in DDM.

Si lavora per inserire nuove forze (ad es., da Udine avremo un dottorando informatico che concorre a una borsa tecnologica INFN e da Bologna c’è qualche possibilità ulteriore) ma non è facile avere maggiore coinvolgimento dei gruppi quando il sistema è ancora “per esperti”


ConclusioniLe componenti necessarie per l’analisi distribuita di ATLAS sono disponibili fra ora (la maggior parte) e l’autunno

Una frazione consistente dei tools sono stati sviluppati da INFN GRID e ne deve essere assicurata nel tempo la manutenzione e limitate evoluzioni

Ci sarà molto lavoro da fare per portare il sistema di analisi a completa maturità

Qualche componente potrebbe rivelarsi non adatta e/o non scalare bene

Il modello di analisi è prudente e ammette vari scenari di fall-backLa distribuzione dei dati e dei cataloghi permette di evitare ingorghi in vari modi

L’INFN ha il maggior coinvolgimento e la maggiore esperienza dopo il CERNMa gli esperti in queste tecnologie sono pochi, in overload, e precari

Imperativo non perderli e fare acquisire esperienza nel campo a più persone “stabili”EGEE-2 finisce fra 2 anni e se non si trovano soluzioni alternative ATLAS-INFN perde più della metà dei suoi esperti

N.B. Pur non essendo oggetto di questa presentazione, va sottolineato che prerequisito per il successo della comunità italiana nell’analisi di ATLAS è una infrastruttura di calcolo (Tier-1 + Federazione Tier-2) in grado di fornire risorse e servizi in modo affidabile ed efficiente.

ATLAS Distributed Analysis Lamberto Luminari CSN1 – Roma, 16 Maggio 2006.

Documents

Transcript of ATLAS Distributed Analysis Lamberto Luminari CSN1 – Roma, 16 Maggio 2006.