PAT Exercise 11: How to produce PAT trigger matches and use them in analysis

Objectives

The trigger is one of the key ingredients of an high energy physics detector. Without a trigger decision we could never cope with the overwhelming input rate of events being produced by the LHC. To reduce event rates from a MHz level to a level of a few 100 Hz without loosing those events we are really interested in requires an extremely high level of decision taking whether an event is interesting enough to be read out or not. This can only be achieved with a more coarse granularity than in the fully exploited offline reconstruction. In many cases just the trigger decision is of interest. There is cases though where you also would like to know that objects fired a given trigger. In this example we will learn how to match objects on trigger level to offline reconstructed objects. We will further on introduce the most prominent use case for physics analyses. This exercise will cover the following objectives:

  • Learn how to embed a trigger object that matches to a given offline reconstructed pat::Candidate.
  • Learn how to access a matched trigger object corresponding to a given offline reconstructed pat::Candidate.
  • Learn how the pat::Candidate and the matched trigger object are correlated.

ALERT! Note:
This web course is part of the PAT Tutorial, which takes regularly place at cern and in other places. When following the PAT Tutorial the answers of questions marked in RED should be filled into the exercise form that has been introduced at the beginning of the tutorial. Also the solutions to the [#Exercise][Exercises]] should be filled into the form. The exercises are marked in three colours, indicating whether this exercise is basic (obligatory), continuative (recommended) or optional (free). The colour coding is summarized in the table below:

Color Code ExplanationSorted ascending
red Basic exercise, which is obligatory for the PAT Tutorial.
yellow Continuative exercise, which is recommended for the PAT Tutorial to deepen what has been learned.
green Optional exercise, which shows interesting applications of what has been learned.

Basic exercises ( red ) are obliged and the solutions to the exercises should be filled into the exercise form during the PAT Tutorial.

Setting up of the environment

Preparation

You can reuse the environment created in Exercise 10.

How to get and compile the code

Check out and recompile the required packages with

ssh -X your_lxplus_name@lxplus6.cern.ch 
cd scratch0/
mkdir exercise11
cd exercise11
cmsrel CMSSW_7_4_1_patch4
cd CMSSW_7_4_1_patch4/src 
cmsenv
git cms-addpkg PhysicsTools/PatAlgos
git cms-merge-topic -u CMS-PAT-Tutorial:CMSSW_7_1_0_patTutorial
scram b -j 9

ALERT! For the following example you need to produce a PAT tuple with the name edmPatTrigger.root beforehand. We will generate this file using the producePatTrigger_cfg.py file in the test directory of the PatExamples package.

cmsRun PhysicsTools/PatExamples/test/producePatTrigger_cfg.py

Exercise

PAT tuple production

red Exercise 11 a):
Produce a PAT-tuple, which contains trigger matching information.

We should use the time while the PAT tuple is being produced to inspect the file a bit:

### ========
### Skeleton
### ========

## ---
## Start with pre-defined skeleton process
## ---
from PhysicsTools.PatAlgos.patTemplate_cfg import *

## switch to uncheduled mode
process.options.allowUnscheduled = cms.untracked.bool(True)
#process.Tracer = cms.Service("Tracer")

process.load("PhysicsTools.PatAlgos.producersLayer1.patCandidates_cff")
process.load("PhysicsTools.PatAlgos.selectionLayer1.selectedPatCandidates_cff")

## ---
## Modifications
## ---
# general
# input files. Let's use Z to mumu sample
process.source.fileNames = ["/store/relval/CMSSW_7_1_0/RelValZMM_13/GEN-SIM-RECO/POSTLS171_V15-v1/00000/6650F961-99FB-E311-BA90-0025905A48BC.root"]
process.maxEvents.input     = 1000  # reduce number of events for testing.
process.options.wantSummary = False # to suppress the long output at the end of the job
# specific
process.selectedPatMuons.cut = 'isGlobalMuon && pt > 20. && abs(eta) < 2.1 && globalTrack.normalizedChi2 < 10. && track.hitPattern.trackerLayersWithMeasurement > 5 && globalTrack.hitPattern.numberOfValidMuonHits > 0 && abs(dB) < 0.2 && innerTrack.hitPattern.numberOfValidPixelHits > 0 && numberOfMatchedStations > 1 && (trackIso+caloIso)/pt<0.2'

## no need to define the path in the unscheduled mode. comment out below lines
## ---
## Define the path
## ---
## 
## process.p = cms.Path(
##  process.patDefaultSequence
## )

