Small adjustment to skip BTV info for open data

[nsmith-]

This patch allows to use the customize commands

--customise PhysicsTools/PFNano/pfnano_cff.PFnano_customizeMC_onlyPF
--customise PhysicsTools/PFNano/pfnano_cff.PFnano_customizeData_onlyPF

which skip trying to add BTV info, and hence skips jet updating. This allows us to run on 2015 OpenData MiniAOD files which have AK8CHS jets instead of AK8Puppi jets, messing up any attempts to access subjet collections.

I'm going to dump here (for lack of a better place at the moment) an example recipe for setting up an opendata area:

source /cvmfs/cms.cern.ch/cmsset_default.sh
cmsrel CMSSW_10_6_30
cd CMSSW_10_6_30/src/
cmsenv
git cms-init
git cms-merge-topic 39040
git clone -b opendata https://github.com/DAZSLE/PFNano.git PhysicsTools/PFNano
scram b

Here are some examples of setting up configurations for processing DoubleMuon or DY records:

xrdcp root://eospublic.cern.ch//eos/opendata/cms/Run2015D/DoubleMuon/MINIAOD/16Dec2015-v1/10000/00348932-30A8-E511-989A-00261894394A.root doublemuon_miniaod.root
cmsDriver.py --python_filename doublemuon_cfg.py --eventcontent NANOAOD --datatier NANOAOD \
  --fileout file:doublemuon_nanoaod.root --conditions 106X_dataRun2_v36 --step NANO \
  --filein file:doublemuon_miniaod.root --era Run2_25ns,run2_nanoAOD_106X2015 --no_exec --data -n -1 \
  --customise PhysicsTools/PFNano/pfnano_cff.PFnano_customizeData_onlyPF

xrdcp root://eospublic.cern.ch//eos/opendata/cms/mc/RunIIFall15MiniAODv2/DYJetsToLL_M-50_TuneCUETP8M1_13TeV-madgraphMLM-pythia8/MINIAODSIM/PU25nsData2015v1_76X_mcRun2_asymptotic_v12_ext1-v1/10000/06761E14-6ED8-E511-BBCD-0025905B85B2.root dy_miniaod.root
cmsDriver.py --python_filename dy_cfg.py --eventcontent NANOAODSIM --datatier NANOAODSIM \
  --fileout file:dy_nanoaod.root --conditions 102X_mcRun2_asymptotic_v8 --step NANO \
  --filein file:dy_miniaod.root --era Run2_25ns,run2_nanoAOD_106X2015 --no_exec --mc -n -1 \
  --customise PhysicsTools/PFNano/pfnano_cff.PFnano_customizeMC_onlyPF

Lastly, they can be run with

cmsRun doublemuon_cfg.py
cmsRun dy_cfg.py

Both run at about 10 events/s from local files, and produce output about 40% the size of the input. Skims could be implemented by using various EDFilters in front of the nano step, e.g. HLTFilter.

A few comments:

• In theory it would be better to build AK8Puppi jets using jetToolbox but as I understand, that still is not part of CMSSW? Is there an easy way to rebuild those from MiniAOD without using jetToolbox?
• I noticed the current example cmsDriver commands in this repo use --eventcontent NANOAODSIM --datatier NANOAODSIM for data, rather than --eventcontent NANOAOD --datatier NANOAOD. This seems to not matter but it does mess up the fakeNameForCrab modifier. I think a better solution here would be to remove all fakeNameForCrab modifiers from pfnano_cff.py and instead use a cmsDriver flag: --customize_commands 'process.NANOAODSIMoutput.fakeNameForCrab = cms.untracked.bool(True)'.
• The era run2_nanoAOD_106X2015 implemented in Introduced new era for 2015 opendata nanoaod processing  cms-sw/cmssw#39040 is not completely validated, see the PR for more detail.

[AnnikaStein]

Hi @nsmith-
Thanks for the PR! From BTV-side, the changes itself look good.
For what concerns the proper place to document the functionality, you could update the PR with a small entry in the README.md where you introduce the new customization options, and put the recipe mentioned in your PR description to help users reproduce with this setup.
On the specific comments:

• jetToolbox: I'd like to pass this question on to JME, maybe @nurfikri89 knows of a jetToolbox-independent way?
• NANOAOD(SIM): we agree, and should switch to NANOAOD for data, the proposed changes (using cmsDriver flag) are fine. We would actually like to port this also to the 12_4_8 branch, but this can come later in an independent PR.
• 2015 Open Data era: thanks for the pointer, I think these are very interesting developments and even if they are not completely validated as you write, I see no showstopper there for PFNano. From what I understand we can go ahead with git cms-merge-topic 39040 for now as proposed.

[nsmith-]

Thanks for your comments! I'll add a small section to the README then.