ZprimeSelectionCycle jet |eta| cut

[xerxes1986]

On l110 the cycle is looking for 2 jets with pT of at least 50 GeV. On l127 this cut is enhanced by requiring the leading jet pT to have 150 GeV. Looking closely though, the |eta| requirements are different. l110 requires 2 jets with |eta| < 2.4, while l127 requires |eta| < 2.5.

I think this is a typo and both should be 2.5. Currently, an event with a jet in the eta range 2.4-2.5 wouldn't pass the first cut. I have checked and this issue is present in our current analyses.

[dgonzal]

Am 19.11.2013 22:00, schrieb xerxes1986:

On l110 the cycle is looking for 2 jets with pT of at least 50 GeV. On
l127 this cut is enhanced by requiring the leading jet pT to have 150
GeV. Looking closely though, the |eta| requirements are different.
l110 requires 2 jets with |eta| < 2.4, while l127 requires |eta| < 2.5.

I think this is a typo and both should be 2.5. Currently, an event
with a jet in the eta range 2.4-2.5 wouldn't pass the first cut. I
have checked and this issue is present in our current analyses.

—
Reply to this email directly or view it on GitHub
#1.

hi not sure who you are,

have a look at the pass, i think the current strategy is to have jets with eta <
2.4.

http://cds.cern.ch/record/1543467/files/B2G-12-006-pas.pdf

cheers

Daniel

[xerxes1986]

This is Paul Turner. I'm with the UIC group doing the boosted semileptonic Z' search.

If this is the case then the |eta| requirement for the second cut should be changed to 2.4 for consistency. It is a small error and probably won't change much, but it can change events that have a large pT jet in the |eta| range 2.4-2.5.

[rkogler]

Hi Paul, as Daniel already wrote, we are using a requirement of |eta| <
2.4 for jets. So the second cut should be adjusted, but it's not going
to have an effect since we already cut on 2.4 in the previous step. In
fact, maybe we should also do the jet cleaning for 2.4 instead of 2.5
(line 283 in ZprimeSelectionCycle). This will not have a large effect,
but we should be consistent with what we write in the AN (and PAS).

[xerxes1986]

I agree, consistency is important. Should we consider using package wide #DEFINEs to define these "hard-coded" cuts and limits instead of coding them by hand?

[rkogler]

Hi Paul,
in my opinion, using #DEFINE statements is against everything object
oriented programming stands for. This would hurt the readability of the
code, make debugging much harder and make the code harder to maintain.
In our specific case it's somtimes necessary to keep objects with looser
selection criteria in an event than what we cut on later (for example,
we want to store all jets with pt > 30 GeV, but then we cut on pt_jet1 >
150 GeV and pt_jet2 > 50 GeV). So it can be quite useful to have
different values in the cleaners than in the selection modules.

If you want to have all cuts and selections defined in one place, you
could write a class which knows about all cuts (pt_jet1, pt_jet2,
eta...). You could even make it a singleton to make sure that only one
object exists at a time, such that any change in a cut is propagated
through correctly. Instead of using hard coded values in the selectors
and cleaners, you would just ask this class what the appropriate cuts are.

On 11/25/13 18:27, Paul Turner wrote:

I agree, consistency is important. Should we consider using package
wide #DEFINEs to define these "hard-coded" cuts and limits instead of
coding them by hand?

—
Reply to this email directly or view it on GitHub
#1 (comment).