search

NWUHEP / ntupleProducer

Northwestern ntuplizer tools for use with CMSSW.
https://twiki.cern.ch/twiki/bin/view/CMS/UserCodeNWUntupleProducer
4 stars 4 forks source link

Check the bool for tracking POG filters #32

Closed andreypz closed 10 years ago

andreypz commented 10 years ago

We may need to reverse the boolean for tracking filters. From the noise filters twiki, https://twiki.cern.ch/twiki/bin/viewauth/CMS/MissingETOptionalFilters _For the three tracking POG filters, there are example configurations of the "taggingMode" in the above mentioned python file exampleICHEPrecommendationcfg.py. One thing to be made clear is that the stored boolean for the three tracking POG filters is the opposite to what we usually have for other filters. Specifically, for the tracking POG filters, true means rejected bad events while false means good events.

Also someone have to check the effect of those filters on the most common datasets. Do they matter at all?

andreypz commented 10 years ago

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

naodell commented 10 years ago

So do they matter?

On Sat, Jul 12, 2014 at 2:01 PM, Andrey Pozdnyakov <notifications@github.com

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 https://github.com/NWUHEP/ntupleProducer/issues/32#issuecomment-48820937 .

andreypz commented 10 years ago

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...

pollackscience commented 10 years ago

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

andreypz commented 10 years ago

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?)

naodell commented 10 years ago

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 <notifications@github.com

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 https://github.com/NWUHEP/ntupleProducer/issues/14: in data: 665; in signal MC: 3.34 Cut #15 https://github.com/NWUHEP/ntupleProducer/issues/15: in data: 663; in signal MC: 3.33 Cut #16 https://github.com/NWUHEP/ntupleProducer/issues/16: in data: 624; in signal MC: 3.33 Cut #17 https://github.com/NWUHEP/ntupleProducer/issues/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 .

naodell commented 10 years ago

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

On Sun, Jul 13, 2014 at 6:40 PM, Nathaniel Odell naodell@gmail.com 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 < notifications@github.com> 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 https://github.com/NWUHEP/ntupleProducer/issues/14: in data: 665; in signal MC: 3.34 Cut #15 https://github.com/NWUHEP/ntupleProducer/issues/15: in data: 663; in signal MC: 3.33 Cut #16 https://github.com/NWUHEP/ntupleProducer/issues/16: in data: 624; in signal MC: 3.33 Cut #17 https://github.com/NWUHEP/ntupleProducer/issues/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 .

andreypz commented 10 years ago

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

On Sun, Jul 13, 2014 at 6:50 PM, Nate Odell notifications@github.com wrote:

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

On Sun, Jul 13, 2014 at 6:40 PM, Nathaniel Odell naodell@gmail.com 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 < notifications@github.com> 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 https://github.com/NWUHEP/ntupleProducer/issues/14: in data: 665; in signal MC: 3.34 Cut #15 https://github.com/NWUHEP/ntupleProducer/issues/15: in data: 663; in signal MC: 3.33 Cut #16 https://github.com/NWUHEP/ntupleProducer/issues/16: in data: 624; in signal MC: 3.33 Cut #17 https://github.com/NWUHEP/ntupleProducer/issues/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 https://github.com/NWUHEP/ntupleProducer/issues/32#issuecomment-48855466 .