Skip to content

Various changes

Sebastien Wertz requested to merge variousChanges into master
  • New possibility to avoid running every time a different sample list has to be used:
    • Define an environment variable for the folder containing all the JSON files, e.g. export SAMPLE_JSONS=/t3home/swertz/swertz/CMSSW_10_2_16_NanoSkim/src/uzh_ttbb/NanoSkimmer/test/Jul2020NanoV6Production/
    • Specify --samples TEMPLATE.YML to, where TEMPLATE.YML can be e.g. config/samples_template.yml or another "template" file with a subset of the samples.
    • Note that the behviour of is not changed, and can still be used as before (-> don't specify the --samples argument, and insert the file list to be used into config/samples.yml).
    • Also note that for technical reasons a config/samples.yml file still has to be present to be loaded into config/analysis.yml, even if that file is actually not used to build the sample list.
  • Add new HT-binned samples to list
  • Latest additions to genMatchingStudies (matching with reco level objets)
  • Rework (and rename) function that normalizes and sums MC contributions to also support systematics (with some caveats)
  • Some changes and additions to plotting utilities:
    • reads simple YAML file (see e.g. /t3home/swertz/swertz/bambooOutput/200701_genRecMatching_fixBug/comparisons.yml), produces not-too-ugly plots with ratios for comparisons
    • plot all 2D slices of a 3D histogram
  • bTagPlotter:
    • Produce and use 3D b-tag SF patches
    • Produce all comparison plots from the postprocessing function
  • controlPlotter: use the 3D b-tag SF patches previously produced using the bTagPlotter
  • Also, I was thinking about the problem of avoiding overlap between the 5FS and 4FS samples: in the samples_template.yml, you'll see that the 5FS samples only have ttcc and ttjj subprocess, while the 4FS sample only has ttB: this is sufficient to avoid any double-counting. Some comments though:
    • In some cases we might still want to process the ttB component of the 5FS sample. We'll have to find another way to exclude it from plotIt (I'll come up with something)
    • When doing unfolding we don't want to enforce the ttB genTtbarCategory for building the signal templates, so the unfolding plotter musn't enforce it (FYI @kcormier, is that OK with you like this?)

Given that there are more and more things added to the bamboo plotting modules (extra arguments, file list insertion, b-tag SF patches, ...), it might be good to have a common subclass for all our modules, to avoid forgetting things and making updates easier. But I'll leave that to a future PR to avoid too disruptive changes now.

Merge request reports