Closed swertz closed 8 years ago
Gen identification does not seem to work well too. I found 0 hadronic ttbar events in all the files I opened, strange :)
Nvm I'm a bit slow tonight. I forgot we require at least two leptons to keep the event, so it's not surprising we don't have any hadronic ttbar...
Kind of expected ^^ But I would have thought we'd pick up at least one or two hadronic events with jets faking elecrons... Well, good that it doesn't happen :)
Well I actually opened only two files, so maybe we have some somewhere else :smiley_cat:
According to muon pog and top pag, we should use delta-beta corrections for muons isolation, and not effective areas as we do for the moment.
Oh good they updated the twikis... Is there anything to add/update in the framework or is it just a function call to change?
It's a function call to change :) It's just swapping 'relativeIsoR0?_withEA' with 'relativeIsoR0?_deltaBeta'
2015-11-02 10:46 GMT+01:00 Sébastien Wertz notifications@github.com:
Oh good they updated the twikis... Is there anything to add/update in the framework or is it just a function call to change?
— Reply to this email directly or view it on GitHub https://github.com/cp3-llbb/TTAnalysis/issues/20#issuecomment-152972144.
Sébastien Brochet
Looking at presentations in the Top XS PAG today, people seem to be using loose JetID... So I think we can try it as well and see what it gives.
We also need to store the hadronFlavour of the jets in MC, to define the b-tagging efficiencies... The info is available in the jets produced by the framework, but it's maybe more convenient to have it directly in the structure?
It's already in the tree, so since we keep the jet index, I think we are good here, don't you?
2015-11-23 11:26 GMT+01:00 Sébastien Wertz notifications@github.com:
We also need to store the hadronFlavour of the jets in MC, to define the b-tagging efficiencies.
— Reply to this email directly or view it on GitHub https://github.com/cp3-llbb/TTAnalysis/issues/20#issuecomment-158898017.
Sébastien Brochet
Yes using https://github.com/swertz/TTAnalysis/blob/master/interface/Types.h#L103 it's probably fine...
I looked at PV requirement, and it's already part of the lepton id. For the jets I'm not sure if it's really relevant?
Otherwise, I think we can merge #23 and launch a new production?
For muons it seems the cut on dZ is applied only for TightID. Anyway, we can plot the dZ variables in the next round and see what it gives...
Shouldn't we have a look at Top reconstruction before launching a new one?
Ah right, forgot that...
Not sure how we should do it? Using https://github.com/cms-sw/cmssw/blob/CMSSW_7_4_X/TopQuarkAnalysis/TopKinFitter/src/TtFullLepKinSolver.cc seems rather straightforward to implement.
If we want something more complicated (like a kinfit), it'll take a bit longer...
2015-11-23 17:53 GMT+01:00 Sébastien Wertz notifications@github.com:
For muons it seems the cut on dZ is applied only for TightID. Anyway, we can plot the dZ variables in the next round and see what it gives...
Shouldn't we have a look at Top reconstruction before launching a new one?
— Reply to this email directly or view it on GitHub https://github.com/cp3-llbb/TTAnalysis/issues/20#issuecomment-158994301.
Sébastien Brochet
If we simply want to compute the solutions to the system we can also take the code from MEM++, using the standard way to handle the ambiguity in the multiplicity of solutions to the system is to take the solution giving the smallest Mttbar... I can take care of it. Then of course, there's not really any kinfit involved in the FullyLept final state: all we need to do is compute O(100) solutions, smearing the b-jet energies, and doing a weighted average of the solutions (where weight = product of gaussians used to smear the bjets). This involves slightly more work since we need to do some kind of fit to get these "transfer functions". Maybe we can use the FullSim events from the previous production...
In principe, issue closed by #23, #24, #25, #26. Tanks a lot!
I'll leave this issue open since there is a couple of things that could be included at some point but are not necessary for the next production.
I'm closing this since almost everything is done (the few remaining points are addressed by #30).
t->Draw("tt_selJets[idx1].minDRjl_lepIDIso[idx2]")
works, but NOTt->Draw("tt_selJets[ tt_selJets_selID[0] ].minDRjl_lepIDIso[idx2]")
Is this a TTreeFormula issue? Stuff liket->Draw("tt_selJets[ tt_diBJets_DRCut_BWP_PtOrdered[0].jidxs.first ].p4.Pt()")
works fine...Discussion here: https://sft.its.cern.ch/jira/browse/ROOT-7757 => solved by not using TTreeFormula.