Cluster Multiplicity

Preparazione area di lavoro

Prerequisiti per usare git

  • Creati un account su www.github.com. Qui http://cms-sw.github.io/faq.html#how-do-i-subscribe-to-github dovrebbero esserci le istruzioni.
  • Seguendo le istruzioni dovrai anche fare quello che e' descritto qua: https://help.github.com/articles/generating-ssh-keys per poter collegarsi a github dalla tua sessione di lxplus senza avere bisogno di usare username e password del tuo account di github. La regola piu' o meno e': se hai configurato per bene github per usare le tue keys di ssh, allora i repository remoti che potrai usare (vedi git remote -v descritto piu' sotto) hanno una forma del tipo git@github.com:/.git Altrimenti devi usare quelli della forma http://www.github.com//.
  • Crea un file chiamato .gitconfig nella home directory che contiene:
[user]
   github = <tuo username su github>
   name = <Nome> <Cognome>
   email = <indirizzo e-mail>
[core]
   excludesfile = <tua home directory>/.gitignore_global
[color]
   ui = true
[alias]
   l = log --graph --all --abbrev-commit --date=relative --format=format:'%C(bold blue)%h%C(reset) %C(green)%ar %C(yellow)%an%C(bold yellow)%d%C(reset)%n %C(white)%s%n'

Creazione area di lavoro

Per creare un area di lavoro con CMSSW_7_1_0 su lxplus eseguire:
cmsrel CMSSW_7_1_0
cd CMSSW_7_1_0/src
cmsenv
Per avere il codice sorgente del pacchetto DPGAnalysis/SiStripTools nell'area di lavoro bisogna inizializzare git nell'area di lavoro e poi fare checkout dopo avere configurato git per fare lo sparse checkout ossia per scaricare solo determinati pacchetti:
git clone -b CMSSW_7_1_X -n git@github.com:cms-sw/cmssw.git $CMSSW_BASE/src    # l'opzione "-n" significa che non viene scaricato nessun pacchetto dal repository remoto. Il parametro dell'opzione "-b" e' il nome del branch che ci interessa e gli ultimi due parametri sono il repository remoto (quello ufficiale di CMSSW) e la directory dove viene clonato il branch del repository
git config core.sparsecheckout true   # viene attivato lo sparse checkout
echo DPGAnalysis/SiStripTools > .git/info/sparse-checkout  # viene scritto un file che contiene la linea "DPGAnalysis/SiStripTools" che e' il pacchetto che vogliamo
git checkout # vengono scaricati tutti i pacchetti ma siccome e' attivo lo sparse checkout, viene scaricato solo quello definito nel file.
A questo punto dovrebbe essere comparsa la directory DPGAnalysis che contiene la directory SiStripTools. Se usi il comando git branch vedrai che c'e' un solo branch definito ed e' preceduto da un asterisco che indica quale e' il branch a cui punta la HEAD del tuo repository locale (quello che abbiamo appena creato clonando quello remoto di CMSSW). Con il comando git remote -v ti dice quali sono i repository remoti con i quali puo' interagire il tuo repository locale. Il primo nome, origin, e' il nome che devi usare nei diversi comandi e quello che segue, che non avresti visualizzato se non avessi usato l'opzione -v, e' l'indirizzo remoto. Con il comando git l che e' un alias definito nel file .gitconfig creato prima, si ha un'idea della struttura delle varie modifiche a CMSSW e archiviate in git. A questo punto per compilare bisogna eseguire
scramv1 b

Esecuzione dei programmi

Mappa della cluster/hit occupancy

Queste sono le istruzioni per produrre risultati simili a quelli presentati in questa pagina. I moduli/sensori del tracciatore sono suddivisi in sottoinsiemi (in questo caso disgiunti ma il programma di analisi funziona anche se non lo sono) definendo delle selezioni usando la classe DetIdSelector e quindi vengono riempiti dei TProfile con il numero medio di cluster (o di singole strip accese) per evento in ogni sottoinsieme (ogni bin riempito del TProfile e' un sottoinsieme). Vengono poi riempiti anche degli istogrammi ausiliari che permettono di normalizzare il numero medio di cluster al numero di canali in ciascun sottoinsieme e di calcolare la posizione media dei moduli di ciascuno sottoinsieme per fare le mappe. Utilizzando eventi selezionati con un trigger di ZeroBias il numero di cluster/hit sara' proporzionale al pileup e quindi alla luminosita' istantanea. Altrimenti bisogna tenere in conto anche del bias introdotto dal trigger.

File di configurazione

Il file di configurazione da cui partire e' DPGAnalysis/SiStripTools/test/OccupancyPlotsTest_cfg.py che puo' essere copiato nella directory src dell'area di lavoro: cp DPGAnalysis/SiStripTools/test/OccupancyPlotsTest_cfg.py . in modo da poi poterlo modificare. Attenzione prima di poterlo utilizzare bisogna aprirlo ed editarlo per commentare ogni riferimento a bxlumianalyzer che e' in un pacchetto software non nella release. Quindi bisogna commentare la linea process.load("TrackingPFG.Utilities.bxlumianalyzer_cfi") = e togliere o commentare =process.bxlumianalyzer dalla definizione di una delle cms.Sequence. Altre modifiche da fare sono:
  • nella linea process.MessageLogger.cout.threshold = cms.untracked.string("WARNING"), sostituire WARNING con INFO. E' il livello minimo dei messaggi che saranno stampati in cout
  • sostituire il valore di limit in process.MessageLogger.cout.default con 0, in modo che, di default, nessun messaggio venga stampato in cout
  • aggiungere le linee
process.MessageLogger.cout.FwkSummary = cms.untracked.PSet(
    limit = cms.untracked.int32(10000)
    )
dopo la configurazione di process.cout.FwkReport in modo da stampare il summary in cout
  • sostituire -1 con options.maxEvents in process.maxEvents = cms.untracked.PSet( input = cms.untracked.int32(-1) ) in modo da poter controllare il numero di eventi da analizzare da linea di comando con il parametro maxEvents
Siccome, spesso, nei file configurazione prima di ogni esecuzione di cmsRun bisogna modificare qualche parametro (file di input, numero di eventi, file di output, GlobalTag,...) in questo file di configurazione viene utilizzato il pacchetto VarParsing che permette di passare dei parametri dalla linea di comando quando viene eseguito cmsRun. La descrizione del pacchetto e' in questa pagina e in questa pagina. Ispezionando il file ci sono istruzioni che definiscono la variabile options del tipo analysis, che aggiungono la definizione di altri parametri da passare da linea di comando oltre a quelli predefiniti nel tipo analysis e poi questi parametri del tipo =options. vengono usati nella configurazione al posto del valore. In questo file di configurazione di usano:
options.inputFiles
options.triggerPath
options.HLTprocess
options.globalTag
Quando non vengono passati nella linea di comando, viene usato il valore di default definito nel file di configurazione. Per eseguire un file di configurazione che usa VarParsing la sintassi e':
cmsRun OccupancyPlotsTest_cfg.py print inputFiles=... triggerPath="..." ...
dove print permette di stampare una tabella con i valori dei parametri. Nel caso in cui il valore di un parametro sia una stringa, usare le virgolette non guasta. Inoltre per parametri come inputFiles nel caso si voglia passare piu' di un file di input, si possono mettere in un file e sostituire inputFiles con
inputFiles_load=<nome del file con elenco infputfiles>
Di solito i file di configurazione caricano altri file di configurazione del tipo cfi o cff usando comandi come import o process.load. Per cui bisogna o sapere quello che c'e' in questi file o fidarsi che c'e' quello che serve. Per avere una visione completa di tutta la configurazione il modo piu' semplice e' quello di aggiungere alla fine del file di configurazione la linea
print process.dumpPython()
(o togliere il simbolo della linea commentata # se c'e' gia') ed eseguire:
python OccupancyPlotsTest_cfg.py > temp.out
Fatto questo ispezionando il file temp.out la prima cosa da cercare sono le definizioni dei cms.Path (in questo caso solo uno) che contengono i nomi dei moduli (process.) o delle cms.Sequence che a loro volta contengono altri moduli o sequenze. cmsRun eseguira' tutti i path definiti del file di configurazione. Nel file temp.out le definizioni di tutti i moduli (e di molti altri che poi non sono utilizzati nei path) sono complete e non c'e' bisogno di cercare dovunque nel file per eventuali modifiche della configurazione di alcuni moduli, a differenza del file di configurazione originario dove, invece, ad esempio, una volta che un modulo viene caricato da un file, poi la sua configurazione viene modificata, sovrascritta, o altri moduli sono creati clonando e poi modificando un modulo di partenza. Per eseguire il file di configurazione originario con cmsRun e' meglio commentare di nuovo la linea usata per fare il dump. Nel path di questo file di configurazione di sono tre elementi rappresentati dalle tre diverse sequenze:
  • la selezione degli eventi basata sul HLT trigger che ha accettato l'evento (process.seqHLTSelection che usa process.triggerResultsFilter che viene configurato con il parametro triggerPath)
  • la sequenza process.seqProducers che e' composta da process.seqMultProd che e' composta dai moduli che contano il numero di clusters or di strip/pixel nei diversi sottoinsiemi del pixel e strip tracker e che producono degli oggetti C++ che poi saranno usati per riempire gli istogrammi (sono quindi EDProducer)
  • la sequenze process.seqAnalyzers che contiene i moduli per riempire gli istogrammi con i numeri di clusters piu' un paio di moduli per selezionare i goodVertices (vertici primari cha passano qualche criterio di qualita') che poi sono utilizzati dall' EDAnalyzer definito nel modulo process.primaryvertexanalyzer.
Da ricordarsi: se un modulo produce un qualche oggetto di un certo tipo (classe C++) eventuali EDAnalyzer che vogliono usare questi oggetti dovrebbero sapere gia' di quale tipo sono (questo e' scritto nel codice dell'analyzer) e per individuare l'oggetto si deve usare il nome del modulo che ha prodotto l'oggetto. Quindi nel file di configurazione (o quello originale o quello prodotto con il dump) nella configurazione degli EDAnalyzer si trovano spesso parametri del tipo cms.InputTag che contengono una stringa uguale al nome di uno dei moduli che ha prodotto l'oggetto.

Dati da analizzare

Visto il tipo di analisi bisogna trovare i dataset e/o i file dove ci sono gli eventi raccolti con il trigger ZeroBias. Bisogna trovarli sia per il periodo durante il quale la separazione delle collisioni era 50ns (la quasi totalita' dei dati raccolti nel 2010-2012), sia per il breve periodo di test durante il quale la separazione delle collisioni era 25ns (uno o due fill?). Sapendo l'HLT trigger a cui siamo interessati, HLT_ZeroBias* si puo' ricavare il nome del dataset in cui si trovano questi eventi se si conosce il trigger menu che puo' essere trovato da qualche parte sul web (ma e' una procedure un po' lunga e la vediamo dopo). Per i dati normali la regola e' abbastanza semplice: i dati raccolti con il trigger ZeroBias sono nel dataset MinimumBias. Il vero problema e' il seguente: siccome vogliamo usare una release recente, 7_1_0, con la quale non e' stato fatto il reprocessing dei dati del 2012 (e forse non lo sara' mai fatto) ma la nostra analisi ha bisogno di dati di tipo RECO perche' deve avere a disposizione le collezioni dei clusters ci sono due opzioni visto che non si possono leggere file RECO prodotti con vecchie release con release piu' recenti:
  • o si utilizzano quei "pochi" eventi RECO che vengono creati per ogni release per la validazione, i cosidetti RelVal
  • o si utilizzano i RAW data e in questo caso bisogna aggiungere qualche modulo in piu' al path per poter ricostruire le collezioni dei clusters.
In entrambi i casi i dati devono essere disponibili, o dalla macchina che si usa nel caso si voglia girare in interattivo (lxplus), o per un eventuale job di crab. Fino ad ora questo voleva dire che i dati dovevano essere al T2 del CERN (T2_CH_CERN) detto anche CAF per l'opzione interattiva/lxplus, oppure su un qualsiasi T2 per l'opzione crab. Ora e' stato introdotto un sistema di accesso remoto dei dati che permette di utilizzare dati dovunque essi siano (purche' siano in un T1 o un T2?) sia in interattivo ( vedere in questa pagina per un esempio su come utilizzare questo servizio nella configurazione del file di input) che con crab (bisogna avere un certificato GRID). Per provare con la prima opzione bisogna andare sul database dei datasets, DAS, https://cmsweb.cern.ch/das/, e provare con la query seguente: dataset dataset=/MinimumBias/*2012*/RECO release=CMSSW_7_1_0 si ottengono due dataset che, come detto, sono dei RelVal. Utilizzando il primo (2012D) e cliccando su Sites si vede che questo dataset e' solo al T0 e al T1 di FNAL. Quindi l'unica speranza di utilizzare questi dati e' quella di poter usare l'accesso remoto. Se si vuole provare in interattivo occorre trovare il nome di qualche file in questo dataset. Per fare questo vediamo di restringerci prima a un solo run. L'elenco dei run in un dataset si trova seguendo il link Runs o con la query run dataset=/MinimumBias/CMSSW_7_1_0-GR_R_71_V6_RelVal_mb2012A-v1/RECO. Siccome e' un RelVal c'e' solo un run. Quindi si puo' passare ai file seguendo il link Files o la query: file dataset=/MinimumBias/CMSSW_7_1_0-GR_R_71_V6_RelVal_mb2012A-v1/RECO. Per avere un output che si possa selezionare facilmente con cut and paste selezionare result format plain e premere di nuovo search. Una volta preparata la lista dei file (incominciare con uno solo e poi vedere se vale la pena provare con piu' di uno in interattivo o passare a crab) eseguire: cmsRun print inputFiles= globalTag=GR_R_71_V6::All triggerPath="HLT_ZeroBias*" dove il nome del GlobalTag e' stato estrapolato dal nome del file essendo il GlobalTag usato per la produzione del file RECO (se non ci sono richieste speciali usare lo stesso GlobalTag non fa male. A volte potrebbe anche non essere necessario perche' nel file di configurazione che si usa non viene eseguito nessun modulo che ha bisogno delle condizioni che sono fornite dal GlobalTag). Siccome il file dovra' essere acceduto in modo remoto, viene chiesta la password del certificato GRID che quindi deve essere stato richiesto, esportato su lxplus e installato (vedere qui o nelle pagine di CMS e, in particolare questa parte).

Per i dati con eventi separati di 25ns si puo' solo usare la seconda opzione, ossia leggere i RAW data e ricostruire i clusters. Con DAS puoi fare la seguente query: dataset=/ZeroBias25ns*/*/RAW trovando che ci sono 8 datasets del tipo ZeroBias . Questo perche' in questo modo il rate di acquisizione che ha potuto sostenere CMS e' stato piu' alto senza creare dataset troppo grandi (a rotazione gli eventi venivano distribuiti fra gli otto datasets). In un modo simile a quello precedente devi procurarti qualche nome di file da usare come input per cmsRun. Per una lista completa dei run e delle lumisection considerate buone in questo run speciale a 25ns si puo' consultare il JSON file appropriato: per i run a 25ns sono qua. Il file di configurazione deve essere modificato per ricostruire anche i clusters. Per fare questo bisogna aggiungere: * questa sequenza:

process.seqRECO = cms.Sequence(process.gtEvmDigis + process.L1Reco
                               + process.siStripDigis + process.siStripZeroSuppression + process.siStripClusters
                               + process.siPixelDigis + process.siPixelClusters)
che poi va aggiunta come prima sequenza del path
  • queste linee
process.load("Configuration.StandardSequences.RawToDigi_Data_cff")
process.load("Configuration.StandardSequences.MagneticField_AutoFromDBCurrent_cff")
process.load("Configuration.StandardSequences.L1Reco_cff")
dopo la linee
process.load("Configuration.StandardSequences.GeometryDB_cff")
process.load("Configuration.StandardSequences.Reconstruction_cff")
e poi tutte queste linee vanno spostate prima della definizione della sequenza altrimenti i moduli per fare i digi, la zero suppression e i cluster (sia strip che pixel) non sono definiti. Si puo vedere questa configurazione DPGAnalysis/SiStripTools/test/MultiplicityProducerTest_cfg.py per un esempio su come rendere configurabile con il parametro fromRAW l'esecuzione dei moduli necessari per girare sui RAW data.
  • elimina/commenta dalla sequence seqAnalyzers i moduli goodVertices e primaryverticesanalyzer perche' non avendo ricostruito le tracce e i vertici non li troverebbe. Se in seguito ci servono vediamo o di ricostruirli o di farci riprocessare un po' di dati con 71x o di spostare l'analisi su una vecchia release per la quale ci sono i RECO data.

Fatto tutto questo provare a girare con lo stesso comando usato sopra. Attenzione: ho fatto una prova veloce su un file e nonostante abbia processato 100 eventi, gli istogrammi hanno una media di clusters uguale a zero. Forse ho preso 100 eventi in cui il tracciatore era spento. Usando i run e le lumisection specificate dal JSON file si dovrebbe risolvere questo problema. La cosa piu' semplice e' capire come si usa il JSON file per job in interattivo (vedere la twiki) o trovare un run che e' buono a partire dalla prima lumisection, poi selezionare con una query a DAS solo i file di quel run nel dataset scelto e provare con uno di questi file.

Output

A parte l'output sullo schermo viene prodotto un file root il cui nome e' controllato dalla configurazione del modulo TFileService nel file di configurazione (se vuoi lo puoi sostituire con options. che deve essere definito o fra quelli predefiniti, ad esempio options.outputFile in modo da poter controllare il nome del file root da linea di comando). Aprendo il file root con root: root , e poi eseguendo TBrowser b in root, e' possibile vedere il contenuto del file. Ci sono delle cartelle, una per ogni analyzer che ha prodotto istogrammi. Navigando nelle cartelle arrivi agli istogrammi far cui: avemult e aveoccu che sono il numero medio di cluster e di strip/pixel in ogni sottoinsieme, poi gli istogrammi nchannels_* con il numero di canali ideale o reale (cioe' tenendo conto dei canali morti) in ogni sotto insieme e poi altri TProfile con le positioni medie o le coordinate medie dei vettori ortogonali alle superfici dei sensori (servono per fare le mappe e per capire la geometria).

Provare a confrontare gli output ottenuti con un run a 50ns e a 25ns.

-- AndreaVenturi - 22 Jun 2014

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2014-07-06 - AndreaVenturi
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback