CMS Software: The Basic Tools

1. CMS Software: The Basic Tools Nicola AmapaneTommaso Boccali (SNS Pisa) Torino, 14-16 Aprile 2003

2. 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 http://cmsdoc.cern.ch/cmsoo/cmsoo.html

4. SCRAM: i primi passi • Aiuto: scram help • Elencare i progetti e le versioni diponibili: scram listscram 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 solosrc/ • Il resto è gestito automaticamente!

6. 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. ORCA SubSystem 1 SubSystem 1 SubSystem 1 Package 2 Package 1 Package 1 Package 1 Package 2 Package 3 Package 2 Package 3 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!

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

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 • 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/

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

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 tuttoquello che avete scaricato Da qui tutti i pacchettidi MuonAnalysis Da qui soloMuonAnalysis

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 compilatoscram 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> <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> <lib> e <group> specificano di linkare librerie o gruppi di librerie <use> specifica di cercare le definizioni dei gruppi in altri subsystem

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 opzioni che controllano la “verbosita’” del codice; abilitano dei printout di debug/info etc. 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/ 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/ Tutto il dataset(oppure un solo run,una collezione) OWNER(e.g. per diverse luminosità) DATASET

29. 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)

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

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. Bugs! • Savannah! https://lcgappdev.cern.ch/savannah/projects/orca/