Introduction
Starting first with a preliminary exrecise in order to be familiar with runTheMatrix .
Identify with the Facilitator which release to be used, and discuss what is a runthematrix command.
runTheMatrix.py contains standard workflows (series of cmsDriver commands) for each release. The list of workflows can be obtained using runTheMatrix.py -ne
Identify the main options thanks to the --help options
How Can I get a 2017 Workflows
is there data workflow available ?
How Can I get SingleMuon ?
How Can I display the cmsdriver command for a given Workflow ?
How the pile up is simulated ?
Generate 1 events of TTBar without PU with the 2017 Pixel
Generate 1 events of TTBar with PU35 standard Mixing with the 2017 Pixel
We can also try to generate events with Phase2 - Note the Bible to know what are the phase2 scenario :
https://github.com/cms-sw/cmssw/blob/master/Configuration/Geometry/README.md
How Can I get a 2023 Workflows
How Can I get SingleMuon ? (extended?)
Generate 1 events of TBar without PU with the appropriate 2023 scenario
First Exercise
The goal of this exercise is to get you familiar with the various component of the Tracker Detector after having followed the slides for introduction .
Accessing Geometry
Create a skeleton for an analyser module, which we will call 'GeometryAnalyzer', and build it.
$ cmsrel CMSSW_9_3_0_pre5
$ cd CMSSW_9_3_0_pre5/src
$ cmsenv
$ mkdir GeomAnalyzer
$ cd GeomAnalyzer
$ mkedanlzr GeometryAnalyzer
$ cd GeometryAnalyzer/src
$ scramv1 b
Modify the configuration file that is created so that you can access the event you enerated earlier with runTheMatrix (step1.root) and verify that the example analyzer runs as expected.
Next, modify the skeleton analyzer that was created so that you are sure it is actually getting inserted into the analysis path:
Access to the geometry is provided by the
TrackerGeometry class, a handle to which is obtained using
ESHandle < TrackerGeometry > theTrackerGeometry;
iSetup.get < TrackerDigiGeometryRecord > ().get(theTrackerGeometry);
Using these classes requires including their header files:
#include "FWCore/Framework/interface/ESHandle.h"
#include "Geometry/TrackerGeometryBuilder/interface/TrackerGeometry.h"
#include "Geometry/Records/interface/TrackerDigiGeometryRecord.h"
Look at the following code
https://github.com/cms-sw/cmssw/blob/master/DataFormats/TrackerCommon/src/TrackerTopology.cc
TrackerTopology is deriving a hierarchical numbering scheme for the tracker modules from the geometry
please write few lines with using trackertopology
#include "DataFormats/TrackerCommon/interface/TrackerTopology.h"
#include "Geometry/Records/interface/TrackerTopologyRcd.h"
use the cms tool cmsglimpse to find in cmssw how to use it , example:
$ cmsglimpse tTopoHandle
for example, please loop over the
CMS detids container and print the layer for the pixelBarrel , extend the exercise in TOB
Important : for this exercise please commit your code in a github branch , the branch should be : YourlastnameBariGeom
Motivation : to be familair with github and I can look later at your code
Third Exercise
Let's try to be familiar with the tracker performance using DQM tools and identify some recent issues on data and MC (see slides)
Fourth Exercise
Depending on progress and whishes , one can look at digis , or edit develop a DQM plots or simhit map , phase2 ?...
--
GaelleBoudoul - 2017-09-03