ALERT! As you see we use the patDefaultSequence from the patTemplate_cfg file. For the selectedPatMuons we apply a "tight muon ID" selection additionally to the kinematic cuts:

  • The muon should be both a global muon.
  • The normalised χ2 of the global track fit should be smaller than 10.
  • The track should have been measured at least in 5 tracker layers.
  • The global track should have at least one hit in the muon system.
  • The impact parameter with respect to the beamsspot should be lower then 200 μm.
  • The inner track should have at leastone hit in the pixel tracker.
  • The relative isolation of the global muon should be (trackIso+caloIso)/pt<0.2.

This selection roughly compares to a typical selection of isolated standard muons here. The important point is the production of the trigger object matching as provided by the muonTriggerMatchHLTMuons module:

## ---
## PAT trigger matching
## --
process.muonTriggerMatchHLTMuons = cms.EDProducer(
  # matching in DeltaR, sorting by best DeltaR
  "PATTriggerMatcherDRLessByR"
  # matcher input collections
, src     = cms.InputTag( 'selectedPatMuons' )
, matched = cms.InputTag( 'patTrigger' )
  # selections of trigger objects
, matchedCuts = cms.string( 'type( "TriggerMuon" ) && path( "HLT_IsoMu24_eta2p1_v*" )' )
  # selection of matches
, maxDPtRel   = cms.double( 0.5 ) # no effect here
, maxDeltaR   = cms.double( 0.5 )
, maxDeltaEta = cms.double( 0.2 ) # no effect here
  # definition of matcher output
, resolveAmbiguities    = cms.bool( True )
, resolveByMatchQuality = cms.bool( True )
)

The offline reconstructed objects we want to match the trigger objects to are the selectedPatMuon candidates at this point in the configuration. The trigger objects are stored in the patTrigger object, that will be created beforehand in the patTriggerSequence. Note that the patTrigger objects keep not much more than the information of a reco::LeafCandidate and the object ID, that indicates whether it is a muon, electron or anything else at trigger level. You can find all possible trigger object type definitions here. In our example we are obviously interested in objects of type TriggerMuon and especially in those that are part of the HLT_IsoMu24_eta2p1 trigger path.

## --
## Switch to selected PAT objects in the main work flow
## --
from PhysicsTools.PatAlgos.tools.coreTools import removeCleaning
removeCleaning( process )
# to save a bit of disk space
process.out.outputCommands += [ 'drop *_*_*_*'
                               ,'keep *_patTrigger*_*_*'
                               ,'keep *_selectedPatMuons*_*_*'
                              ]

Now we switch on our trigger matching module muonTriggerMatchHLTMuons. This switch includes the complete trigger information automatically, if not done already.

## --
## Switch on PAT trigger
## --
from PhysicsTools.PatAlgos.tools.trigTools import *
switchOnTrigger( process ) # This is optional and can be omitted.
switchOnTriggerMatching( process, triggerMatchers = [ 'muonTriggerMatchHLTMuons' ] )
# Switch to selected PAT objects in the trigger matching

To learn more about the patTrigger workflow we inspect it a bit further with the python interpreter:

python -i PhysicsTools/PatExamples/test/producePatTrigger_cfg.py
>>> process.patDefaultSequence
cms.Sequence([...]+muonMatch*patMuons+[...]+selectedPatMuons+[...]+countPatMuons+[...]*patTrigger*muonTriggerMatchHLTMuons*patTriggerEvent)
>>> process.patDefaultSequenceTrigger
cms.Sequence(patTrigger*muonTriggerMatchHLTMuons)
>>> process.patDefaultSequenceTriggerEvent
cms.Sequence(patTriggerEvent)

The PAT trigger production is appended to the very end of the path. The first object being produced is the patTrigger, which re-keys the information from the various sources meaningfully. Next you can see the muonTriggerMatchHLTMuons module, which performs the actual matching between the online and offline reconstructed objects. Finally the result of this match is attached to the patTriggerEvent which will be the central entry point to all trigger information.

Question Question 11 a):
What are the differences between the MC matching and the trigger matching? And why is this necessary?
( Hint: you can see it already from the parameters.)

Question Question 11 b):
Which Python tool has to be used explicitly and which tool(s) are called automatically?

Analysis of the PAT trigger matching

To analyse the trigger match we make use of the PatTriggerAnalyzer module as defined in the plugins directory in the PatExamples package. To run the module on the PAT tuple that we created do the following:

Have a look into the configuration file ( PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py ). The first part should be pretty known to you. The patTuple.root file is opened and the TFileService is registered:

import FWCore.ParameterSet.Config as cms

process = cms.Process( "TEST" )

process.load( "FWCore.MessageService.MessageLogger_cfi" )
process.options = cms.untracked.PSet(
    wantSummary = cms.untracked.bool( False )
)

process.source = cms.Source( "PoolSource",
    fileNames = cms.untracked.vstring(
        'file:edmPatTrigger.root'
    )
)
process.maxEvents = cms.untracked.PSet(
    input = cms.untracked.int32( -1 )
)

process.TFileService = cms.Service( "TFileService",
    fileName = cms.string( 'analyzePatTrigger.root' )
)

The PATTriggerAnalyzer module is defined below:

process.triggerAnalysis = cms.EDAnalyzer( "PatTriggerAnalyzer",
    trigger      = cms.InputTag( "patTrigger" ),
    triggerEvent = cms.InputTag( "patTriggerEvent" ),
    muons        = cms.InputTag( "selectedPatMuons" ),
    nBins    = cms.uint32( 20 ),
    binWidth = cms.double( 4. ),
    minID = cms.uint32( 81 ),
    maxID = cms.uint32( 96 )
)

process.p = cms.Path(
    process.triggerAnalysis
)

You see that for the analysis we read all produced trigger objects, the selectedPatMuons and some further parameters:

  • nBins, binWidth: These steer the binning of the turn-on curve histogram as explained below.
  • minID, maxID: These correspond to the trigger object types as defined here (sorry, no enum supported). We will make use of these to fill the ptMean histogram as explained below.

You can compile and run the module like this:

scram b
cmsRun PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py

Once your job is finished you can inspect the analyzePatTrigger.root file:

root -l analyzePatTrigger.root

It contains the following -- currently still empty -- histograms in a directory triggerAnalysis:

  • etaTrigCand: showing the correlation in η between the offline reconstructed pat::Muon and the matched trigger muon.
  • phiTrigCand: showing the correlation in φ between the offline reconstructed pat::Muon and the matched trigger muon.
  • ptTrigCand: showing the correlation in pt between the offline reconstructed pat::Muon and the matched trigger muon.
  • turnOn: showing the pt turn-on curve of the offline reconstructed pat::Muon, where the x-axis is defined by the parameters nBins and binWidth in the configuration of the PatTriggerAnalyzer module.
  • ptMean: showing the mean pt for each of trigger object type for a range defined by the parameters minID and maxID in the configuration of the PatTriggerAnalyzer module.

We will go through the implementation of the module and the way the histograms should be filled in the following section.

The PATTriggerAnalyzer module

You can find the PATTriggerAnalyzer module in the plugins directory of the PatExamples package. The class is defined and implemented in the PatTriggerAnalyzer.cc file.

red Exercise 11 b):
Analyse PAT trigger matching information.

Basics

The first section of the analyze(...) function shows how to load the required input from the event:

// PAT trigger event
edm::Handle< TriggerEvent > triggerEvent;
iEvent.getByToken( triggerEventToken_, triggerEvent );

// PAT object collection
edm::Handle< MuonCollection > muons;
iEvent.getByToken( muonsToken_, muons );

You have now the pat::TriggerEvent and the pat::MuonCollection available.
TIP Possibly, it will turn out in the following, that you might need something more.(?)

Kinematic comparisons

We want to fill 2-dimensional histograms, comparing the pt, η and φ of the offline and the trigger muon.

The second code section of the analyze(...) function shows a skeleton loop over the muons.

/*
  kinematics comparison
*/

// loop over muon references (PAT muons have been used in the matcher in task 3)
for( size_t iMuon = 0; iMuon < muons->size(); ++iMuon ) {
}

This loop is meant to host the filling of the simple scatter plots, comparing the kinematic variable of the trigger to the offline objects. Since you have access to the offline muons directly, you just need to find the correspondingly matched trigger muons.

Question Question 11 c):
Which function gives back the matched trigger object, starting form the offline object?

After you have used this function (and, of course, assigned its output to a variable) you can start filling the three plots.
ALERT! In case the function returns something like a edm::Ref, you should check its availability and validity before accessing its content.

Find examples of the resulting plots below:

  • ptTrigCand.png:
    ptTrigCand.png

  • etaTrigCand.png:
    etaTrigCand.png

  • phiTrigCand.png:
    phiTrigCand.png

You will find a possible solution below:

( See the text below the code. )

// PAT trigger event
edm::Handle< TriggerEvent > triggerEvent;
iEvent.getByLabel( triggerEvent_, triggerEvent );

// PAT object collection
edm::Handle< MuonCollection > muons;
iEvent.getByLabel( muons_, muons );

// PAT trigger helper for trigger matching information
const helper::TriggerMatchHelper matchHelper;

/*
  kinematics comparison
*/

// loop over muon references (PAT muons have been used in the matcher in task 3)
for( size_t iMuon = 0; iMuon < muons->size(); ++iMuon ) {
  // we need all these ingredients to receive matched trigger objects from the matchHelper
  const TriggerObjectRef trigRef( matchHelper.triggerMatchObject( muons, iMuon, muonMatch_, iEvent, *triggerEvent ) );
  // finally we can fill the histograms
  if ( trigRef.isAvailable() && trigRef.isNonnull() ) { // check references (necessary!)
    histos2D_[ "ptTrigCand" ]->Fill( muons->at( iMuon ).pt(), trigRef->pt() );
    histos2D_[ "etaTrigCand" ]->Fill( muons->at( iMuon ).eta(), trigRef->eta() );
    histos2D_[ "phiTrigCand" ]->Fill( muons->at( iMuon ).phi(), trigRef->phi() );
  }
}

As you see, there are a few steps even with PAT that have to be done to arrive at the matched trigger objects. This is indeed the most technical part of this Tutorial. The reason is that there is just too many combinations of trigger objects, modules, paths and filters, which complicate a straight forward association. The solution within the EDM model is to keep all this information implicit in the edm::TriggerEvent. PAT facilitates the access to this implicit information by making it explicit. But as the edm::TriggerEvent before, the pat::TriggerEvent remains the main entry point to access the trigger objects. To access the trigger objects we need an association between the pat::TriggerEvent and the selectedPatMuons.

Here are some technical details:

  • You might have noticed that the following loop is indeed not over C++ iterators but just over indices. The reason is that we only need the reference to the basic reco::Candidate of the muon (candBaseRef), indicated here as a reco::CandidateBaseRef (a C++ typedef of an edm::Ref<reco::Candidate*>). The best way to receive this thing is indeed via the edm::Handle and the index of the candidate in the object collection. However, this is done internally in the method provided by the pat::helper::TriggerMatchHelper class.

  • Once we have the ingredients at hand we pass them to the matchHelper which is of type pat::helper::TriggerMatchHelper and has been instantiated before. The matchHelper needs the following inputs:
    • muons: the handle provided access to the selectedPatMuon candidates.
    • iMuon: the index indicating the particular object, we are interested in.
    • muonMatch_: the original label (e.g. as std::string) of the PAT trigger match producer for matches of trigger objects to selectedPatMuons.
      ALERT! This has to be set somewhere! Ideal would be to have it configurable.
    • iEvent: the edm::Event itself.
    • triggerEvent: the pat::TriggerEvent itself.

The reason for the helper class is that a data format like the pat::TriggerEvent by construction is not allowed to have any dependencies on the edm::Event and its member functions. However, the pat::TriggerEvent needs information of the edm::Event for technical reasons. The way to solve this problem was to have a class pat::helper::TriggerMatchHelper to take both the pat::TriggerEvent and the edm::Event as arguments. A small tribute to the architecture of CMSSW. The pat::TriggerObjectRef (trigRef) is indeed the reference to the matched trigger object itself! We got it...

ALERT! Not every selectedPatMuon does necessarily have a matched trigger object. This is in analogy to the Monte Carlo truth match discussed in Exercise 8. The reference can be a NULL reference. So before trying to access any information check its validity using the member function as indicated in the code snipped above.

Turn-on curve

We want to determine a "turn-on curve", which shows the efficiency of the trigger in pt-bins of the offline muon.

The third code section of the analyze(...) function shows a skeleton loop over the trigger objects, which are HLT muons. Remember, that this has been the trigger object type in the matcher:

/*
  turn-on curve
*/

// loop over muon references again
for( size_t iMuon = 0; iMuon < muons->size(); ++iMuon ) {
  // fill the counting histogram...
  histos1D_[ "countCand" ]->Fill( muons->at( iMuon ).pt() );
}

// get the trigger objects corresponding to the used matching (HLT muons)
const TriggerObjectRefVector trigRefs( triggerEvent->objects( trigger::TriggerMuon ) );
// loop over selected trigger objects
for ( TriggerObjectRefVector::const_iterator iTrig = trigRefs.begin(); iTrig != trigRefs.end(); ++iTrig ) {
}

This loop is meant to host the filling of the turn-on histogram with the pt of the offline muons. Since you have access to the trigger muons via references, you just need to find the correspondingly matched offline muon (only one!).

Question Question 11 d):
Which function gives back the matched offline object(s), starting form the trigger object?

After you have used this function (and, of course, assigned its output to a variable) you can start filling the plot.
ALERT! In case the function returns something like a edm::Ref, you should check its availability and validity before accessing its content.

Find examples of the resulting plots below:

  • countCand.png:
    countCand.png

  • turnOn.png:
    turnOn.png

You will find a possible solution below:

/*
  turn-on curve
*/

// loop over muon references again
for( size_t iMuon = 0; iMuon < muons->size(); ++iMuon ) {
  // fill the counting histogram...
  histos1D_[ "countCand" ]->Fill( muons->at( iMuon ).pt() );
}

// get the trigger objects corresponding to the used matching (HLT muons)
const TriggerObjectRefVector trigRefs( triggerEvent->objects( trigger::TriggerMuon ) );
// loop over selected trigger objects
for ( TriggerObjectRefVector::const_iterator iTrig = trigRefs.begin(); iTrig != trigRefs.end(); ++iTrig ) {
  // get all matched candidates for the trigger object
  const reco::CandidateBaseRefVector candRefs( matchHelper.triggerMatchCandidates( ( *iTrig ), muonMatch_, iEvent, *triggerEvent ) );
  if ( candRefs.empty() ) continue;
  // fill the histogram...
  // (only for the first match, since we resolved ambiguities in the matching configuration,
  // so that we have one at maximum per trigger object)
  reco::CandidateBaseRef muonRef( candRefs.at( 0 ) );
  if ( muonRef.isAvailable() && muonRef.isNonnull() ) {
    histos1D_[ "turnOn" ]->Fill( muonRef->pt() );
  }
}

In fact, this does not differ much from the access to the trigger object from the offline objects. You just need to keep in mind that the access function returns a vector of possible matches in this case, even though it might have the size 1 anyway.

TIP You can see then in the endJob() function, how the absolute counts per pt-bin are normalised with the total count of objects to obtain an actual efficiency

Mean pt calculation

We want to plot the mean pt of trigger objects, depending on their trigger object type.

This is just another example how to access the trigger objects. As you see we do not make use of any matching as we did in the examples above. Though good to know how to access the trigger objects from the pat::TriggerEvent, the general use case might be quite technical. In most cases of your analyses you might just be interested in those objects that match to a certain class of offline reconstructed objects as shown in the former sections.

The forth code section of the analyze(...) function shows a skeleton loop over the configured trigger object types

/*
  mean pt
*/

// loop over all trigger objects from minID to maxID; have
// a look to DataFormats/HLTReco/interface/TriggerTypeDefs.h to
// know more about the available trrigger object id's
for ( unsigned id=minID_; id<=maxID_; ++id ) {
}

Question Question 11 e):
Which function gives back all trigger objects associated to a certain trigger object type?

Find examples of the resulting plot below:

  • ptMean.png:
    ptMean.png

You will find a possible solution below:

/*
  mean pt
*/

// loop over all trigger match objects from minID to maxID; have
// a look to DataFormats/HLTReco/interface/TriggerTypeDefs.h to
// know more about the available trrigger object id's
for ( unsigned id=minID_; id<=maxID_; ++id ) {
  // vector of all objects for a given object id
  const TriggerObjectRefVector objRefs( triggerEvent->objects( id ) );
  // buffer the number of objects
  sumN_[ id ] += objRefs.size();
  // iterate the objects and buffer the pt of the objects
  for ( TriggerObjectRefVector::const_iterator iRef = objRefs.begin(); iRef != objRefs.end(); ++iRef ) {
    sumPt_[ id ] += ( *iRef )->pt();
  }
}

You see that this time we just loop over the integers given by the input parameters minID, maxID. The integers correspond to the trigger object types as defined here. The default values of minID, maxID correspond to all possible trigger object types for HLT, starting from the TriggerPhoton up to the somehow cryptic TriggerHLongit . The TriggerMuon corresponds to the "83". From the pat::TriggerEvent we receive a vector of all pat::TriggerObjectRef in the event. (ALERT! In the code snipped above this std::vector<patTriggerObjectRef> is represented by the C++ typedef pat::TriggerObjectRefVector.) We store the number of objects and sum their pt per trigger object type for further use in the endJob() function, where we determine the mean pt per object.


TIP You will find an additional hint about the solutions below:

You can get the solutions and compare to your ideas as follows:

mv PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc~
mv PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py~
git checkout PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py
diff -y PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc~
diff -y PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py~


PAT trigger "on-the-fly"

This exercise will even leave the context of PAT trigger information and aims for a more general idea:

green Exercise 11 c):
Run PAT and the subsequent analyser in one go, without storing the PAT tuple itself, but only the histogram file.

Question Question 11 f):
What do you have to change in the configuration(s) in order to produce the plots from Exercise 11 b) directly from the EDM input in a single CMSSW job without saving the PAT-tuple intermediately
( "PAT on-the-fly" )?

Build a configuration file, which unifies

  • PhysicsTools/PatExamples/test/producePatTrigger_cfg.py and
  • PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py
to run under the described conditions.

You will find the solution here:

You can get the solutions and compare to your ideas as follows:

cmsRun PhysicsTools/PatExamples/test/analyzePatTrigger_onTheFly_cfg.py

Some brief explanations on what has been done:

  • PhysicsTools/PatExamples/test/producePatTrigger_cfg.py has been used as starting point. The additional tasks are simply appended.
  • The cms.EndPath has been "emptied" from the output module (which produces the EDM output) by redefinition:
## --
## Remove EDM output by redefinition of the EndPath
##
process.outpath = cms.EndPath()
  • The TFileService for the histogram output and the actual analyser have been added just by copying from PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py:
### ========
### Analyser
### ========

process.TFileService = cms.Service( "TFileService",
    fileName = cms.string( 'analyzePatTrigger_onTheFly.root' )
)

process.triggerAnalysis = cms.EDAnalyzer( "PatTriggerAnalyzer",
    trigger      = cms.InputTag( "patTrigger" ),
    triggerEvent = cms.InputTag( "patTriggerEvent" ),
    muons        = cms.InputTag( "selectedPatMuons" ),
    muonMatch    = cms.string( 'muonTriggerMatchHLTMuons' ),
    nBins    = cms.uint32( 20 ),
    binWidth = cms.double( 4. ),
    minID = cms.uint32( 81 ),
    maxID = cms.uint32( 96 )
)
  • Finally, the analyser needs to be appended to the path:
## --
## Append the analyser to the existing path
##
process.p = cms.Path(process.triggerAnalysis)


... and that is it already!

ALERT! Note:
In case of problems don't hesitate to contact the SWGuidePAT#Support. Graduation CONGRATULATIONS! Graduation if you have successfully finished Exercise 11. You have finished the PAT Tutorial! You should have a good overview of the possibilities you have using PAT in your analysis. You might want to have a look to the WorkBookPATTutorial#MoreExercises to see what PAG and POG specific exercises, tricks and hints exist apart from this core part of the PAT Tutorial. Especially the WorkBookPATExampleTopQuarks page will provide you with a real physics use case which make use of nearly everything you learned during this Tutorial. Have fun!

ALERT! Note:
We hope that you liked this tutorial and all the cool features of PAT. You can imagine that a lot of work goes into this: service work for YOU! You might want to join in. We are always happy to welcome new people who want to join our team! Please contact the PAT support.

Review status

Reviewer/Editor and Date (copy from screen) Comments
RogerWolf - 13 March 2012 Added color coding.
VolkerAdler- 02 July 2012 Update for July 2012 tutorial
VolkerAdler- 05 December 2012 Update for Dec. 2012 tutorial
TaeJeongKim- 03 July 2014 update for July. 2014 tutorial

Responsible: RogerWolf

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng countCand.png r1 manage 26.2 K 2012-07-02 - 20:08 VolkerAdler  
PNGpng etaTrigCand.png r1 manage 28.9 K 2012-07-02 - 20:08 VolkerAdler  
PNGpng phiTrigCand.png r1 manage 26.0 K 2012-07-02 - 20:08 VolkerAdler  
PNGpng ptMean.png r1 manage 26.6 K 2012-07-02 - 20:08 VolkerAdler  
PNGpng ptTrigCand.png r1 manage 29.3 K 2012-07-02 - 20:08 VolkerAdler  
PNGpng turnOn.png r1 manage 25.3 K 2012-07-02 - 20:08 VolkerAdler  
Cascading Style Sheet filecss tutorial.css r1 manage 0.2 K 2010-06-16 - 17:13 RogerWolf  
Edit | Attach | Watch | Print version | History: r64 < r63 < r62 < r61 < r60 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r64 - 2015-06-28 - JunghwanGOH
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

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