Check the bool for tracking POG filters about ntupleproducer HOT 8 CLOSED

This is now fixed at dev-andrey. Will propagate to master in the next merge.

from ntupleproducer.

So do they matter?

On Sat, Jul 12, 2014 at 2:01 PM, Andrey Pozdnyakov <[email protected]

wrote:

This is now fixed at dev-andrey. Will propagate to master in the next
merge.

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

from ntupleproducer.

Actually, yes, it looks like they matter.
In my analysis, after the final selection I get:
Before filters in data: 665; in signal MC: 3.34
After filters in data: 624; in signal MC: 3.28
This is all filters applied together, will need to investigate which ones actually cut events...

from ntupleproducer.

Be careful, some of the filters will veto events due to MET or other nonsense that does not affect the relevant subdetectors for your selection

from ntupleproducer.

An update on this.
First giving a snippet I use in my analyzer:

 if (NoiseFilters_isScraping || NoiseFilters_isNoiseHcalHBHE || NoiseFilters_isNoiseHcalLaser)
    return kTRUE;
  CountEvents(14);

 if (NoiseFilters_isNoiseEcalTP || NoiseFilters_isNoiseEcalBE || NoiseFilters_isNoiseEEBadSc)
    return kTRUE;
  CountEvents(15);

  if (NoiseFilters_isCSCTightHalo || NoiseFilters_isCSCLooseHalo)
    return kTRUE;
  CountEvents(16);

  if (NoiseFilters_isNoiseTracking ||
      !NoiseFilters_isNoisetrkPOG1 || !NoiseFilters_isNoisetrkPOG2 || !NoiseFilters_isNoisetrkPOG3)
    return kTRUE;
  CountEvents(17);

The results for my analysis are the following:
Before the filters I get in data: 665; in signal MC: 3.34
Cut 14: in data: 665; in signal MC: 3.34
Cut 15: in data: 663; in signal MC: 3.33
Cut 16: in data: 624; in signal MC: 3.33
Cut 17: in data: 624; in signal MC: 3.28

That is Hcal noise don't filter nothing, Ecal noise filters a little bit,
most events are cut by CSC-Halo filters. What the hell are those?
Trk POG are not important in that order (but maybe they would cut events if placed first?)

from ntupleproducer.

This is good to see, Andrey. I think I'll check to see if it has any
effect with my selection, too since I might be sensitive to these events.
I think the halo filters might have something to do with muons produced
outside the detector possibly because of a degradation of the vacuum in the
beam pipe. Just a guess.

Shouldn't the tight halo filter cover the loose, though? I was using the
tight at some point, but removed it.

On Sun, Jul 13, 2014 at 6:25 PM, Andrey Pozdnyakov <[email protected]

wrote:

An update on this.
First giving a snippet I use in my analyzer:

if (NoiseFilters_isScraping || NoiseFilters_isNoiseHcalHBHE || NoiseFilters_isNoiseHcalLaser)
return kTRUE;
CountEvents(14);

if (NoiseFilters_isNoiseEcalTP || NoiseFilters_isNoiseEcalBE || NoiseFilters_isNoiseEEBadSc)
return kTRUE;
CountEvents(15);

if (NoiseFilters_isCSCTightHalo || NoiseFilters_isCSCLooseHalo)
return kTRUE;
CountEvents(16);

if (NoiseFilters_isNoiseTracking ||
!NoiseFilters_isNoisetrkPOG1 || !NoiseFilters_isNoisetrkPOG2 || !NoiseFilters_isNoisetrkPOG3)
return kTRUE;
CountEvents(17);

The results for my analysis are the following:
Before the filters I get in data: 665; in signal MC: 3.34
Cut #14 #14: in data:
665; in signal MC: 3.34
Cut #15 #15: in data:
663; in signal MC: 3.33
Cut #16 #16: in data:
624; in signal MC: 3.33
Cut #17 #17: in data:
624; in signal MC: 3.28

That is Hcal noise don't filter nothing, Ecal noise filters a little bit,
most events are cut by CSC-Halo filters. What are hell are those?
Trk POG are not important in that order (but maybe they would cut events
if placed first?)

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

from ntupleproducer.

Actually, you have some special cuts for your trailing muon, no?

On Sun, Jul 13, 2014 at 6:40 PM, Nathaniel Odell [email protected] wrote:

