search

cms-tau-pog / TauFW

Analysis framework for tau analysis at CMS using NanoAOD
9 stars 40 forks source link

Full stitching #23

Closed smonig closed 1 year ago

smonig commented 2 years ago
IzaakWN commented 2 years ago

Hi @smonig, you have added your JSON config file again... :p Can you maybe close this PR and open a new one with a new branch where you did not commit/touch the PicoProducer/config/config.json, please?

Besides that, did you already manage to do a closure test with/without the mutauh stitching to compare the overall yield and shapes?

smonig commented 2 years ago

Hi @smonig, you have added your JSON config file again... :p Can you maybe close this PR and open a new one with a new branch where you did not commit/touch the PicoProducer/config/config.json, please?

Besides that, did you already manage to do a closure test with/without the mutauh stitching to compare the overall yield and shapes?

Hi @IzaakWN , thanks for checking. Oups; I already made a new branch, but it looks like the config changes ended up in my own master. It should now be fixed... sorry! :-)

I made some closure tests on the visible mass. The agreement is not perfect, so I planned to still check where it comes from. Screenshot_20220829_115711

IzaakWN commented 2 years ago

Hi @smonig,

Thanks for the plot. Did you use this version of the mutau flag for all DY samples you stitch? https://github.com/cms-tau-pog/TauFW/blob/master/PicoProducer/python/analysis/utils.py#L146-L194 In particular, making sure you exclude taus that radiate, see slide 6: https://indico.cern.ch/event/1170879/#2-validation-of-exclusive-dy-t

You could also check per LHE-njets (NPU) bin to see if that's the reason. Also adding stat. error bars can be useful.

Regarding the branch. I think it's safer to open a new PR with the fresh branch where you did not touch the config file.

Cheers, Izaak

smonig commented 2 years ago

Hi @smonig,

Thanks for the plot. Did you use this version of the mutau flag for all DY samples you stitch? https://github.com/cms-tau-pog/TauFW/blob/master/PicoProducer/python/analysis/utils.py#L146-L194 In particular, making sure you exclude taus that radiate, see slide 6: https://indico.cern.ch/event/1170879/#2-validation-of-exclusive-dy-t

You could also check per LHE-njets (NPU) bin to see if that's the reason. Also adding stat. error bars can be useful.

Regarding the branch. I think it's safer to open a new PR with the fresh branch where you did not touch the config file.

Cheers, Izaak

Yes, I am using the flag with excluding the radiating taus (can check again that the charge asymmetry disappeared as expected). And yes, these are checks I am going to do. Stat errors are very small (barely visible in the inclusive distribution), this is why I did not plot them here; they can not explain the diff.

For the branch: I would say this is safe. Basically I reverted the config in my master and then checked it out from the master in this branch. Otherwise, this branch is exactly what you said, i.e. a copy of the master branch with only the stitching changes. :-)

smonig commented 2 years ago

Hi @IzaakWN , just to keep you posted (sorry for me being slow at the moment...). I just made a few more checks, and what is most apparent is that the stitching becomes less good with increasing number of jets, as shown in the plots below:

Screenshot_20220906_160959

If you look the mutau efficiencies in the Njet sample, one clearly sees a dependency. So I believe, the mismatch might come from this approximation:

Screenshot_20220906_161109

where instead of taking the product eff_Nj^incl * eff_mutau^incl/excl, one should compute directly the eff_mutau&&nj^incl/excl. I think, that for this I would need to reproduce samples adding the NUP fractions in the cutflow in order to compute the efficiencies, so that is why I am posting this here already now as a status update...

smonig commented 2 years ago

Hi @IzaakWN again,

so indeed, computing the specifig weights (instead off using eff_njet^incl * effmutau^excl / incl, compute directly eff(mutau && njet) ^ excl / incl) solves the problem. Of course, these efficiencies will need to be updated with the corrected mutau flag, for now they use the radiating tau veto. I put a warning in the code.

Screenshot_20220907_102414

IzaakWN commented 1 year ago

Okay, great! Many thanks for the closure test! Merging now. As discussed privately, when the new samples arrive, we should 1. back up the current version into a separate branch,

  1. update the mutaufilter (without radiating tau veto),
  2. update the stitching weights.