Difference: SWGuidePATTriggerMatchExercise (62 vs. 63)

Revision 632014-07-03 - TaeJeongKim

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

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

Line: 46 to 46
 scram b -j 9
Changed:
<
<
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.
>
>
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
Line: 136 to 136
 , resolveByMatchQuality = cms.bool( True ) )%ENDSYNTAX%
Changed:
<
<
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.
>
>
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.
  %TWISTY{mode="div" showlink="Show " hidelink="Hide " firststart="hide" showimgright="/twiki/pub/TWiki/TWikiDocGraphics/toggleopen-small.gif"
Line: 188 to 188
 

Analysis of the PAT trigger matching

Changed:
<
<
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:
>
>
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:
Line: 206 to 206
  process.source = cms.Source( "PoolSource", fileNames = cms.untracked.vstring(
Changed:
<
<
'file:patTuple.root'
>
>
'file:edmPatTrigger.root'
  ) ) process.maxEvents = cms.untracked.PSet(
Line: 236 to 236
  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.
Changed:
<
<
  • 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.
>
>
  • 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:
Line: 273 to 273
  The first section of the analyze(...) function shows how to load the required input from the event:
Changed:
<
<
%SYNTAX{ syntax="cpp"}%// PAT trigger event
>
>
%SYNTAX{ syntax="cpp"}% // PAT trigger event
 edm::Handle< TriggerEvent > triggerEvent;
Changed:
<
<
iEvent.getByLabel( triggerEvent_, triggerEvent );
>
>
iEvent.getByToken( triggerEventToken_, triggerEvent );
  // PAT object collection edm::Handle< MuonCollection > muons;
Changed:
<
<
iEvent.getByLabel( muons_, muons ); }%ENDSYNTAX%
>
>
iEvent.getByToken( muonsToken_, muons ); %ENDSYNTAX%
  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.(?)
Line: 513 to 514
  } }%ENDSYNTAX%

Changed:
<
<
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.
>
>
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.
  </>
<!--/twistyPlugin-->
Line: 527 to 528
 
mv PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc~
mv PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py PhysicsTools/PatExamples/test/analyzePatTrigger_cfg.py~

Changed:
<
<
cvs up -r tutorialJuly2013_solution11 PhysicsTools/PatExamples/plugins/PatTriggerAnalyzer.cc 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~
Line: 559 to 560
  You can get the solutions and compare to your ideas as follows:

Changed:
<
<
cvs co -r tutorialJuly2013_solution11 PhysicsTools/PatExamples/test/analyzePatTrigger_onTheFly_cfg.py
>
>
cmsRun PhysicsTools/PatExamples/test/analyzePatTrigger_onTheFly_cfg.py
 

Some brief explanations on what has been done:

Line: 592 to 593
 %SYNTAX{ syntax="python"}%## -- ## Append the analyser to the existing path ##
Changed:
<
<
process.p *= process.triggerAnalysis%ENDSYNTAX%
>
>
process.p = cms.Path(process.triggerAnalysis) %ENDSYNTAX%
  </>
<!--/twistyPlugin-->
Line: 617 to 619
 
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
Added:
>
>
TaeJeongKim- 03 July 2014 update for July. 2014 tutorial
 

Responsible: RogerWolf

 
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