Add UL2017 JECs and JERs #248
Conversation
Rebase master, 27/08/2019
Rebase from master
Rebase again.
Rebase master
|
@fgolf |
| '2018' : [1.24, 1.20, 1.28] | ||
| jmrValues = { '2016' : [1.0, 1.2, 0.8], | ||
| '2017' : [1.09, 1.14, 1.04], | ||
| 'UL2017' : [1.00, 1.00, 1.00], # placeholder |
There was a problem hiding this comment.
note for later:
the jetMass scale and resolution use the placeholder values. basically no smearing/noscaling.
Given the large set of changes (taggerss algorithm, puppi tune) ... I think it's better to reset these for the UL and update later when proper values are checked as function of pt
|
Btw, after these |
|
pinging jme conveners @ahinzmann, @lathomas |
|
@IzaakWN you mean that you still see data/MC discrepancy? Yes, the agreement is not perfect but much better than EOY and now within JES uncties in principle. See slide 9 and 30 of https://indico.cern.ch/event/928283/contributions/3912643/attachments/2061682/3469831/ul17jecsvalidation_v2.pdf |
|
Yes, that we still see data/MC discrepancies. Thanks for the links! It indeed looks consistent. Regarding this PR, do you think it's worth it to already include these JECs into this repository, or should we wait for the next set of corrections? |
|
Yes I wouldn't wait. The next set of UL17 JECs will not happen before a few months. |
|
@IzaakWN |
|
Hi, as far as I could tell, ignoring spaces, the only conflicting change was |
Looks good to me. thanks |
| '2018' : [1.24, 1.20, 1.28] | ||
| jmrValues = { '2016' : [1.0, 1.2, 0.8], | ||
| '2017' : [1.09, 1.14, 1.04], | ||
| '2018' : [1.09, 1.14, 1.04], # Use 2017 values for 2018 until 2018 are released |
There was a problem hiding this comment.
Why were these reverted to the 2017 values?
There was a problem hiding this comment.
@camclean
indeed where changed accidentally
questions:
- where the 2018 come from ? are not in the wiki page
https://twiki.cern.ch/twiki/bin/view/CMS/JetWtagging#2018_scale_factors_and_correctio - the original,up,down numbers seems not correct looks more "nominal, down, up"
There was a problem hiding this comment.
The numbers are working point dependent and are shown in the tables in the section you linked. You can see the JMS and JMR values in the m and sigma column in the data/MC row.
--> sorry I cannot find in the twiki (rev 77) the table of the 2018 JMR/JMS. I can see very clearly the 2016-2017. Neither the numbers "1.24" (your new JMRnominal) nor "0.997" (your new JMSnominal) can be found on the wiki.
----> The numbers are here (copied from the twiki).
Yes, it should be nominal, down, up.
--> it cannot be that for 2016-2017 we have nominal, up, down and then for 2018 nominal, down, up. If this is the way the code handles stuff, some some cleanup is required there.
----> I apologize. This was incorrect. The JMS values below are nominal, down, up, while you are right that the JMR values are nominal, up, down.
There was a problem hiding this comment.
So in the end it was good that this was removed because it was buggy. But the values should now be updated to 2018 values.
Since there are actually multiple working points for W-tagging (and they should be optional), I can make a PR that makes the JMS/JMR values default to 1.0 but have optional other inputs. I think there are a couple of other outstanding updates/fixes from the JME side so maybe I should prepare a presentation for the next XPOG meeting?
Add latest JECs (
Summer19UL17_V5, TWiki) and JERs (Summer19UL17_JRV2, TWiki) and implement intojetmetHelperRun2.pyas'UL2017'. @danbarto @camclean(This PR would be use for measurements in the TauPOG based on nanoAOD.)