Generator Level Filters in CMSSW

Complete: 2

WARNING: UPDATE IN PROGRESS

Filtering events at generation level

If you want to select events that satisfy particular criteria at the generation level, i.e. based on the content of the HepMC event, you can do so by either using one of the existing "filters" or by writing your own dedicated one.
Such module will be of the EDFilter type. EDFilter modules are similar to EDProducers, since they can add new products into the Event, but in addition return a boolean flag that reports to the Framework if the Event passed the user-defined condition. Based on the value of the return flag, the Framework will continue or will terminate event processing in the path where the filter is included.
More information on using EDFilter's in the analysis applications can be found in the SWGuideEDFilterAnalysis.

Generator level filters

The collection of generator-level filters currently offered within CMSSW can be found in GeneratorInterface/GenFilters package.

Various filters can be combined in the event processing chain; local AND or OR combinations of them are possible.

Event filtering should be accounted for in the configuration of the PoolOutputModule, such that only events that satisfy user-applied conditions will be written out to the output.

The number of events to process in a given job is controlled by either parameter input or output in the process-level parameter set maxEvent.
In the first case, the job will run until it "sources-in" the required number of events.
In the second case, it'll run until it collects the required number of filtered events in the output.

Schematic representation of the AND combination can be illustrated as follows:

import FWCore.ParameterSet.Config as cms

process = cms.Process("TEST")
process.maxEvents = cms.untracked.PSet(
    output = cms.untracked.int32(10)
)
process.source = cms.Source("PoolSource",
    fileNames = cms.untracked.vstring('file:test.root')
)

process.filter1 = cms.EDFilter("Filter1", ...... )

process.filter2 = cms.EDFilter("Filter2", ...... )

process.USER = cms.OutputModule("PoolOutputModule",
    SelectEvents = cms.untracked.PSet(
        SelectEvents = cms.vstring('p1')
    ),
    fileName = cms.untracked.string('test_filtering.root')
)

process.p1 = cms.Path(process.filter1*process.filter2)
process.outpath = cms.EndPath(process.USER)

In this case, only events that satisfy BOTH filters will be written out by the PoolOutputModule.
Please note that, if Filter1 fails, event processing down the path p1 will terminate anyway.

Schematic representation of the OR combination can be illustrated like this:

import FWCore.ParameterSet.Config as cms

process = cms.Process("TEST")
process.maxEvents = cms.untracked.PSet(
    output = cms.untracked.int32(10)
)
process.source = cms.Source("PoolSource",
    fileNames = cms.untracked.vstring('file:test.root')
)

process.filter1 = cms.EDFilter("Filter1", ...... )

process.filter2 = cms.EDFilter("Filter2", ...... )

process.USER = cms.OutputModule("PoolOutputModule",
    SelectEvents = cms.untracked.PSet(
        SelectEvents = cms.vstring( 'p1', 'p2' )
    ),
    fileName = cms.untracked.string('test_filtering.root')
)

process.p1 = cms.Path(process.filter1)
process.p2 = cms.Path(process.filter2)
process.outpath = cms.EndPath(process.USER)

Please note that failure of either filter will not affect event processing on the other path.

In addition, please be advised that combinations like SelectEvents = cms.vstring( '!p1', 'p2' ) are also possible in the PoolOutputModule configuration. In this case, we'll accept events that fail Filter1 and satisfy Filter2.

Below we offer descriptions of 3 generic filters available within CMSSW.

Brief overview of other available filters will be added shortly.

1. Filter based on the MC "event level" information: the Pythia process ID and Pt_hat.

process.filter1 = cms.EDFilter("MCProcessFilter",
    MaxPthat = cms.untracked.vdouble(50.0, 10000.0),
    ProcessID = cms.untracked.vint32(1, 2),
    MinPthat = cms.untracked.vdouble(40.0, 0.0)
)

2. Filter based on the MC "particle level" information: the Pythia particle ID, Pt, eta, status, ...

Example use:

process.filter2 = cms.EDFilter("MCSingleParticleFilter",
    MaxEta = cms.untracked.vdouble(2.4, 2.4, 2.4, 2.4),
    Status = cms.untracked.vint32(1, 1, 1, 1),
    MinEta = cms.untracked.vdouble(-2.4, -2.4, -2.4, -2.4),
    MinPt = cms.untracked.vdouble(40.0, 40.0, 30.0, 30.0),
    ParticleID = cms.untracked.vint32(11, -11, 13, -13)
)

3. Filter based on the MC "particle level" information for particle pairs: the Pythia particle ID, Pt, P, eta, mass, deltaphi, ...

Example use:

process.filter3 = cms.EDFilter("MCParticlePairFilter",
    Status = cms.untracked.vint32(1, 1),
    MinDeltaPhi = cms.untracked.double(0.0),
    MaxDeltaPhi = cms.untracked.double(6.29),
    MinPt = cms.untracked.vdouble(40.0, 40.0),
    MinP = cms.untracked.vdouble(40.0, 40.0),
    MaxEta = cms.untracked.vdouble(2.4, 2.4),
    MinEta = cms.untracked.vdouble(-2.4, -2.4),
    ParticleCharge = cms.untracked.int32(-1),
    MaxInvMass = cms.untracked.double(1000.0),
    MinInvMass = cms.untracked.double(40.0),
    ParticleID1 = cms.untracked.vint32(11, 13),
    ParticleID2 = cms.untracked.vint32(11, 13)
)

Generator level filter efficiency

The efficiency of generator level filters cannot be evaluated after the production run from the TriggerResults product since it contains information only for events saved (being primarily thought for HLT). In order to keep the original information available at run-time a product to be filled in the EndPath at the end of the GEN step has been added since CMSSW_3_10_0_pre8: GenFilterInfo .

It is a Luminosity block product, containing the number of events originally generated and the number actually passing the generator level filters and stored permanently in the EDM file. Methods computing the efficiency and its uncertainty are provided.

A simple analyzer to dump the information from this product, GenFilterEfficiencyAnalyzer, is provided in GeneratorInterface/Core, and can be run using the example runGenFilterEfficiencyAnalyzer_cfg.py. The standard cmsDriver.py script is by default triggering the production of this object. The user has the freedom to redefine the name (through a parameter) of the Path in which the producer has to be run, for use in non standard work-flows.

Review Status

Reviewer/editor (please include date) comments
FilipMoortgat - 13 Feb 2007 Page author
JennyWilliams - 16 Feb 2007 Edited for SWGuide inclusion

Responsible: FilipMoortgat
Last reviewed by: Reviewer

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2010-12-09 - FabioCossutti



 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback