## My Notes

### Questions

• Very Important: overlap with other tutorials: BTV?

### Ideas for new exercises

#### BeamSpot exercises

• Explain what the BeamSpot is.
• Show the difference between the BeamSpot as a point and the BeamSpot as a region
• PV-BS: can be done with a reduced data content using Jet300 events
• do I need special dataset? Jets?
• this can be done with reduced format events: Vertices and BeamSpot
• Fit both exercises in a single analyzer
• reference to the main analyzer in Validation/RecoVertex
• PV-BS with and without taking into account the slope: TProfile and/or TH2F
• Compare Delta(PV-BS) only first vertex and all vertices
• d0 vs z
• d0 vs phi correlation plot with and without taking into account the slope: TProfile2D
• d0 distribution vs z: can I see anything?
• This plot can be added to Kevin's exercise
• It can be given as an additional exercise

#### Primary Vertex multiplicity

• Introduce the Primary Vertex Collection
• Explain the pileup
• One (or zero) interesting intereactions and n additional interactions among those with the largest cross section
• Any plot about vertex reconstruction and pileup?
• MC reco vs true plot: examples. vs Npileup, vs average Npileup
• to be done with different ndof cuts? Why the slope changes by changing ndof cut? Use filter
• to be done with ZeroBias and with a MC with a signal: different intercept
• Vertex multiplicity vs Luminosity
• example of plots: with large luminosity, with normal luminosity
• lumi not corrected
• correct for luminosity linearization in the code (and explain it)
• Fit a Poissonian in each slice?
• Compute vertex cross section
• ZeroBias events are needed: large pileup run
• rerun lumiProducer
• Check how many events are needed for a clean plot
• remove bad LS? If not, they have to be explained
• Explain what is available in MC
• Npileup, average Npileup
• show an example of analyzer, run it, look at the plots
• Zero Bias vs high pt event
• Use a Primary Vertex filter to produce a cleaner vertex collection
• show how to apply the cuts in the analyzer
• show that the same can be obtained with an external filter
• prepare pairs of configuration/analyzer which show both approaches
• repeat exercise with different ndof cuts
• different ndof cut in the same configuration

#### Iterative Tracking

• Brief explanation of the idea
• Cleaning of the cluster collections
• Different seeding acceptances
• Explaning seeding and track building
• Explain track selector
• high purity tracks
• Distributions of track properties for the different iterations
• pt
• number of (pixel) hits
• eta vs phi: pixel pairs where the holes are
• d0, z0 (?) * It can be used to introduce the filter on tracks to factorize track selection and track analysis * Check iteration description in the workbook

#### Tracks and pileup

• Show track multiplicity vs luminosity
• Compare the eta distributions at small and large pileup
• This exercise can be combined with the one about vertex multiplicity and use track and vertex filters
• Check how much statistics in needed
• Check how much time is needed to run the jobs

#### Track to Vertex Association

• Show that in Z to mumu events the muons are likely to come from the first vertex
• compare mumu vertex z position with first vertex and other vertices?
• compare individual muon z with vertex z?
• define track z
• is it too obvious given first vertex definition? Other better examples?
• Anything that shows how to clean up event with vertices? PFnopileup

• Stress that tracks are needed also for Particle Flow
• Does a Particle Flow tutorial exist?
• Sketch to better define impact parameter definition in CMSSW
• Different styles: ntuples, TFileService, python: that's ok

### To Do List

• The instructions have to be modified to be complaint with Pisa environment
• Set up a CVS area where to save my stuff for the tutorial
• Execute the exercises myself
• Check that Workbook documentation is ok

## Instructions

