CMS Software:
The Basic Tools
Nicola Amapane
Tommaso Boccali (SNS Pisa)
Torino, 14-16 Aprile 2003
Outline
• Dove è il codice?
• Come compilo?
• Come eseguo?
• Come trovo la documentazione?
• Come scrivo ntuple, o ROOT files?
Parleremo di ORCA,
ma lo stesso vale anche per gli altri progetti!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
2
SCRAM è la chiave di tutto
Software Configuration, Release And Management
Gestisce:
– Ambiente
• Configurazione di tool e librerie esterne
• Inizializzazione variabili di ambiente
• Path di eseguibili e librerie a runtime
– Compilazione e link
• Opzioni di compilazione, compilatori
• Dipendenze e ricompilazione parziale
• Link delle librerie corrette
Documentazione: da
http://cmsdoc.cern.ch/cmsoo/cmsoo.html
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
3
SCRAM: i primi passi
• Aiuto:
scram help
• Elencare i progetti e le versioni diponibili:
scram list
scram list [project]
• Creare l’ambiente impostando tutte le dipendenze ed i tool
per una versione di un certo progetto (ORCA, OSCAR…):
scram project <project> <version>
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
4
Creare un’area ORCA
• Esempio: usare il più recente prerelease di ORCA:
scram project ORCA ORCA_7_2_0_pre13
Viene creata la directory “ORCA_7_2_0_pre13” con alcune
sottodirectory:
.SCRAM/, config/
tmp/
lib/
bin/
src/
mantengono la configurazione di SCRAM
directory di lavoro di SCRAM
conterrà le librerie compilate
conterrà gli eseguibili
conterrà il codice
• Voi utilizzerete solo src/
– Il resto è gestito automaticamente!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
5
src/, lib/, bin/
…inizialmente sono vuote!
• Esiste una “release area” centrale con tutto il codice e le
librerie precompilate per una data versione.
• Dovete scaricare solo il codice che volete modificare
– Durante la compilazione, gli header vengono presi dalla repository
se non sono presenti sotto src/
– Durante il link ed a runtime, le librerie vengono prese dalla
repository se non sono presenti sotto lib/
– Quando compilate, le librerie sono create automaticamenrte sotto
lib/ e gli eseguibili sotto bin/
Don’t worry - SCRAM si occupa di questo per voi!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
6
Struttura del codice
• ORCA è strutturato a SubSystems e Packages, a tre livelli
– E’ necessario per gestire le dipendenze fra pacchetti
– A questa struttura corrisponde 1:1 una struttura di directory
– Per ogni package viene creata una libreria!
ORCA
SubSystem 1
Package 2
Package 1
Package 3
N. Amapane, T. Boccali
SubSystem 1
SubSystem 1
Package 1
Package 2
Package 3
Torino, 14-16 Aprile 2003
Package 1
Package 2
7
I Subsystem di ORCA
http://cmsdoc.cern.ch/cmsoo/cmsoo.html
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
8
All’ interno di ogni pacchetto c’è un’ulteriore struttura:
• interface/
contiene l’interfaccia delle classi, è la sola informazione
importante per un developer che debba utilizzarle.
• src/
Contiene l’implementazione delle classi, (da guardare per
modificare o per capire meglio l’algoritmo usato)
• test/
contiene codice utile per testare il package, esempi, ecc.
• doc/
documentazione del pacchetto (!)
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
9
Scaricare il codice
• CVS (Concurrent Versions System) è un tool che permette
lo sviluppo parallelo del codice da parte di più persone
– Ognuno lavora su una copia personale
– Si possono recuperare le modifiche fatte da altri e rendere
disponibili le proprie
– Mentre il software è in continua evoluzione, è possibile “congelare”
una versione funzionante e stabile e darle un nome (TAG)
• Per iniziare: indicare dove è la “repository”
– In CMS abbiamo due facili script per fare questo, a seconda che voi
siate registrati come developer oppure no:
• Developers (read/write access): project ORCA
• non developers: cmscvsroot ORCA; cvs login
la password è “98passwd”
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
10
CVS checkout
Per scaricare il pacchetto XXX/YYY
cvs co –r <tag> <file o directory>
– Viene scaricato nella directory corrente!
• Dovete assicurarvi di mettere i pacchetti nel posto giusto
– Esistono delle convenzioni sui nomi dei tag
• e.g. “ORCA_7_1_1” o “ORCA_7_2_0_pre13”
– Se non si specifica –r <tag> viene presa la versione più recente di
ogni file
• Che tipicamente non funziona!
Provate con il tag ORCA_7_2_0_pre13 di MuonAnalysis/MuonTutorial
– Attenzione a rispettare la struttura delle directory: dovete avere
ORCA_7_2_0_pre13/src/MuonAnalysis/MuonTutorial
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
11
CVS
Altre funzionalità:
• cvs diff
– Diff fra la propria versione e la repository
• cvs log
– Storia delle modifiche nella repository
• cvscheck
– Quali file sono cambiati?
• cvs commit
– Inserire le proprie modifiche nella repository
http://www.cvshome.org/docs/
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
12
Compilazione
• Molto complicato!
–
–
–
–
Diversi sistemi (SUN, Linux RH6, Linux RH7)
Quali opzioni di compilazione?
Dove prendo i pacchetti che non ho scaricato?
Tool esterni: dove? quale versione?
• CLHEP, GEANT, ROOT, Objectivity, COBRA, IGUANA...
Meno male che ci pensa SCRAM!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
13
Ad-interim!
In questo momento sono in corso due importanti transizioni:
– RedHat 6  RedHat 7
• ORCA dalla versione 7 in poi è sviluppata solo su RedHat 7
– gcc 2.95.2  gcc 3.2
• La prima è ancora default ma verrà abbandonata presto
• Noi stiamo guardando ORCA_7_2_0_pre13 e vogliamo gcc3:
setenv SCRAM_ARCH Linux__2.4/gcc3
eval `scram runtime –csh`
– Quest’ ultimo comando imposta tutte le variabili di ambiente
necessarie anche per la corretta esecuzione di un job!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
14
Compilazione
• Per compilare si usa semplicemente:
scram build (oppure scram b)
– Compila tutti i pacchetti che trova nella directory corrente e sue
sottodirectory:
ORCA_7_2_0_pre13/src/MuonAnalysis/MuonTutorial/src
Da qui compila tutto
quello che avete scaricato
Da qui tutti i pacchetti
di MuonAnalysis
Da qui solo
MuonAnalysis
– In ogni pacchetto, viene creata una libreria usando tutti i file src/*.cc
– Provate a compilare MuonTutorial!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
15
Compilazione
Beh, non succede nulla!
– SCRAM si è accorto che non avete cambiato nulla rispetto alla
release area, e allora perché ricompilare?
• Facciamo touch di un file .cc in src/, e riproviamo.
touch MuonTrackPrinter.cc
scram b
• Ora questo file viene ricompilato e la libreria ricreata!
– Andando a vedere in lib/, dovrebbe essere apparsa la libreria!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
16
Pulizia!
• Se volete eliminare tutto quello che avete compilato
scram b clean
– Cancella tutti gli oggetti intermedi (.o)
– E’ utile se si fanno grossi pasticci…
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
17
Eseguibili
• Ok, la libreria è compilata. Ma come creo un programma
eseguibile?
• Il main ci è fornito da COBRA (il framework).
– Noi non creeremo (quasi) mai un main() alla C++, che abbia il
controllo flusso del programma
– Il nostro codice è in una libreria che viene caricata a runtime
• Dobbiamo chiedere a COBRA:
– Di istanziare le nostre classi: usando PKBuilder<class>
– Di chiamare alcuni metodi quando appropriato: usando il
meccanismo di Dispatcher/Observer
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
18
Linking
• Per creare un eseguibile devo fare il “link” della mie classi
con:
–
–
–
–
–
–
–
il framework
l’API dei database
la geometria
la ricostruzione
il sistema grafico
le librerie matematiche
Ecc. ecc.
• Anche qui ci aiuta SCRAM, ma ha bisogno di istruzioni:
il BuildFile
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
19
Il BuildFile
Serve ad “aiutare”
scram specificando
quali librerie devono
essere linkate.
<environment>
<group name=G3>
<group name=RecReader>
<External ref=COBRA Use=CARF>
<group name=MuonReconstruction>
<use name=MuonReco>
<group name=L1GlobalMuon>
<use name=Trigger>
<group name=MuonTrackFinder>
<use name=Muon>
<use name=CommonReco>
<use name=CommonDet>
<External ref=COBRA Use=Utilities>
<External ref=COBRA Use=MagneticField>
<lib name=MuonTutorial>
<bin file=printMuonTracks.cpp></bin>
</environment>
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
20
Il BuildFile
Un environment definisce le
librerie per un eseguibile, in
questo caso quello creato a
partire da printMuonTracks.cpp,
specificato nella direttiva <bin>
<environment>
<group name=G3>
<group name=RecReader>
<External ref=COBRA Use=CARF>
<group name=MuonReconstruction>
<use name=MuonReco>
<group name=L1GlobalMuon>
<use name=Trigger>
<group name=MuonTrackFinder>
<use name=Muon>
<use name=CommonReco>
<use name=CommonDet>
<External ref=COBRA Use=Utilities>
<External ref=COBRA Use=MagneticField>
<lib name=MuonTutorial>
<bin file=printMuonTracks.cpp></bin>
</environment>
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
21
Il BuildFile
Le direttive <External>
specificano che abbiamo
bisogno di librerie non
appartenti a ORCA
<environment>
<group name=G3>
<group name=RecReader>
<External ref=COBRA Use=CARF>
<group name=MuonReconstruction>
<use name=MuonReco>
<group name=L1GlobalMuon>
<use name=Trigger>
<group name=MuonTrackFinder>
<use name=Muon>
<use name=CommonReco>
<use name=CommonDet>
<External ref=COBRA Use=Utilities>
<External ref=COBRA Use=MagneticField>
<lib name=MuonTutorial>
<bin file=printMuonTracks.cpp></bin>
</environment>
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
22
Il BuildFile
<lib> e <group>
specificano di linkare
librerie o gruppi di librerie
<use> specifica di
cercare le definizioni dei
gruppi in altri subsystem
<environment>
<environment>
<group
name=G3>
<External ref=Objectivity>
<group name=RecReader>
<External ref=HepODBMS>
<External ref=COBRA Use=CARF>
<Group name=G3>
<group name=MuonReconstruction>
<External ref=COBRA
<use
name=MuonReco>
Use=GeneratorInterface>
<group
name=L1GlobalMuon>
<group name=TkTrackWriter>
<use
name=Trigger>
<group
name=TrackAnalysis>
<lib name=TkRecoDebugTools> </lib>
<group
<use name=MuonTrackFinder>
name=TrackerReco>
<use name=Muon>
<use
name=CommonReco>
<External
ref=COBRA Use=MagneticField>
<use name=CommonDet>
<External
ref=COBRA Use=Utilities>
<group name=RecReader>
<External
ref=COBRA
<External
ref=COBRA Use=MagneticField>
Use=CARF>
<lib
name=MuonTutorial>
<External
ref=COBRA Use=Utilities>
<bin
file=TrackPersistentTest.cpp></bin>
<bin
file=printMuonTracks.cpp></bin>
</environment>
</environment>
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
23
Linking
• Normalmente gli eseguibili ed i relativi BuildFile sono messi
nella directory test/ di ogni pacchetto.
• Per crearli basta andare in questa directory e fare
scram b
• L’eseguibile viene messo in bin/, che scram ha aggiunto al
vostro path!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
24
Pacchetti “speciali”
Alcune importanti eccezioni alla struttura che ho descritto:
• Examples
– Questo subsystem contiene molti esempi e programmi di uso
comune per la produzione di eventi (ExProduction)
– I pacchetti di Examples non hanno le sottodirectory interface/, src/,
test/
– Li useremo anche noi!
• Workspace
– Questo “subsystem” non ha pacchetti nè sottodirectory. Contiene
una struttura semplice che potete usare per dei test veloci
– Provate a scaricarlo e compilarlo!
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
25
Esecuzione
• Coraggio, mancano solo 2 passi:
• configurare l’ambiente runtime (path, variabili d’ambiente)
eval `scram runtime –csh` (lo avete già fatto!)
rehash (se il vostro eseguibile è stato creato dopo il comando
precedente)
• Fornire opzioni all’eseguibile e al framework
– con il file .orcarc nella directory di esecuzione
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
26
.orcarc
Verbose:test = 0
opzioni che controllano la
“verbosita’” del codice; abilitano
dei printout di debug/info etc.
CMSRandom:Seeds = 40 3
Numero random iniziale
(importante per la riproducibilita’)
Verbose:info = 1
FirstEvent = 0
MaxEvents
= 20
Da quale evento cominciare
quanti eventi processare
FilePath = suncmsc:/data/valid/ORCA_7_2_0_pre13
FileProtocol = rfio
InputCollections =
/System/NoPileUpTk/single_muminus_pt50/single_muminus_pt50/
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
27
Come si specificano i campioni?
• FilePath
– Se non specificato, usa la directory corrente
– Può essere una directory locale, eg.
FilePath = /data/ORCA_7_2_0
– o remota a cui si accede via RFIO
FileProtocol = rfio
FilePath = suncmsc:/data/valid/ORCA_7_2_0_pre13
oppure
FilePath = /castor/cern.ch/user/U/USERNAME/tutorial
• InputCollections
InputCollections =
/System/NoPileUpTk/single_muminus_pt50/single_muminus_pt50/
OWNER
(e.g. per diverse
luminosità)
N. Amapane, T. Boccali
DATASET
Torino, 14-16 Aprile 2003
Tutto il dataset
(oppure un solo run,
una collezione)
28
Sì ma dove li trovo?
• A regime, su:
http://cmsdoc.cern.ch/cms/production/www/html/general/index.html
• Attualmente, ci sono solo campioni scritti su Objectivity/DB
– I campioni usati per il DAQ TDR
– Usabili sono con ORCA 6 
• Esistono dei campioni di prova per ogni (pre)release di
ORCA 7
FilePath = suncmsc:/data/valid/<ORCA_VERSION>
– Potete accederci con RFIO (rfdir, rfcp)
– Esiste uno script per fare la lista dei dataset (rfdumpcatalog)
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
29
Workspace: ExRunEvent
• Esempio elementare: contiamo gli eventi!
– In realtà meno di quanto sembri, dato che analizzaremo eventi con
pile-up.
– per ogni evento di segnale, quanti eventi di pile up ci sono?
• Guardiamo l’esempio in Workspace
– La nostra classe è un Observer<G3EventProxy*>, cerchiamo
G3EventProxy nella documentazione di COBRA:
http://cobra.web.cern.ch/cobra/COBRA_7_2_0/doc/ReferenceManual/html/classes.html
– Troviamo, fra l’altro, il metodo G3EventProxy::pileups()
– Ad ogni evento di pile-up (SimPU) possiamo chiedere
id().eventInRun() e id().runNumber()
– Lo stesso possiamo chiedere all’evento di trigger (SimSignal)
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
30
Proviamo!
• Avete gia’compilato Workspace!
• Guardate/modificate il .orcarc
– Scegliete un campione a bassa luminosità
• Eseguite!
ExRunEvent
• Su 100 eventi dovreste avere ~3150 eventi di Pile up
– Considerando che a bassa luminosità 3.5 eventi sono attesi per
Bunch-Crossing, e consideriamo i bunch crossing [-5,+3] (sono 9),
ci aspettiamo 3.5 x 100 x 9 = 3150 eventi
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
31
Giochiamo!
• Esercizi (Cercate sulla documentazione di COBRA)
– Stampate l’evento di trigger
• Hint: SimSignal()::Print()
– Modificate il codice in modo da stampare l’elenco delle paricelle
generate per l’evento di trigger
• Hint: SimSignal()::genparts()
– Stampate solamente il pile-up in-time
• Hint: G3EventProxy::pileups(int minb, int maxb)
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
32
Ntuple, Trees, etc.
• Esempio di scrittura di un’ntupla:
– Examples/HBook
• Esempio di scrittura di ROOT files:
– Examples/Root
– Per la scrittura di Tree: MuonAnalysis/MuonHLTSelection
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
33
Bugs!
• Savannah!
https://lcgappdev.cern.ch/savannah/projects/orca/
N. Amapane, T. Boccali
Torino, 14-16 Aprile 2003
34