Nicola Amapane Tommaso Boccali (SNS Pisa) CMS Software: The Basic Tools Nicola Amapane Tommaso Boccali (SNS Pisa) Torino, 14-16 Aprile 2003

ma lo stesso vale anche per gli altri progetti! 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!

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

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>

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/ mantengono la configurazione di SCRAM tmp/ directory di lavoro di SCRAM lib/ conterrà le librerie compilate bin/ conterrà gli eseguibili src/ conterrà il codice Voi utilizzerete solo src/ Il resto è gestito automaticamente!

Don’t worry - SCRAM si occupa di questo per voi! 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!

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 1 Package 2 Package 3

I Subsystem di ORCA http://cmsdoc.cern.ch/cmsoo/cmsoo.html

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 (!)

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”

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

CVS Altre funzionalità: cvs diff cvs log cvscheck cvs commit 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/

Meno male che ci pensa SCRAM! 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!

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!

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 In ogni pacchetto, viene creata una libreria usando tutti i file src/*.cc Provate a compilare MuonTutorial! Da qui compila tutto quello che avete scaricato Da qui tutti i pacchetti di MuonAnalysis Da qui solo MuonAnalysis

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!

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…

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

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

Il BuildFile <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> Serve ad “aiutare” scram specificando quali librerie devono essere linkate. XML!!!!

Il BuildFile <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> Un environment definisce le librerie per un eseguibile, in questo caso quello creato a partire da printMuonTracks.cpp, specificato nella direttiva <bin>

Il BuildFile <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> Le direttive <External> specificano che abbiamo bisogno di librerie non appartenti a ORCA

Il BuildFile <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> <lib> e <group> specificano di linkare librerie o gruppi di librerie <use> specifica di cercare le definizioni dei gruppi in altri subsystem <environment> <External ref=Objectivity> <External ref=HepODBMS> <Group name=G3> <External ref=COBRA Use=GeneratorInterface> <group name=TkTrackWriter> <group name=TrackAnalysis> <lib name=TkRecoDebugTools> </lib> <use name=TrackerReco> <External ref=COBRA Use=MagneticField> <group name=RecReader> <External ref=COBRA Use=CARF> <External ref=COBRA Use=Utilities> <bin file=TrackPersistentTest.cpp></bin> </environment>

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!

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!

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

.orcarc Verbose:info = 1 Verbose:test = 0 CMSRandom:Seeds = 40 3 FirstEvent = 0 MaxEvents = 20 FilePath = suncmsc:/data/valid/ORCA_7_2_0_pre13 FileProtocol = rfio InputCollections = /System/NoPileUpTk/single_muminus_pt50/single_muminus_pt50/ opzioni che controllano la “verbosita’” del codice; abilitano dei printout di debug/info etc. Numero random iniziale (importante per la riproducibilita’) Da quale evento cominciare quanti eventi processare

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à) Tutto il dataset (oppure un solo run, una collezione) DATASET

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)

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)

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

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)

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

https://lcgappdev.cern.ch/savannah/projects/orca/ Bugs! Savannah! https://lcgappdev.cern.ch/savannah/projects/orca/