Commissione Scientifica Nazionale I [email protected] …€¦ · FMD ITS MUON PHOS PMD TRD TPC TOF...

M.Masera ALICE Physics DC-3

ALICEPHYSICS DATA CHALLENGE III

Massimo [email protected]

Commissione Scientifica Nazionale I 23 giugno 2003


Sommario• Alice DC-3: che cos’e`; quali sono gli scopi• Framework: AliRootAliRoot, , AliEnAliEn . . Che cosa e’

cambiato per il Data Challenge?• Strumenti comuni di calcolo distribuito:

situazione attuale (EDGEDG--1.4 1.4 EDG 2.0EDG 2.0)• Infrastrutture di calcolo necessarie• Infrastrutture di calcolo esistenti e da acquisire • Strumenti comuni di calcolo distribuito per il DC-

3: LHC Computing Grid (LCG)LHC Computing Grid (LCG)


Test of the final system for reconstruction and analysis.

20%01/06-06/06

Complete chain used for trigger studies.Prototype of the analysis tools.Comparison with parameterised

MonteCarlo.Simulated raw data.

10%01/04-06/04

First test of the complete chain from simulation to reconstruction for the PPR

Simple analysis tools.Digits in ROOT format.

5%06/02-12/02

pp studies, reconstruction of TPC and ITS1%06/01-12/01

Physics ObjectiveFraction of the final capacity (%)

Period(milestone)

ALICE PHYSICS DATA CHALLENGES


Physics Data Challenge 3: obiettivi

• Il Physics Performance Report di ALICE e’ in via di completamento e dovrebbeterminare entro la fine dell’anno

• Simulazioni post-PPR: enfasi su hard physics; jets e jet quenching:– a LHC, ma in parte a RHIC, dovrebbe

crescere il contributo di minijet allaproduzione di particelle nella zona centrale di rapidita`


Physics Data Challenge 3: obiettivi • Una semplice parametrizzazione signalsignal--freefree di un modello

microscopico non puo` essere usato a causa dell’assenza di fluttuazioni dovute alla produzione di jet e minijet

• E` necessario far ricorso a generatori di eventi come HIJING, cheincludano la produzione di jet, anche per la simulazione deicosiddetti “eventi di background” usati con l’event mixing per simulare fenomeni a bassa sezione d’urto

• A pT ~10-20 GeV/c ci si aspetta~1 jet per evento • Jet con pT~200 GeV/c 1000/ mese di presa dati

– Studio di jet con pT fino a qualche 10 GeV/c: questo compitonon e` semplice ed e` basato sulla ricerca di leading particles ad alto pT nel barrel.

– La tecnica dell’event mixing (generazione separata di segnale e background) non e` possibile

– Studio di jet cpn pt~100 GeV/c e maggiore : event mixing. Un singolo evento di background puo` essere utilizzato fino a 50 50 voltevolte


Physics Data Challenge 3: obiettivi

• La definizione del numero di eventi da simulare nel DC-3 e` dovuta essenzialmente allo studio dei jet:– 105 eventi per lo studio di jets with pT fino a 10-20 GeV/c con

statistica sufficiente – 104 - 105 eventi per studi di correlazione di particelle e per

iperoni con stranezza singola e doppia (Λ,Ξ)– 106 eventi: jet di alto pT ( ~105 eventi di background)– Ω, stati di charmonio e bottomonio e+e- La statistica

necessaria e` dello stesso ordine di grandezza di quantonecessario per i jet. Gli stessi eventi di background possonoessere riutilizzati.

– Centralita`: • 50% central events (b<2-3 fm) • 50% minimum bias


Physics Data Challenge 3: scopi• Oltre a simulazioni Pb-Pb: 107 eventi p-p (Pythia) e ~106

p-A (Hijing)• Il DC serve anche per verificare la capacita` di simulare

e soprattutto analizzare una mole di dati ~10% di quellada trattare a regime con le tecnologie informatiche a disposizione ricaduta su framework e middleware

• La durata del DC e` di 6 mesi: la Collaborazione vuoleverificare quanti eventi e’ in grado si simulare e analizzare (in modalita` diretta o con mixing) in questoperiodo sfruttando sia risorse proprie che risorsedisponibili nell’ambito LCG

