Hlt Trigger Selection Naming Convention

The following naming convention applies to strings used to identify Trigger Selections which may get saved in HltSummary.

Since in Hlt1 all algorithms inheriting from HltAlgorithm class are automatically saveable in HltSummary under the name of the instance of the algorithm, this convention does apply to the names of these algorithms.

In Hlt2 the names under which the selection outputs are saved in HltSummary are not automatically tied to the names of the algorithms. Thus, we do not impose any restrictions on algorithm names in Hlt2. However, it is strongly recommended that the name of the instance of the Hlt2 algorithm appears in the middle of the identification string used in the HltSummary.

Prefix identifying trigger level

All trigger selection names must start with either "L0", "Hl1", "Hlt2" or "Hlt". Only the first letter should be capitalized in the prefix. The first letter following the prefix should be capital and should not be a number.

The "L0" prefix is reserved for selections containing respresentations of L0 objects in Hlt-selection format.

The "Hlt1" prefix identifies all selections which can be created only in Hlt1 step, except for representations of L0 objects (see above).

The "Hlt2" prefix identifies all selections which can be created only in Hlt2 step.

Selections of algorithms which can be executed either in Hlt1 or Hlt2 steps should start with "Hlt".

Postfix identifying final selections at given trigger level

To identify trigger selections which are responsible for final decision to keep event after given trigger level from intermediate ones, every final selection name should end with "Decision". The "Decision" string should not appear anywhere within names of intermediate selections.

If you use HltSelectionFilter which takes an OR between a subset of final selections, you should not be ending a name of such selection with "Decision", since the decision to keep event has been already make. Call it something else and put "SF" in the name (see below).

Thus the triggers (i.e. final trigger selection names) will be:

  • "L0xxxDecision" where "xxx" is the name of L0 trigger channel ("Muon", "DiMuon", "MuonNoGlob", "Hadron", "Electron", "Photon", "LocalPi0", "GlobalPi0").

  • "Hlt1xxxDecision" where "xxx" is the name of an alley (see below for recommended structure)

  • "Hlt2xxxDecision" where "xxx" is the name of Hlt2 algorithm which produced final selection.

Recommendations for naming Hlt1 selections

Each part of the name must start with capital letter and is allowed to contain other capitalized letters in the middle (to make it more readable).

The first part of the name following the "Hlt1" prefix should identify family (i.e. "alley") of triggers e.g. "Hadron", "Muon", "MuTrack" etc. The subsequent parts should indetify sub-families ("sub-alleys") if any.

Once the individual Hlt1 trigger line is identified, you should identify algorithm corresponding to the generic Hlt algorithm you use:

  • HltTrackFilter -> "TF"
  • HltVertexFilter -> "VF"
  • HltSelectionFilter -> "SF"
  • HltTrackUpgrade -> "TU"
  • HltVertexUpgrade -> "VU"
  • HltVertexMaker -> "VM"
  • HltL0Filter -> "L0"

The filter algorithm will usually be followed by the name of track/vertex it operated on e.g. ""RZVelo", "Velo", "Forward", "L0MuonDecision" etc. For example "Hlt1HadronSingleTFRZVelo".

The upgrade algorithm will usually be followed by the name of reconstruction step: "Velo", "Forward" etc. For example "Hlt1HadronSingleTUVelo".

The selections making final decisions are exempt from identifying algorithm/object type they use to make the decision. For example "Hlt1HadronSingleDecision" is a HltTrackFilter.

Entry selections, usually based on L0 trigger criteria (HltL0Filter), can be shared among alleys, thus are just named: "Hl1L0XXX" where XXX is L0 trigger name for single condition (e.g. "Hlt1L0Muon"). For more complex entry points use descriptive name (e.g. "Hlt1L0MuonORMuonNoGlob"). Note that, because each alley is supposed to be able to run independent of the others )eg. all others might be switched off, or prescaled for a given event), one must add the entry selection, using the shared name to avoid duplicating the algorithm and to insure it executes at most once for a single event, at the beginning of each individual alley.

input and output properties of selection algorithms

Note that soon we will enforce the rule that an algorithms will have the following convention for the properties that define their in- and output: The name of output selections is specified by the property 'OutputSelection', which defauts to the name of the algorithm. In case the algorithm has a single input selection, it is specified by 'InputSelection', and this In case the algorithm has N input selections, their names are 'InputSelection1','InputSelection2',...,'InputSelectionN'. In the last two cases, each property must be set explicitly. Not doing so will result in an error. In case the algorithm has a variable number of input selections, the property is 'InputSelections', which is vector of strings.

-- TomaszSkwarnicki (with input from Jose) - 20 Jun 2008, 01 Jul 2008 -- GerhardRaven - 22 Jul 2008

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2008-07-22 - GerhardRaven
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb 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