Alcuni approcci all’analisi dati (tra CMSSW e ROOT)

Riunione mensile di software e analisi, 15/12/2008

Massimo Nespolo

1

Sommario:• Dalle root-uple all’EDM di CMS:

– Motivazione;– Confronto critico;

• Nella pratica:– Grafici immediati;– Approccio uniforme;

• Soluzione “definitiva”:– TFWLiteSelector.

Alcuni approcci all’analisi dati (tra CMSSW e ROOT)

2

Il problema

L’analisi viene effettuata parte in CMSSW e parte in ROOT

L’analisi in ROOT deve essere il piu’ possibile “agile”

Bisogna far comunicare i due framework

Necessità di avere un formato dati che faccia da ponte,ma che sia insieme facile da manipolare e da interpretare

ROOT opera su alberi, ma non impone l’organizzazione dei dati

3

Prima idea: Ntupla

TTree* anaTree = new TTree("events", "analysis tree" );const int Nmus = 100;float* ptmu = new float[Nmus];int Nmuons = 0;anaTree->Branch("ptmu", ptmu, "ptmu[Nmuons]/F" );

Utilizziamo i costrutti di base del C++ (arrays, puntatori, tipi base) e di ROOT (TTree, TBranches)

Otteniamo l’obbiettivo: un file per l’analisi in ROOT

Ci siamo appiattiti sul minimo comune a CMSSW e ROOT !

mama

4

Semplicità solo apparente

Ci siamo dimenticati (come spesso succede) che il C++ e’ un linguaggio “a due livelli” (Carlo Pescio, C++ Informer 12, ottobre 2000):

Iniziamo cosi' a capire la natura "a due livelli" del C++, (…): il C++ offre un supporto nativo low-level per costruire astrazioni di piu' alto livello. Il programmatore dovrebbe lavorare con queste astrazioni, costruendole quando servono, e non lavorare costantemente al livello nativo.

Estremamente incline all’errore (riservato ai piu’ esperti)

1. Spesso nessun delete[].

2. Rischio di sforare il limite dell’array.

3. Impossibile il type-cheking a tempo di compilazione.

1. Memory leaks.

2. Errore a run-time con morte del programma.

3. Si perdono i vantaggi del controllo forte sui tipi.

5

Destrutturazione dell’evento

Vantaggio per pochi dati, immediatamente visibili

Vi sono raggruppamenti “logici” di alcune variabili (prefissi)

Mostra velocemente i suoi limiti al crescere del numero delle varibili

La Ntupla costituisce una rappresentazione “piatta” (flat) dell’evento, senza sotto-strutture

Dovrebbero essere ottenuti tramite le strutture (branches) di ROOT

6

Seconda idea: classi custom (adapter)

7

1. Numerose (una per ogni classe di CMSSW).2. Per loro stessa natura instabili, modificate spesso.3. Non standard, cosa che si cerca di evitare.

Ambedue i problemi che abbiamo visto possono essere risolti ricorrendo ad opportune astrazioni

Scrivere delle classi, che incapsulino i dettagli

Idea subito abbandonata (fortunatamente), poiché:

EDM dentro ROOT

8

Tutti i files di CMS sono in realtà files di ROOT,con una struttura gerarchica “naturale”

1. A ciascuna collezione corrisponde un ramo.2. A ciascuna variabile corrisponde una foglia.3. Esistono alias compatti e standardizzati.

Abbiamo solo bisogno di un sistema che ci isoli dalle variabili private, per loro stessa natura soggette a cambiamento...

E’ sempre possibile fare un’analisi “tipo rootupla”,

a partire da ogni file di CMSSW

Dal prompt o tramite le classi generate da MakeClass e (meglio) da MakeSelector

FWLite

9

Libreria (sottinsieme del FrameWork CMSSW) che consente di interpretare il contenuto dei files di CMS

gSystem->Load("libFWCoreFWLite");AutoLibraryLoader::enable();gSystem->Load("libDataFormatsFWLite");

TFile file(“rootFile.root" );

A questo punto, abbiamo acceso diretto alla struttura gerarchica definita dall’EDM di CMS, ma soprattutto

alle funzioni che costituiscono l’interfaccia delle classi.

In pratica…

Un esempio grafico…

10

… e due esempi dal prompt

11

Events->Draw("IC5CaloJet.theta():IC5CaloJet.phi()", "", "LEGO2 CYL")

Events->Draw("Muons.pt():Muons.isolationR03().sumPt/Muons.pt()", "Muons.pt()<100")

Vantaggi

12

E’ possibile visualizzare il contenuto di ogni file, così come

produrre istogrammi e matrici

Il codice è sostanzialmente identico a quello che utilizziamo

in CMSSW: nomi delle classi, delle funzioni, degli alias…

Non dipendiamo dalla traduzione operata da una classe di tipo EDAnalyzer

Una volta capito l’EDM, possiamo concentrarci

sull’obbiettivo dell’analisi

Tutte le proprietà degli oggetti che stiamo analizzando sono

sempre disponibili

Non devo ripassare per CMSSW se mi serve una

nuova variabile

Aggiungere dati all’evento

13

Se il prodotto è relativamente “stabile”

Scriviamo un EDProducer (non un EDAnalyzer)

Se e’ una cosa che cambia spesso (tipo la massa invariante calcolata

per diversi tagli)

Lavoriamo in ROOT, e salviamo il prodotto in un

albero friend

I due approcci non sono mutualmente esclusivi:il concetto di albero friend si applica al momento in cui i files

vengono aperti per l’analisi in ROOT

fwlite::Event

14

TFile file(“rootFile.root");fwlite::Event ev(&file);

for( ev.toBegin(); ! ev.atEnd(); ++ev) { //sort of iterator

fwlite::Handle<std::vector<reco::Muon> > muons; muons.getByLabel(ev,“Muons");

//now we can access data}

Event loop esplicito, ma astrazione dai dettagli dei Branches

1. fwlite::Handle muons;2. muons.getByLabel(ev, “Muons”)

1. edm::Handle muons;2. ev.getByLabel( “Muons”, muons)

Un esempio: la Z

15

Rosso: pt > 20 GeVRosso: pt > 20 GeV e 2 muoni

TFWLiteSelector

16

TFWLiteSelector eredita da TSelector

1. Impone di separare Begin/Process/Terminate.2. Nessun loop esplicito (gestito internamente).3. Supporta il parallelismo tramite PROOF.

Alla funzione Process viene passato edm::Event, non

fwlite::Event

Il codice di analisi è identico (non solo simile) a

quello dell’EDAnalyzer

Differenza fondamentale rispetto a fwlite::Event

TFWLiteSelector: in pratica

17

class MyAnalysisAlgorithm {public: void process( const edm::Event & ); void postProcess( TList & ); void terminate( TList & );};

Isoliamo l’algoritmo di analisi in una classe (o una

struct) a parte

TFile file(“rootFile.root");TSelector* mysel = new TFWLiteSelector<MyAnalysisAlgorithm>Events->Process( mysel );

Creiamo un’istanza di TFWLiteSelector passando l’algoritmo come template

TFWLiteSelector ed EDAnalyzer

18

Lo stesso algoritmo può essere eseguito in CMSSW

void MyAnalyzer::analyze(const edm::Event& ev, const edm::EventSetup& ) {

algo_.process( ev ); }

Basta scrivere un EDAnalyzer molto semplice e standard

(pattern Adapter, GoF)

L’algoritmo visto prima diventa un membro privato della classe EDAnalyzer

Soluzione ottima, ma non aggiornata al formato di CMSSW 2_1_X

In sintesi…

19

• Il C++ è un linguaggio “a due livelli”:– Le classi devono rappresentare elementi del problema.– Vantaggi programmazione Object-based (non ancora

Object-oriented, di cui non abbiamo parlato).• FWLite:

– Accesso completo dell’EDM di CMS.• TFWLiteSelector:

– Analisi “ordinata” e parallelizzabile.– Possibilità di muovere il codice da ROOT a CMSSW.

• Analisi agili a partire da ogni file di CMS:– Interpretare i risultati è già abbastanza complicato…