• Parte dei dati simulati sara` portata al Cern e di qui redistribuita per l’analisi


Il framework

ROOT

AliRoot

STEER

Virtual MC

G3 G4 FLUKA

HIJING

MEVSIM

PYTHIA6

PDF

CRT

EMCAL ZDC

FMD

ITS

MUON

PHOSPMD TRD

TPC

TOF

STRUCT START

RICH

RALICE

EVGEN

HBTP

HBTAN

ISAJET

DPMJET

Si veda la relazione di F.Carminati alla CSNI del Nov. 2002


AliRoot + AliEn• AliRoot

– C++: 400kLOC + 225kLOC (generated) + macros: 77kLOC – FORTRAN: 13kLOC (ALICE) + 914kLOC (external packages)– Maintained on Linux (any version!), HP-UX, DEC Unix, Solaris– Works also with Intel icc compiler

• Two packages to install (ROOT+AliRoot) + MC’s– Less that 1 second to link (thanks to 37 shared libs)– 1-click-away install: download and make (non-recursive

makefile)• AliEn

– 25kLOC of PERL5 (ALICE) – ~2MLOC mostly PERL5 (opens source components)

• Installed on almost 50 sites by physicists – >50 users develop AliRoot from detector groups– 70% of code developed outside, 30% by the core Offline team

Che cosa c’e` di nuovo in AliRoot?

User Code VMC

Geometrical Modeller

G3 G3 transport

G4 transportG4

FLUKA transportFLUKA

Reconstruction

Visualisation

Geant3.tar.gz includes

an upgraded Geant3with a C++ interface

Geant4_mc.tar.gz includesthe TVirtualMC <--> Geant4

interface classes

Generators

Monte Carlo Monte Carlo VirtualeVirtuale

M.Masera ALICE Physics DC-3ALICEALICEALICEALICE

3 milioni di volumi

Breaking News!

GEANT3 funziona a parti

re dal nuovomodella

tore


Che cosa c’e` di nuovo in AliRoot? NewIO

• Nuovo I/O: verra’ usato nel DC-3 per la prima volta. La gestione dell’IO e’ demandata a un set di classi dedicate (AliLoader, AliRunLoader, AliDataLoader…) e la dipendenza tra classi e’ ridotta con l’uso dei “folder” di root. – Highlights: migliore modularita’, facilita’ di rifare parti

di ricostruzione, possiblita’ di accedere (e spostarese serve) parte dell’informazione che e’ distribuita supiu’ file. Possibilita` di aggiornare l’informazione suMSS aggiungendo nuovi file (ad esempio: vertici, tracce, etc) senza alterare i file contenentil’informazione di partenza

TPC.RecPoints.root

ObjectObjectObjectObject

TreeTreeTreeTree

TPC.Hits.rootRoot dir

FolderFolderFolderFolder

Kine.root

Event #2TreeHTreeHTreeHTreeH

Event #2

TreeKTreeKTreeKTreeK

Event #1TreeHTreeHTreeHTreeH

Event #1

TreeKTreeKTreeKTreeK

TPC.Digits.rootEvent #1 Event #2

File

ITS.Tracks.root

ITS.Digits.root TPC.Tracks.root

ITS.Hits.root TPC.RecPoints.root

ObjectObjectObjectObject

galice.root

RunLoadergAlice TreeTreeTreeTreeEEEE

TreeTreeTreeTreeDDDDTreeTreeTreeTreeDDDD

NuovoI/O

Piotr Skowronski


I Loaders• Un Loader e` un oggetto responsabile della

gestione dei files– Gestisce I nomi dei file e delle directory (sia a livello di

OS che ROOT)• “Posting” dei dati su TFolders

– Da file a folder – lettura– E viceversa - scrittura

• Sono implementati dei metodi per accederecomodamente ai dati– e.g invece di usare:

dynamic_cast<TTree*>(fEventFolder->FindObject(fgkHeaderContainerName));

si puo’ fareloader->TreeE();


Architettura

AliRunLoader

AliLoader (ITS) AliLoader (PHOS)

This object takes care ofKinematics Track ReferencesHeader

These ones takes care of any data assiciated with one detectorHits Summble DigitsDigits

.....


Architettura

AliRunLoader

AliLoader (ITS) AliLoader (PHOS)

AliDataLoader(Hits)

AliDataLoader(SDigits)

AliDataLoader(Digits)

AliDataLoader(Tracks)

AliDataLoader(RecPoints)

AliDataLoader(Hits)

AliDataLoader(SDigits)

AliDataLoader(Digits)

AliDataLoader(Tracks)

AliDataLoader(RecPoints)

Migliore scalabilita`

