Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi...

Claudio Grandi INFN-Bologna

L’ambiente per la simulazione e l’analisi in CMS

Claudio Grandi

INFN-Bologna

2Claudio Grandi INFN-Bologna

Attività principali

• Simulazione della fisica• Simulazione del rivelatore• Simulazione dell’elettronica• Simulazione del trigger

• Ricostruzione• Analisi

• La simulazione dell’elettronica viene chiamata digitizzazione


Attività principaliSimulazione della fisica

Simulazione del rivelatore

Geometria del

rivelatore

HITSDigitizzazione(Specifica di

CMS)

DIGI(raw data)

RicostruzioneDati perl’analisi

4-momenti

Simulazione del Trigger

Dati del Trigger

TriggerDIGI


PythiaZebra fileswith HITS

HEPEVTntuples

CMSIM(GEANT3)

MC

P

rod

.

ORCADigitization

(merge signaland pile-up)

ObjectivityDatabase

OR

CA

Pro

d.

ORCAooHit

FormatterObjectivityDatabase

Catalog import

Gli strumenti utilizzati

Level 1 Triggersimulation

HLT Algorithms Reconstructed

ObjectsHLT G

rp

Data

bases

ObjectivityDatabase

Catalog import

ObjectivityDatabaseObjectivityDatabaseytivitcejbOytivitcejbOesabataDesabataD

Mirro

red

Db

’s(U

S,R

ussia

,Italy

...)


Gli strumenti utilizzati

• Simulazione della fisica Pythia• Simulazione del rivelatore CMSIM (GEANT3)

• Simulazione dell’elettronica ORCA• Simulazione del trigger ORCA• Ricostruzione ORCA• Analisi ORCA+HBOOK+PAW ( +IGUANA)

C++/JAVA FORTRAN


ORCA e CARF Object Reconstruction for CMS Analysis

– digitizzazione del rivelatore– ricostruzione del rivelatore– simulazione del trigger– ricostruzione degli oggetti fisici – strumenti di analisi

CMS Analysis and Reconstruction Framework– immagazzinamento dei dati – framework per analisi e ricostruzione

• La proprietà di un dato di poter essere immagazzinato su disco è detta persistenza

Un oggetto non persistente è detto transiente


Programmare in ORCA

N.B. Non entrerò nel dettaglio di come funziona ORCA né di come si programma ad oggetti

• L’utente deve costruire un oggetto di analisi, che come tutti gli oggetti viene creato e distrutto

• L’oggetto analisi deve sapere quando viene letto un nuovo evento per poterlo analizzare– L’oggetto analisi si registra presso un servizio che sa

quando viene letto un nuovo evento per poter essere notificato al momento opportuno

• Il servizio che notifica la presenza di un nuovo evento viene chiamato Dispatcher, l’oggetto che si registra al Dispatcher si chiama Observer


Dispatcher/Observer

Obs1Obs1 Obs2Obs2 Obs3Obs3

DispatcherDispatcher

Obs4Obs4 ObserversObservers


Un oggetto di analisi• Tipicamente un’analisi deve eseguire qualcosa:

– all’inizio della sua vita

Nel costruttore dell’analisi– al set-up della geometria (della calibrazione, ecc…)

Deve essere Observer di SetUp– evento per evento

Deve essere Observer di Event– alla fine del processamento

Nel distruttore dell’analisi

• L’oggetto di analisi viene creato (come oggetto statico) semplicemente dichiarandolo!

PKBuilder<UserAnal> myAnal(“UserAnal”);


Il flusso del programma• In ORCA gli oggetti vengono prodotti solo quando

richiesti:– l’iniziatore del processamento è il codice utente– l’analisi deve conoscere solamente a chi chiedere gli

oggetti che vuole utilizzare senza conoscere le fasi precedenti del processamento!

– All’atto di una richiesta di alto livello viene iniziata una catena di richieste che arriva fino agli oggetti elementari (ad esempio i raw data). Le richieste vengono quindi soddisfatte ripercorrendo la catena in senso inverso

• La tecnica viene chiamata reconstruction on demand ed è implementata tramite LazyObserver


Lazy Observers

LazyLazyObs2Obs2

ObsObs

DispatcherDispatcher

LazyLazyObs1Obs1LazyLazyObs1Obs1obsoleteobsolete

