HTopMultilepAnalysis

WARNING!

We have moved to GitHub! All the package and its Wiki lives here. Please refer to that.

PLEASE IGNORE THE FOLLOWING INSTRUCTIONS, AND CHECK OUT THE WIKI ON GITHUB. This page will be phased out soon...

Introduction

A RootCore package to be used alongside xAODAnaHelpers to perform a RunII ttH to multileptons analysis. It works by setting up ASG Base release.

Current package tags

Make sure you download the green-lighted tags of both packages.

For HTopMultilepAnalysis:

For xAODAnaHelpers:

Checkout, setup and compile

NEW : The HTopMultilepAnalysis package has been now migrated to the common HSG8 svn repository: HTopMultileptons.

* Check out HTopMultilepAnalysis : 

svn co svn+ssh://svn.cern.ch/reps/atlasphys-hsg8/Physics/Higgs/HSG8/AnalysisCode/multileptons/xAOD/HTopMultilepAnalysis/tags/HTopMultilepAnalysis-XX-YY-ZZ  HTopMultilepAnalysis

  • Checkout xAODAnaHelpers: 

svn co svn+ssh://svn.cern.ch/reps/atlasinst/Institutes/UChicago/xAODAnaHelpers/tags/xAODAnaHelpers-XX-YY-ZZ xAODAnaHelpers

  • Then, setup the ASG release: 
rcSetup Base,2.X.Y

(remember to do this every time you log in. If you don't plan to change the release, just source the rcSetup.sh script that will be automatically created after the first time you set up ASG)

  • After this, you need to manually checkout some ASG packages and apply some svn patches. Execute the folllowing handy python script (remembering to give as command argument also the number identifier of this ASG release), and you'll automatically have all the recommended package tags for the release you are using: 

python xAODAnaHelpers/scripts/checkoutASGtags.py 2.X.Y


rc find_packages

rc compile

Run the analysis

It's now time to run! Let's create a soft link to the scripts/ directory first: 

ln -s HTopMultilepAnalysis /scripts .

Have a look at the content of the scripts/ folder: 

submit-grid-HTopMultilep.sh
submit-grid-singleDS-HTopMultilep.sh
submit-local-HTopMultilep.sh
submit-lxbatch-HTopMultilep.sh

These bash scripts contain just the shell command sequence that is used to run the job steering macro on the various drivers (local, grid ...). As an example, let's see how to submit a local job for the main HTopMultilepAnalyis, running on a single dataset: 

test-HTopMultilep --inDSType INDSTYPE --inDir /PATH/TO/DIR/CONTAINING/DATASET/ --inDSName DATASETFOLDER --outDir OUTDIR --maxEvents N

  • INDSTYPE is a string that is used to identify the sample processed. It's needed to distinguish full xAODs from DxAODs, and should have a structure like (e.g.) DxAOD-2015-13TeV
  • /PATH/TO/DIR/CONTAINING/DATASET/ is the path to the directory containing the datasets sub-directories
  • DATASETFOLDER is the name of the folder relative to the dataset under question
  • OUTDIR is the name of the output directory which wil be created where the job has been executed. It will contain the output histograms, trees etc. The name of this folder is up to the user.
  • N: specify if you want to run on a subset of events ( N = -1 : run on all events )

Other options are available. They can be shown just by doing: 

test-HTopMultilep --help

Grid submission

A few important things to do if you wish to run the analysis on the grid.

As a first thing when you log in on your machine, you will need to set up dq2 and PanDA: 

localSetupDQ2Client

voms-proxy-init -voms atlas

localSetupPandaClient currentJedi --noAthenaCheck

Only after doing this, setup the ASG release and compile (see instructions above).

A typical submission command would be something like: 

test-{ANALYSISALGO} --outDir OUTDIR --grid 1 -gridUser GRIDUSERNAME --inGridDSList HTopMultilepAnalysis /doc/{YOURSAMPLELIST}.txt --inDSType INDSTYPE --outDSID GRIDOUTDSIDENTIFIER

Have a look into the doc/ folder to see how a sample list file looks like. The GRIDOUTDSIDENTIFIER is a name of your choice that will uniquely identify the output datasets of your grid job.

When you issue the above command, you will be prompted to confirm the output DS identifier. If you say "yes", then the submission will start (usually takes a bit of time, depending on how many samples you are processing).

Inside the steering macro, it's possible to configure the grid job using EventLoop metadata system (see here for a list of options), as much as you would do with prun.

Description of the algorithms

Let's have a look at what the main parts of the code do.

Available algorithms

These do the heavy duty work. Here are the algorithms implemented so far:

Algorithm Description
HTopMultilepEventSelector.cxx An algorithm that applies an event selection.

At the moment, the user can apply a cut based on ( minimum number of leptons (muons + electrons) OR minimum number of leptons and taus ) and on the minimum number of bjets.

NB: At this stage, the muons and electrons are combined into a "Leptons_Sel" xAOD custom container, which is then used by all the algorithms downstream.
TruthMatchAlgo.cxx

An algorithm that applies truth matching to the reconstructed objects, and decorates them with info about the truth type and origin, as well as info for charge flipped leptons.

TruthMatchAlgo::applyTruthMatchingDC14( )

Default algorithm for truth matching on DC14 samples.

TruthMatchAlgo::applyTruthMatchingMuonMC15()

TruthMatchAlgo::applyTruthMatchingElectronMC15()

These will be the default algorithms for MC 15. They take advantage of the already stored info on the xAOD::Electron objects ( i.e., truthType and truthOrigin of the truth particle that has been found matching this electron at reconstruction level ). For the Muon objects, still need to pass through the "MuonTruthParticles" truth xAOD container and do a track-matching.
HTopMultilepAnalysis.cxx The main ttH analysis algorithm.

It retrieves manipulated objects from the xAH algos upstream, and applies analysis-specific event selection and categorisation.

HTopMultilepAnalysis::addChannelDecorations()

A method used to decorate event and lepton objects with specific attributes used afterwards for category definitions.

These custom attributes are also crucial for the subsequent calculation of the MM weights.

HTopMultilepAnalysis::fakeWeightCalculator()

A method that calculates the Matrix Method weights for the fake lepton background estimation. Real/fake rates are manually plugged in at the moment.

For the future: read the "baseline" rates from an external ROOT file.

HTopMultilepAnalysis::applyTagAndProbeRFRateMeasurement()

A method that performs a selection for real and fake-enriched CRs (low jet multiplicity, OS and SS respectively), and then defines "Tag&Probe" leptons. The probe in each CR (OS, SS) is used to derive the rates offline, by taking the ratio ( N. probe Tight / N. probe Tight ) binned in pT and eta
HTopMultlepTree.cxx This is where the user defines the custom TTree branches to be dumped in the ntuple. They get filled by either accessing primitive attributes of the objects ( pt, d0sig,...) or by accessing decorations of the objects themselves (e.g., isTight, ... )
HTopMultilepTreeAlgo.cxx An EL::algo managing the TTree writing.

This is the one which gets instantiated and configured by the user.

Via configuration, the user can decide whether to dump or not some basic sets of branches for the event/object collections defined in xAH HelpTreeBase algo (e.g., basic kinematic variables for electrons, electron track parameters, etc. ).

The custom branches defined in HTopMultilepTree will be fully dumped instead.

Output TTree branches

Configuration file to set the level of output in the final ntuple is (e.g.): 

HTopMultilepAnalysis/data/Tree/tree_HTopMultilep_DxAOD-DC14-8TeV.config

specifically at the lines: 

EventDetailStr  "pileup"

MuonDetailStr  "kinematic trackparams trackhitcont"

...

The available strings to decide the sets of output branches for each "object" are defined in: 

xAODAnaHelpers/trunk/Root/HelperClasses.cxx

in the : 

{MY-OBJECT}InfoSwitch::initialize()

methods. Beware that these will affect only the "basic" branches defined in the tree base class: 

xAODAnaHelpers/trunk/Root/HelpTreeBase.cxx

(these are branches that will most likely be used by any analysis). At this stage, I haven't implemented such a thing for the branches defined in the HTopMultilepTree.h derived class, but can be easily done if needed.

The job steering macro

A fairly simple C++ macro that is used to:

  • instantiate and configure all the xAH, HTopML algorithms
  • set the order of call of the algorithms
  • send the job to the selected EL::Driver (local, grid, batch ... so far I tested only local and grid! )

At the moment, we have two steering macros, one for each analysis: 

HTopMultilepAnalysis/util/test-HTopMultilep.cxxHTopMultilepAnalysis/util/test-HTopMultilepAnalysis.cxx

( the other *.cxx in the util/ folder are just simple test macros used for debugging. Still, they are a perfect testing ground if you just want to play around with the xAOD EDM smile )

They should be fairly easy to read through. However, please feel free to ask for clarifications.

Configuring the algorithms

The configuration files are located into the HTopMultilepAnalysis/data/ directory. For each algorithm category, the .config files have been put into separate subdirectories: 

Event/Muons/Electrons/Jets/Tracks/OverlapRemoval/Analysis/Tree/

The name of the config files themselves, and the lines where flags/thresholds/WPs are set should be pretty straightforward to understand.

A few words on the: 

InputContainer     MyContainer_INOutputContainer    MyContainer_OUT

lines.

The MyContainer_IN must be the name of the xAOD container that is going to be processed by this algo. In this regard, the place of the algorithm in question in the ordered list defined in the steering macro is crucial. That is, if this algo is the first in the list to handle, say, muons, then the input conatiner will be the original xAOD container name (i.e., the one you see when you open the xAOD with the TBrowser or with the checkxAOD.py script). Whereas, if this algo processes muons after another algo, then the input conatiner will be the output container of the upstream algo!

Setting this I/O flags in the wrong way will result in an unpleasant crash at runtime.

Take some time to look at how the I/O are set with the current configuration I have.

The 

InputAlgoOutputAlgo

lines concern systematics management. Will explain about these soon...

Useful links

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r22 - 2015-07-10 - MarcoMilesi
 
    • 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