Aggiungere nuovi tipi di datoe` facile

AliDataLoader(RawCluseters)

AliDataLoader(Kinematics)

AliDataLoader(Track Refs)

AliDataLoader(Header)

AliBasicLoader(TreeD)

AliBasicLoader(AliITSDigitizer)

AliBasicLoader(QATask)

AliBasicLoader(QAObject)

AliBasicLoader(TreeD)

AliBasicLoader(AliPHOSDigitizer)

AliBasicLoader(QATask)

AliBasicLoader(QAObject)

AliDataLoader(Vertex)


AliROOTAliROOT

UserUserSimulation,

Reconstruction,Calibration,

Analysis

C++

ROOTROOTSystemSystem

GUIPersistent IOUtility Libs

C++

WorldWorldInterfaces &

Distributed computing environment

anything

Nice! I only have to

learn C++

Typical HEP use cases:Simulation & Reconstruction

Event mixing

Analysis

Novita` in AliEn: connessione con EDG ( LCG)


Stefano Bagnasco, INFN Torino (DataTAG)

Il primo evento sottomesso via AliEn e’ girato sull’applicationtestbed di EDG (1.4) il 11/03/2003


Server Interface Site

AliEn CESubmissionEDG UI

EDG SiteEDG CE

EDG RB

WN

AliEn

EDG SE

Status report: outbound connectivity

AliEn SE

L’intera Grid e’ vista dal server come un singolo Computing Element (CE) di AliEn e l’intero storage diGrid come uno Storage Element (SE) di AliEn.

Interfaccia AliEn / GRID: job submission

Un “interface site” e’ una macchina User Interface di GRID sulla quale gira la AliEn client suite -ClusterMonitor, CE e SE

L’ interface client prende (“pulls”) un job dal server, genera un jdl appropriato che sia GLUE-compliant e manda il job alResource Broker (RB)

Sul Worker Node, il job attiva AliEn che comunica direttamente con il server

Nota: AliEn fa parte delSoftware di ALICE.

Non ci sono demoni attivi sul WN


L’output generato dal job di AliEn che gira su un sito EDG e` salvato su uno Storage Element definito dal RB di EDG. L’informazione e’ acquisita da AliEn a partire dal file .BrokerInfo.

I file sono registrati nel Replica Catalogue di EDG

I file sono quindi aanche registrati nel AliEn Data Catalogue usando il Logical File Name di EDG come AliEn Physical FileName

Accedere ai dati da AliEn e` un processo a 2 step via l’ AliEn Data Catalogue and EDG Replica Catalogue.

Il nodo di interfaccia e` anche in grado di effettuare lo stage di file attraverso i 2 sistemi.

Data Catalogue

EDG RC

EDG Site

EDG CE

WNAliEn

EDG SE

LFN

PFN

EDG://<RC>/<LFN>

Interfaccia AliEn / GRID: data management


Problemi aperti

Con EDG 1.4 il tracciamento degli errori e` problematico. Le cose dovrebbero sensibilmente migliorare con EDG 2.0

Il tasso di fallimento nel trasferimento di file tra i due sistemi e’ ancora molto alto (90%). Le ragioni sono:

Instabilita’ di EDG (interruzione di servizi quali RC, FT, etc)

Problemi noti di EDG specifici ad alcuni siti (e.g. RAL)

Problemi di saturazione della staging area dell’interfaccia: ilclean up non e’ fatto da AliEn. Il problema e’ superato: clean up fatto localmente.

Crash occasionali del File Transfer Demon Slow file transfer performance

Fortunatamente sono problemi di performance per i quali le soluzioni sono possibili.


Analisi distribuita: AliEnFS

MSS

MSS

MSS

MSS

VFS

Kernel

LUFS

Kernel Space

AliEnFS AliEnAPI

User Space

castor://

soap://root://

root:// root://https://

/alien/

alice/ atlas/

data/ prod/mc/

a/ b/

Linux File System

MSS

Il catalogo di AliEnpuo’ essere montato in ambiente linux come un file system:

Il browsing del catalogo e l’accesso aifile e’ dal punto di vista dell’utente equivalenteall’accesso di un file system convenzionale.

CAVEAT: per file remoti su MSS I tempi di accesso dipendonodalle risorse locali


Analisi distribuita: job splitting

*******************************************

* ** W E L C O M E to R O O T ** ** Version 3.03/09 3 December 2002 ** ** You are welcome to visit our Web site ** http://root.cern.ch ** ********************************************

Compiled for linux with thread support.

