Common Tools Trigger Utility Class
__GenericTriggerEventFlag__

Complete: 5

TIP This documentation refers to CommonTools/TriggerUtils V00-03-06 (CMSSW_5_2_X)
Older releases, incl. those with CommonTools/RecoUtils or DQM/TrackerCommon, are found in the release notes.

Introduction

Since the definitions of streams, primary datasets (PDs) or skims do not always correspond to the definition of events, which are desired for code being executed in EDM modules, filtering mechanisms have to be applied to reject unwanted events. However, sometimes EDFilters cannot be applied before the execution of a modules, since they would break a whole CMSSW path instead of only skipping a certain module. The solution offered here is a utility class, which is called from within a given module and determines if the module should be executed or not. By this approach, the path execution remains unaffected.

The utility class is called from within the event-wise EDM module method (e.g. analyze([...])) by means of a boolean function. The return value offers the opportunity to decide what should be done. The most common use case is that the module does this as first action in an event and returns immediately on a false without executing any further code.

The decision of the utility class is determined on the basis of its configuration within the EDM module's configuration. It is no EDM module (plug-in) and has no own configuration in the CMSSW job.
In case the according configuration is missing, the utility class returns a true immediately and acts by this as if it has not been called at all. This behavior guarantees backward compatibility fo the usage of old configuration files.

For Users

This section describes, how to use the utility class and its filter with an CMSSW package, where it already has been incorporated. The incorporation itself is described here.

For the installation, follow the recipes given for the CMSSW package you are working with.

Configuration Location

The configuration of the applied filters can be located as follows:

  • directly in the configuration of the EDM module;
  • separately in a configuration file fragment (*_cff.py) by a cms.PSet and then imported into the configuration of the EDM module. This can be a centrally maintained *_cff.py as well as an individual one per e.g. sub-system;
  • by subsequent definition of the needed configuration parameters in any configuration file, which has access to the EDM module's configuration, e.g. by importing it. This is supported by a tolerance of the utility class against missing configuration parameters, so that they do not need to be defined in all cases.
    TIPThis is the recommended approach.

Configuration Parameters

This section explains the meaning and usage of the filter's configuration parameters. The filter's behaviour in case of certain configuration values is described here.

General

  • cms.bool andOr:
    specifies the logical combination of the single filters' (L1, HLT and DCS) decisions at top level;
    ==False== ≡ AND,
    ==True== ≡ OR.
    It also defines the return values of the sub-filters in case of missing configurations by its neutral element, which is (NOT andOr).
    A neutral element of a logical junctor is the element, which does not change the logical expression, if it is added using this junctor. By letting the sub-filters return the according neutral element to the junctor defined by andOr, they act as if they do not exist. So, the return values are:
    • andOr = FalseAND ⇒ neutral element is TrueNOT andOr
      (adding ([...] AND TRUE) to a logical expression does not change its value);
    • andOr = TrueOR ⇒ neutral element is FalseNOT andOr
      (adding ([...] OR FALSE) to a logical expression does not change its value).

  • cms.string dbLabel (optional):
    specifies the label under which the DB payload is available from the ESSource or Global Tag
    • default: "" (no label used)
      ALERT! This default needs an es_prefer in the configuration, if an ESSource is used together with a Global Tag.
      ALERT! The default points to the trigger bits used in AlCa production at Tier0, when used with a Global Tag without an own ESSourse. Individual configurations need an own DB label, which has to be agreed upon with the Global Tag responsibles, since it has to be set up in the creation of the Global Tag.

  • cms.uint32 verbosityLevel (optional):
    specifies the amount of output:
    • 0: complete silence (default), needed for T0 processing;
    • 1: only LogError;
    • 2: LogError and LogWarnings, recommended for testing.

DCS filter (scalers)

  • cms.InputTag dcsInputTag:
    !InputTag of the DCS scalers collection
    ALERT!The default value is "scalersRawToDigi". Do not change it, if you do not know exactly, what you are doing!

  • cms.vint32 dcsPartitions:
    Lists the DCS partitions, which should have been ON in the event. DCS partition numbers can be found in the enum definition in DataFormats/Scalers/interface/DcsStatus.h.
    An empty vector lets the filter return the neutral element as explained here (switched off).

  • cms.bool andOrDcs:
    specifies the logical combination of the single DCS filters' decisions;
    ==False== ≡ AND,
    ==True== ≡ OR.
    In case it is missing, the DCS filter will not be executed and returns the neutral element of the general andOr configuration parameter setting (s. there). By this, it has no effect on the event selection.

  • cms.bool errorReplyDcs:
    specifies the desired return value of the DCS filter and the single DCS partition filter in case of certain errors as described here.

GT filter

  • cms.InputTag gtInputTag:
    !InputTag of the GT status bits collection
    ALERT!The default value is "gtDigis". Do not change it, if you do not know exactly, what you are doing!

  • cms.InputTag gtEvmInputTag (optional):
    !InputTag of the extended GT status bits collection
    ALERT!The default value is "gtEvmDigis". Do not change it, if you do not know exactly, what you are doing!

  • cms.string gtDBKey (optional):
    Tag of the record in the database, where IOV-based GT status bits are found. This record overwrites the configuration parameter gtStatusBits.
    ==gtStatusBits== remains valid if:
    • gtDBKey is not present (database access switched off);
    • database access fails.

  • cms.vstring gtStatusBits:
    Lists logical expressions of GT status bits, which should be set in the event. Negation is supported by a prefixing a '~' to any element of the vector..
    An empty vector lets the filter return the neutral element as explained here (switched off).
    ALERT! There is no common, resp. official naming or numbering of GT status bits so far. They are defined here by meaningful names for the time being. Available GT status bits are (self-explanatory):
    • Detector status:
      • PhysDecl or
        PhysicsDeclared;
    • Beam status:
      TIP The beam status bits are hierarchically ordered and include higher levels. E.g. asking for Sqeeze will automatically include Adjust and Stable.
      • Stable or
        StableBeam;
      • Adjust;
      • Sqeeze;
      • Flat or
        FlatTop;
    • Beam momentum:
      • 8TeV;
      • 7TeV;
      • 2360GeV;
      • 900GeV.

  • cms.bool andOrGt:
    specifies the logical combination of the single GT status bits;
    ==False== ≡ AND,
    ==True== ≡ OR.
    In case it is missing, the GT filter will not be executed and returns the neutral element of the general andOr configuration parameter setting (s. there). By this, it has no effect on the event selection.

  • cms.bool errorReplyGt:
    specifies the desired return value of the GT filter and the single GT status bits in case of certain errors as described here.