• Setup the working area
• Prepare a CMSSW working area with a release version of the 4_4_x cycle:
• `cmsrel CMSSW_4_4_2_patch9`
• `cd CMSSW_4_4_2_patch9/src`
• `cmsenv`
• Add a tag of the luminosity reconstruction package needed to fix a bug in the Luminosity producer:
• `cvs co -r V05-01-01 RecoLuminosity/LumiProducer`
• Add the package with the CMSDAS exercises:
• `cvs co -d CMSDAS/PrimaryVertexExercise -r V00-00-00 UserCode/VenturiA/CMSDAS/PrimaryVertexExercise`
• The use of the `"cvs co -d..."` command is useful to checkout packages from the UserCode areas where it is not possible to have a `<Subsystem>/<Package>` directory structure
• The CMSDAS/PrimaryVertexExercise package contains:
• in the directory `plugins`: the code of the EDAnalyzer `PVExerciseAnalyzer` which produces a root file with the distributions obtained from the analyzed events
• in the directory `python`: the configuration inlcude file `pvexerciseanalyzer_cfi.py` with an example of the configuration of the EDAnalyzer. The EDAnalyzer requires the names of the primary vertex collection, of the beamspot object and of the luminosity information object
```pvexerciseanalyzer = cms.EDAnalyzer('PVExerciseAnalyzer',
pvSrc = cms.InputTag('offlinePrimaryVertices'),
bsSrc = cms.InputTag('offlineBeamSpot'),
lumiSrc = cms.InputTag('lumiProducer')
)
```
• in the directory `test`: the configuration file `pvexercise_cfg.py` to be executed to do the exercise
• in the directory `data`: a few text files with a list of input edm data files to be used as input of the CMSSW job
• in the directory `bin`: the code of some root macros to be compiled and loaded during a root interactive session to produce the plots of the distributions created by the EDAnalyzer
• Build the libraries and the executables:
• `scramv1 b`
• Run the CMSSW job
• `cmsRun CMSDAS/PrimaryVertexExercise/test/pvexercise_cfg.py print inputFiles_load=CMSDAS/PrimaryVertexExercise/data/inputfiles_176309_20Oct2011_ZeroBias.list maxEvents=200000 hltSelection="HLT_ZeroBias_*" lumiBlockRange="176309:min-176309:max"`
• or `cmsRun CMSDAS/PrimaryVertexExercise/test/pvexercise_cfg.py print inputFiles_load=CMSDAS/PrimaryVertexExercise/data/inputfiles_179563_prompt_ZeroBias.list maxEvents=200000 hltSelection="HLT_ZeroBias_*" lumiBlockRange="179563:min-179563:max"`
• The configuration file we have executed has one `cms.Path`:
```process.p0 = cms.Path(
process.hltSelection +
process.lumiProducer +
process.goodVertices +
process.pvexerciseanalyzer
)
```
• `process.hltSelection` module is an EDFilter which allows only the events which have passed a given HLT paths to be processed and analyzed by the following modules in the path. The HLT paths are configured using the parameter `hltSelection` in the `cmsRun` command
• `process.lumiProducer` module produces the LumiDetails object which is used by the EDAnalyzer. It gets the luminosity information from the DB and saves it in a LuminosityBlock object. The name of the module has to match the name of the InputTag in the EDAnalyzer configuration
• `process.goodVertices` module produces a new collection of primary vertices which fulfill the selection cuts defined in the configuration of this module:
```process.goodVertices = cms.EDFilter("VertexSelector",
src = cms.InputTag("offlinePrimaryVertices"),
cut = cms.string("!isFake && ndof > 4 && abs(z) <= 24 && position.Rho <= 2"),
filter = cms.bool(False),   # otherwise it won't filter the events, just produce an empty vertex collection.
)
```
• `process.pvexerciseanalyzer` module is the EDAnalyzer which produces the distributions from the analyzed events. It has to be configured to use the `goodVertices` primary vertex collection
```process.pvexerciseanalyzer.pvSrc = cms.InputTag("goodVertices")
```
• This configuration file uses the VarParsing module to pass in the command line the values of some parameters needed in the configuration. Look for `options.<keyword>` in the configuration file to understand how it works. The list of parameters is:
• `inputFiles_load` : name of the file with a list of input edm data files
• `maxEvents`: number of events to be analyzed
• `hltSelection`: string with the selected HLT path (with wildcards)
• `lumiBlockRange`: string used to select a run and luminosity block range as described here
• Results: explanation of the code and interpretation
• The EDAnalyzer saves all the distributions in the `PVExercise.root` file, using the =TFileService CMSSW service
• Start a root interactive session: `root PVExercise.root`.
• All the histograms can be looked at using the root `TBrowser`. Otherwise a set of macros can be used to display the produced distributions:
• Load the macro library: `.L ../lib/slc5_amd64_gcc434/libCMSDASPrimaryVertexExerciseMacros.so`
• Primary Vertex multiplicity
• Execute the macro `plot_nvtx(_file0,false)`. It displays the distribution of the number of primary vertices (after the `goodVertices` selection described above) reconstructed in each event. More than one primary vertex is reconstructed because more than one proton-proton inelastic interaction may occur for each proton bunch crossing. When the luminosity is about 3*10^33 cm^-2 s^-1, the rate of pp interactions is about 200 MHz which means about 18.5 thousands pp interactions in each LHC orbit. Since LHC is filled with about 1380 bunches, about 13 pp interactions are expected, on average, for each bunch crossing. To achieve such a luminosity each LHC proton bunch is filled with xx 10^11 protons with a transverse size of about 28-35 um (RMS). Executing the macro `plot_nvtx(_file0,true)` displays the primary vertex multiplicity distribution with, superimposed, the Poisson distribution with the same mean value. If the distribution is displayed in log scale (right-click on the root TCanvas outside the distribution area and select SetLogy), it is evident that the observed distribution is not well reproduced by a single Poisson distribution, especially in the upper tail. This is due to the fact that the average number of pileup interactions is not constant. The part of the EDAnalyzer code used to produce such distribution is:
``` // in the PVExerciseAnalyzer::analyze method

// get the Handle of the primary vertex collection
edm::Handle<reco::VertexCollection> pvcoll;
iEvent.getByLabel(m_pvcollection,pvcoll);
...
unsigned int nvtx = 0;

for(reco::VertexCollection::const_iterator vtx=pvcoll->begin();vtx!=pvcoll->end();++vtx) {
// check that the primary vertex is not a fake one, that is the beamspot (it happens when no primary vertex is reconstructed)
if(!vtx->isFake()) {
++nvtx;
...
}
}
m_hnvtx->Fill(nvtx);  // m_hnvtx is the pointer to a TH1F booked using TFileService
```
• Primary Vertex Multiplicity vs time
• Execute the macro `plot_nvtsvstime(_file0,false)`. It displays the average number of primary vertices as a function of the Luminosity Block number. In CMS one Luminosity Block is a time interval whose length is equal to 2^18 orbits, about 23,3 seconds and the Luminosity Block counter is reset at the beginning of each run (that's why this plot makes sense only if events from the same run are used). This distribution shows that the average amount of pileup interactions decreases exponentially with the time due to the loss of protons in the beam. Executing the macro `plot_nvtxvstime(_file0,true)` the same distribution is displayed with, superimposed, the result of an exponential fit to the points. From the parameters of the fitted function it is possible to measure the lifetime of the LHC beam luminosity: about 20 hours. The part of the code of the EDAnalyzer used to produce such a distribution (TProfile) is:
```// in the PVExerciseAnalyzer::analyze method

// get the Handle of the primary vertex collection
edm::Handle<reco::VertexCollection> pvcoll;
iEvent.getByLabel(m_pvcollection,pvcoll);
...
unsigned int nvtx = 0;

for(reco::VertexCollection::const_iterator vtx=pvcoll->begin();vtx!=pvcoll->end();++vtx) {
// check that the primary vertex is not a fake one, that is the beamspot (it happens when no primary vertex is reconstructed)
if(!vtx->isFake()) {
++nvtx;
...
}
}
m_hnvtxvstime->Fill(iEvent.getLuminosityBlock().luminosityBlock(),nvtx); // m_hnvtxvstime is a pointer to a TProfile booked with TFileService
```
• Primary Vertex multiplicity vs instantaneous luminosity
• Execute the macro `plot_nvtxvslumi(_file0,false)`. It displays the primary vertex multiplicity vs the instantaneous luminosity of the corresponding bunch crossing (the bunches do not have the same amount of protons and, therefore, the luminosity and the amount of pileup depends on the pair of crossing bunches) as measured by the Forward Hadron Calorimeter (HF) and averaged over a Luminosity Block. The black points show the average primary vertex multiplicity for each bin of the instantaneous luminosity. The correlation is pretty linear. Executing the macro `plot_nvtxvslumi(_file0,true)` the result of a linear fit to the average primary vertex multiplicity is shown. From the slope of the linear fit it is possible to estimate the cross section of a pileup interaction with a detectable primary vertex about 47.8 mb. When compared to the inelastic pp cross section, 68-73.5 mb, the resluting primary vertex efficiency or acceptance is about 70%. The part of the EDAnalyzer code used to produce this distribution is:
```// in the PVExerciseAnalyzer::analyze method

// get the Handle of the primary vertex collection
edm::Handle<reco::VertexCollection> pvcoll;
iEvent.getByLabel(m_pvcollection,pvcoll);

// get the Handle of the luminosity: since it is a luminosity block information the Handle has to be get by the LuminosityBlock object
edm::Handle<LumiDetails> ld;
iEvent.getLuminosityBlock().getByLabel(m_lumicollection,ld);

...
// compute the instantanous (averaged over a Luminosity Block) luminosity. The corrections are hidden in the getCorrLumi method
float lumi = -1.;
// sometimes the luminosity is not available or invalid: to be checked
if(ld.isValid()) {
if(ld->isValid()) {
lumi = getCorrLumi(ld->lumiValue(LumiDetails::kOCC1,iEvent.bunchCrossing()));
} else {
edm::LogWarning("InvalidLumi") << "invalid LumiDetails";
}
} else {
edm::LogWarning("InvalidLumiHandle") << "invalid LumiDetails Handle";
}

unsigned int nvtx = 0;

for(reco::VertexCollection::const_iterator vtx=pvcoll->begin();vtx!=pvcoll->end();++vtx) {
// check that the primary vertex is not a fake one, that is the beamspot (it happens when no primary vertex is reconstructed)
if(!vtx->isFake()) {
++nvtx;
...
}
}
if(lumi>=0) m_hnvtxvslumi->Fill(lumi,nvtx); // m_hnvtxvslumi is a pointer to a TH2F booked with TFileService
```
```    TH2F* nvtxvslumi = (TH2F*)gDirectory->Get("nvtxvslumi");  // TH2F histogram produced by the EDAnalyzer

if(nvtxvslumi) {
int low = nvtxvslumi->GetXaxis()->FindFixBin(firstslice-delta);                  // lower bin compatible with firstslice-delta luminosity value
int high = nvtxvslumi->GetXaxis()->FindFixBin(firstslice+delta);               // upper bin compatible with firstslice+delta luminosity value
TH1D* nvtxvslumi_1 = nvtxvslumi->ProjectionY("nvtxvslumi_1",low,high);  // TH1D obtained from a slice of the TH2F
TF1* poiss_1 = new TF1("poiss_1","[0]*TMath::Poisson(x,[1])",0.,50.);     // TF1 Poisson function whose normalization and mean value is taken from the TH1D
poiss_1->SetParameter(0,nvtxvslumi_1->GetEntries());
poiss_1->SetParameter(1,nvtxvslumi_1->GetMean());
...
}
```
• Primary Vertex properties
• The collection of the primary vertices is sorted according to the value of the sum of the squared transverse momenta of the tracks associated to the vertex, in descending order. In this way, very likely, the first primary vertex of the collection is vertex of the main interaction of the event, that is the vertex of the hard interaction which has fired the trigger (in case of ZeroBias events there is no triggering interaction and, therefore, the first vertex is simply the one of the interaction with the largest activity). Because of this sorting, the properties of the first vertex in each event are different from those of the other events:
• Execute the macro `plot_ntrks(_file0)`. It displays the distribution of the number of tracks associated to each vertex for all the vertices and only for the first vertex in each event. The latter has an average track multiplicity which is larger than that of the inclusive distribution.
• Similarly execute the macro `plot_ndof(_file0)`. It displays the distribution of the number of degrees of freedom of each vertex for all the vertices and for the first vertex of each event. The number of degrees of freedom is strongly correlated to the number of tracks but it is not a trivial function of it since an adaptive algorithm is used to reconstruct the primary vertices: each track is assigned a weight which represents its compatibility with the vertex and the number of degrees of freedom is equal to 2*sum(weights)-3. Therefore the correlation between the number of degrees of freedom and the number of tracks depends on how close to one is the average track weight. Execute the macro `plot_ndofvsntrks(_file0)`: it displays the correlation between the number of degrees of freedom and the number of tracks. The part of the EDAnalyzer code to produce these distributions is:
```// in the PVExerciseAnalyzer::analyze method

// get the Handle of the primary vertex collection
edm::Handle<reco::VertexCollection> pvcoll;
iEvent.getByLabel(m_pvcollection,pvcoll);

for(reco::VertexCollection::const_iterator vtx=pvcoll->begin();vtx!=pvcoll->end();++vtx) {
// check that the primary vertex is not a fake one, that is the beamspot (it happens when no primary vertex is reconstructed)
if(!vtx->isFake()) {
...
// Fill the vertex properties histograms
m_hntrks->Fill(vtx->tracksSize());   // m_hntrks is a pointer to a TH1F booked with TFileService
m_hndof->Fill(vtx->ndof());            // m_hndof is a pointer to a TH1F booked with TFileService
m_hndofvsntrks->Fill(vtx->tracksSize(),vtx->ndof());  // m_hndofvsntrks is a pointer to a TH2F booked with TFileService
...
}
}
```
• Primary Vertices and Beam Spot
• The transverse position of the primary vertices is strongly correlated to the transverse beamspot position due to its narrow width: in 2011 the typical beamspot transverse size (RMS) has been 20-25 um. Execute the macros `plot_deltaxyz(_file0,"x")` and `plot_deltaxyz(_file0,"y")` to display the distributions of the difference between the x and y primary vertex positions and the x and y beamspot position. The distributions obtained using only the first vertex of each events are narrower because the larger track multiplicity and track transverse momenta bring to a better resolution of vertex position (see for example TRK-10-005)
• Since the length of the beamspot along the beam line has been between 5.5 and 6 cm in 2011, the correlation between the beamspot position and the primary vertex position along the beam line (z coordinate) is much less strong and there is no visible difference when vertices with different resolution are considered. Execute the macro `plot_deltaxyz(_file0,"z")` to display the distribution of the difference between the z position of the primary vertices and the z position of the beamspot.
• The beamspot is not simply a 3D point (with errors) but it is like a "stick" almost parallel to the z axis (3D ellipsoid with large sigmaZ and small sigmaX and sigmaY). Therefore the transverse beamspot position (x,y) is a function of the z coordinate. Execute the macro `plot_deltaxyvsz(_file0)` to display the distribution of the differences between the x and y primary vertex positions and the x and y beamspot positions when the beamspot slope w.r.t. the z axis is taken or is not taken into account. Execute the macro `plot_deltaxyvsz(_file0,-0.005,0.005)` to zoom in. The average values of the x and y differences as a function of z show a linear dependence when the beamspot slope is not taken into account which can introduce and offset as large as about 10-15 um when |z| = 10-15 cm.
• The part of the EDAnalyzer code to produce these distributions is:
```  // in the PVExerciseAnalyzer::analyze method

// get the Handle of the primary vertex collection
edm::Handle<reco::VertexCollection> pvcoll;
iEvent.getByLabel(m_pvcollection,pvcoll);

// get the Handle of the beamspot
edm::Handle<reco::BeamSpot> bs;
iEvent.getByLabel(m_bscollection,bs);

for(reco::VertexCollection::const_iterator vtx=pvcoll->begin();vtx!=pvcoll->end();++vtx) {
// check that the primary vertex is not a fake one, that is the beamspot (it happens when no primary vertex is reconstructed)
//    if(!vtx->isFake() && vtx->ndof() > 4 && fabs(vtx->z()) <= 24. && vtx->position().Rho() <= 2) {
if(!vtx->isFake()) {
...
// compute position differences w.r.t. the beamspot
// taking into account the beamspot slope : reco::BeamSpot::x(const double z), reco::BeamSpot::y(const double z)
double deltax = vtx->x()-bs->x(vtx->z());
double deltay = vtx->y()-bs->y(vtx->z());
// WITHOUT taking into account the beamspot slope : reco::BeamSpot::x0(), reco::BeamSpot::y0()
double deltaxnoslope = vtx->x()-bs->x0();
double deltaynoslope = vtx->y()-bs->y0();

double deltaz = vtx->z()-bs->z0();

// Fill the histograms
m_hdeltax->Fill(deltax);
m_hdeltay->Fill(deltay);
m_hdeltaz->Fill(deltaz);
m_hdeltaxvsz->Fill(vtx->z(),deltax);
m_hdeltayvsz->Fill(vtx->z(),deltay);
m_hdeltaxvsznoslope->Fill(vtx->z(),deltaxnoslope);
m_hdeltayvsznoslope->Fill(vtx->z(),deltaynoslope);
}
}
```

-- AndreaVenturi - 13-Dec-2011

Topic attachments
I Attachment History Action Size Date Who Comment
gif deltax_176309_ZB.gif r1 manage 12.5 K 2011-12-28 - 22:23 AndreaVenturi PV-BS deltaX
gif deltaxyvsz_176309_ZB.gif r1 manage 23.6 K 2011-12-28 - 22:29 AndreaVenturi deltax and delta y vs z
gif deltaxyvsz_zoom_176309_ZB.gif r1 manage 28.3 K 2011-12-28 - 22:29 AndreaVenturi delta x and delta y vs z zoom
gif deltay_176309_ZB.gif r1 manage 11.5 K 2011-12-28 - 22:23 AndreaVenturi PV-BS deltaY
gif deltaz_176309_ZB.gif r1 manage 12.3 K 2011-12-28 - 22:24 AndreaVenturi PV-BS deltaZ
gif ndof_176309_ZB.gif r1 manage 12.1 K 2011-12-28 - 22:19 AndreaVenturi vertex number of degrees of freedom
gif ndofvsntrks_176309_ZB.gif r1 manage 12.7 K 2011-12-28 - 22:19 AndreaVenturi vertex ndof vs ntrks
gif ntrks_176309_ZB.gif r1 manage 12.0 K 2011-12-28 - 22:18 AndreaVenturi vertex track multiplicity
gif nvtx_176309_ZB.gif r1 manage 9.1 K 2011-12-28 - 21:47 AndreaVenturi Vertex multiplicity ZeroBias events run 176309
gif nvtx_log_176309_ZB.gif r1 manage 8.1 K 2011-12-28 - 21:48 AndreaVenturi Vertex multiplcity ZeroBias events run 176309
gif nvtxvslumi_176309_ZB.gif r1 manage 16.0 K 2011-12-28 - 22:05 AndreaVenturi vertex mutliplicity vs luminosity run 176309 zerobias events
gif nvtxvslumi_slices_176309_ZB.gif r1 manage 10.8 K 2011-12-28 - 22:14 AndreaVenturi vertex mutliplicity in two luminosity slices
gif nvtxvslumi_slices_log_176309_ZB.gif r1 manage 10.4 K 2011-12-28 - 22:15 AndreaVenturi vertex multiplicity in two luminosity slices (log scale)
gif nvtxvslumi_withfit_176309_ZB.gif r1 manage 17.7 K 2011-12-28 - 22:06 AndreaVenturi vertex mutliplicity vs luminosity with fit run 176309 zerobias events
gif nvtxvstime_176309_ZB.gif r1 manage 11.3 K 2011-12-28 - 22:02 AndreaVenturi vertex multiplicity vs time
gif nvtxvstime_withfit_176309_ZB.gif r1 manage 12.3 K 2011-12-28 - 21:54 AndreaVenturi vertex multiplicity vs time with exponential fit: ZB events run 176309
Edit | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | More topic actions
Topic revision: r11 - 2012-01-22 - AndreaVenturi

Webs

Welcome Guest

 Cern Search TWiki Search Google Search Main All webs
Copyright &© 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