CINT/ROOT C/C++ Interpreter version 5.15.61, Oct 6 2002Type ? for help. Commands must be C++ statements.Enclose multiple statements between .root [0]newanalysis->Submit();

Analysis Macro

MSS

MSS

MSS

MSS

MSS

CE

CE

CE

CE

CE

merged Trees +Histograms

? Query for Input Data

•Esiste a livello di prototipo in Root/AliEn:

•A partire da unamacro di analisivengono generati tantijob AliEn quanti sono i file su sisti remoti daanalizzare

•I job vengono eseguitiin parallelo

•I risultati sotto forma di TTree, TNtuple, istogrammi vengonosottoposti a merge

PROOF Classic

PROOFPROOF

USER SESSIONUSER SESSION

32 Itanium II 2x1GHz, 2 GB RAM, 2x75GB 15K SCSI, Fast/GB Eth

PROOF PROOF SLAVE SERVERSSLAVE SERVERS


Super PROOF

USER SESSIONUSER SESSION

PROOFPROOFM+SM+S

SITE ASITE A

PROOFPROOFM+SM+S

SITE BSITE B

PROOFPROOFM+SM+S

SITE CSITE C

SuperSuperPROOFPROOF

SuperSuperPROOFPROOF

MASTER MASTER


Strumenti di GRID. Situazioneattuale

• ALICE ha tentato la produzione di 5000 eventiPb-Pb (HBT) sull’application testbed di EDG 1.4– 1 job/evento– 12-24 ore di CPU– 1.8 GB/evento 9 TB in tutto

• Start: 15 Marzo 03. Stop 31 Maggio 03• Eventi prodotti 450. 6 eventi/giorno. Abbastanza

per studiare la correlazione di pioni• L’application testbed di EDG non e` adatto a

grandi produzioni

BA: 3 servers (2 ALICE, 1 CMS)BO: 6 serversCA: 2 serversCNAF: 2 servers

CNAFCNAF

PadovaPadova

“Stress test” della rete•ALICE ha condotto un test sullacapacita’ di utilizzo delle reti• Obiettivi:

•dove sono i bottle neck nelleconnessioni di rete?• Le bandwidth sono sufficienti?

• Risultati:• bandwidth saturate in alcuni sitiin condizioni di uso normale nelDC• Architettura delle farm: NFS inadeguato per file grandi e thread multipli

CT: 2 serversPD: 6 serversTO: 2 serversTS: 1 server


EDG 2.0 LCG• L’uso del testbed da parte delle applicazioni e` servito a

mettere in luce i problemi esistenti• La versione 2 di EDG e la versione finale (ottobre

LCG) dovrebbero aver risolto la maggior parte deiproblemi che si sono presentati

SVILUPPI IN ITALIA• Potenziamento del development testbed di DataGrid in

modo da arrivare ad una versione finale (autunno 2003) che sia productionproduction--qualityquality e completa di VOMS e autenticazione (sviluppati in Italia)

• In parallelo si sta definendo la partecipazione INFN al Certification Testbed di LCG (macchine al CNAF – team distribuito)


Stima delle risorse necessarie• Simulazione:

– 105 Pb-Pb + 107 p-p– Produzione distribuita, replica dei dati (almeno parte) al CERN

• Ricostruzione e analisi :– 5×106 Pb-Pb + 107 p-p– Ricostruzione effettuata al Cern e fuori a seconda della disponibilita` di

risorse– I dati originano dal CERN

• Risorse (CPU e Storage) :– 2004 Q1: 1354 KSI2K e 165 TB– 2004 Q2: 1400 KSI2K e 301 TB– Definite nel documentodocumento sulsul Data Challenge Data Challenge presentatopresentato al PEB al PEB didi LCGLCG,

rivedute alla luce del fattore di mixing salito da 1/500 a 1/50. • Le valuazioni numeriche sono state recentemente riviste (Offline

week 10 Giugno 2003) e sono ancora in fase di elaborazione


RISORSE PER IL DC3O4Q1 O4Q2

Alice 1354 1400Total 1354 1400

LCG Declared Capacity for ALICE 1191 1191LCG Capacity for ALICE in Italy 145 145ALICE planned capacity Italy 400 400

Alice 165 301Total 165 301

LCG Declared Capacity for ALICE 202 202LCG planned Capacity for ALICE in Italy 16 16

70 70

CPU Requirements Ksi2k

Storage Requirements - total TB active data

ALICE planned capacity Italy

Le valutazioni sonodescritte nel documento“ALICE Data Challenge Planning” e sono basate su:

• Risultati dei data challenge precedenti

•Stime delle simulazioni daeffettuare al 2008, con ilrivelatore operativo.

• STORAGE: I 300 TB didati dovrebbero esseremantenuti su MSS oltre ilDC

Piano poliennale

Quota USA (30%)Non confermata


RISORSE CHE DOVREBBERO ESSERE DISPONIBILI PER ALICE

@ LCG-1SUM LCG Value Resource

Year Country CPU capacity (KSI2K)DISK capacity

(TB)LCG SUPPORT

(FTE) TAPE capacity (TB)2004 CERN 175 40 2,5 250

Czech Rep. 18 2 0,8 2France 120 23 2,9 154Germany 69 14 3,0 22Holland 41 1 1,3 4Italy 145 16 4,3 25Poland 0 0 0,0 0Russia 30 8 2,5 10UK 69 24 2,3 41USA 400 50 0,0 1400Sweden 90 20 1,0 20Hungary 35 6 1,3 0

Total 2004 1191 202 21,7 1928

La quota statunitense e` da confermare


