pkgs/Filter (NOvA offline)

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.


The 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:

<node module="Filter" config="default" reco="1" ana="0"/>
The filters that are defined presently are listed below. The format of the table is this:
FilterName -- General filter description
config1 description of config1
config2 description of config2
And here's the table:
DummyFilter -- Passes everything. Takes no parameters.
"default" only possible configuration
CellHitLimits -- Looks in a specified folder and counts the CellHits. Passes the event if the count falls in a specified range.
"CellHitLimits" Looks in "Hits" folder of Cal() branch and requires CellHit count to fall in [30,99999]
VerticesInDetector -- Requires the number of true MC neutrino vertices in the detector volume to be in a specified range.
"VerticesInDetector" Requires from 1 to 9999 vertices.
EventListFromFile -- Requires that the event/run number combo be present in the list specified via text file.
"EventListFromFile" Looks in file evtlist.txt for "eventnum runnum" entries to keep.

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., IntPars, StringPars, DoublePars). And, be sure to add your new filter to the above table.