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. contains standard workflows (series of cmsDriver commands) for each release. The list of workflows can be obtained using -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 :

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

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

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2017-09-04 - GaelleBoudoul
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

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