Risorse in un Tier1 tipico

La tabella e` ricavata nell’ipotesi che il CERN contribuiscacome un Tier1 standard sulla base delle capacita` dichiaratedal Cern per LCG (175 KSI2K)

TYPICAL TIER-1 REQUIREMENTS

CPUKSI2K x 3 months

KSI2K x 3 months

186 193STORAGE TB TB

23 41


RISORSE LCG (Esistenti o pianificate)

• CPU: 145 KSI2K (dichiaratedichiarate al al progettoprogettoLCGLCG) – 75 al Tier1– 70 al Tier2 di Torino (34 gia’ esistenti)

• STORAGE: 16 TB – 8 TB dischi al Tier2 di Torino (2.6 gia`

esistenti)– Restante quantita` al Tier1

• TAPE CAPACITY:– 25 TB al Tier1


RISORSE DISPONIBILI nel 2003• Tier2 Torino (Farm CSNIII + farm LCG +

sblocco s.j. 2003)– CPU: 56.8 KSI2K– DISCO: 11.6 TB

• Tier2 Catania (Farm CSNIII + sblocco s.j. 2003)– CPU: 22.9 KSI2K– DISCO: 10.4 TB

• Totale Tier2: ~80 KSI2K e 22 TB di disco

s.j. CSNIIIPiccolo sblocco a giugno

Il resto a settembre(se va bene)


ESIGENZE per DC-3 ALICE ITALIA

5050NASTRO (TB)

4343DISCO (TB)(Escluso spool CASTOR)

140350CPU (KSI2000)

II SEMESTRE 2004

I SEMESTRE 2004

RICHIESTE per DC-3 ALICE ITALIA

050050NASTRO (TB)

11101110DISCO (TB)(Escluso spool CASTOR)

56 456 215CPU (KSI2000)

SEM II Tier2

SEM II Tier1

SEM I Tier2

SEM I Tier1

Questa dotazione andrebbe ad aggiungersi agli 80 KSI2000 e 22 TB disponibili aiTier2 secondo lo schema della slide 34


ALICE DC-3 e LCG

• AliEn e` l’interfaccia di produzione di ALICE– in modo diretto– via LCG

• Cfr. Attivita` sul testbed e sulla interoperabilita` AliEn/EDG• ALICE ha il committment ad usare tutte le

risorse LCG disponibili, assunta un’efficienzaragionevole

• Le risorse per il Data Challenge III (gennaio2004) vanno stabilite adesso

• ALICE non avra` DC nel 2005 • Le richieste per il 2004 sono per il DC-3


Soluzioni di backup• Se il testbed di produzione di LCG fosse in

ritardo o dovesse avere delle instabilita` tali darenderlo inefficiente :– Perderemmo gran parte delle risorse e il

raggiungimento degli obiettivi del DC potrebbe esserein forse

– Almeno in Italia, si potrebbero utilizzare le farm allocate pro tempore ad ALICE direttamente con AliEn

• La conversione dei WN e’ molto semplice• L’aggiunta di CE e SE addizionali e’ un po’ piu’ laboriosa. La

riconversione a LCG potrebbe richedere il mirroring dei datisu MSS

Commissione Scientifica Nazionale I [email protected] …€¦ · FMD ITS MUON PHOS PMD TRD TPC TOF...

Documents

Transcript of Commissione Scientifica Nazionale I [email protected] …€¦ · FMD ITS MUON PHOS PMD TRD TPC TOF...