The Ntuple Producer code

This is a CMSSW code for creating small ROOT ntuples from CMS data/MC samples. Check out this twiki for more details: CMS/UserCodeNWUntupleProducer

Instructions for Users

Set up the environment
```
setenv SCRAM_ARCH slc5_amd64_gcc462
setenv CVSROOT :ext:<cern-user-account>@lxplus.cern.ch:/afs/cern.ch/user/c/cvscmssw/public/CMSSW
cmsrel CMSSW_5_3_13_patch3
cd CMSSW_5_3_13_patch3/src
cmsenv
```
Replace the <cern-user-account> with your CERN account. Since the new recipe for CVS connection is done through ssh to lxplus you will have to type your CERN password every time when checkout from CVS. It is inconveniet, but we have to live with it for now.

Met recipes, according to workbook and met-recipe:

git cms-addpkg PhysicsTools/PatAlgos
git cms-merge-topic 1472
git cms-merge-topic -u TaiSakuma:53X-met-131120-01
scram b -j 9

Met filters according to MissingETOptionalFilters:

cvs co -r V00-00-13-01 RecoMET/METFilters
cvs co -r V00-03-23 CommonTools/RecoAlgos
cvs co -r V01-00-11-01 DPGAnalysis/Skims
cvs co -r V00-11-17 DPGAnalysis/SiStripTools
cvs co -r V00-00-08 DataFormats/TrackerCommon
cvs co -r V01-09-05 RecoLocalTracker/SubCollectionProducers
scram b -j 9

Ecal tools so we can get more photon variables for photon MVA:
```
git cms-addpkg RecoEcal/EgammaCoreTools
```
Tools for recommended Electron Iso EgammaPFBasedIsolation
```
git-cms-addpkg CommonTools/ParticleFlow
```

Egamma tools from MVA Electron ID:

cvs co -r V00-00-09 EgammaAnalysis/ElectronTools
cvs co -r V09-00-01 RecoEgamma/EgammaTools
cd EgammaAnalysis/ElectronTools/data
cat download.url | xargs wget
cd ../../../
scram b -j 9

MVA MET Code (Just for PU Jet ID) Jet PU ID:

cvs co -r METPU_5_3_X_v4 RecoJets/JetProducers
cvs up -r HEAD RecoJets/JetProducers/data/
cvs up -r HEAD RecoJets/JetProducers/python/PileupJetIDCutParams_cfi.py
cvs up -r HEAD RecoJets/JetProducers/python/PileupJetIDParams_cfi.py
cvs up -r HEAD RecoJets/JetProducers/python/PileupJetID_cfi.py
cvs co -r V05-00-16 DataFormats/JetReco
scram b -j 9

Extra code (for boosted Z->ee isolation), (-d option not working since new CVS directory) following boostedZ and heep twikies:

mkdir TSWilliams
mkdir SHarper
cvs co -r V00-02-03 UserCode/TSWilliams/BstdZee/BstdZeeTools
cvs co -r V00-09-03 UserCode/SHarper/HEEPAnalyzer
mv UserCode/TSWilliams/BstdZee/BstdZeeTools TSWilliams/.
mv UserCode/SHarper/HEEPAnalyzer SHarper/.
rm -r UserCode

PF footprint removal Supercluster footprint removal twiki:

git clone https://github.com/peruzzim/SCFootprintRemoval.git PFIsolation/SuperClusterFootprintRemoval
cd  PFIsolation/SuperClusterFootprintRemoval
git checkout V01-06
cd ../..
scram b -j 9

Now check out the ntuple producer code and then the specific tag/branch of the code that is known to work

git clone https://github.com/NWUHEP/ntupleProducer NWU/ntupleProducer
cd NWU/ntupleProducer
git checkout v9.9
cd ../..
scram b -j 9

Once compiled, we are ready to run it

Runnning the code

  cd NWU/ntupleProducer/test
  cmsRun ntupleProducer_cfg.py

it assumes you are running over an MC sample. If you want to run on data, do:

  cmsRun ntupleProducer_cfg.py isRealData=1

that will set up an appropriate global tag etc.

NB By defualt, the ntuples require that there be at least one muon(electron) with pT > 3(5) GeV in order for an event to be saved. In the case that this is not desired (for instance, in jet or photon based studies), you should switch off the skimLeptons option in ntupleProducer_cfg.py

In addition to this, there are various flags the configuration file, ntupleProducer_cfg.py, that allow to save/not save certain objects (muons, jets, etc). All are saved by default.

Running with CRAB

For running over individual datasets, it's best to use standard crab. The configuration files for MC and data are crabNtuples_MC.cfg and crabNtuples_Data.cfg. Submission goes as follows,

crab -create -cfg crabNtuples_<type>.cfg
crab -submit -c <ui_working_dir>

To check the status of your jobs,

crab -status -c <ui_working_dir>

and to get the log files,

crab -get -c <ui_working_dir>

More information can be found in the CMS SW guide chapter on CRAB.

For submission of ntuple production of multiple datasets at once, the multicrab framework can be used. It is described very briefly here. The important feature is that you can use most (?) of the standard crab commands for submission and checking on jobs status by replacing the crab command with multicrab. For instance when jobs are submitted in multicrab you can do the following,

multicrab -create -cfg <cfg_file> -submit

and to check their status

multicrab -status -c <ui_working_dir>

which also works for crab. You can also check the status of individual datasets using standard crab commands. The main difference is in the format of the configuration files. For multicrab, there is a crab.cfg file with a set of global configuration parameters and a multicrab.cfg file where each dataset is given its own specific configuration. As for the case of normal crab, two configuration files have been prepared for data and MC, multicrab_data.cfg and multicrab_mc.cfg.

Checking Output

After CRAB claims that your jobs are finished with exit codes 0 0, you will want to double check because it lies and large jobs tend to have a few extra or missing files.

Run the following command:

  ./find_goodfiles.py -c Path/To/CrabDir -q

This will check that all the jobs listed in the crab xml files are actually in your output area, and that your output area contains no extra or duplicate files. If it does, the script will tell you what needs to be rerun or what needs to be deleted.

Instructions for Developers

First, make sure you are on master branch and have the latest code:
```
git checkout master
git pull
```

Then create a new branch and swich to it:

git branch dev-username
git checkout dev-username

Now you can make any changes you want. Once you are done, commit it and push your branch.
```
git commit -a
git push origin dev-username
```
When you are satisfied with you new code, merge it with master branch. For that:
```
git checkout master
git merge dev-username
git push
```

If the changes do not conflict, you are done. If there are conflicts, markers will be left in the problematic files showing the conflict; git diff will show this. Once you have edited the files to resolve the conflicts, git commit -a.

Tagging policy

At any time you can tag your code, and push your tags to remote:

  git tag -a test1 -m "my tag"
  git push origin --tags

You can use any tags you want, later those can be deleted.

For the global production though, we should stick with a tagging convention. Tags should be vX.Y and I am starting them with v6.1. Such that the tag corresponds to the nutuple_v6 name of ntuple production. If the new code significantly changes the format of the ntuples (substantial changes to class definitions etc.) then the first number of a tag should be incremented (to v7.1 etc.) and the ntuple production path-name should be changed correspondingly. Otherwise, incremental changes should be reflected in changes to the second digit.

NWUHEP / ntupleProducer