Goodruns
Introduction
As data is recorded all sorts of issues may appear which might make data more or less appropriate to use for specific purposes. For example, if a run has excessive noise in the tracker, it might not be good for physics analysis, but would be fine for calorimeter cosmics calibration.
This system has two parts. The first part allows the experiment to set bits for each run, defining if the data passed or failed certain criteria. These bits need to be defined and labeled, but it is simple to create new ones as needed. This page does not address what bits will be used, since that is topic for operations. These daily records can be converted into a list of runs which pass certain criteria for a certain purpose (analysis, calibration, studies). These good run lists are the second function of the system. The resulting good run list can then be used to filter or select good data. Arbitrary good run lists can be created and used.
Recording status with bits
Interactions with the database are by an exe called grlTool, which is available with Offline and has a help.
The bit record consist of words, and bits assigned inside each word. The name of each word is categories:
category/subcategory/name
for example
DAQ/DQM/tracker Ops/shift/tracker Pass1/DQM/calo Analysis/eplus/efficiencies
A word can be defined
grlTool define-word DAQ/DQM/tracker "auto entry from DQM end run"
and then for each word, bits can be defined and labeled.
grlTool define-bit DAQ/DQM/tracker noise "more than 5% noise hits" grlTool define-bit DAQ/DQM/tracker badnoise "more than 10% noise hits" grlTool define-bit DAQ/DQM/tracker badROC "ROCs were misconfigured" grlTool define-bit DAQ/DQM/tracker running "the tracker was active and triggered no readout errors or trips"
Word and bit definitions are permanent, obsolete bits can be ignored. The database is recording an actual bit field to attach to the bit name for this word. As shown later, bits can have a positive sense or a negative sense, i.e. you want to require the bit on to be a good run, or reject the run if the bit is set. Once bits have been defined, they can be set:
grlTool set-word 103001 DAQ/DQM/tracker running noise
This example sets the two specified bits of the given word. If there was a previous entry for this word and this run, the old entry will be retired and this value will replace it. Since words are replaced, and not additive, there would typically only be one set-bit command for a given word for a given run. The run field can be a single run, a run range, and may include subruns as boundaries. The syntax is the same as for the conditions IoVs
The above entries all have corresponding print routines.
Selecting on bits
Conceptually, the process of analyzing bits could be arbitrarily complex. Here we provide a quick and simple selection syntax which should meet the most common needs. Create a file of selections, which can be to require a bit or to reject a bit:
# my selection REQUIRE DAQ/DQM/tracker running REJECT DAQ/DQM/tracker badnoise badROC
and then run the selection. The final optional int say to start with only runs of this type.
grlTool gen-list mysel.txt 7
Good run lists
The good run lists themselves are just lists of run intervals. The list could be created by gen-list, by hand, or some combination. The list has a given name, which can be declared
grlTool create-list forNtupling_0
and add runs to the list
grlTool extend-list forNtupling_1 103100-103200
then lock it, for example, to define a list for an analysis period
grlTool lock-list forNtupling_0
and there are print routines.
Additional functions
There is a module which will filter events based on a goodrun list in the database, Filters/src/GoodRunFilter_module.cc
The goodruns can be accessed in any code linked to Offline, so several bits or goodrun list status could be added to ntuples.
A future functionality would be to provide a script which takes a dataset and outputs a subset of the files which contain the data indicated by a given goodrun list.