L1 filter

  • cms.string l1DBKey (optional):
    Tag of the record n the database, where IOV-based L1 algorithms are found. This record overwrites the configuration parameter l1Algorithms.
    ==l1Algorithms== remains valid if:
    • l1DBKey is not present (database access switched off);
    • database access fails.

  • cms.vstring l1Algorithms:
    Lists logical expressions of L1 algorithms, which should have accepted the event. Negation is supported by a prefixing a '~' to any element of the vector. L1 algorithm names can be found via the L1 menues (pick out the menu you need).
    An empty vector lets the filter return the neutral element as explained here (switched off).
    ALERT! L1 trigger bit numbers are not supported to avoid confusion between physics algorithms' and technical trigger bits.
    ALERT! Wild-cards are enabled for L1 algorithm names.
    The usage of the '*' character will expand to all matching L1 algorithm names available in the menu, connected by OR in brackets.

  • cms.bool andOrL1:
    specifies the logical combination of the single L1 algorithms' decisions;
    ==False== ≡ AND,
    ==True== ≡ OR.
    In case it is missing, the L1 filter will not be executed and returns the neutral element of the general andOr configuration parameter setting (s. there). By this, it has no effect on the event selection.

  • cms.bool errorReplyL1:
    specifies the desired return value of the L1 filter and the single L1 algorithm filter in case of certain errors as described here.

HLT filter

  • cms.InputTag hltInputTag:
    !InputTag of the HLT TriggerResults collection
    TIPThe process name has to be included, since an EDM file can contain several TriggerResults collections. A missing process name leads to an error of the HLT filter.
    ALERT! The default value is "TriggerResults::HLT". Do not change it, if you do not know exactly, what you are doing!

  • cms.string hltDBKey (optional):
    Tag of the record in the database, where IOV-based HLT paths are found. This record overwrites the configuration parameter hltPaths.
    ==hltPaths== remains valid if:
    • hltDBKey is not present (database access switched off);
    • database access fails.

  • cms.vstring hltPaths:
    Lists logical expressions of HLT paths, which should have accepted the event. Negation is supported by a prefixing a '~' to any element of the vector. HLT path names can be found via the HLT trigger tables (pick out the table you need).
    An empty vector lets the filter return the neutral element as explained here (switched off).
    ALERT! Wild-cards are enabled for HLT path names.
    The usage of the '*' character will expand to all matching HLT path names available in the menu, connected by OR in brackets.
    If the given HLTpath name ends with '_v*', only numerical expansion is applied, so that the (obvious) purpose of matching version numbers is not spoiled by accidentally matching path names. E.g HLT_Mu24_v* will not expand to HLT_Mu24_vertexMatched_v99, if this was also available in the menu.

  • cms.bool andOrHlt:
    specifies the logical combination of the single HLT paths' decisions;
    ==False== ≡ AND,
    ==True== ≡ OR.
    In case it is missing, the HLT filter will not be executed and returns the neutral element of the general andOr configuration parameter setting (s. there). By this, it has no effect on the event selection.

  • cms.bool errorReplyHlt:
    specifies the desired return value of the HLT filter and the single HLT path filter in case of certain errors as described here.

Logical Expressions

The configuration parameters for L1 algorithms and HLT paths (trigger names, both of type cms.vstring) support logical expressions to combine the triggers flexibly. E.g. the famous event selection for early collisions data

process.hltLevel1GTSeed.L1SeedsLogicalExpression = '0 AND ( 40 OR 41 ) AND NOT ( 36 OR 37 OR 38 OR 39 )'
can not be represented by the simple approach of (optionally negated) vector elements, which are combined by either an AND or an OR (cms.bool andOr[...] configuration parameters).

Each string in the cms.vstring configuration parameters can be such a logical exression, consisting of trigger names combined by operators. The supported operators are the same as in the HltLevel1GTSeed filter, namely:

  • AND
  • OR
    inclusive OR;
  • NOT
    negation;
  • ([...])
    grouping.
ALERT! L1 trigger bit numbers are not supported in the l1Algorithms configuration parameter to avoid confusion between physics algorithms' and technical trigger bits. The L1 algorithm names have to be used instead E.g. the event selection shown above becomes now
l1Algorithms = cms.vstring( 'L1Tech_BPTX_plus_AND_minus.v0 AND ( L1Tech_BSC_minBias_threshold1.v0 OR L1Tech_BSC_minBias_threshold2.v0 ) AND NOT ( L1Tech_BSC_halo_beam2_inner.v0 OR L1Tech_BSC_halo_beam2_outer.v0 OR L1Tech_BSC_halo_beam1_inner.v0 OR L1Tech_BSC_halo_beam1_outer.v0 )' )

This approach lets the combination of the cms.vstring elements via the cms.bool andOr[...] configuration parameters become obsolete. Anyway, this functionality is kept for the moment for backward compatibility reasons.

Error Checks UPDATED

General

  • Availability of filter configuration:
    • checks, if the configuration parameter andOr is available and assumes that the filter configuration is missing, if not;
    • checks, if any of the sub-filters is available and acts as in case of a missing andOr, if not;
    • returns true to the calling EDM module, if andOr is missing;
    • guarantees backward compatibility, if old configuration files are used.

DCS filter (scalers)

  • Availability of sub-filter configuration:
    • checks, if the configuration parameter andOrDcs is available and assumes that the sub-filter configuration is missing, if not;
    • returns the neutral element as explained here to the filter's top level method.
    • guarantees backward compatibility, if old configuration files are used;
    • should be used to skip the DCS filtering by not defining any of its configuration parameters.
  • Empty DCS partition list:
    • checks, if the configuration parameter dcsPartitions provides an empty vector;
    • returns the neutral element as explained here to the filter's top level method;
    • can be used to skip the DCS filtering.
  • Unvalid or empty DcsStatusCollection:
    • checks, if the DcsStatusCollection for the configuration parameter dcsInputTag is valid or empty (older data files!);
    • returns the value of errorReplyDcs to the filter's top level method, if not.
  • Unknown DCS partition:
    • checks, if a provided partition number of the dcsPartitions vector is known;
    • returns the value of errorReplyDcs to the DCS filtering for this particular partition, if not.

GT filter UPDATED

  • Availability of sub-filter configuration:
    • checks, if the configuration parameter andOrGt is available and assumes that the sub-filter configuration is missing, if not;
    • returns the neutral element as explained here to the filter's top level method.
    • guarantees backward compatibility, if old configuration files are used;
    • should be used to skip the GT filtering by not defining any of its configuration parameters.
  • Availability of DB tag:
    • checks (if the configuration parameter gtDBKey is given), if the tag is available in the DB;
    • uses the configuration parameter gtStatusBits for the GT status bit list instead otherwise.
  • Empty GT status bit list:
    • checks, if the configuration parameter gtStatusBits provides an empty vector;
    • returns the neutral element as explained here to the filter's top level method;
    • can be used to skip the GT filtering.
  • Unvalid L1CMS.GlobalTriggerReadoutRecord: UPDATED
    • checks, if the L1CMS.GlobalTriggerReadoutRecord for the configuration parameter gtInputTag is valid (if needed);
    • returns the value of errorReplyGt to the filter's top level method, if not.
  • Unvalid L1CMS.GlobalTriggerEvmReadoutRecord: UPDATED
    • checks, if the L1CMS.GlobalTriggerEvmReadoutRecord for the configuration parameter gtEvmInputTag is valid (if needed);
    • returns the value of errorReplyGt to the filter's top level method, if not.
  • Unknown GT status bit:
    • checks, if a provided status bit name in the gtStatusBits vector is known;
    • returns the value of errorReplyGt to the GT filtering for this particular status bit, if not.

L1 filter

  • Availability of sub-filter configuration:
    • checks, if the configuration parameter andOrL1 is available and assumes that the sub-filter configuration is missing, if not;
    • returns the neutral element as explained here to the filter's top level method.
    • guarantees backward compatibility, if old configuration files are used;
    • should be used to skip the L1 filtering by not defining any of its configuration parameters.
  • Availability of DB tag:
    • checks (if the configuration parameter l1DBKey is given), if the tag is available in the DB;
    • uses the configuration parameter l1Algorithms for the L1 algorithm list instead otherwise.
  • Empty L1 algorithm list:
    • checks, if the configuration parameter l1Algorithms provides an empty vector;
    • returns the neutral element as explained here to the filter's top level method;
    • can be used to skip the L1 filtering, should be used to skip it temporarily.
  • Empty L1 logical expression:
    • checks, if a provided element of the l1Algorithms vector is an empty string;
    • includes the consideration of the negation character '~';
    • returns the value of errorReplyL1 to the L1 filtering for this particular expression.
  • Error from L1 information in the event:
    • checks, if the retrieval method for the L1 decision for a certain L1 algorithm returns an error;
    • returns the value of errorReplyL1 to the L1 logical expression for this particular algorithm.

HLT filter

  • Availability of sub-filter configuration:
    • checks, if the configuration parameter andOrHlt is available and assumes that the sub-filter configuration is missing, if not;
    • returns the neutral element as explained here to the filter's top level method.
    • guarantees backward compatibility, if old configuration files are used;
    • should be used to skip the HLT filtering by not defining any of its configuration parameters.
  • Availability of DB tag:
    • checks (if the configuration parameter hltDBKey is given), if the tag is available in the DB;
    • uses the configuration parameter hltPaths for the HLT path list instead otherwise.
  • Empty HLT path list:
    • checks, if the configuration parameter hltPaths provides an empty vector;
    • returns the neutral element as explained here to the filter's top level method;
    • can be used to skip the HLT filtering.
  • Missing HLT process name:
    • checks, if the HLT process name is provided with the configuration parameter hltInputTag;
    • returns the value of errorReplyHlt to the filter's top level method, if not.
  • Unvalid or empty TriggerResults collection:
    • checks, if the TriggerResults collection for the configuration parameter hltInputTag is valid or empty;
    • returns the value of errorReplyHlt to the filter's top level method, if not.
  • HLT configuration initialization:
    • checks, if the init([...]) method of the HLTConfigProvider succeeded;
    • returns the value of errorReplyHlt to the filter's top level method, if not.
  • HLT configuration length:
    • checks, if the HLT configuration retrieved by the HLTConfigProvider contains paths at all;
    • returns the value of errorReplyHlt to the filter's top level method, if not.
  • Empty HLT logical expression:
    • checks, if a provided element of the hltPaths vector is an empty string;
    • includes the consideration of the negation character '~';
    • returns the value of errorReplyHlt to the HLT filtering for this particular expression.
  • Unknown HLT path:
    • checks, if a provided path name in the logical expression is known to the process;
    • returns the value of errorReplyHlt to the HLT logical expression for this particular path, if not.
  • Error in HLT path:
    • checks, if a provided path of the hltPaths vector in the logical expression was in error;
    • returns the value of errorReplyHlt to the HLT logical expression for this particular path.

For Developers

This section gives insight into the implementation of the utility class in order either to develop it further or to incorporate it into an existing module.

Implementation Details

General

The GenericTriggerEventFlag utility class follows the general structure of an EDM module in order to be easily accessible. Its main parts are:

  • a c'tor to be called from EDM module's c'tor;
  • an initRun() method to be called from EDM module's beginRun() (eases also HLTConfigProvider::init() usage);
  • an accept() method to be called from EDM module's analyze() / filter() / produce().

The data members of the class are:

  • one of type L1GtUtils to access the L1 GT information;
  • one of type HLTConfigProvider= to access the HLT information beyond the TriggerResults (plus a bool to store the success of its initialization);
  • numerous of several types to store the configuration parameters;
  • one general and four sub-filter bool switches in order to transport information derived from the configuration or run initialization to the event loop.

DCS Scaler Results

The result for a particular DCS partition is extracted directly from the DcsStatusCollection in the event:

edm::Handle< DcsStatusCollection > dcsStatus_;
event.getByLabel( dcsInputTag, dcsStatus_ );
const bool decision( dcsStatus_->at( 0 ).ready( dcsPartition ) );
where dcsInputTag_ is the edm::InputTag of the DCS status collection, event is the edm::Event provided by the public accept([...]) method, and dcsPartition is the individual DCS partition number as provided in the cms.vint32 dcsPartitions configuration parameter.

GT Status Bits

A particular GT status bits is extracted directly from the L1CMS.GlobalTriggerReadoutRecord or L1CMS.GlobalTriggerEvmReadoutRecord in the event:

edm::Handle< L1CMS.GlobalTriggerReadoutRecord > gtReadoutRecord_;
event.getByLabel( gtInputTag, gtReadoutRecord_ );
const bool decision( ( gtReadoutRecord_->gtFdlWord().physicsDeclared() == 1 ) ); // example for "PhysicsDeclared"
edm::Handle< L1CMS.GlobalTriggerEvmReadoutRecord > gtEvmReadoutRecord_;
event.getByLabel( gtEvmInputTag, gtEvmReadoutRecord_ );
const bool decision( ( gtEvmReadoutRecord_->gtfeWord().beamMode() == 11 ) ); // example for "StableBeam"
where gtInputTag_ is the edm::InputTag of the L1CMS.GlobalTriggerReadoutRecord collection, gtEvmInputTag_ is the edm::InputTag of the L1CMS.GlobalTriggerEvmReadoutRecord collection, event is the edm::Event provided by the public accept([...]) method, and physicsDeclared() and beamMode() are examples for retrieval method for a GT status bit as defined in the cms.vstring gtStatusBits configuration parameter.

L1 Algorithm Results

The result of a particular L1 algorithm is evaluated using the L1GtUtils class, which provides easy access to L1 global trigger information.
It first reads the L1 event setup

L1GtUtils l1Gt_;
l1Gt_.retrieveL1EventSetup( setup );
where setup is the edm::EventSetup provided by the corresponding public accept([...]) method (s. here).
For each individual L1 algorithm, its decision is then retrieved by
int error( -1 );
const bool decision( l1Gt_.decision( event, l1AlgoName, error ) );
where event is the edm::Event also provided by the public accept([...]) method. The error variable is used for some error checks as described here.

HLT Path Results

The result of a particular HLT path is evaluated using the HLTConfigProvider. It provides the correspondances between HLT path names and HLT path indices, where the latter are needed to extract the HLT trigger result from the event.
It is initialized with the process name of the HLT process in the initRun( const edm::Event& run, const edm::EventSetup& setup) method:

bool changed( true );
if ( ! hltConfig_.init( run, setup, hltInputTag_.process(), changed ) ) {
  [do something on error]
}
where hltConfig_ is the HLTConfigProvider data member, hltInputTag_ is the edm::InputTag of the HLT process's edm::TriggerResults collection, and changed is an indicator for changes of the HLT configuration (not used here).
The results of the HLT paths are stored in the edm::TriggerResults collection, which are stored in the event:
edm::Handle< edm::TriggerResults > hltTriggerResults_;
event.getByLabel( hltInputTag_, hltTriggerResults_ );
The result of an iondividual HLT path is extracted by getting the path index corresponding to the path name (const std::string hltPathName) and determining the result for this index:
const unsigned indexPath( hltConfig_.triggerIndex( hltPathName ) );
const bool decision( hltTriggerResults_->accept( indexPath ) );

Logical Expressions

The logical expressions for L1 algorithms resp. HLT paths are evaluated using the L1GtLogicParser. (Example code given here is generic in order to cover both, L1 and HLT case.)
The parser is constructed with the string containing the logical expression:

L1GtLogicParser myLogicParser( logicalExpression );
By this, it provides a vector of the operands (the individual trigger) providing the operands' names and results (false by default). This vector can be manipulated.
Looping over it, the result of each trigger is determined as described earlier in this section, and this result is assigned to the trigger's entry in the vector:
myLogicParser.operandTokenVector().at( iToken ).tokenResult = decision;
where iToken is the index of the operand (token) in the vector and decision is the trigger result for the particular trigger as extracted from the event (s. above).
Now that the trigger results in the operands vector of the parser are correct, the result of the whole logical expression is given by an according method of the parser:
const bool logExprDecision( myLogicParser.expressionResult() );
TIP Note that the methods provided by the parser itself to extract L1 algorithm results from the event are not used here.

Adding the Filter to an EDM Module

This section describes, how to incorporate the utiliy class into a EDM package.

First, follow the installation recipe as given in the release notes. Then (of course) add also the package containing the EDM module you want to adapt to your working area.

Adding it to the C++ Code

These steps are needed in order to make the filtering available for an EDM module:

  • CMS.BuildFile of the package containing your EDM module:
    • add the line
<use name=CommonTools/TriggerUtils>
  • Interface (*.h) of your EDM module:
    • add the line
#include "CommonTools/TriggerUtils/interface/GenericTriggerEventFlag.h"
    • add a data member of the type GenericTriggerEventFlag * to your module class, e.g.
class myDqmModul : public edm::EDAnalyzer {
[...]
  private:
    GenericTriggerEventFlag * genericTriggerEventFlag_;
[...]
}
  • Source (*.cc) of your EDM module:
    • call the c'tor from the EDM module's c'tor, e.g.
myDqmModule::myDqmModule( const edm::ParameterSet& conf_ )
: genericTriggerEventFlag_( new GenericTriggerEventFlag( conf_ ) )
[...]
{
[...]
}
    • destroy it again in the EDM module's d'tor, e.g.
myDqmModule::~myDqmModule() {
[...]
  delete genericTriggerEventFlag_;
[...]
}
    • initialize the GenericTriggerEventFlag for each run in the EDM module's beginRun() method, e.g.
void myDqmModule::beginRun( edm::Run& run, edm::EventSetup& setup ) {
[...]
  if ( genericTriggerEventFlag_->on() ) genericTriggerEventFlag_->initRun( run, setup );
[...]
}
    • use the result of the utility class in the module's event loop (e.g. analyze( const edm::Event& e, const edm::EventSetup& es ) method) by e.g.:
      • skip the whole module by adding the lines
if ( genericTriggerEventFlag_->on() && ! genericTriggerEventFlag_->accept( event, setup ) ) return;
at its very top;
      • executing code depending on it with
if ( genericTriggerEventFlag_->on() && ! genericTriggerEventFlag_->accept( event, setup ) ) {
  [do something]
} else {
  [do something else]
}

Adding it to the Configuration

The configuration parameters as described above have to be added to the configuration of your EDM module in the usual ways:

  • either by directly including them
  • or by means of a cms.PSet than can be included into the configuration, possibly imported from another configuration file fragment;
  • or by defining the needed configuration parameters in a higher level configuration file, where the EDM module is included, like e.g.
from SubSystem.Package.myModule_cfi import myModule
myModule.andOr         = cms.bool( False )
# myModule.dbLabel       = cms.string( 'myLabel' ) # will be discussed below (DB)
myModule.dcsInputTag   = cms.InputTag( "scalersRawToDigi" )
myModule.dcsPartitions = cms.vint32( 24, 25, 26, 27 )
myModule.andOrDcs      = cms.bool( False )
myModule.errorReplyDcs = cms.bool( False )
myModule.gtInputTag    = cms.InputTag( "gtDigis" )
myModule.gtDBKey       = cms.string( 'myModule_Gt' )
myModule.gtStatusBits  = cms.vstring( 'PhysicsDeclared' ) # fall-back for failing DB access, of course valid for the whole job (no IOVs)
myModule.andOrGt       = cms.bool( False )
myModule.errorReplyGt  = cms.bool( False )
TIPThe configuration parameters of any sub-filter can be skipped, if it should not be run. Skipping all possible sub-filters has the same effect as skipping the whole filter.

Using DB for the configuration of the logical expressions

Since the logical expressions used to define the event selection logics for GT bits, L1 algorithms and HLT paths are managed in the format std::vector< std::string >, it has been chosen to reuse an already existing conditions format, which provides this structure, namly the AlCaRecoTriggerBits. Its basic usage is documented here, and usage tools and examples are provided in the CondTools/HLT package.

However, for the specialized use of this conditions format in the configuration of the GenericTriggerEventFlag, find adapted documentation and examples here.

For general information on the conditions DB, please consult the conditions DB software guide.

Creation of an SQLite payload for the logical expressions

New Creation

The creation of a new SQLIte payload is examplified in CommonTools/TriggerUtils/test/GenericTriggerEventFlag_AlCaRecoTriggerBitsRcd_create_cfg.py. It uses the EDAnalyzer AlCaRecoTriggerBitsRcdUpdate and the PoolDBOutputService.
The configuration parameters to be adapted to the user's needs are:

  • cms.EDAnalyzer( "AlCaRecoTriggerBitsRcdUpdate" ) process..AlCaRecoTriggerBitsRcdCreate:
    • cms.uint32 firstRunIOV:
      defines the start of the IOV,
      default: 1;
    • cms.int32 lastRunIOV:
      defines the end of the IOV, -1 means infinity,
      default: -1;
    • cms.VPSet triggerListsAdd:
      vector of parameter sets, where each parameter set defines one set of logical expressions with:
      • cms.string listName:
        defines the name of the set of logical expressions, which is used later to identify the correct set to be used in one particular sub-filter of the utility class (s. configuration parameters cms.string *DBKey);
      • cms.vstring hltPaths:
        holds finally the actual logical expressions to be stored in the DB.
  • cms.Service( "PoolDBOutputService" ) process.PoolDBOutputService:
    • cms.string connect:
      path to the SQLite file,
      ALERT! starts always with sqlite_file:;
    • cms.VPSet toPut:
      vector of parameter sets, which define the output with:
      • cms.string tag:
        unique tag to identify the current data within a data record.
TIP All other configuration paramters should stay untouched, unless the user knows exactly, what (s)he is doing.

Update

The update of an existing SQLIte payload is examplified in CommonTools/TriggerUtils/test/GenericTriggerEventFlag_AlCaRecoTriggerBitsRcd_update_cfg.py. It uses the PoolDBESSource, the EDAnalyzer AlCaRecoTriggerBitsRcdUpdate and the PoolDBOutputService.
The configuration parameters to be adapted to the user's needs are:

  • cms.Service( "PoolDBESSource" ) process.PoolDBESSource:
    • cms.string connect:
      path to the SQLite input file,
      ALERT! starts always with sqlite_file:,
      TIPusually identical to the output file of the creation configuration;
    • cms.VPSet toGet:
      vector of parameter sets, which define the input with:
      • cms.string tag:
        unique tag to identify the input data within a data record,
        TIP usually identical to the output tag of the creation configuration;
  • cms.EDAnalyzer( "AlCaRecoTriggerBitsRcdUpdate" ) process..AlCaRecoTriggerBitsRcdUpdate:
    • cms.uint32 firstRunIOV:
      defines the start of the_new_ IOV,
    • cms.int32 lastRunIOV:
      defines the end of the IOV, -1 means infinity,
      default: -1;
    • cms.vstring listNamesRemove:
      list, which exist already and are updated, have to be added also here,
      TIP update is done by a remove/re-add action;
    • cms.VPSet triggerListsAdd:
      vector of parameter sets, where each parameter set defines one set of logical expressions for update and new addition with:
      • cms.string listName:
        defines the name of the set of logical expressions, which is used later to identify the correct set to be used in one particular sub-filter of the utility class (s. configuration parameters cms.string *DBKey);
      • cms.vstring hltPaths:
        holds finally the actual logical expressions to be stored in the DB.
  • cms.Service( "PoolDBOutputService" ) process.PoolDBOutputService:
    • cms.string connect:
      path to the SQLite file,
      ALERT! starts always with sqlite_file:,
      TIP can be a new or even the old (input) file;
    • cms.VPSet toPut:
      vector of parameter sets, which define the output with:
      • cms.string tag:
        unique tag to identify the current data within a data record,
        TIP can be a new or even the old (input) tag.
TIP All other configuration paramters should stay untouched, unless the user knows exactly, what (s)he is doing.

Verification

The reading of an existing SQLIte payload is examplified in CommonTools/TriggerUtils/test/GenericTriggerEventFlag_AlCaRecoTriggerBitsRcd_read_cfg.py. It uses the EmptySource, the PoolDBESSource and the EDAnalyzer AlCaRecoTriggerBitsRcdRead.
The configuration parameters to be adapted to the user's needs are:

  • cms.Source( "EmptySource" ) process.source:
    • cms.untracked.uint32 firstRun:
      defines, where to start reading;
  • cms.untracked.PSet maxEvents:
    • cms.untracked.int32 input:
      defines the number of runs to read,
      TIP only one event per run is evaluated;
  • cms.Service( "PoolDBESSource" ) process.dbInput:
    • cms.string connect:
      path to the SQLite input file,
      ALERT! starts always with sqlite_file:;
    • cms.VPSet toGet:
      vector of parameter sets, which define the input with:
      • cms.string tag:
        unique tag to identify the input data within a data record;
  • cms.EDAnalyzer( "AlCaRecoTriggerBitsRcdRead" ) process..AlCaRecoTriggerBitsRcdRead:
    • cms.untracked.string outputType:
      defines the output format,
      availabel: twiki, text, python;
    • cms.untracked.string rawFileName:
      defines the name of the output type withou the suffix, which will be added according to the output type,
      TIP leaving this empty, redirects the output to the MessageLogger.

Uploading a new payload for the logical expressions to DB

The upload of new SQLite payloads to the databases is maintained by the Offline Drop Box.
The mechanisms provided there allow to correct IOVs, tags etc.

ALERT! In any case, only one IOV per SQLite file should be uploaded to ensure the well functioning of the Offline Drop Box mechanisms. The Offline Drop Box is under continous development, and the correct handling of multiple IOVs cannot be guaranteed at this point.

Accessing a payload for the logical expressions

Access to a DB payload is provided by the definfition of an cms.ESSource or direct addition to the Global Tag in the configuration file. This is explained in detail here.

TIPNote that the GenericTriggerEventFlag DB access supports labeling of DB data record contents. One can add to any cms.PSet in the cms.VPSet toGet a parameter

  • cms.untracked.string label,
which identifies the data defined in the cms.PSet later on in the data record. This mechanism allows to use different data of the same type without discarding some by using es_prefer statements. This is of particular importance, since an unlabeled payload of AlCaRecoTriggerBits exists already in the Global Tag.
ALERT!The label assigned here has to be used also in the configuration parameter
  • cms.string dbLabel
of the configuration of the GenericTriggerEventFlag .

Access to the payloads is also provided for the use within CMSSW code by the access function

  • std::vector< std::string > expressionsFromDB( const std::string & key, const edm::EventSetup & setup ):
    provides the logical expressions as vector of strings, depending on the key and using the event setup;
    ALERT! an empty key will result in a vector with one element being the constant EMPTY_KEY_ERROR without any further error or warning message anywhere;
    keys can be retrieved, using the following functions:
    • std::string gtDBKey():
      provides the current key to access the global trigger payload;
    • std::string l1DBKey():
      provides the current key to access the L1 payload;
    • std::string hltDBKey():
      provides the current key to access the HLT payload;

Status and Development

Validation

Notes on CMSSW and package releases

  • DQM/TrackerCommon V03-02-05 and later (including CommonTools/TriggerUtils and CommonTools/RecoUtils):
    ALERT!Do not use HLT paths filtering for data recorded with releases earlier than CMSSW_3_5_4 in online, when processing multiple runs!
    The HLTConfigProvider::init() migration to run-by-run usage hits an upstream framework bug, which lets it fail in case of changing HLT tables between runs.
    7TeV data is fine!

  • CMSSW_3_5_3:
    ALERT! Do not use this release!
    The DCS scalers are broken and wrong (fixed in CMSSW_3_5_4 ).
  • DQM/TrackerCommon V03-02-06:
    ALERT!Do not use this package!
    It contains a bug in the combinatorial logics.

Development Plans

Next Steps

Further Plans

Release Notes UPDATED

TIP The installation recipes should be followed especially for the CMSSW version given. Other versions than the given ones might require additional packages to be checked out for proper functionality.

CommonTools/TriggerUtils V00-03-06 (CMSSW_6_1_X) NEW

TIP This is the tag this documentation refers to!

  • Remove getByType.

CMSSW_6_1_X
ssh lxplus.cern.ch
cmsrel CMSSW_6_1_0_pre3
cd CMSSW_6_1_0_pre3/src
cmsenv
addpkg CommonTools/TriggerUtils V00-03-06

Add any additional package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-03-05 (CMSSW_5_X_Y)

TIP This tag is documented in rev. 48 of this TWiki.

  • Add protection against wrong or missing labels for DB access.

CMSSW_6_0_X
ssh lxplus.cern.ch
cmsrel CMSSW_6_0_0_pre2
cd CMSSW_6_0_0_pre2/src
cmsenv
addpkg CommonTools/TriggerUtils V00-03-05

CMSSW_5_2_X
ssh lxplus.cern.ch
cmsrel CMSSW_5_2_4
cd CMSSW_5_2_4/src
cmsenv
addpkg CommonTools/TriggerUtils V00-03-05

Add any additional package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-03-03 (CMSSW_5_X_Y)

TIP This tag is documented in rev. 47 of this TWiki.

  • Enabling wild-cards for L1 algorithm and HLT path names in order to deal more easily with path versioning.
  • Add unit test.

CMSSW_5_0_X
ssh lxplus.cern.ch
cmsrel CMSSW_5_0_0_patch1
cd CMSSW_5_0_0_patch1/src
cmsenv
addpkg CommonTools/TriggerUtils V00-03-03
addpkg DQM/SiStripMonitorTrack
addpkg DQM/TrackerMonitorTrack
addpkg DQM/TrackingMonitor
addpkg DQMOffline/JetMET
addpkg DQMOffline/Muon 

Add any additional package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-02-03 (CMSSW_4_X_Y) and
CommonTools/TriggerUtils V00-03-00 (CMSSW_5_X_Y)

TIP This tag is documented in rev. 41 of this TWiki.

  • Giving public access to logical expressions from DB;
  • Bug fix in CandidateTriggerObjectProducer.

CMSSW_4_2_X
ssh lxplus.cern.ch
cmsrel CMSSW_4_2_8_patch7
cd CMSSW_4_2_8_patch7/src
cmsenv
addpkg CommonTools/TriggerUtils V00-02-03

CMSSW_4_4_X
ssh lxplus.cern.ch
cmsrel CMSSW_4_4_2_patch10
cd CMSSW_4_4_2_patch10
cmsenv
addpkg CommonTools/TriggerUtils V00-02-03

CMSSW_5_0_X
ssh lxplus.cern.ch
cmsrel CMSSW_5_0_0
cd CMSSW_5_0_0/src
cmsenv
addpkg CommonTools/TriggerUtils V00-03-00

Add any package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-00-03

TIP This tag is documented in rev. 35 of this TWiki.

  • Enabled (optional) labeling of DB payloads for configuration.
    This is needed for possible future inclusion into the Global Tag.

CMSSW_3_7_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_7_0_patch4
cd CMSSW_3_7_0_patch4/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-03

CMSSW_3_8_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_8_0_pre8
cd CMSSW_3_8_0_pre8
cmsenv
addpkg CommonTools/TriggerUtils V00-00-03

Add any package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-00-02

TIP This tag is documented in rev. 33 of this TWiki.

  • Enabled (optional) labeling of DB payloads for configuration.
    This is needed for possible future inclusion into the Global Tag.

CMSSW_3_6_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_6_3
cd CMSSW_3_6_3/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-02

CMSSW_3_7_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_7_0_patch4
cd CMSSW_3_7_0_patch4/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-02

CMSSW_3_8_X
%CODE addpkg CommonTools/TriggerUtils V00-00-02{"sh" }%ssh lxplus.cern.ch cmsrel CMSSW_3_8_0_pre8 cd CMSSW_3_8_0_pre8 cmsenv addpkg CommonTools/TriggerUtils V00-00-02%ENDCODE%

Add any package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-00-01(CMSSW_3_8_0_pre6)

TIP This tag is documented in rev. 33 of this TWiki.

  • Enabled (optional) labeling of DB payloads for configuration.
    This is needed for possible future inclusion into the Global Tag.

CMSSW_3_6_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_6_3
cd CMSSW_3_6_3/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-01

CMSSW_3_7_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_7_0_patch3
cd CMSSW_3_7_0_patch3/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-01

CMSSW_3_8_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_8_0_pre6
cd CMSSW_3_8_0_pre6
cmsenv

Add any package that contains an EDM module you want to introduce the filter to.

CommonTools/TriggerUtils V00-00-00 (CMSSW_3_8_0_pre5, CMSSW_3_7_X IBs since 15-Jun-2010)

TIP This tag is documented in rev. 28 of this TWiki.

  • Migration to CommonTools/TriggerUtils

CMSSW_3_6_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_6_3
cd CMSSW_3_6_3/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-00

CMSSW_3_7_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_7_0_patch2
cd CMSSW_3_7_0_patch2/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-00

CMSSW_3_8_X
ssh lxplus.cern.ch
cmsrel CMSSW_3_8_0_pre4catfix
cd CMSSW_3_8_0_pre4catfix/src
cmsenv
addpkg CommonTools/TriggerUtils V00-00-00

Add any further package that contains an EDM module you want to introduce the filter to.

CommonTools/RecoUtils (ALERT! deprecated)

CommonTools/RecoUtils V00-00-05

TIP This tag is documented in rev. 27 of this TWiki.

  • Adding optional choice to check L1 algorithms before or after mask, default: before.

CMSSW_3_6_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_6_1
cd CMSSW_3_6_1/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-05

CMSSW_3_7_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_7_0_pre5
cd CMSSW_3_7_0_pre5/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-05

Add any further package that contains an EDM module you want to introduce the filter to.

CommonTools/RecoUtils V00-00-04

  • Example configurations to create, update and read DB payloads for the configuration of the logical expressions.

CMSSW_3_6_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_6_1
cd CMSSW_3_6_1/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-04

CMSSW_3_7_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_7_0_pre4
cd CMSSW_3_7_0_pre4/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-04

Add any further package that contains an EDM module you want to introduce the filter to.

CommonTools/RecoUtils V00-00-03 (entered in CMSSW_3_7_0_pre5)

  • Default verbosity reduced to 0, but configurable in levels.

CMSSW_3_6_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_6_1
cd CMSSW_3_6_1/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-03

CMSSW_3_7_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_7_0_pre4
cd CMSSW_3_7_0_pre4/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-03

Add any further package that contains an EDM module you want to introduce the filter to.

CommonTools/RecoUtils V00-00-02

  • Bug fix in verbosity levels.

CMSSW_3_6_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_6_1
cd CMSSW_3_6_1/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-02

CMSSW_3_7_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_7_0_pre4
cd CMSSW_3_7_0_pre4/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-02

Add any further package that contains an EDM module you want to introduce the filter to.

CommonTools/RecoUtils V00-00-01 (entered in CMSSW_3_6_1, CMSSW_3_7_0_pre3)

TIP This tag is documented in rev. 25 of this TWiki.

  • Moving to more central package.

CMSSW_3_5_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_X_2010-05-05-0200
cd CMSSW_3_5_X_2010-05-05-0200/src
cmsenv
addpkg CommonTools/RecoUtils V00-00-01

CMSSW_3_6_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_6_X_2010-05-05-1100
cd CMSSW_3_6_X_2010-05-05-1100/src
cmsenv
[No check-out needed; package is in IB]

CMSSW_3_7_X
ssh lxplus5.cern.ch
cmsrel CMSSW_3_7_0_pre3
cd CMSSW_3_7_0_pre3/src
cmsenv
[No check-out needed; package is in release]

Add any further package that contains an EDM module you want to introduce the filter to.
Examples will be added later.

DQM/TrackerCommon (ALERT! deprecated)

DQM/TrackerCommon V03-02-09

TIP This tag is documented in rev. 21 of this TWiki.

  • Enabling database access to read logical expressions for GT status bits, L1 algorithms and HLT paths.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_4
cd CMSSW_3_5_4/src
cmsenv
addpkg DQM/TrackerCommon V03-02-09
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor (with configuration in DQM/SiStripMonitorClient) can be found by cvs co -r DQMTriggerFilter-3_5_4-100314 UserCode/VAdler/src/DQM to be used on top of the packages as found there in DQM/TrackingMonitor/tags.txt.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-07 (entered in CMSSW_3_6_0_pre3)

TIP This tag is documented in rev. 14 of this TWiki.

  • Adaption of the utility class to the general structure of EDM modules (using also identical arguments):
    • c'tor to be called from EDM module's c'tor;
    • initRun() to be called from EDM module's beginRun() (eases also HLTConfigProvider::init() usage);
    • accept() to be called from EDM module's analyze/filter/produce().
  • As consequences, this implies:
    • reduction of number of accept() methods to 1;
    • removal of necessity of the EDM module to have the configuration as data member, since it is passed with the c'tor;
    • removal of necessity of the EDM module to call HLTConfigProvider::init().

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_4
cd CMSSW_3_5_4/src
cmsenv
addpkg DQM/TrackerCommon V03-02-07
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor (with configuration in DQM/SiStripMonitorClient) can be found by cvs co -r DQMTriggerFilter-3_5_4 UserCode/VAdler/src/DQM to be used on top of the packages as found there in DQM/TrackingMonitor/tags.txt.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-06

ALERT! This tag contains a bug!

DQM/TrackerCommon V03-02-05

This tag marks an intermediate development step and does not need to be considered.

  • Migration of HLTConfigProvider::init() to the beginRun() method of EDM modules.

DQM/TrackerCommon V03-02-04

TIP This tag is documented in rev. 10 of this TWiki.

  • filter on GT status bits added;
  • possibility to "hide" individual sub-filters (like e.g. L1, HLT) in the configuration;
  • return the neutral element of the top level logical operation rather than simply true in case of missing or empty sub-filter configurations;
  • removal of centralized configuration file.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_1
cd CMSSW_3_5_1/src
cmsenv
addpkg DQM/TrackerCommon V03-02-04
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor (with configuration in DQM/SiStripMonitorClient) can be found by cvs co -r DQMTriggerFilter-3_5_1 UserCode/VAdler/src/DQM to be used on top of the packages as found there in DQM/TrackingMonitor/tags.txt.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-03

TIP This tag is documented in rev. 9 of this TWiki.

  • Enabling logical expression parsing for L1 and HLT filter:
    • each vector element of hltPaths/l1Algorithms configuration parameters can be a logical expression;
    • combined by AND, OR, NOT and ( ... ) - just like e.g. in the HltLevel1GTSeed configuration parameter L1SeedsLogicalExpression;
    • fully backward compatible.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_0_pre5
cd CMSSW_3_5_0_pre5/src
cmsenv
addpkg DQM/TrackerCommon V03-02-03
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor can be found by cvs co -r DQMTriggerFilter-3_5_0_pre5-100204 UserCode/VAdler/src/DQM to be used on top of the packages as they come with the release.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-02 (entered in CMSSW_3_5_0, CMSSW_3_6_0_pre1)

TIP This tag is documented in rev. 6 of this TWiki.

  • L1 and DCS (scaler) filters added;
  • possibility to choose AND or OR combination of L1, HLT and DCS decision;
  • code restructured and simplified;
  • configurations extended according to added functionality and template PSets for SiPixel DQM modules added;
  • remaining testing/debugging output removed.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_0_pre5
cd CMSSW_3_5_0_pre5/src
cmsenv
addpkg DQM/TrackerCommon V03-02-02
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor can be found by cvs co -r DQMTriggerFilter-3_5_0_pre5-100202 UserCode/VAdler/src/DQM to be used on top of the packages as they come with the release.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-01

  • Removal of tests from configuration file.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_0_pre3
cd CMSSW_3_5_0_pre3/src
cmsenv
addpkg DQM/TrackerCommon V03-02-01
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor can be found by cvs co -r DQMTriggerFilter-3_5_0_pre3 UserCode/VAdler/src/DQM to be used on top of the packages as they come with the release.
scram b clean && scram b -r -j 5
cmsRun [your config]

DQM/TrackerCommon V03-02-00 (entered in CMSSW_3_5_0_pre3)

  • Initial implementation;
  • filter functionality for HLT only.

ssh lxplus5.cern.ch
cmsrel CMSSW_3_5_0_pre3
cd CMSSW_3_5_0_pre3/src
cmsenv
addpkg DQM/TrackerCommon
Add any further package that contains an EDM module you want to introduce the filter to.
Examples for DQM/SiStripMonitorTrack and DQM/TrackingMonitor can be found by cvs co -r DQMTriggerFilter-3_5_0_pre3 UserCode/VAdler/src/DQM to be used on top of the packages as they come with the release.
scram b clean && scram b -r -j 5
cmsRun [your config]

Contacts

Review status

Reviewer/Editor and Date Comments
Volker Adler - 03-Feb-2010 created page
Volker Adler - 02-May-2010 moved from TrackerDQMFilter to SWGuideGenericTriggerEventFlag
Edit | Attach | Watch | Print version | History: r49 < r48 < r47 < r46 < r45 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r49 - 2012-10-04 - VolkerAdler
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic 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