LazyLazyObs2Obs2obsoleteobsolete

LazyLazyObs1Obs1uptodateuptodate

LazyLazyObs2Obs2uptodateuptodate


Esempio: il trigger di muoni

RPC DTBX CSC

RPCOn-chamber

TriggerElectronics

PACTPAttern

Comparator Trigger

RPCsorter

DTsorter

CSCsorter

Global muon Trigger

BTIBunch & Track Identifier

TRACOTRAck COrrelator

Trigger Server

DT MTTFMuon Trigger Track Finder

Wire card

motherboard

CSC MTTFMuon Trigger Track Finder

Strip LCTcard

Wire LCTcard

Strip card

Calorimeterquiet bits


Componenti DT on-chamber

Il TRACO costruisce tracce in unacamera correlando i segmenti deipiani R-

Il Trigger Server seleziona i migliori 2 segmenti della camera, sopprime i ghosts e passa le tracce al Trigger Regionale

Il BTI trova segmenti in un quadrupletto e assegna il BX utilizzando una tecnica di mean-timer


Pacchetti in ORCAInterfaccia all’utente System setup

ConfigurazioneGeometriaecc...

Simulazione delle componenti del trigger


Diagramma delle classiOggetti vistidall’utente

Si attivano solamente quandol’output del trigger è richiesto

Camere e TriggerUnits sono in corri-spondenza 1-1


Interaction diagram per il BTIQuando l’output è richiestoQuando un evento è letto


Esempio di codice utente#include “...” // All needed include files here

class UserAnal : ActiveObserver<G3EventProxy*> {

public:

UserAnal() {}

virtual ~UserAnal() {}

void upDate(G3Eventproxy* ev) {

// Processing an event...

L1MuDTTrigSetup* setup = Singleton<L1MuDTTrigSetup>::instance();

L1MuDTTrig* dttrig = setup->DTTrig();

//define chamber (iwh,ist,ise) and BX (is)

int iwh=…;int ist=…;int ise=…;int is=…;

L1MuDTChambPhSegm* first = dttrig->chPhiSegm1(iwh,ist,ise,is);

L1MuDTChambPhSegm* second = dttrig->chPhiSegm2(iwh,ist,ise,is);

L1MuDTChambThSegm* theta = dttrig->chThetaSegm(iwh,ist,ise,is);

}

};

#include “Utilities/Notification/interface/PackageInitializer.h”

PKBuilder<UserAnal> myAnal(“UserAnal”);


SCRAM e CVS

Software Configuration, Release And Management

– Sviluppato da CMS – Compilazione e link dei programmi (build)– Gestione della configurazione– Distribuzione dell’ambinete di siluppo– condivisione delle risorse

Concurrent Versioning System– Gestione del codice sorgente (anche in sviluppo!)

• Il processo di copilazione e creazione di librerie, link di un eseguibile, ecc... viene detto build


Comandi frequentiscram list lista dei progetti disponibili

scram project ORCA ORCA_4_0_0 installazione di una directory di sviluppo per ORCA 4.0.0

scram b build delle librerie o degli eseguibili

eval `scram runtime -csh` definizione dell’ambiente per buid e running

cvs co Examples/ExProduction copia il codice da CVS alla directory di lavoro

• repository dove CVS tiene il codice checkout/commit copia dal repository alla

directory di lavoro e viceversa head l’ultima versione disponibile nella

repository tag una versione a cui è stato dato un nome


La struttura delle directories

Top Directory

srclibbin tmpconfig logs.SCRAM

subsys OSOS OSOS

subsyscodice sorgente(checkout + utente)

files temporanei(files oggetto, dipendenze, ecc...)

librerie (incluso in$LD_LIBRARY_PATH)

configura-zioni per il build

creata da scram project ...

eseguibili (incluso in $PATH)

configurzioni per i pacchettiesterni

logfiles


Struttura per un sottosistema

Sub-systemtop Directory

srcinterface

package

test

domain

stubsinterfacce (.h, .icc)

implementazione dei metodi (.cc) .h e .cc per

librerie di test

informazionisul dominio(doc, html, ecc...) programmi

utente pertest(.cpp, .cc)


Librerie• Viene prodotta una libreria per ogni

sottosistema. Per crearla si usa scram b nella top directory del sottosistema– shared (libxxx.so): funzioni caricate a run-time

• si possono ricompilare le librerie senza dover ri-linkare!• le librerie devono essere disponibili a run-time

– archive (libxxx.a): funzioni attaccate all’eseguibile– debug (libxxx_d.so e libxxx_d.a): ogni libreria

può essere compilata con l’opzione per il debugger (lenta! occupa molto spazio!)

– per default vengono create shared e shared_debug• Editare top_dir/config/library_makefile.mk per

avere solo le shared (se è il caso!)


Il sotto-dominio Workspace

• Contiene i programmi utente • Assomiglia alla directory test di un package• E’ il posto in cui lavorare!• Per la configurazione si usa il file: top_dir/config/Worksapce_makefile.mk

• Se fate il check-out di Workspace avete alcuni programmi di esempio e files per la configurazione dell’ambiente oltre ad un esempio di BuildFile (vedi oltre...)


BuildFile• Sono l’equivalente dei Makefile unix e sono

invocati da scram b (in test o Workspace)• Contengono le informazioni sulle librerie:

<ignore>commenti</ignore>

<External ref=cern>

<External ref=cmsim>

<lib name=L1MuDTTrigger>

<use name=Muon>

<use name=CARF>

<use name=Utilities>

<bin file=ExProdRead.cpp>

Commenti sull’eseguibile

</bin>

include prodotti esterni

include la libreria di un package

include tutte le libreriedi un sotto-dominio

sorgente dell’eseguibile


Parametri

• Gran parte dei parametri (nomi dei files, numero di eventi, informazioni per il pile-up, ecc..) sono passati ai programmi tramite variabili ambientali unix

• Alcuni parametri di configurazione sono scritti nel file .orcarc che viene cercato nella directory di lavoro

• L’interfaccia per l’uso del database (Objectivity) è in fase di sviluppo (molti cambiamenti in ORCA 4 rispetto ad ORCA 3!!!)


Input files

• In ORCA 3 era possibile leggere direttamente gli HITS di GEANT dai files .fz e fare tutta l’analisi in modo transiente

• In ORCA 4 l’analisi può essere fatta solamente a partire da databases di Objectivity

• Esiste un programma speciale di ORCA che viene chiamato ooHitFormat che “copia” gli HITS di GEANT dai files .fz ai databases di Objectivity senza fare alcun processamento


Objectivity/DB• Objectivity/DB (Objy) è un database ad

oggetti. Ciò significa che i dati sono salvati in strutture complesse e non in strutture lineari– Vi ricordate: COMMON/MZSTORE/...ISTORE(BIGNUMBER)???

• Ogni oggetto è caratterizzato da un identificatore. Questo permette di usare un efficiente sistema di puntatori per navigare nel database

• Ogni oggetto è creato a partire dalle informazioni contenute nell’header file– sono possibili strutture arbitrariamente complesse!!!


Componenti di Objy


Un po’ di lessico di Objy

Federazione: è il punto d’ingresso al sistema di databases

Schema: contiene la struttura degli oggetti. E’ salvato nella federazione

Database: coincide fisicamente con un file Boot file: contiene le informazioni per

entrare nella federazione Lock server: è un processo che gestisce gli

accessi concorrenti ai files delle federazioni AMS server: è un processo che permette di

accedere ai databases remoti Container: le unità logiche in cui è diviso un

database


Uso di Objy con ORCA

• Ogni utente si crea una propria federazione di sviluppo

• La variabile ambientale $OO_FD_BOOT punta al boot file della federazione

• I databases coi dati possono essere attaccati alla federazione privata in read-only

• Se si vogliono solamente analizzare i dati senza modificare gli schemi o creare nuovi databases, si può usare la federazione comune di analisi (attualmente quelle dei gruppi HLT)


Documentazione

• Pagine web:– http://cmsdoc.cern.ch/orca ORCA– http://cmsdoc.cern.ch/orca/tutorials/index.html tutorial di ORCA 3

– http://cmsdoc.cern.ch/Releases/SCRAM/current/doc/html/index.html SCRAM

– http://www.loria.fr/~molli/cvs/doc/cvs_toc.html CVS

– http://wwwinfo.cern.ch/asd/lhc++/Objectivity/index.html Objectivity

Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi...

Documents

Transcript of Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi...