compilare HiggsAnalysisTools

Per riuscire a compilare HiggsAnalysisTools su lxplus a 64 bit (per sapere se un lxplus e' a 64 bit, ho fatto "uname -a" e ci ho visto scritti dei 64) ho avuto bisogno del root giusto:

export ROOTSYS=/afs/cern.ch/sw/lcg/external/root/5.15.08/slc4_amd64_gcc34/root

variabili LAT 2

con le stesse configurazioni del post precedente (qui), ho cambiato l'algoritmo per calcolare etaLat e phiLat. Mentre prima anche il raggio di moliere era pesato per la direzione della posizione dei due cristalli piu' energetici, ora e' lasciato costante.

LAT

ETA LAT

PHI LAT


Le modifiche sono state committate ed un test di esempio per leggere le nuove variabili di LAT sta in HtoWWElectrons/ElectronIDAnalyzer, con nome testlat.

per leggere il trigger

• In HtoWWTreeDumper abbiamo aggiunto due classi per propagare l'informazione del trigger fino al dumper, che abbiamo modificato perche' aggiunga le info al tree (prefix e suffix sono temporalei!)


• Il config file da usare si chiama hToWWAnalysisTriggerPlugins.cfg NON contiene l'include a Reconstruction.cff per via di un conflitto


• il modulo del treeDumper non e' nel cfg file dell'analisi, perche' va messo nell'endpath del trigger in modo da essere sicuri che venga girato dopo i trigger. per farlo:
  
  
  
  • scramv1 project CMSSW CMSSW_1_3_1_HLT5
  
  
  • cd CMSSW_1_3_1_HLT5/src
  
  
  • project CMSSW
  
  
  • cvs co -r V00-01-44 HLTrigger/Configuration
  
  
  • edit HLTrigger/Configuration/data/common/HLTEndpath.cff
  
  
  • aggiungere in fondo al file:
    
    include "HtoWWElectrons/HtoWWTreeDumper/data/treeDumper.cfi"
    replace treeDumper.nameFile = "default.root"
    endpath endl1hlt = {hltMSO & l1tTR & hltTR & myTimer & pts & treeDumper}
    
    
  
  
  
  

per usare Crab

Ciao,
ecco alcune istruzioni per usare CRAB una volta avuto/abilitato/settato il certificato
[io questo l'ho sempre fatto da SLC3]:

source /afs/cern.ch/cms/LCG/LCG-2/UI/cms_ui_env.csh
source /afs/cern.ch/cms/ccs/wm/scripts/Crab/crab.csh
voms-proxy-init -voms cms

dalla directory dentro CMSSW
eval `scramv1 runtime -csh`
crab -create -submit -cfg ilMioCrab.cfg --> per creare e sottomettere i job

crab -status --> per conoscere lo stato dei job
crab -getoutput --> per riprendersi l'output dei job

una cosa: se si creano le directory su castor con rfmkdir crab non
riconosce l'utente e dice di non avere i permessi per scriverci. Vanno
create (ad esempio) cosi':
edg-gridftp-mkdir gsiftp://castorgrid.cern.ch/castor/cern.ch/user/c/crovelli/LaMiaDirectory

Metto nella mia public alcuni esempi di cfg x crab:
/afs/cern.ch/user/c/crovelli/public/crabCfg

Ciao,
Chiara

variabili LAT

ho provato ad aggiungere il computo delle variabili lat al codice di analisi.
Ecco qualche primo plot:

il verde corrisponde a :
"/store/mc/2006/12/21/mc-physval-120-DiEle-Pt35/0000/50545055-4A98-DB11-AAF6-00093D139EE5.root"

la linea rossa corrisponde a :
"/store/mc/2006/12/21/mc-onsel-120_QCD_pt_30_50/0018/123194E5-B19A-DB11-835C-001731AF66FF.root"

le variabili etaLat e phiLat sono calcolate utilizzando la componente parallela o perpendicolare alla direzione del fascio del raggio trasverso.

Gli istogrammi sono normalizzati al proprio integrale.
Il numero di entry utilizzate e' di 5006 per i dielettroni, 210 per il sample QCD.


LAT

ETA LAT

PHI LAT

Ricetta per la catena completa con i plugins

Tutta la catena completa e' ora funzionante con i plugin e il nuovo setup per la Likelihood.
La ricetta e':

1) create the working area
> scramv1 project -n HtoWW131 CMSSW CMSSW_1_3_1

2) setup environment
> cd HtoWW131/src/
> eval `scramv1 ru -csh`
> project CMSSW

3) checkout some cfg to patch
> cvs co RecoMET/METProducers/test/CaloCandidatesFromDigis.cfi
> cvs co Configuration/StandardSequences/data/Reconstruction.cff
> cp ~emanuele/public/patches/1_3_1/CaloCandidatesFromDigis.cfi RecoMET/METProducers/test/CaloCandidatesFromDigis.cfi
> cp ~emanuele/public/patches/1_3_1/Reconstruction.cff Configuration/StandardSequences/data/Reconstruction.cff

4) setup CVSROOT to Pietro repository and checkout the package:
> source ~emanuele/public/cvs_setup_htoww.csh
> cvs co -P HtoWWElectrons
> cvs co -r V01-00 PhysicsTools
> cvs co -r V01-00 DataFormats
> cvs co -r V01-00 RecoEcal

6) build cmsRun
scramv1 b

7) run it:
> cmsRun HtoWWElectrons/HtoWWTreeDumper/test/hToWWAnalysisPlugins.cfg

this will produce the tree "default.root" in the current dir (and also some monitoring ROOT files with histograms)

8) If you want to do an extensive production use "run.pl" tool:
http://welectrons.blogspot.com/2007/05/script-to-do-batch-production.html

---> ElectronID: in the hToWWAnalysisPlugins.cfg the electron ID by cuts is OFF.
To turn on it, just change:

InputTag src = ambSolving
# InputTag src = eleIdentifying

in

# InputTag src = ambSolving
InputTag src = eleIdentifying

in the HtoWWEleCloner module. This will pass to the dumper the cut-ID electron
candidate collection (NB: in this way the likelihood is very biased)

This is preliminary. The aim is to have the mapped electron collection
with different algo (cut/LH) and purities.



emanuele & pietro

Likelihood nel framework "ESetup"

Per ora gira, ma secondo un primo test mi pare che ci sia ancora qualcosina che non va (un po' di -1 che non ci dovrebbero essere)
Per girarlo (per ora abbiamo fatto un analyzer standalone dalla nostra analisi):

cvs co HtoWWElectrons/HtoWWLHRecord
cvs co HtoWWElectrons/HtoWWLHESSource
cvs co HtoWWElectrons/HtoWWLHAlgo
cvs co HtoWWElectrons/ElectronIDAnalyzer

scramv1 b

cmsRun HtoWWElectrons/ElectronIDAnalyzer/test/electronid.cfg

plugins

Ho aggiunto in /HtoWWElectrons/HtoWWEleProducer/src un cloner HtoWWEleCloner che clona GSF electrons in candidates, da utilizzare nella 131 in attesa di quello ufficiale della 15X.

In /HtoWWElectrons/HtoWWEleProducer/plugins ci sono bugfix per HWWEleId e HWWEleAmbiguityResolve.

In /HtoWWElectrons/HtoWWTreeDumper/test c'e' testPluginDumper.cfg per provare a lanciare la catenza di analisi completa con i plugin.

Primo sguardo alla catena completa

Ciao,

1) con il tag:
> cvs co -r edm-09062007 HiggsAnalysisTools
si puo' girare la catena completa dell'analisi.
Per ora electron-ID e tracker- e hcal- isolation sono fatti qui per debug
(sopratutto, l'isolamento e' ancora dubbio).

Con il set di tagli "storici" su un campione H(160 GeV):

*****************************************
* EVENT EFFICIENCIES
*****************************************
* MCtruth: 0.110 +/- 0.001
* trigger: 0.782 +/- 0.005
* nRecoEle: 0.775 +/- 0.006
* twoGoodRec: 0.876 +/- 0.005
* eleID: 0.665 +/- 0.008
* trackerIsol: 0.888 +/- 0.007
* hcalIsol: 1.000 +/- 0.000
* jetVeto: 0.809 +/- 0.009
* maxPtEle: 0.505 +/- 0.013
* minPtEle: 0.929 +/- 0.009
* MET: 0.708 +/- 0.017
* deltaPhi: 0.821 +/- 0.017
* eleInvMass: 0.620 +/- 0.024
* final: 0.043 +/- 0.003
*******************************************

dove MC-truth e' la frazione di eventi con H->2e2nu
(il MC contiene 2e2nu + 2mu2nu + 1e1nu1mu1nu)
---> final = eventi(sel)/eventi(generati 2e2nu)

E questo e' il dettaglio dell'electron-ID (N.B. l'eff dell'evento
e' quella richiedendo che ambedue gli elettroni ricostruiti siano
identificati).

*****************************************
* ELE-ID EFFICIENCIES
*****************************************
* hOverE: 0.964 +/- 0.002
* s9s25: 0.970 +/- 0.002
* deta: 0.974 +/- 0.002
* dphiIn: 0.990 +/- 0.001
* dphiOut: 0.956 +/- 0.003
* covEtaEta: 0.950 +/- 0.003
* eOverPout: 0.995 +/- 0.001
* Fisher: 1.000 +/- 0.000 <--- spento
* finalEleID: 0.815 +/- 0.005
*****************************************

------------------------------------------------------------------
2) Nei config files ci sono anche i tagli sul Fisher con i quali si ha la stessa efficienza sul segnale (classe per classe). Per accenderlo:

> nano electronIDSwitches.txt

cambiare gli switch:
s9s25 1
covEtaEta 1
Fisher 0

in:
s9s25 0
covEtaEta 0
Fisher 1

non abbiamo ancora prodotto campioni di W+jets e Z+jets a sufficienza.
Su campioni di puri elettroni (pt=35 GeV)
con questi tagli a parita' di efficienza sul segnale
(~92% su ECAL barrel e ~87% su ECAL endcap)
vs. puri jets (pt=30-50 GeV)
si ottiene una riduzione del ~25% del fake rate
(da ~4% a ~3% su entrambi barrel e endcap).

----------------------------------------------------------------------
3) Nei config files, allo stesso modo, ci sono i tagli sulla Likelihood
con cui si ha la stessa efficienza sul segnale (classe per classe).
Si accende analogamente a prima:

> nano electronIDSwitches.txt

s9s25 0
....
Fisher 0
Likelihood 1

A parita' di efficienza sul segnale della selezione precedente
si ottiene una riduzione di ~60% del fake rate (??? sistematiche ???)
rispetto ai tagli standard (~50% di quello con i tagli col Fisher)
(da 4% a ~ 1.6%)




P.S. I campioni sono ancora statisticamente limitati

P.P.S La dipendenza delle PDF (ma anche delle eff dei tagli) dall'energia
e' da indagare (ad un primo sguardo, le PDF, compresa la cluster shape,
sembrano ~indipendenti da E tranne che per E<= 10 GeV)

developing CMSSW sw

pagina del wiki dove si spiega come fare sw developement in CMSSW, fra le altre cose si puo' committare codice personale nel CVS di CMSSW.

Developing CMSSW Software

primi test dei plugin

ho aggiunto in /HtoWWElectrons/HtoWWEleProducer/test i config file:

testAmbResolver.cfg <-- test dell'ambiguity resolver
testEleId.cfg <-- test dell'electron ID
testChain.cfg <-- test dei due plugin concatenati

il primo dei tre gira, il secondo ha un crash dopo pochi eventi, il terzo gira.
I test sono soltanto tecnici, non di fatto.
L'ultimo config file contiene anche il treeDumper.
Nel caso in cui il treeDumper non venga incluso, non ci sono problemi; se viene incluso, c'e' un crash.

Lista di tags e nuova ricetta

Ciao, questa e' la nuova ricetta per girare il nostro pacchetto:

1) create the working area
> scramv1 project CMSSW CMSSW_1_3_1

2) setup environment
> cd CMSSW_1_3_1/src/
> eval `scramv1 ru -csh`
> project CMSSW

3) checkout some cfg to patch
> cvs co RecoMET/METProducers/test/CaloCandidatesFromDigis.cfi
> cvs co Configuration/StandardSequences/data/Reconstruction.cff
> cp ~emanuele/public/patches/1_3_1/CaloCandidatesFromDigis.cfi RecoMET/METProducers/test/CaloCandidatesFromDigis.cfi
> cp ~emanuele/public/patches/1_3_1/Reconstruction.cff Configuration/StandardSequences/data/Reconstruction.cff

4) setup CVSROOT to Pietro repository and checkout the package:
> source ~emanuele/public/cvs_setup_htoww.csh
> cvs co -r V01-00 HtoWWElectrons
> cvs co -r V01-00 DataFormats
> cvs co -r V01-00 RecoEcal

6) build cmsRun
scramv1 b

7) run it:
> cmsRun HtoWWElectrons/HtoWWTreeDumper/test/hToWWAnalysis.cfg

this will produce the tree "default.root" in the current dir (and also some monitoring ROOT files with histograms)

8) If you want to do an extensive production use "run.pl" tool:
http://welectrons.blogspot.com/2007/05/script-to-do-batch-production.html

DataFormats and RecoEcal nel CVS di Pietro

Ciao,

ho aggiunto al CVS di Pietro i pacchetti

DataFormats
RecoEcal

questi corrispondono ai relativi pacchetti di CMSSW_1_3_1,
ma in cui ho modificato il file in cui c'e' l'algoritmo di Cluster Shape
per aggiungere le nuove variabili
(RecoEcal/EgammaCoreTools/src/ClusterShapeAlgo.cc)
poi ho anche modificato
DataFormats/EgammaReco/src/ClusterShape.cc
per rendere accessibili le variabili dall'oggetto clusterShape.

gia' che c'ero ho anche committato il bug fix di Chiara in
DataFormats/EgammaCandidates/src/PixelMatchGsfElectron.cc


emanuele

isolation in CMSSW

generic isolation in the reference manual

annunciato cosi':

according to a discussion had with all the people who are contributing
with isolation tools development, I made the following rearrangement of
Francesco Fabozzi's Generic Isolation module:

* the isolation algorithm(s) with no dependency
on Framework are in the new package:

PhysicsTools/IsolationUtils

* the isolation generic producer module(s)
goes in the new package:

PhysicsTools/IsolationAlgos

In this way, it will be possible to add Reflex dictionaries to
algorithms in PhysicsTools/IsolationUtils for FWLite use of isolation.

The old package PhysicsTools/LeptonIsolation will be removed in next
releases (nightly + next 1.5.0).

plugin di analisi

ho committato in /HtoWWElectrons/HtoWWEleProducer/ la cartella plugins, che contiene un primo tentativo di traduzione di passaggi dell'analisi in plugin di CMSSW:

HWWEleAmbiguityResolve.cc
HWWEleAmbiguityResolve.h
HWWEleId.cc
HWWEleId.h
PluginTemplate.cc
PluginTemplate.h
SealModule.cc

La terza coppia e' il modello che ho utilizzato per fare gli altri due.

isolamento adronico

Ciao,

ho committato alcuni bug fix x le correzioni all'energia degli elettroni
+ una prima versione dell'isolamento adronico (vorrei prendere i cluster in hcal ma non
ci riesco, per ora e' fatta con i rechits). inoltre ho messo alcune variabili utili x studiare
i tagli di isolamento nel tree.

Per usare il tutto si segue la ricetta postata da Emanuele.
In piu':
- per usare le variabili di shape meglio prendere la v02 dal repository di Emanuele
- bug fix per H/E: bisogna modificare
DataFormats/EgammaCandidates/src/PixelMatchGsfElectron.cc
sostituendo
hadOverEm_ *=superClusterEnergy_/newEnergy
alla line 196

Ciao,
Chiara

Likelihood per l'electron ID

Ciao a tutti,

ho aggiunto un modulo che calcola la likelihood
per l'electron-ID.
E' nel tag edm-01062007 di HtoWWElectrons.

Sta tutto in HtoWWEleProducer.
La classe che la costruisce e' GsfLHSelector.


Pensieri sparsi in liberta':

1) La likelihood e' fatta con le seguenti variabili:
deltaPhi @ Calo
deltaEta @ Calo
E/P_out
H/E
cluster shape (discriminante di Fisher)

2) Il discriminante di Fisher e' fatto con alcune variabili di cluster
shape, scelte per essere sotto controllo e con una correlazione < 30%
tra di loro. Questo permette di includere gran parte delle
informazioni relative alla cluster shape che non potrebbero essere
usate tutte insieme nella likelihood fattorizzata (a meno di fare PDF
n-dim. brrr...)

I coefficienti del discriminante di Fisher sono stati calcolati
separatamente per barrel e endcap.
La formula e' la seguente:

---> EB: clusterShapeF = 42.0238-3.38943*s9s25-794.092*sigmaEtaEta-15.3449*lat-31.1032*a20
http://emanuele.web.cern.ch/emanuele/ElectronID/linearFisher.eps

---> EE: clusterShapeF = 27.2967+2.97453*s9s25-169.219*sigmaEtaEta-17.0445*lat-24.8542*a20
http://emanuele.web.cern.ch/emanuele/ElectronID/linearFisherEE.eps

i coefficienti sono calcolati per
sig: eventi e+e-, pt=35 GeV
bkg: qcd jets, pt=30-50 GeV

(nota: studiare l'andamento in energia. Non dovrebbero dipendere molto,
perche' le variabili sono tutti rapporti, vedi:
http://emanuele.web.cern.ch/emanuele/ElectronID/electronID_allclasses.ps )


3) Si fanno due likelihood separate, per EB e EE

4) La shape delle pdf di segnale e' dipendente dalla classe ("GsfClass")
dell'elettrone. Quindi le PDF del segnale sono splittate per classe.
Le PDF del fondo non sono splittate.
(Nota: le frazioni di classe si possono giudicare dal MC,
per ora ho messo 1. (sbagliato))

5) Le pdf sono istogrammi letti da 2 ROOT files (uno per EB, uno per EE)

6) Le frazioni (probabilita' a priori) delle varie specie (ipotesi di
ele, jet @ pt=35, pt=50...) sono da settare (per ora ho messo 1.)
dalle sezioni d'urto?

7) i ROOT files con le PDF sono in:
~emanuele/public/EBpdfs.root
~emanuele/public/EEpdfs.root

da mettere in HtoWWElectrons/HtoWWEleProducer/data/
(dove metterle nel futuro? non si puo' committare un ROOT file in CVS
di CMSSW)

Nota: il binning non e' ottimale

8) Un ulteriore passo e' quello di PDF parametriche.
Dovrebbe essere semplice implementare una nuova classe GsfParametricPdf
da sostituire a GsfPdf in GsfLikelihood


9) Il likelihood ratio L(ele)/L(tot) e' calcolato e messo nel tree-ridotto
dal modulo CmsEleIDTreeFiller.cc



emanuele