Difference: CMSSWatFNALTutorialJuly2006 (1 vs. 7)

Revision 62006-11-27 - KatiLassilaPerini

Line: 1 to 1
 
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Line: 254 to 254
 
    • Clustering and RecHit Conversion of Pixel and Strip Tracker signals
    • Track Reconstruction using the RoadSearch Seed Finding and Pattern Recognition and the CkF Seed Finding and Pattern Recognition both completed with a Kalman Final Fit
    • The tracking chain is a good example for the usage of .cfi and .cff files and worth looking at in detail. If an included file is not found in the local CMSSW project by the framework, it is automatically looked up in the release area which is accessible via the environment variable $CMSSW_RELEASE_BASE. Each module can have a .cff file which includes the .cfi file of the module and all needed services by inclusion of their .cfi respective files. This enables the user just to include the .cff file in his parameter-set and relieves him from having to know about the required services.
Changed:
<
<
>
>
 
    • Digitization of signals from the DT chambers, the CSC and the RPC
    • RecHit conversion and 2D and 4D segment reconstruction for the DT chambers
    • RecHit conversion and segment reconstruction for the CSC

Revision 52006-08-08 - OliverGutsche

Line: 1 to 1
 
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Line: 999 to 999
  which creates a new collection of TrackUtil's per event and fills exactly one entry per event.
Changed:
<
<
Now, we compile the EDProducer using SCRAMV1:
>
>
Now, we compile the EDProducer and the new DataFormats using SCRAMV1:
 
Changed:
<
<
cd <CMSSW-Project-Directory>/src/MyCode/MyTrackUtility
>
>
cd <CMSSW-Project-Directory>/src
 scramv1 b

Revision 42006-07-19 - JennyWilliams

Line: 1 to 1
 
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Line: 258 to 258
 
    • Digitization of signals from the DT chambers, the CSC and the RPC
    • RecHit conversion and 2D and 4D segment reconstruction for the DT chambers
    • RecHit conversion and segment reconstruction for the CSC
Changed:
<
<
>
>
 
    • Digitization of ECAL and HCAL signals
    • ECAL and HCAL RecHit conversion
    • Island and Hybrid Clustering in the ECAL

Revision 32006-07-12 - OliverGutsche

Line: 1 to 1
 
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Line: 714 to 714
 Now, we compile the EDFilter using SCRAMV1:
Changed:
<
<
cd <CMSSW-Project-Directory>/src/MyCode/MyTrackAnalyzer
>
>
cd <CMSSW-Project-Directory>/src/MyCode/MyTrackFilter
 scramv1 b

Revision 22006-07-12 - OliverGutsche

Line: 1 to 1
 
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Line: 276 to 276
 tutorial.root
Added:
>
>
Larger Samples

Already prepared samples with 1000 events are available on dCache. Before you copy one of the files, please make sure that you have enough diskspace. To copy files from dCache to your current directory, do

dccp /pnfs/cms/WAX/resilient/gutsche/tutorial/July06CMSSWtutorial/tutorial-1mu.root `pwd`/tutorial-1mu.root
dccp /pnfs/cms/WAX/resilient/gutsche/tutorial/July06CMSSWtutorial/tutorial-higgs.root `pwd`/tutorial-higgs.root

Attention, each file is 4 GB.

 

Bare ROOT access

The CMSSW root file is directly browseable in ROOT. Open the ROOT file with:

Revision 12006-07-12 - OliverGutsche

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="RoadSearch"

CMSSW@FNAL tutorial 12th July 2006

Disclaimer

This software tutorial gives an introduction to the new CMS framework CMSSW for very first beginners. It is based on the latest major CMSSW release, CMSSW_0_7_2, and it is designed to be run at the cmsuaf interactive workgroup cluster at FNAL. The tutorial is not meant to be complete in explaining all details of CMSSW concerning reconstruction and analysis. But it should give a good basis for working in CMSSW and all needed skills to start developing code and doing analysis.

CMSSW is still undergoing heavy development. The tutorial shows the state of reconstruction and analysis capabilities of CMSSW_0_7_2. It cannot be guaranteed that all functionality will be available in the here presented form in following releases due to the rapid development cycles of CMSSW. Functionality can be added and existing functionality can be optimized and therefore changed. The user is kindly requested to follow the pre-releases which are made available before major releases and follow the CMS TWiki and the CERN hypernews forums.

All here presented information is based on the CMSSW tutorials held during the CMS week June 2006. Thanks to all who prepared the tutorials and spend a significant amount of time next to their normal development duties.

I encourage everyone to ask as many questions as possible and leave the suggested path whenever the user wants to try something which is not presented in the tutorial. It cannot be guaranteed that all questions can be answered but surely a start in solving these problems can be made.

Tutorial