This is good to see, Andrey. I think I'll check to see if it has any
effect with my selection, too since I might be sensitive to these events.
I think the halo filters might have something to do with muons produced
outside the detector possibly because of a degradation of the vacuum in the
beam pipe. Just a guess.

Shouldn't the tight halo filter cover the loose, though? I was using the
tight at some point, but removed it.

On Sun, Jul 13, 2014 at 6:25 PM, Andrey Pozdnyakov <
[email protected]> wrote:

An update on this.
First giving a snippet I use in my analyzer:

if (NoiseFilters_isScraping || NoiseFilters_isNoiseHcalHBHE || NoiseFilters_isNoiseHcalLaser)
return kTRUE;
CountEvents(14);

if (NoiseFilters_isNoiseEcalTP || NoiseFilters_isNoiseEcalBE || NoiseFilters_isNoiseEEBadSc)
return kTRUE;
CountEvents(15);

if (NoiseFilters_isCSCTightHalo || NoiseFilters_isCSCLooseHalo)
return kTRUE;
CountEvents(16);

if (NoiseFilters_isNoiseTracking ||
!NoiseFilters_isNoisetrkPOG1 || !NoiseFilters_isNoisetrkPOG2 || !NoiseFilters_isNoisetrkPOG3)
return kTRUE;
CountEvents(17);

The results for my analysis are the following:
Before the filters I get in data: 665; in signal MC: 3.34
Cut #14 #14: in data:
665; in signal MC: 3.34
Cut #15 #15: in data:
663; in signal MC: 3.33
Cut #16 #16: in data:
624; in signal MC: 3.33
Cut #17 #17: in data:
624; in signal MC: 3.28

That is Hcal noise don't filter nothing, Ecal noise filters a little bit,
most events are cut by CSC-Halo filters. What are hell are those?
Trk POG are not important in that order (but maybe they would cut events
if placed first?)

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

from ntupleproducer.

Not so special really, Combination of Loose and Soft Muon-ID,
pt > 4GeV

On Sun, Jul 13, 2014 at 6:50 PM, Nate Odell [email protected]
wrote:

Actually, you have some special cuts for your trailing muon, no?

On Sun, Jul 13, 2014 at 6:40 PM, Nathaniel Odell [email protected]
wrote:

This is good to see, Andrey. I think I'll check to see if it has any
effect with my selection, too since I might be sensitive to these events.
I think the halo filters might have something to do with muons produced
outside the detector possibly because of a degradation of the vacuum in
the
beam pipe. Just a guess.

Shouldn't the tight halo filter cover the loose, though? I was using the
tight at some point, but removed it.

On Sun, Jul 13, 2014 at 6:25 PM, Andrey Pozdnyakov <
[email protected]> wrote:

An update on this.
First giving a snippet I use in my analyzer:

if (NoiseFilters_isScraping || NoiseFilters_isNoiseHcalHBHE ||
NoiseFilters_isNoiseHcalLaser)
return kTRUE;
CountEvents(14);

if (NoiseFilters_isNoiseEcalTP || NoiseFilters_isNoiseEcalBE ||
NoiseFilters_isNoiseEEBadSc)
return kTRUE;
CountEvents(15);

if (NoiseFilters_isCSCTightHalo || NoiseFilters_isCSCLooseHalo)
return kTRUE;
CountEvents(16);

if (NoiseFilters_isNoiseTracking ||
!NoiseFilters_isNoisetrkPOG1 || !NoiseFilters_isNoisetrkPOG2 ||
!NoiseFilters_isNoisetrkPOG3)
return kTRUE;
CountEvents(17);

The results for my analysis are the following:
Before the filters I get in data: 665; in signal MC: 3.34
Cut #14 #14: in data:
665; in signal MC: 3.34
Cut #15 #15: in data:
663; in signal MC: 3.33
Cut #16 #16: in data:
624; in signal MC: 3.33
Cut #17 #17: in data:
624; in signal MC: 3.28

That is Hcal noise don't filter nothing, Ecal noise filters a little
bit,
most events are cut by CSC-Halo filters. What are hell are those?
Trk POG are not important in that order (but maybe they would cut events
if placed first?)

Reply to this email directly or view it on GitHub
<
https://github.com/NWUHEP/ntupleProducer/issues/32#issuecomment-48854916>
.

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

from ntupleproducer.