PUPPI vs CHS

In principle, PUPPI leads to smaller uncertainties and is now recommended over CHS. One should simply rerun the whole workflow, say for 2018 where the pileup is the strongest, and check the impact on the spectrum and on the uncertainties.

assigned to @vaguglie

added On hold label

removed On hold label

added To Do label

changed milestone to %pile-up

changed milestone to %Understanding JERC (UL FR2)

changed milestone to %pile-up

added to epic &2

removed milestone %pile-up

added changepatch important typephysics labels

added changenone label and removed changepatch label

assigned to @euslan and unassigned @vaguglie

I am trying the applyJEScorrections step for PUPPI and CHS. When I used tables/jsonpog-integration/POG/JME/2018_UL/jet_jerc.json and Summer19UL18_V5_MC as the tag for CHS, it worked without any problems. I have added how I run the command below.

parallel -j16 applyJEScorrections 3M_applyPUcleaning/ 4M_applyJEScorrections/ /eos/user/e/euslan/EL9/DasAnalysisSystem/tables/jsonpog-integration/POG/JME/2018_UL/jet_jerc.json Summer19UL18_V5_MC -f -s

When I try the same for PUPPI, I get the error below. Then I check jet_jerc.json, the corrections are all named as chs.

Should I use a different JSON file for correctıons?

try applyJEScorrections 3M_applyPUcleaning/ 4M_applyJEScorrections/ /eos/user/e/euslan/EL9/DasAnalysisSystem/tables/jsonpog-integration/POG/JME/2018_UL/jet_jerc.json Summer19UL18_V5_MC -f -s
applyJEScorrections 3M_applyPUcleaning/ /eos/home-e/euslan/Root_Files_EL9/Pythia_FlatUL18_PUPPI/4M_applyJEScorrections/0.root /eos/user/e/euslan/EL9/DasAnalysisSystem/tables/jsonpog-integration/POG/JME/2018_UL/jet_jerc.json Summer19UL18_V5_MC -f -s -j 193897
applyJEScorrections 0/193897 start
latest commit: Merge branch 'migration' into 'main'

Migration

Closes #123, #125, #109, #96, #133, and #121

See merge request cms-analysis/general/DasAnalysisSystem/Core!174               by Patrick Louis S Connor (964e6891db8b4ba)
Warning: input tree not reproducible.
ControlPlots	raw
ControlPlots	nominal
ControlPlots	AbsoluteStatDown
ControlPlots	AbsoluteStatUp
ControlPlots	AbsoluteScaleDown
ControlPlots	AbsoluteScaleUp
ControlPlots	AbsoluteMPFBiasDown
ControlPlots	AbsoluteMPFBiasUp
ControlPlots	FragmentationDown
ControlPlots	FragmentationUp
ControlPlots	SinglePionECALDown
ControlPlots	SinglePionECALUp
ControlPlots	SinglePionHCALDown
ControlPlots	SinglePionHCALUp
ControlPlots	FlavorQCDDown
ControlPlots	FlavorQCDUp
ControlPlots	RelativeJEREC1Down
ControlPlots	RelativeJEREC1Up
ControlPlots	RelativeJEREC2Down
ControlPlots	RelativeJEREC2Up
ControlPlots	RelativeJERHFDown
ControlPlots	RelativeJERHFUp
ControlPlots	RelativePtBBDown
ControlPlots	RelativePtBBUp
ControlPlots	RelativePtEC1Down
ControlPlots	RelativePtEC1Up
ControlPlots	RelativePtEC2Down
ControlPlots	RelativePtEC2Up
ControlPlots	RelativePtHFDown
ControlPlots	RelativePtHFUp
ControlPlots	RelativeBalDown
ControlPlots	RelativeBalUp
ControlPlots	RelativeSampleDown
ControlPlots	RelativeSampleUp
ControlPlots	RelativeFSRDown
ControlPlots	RelativeFSRUp
ControlPlots	RelativeStatFSRDown
ControlPlots	RelativeStatFSRUp
ControlPlots	RelativeStatECDown
ControlPlots	RelativeStatECUp
ControlPlots	RelativeStatHFDown
ControlPlots	RelativeStatHFUp
ControlPlots	PileUpDataMCDown
ControlPlots	PileUpDataMCUp
ControlPlots	PileUpPtRefDown
ControlPlots	PileUpPtRefUp
ControlPlots	PileUpPtBBDown
ControlPlots	PileUpPtBBUp
ControlPlots	PileUpPtEC1Down
ControlPlots	PileUpPtEC1Up
ControlPlots	PileUpPtEC2Down
ControlPlots	PileUpPtEC2Up
ControlPlots	PileUpPtHFDown
ControlPlots	PileUpPtHFUp
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
try: Command '['applyJEScorrections', '3M_applyPUcleaning/', '/eos/home-e/euslan/Root_Files_EL9/Pythia_FlatUL18_PUPPI/4M_applyJEScorrections/0.root', '/eos/user/e/euslan/EL9/DasAnalysisSystem/tables/jsonpog-integration/POG/JME/2018_UL/jet_jerc.json', 'Summer19UL18_V5_MC', '-f', '-s', '-j', '193897']' died with <Signals.SIGABRT: 6>.
Boost 1_82, Cpp C++20, Darwin a30e901bffe1fdf9b7f11974b793300495143f0c, ROOT 6.28/04, gpp 13.1.0, libgit2 1.1.1, Python 3.9
Consider opening a GitLab issue if you don't understand the cause of the failure.

added statusongoing label and removed statusto do label

It seems to me that the https://gitlab.cern.ch/cms-nanoAOD/jsonpog-integration repo isn't exhaustive. I can find

• AK4chs in jet_jerc.json
• AK8puppi in fatJet_jerc.json

but AK4puppi and AK8chs in none of them.

Can you ask the JERC subgroup on their CMS Talk channel?

Important note: as mentioned in that other thread, the V5 tables are invalid for AK8, and V6 tables should be used. @dsavoiu (current JERC L3 convener) gently provided V6 tables for AK8chs, but I am not sure if AK8puppi have been included in the tables (in principle, one can use correction summary jet_jerc.json to get a summary of the content of the tables, but the command is currently yielding an error...)

Note for myself:

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

should be properly caught by a catch block.

mentioned in issue #157 (closed)

Here are the trigger efficiencies results for PUPPI and CHS.

UL18_TriggerEff.pdf

Thanks!

1. Can you plot the tag-and-probe efficiency for all triggers?
2. There is currently no fit in the procedure, so showing it is misleading (and it anyway seems to fail in certain cases).

Added pT spectrum comparison for PUPPI and CHS.

UL18_pT-spectrum-andTriggerEff.pdf

added statusfinalising label and removed statusongoing label