In this tutorial, we want to:

  1. Setup a CMSSW release and check out needed tutorial input from CVS
  2. Run the full chain from simulation to reconstruction
  3. Have a more detailed look at the used parameter-sets
  4. Access the output in different analysis modes
  5. Learn how to write code in the framework using skeleton generators

Setup

The following instructions are an extract from CMS WorkBook: Setting up your Computing Environment.

After getting a valid addressless FNAL Kerberos token on your local machine by executing

kinit -n

on Scientific Linux or a similar command on other platforms, login to the cmsuaf by:

ssh -l <USERNAME> -X cmsuaf.fnal.gov

If this does not work, please have alook at USCMS instructions: connecting to the UAF.

FNAL users on the cmsuaf have three different directories with diskspace available:

1. afs home directory, check quota with:

cd $HOME
fs lq

2. Ibrix home directory (in backup) at

/uscms/home/<username>

check quota with

ibrix_uquota

3. Ibrix user data directory (not in backup) at

/uscms_data/d1/<username>

Go to your Ibrix user data directory, create a directory called "tutorial" and change to this directory

cd /uscms_data/d1/<username>
mkdir tutorial
cd tutorial

Setup the FNAL local software installation by sourcing the FNAL setup script when you are using a shell from the csh family:

source /afs/fnal.gov/files/code/cms/setup/cshrc uaf

or if you are using a shell from he sh family

source /afs/fnal.gov/files/code/cms/setup/shrc uaf

Use SCRAMV1 to create a user project directory of the CMSSW release CMSSW_0_7_2 and change the directory to it:

scramv1 project CMSSW CMSSW_0_7_2
cd CMSSW_0_7_2/src

For more information about SCRAMV1, please have a look at the SCRAMV1 introduction.

After creating a local project directory, the release, the PATH and the LD_LIBRARY_PATH have to be setup from within the project area. If you are using a shell from the csh family, do:

eval `scramv1 runtime -csh`

or if you are using a shell from the sh family, do:

eval `scramv1 runtime -sh`

In the following, we use anonymous CVS access to the CERN CVS repository to retrieve needed input for the tutorial. The CVS access is setup by

cmscvsroot CMSSW

followed by a login using the well-known password:

cvs login

Check out needed input for the tutorial by

cvs co -r TUTORIAL_0_7_2 UserCode/Gutsche/Tutorial
cvs co -r V01-00-09 Geometry/TrackerRecoData

which concludes the setup.

CMSSW introduction

An introduction to the CMSSW framework can be found in the CMSSW Application Framework Introduction:

The overall collection of software, referred to as CMSSW, is built around a Framework, an Event Data Model (EDM), and Services needed by the simulation, calibration and alignment, and reconstruction modules that process event data so that physicists can perform analysis. The primary goal of the Framework and EDM is to facilitate the development and deployment of reconstruction and analysis software.

The CMSSW framework implements a software bus model wherein there is one executable, called cmsRun, and many plug-in modules which run algorithms. The same executable is used for both detector and Monte Carlo data. This framework is distinct from a more traditional approach in which several executables are used, one per task or set of tasks.

The CMSSW executable, cmsRun, is configured at run time by the user's job-specific configuration file (parameter-set). This file tells cmsRun which data to use, which modules to run, which parameter settings to use for each module, and in what order to run the modules. Required modules are dynamically loaded at the beginning of the job.

The CMS Event Data Model (EDM) is centered around the concept of an Event as a C++ object container for all RAW and reconstructed data pertaining to a physics event. During processing, data are passed from one module to the next via the Event, and are accessed only through the Event. All objects in the Event may be individually or collectively storable as ROOT files, and are thus directly browsable in ROOT.

Module types

CMSSW distinguishes following module types:

  • EDProducer: takes input from the event and produces new output which is saved in the event
  • EDAnalyzer: takes input from the event and processes the input without writing information back to the event
  • EDFilter: decides if processing the event can be stopped and continued
  • EventSetup: external service not bound to the event structure which provides information useable by all modules

CVS

The CMSSW code is stored in the central CVS repository at CERN.

The repository structure is based on the separation Package/Module. Two packages have to be mentioned in particluar

DataFormats
SimDataFormats

which hold the object containers and objects which can be persistet in the event and therefore written out to file. The remaining Packages and Modules contain algorithmic code to process and produce DataFormats.

Parameter-Set

A parameter-set is used to configure the cmsRun executable and to schedule the execution of modules in a given order. It is based upon the concept of a set:

<identifier> <name> = <module/service> 
{
...
<parameters>
...
}

where the parameters can be variables or set's as well.

The parameter-set handed over to the cmsRun executable is called the process set:

process <process name> = 
{
...
}

and represents the top of the parameter-set hierarchy.

The typical components of a process set are:

  • services which are not bound to the event separation and used by all modules (e.g. geometry, magnetic field, ...)
  • modules which should be executed (EDProducer, EDAnalyzer, EDFilter)
  • the endpath, path's and sequences which define ordered execution of modules and therefore specify what the cmsRun executable has to do.

