Nicola Amapane Tommaso Boccali (SNS Pisa)

Presentazione sul tema: "Nicola Amapane Tommaso Boccali (SNS Pisa)"— Transcript della presentazione:

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

2 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!

3 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

4 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>

5 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!

6 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!

7 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

8 I Subsystem di ORCA

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

10 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”

11 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

12 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

13 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!

14 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  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!

15 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

16 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!

17 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…

18 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

19 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

20 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!!!!

21 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>

22 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

23 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>

24 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!

25 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!

26 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

27 .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

28 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

29 Sì ma dove li trovo? A regime, su:
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)

30 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: 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)

31 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

32 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)

33 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

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