-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merging jet uncertainty evaluator #114
base: master
Are you sure you want to change the base?
Conversation
…on code for adjusting this efficiently
Could you give a brief writeup of what each piece is doing and where and how it runs? In particular, we have to do this at the nano level in CMSSW, it needs something not already in the nanoAOD? |
Ah, sorry, it's my fault. I should describe the details... [1] nano/nanoAOD/plugins/JetUncertaintyEvaluator.cc Lines 74 to 84 in 43d20eb
[2] nano/nanoAOD/plugins/JetUncertaintyEvaluator.cc Lines 87 to 116 in 43d20eb
[3] https://github.com/vallot/CATTools/blob/cat90x/CatProducer/plugins/CATJetProducer.cc#L218-L228 [4] https://github.com/vallot/CATTools/blob/cat90x/CatProducer/plugins/CATJetProducer.cc#L238-L266 |
should be able to just do tlorentzvector*Jet_jes_up |
Yep, actually my instruction in the above comment is mathematically equivalent to yours. Btw strangely, the postprocessing tool provided by nanoAOD guys gives evaluations for each of mass of jets and pt of jets separately (see [1] and [2] and [3]). I think it gives somewhat different factors on mass and pt, where other evaluations are applied to mass (JMS, JMR, see [2]). Also I think the nominal values of JMS and JMR for mass in their code are not unit in default. I think we need to check them, at least whether we can ignore them or not [1] https://github.com/cms-nanoAOD/nanoAOD-tools/blob/master/python/postprocessing/modules/jme/jetmetUncertainties.py#L237-L259 |
Yes, let's find the instructions recommended by the JetMET group, and the particular instructions on how we should evaluate the systematics from the Top group. My preference would be that if we can evaluate the systematics using the nano tuples only (i.e. don't need anything extra from MiniAOD collections) that we just add our own little analyser to do it (or adapt nanoAOD-tools or someone elses code or so), and be able to run on the fly. But step 1 is to check the recommendations on the twiki. |
is this done? |
Nope... I've implemented the product code for this into on-the-fly level, and now I'm testing it. |
Also, as mentioned in the last comment in the related issue ([1]), I think we need to have a discussion about the additional jet mass factor. (I should bring this topic to the last nanoAOD meeting...) [1] #57 |
Weren't we trying to not have to use CMSSW? |
Ah, I just used [1] https://github.com/cms-sw/cmssw/blob/CMSSW_9_4_X/DataFormats/Math/interface/deltaR.h |
No more than the header file is needed, but it means we have to pull in all the CMSSW to use it, i.e. can't be run locally. |
Alright, then I'll roll back this. [1] nano/analysis/interface/topObjectSelection.h Lines 8 to 11 in 0c21443
|
Well, I've read codes for JER/JES in CMSSW I used. I think there dependency of CMSSW is almost trivial (even JER part is already designed with standalone case), so I can port them into our nano standalone, that is, into nano/external. Shall I do this? |
Yep, I would prefer it if its simple enough. So far, we're still able to compile and test analysis/ standalone, if its possible to keep this structure if we can. Thanks! |
But of course, we should document where we take it from so we can check the updates as the new calibrations come through. |
Don't worry, that's a basic option. ;) I'll port asap. |
Hm, seems like the JER files are not the problem, but there might be something unexpected. I'm looking for what the heck it is. |
I changed some namespace to avoid conflicts with CMSSW. This is tested in the CMSSW_9_4_6 docker image |
I checked that our nanoAOD producer only do JEC but not nominal JER smearing, and my code produces same result as 'the nominal JER smearing in CMSSW' (see [1]). See my slides ([2]) which summarizes all of this. [1] https://github.com/cms-sw/cmssw/blob/CMSSW_9_4_X/PhysicsTools/PatUtils/interface/SmearedJetProducerT.h |
I changed some of my test code (the jetUncEval_compare branch); because I turned off the pre-cut on jets in nanoAOD production (see [1]), the size of jet arraries is not enough so that it causes memory corruption. (Don't worry, with the pre-cut, our current size seems enough.) So, only for this test, I changed the size (see [2]). (ONLY FOR THIS TEST BRANCH. Not for pull request at all.) This solves the issue on JEC discrepancy in full event test (see p. 20 in my slides). But still the discrepancy on smearing is remaining. Hm... [1] quark2/cmssw@820c63b |
…he repositories (neither nano nor nanoData)
I added a slide for comparison of jets before smearing with after-smearing ones. Does it make sense? |
analysis/src/topObjectSelection.cc
Outdated
// In default, these are same as the original ones, but when a user wants to study systematic uncertainty | ||
// so that he/she needs to switch them to the evaluated ones, | ||
// just touching them in anlalyser class will be okay, and this is for it. | ||
void topObjectSelection::GetJetMassPt(UInt_t nIdx, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't everyone need to do this? In which case, why are we doing it in top objects and not a level above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean, it would be better if this function (and the stuffs for initialization in the constructor) is in mother class, that is, nanoBase?
@@ -1,4 +1,6 @@ | |||
<use name="nano/external" /> | |||
<use name="JetMETCorrections/Objects"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can remove this now
@@ -87,8 +92,9 @@ class topObjectSelection : public nanoBase | |||
|
|||
std::vector<TParticle> genJetSelection(); | |||
|
|||
topObjectSelection(TTree *tree=0, TTree *had=0, TTree *hadTruth=0, Bool_t isMC = false); | |||
topObjectSelection(TTree *tree=0, Bool_t isMC=false) : topObjectSelection(tree, 0, 0, isMC) {} | |||
topObjectSelection(TTree *tree=0, TTree *had=0, TTree *hadTruth=0, Bool_t isMC = false, UInt_t unFlag = 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we name unFlag better? Its just for JES/JER, so maybe jetUnc?
const double jetRes = m_jetResObj.getResolution(jetPars); // Note: this is relative resolution. | ||
const double cJER = m_jetResSFObj.getScaleFactor(jetPars, | ||
((unFlag & (OptFlag_JER_Up | OptFlag_JER_Dn)) == 0 ? Variation::NOMINAL : | ||
((unFlag & OptFlag_JER_Up) != 0 ? Variation::UP : Variation::DOWN))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit confusing, we can use plain flags rather than bit fields for these options
Launching jet uncertainty evaluator, and modifying the object selection code for adjusting this efficiently