For example, a module is defined in a parameter-set by:

module <module-label> = <module-name>
{
...
<module-parameter>
...
}

Parameter-Set Inclusion and Defaults

Parameter-sets can include other parameter-sets via the inclusion mechanism:

include "<path to parameter-set relative to <CMSSW_PROJECT_DIR>/src>/<parameter-set>"

CMSSW modules do not contain hardcoded defaults for their parameters. Therefore, each module (will have) has a default parameter-set in

<Package>/<Module>/data/<Module-Label>.cfi

with the ending .cfi which defines only the module in question and gives the default parameters. The .cfi file of a Module is named after the Module Label. To change the parameters from their default, include the .cfi and change individual variables via the replace mechanism. Multiple inclusion of the same .cfi is resolved by the framework.

MessageLogger

A special service is the MessageLogger which provides a unified interface to messages (standard output, standard error, ...) from the cmsRun executable. The MessageLogger has the ability to restrict the output and redirect it to several destinations like the screen, ascii files, ... . The default configuration of the MessageLogger is included in the parameter-set by including

include "FWCore/MessageLogger/data/MessageLogger.cfi"

and should be included in every top level parameter-set.

More information about the MessageLogger and its configuration possibilities can be found at the MessageLogger TWiki page.

Simulation and Reconstruction

The simulation and reconstruction parameter-set was composed from the different tutorials given during the CMS week in June 2006. The parameter-set and its includes are contained in the module checked out during the setup and can be run by

cd UserCode/Gutsche/Tutorial
cmsRun tutorial.cfg

The used parameter-set is setup to generate 10 single muon events with pT = 10 GeV. In the parameter-set, also the generation of events with 4 muons and single pions as well as the simulation of H->ZZ->4mu with Pythia is prepared and can be changed by the user. The generation is followed by the simulation where also the vertex smearing and mixing module which defines the bunch spacing is defined.

The following properties are reconstructed in the generated events:

  • Tracks (taken from the Track Reconstruction Tutorial) consisting of the following steps
    • Digitization of Pixel and Strip Tracker signals
    • Clustering and RecHit Conversion of Pixel and Strip Tracker signals
    • Track Reconstruction using the RoadSearch Seed Finding and Pattern Recognition and the CkF Seed Finding and Pattern Recognition both completed with a Kalman Final Fit
    • The tracking chain is a good example for the usage of .cfi and .cff files and worth looking at in detail. If an included file is not found in the local CMSSW project by the framework, it is automatically looked up in the release area which is accessible via the environment variable $CMSSW_RELEASE_BASE. Each module can have a .cff file which includes the .cfi file of the module and all needed services by inclusion of their .cfi respective files. This enables the user just to include the .cff file in his parameter-set and relieves him from having to know about the required services.
  • Muon segments (taken from the Muon Segment Reconstruction Tutorial) consisting of the following steps:
    • Digitization of signals from the DT chambers, the CSC and the RPC
    • RecHit conversion and 2D and 4D segment reconstruction for the DT chambers
    • RecHit conversion and segment reconstruction for the CSC
  • CAL clusters and islands (taken from ECAL Clustering Tutorial and the HCAL Reconstruction Tutorial) consisting of the following steps:
    • Digitization of ECAL and HCAL signals
    • ECAL and HCAL RecHit conversion
    • Island and Hybrid Clustering in the ECAL
    • CaloTower creation in the HCAL
    • The CAL reconstruction is a good example for the usage of the replace mechanism in parameter-sets
  • Jet and MET (taken from Jet Reconstruction Tutorial) consisting of the following steps:
    • Jet reconstruction using the Kt and the Cone algorithm
    • MET reconstruction
    • Jet reconstruction from simulated information using the Kt and the Cone algorithm
    • MET reconstruction from simulated information

The given parameter-set produces a ROOT file with the name

tutorial.root

Bare ROOT access

The CMSSW root file is directly browseable in ROOT. Open the ROOT file with:

root.exe tutorial.root

and ignore all warnings about missing dictionaries. Dictionaries enable ROOT to understand objects and access their member functions. They are needed for more complex operations. Bare ROOT is the simplest access method where the dictionaries are not needed.

Open a TBrowser to look at the tutorial ROOT file:

[1] new TBrowser;

Open the top level of the file by:

  • double-click on "ROOT Files" in the left pane of the TBrowser window
  • double-click on "tutorial.root" in the left pane of the TBrowser window

You see the top level of the CMSSW ROOT file. For the user, only the "Events" tree is important because it holds all the collections of objects. Open the "Events" tree by

  • double-click on "Events" in the left pane of the TBrowser window

Now you see all branches includede in the tutorial ROOT file. A branch name is composed of:

<collection-name>_<module-label>_<module-instance-label>__<process label>

and is meant to be unique. Therefore, the <collection-name> sometimes can be long and complicated to guarantee the uniqueness. The <module-instance-label> is only used if an EDProducer produces several collections of the same type to distinguish them.

Go to the RS track branch

recoTracks_RSWMaterial__T

and double-click it. You can see in the right pane the representation of the track collection:

recoTracks_RSWMaterial__T.obj

and another double click on the track collection representation shows you the data members of the reco::Track class. Double-click on one of the data members (for example recoTracks_RSWMaterial__T.obj.found_) loops over all tracks in all events in the file and plots the number of hits per track.

If you want to know more about the objects within a collection, use Doxygen (also called the Reference Manual for the used release: Doxygen for CMSSW_0_7_2. At the top of the page, you can find the link to the class list where you can look up reco::Track.

The reco::Track Class Reference shows you the inheritance of the track class and its member functions. A very useful feature is List of all members which shows you all accessible member functions also from the base classes.

Another very useful tool is the LXR browser which provides full text search in the code repository. You can also search for the location and content of specific filenames which comes in handy if you want to look for .cfi, .cff or includede header files.

Data mambers of objects in the collections are also accessible directly in bare ROOT. You can plot the chi-squared distribution of tracks by using the full path of the private data member in the ROOT file

Events->Draw("recoTracks_RSWMaterial__T.obj.chi2_");

For the reduced chi-squared, you have to divide by the number of degrees of freedom which can be easily achieved by

Events->Draw("recoTracks_RSWMaterial__T.obj.chi2_/recoTracks_RSWMaterial__T.obj.ndof_")

FWLite access

More sophisticated analysis possibilities are offered by the FWLite mode which has access to all class dictionaries contained in a CMSSW ROOT file. The reprocessing of data, however, is not possible in the FWLite mode.

The FWLite example presented here uses the generated H->ZZ->4mu sample. Two ROOT macros are needed to reconstruct the Higgs mass in FWLite:

  • analyze_HZZ_head.C:
    • enable automatic loading of DataFormats libraries
    • load the ROOT file
  • analyze_HZZ.C:
    • get the event tree from the file
    • get a branch containing tracks and set the branch address to a before created collection instance
    • loop over the branch entries in each event
      • get the branch entry, i.e. the tracks
      • access the branch, i.e. the track information

Please adapt analyze_HZZ_head.C to load the correct ROOT file and analyze_HZZ.C to access the correct track branch which name you can check with Bare ROOT:

   TBranch *branch = tree->GetBranch("recoTracks_RSWMaterial__T.obj");

Start ROOT:

root.exe

to extract the Z and Higgs mass running the following FWLite macros:

.x analyze_HZZ_head.C
.x analyze_HZZ.C

to produce a ROOT file HZZ.root which contains histograms which can be opened in ROOT:

root.exe HZZ.root

to draw the Higgs and Z mass peaks

mmumu->Draw();
mzz->Draw();

If you want to read more than one branch in your loop, you have to double the branch connection code and call for each branch

branch->GetEntry(index);

CMSSW file access and output to file

The entry point for the cmsRun executable is an event source. Previously, we used MC generators to generate events which were then reconstructed. CMSSW has also to be able to read in CMSSW ROOT files. This is handled by the PoolSource:

source = PoolSource 
{
  untracked vstring fileNames = {"file:tutorial-simulation.root"}
  untracked int32 maxEvents = -1
}

The PoolSource is able to read in a comma-separated list of files. CMSSW will check if the files are compatible and throw an exception if it is not the case. The file: in front of the filename is needed to tell CMSSW that the file it should open is a local file.

The output is handled by the PoolOutputModule:

module Out = PoolOutputModule
{
  untracked string fileName = "tutorial-cal.root"
}

In general, everything from the input file is copied to the output file. But the PoolOutputModule can be told to skip specific branches following the Instructions how to configure Output Modules.

Different to the input source which does not have to be scheduled in the path, the output module has to be scheduled in the endpath. A parameter-set can have several path's which are all executed. The endpath is guaranteed to be executed per event after all other path's have been executed.

The tutorial module provides parameter-sets which split the tutorial.cfg into different steps writing out intermediate information to file and reading it back. Following parameter-sets are provided:

  • tutorial-simulation.cfg: runs generation and simulation and writes out intermediate ROOT file
  • tutorial-tracking.cfg: takes simulation ROOT file as input, performs track reconstruction and writes out intermediate ROOT file
  • tutorial-cal.cfg: takes simulation ROOT file as input, performs CAL and Jet/MET reconstruction and writes out intermediate ROOT file
  • tutorial-muon.cfg: takes simulation ROOT file as input, performs MUON RecHit and segment reconstruction and writes out intermediate ROOT file

EDAnalyzer

To write an EDAnalyzer, one can use the skeleton code generators provided by the framework. You can create an EDAnalyzer by:

cd <CMSSW-Project-Directory>/src
mkdir MyCode
cd MyCode
mkedanlzr MyTrackAnalyzer

This will produce the correct code pieces for an EDAnalyzer which have to be filled with functionality now.

In the created subdirectory MyTrackAnalyzer, you can find the standard structure of a CMSSW module:

  • BuildFile: directives for SCRAMV1 how to compile this module and which other libraries to include
  • doc: directory for documentation
  • interface: directory for header files
  • src: directory for source files
  • test: directory for test parameter-sets

The skeleton generator already created a template BuildFile and source file for our track EDAnalyzer. After compilation, the libraries are available in <CMSSW-Project-Directory>/lib/slc3_ia32_gcc323 and the track EDAnalyzer module is available to all parameter-sets.

To prepare the access to tracks, the track library has to be added to the BuildFile by including:

<use name=DataFormats/TrackReco>
<use name=FWCore/MessageLogger>

Also the MessageLogger library has to be added.

Then we add our analyzer code into MyTrackAnalyzer/src/MyTrackAnalyzer.cc. We add the inclusion of following header files at the top:

#include <string>
#include "DataFormats/TrackReco/interface/TrackFwd.h"
#include "DataFormats/TrackReco/interface/Track.h"
#include "FWCore/MessageLogger/interface/MessageLogger.h"

to be able to access reco::Track objects and use the MessageLogger.

We want to use a parameter for the module-label of the tracks to be able to read in different track collections. For this, we need to add a private data member in the class definition:

class MyTrackAnalyzer : public edm::EDAnalyzer {
   public:
      explicit MyTrackAnalyzer(const edm::ParameterSet&);
      ~MyTrackAnalyzer();


      virtual void analyze(const edm::Event&, const edm::EventSetup&);
   private:
      // ----------member data ---------------------------
      std::string trackProducerName;
};

and fill it in the constructor using the parameter-set information parsed at startup of cmsRun:

//
// constructors and destructor
//
MyTrackAnalyzer::MyTrackAnalyzer(const edm::ParameterSet& iConfig)
{
   //now do what ever initialization is needed
   trackProducerName = iConfig.getParameter<std::string>("TrackProducer");

}

Next we replace the example code in MyTrackAnalyzer::analyze with

void
MyTrackAnalyzer::analyze(const edm::Event& iEvent, const edm::EventSetup& iSetup)
{
   // Get Inputs
   edm::Handle<reco::TrackCollection> tracks;
   iEvent.getByLabel(trackProducerName, tracks);
   
   edm::LogInfo("Tutorial") << "number of Tracks: " << tracks->size();

   for ( reco::TrackCollection::const_iterator track = tracks->begin(); track != tracks->end(); ++track ) {
      edm::LogInfo("Tutorial") << "Perigee-Parameter: transverseCurvature: " << track->transverseCurvature();
      edm::LogInfo("Tutorial") << "Perigee-Parameter: theta: " << track->theta();
      edm::LogInfo("Tutorial") << "Perigee-Parameter: phi0: " << track->phi0();
      edm::LogInfo("Tutorial") << "Perigee-Parameter: d0: " << track->d0();
      edm::LogInfo("Tutorial") << "Perigee-Parameter: dz: " << track->dz();
   }

}

Now, we compile the EDAnalyzer using SCRAMV1:

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackAnalyzer
scramv1 b

Finally, we write a parameter-set which defines the module and sets the TrackProducer parameter to the module label of one of the track collections:

process A = 
{

  #
  # initialize  MessageLogger
  #
  include "FWCore/MessageLogger/data/MessageLogger.cfi"

  #
  # load input file
  #
  source = PoolSource 
  {
    untracked vstring fileNames = {"file:tutorial.root"}
    untracked int32 maxEvents = -1
  }

  module analyzer = MyTrackAnalyzer
  {
    string TrackProducer = "RSWMaterial"
  }


  path p = 
  {
    analyzer
  }

}

We safe this parameter-set in

<CMSSW-Project-Directory>/src/MyCode/MyTrackAnalyzer/test/test-mytrackanalyzer.cfg

copy a CMSSW ROOT file from the above presented reconstruction to the same directory and execute it with

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackAnalyzer/test
cmsRun test-mytrackanalyzer.cfg

All of the above created code is available in the tutorial input module in

<CMSSW-Project-Directory>/src/UserCode/Gutsche/Tutorial/MyCode/MyTrackAnalyzer

where the extension .tutorial has been added to all files. The files are stored in the correct directory structure of the module. If the user wants to skip the step of writing the code himself, he just has to copy the MyTrackAnalyzer directory to

<CMSSW-Project-Directory>/src/MyCode

remove the .tutorial extension and compile.

EDFilter

The second most useful module for analysis is the EDFilter.

In a process set, the execution of different modules is steered by the path. It triggers the execution and defines the order in which modules are executed. An EDFilter checks the current execution state in a path and continues only on the path if the requirements are fullfilled. En example can be the reconstruction of H->ZZ->4mu events where an EDFilter checks after track reconstruction that at least 4 tracks have been reconstructed and then continue with vertexing. Or you can restrict the events written out to the output file by including an EDFilter before the output module in the endpasth.

To write an EDFilter, one can again use the skeleton code generators provided by the framework. You can create an EDFilter by:

cd <CMSSW-Project-Directory>/src
mkdir MyCode
cd MyCode
mkedfltr MyTrackFilter

This will produce the correct code pieces for an EDFilter which have to be filled with functionality.

To prepare the access to tracks, the track library has to be added to the BuildFile by including:

<use name=DataFormats/TrackReco>
<use name=FWCore/MessageLogger>

Also the MessageLogger library has to be added.

Then we add our analyzer code into MyTrackFilter/src/MyTrackFilter.cc. We add the inclusion of following header files at the top:

#include <string>
#include "DataFormats/TrackReco/interface/TrackFwd.h"
#include "DataFormats/TrackReco/interface/Track.h"
#include "FWCore/MessageLogger/interface/MessageLogger.h"

to be able to access reco::Track objects and use the MessageLogger.

We want to use a parameter for the module-label of the tracks to be able to read in different track collections. And we want the filter to cut on the maximal and minimal number of tracks per event. So we add three parameters following the approach in the EDAnalyzer. They have to be added as private data members in the class definition:

class MyTrackFilter : public edm::EDFilter {
   public:
      explicit MyTrackFilter(const edm::ParameterSet&);
      ~MyTrackFilter();


      virtual bool filter(edm::Event&, const edm::EventSetup&);
   private:
      // ----------member data ---------------------------
      std::string trackProducerName;
      unsigned int minimalNumberOfTracks;
      unsigned int maximalNumberOfTracks;
};

and in the constructor to fill them with the parameters from the parameter-set:

MyTrackFilter::MyTrackFilter(const edm::ParameterSet& iConfig)
{  
   //now do what ever initialization is needed
   trackProducerName = iConfig.getParameter<std::string>("TrackProducer");
   minimalNumberOfTracks = iConfig.getParameter<unsigned int>("MinimalNumberOfTracks");
   maximalNumberOfTracks = iConfig.getParameter<unsigned int>("MaximalNumberOfTracks");
}

As we introduced real parameters which have to have defaults, we have to write a .cfi file:

<CMSSW-Project-Directory>/src/MyCode/MyTrackFilter/data/trackFilter.cfi

and instantiate the filter module in it defining the default parameter:

module trackFilter = MyTrackFilter
{
  string TrackProducer = "RSWMaterial"
  uint32 MinimalNumberOfTracks = 0
  uint32 MaximalNumberOfTracks = 999999
}

Next we replace the example code in MyTrackFilter::filter with

// ------------ method called to produce the data  ------------
bool
MyTrackFilter::filter(edm::Event& iEvent, const edm::EventSetup& iSetup)
{
   // Get Inputs
   edm::Handle<reco::TrackCollection> tracks;
   iEvent.getByLabel(trackProducerName, tracks);

   bool result = false;

   if ( (tracks->size() <= maximalNumberOfTracks) &&
        (tracks->size() >= minimalNumberOfTracks) ) {
        edm::LogInfo("Tutorial") << "Event passed MyTrackFilter with " << tracks->size() << " tracks!";
        result = true;
   }

  return result;
}

Now, we compile the EDFilter using SCRAMV1:

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackAnalyzer
scramv1 b

Finally, we write a parameter-set which includes the .cfi of our module and sets the TrackProducer parameter to the module label of one of the track collections:

process F =
{

  #
  # initialize  MessageLogger
  #
  include "FWCore/MessageLogger/data/MessageLogger.cfi"

  #
  # load input file
  #
  source = PoolSource
  {
    untracked vstring fileNames = {"file:tutorial.root"}
    untracked int32 maxEvents = -1
  }

  # include MyTrackFilter
  include "MyCode/MyTrackFilter/data/trackFilter.cfi"
  replace trackFilter.MinimalNumberOfTracks = 4
  replace trackFilter.MaximalNumberOfTracks = 4

  #
  # write results out to file
  #
  module Out = PoolOutputModule
  {
    untracked string fileName = "tutorial-filtered.root"
  }

  endpath e =
  {
    trackFilter,Out
  }
}

You can see that the filter is scheduled before the output module in the endpath. The replace syntax is used to change the minimual and maximal number of tracks parameters to 4. This means that only events with exactly 4 reconstructed events are written out to file.

We safe this parameter-set in

<CMSSW-Project-Directory>/src/MyCode/MyTrackFilter/test/test-mytrackfilter.cfg

copy the H->ZZ->4mu CMSSW ROOT file from the above presented reconstruction to the same directory and execute it with

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackFilter/test
cmsRun test-mytrackfilter.cfg

All of the above created code is available in the tutorial input module in

<CMSSW-Project-Directory>/src/UserCode/Gutsche/Tutorial/MyCode/MyTrackFilter

where the extension .tutorial has been added to all files. The files are stored in the correct directory structure of the module. If the user wants to skip the step of writing the code himself, he just has to copy the MyTrackFilter directory to

<CMSSW-Project-Directory>/src/MyCode

remove the .tutorial extension and compile.

EDProducer

After writing an analysis step in FWLite or in an EDAnalyzer, the user can transform it into an EDProducer and create an own DataFormats object to be persistet into the event file for easier access. This is prefereable if the execution time of an analysis step gets too longs to be excuted interactively.

First, we have to write the DataFormats object. Goal is to write an object which stores the number of tracks as a private data member and persist it into the event file.

First, we create a DataFormats package and its directory structure

cd <CMSSW-Project-Directory>/src
mkdir -p DataFormats/TrackUtil
cd DataFormats/TrackUtil
mkdir interface
mkdir src

and we create a simple BuildFile in the new DataFormats package which only links the needed code for persisting objects in the ROOT file:

<use name=DataFormats/Common>
<export>
 <lib name=DataFormatsTrackUtil>
 <use name=DataFormats/Common>
</export>

we then create header files for the class itself

interface/TrackUtil.h

containing

#ifndef DATAFORMATS_TRACKUTIL_H
#define DATAFORMATS_TRACKUTIL_H


class TrackUtil {
public:

  TrackUtil() {}
  TrackUtil(unsigned int tracks): numTracks_(tracks) {}

  inline unsigned int GetNumberOfTracks() { return numTracks_; }
  inline void SetNumberOfTracks(unsigned int tracks) { numTracks_ = tracks; }

private:

  unsigned int numTracks_;

};

#endif // DATAFORMATS_TRACKUTIL_H

and the header file for the collection:

interface/TrackUtilCollection.h

containing

#ifndef DATAFORMATS_TRACKUTILCOLLECTION_H
#define DATAFORMATS_TRACKUTILCOLLECTION_H

#include <vector>
#include "DataFormats/TrackUtil/interface/TrackUtil.h"

typedef std::vector<TrackUtil> TrackUtilCollection;

#endif // 

The information for the framework to persist the class have to be coded into two files in the src directory, the

src/classes.h

containing

#ifndef TRACKUTIL_CLASSES_H
#define TRACKUTIL_CLASSES_H

#include "DataFormats/TrackUtil/interface/TrackUtilCollection.h"
#include "DataFormats/Common/interface/Wrapper.h"
#include <vector>

namespace {
  namespace {
    edm::Wrapper<TrackUtilCollection> trackUtilCollectionWrapper;
  }
}

#endif // TRACKUTIL_CLASSES_H

and the

src/classes_def.xml

containing

<lcgdict>
  <class name="TrackUtil"/>
  <class name="std::vector<TrackUtil>"/>
  <class name="edm::Wrapper<std::vector<TrackUtil> >"/>
</lcgdict>

As before, the example code is provided in the input module in

<CMSSW-Project-Directory>/src/UserCode/Gutsche/Tutorial/DataFormats/TrackUtil

where the extension .tutorial was added to each file.

To write an EDProducer, one can again use the skeleton code generators provided by the framework. You can create an EDProducer by:

cd <CMSSW-Project-Directory>/src
mkdir MyCode
cd MyCode
mkedprod MyTrackUtility

This will produce the correct code pieces for an EDProducer which have to be filled with functionality.

To prepare the access to tracks and the new DataFormats, the track library and the TrackUtil library have to be added to the BuildFile by including:

<use name=DataFormats/TrackReco>
<use name=FWCore/MessageLogger>
<use name=DataFormats/TrackUtil>

Also the MessageLogger library has to be added.

Then we add our analyzer code into MyTrackUtility/src/MyTrackUtility.cc. We add the inclusion of following header files at the top:

#include <string>
#include "DataFormats/TrackReco/interface/TrackFwd.h"
#include "DataFormats/TrackReco/interface/Track.h"
#include "DataFormats/TrackUtil/interface/TrackUtil.h"
#include "DataFormats/TrackUtil/interface/TrackUtilCollection.h"
#include "FWCore/MessageLogger/interface/MessageLogger.h"

to be able to access reco::Track objects, the TrackUtil objects and use the MessageLogger.

We want to use a parameter for the module-label of the tracks to be able to read in different track collections which has to be added as a private data member in the class definition:

class MyTrackUtility : public edm::EDProducer {
   public:
      explicit MyTrackUtility(const edm::ParameterSet&);
      ~MyTrackUtility();


      virtual void produce(edm::Event&, const edm::EventSetup&);
   private:
      // ----------member data ---------------------------
      std::string trackProducerName;
};

and in the constructor to fill it with the parameter from the parameter-set:

MyTrackUtility::MyTrackUtility(const edm::ParameterSet& iConfig)
{
   produces<TrackUtilCollection>();

   //now do what ever other initialization is needed
   trackProducerName = iConfig.getParameter<std::string>("TrackProducer");
}

The constuctor also holds a placeholder for the framework defining what the EDProducer produces.

Next we replace the example code in MyTrackUtility::produce with

void
MyTrackUtility::produce(edm::Event& iEvent, const edm::EventSetup& iSetup)
{
   // Get Inputs
   edm::Handle<reco::TrackCollection> tracks;
   iEvent.getByLabel(trackProducerName, tracks);

   // create output collection instance
   std::auto_ptr<TrackUtilCollection> output(new TrackUtilCollection());

   // fill collection
   output->push_back(TrackUtil(tracks->size()));

   iEvent.put(output);
}

which creates a new collection of TrackUtil's per event and fills exactly one entry per event.

Now, we compile the EDProducer using SCRAMV1:

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackUtility
scramv1 b

Finally, we write a parameter-set which instantiates our module and sets the TrackProducer parameter to the module label of one of the track collections:

process P =
{

  #
  # initialize  MessageLogger
  #
  include "FWCore/MessageLogger/data/MessageLogger.cfi"

  #
  # load input file
  #
  source = PoolSource
  {
    untracked vstring fileNames = {"file:tutorial.root"}
    untracked int32 maxEvents = -1
  }

  # include MyTrackUtility produces
  module producer = MyTrackUtility
  {
    string TrackProducer = "RSWMaterial"
  }

  #
  # write results out to file
  #
  module Out = PoolOutputModule
  {
    untracked string fileName = "tutorial-plus-utilities.root"
  }

  path p =
  {
    producer
  }

  endpath e =
  {
    Out
  }
}

We safe this parameter-set in

<CMSSW-Project-Directory>/src/MyCode/MyTrackUtility/test/test-mytrackutilityproducer.cfg

copy the H->ZZ->4mu CMSSW ROOT file from the above presented reconstruction to the same directory and execute it with

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackUtility/test
cmsRun test-mytrackutilityproducer.cfg

We can also combine the EDFilter and the EDProducer and write only TrackUtil's out to the event which pass the filter.

We write another parameter-set which instantiates our module and the EDFilter from above and sets the TrackProducer parameter to the module label of one of the track collections:

process P =
{

  #
  # initialize  MessageLogger
  #
  include "FWCore/MessageLogger/data/MessageLogger.cfi"

  #
  # load input file
  #
  source = PoolSource
  {
    untracked vstring fileNames = {"file:tutorial.root"}
    untracked int32 maxEvents = -1
  }

  # include MyTrackUtility produces
  module producer = MyTrackUtility
  {
    string TrackProducer = "RSWMaterial"
  }

  # include MyTrackFilter
  include "MyCode/MyTrackFilter/data/trackFilter.cfi"
  replace trackFilter.MinimalNumberOfTracks = 4
  replace trackFilter.MaximalNumberOfTracks = 4

  #
  # write results out to file
  #
  module Out = PoolOutputModule
  {
    untracked string fileName = "tutorial-plus-filtered-utilities.root"
  }

  path p =
  {
    trackFilter,producer
  }

  endpath e =
  {
    Out
  }
}

We safe this parameter-set in

<CMSSW-Project-Directory>/src/MyCode/MyTrackUtility/test/test-myfilteredtrackutilityproducer.cfg

copy the H->ZZ->4mu CMSSW ROOT file from the above presented reconstruction to the same directory and execute it with

cd <CMSSW-Project-Directory>/src/MyCode/MyTrackUtility/test
cmsRun test-myfilteredtrackutilityproducer.cfg

We can check the difference between the two created output ROOT files using the Bare ROOT mode.

All of the above created code is available in the tutorial input module in

<CMSSW-Project-Directory>/src/UserCode/Gutsche/Tutorial/MyCode/MyTrackUtility

where the extension .tutorial has been added to all files. The files are stored in the correct directory structure of the module. If the user wants to skip the step of writing the code himself, he just has to copy the MyTrackUtility directory to

<CMSSW-Project-Directory>/src/MyCode

remove the .tutorial extension and compile.

Summary and Outlook

Finishing the tutorial, I hope the user got an impression what it means to do reconstruction and analysis in CMSSW. Please start using CMSSW and its analysis capabilities for your physics studies and ask questions and give feedback in the CERN hypernews forums.

 
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