-
Notifications
You must be signed in to change notification settings - Fork 5
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
vhbb#561 #564
vhbb#561 #564
Conversation
…ts are kept in Ntuples (needed for measurement of electron charge misidentification rate and of jet->lepton fake-rate in ttH, H->tautau analysis)
- resolved merge conflicts - added triggers for ttH, H->tautau analysis for full 2016 dataset Conflicts: VHbbAnalysis/Heppy/python/TriggerTable.py VHbbAnalysis/Heppy/python/TriggerTableData.py
Hi Andrea, |
this PR makes passall=true that is not ok. If there is a specific class of events you want to save we have to let them pass, we cannot passall=true for space reason especially when running on fully hadronic stuff |
Hi Andrea, the effect of the passall=true flag is that events with less than 2 jets no longer get cut. The nJets >= 2 cut is very loose for fully hadronic events. I expect that the nJets >= 2 cut mainly removes Z->ll and W->lnu events. Unfortunately, we do need an inclusive sample of Z->ee events for the purpose of estimating backgrounds, arising from electron charge misidentification, in the ttH, H->tautau analysis. I would prefer that we keep the event processing simple and not run different configs (with and without the nJet >= 2 cut on different samples). If disk space is a problem, we can store the VHbb Ntuples in Tallinn if you like (we have enough disk space). |
you only need Zee? then why having passall=true? can't we just whitelist Vtype=1 ? |
Hi Andrea,
The “problem” is that we need to compare Z->ee data (single and double electron datasets) will the sum of SM MC (DYJets, but also WJets, TTbar, diboson).
Maybe it is easier to discuss this on Skype… samples with tt+jets, ttH and H->bb will pass the nJets >= 2 cut anyway, so setting passall=true will not increase the size of those samples, isn’t it ?
Cheers,
Christian
… On Dec 21, 2016, at 2:53 PM, arizzi ***@***.***> wrote:
you only need Zee? then why having passall=true? can't we just whitelist Vtype=1 ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#564 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwCTpZXVX1YUJ5e7beFqTUPKVBX8_DJks5rKSFDgaJpZM4KrjGC>.
|
HI Andrea, Christian, sorry to chime in, May I ask you @veelken if you know for example for QCD bkgs how much would be the addition of events on tape? I think this is the only sample that we are afraid of exploding, @arizzi true? Maybe also the data (MET dataset? BtagCVS?
|
michele, asking with no motivation is not going to go anywhere. What's the reason for passall=true from others? |
ciao, I tend to agree with @arizzi that we have to be conservative about space for the following reasons:
Possibly for the special cases one can consider making a separate crab run, but we have to keep throwing events at every possible stage we can. |
the most common comment is to make life easier for signal and bkg cut flow/efficiency studies btw it would be interesting to quantify for QCD |
Hi Michele,
I haven’t checked the effect on QCD multijet MC. I would expect that most QCD events actually pass nJets >= 2 anyway, as the pT and eta cuts on the jets are rather loose (pT > 25 GeV && abs(eta) < 4.7).
Cheers,
Christian
P.S. If you want me to compare the size of the VHbb Ntuples with and without the nJets >= 2 cut for one QCD MC sample, I am happy to do it. Just let me know on which sample I should run on
… On Dec 21, 2016, at 3:51 PM, michele de gruttola ***@***.***> wrote:
the most common comment is to make life easier for signal and bkg cut flow/efficiency studies
(so I guess is more relevant for signal samples)
btw it would be interesting to quantify for QCD
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#564 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwCTuXcwZofWC2WUmpUqYgiCC0xhAipks5rKS7ngaJpZM4KrjGC>.
|
Hi, QCDHT200-300: root -l root://stormgf1.pi.infn.it:1094///store/user/arizzi/VHBBHeppyV24/QCD_HT200to300_TuneCUETP8M1_13TeV-madgraphMLM-pythia8/VHBB_HEPPY_V24_QCD_HT200to300_TuneCUETP8M1_13TeV-madgraphMLM-Py8__spr16MAv2-puspr16_80r2as_2016_MAv2_v0-v1/160909_064004/0000/tree_4.root but for the lower bin we consider so this one will be problematic |
Hi Michele, thank you for the numbers. I didn't know it is that easy to get them! Cheers, Christian |
no, we are not going to do it. PS: QCD events are not passing for other reasons (not the 2 jets requirements) and the passall will let those go through too. |
Hi, I have changed passall=False so that PR #561 can be merged. Cheers, Christian |
Can you perhaps clarify the details of the selection you would apply on the
passall=true events?
Which vtype? Any ll mass cut?
Ciao
Andrea
Il 22 dic 2016 09:50, "Christian Veelken" <notifications@github.com> ha
scritto:
Hi,
I have changed passall=False so that PR #561
<#561> can be merged.
Would it be an option that we build two versions of vhbbHeppy for the
ReReco data and MC , one with passall=True and one with passall=False, so
that a few VHbb Ntuples could centrally be produced with passall set to
true ?
The alternative is of course that people working on ttH, H->tautau organize
the production of samples with passall=True by themselves.
What do you think ?
Cheers,
Christian
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#564 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEyiluRP-6YU4-3gCrJQ0uGl8QP9q0Myks5rKjmkgaJpZM4KrjGC>
.
|
Hi Andrea, we don't apply a cut on vtype in the ttH, H->tautau analysis. We do apply a cut 60 < mll < 120 GeV in some of our control regions/auxiliary measurements, but not in all. The best option in my opinion would still be to set passall=true based on the sample name. I noticed that PR #561 is not merged yet. Can you please merge it now ? Cheers, Christian |
what does "mll" means for VTypes where there are not two leptons selected?!? |
Hi Andrea, we compute mll by looping over the selLeptons branch, apply some lepton selection criteria and then add the lepton four-vectors for pairs of leptons that pass the lepton selection criteria. As I mentioned before, I think it is best not to use vtype and mll, but set passall=true based on the sample name. Cheers, Christian |
well, "it is better" is a relative concept, for sure it is not better for who has to babysit tens of thousands of jobs and add the complication of different settings. |
Hi Andrea, sorry for not being more clear about it: Zee is only one of the control regions we need for ttH, H->tautau. We need other control regions to measure tight/loose lepton ratios and these control regions use events with single leptons (these control regions are dominated by QCD; we don't need QCD MC for these measurements though, only data). Cheers, Christian |
this doesn't help. On data the passall=false is even more important because that's where we get most of the reduction. |
@@ -263,6 +263,7 @@ | |||
from PhysicsTools.Heppy.analyzers.objects.JetAnalyzer import JetAnalyzer | |||
JetAna = JetAnalyzer.defaultConfig | |||
JetAna.calculateSeparateCorrections = True # CV: needed for ttH prompt lepton MVA | |||
JetAna.lepSelCut = lambda lep : (abs(lep.pdgId()) == 11 and lep.relIso03 < 0.4) or (abs(lep.pdgId()) == 13 and lep.relIso04 < 0.4) |
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.
what is this meant for? we already have a selection for the selectedLeptons used here.
The only difference seem to be you do not OR with miniIsoltion, is that the purpose? remove the miniIsolation or?
Hi Andrea, yes, the motivation for this change is to not clean the jets wrt leptons that pass the miniIsolation, but fail the standard isolation. As we studied with Lorenzo, the effect of cleaning the jets wrt leptons passing miniIsolation or standard isolation is small, on the level of 1%. The main motivation for restoring the "old" jet cleaning behavior is to avoid differences in synchronization with other groups. |
Dear all,
we would like to propose 3 modifications to vhbb.py and vhbbobj.py for the ttH, H->tautau analysis. We believe the modifications will not introduce any problem for anyone, except for an increase in filesize for some of the samples. Please let us know what you think.
Cheers,
Karl and Christian
for ttH, H->tautau
vhbb.py
In the VHbbAnalyzer config we would like to set the flag passall=True to disable the numJets >= 2 cut
The motivation for this modification is that in the ttH multilepton and ttH, H->tautau analyses we measure the electron charge misidentification rate in Z->ee events. Because the electron charge misidentification rate is very small, we need the full event statistics.
We would like to add
JetAna.lepSelCut = lambda lep : (abs(lep.pdgId()) == 11 and lep.relIso03 < 0.4) or (abs(lep.pdgId()) == 13 and lep.relIso04 < 0.4)
so that jets don't get cleaned with respect to leptons that pass only the miniIso, but not the standard isolation cuts. In case the jet collection is cleaned with respect to leptons passing the miniIso, about 1% of b-jets get cleaned, which we would like to recover.
vhbbobj.py
We would like to replace the line
NTupleVariable("eleooEmooP", lambda x : abs(1.0/x.ecalEnergy() - x.eSuperClusterOverP()/x.ecalEnergy()) if abs(x.pdgId())==11 and x.ecalEnergy()>0.0 else 9e9 , help="Electron 1/E - 1/P"),
by
NTupleVariable("eleooEmooP", lambda x : (1.0/x.ecalEnergy() - x.eSuperClusterOverP()/x.ecalEnergy()) if abs(x.pdgId())==11 and x.ecalEnergy()>0.0 else 9e9 , help="Electron 1/E - 1/P"),
i.e. remove the abs function. In the ttH multilepton and ttH, H->tautau analyses events with negative 1/E - 1/P values get cut and the presence of the abs in the computation of eleooEmooP means that we cannot do that, causing a problem for us in terms of synchronization with other groups. In our opinion, it is safe to remove the abs function, as it can always be applied later on analysis level.