AttributeError, 'jet' has no attribute 'mcJet'

[TaiSakuma]

The AttributeError occurs at L449 in the method smearJets() because some jets don't have the attribute mcJet.

The attribute 'mcJet' is attached to jet at L443 in the method matchJets().

At L169, matchJets() called with only selected jets but, at L171, smearJets() is called with all jets.

Therefore, some jets don't have mcJet and causes the AttributeError.

[Xtian9]

Can we just apply matchJets() to all jets (as was done before), it's good to have this information for jets below threshold too.

cmg-cmssw/PhysicsTools/Heppy/python/analyzers/objects/JetAnalyzer.py

Line 168 in ebe350c

# self.matchJets(event, allJets)

[arizzi]

...or set mcJet to None for all jets, or use getattr with default in smearJets... matching takes time, so avoiding running it for low pt jets makes sense...

[arizzi]

..or even smear only jets above cut ...

[gpetruc]

I don't think it's correct to smear only the jets above the cut, as you'll loose jets that get smeared down (if you re-cut on the pt afterwards) but not gain jets that get smeared up.

IMHO the previous implementation, matching for all jets, made more sense, maybe @mmasciov can explain why the change.

If there's a good reason for the change, then in case smearing is applied one should first match on all jets, then smear, and then re-match.

[mmasciov]

We did this for two reasons:

1. to reduce time (we do not run the smearJet
2. to avoid that for a 1-1 angular matching of reco jets and genJets you can have a genJet matched to a reco jet with very low pT, likely to be a PU jet for instance

I think a way to fix this is to add an option to the module:
if doMatchingWithThreshold and not doSmear, then apply threshold on reco jets, otherwise run matching on all jets, which would be the default. This way one would be able to run the matching and not the smearing, without running twice the matching.
I'll implement this and open a PR if you agree.

[gpetruc]

The matching is done with matchObjectCollection2, which does the uniqueness
by iteratively picking the best pair of objects, locking them, and
repeating for the rest.
Since jets can't be arbitrarily close-by, I think your case (2) shouldn't
happen if there's a good reco jet - what could instead happen is that the
reco objects are clustered differently and a single gen jet is split into
two reco jets, and then the matcher will pick the closest of the two in
direction and not the closest in pt, but I don't think there's really a
best option in this case, one just has to leave with the fact that jet
clustering can sometimes converge to different final states for small but
finite initial state differences (that's why e.g. to tag fake jets in reco
one may be better off by adding up the visible gen particles in a cone
around the reco jet rather than doing matching).
My fear is that (2) may instead happen if you apply the cut before
matching: with the cut, it can happen that the closest reco jet to the gen
jet is below the cut, so the gen jet may end up matched to a pile-up or
fake jet if that's above the cut (since that PU or fake jet will not have a
gen jet of its own that would otherwise give a better match).

On Thu, May 26, 2016 at 6:09 PM, mmasciov [email protected] wrote:

We did this for two reasons:

1. to reduce time (we do not run the smearJet
2. to avoid that for a 1-1 angular matching of reco jets and genJets you
   can have a genJet matched to a reco jet with very low pT, likely to be a PU
   jet for instance

I think a way to fix this is to add an option to the module:
if doMatchingWithThreshold and not doSmear, then apply threshold on reco
jets, otherwise run matching on all jets, which would be the default. This
way one would be able to run the matching and not the smearing, without
running twice the matching.
I'll implement this and open a PR if you agree.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#640 (comment)