1 / 34

CMS Software: The Basic Tools

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,

azize
Télécharger la présentation

CMS Software: The Basic Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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/

More Related