Filter provides user-defined light-weight event filters to streamline offline analysis work. When
Filter is inserted into your job sequence, only those events passing certain conditions make it through to the rest of the job (including output).
A few filters are defined already. Users are encouraged to add their own filter definitions and commit them to the repository.
Filter package provides the
Filter module. Configuration(s) are provided in
Filter.xml. You likely do not want the default configuration, but I use it here to show an example usage:
The filters that are defined presently are listed below. The format of the table is this:
<node module="Filter" config="default" reco="1" ana="0"/>
|FilterName -- General filter description|
|config1||description of config1|
|config2||description of config2|
|"default"||only possible configuration|
|"CellHitLimits"||Looks in "
|"VerticesInDetector"||Requires from 1 to 9999 vertices.|
|"EventListFromFile"||Looks in file
Adding new configurations for existing filters
The default configurations for each filter shares its name with the filter. Imagine you find yourself always asking for events with 500 or more CellHits. You could define a new configuration named "CellHitLimits_500up" (or similar) in Filter.xml and commit this to CVS. Then, someone could use your filter configuration simply by specifying:
<node module="Filter" config="CellHitLimits_500up" reco="1" ana="0"/>
If you commit new configurations, be sure to add them to the above table.
Adding new filter types
If you have a different condition you'd like to filter on, you can add a new class of filter. Simply open up Filter.xml, Filter.h, and Filter.cxx and follow the templates and examples you see there. It is fairly straightforward. Ideally, you would do this for any filtering condition that is (1) generally useful and (2) code-able in a simple subroutine (a few dozen lines of code at most). Anything more complicated might deserve its own package.
Each filter type can take parameters of type string, integer, or double. What the filter does with its parameters will depend on the filter. If your new filter doesn't need all of these types, simply leave them out of the XML and indicate this in the Config() method in Filter.cxx. Be sure to document the parameters you do require in the XML, since the names are generic (i.e.,
DoublePars). And, be sure to add your new filter to the above table.