Skip to content

Installation

Brenda Fabela edited this page May 26, 2020 · 13 revisions

Installation of the NanoAOD Analyzer framework

In this page you will find the instructions to install the framework for the first time in your CMSSW working area.

Setting up your CMSSW working area

For the instructions below, we assume you already have an LPC account. From your terminal:

  • Log into the Fermilab LPC cluster SL7 machine and go to your nobackup area:
ssh -XYt <username>@cmslpc-sl7.fnal.gov
cd ~/nobackup

The architecture that we use now must be compatible with sl7, not sl6.

  • Get a new CMS environment:
export SCRAM_ARCH=slc7_amd64_gcc700            # Makes sure you have the proper CMS environment variables (*)
source /cvmfs/cms.cern.ch/cmsset_default.sh    # This sets-up an appropriate CMS environment with which to run the steps to follow.
cmsrel CMSSW_10_2_18
cd CMSSW_10_2_18/src
cmsenv                                         # This executes proper CMS environment variables once more.

(*) This is the equivalent of executing cmsenv in the src/ directory of your CMSSW release. If this doesn’t work, it might be because you are using a different shell. Check your shell, and in that case, you might source the file cmsset_default.csh.

Setting up your GitHub account

If you do not have a GitHub account:

  • Go to github.com and create a new account: acquire a username and password to go with said account.
  • Go to the "How do I suscribe..." page of the following URL: http://cms-sw.github.io/cmssw/faq.html
  • Click on "Register in GitHub your ssh key".
  • Check for existing ssh keys in your LPC area: ls ~/.ssh
  • In case you don't have ssh keys, generate a new one: ssh-keygen -t rsa -C <email>
  • Hit enter when prompted to select file save location.
  • Enter and establish a passphrase. Write down and keep this information in a secure place.
  • Add the new ssh key to GitHub:
    • Navigate to Account Settings.
    • Click “SSH Keys” on left sidepanel.
    • Click “Add SSH Key.”
    • Copy the contents of id_rsa.pub to the “Key” field. Make sure you do not include line return characters in the copy-paste. Get rid of those, for otherwise, GitHub will not recognize your key as valid.
    • Add key.

When you get your GitHub account or if you already have one:

  • Configure your GitHub username at LPC:
git config --global user.github <username>
git config --global user.name '<your name> <your last name>'
git config --global user.email '<your e-mail>'
  • Set up the CMSSW Git repository. This will be helpful if you need to checkout CMSSW packages later:
git cms-init

Now, you are ready to install the NanoAOD Analyzer framework:

  • Clone the NanoAOD_Analyzer GitHub repository in your CMSSW_10_2_18/src area:
git clone https://github.com/VandyHEP/NanoAOD_Analyzer.git
  • Go to the new directory for the Analyzer and compile it with make:
cd NanoAOD_Analyzer/
make -j8

This builds the objects that are in the src/ directory of the Analyzer. The j8 option specifies that you build with 8 cores. Let’s say that you make a change later on to src/Analyzer.cc. Before running the Analyzer, you must build it again to see (1) if errors in your new code arise and (2) how the new code is reflected in the output. So, you’d execute make again.


Running the NanoAOD Analyzer

Description

There are three main components of the Analyzer

  • src/: This is the source code of the Analyzer, where particle definitions, functions that apply the desired selections, fill the histograms and write the final output root files are written.
  • PartDet/: In this folder reside all the configuration files where the analyzed objects are defined, event selections and output distributions are set up.
  • Pileup/: Pileup distributions for data and MC are stored, as well as the golden JSON files for each data-taking campaign and files related to different corrections like b-tagging scale factors.

Running interactively

To test that your Analyzer is working properly before submitting any jobs to the grid, check that the cuts you set up in the configuration files are being applied correctly, etc., you can run the Analyzer interactively with:

./Analyzer -in <inputfilename>.root -out <outputfilename>.root -C <path_to_PartDet> -y <year>

By default, the option -C is ./PartDet, -y is 2016, so you don't always need to specify them when running quick tests. If you do not want to run over the full input sample, add the option -t:

./Analyzer -in <inputfilename>.root -out <outputfilename>.root -C <path_to_PartDet> -y <year> -t

For example,

./Analyzer -in root://cmsxrootd.fnal.gov///store/mc/RunIISummer16NanoAODv6/TT_TuneCUETP8M2T4_13TeV-powheg-pythia8/NANOAODSIM/PUMoriond17_Nano25Oct2019_102X_mcRun2_asymptotic_v7-v2/20000/35CE4B6A-2C53-D544-B50B-53A54910AB7D.root -out test.root -t

Here, since my input file corresponds to the 2016 MC campaign, I did not specify the year and I'm using whatever configuration files are stored at PartDet. If I were to run over a 2017 MC sample with a set of configuration files in a folder called MyPartDet, then the syntax will be:

./Analyzer -in root://cmsxrootd.fnal.gov///store/mc/RunIIFall17NanoAODv6/TTToSemiLeptonic_TuneCP5_PSweights_13TeV-powheg-pythia8/NANOAODSIM/PU2017_12Apr2018_Nano25Oct2019_102X_mc2017_realistic_v7-v1/110000/0BD5AC15-90E4-AC47-BFBE-023E726B75CE.root -out test.root -y 2017 -C MyPartDet -t

Examples

We compiled a simple example to help you get acquainted with the framework: a Z->mumu control region that we also refer to as a standard candle. Check the Examples page to do this exercise.

Running the NanoAOD Analyzer on the LPC cluster

Before starting submitting jobs to the LPC cluster, we recommend to get yourself familiar with the Analyzer framework by doing one of the following examples and run them interactively. When you feel confident and ready to start working in your analysis, please refer to the instructions found at the NanoAOD Submission wiki page.

Additional notes

Data filtering

Into this framework, there is a filter for the data. This is because good run and luminosity sections are not selected already in the nanoAOD datasets. In the latest version of the Analyzer, the year corresponding to the data/MC being analyzed is an input argument that will automatically take care of reading the right golden JSON file (which keeps track of the good parts of the data). In the Analyzer, this is done by the new Analyzer::checkGoodRunsAndLumis function called in Analyzer::preprocess. Please read the notes to follow:

  • In Analyzer/Pileup, there is a file called json2016.txt. This file has the good run and luminosity section bounds for 2016 data.
    • This file is in a format that is usable for the filter. That is, it is a series of numbers separated by commas.
    • The first number in the line is the run number.
    • The subsequent numbers in each line define the luminosity bounds that are good. That is, consider the following:
      • Example: 112500,17,20,41,57: Run 112500 has good luminosity sections from 17 to 20, inclusive, and 41 to 57, inclusive.

Pileup weights

  • The current good Pileup files for the various runs have been added to Analyzer/Pileup. Thanks to Brandon for gathering these:
Year Data (nom) MC Data (syst. down) Data (syst. up)
2016 PileUpReweighting2016.root mc2016_pileup_Dec2018reReco.root PileUpReweighting2016Do.root PileUpReweighting2016Up.root
2017 PileUpReweighting2017.root mc2017_pileup_Dec2018reReco.root PileUpReweighting2017Do.root PileUpReweighting2017Up.root
2018 PileUpReweighting2018.root mc2018_pileup_Dec2018reReco.root PileUpReweighting2018Do.root PileUpReweighting2018Up.root

(*) About 2017 MC pileup weights: Due to a bug in MC production, some MC samples have pileup distributions that are different to that in mc2017_pileup_Dec2018reReco.root. A new functionality has been added to the Analyzer to deal with this and it is discussed here.