Trigger Masks for jobs running in the Monitoring Farm

Using TriggerMask and VetoMask based selections you can "tune" your monitoring task. Require the bit to be set in the trigger mask and veto whatever else you do not want to see.

The first three 32-bit words of the trigger mask (i.e. 96 bits in total) are reserved for the HLT, the fourth word is reserved for use by the buffer manager.


  • The triggermask is OR'ed. Hence any matching bit set in the 4 words leads to TRUE; ie. you will see this event.
  • The vetomask is AND'ed. Any set bit matching leads to FALSE; ie. you will not see this event.
  • vetomask and triggermask requirements must both be fulfilled.


In order to NOT trigger your monitoring task on Lumi events you should apply the following trigger/veto masks to your event selector request:

EventSelector.REQ1 = "EvType=2;TriggerMask=0x0,0x4,0x0,0x0;VetoMask=0,0,0,0x700;MaskType=ANY;UserType=USER;Frequency=PERC;Perc=100.0";

In the TriggerMask bit34 (= the 3rd bit of second 32-bit word = 0x0,0x4,0x0) means that also something else (besides Lumi decision) triggered the event (i.e. routing bit 34 = not exclusive lumi). This is normally exactly what monitoring jobs want.

The TriggerMask setting can be obtained from the desired routing bit as follows: 0x4 = 4 = 2**(34-32). For Hlt2 physics (=routing bit 77): 0x2000=8192=2**13=2**(77-64).

The same is obtained (and is easier to read) by setting 0x0,0x1 << (34-32),0x0 or 0x0,0x0,0x1 << (77-64).

To do the OR of two bits, do this:

from Configurables import  HltRoutingBitsFilter
filter = HltRoutingBitsFilter('CharmFilter', RequireMask = [0x0, (0x1<<(42-32) ) | (0x1<<(55-32)),0x0,0x0] )  ]


Monitoring tasks processing raw event data should set in the VetoMask the 4th. word to 0x700 to avoid
  • reconstructed events (0x100),
  • HLT timeouts (0x200, does not yet work) and
  • access violations (0x400).

Reconstructed events

For FEST and LHCb we also route reconstructed events to the monitoring farm for high level (track-based) monitoring applications. These events end in the same buffer as the raw data events.

To avoid picking these events up you have to adjust the requirements option of the online event selector and veto the reconstructed events. You have to use the following VetoMask:

EventSelector.REQ1 = "EvType=2;TriggerMask=0xffffffff,0xffffffff,0xffffffff,0xffffffff;VetoMask=0,0,0,0x100;MaskType=ANY;UserType=USER;Frequency=PERC;Perc=100.0";

Currently the bits in the 4rth word of the VetoMask have the following meaning:

0x1: Bit set for all raw events (normal channel) 0x10: Bit set for the express stream 0x100: Bit set for reconstructed events

===> You must mask out at least 0x100 in the forth word of the veto mask.


TriggerMask=0xffffffff,0xffffffff,0xffffffff,0x11 VetoMask=0,0,0,0xffffffee ==> Selects raw and express stream events: 0xffffffee = ~0x0 - 0x10 - 0x1

TriggerMask=0xffffffff,0xffffffff,0xffffffff,0x1 VetoMask=0,0,0,0xfffffffe ==> Selects raw stream only (ignores express stream!): 0xfffffffe = ~0x0 - 0x1

TriggerMask=0xffffffff,0xffffffff,0xffffffff,0x100 VetoMask=0,0,0,0xfffffeff ==> Selects reconstructed events only: 0xfffffeff = ~0x0 - 0x100

TriggerMask=0,0,0,0x10 VetoMask=0,0,0,0xffffffee ==> Selects express stream only: 0xffffffee = ~0x0 - 0x10 - 0x1 Note: express stream has 0x10 AND 0x1; hence need to narrow using trigger mask as well....

-- EricvanHerwijnen - 24-Apr-2011

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2011-09-12 - EricvanHerwijnen
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback