Adding FSR photon collection to 2017 analysis

[eyigitba]

Adding FST photon collection to 2017 analysis based on the information in:

• https://github.com/UFLX2MuMu/Ntupliser/pull/77/commits/908bc3b0ef8eb19406395cde666438f8e7b58ca0

• https://gitlab.cern.ch/uhh-cmssw/fsr-photon-recovery

[eyigitba]

Added FSR photon collections to 2017 analysis. You can see the changes here: https://github.com/UFLX2MuMu/Ntupliser/commit/346ae62f48aa32329ed080e7ff9691ea1af025ec

The main question now is that what kind of isolation cuts we should use and whether to apply these cuts on the ntupliser step or the analysis step.

I can see that Oliver is suggesting (https://gitlab.cern.ch/uhh-cmssw/fsr-photon-recovery): double fsrDrEt2Cut = 0.019; double fsrIsoCut = 0.8;

whereas A.Rizzi is using (https://github.com/arizzi/cmssw/blob/nanoAOD-FSR-11_0_0_pre9_withNanoCode/MuonAnalysis/MuonAssociators/plugins/MuonFSRProducer.cc#L54): desc.add("deltaROverEt2Max", 0.05)->setComment("max ratio of deltsR(mu,photon) over et2 of the photon"); desc.add("isolation", 2.0)->setComment("relative isolation cut");

Which one is correct here? Also if these are subject to change maybe it's more practical to cut on these values after ntuplising.

[bortigno]

I would use looser precuts - I think the same as Andrea is using could be ok : they look to be about a factor of 3 loser than Oliver suggestions, so maybe a good compromise between saving some space in the tuples and cleaning up junk, and keeping enough information to maybe tune it more in the future.

[bortigno]

346ae62 looks good to me Before PR I would move all the requirement (there are many hardcoded cuts) to an external python config so it's easier to keep track of them and change them in the future.

[eyigitba]

OK both those suggestions sound good to me. I'll update the code accordingly and submit the PR later.

[eyigitba]

I moved hardcoded cuts to python configs and changed the values of the cuts so they match Andrea's values now. There is also some renaming of variables/methods. See the commit https://github.com/UFLX2MuMu/Ntupliser/commit/b360b0a21c4e511933f5063817b73c65959fbb4d

If we're happy with these changes we can implement the same changes to 2016 and 2018 branches as well.

[eyigitba]

I moved the _phot_etaGap_min/max cuts back in the code. Removed all modifications to duplicate config files. Only configs that are up-to-date are the main configs Analyzer_MC_cff.py and Analyzer_cff.py. The commit is here https://github.com/UFLX2MuMu/Ntupliser/commit/dd0e8786de07bd90c4b1e07b9b33a9968b1ab305.

Also issuing a PR.

[bortigno]

Porting it to 2018.

Here the workflow:

git checkout master_2018_102X
git checkout -b port-issue-86-2018-fsr
git cherry-pick 346ae62f48aa32329ed080e7ff9691ea1af025ec
git add interface/PhotHelper.h interface/PhotInfo.h src/PhotHelper.cc
git cherry-pick --continue
git cherry-pick b360b0a21c4e511933f5063817b73c65959fbb4d
# fixing some trivial conflicts on plugins/UFDiMuonsAnalyzer.cc
git add plugins/UFDiMuonsAnalyzer.cc
# here removing the old cfg
git rm python/Analyzer_2017_94X_MC_cff.py python/Analyzer_2017_94X_cff.py
git cherry-pick --continue
git cherry-pick 60fcd5df2e38a65246466524c1af7adfe1f09024
# removing the other old cfg
git rm python/Analyzer_2016_94X_MC_cff.py python/Analyzer_2016_94X_cff.py
git cherry-pick --continue
git cherry-pick dd0e8786de07bd90c4b1e07b9b33a9968b1ab305
# keep removing these files...
git rm python/Analyzer_2016_94X_MC_cff.py python/Analyzer_2016_94X_cff.py python/Analyzer_2017_94X_MC_cff.py  python/Analyzer_2017_94X_cff.py
git cherry-pick --continue
git cherry-pick dd0e8786de07bd90c4b1e07b9b33a9968b1ab305
# keep removing them
git rm python/Analyzer_2016_94X_MC_cff.py python/Analyzer_2016_94X_cff.py python/Analyzer_2017_94X_MC_cff.py  python/Analyzer_2017_94X_cff.py
git cherry-pick --continue

Though it does not compile.

I realised that I didn't picked Andrew initial FSR part... Trying to fix it on the fly adding the classes in the BuildFiles.

vi src/classes.h 
vi src/classes_def.xml 
git commit -m "adding photos classes" src/classes.h src/classes_def.xml
scram b clean
scram b -j 8

also need to update NtupleBranches.h no. too messy. need to integrate Andrew's commits carefully.

[bortigno]

Thanks Efe.

Starting fresh on a different branch port-issue-86-2018-fsr-2

git cherry-pick 908bc3b
git cherry-pick 4e99ad8
git cherry-pick 346ae62
git cherry-pick b360b0a
# checking conflicts 
# deleted by us:   python/Analyzer_2017_94X_MC_cff.py
git rm python/Analyzer_2017_94X*cff.py
git cherry-pick --continue
git cherry-pick 60fcd5d
git rm python/Analyzer_2016_94X*cff.py
git cherry-pick --continue
git cherry-pick dd0e878
git rm python/Analyzer_2017_94X*cff.py
git rm python/Analyzer_2016_94X*cff.py
git cherry-pick --continue

scram b -j 6

It compiles and runs. Here some DQM plots and table on ggH MC. They all look good except for the relIso: do we expect this range of values? Looking at the code [1] looks a bit strange. We are summing only pi+ K-long and photon in the relative isolation? that means that it works only on MC ? Uhm ? Probably not a big deal but I would like to understand more about it.

[1] https://github.com/UFLX2MuMu/Ntupliser/blob/7b8678cf7d01d21e22b391818575931fc801d875/DiMuons/src/PhotHelper.cc#L132 https://github.com/UFLX2MuMu/Ntupliser/blob/7b8678cf7d01d21e22b391818575931fc801d875/DiMuons/src/PhotHelper.cc#L134

***********************************************************************************************************
*    Row   * Instance * phots.mu_ *  phots.pt * muons[pho * phots.eta * muons[pho * phots.phi * muons[pho *
***********************************************************************************************************
*       59 *        0 *         1 * 3.6777343 * 28.105695 * 0.8609882 * 0.9443836 * -2.666875 * -3.035466 *
*       74 *        0 *         1 *  40.09375 * 17.343797 * -2.389050 * -2.391192 * -0.263972 * -0.269594 *
*       76 *        0 *         1 * 3.6621093 * 60.359058 * -1.275185 * -1.413371 * 2.8557539 * 3.0427646 *
*       90 *        0 *         1 * 30.859375 * 45.535308 * -0.850917 * -0.430917 * 2.1068029 * 2.0570042 *
*      107 *        0 *         1 * 13.382812 * 46.211071 * -1.694875 * -1.252443 * 0.0785172 * -0.071018 *
*      119 *        0 *         1 * 3.7714843 * 25.229314 * 2.3912472 * 1.9300645 * -0.276475 * -0.447761 *
*      131 *        0 *         1 * 29.453125 * 26.749019 * 1.3385418 * 1.7864931 * -0.054200 * -0.010745 *
*      154 *        0 *         1 *     4.625 * 36.477092 * -1.154698 * -1.411425 * -2.328096 * -2.350880 *
*      176 *        0 *         1 * 12.414062 * 28.773145 * 0.7324442 * 0.7332011 * 2.4759552 * 2.4893791 *
*      236 *        0 *         1 * 2.6113281 * 65.523887 * -0.191167 * -0.256859 * -0.012106 * -0.170671 *
*      279 *        0 *         1 * 7.0273437 * 37.833454 * -0.396252 * -0.385792 * -0.320125 * -0.357356 *
*      294 *        0 *         1 *    6.6875 * 13.730788 * -0.918301 * -1.214926 * -0.768576 * -1.011752 *
*      320 *        0 *         1 * 11.453125 * 46.410873 * -0.384166 * -0.584789 * 1.9220321 * 2.3574824 *
*      509 *        0 *         1 *  3.078125 * 39.501075 * -0.005676 * 0.2097582 * -0.449326 * -0.629403 *
*      512 *        0 *         1 * 2.6660156 * 16.372848 * -1.076509 * -1.201470 * -1.025320 * -0.940474 *
*      520 *        0 *         1 * 12.570312 * 37.594993 * -0.056031 * -0.026600 * -0.037501 * 0.0035327 *
*      521 *        0 *         1 * 5.1601562 * 45.773750 * 0.3936887 * 0.5298694 * 0.7926980 * 1.0124131 *
*      556 *        0 *         1 * 3.5820312 * 42.418148 * -0.794152 * -1.061666 * 2.4564199 * 2.2829618 *
*      653 *        0 *         1 * 2.1777343 * 28.941539 * -2.151737 * -2.039757 * 1.0125263 * 0.9137029 *
*      665 *        0 *         1 * 15.226562 * 35.922256 * -0.089358 * -0.086781 * 0.3272567 * 0.3270896 *
*      668 *        0 *         1 *  39.84375 * 22.598924 * 0.0849635 * 0.0847059 * 2.9852476 * 2.9805650 *
***********************************************************************************************************

[bortigno]

Open PR #95

[bortigno]

Make sure we are storing enough phase space to accommodate possible additional cuts.

[eyigitba]

I checked Raffaele's talk (https://indico.cern.ch/event/855983/contributions/3602452/subcontributions/293426/attachments/1949210/3234936/Raffaele_20_11_2019.pdf) and he's suggesting a more aggressive cut on dR (around 0.05). We currently have very loose cuts in all the dR (at 0.5) and isolation variables. I think we don't have anything to worry about and we can close this issue.

[eyigitba]

Everything is OK. Merged in #87, #93 and #95.