Instructions for writing a subclass of L1ObjectKeysOnlineProdBase for TSC objects

For Run Settings (RS) objects, see SWGuideL1ObjectKeysOnlineProdBaseRS instead.

Starting from the TSC key, filling a L1TriggerKey with object key information occurs in three steps:

  1. Run L1SubsystemKeysOnlineProd with an input TSC key to determine top-level key for each subsystem (CSCTF, DTTF, RPC, GMT, RCT, GCT, GT). These are obtained from the OMDS table TRIGGERSUP_CONF, columns CSCTF_KEY, DTTF_KEY, RPC_KEY, GMT_KEY, RCT_KEY, GCT_KEY, GT_KEY. Store these subsystem keys in L1TriggerKey.
  2. Run subclasses of L1ObjectKeysOnlineProdBase, which retrieve the above L1TriggerKey and use the stored subsystem keys to determine the object keys. Store these object keys in L1TriggerKey.
  3. Run L1TriggerKeyOnlineProd to merge the object keys for all subsystems into a single L1TriggerKey, which will be written to ORCON. The list of subsystems to include is controlled by a parameter.

The reason for dividing this workflow into three steps is to allow each subsystem to define step 2, using a common base class that provides the interfaces to steps 1 and 3.

This base class, L1ObjectKeysOnlineProdBase, contains a protected data member m_omdsReader of type OMDSReader. Individual subsystems implement a concrete subclass, in which the fillObjectKeys(...) function uses m_omdsReader and the subsystem key (given in the input L1TriggerKey) to determine the corresponding object keys. These object keys are then stored in the same L1TriggerKey object.

Skeleton for subclasses of L1ObjectKeysOnlineProdBase for objects in the TSC key

The skeleton below shows example code for a single object key. Ideally, all the object keys for a given subsystem should be handled by a single producer, so the code below should be replicated for each object key. If this organization is not practical (e.g. producers for a given subsystem appear in multiple L1TriggerConfig packages), then multiple producers may be used, as long as the _cfi.py file is suitably modified (see below).

In the skeleton, replace MYSUBSYSTEM_ with your subsystem name and MYOBJECT with your configuration object name. Also, < use name=CondTools/L1Trigger > should be added to the CMS.BuildFile.

The input subsystem keys are available through the L1TriggerKey object passed into the fillObjectKeys(...) function. These keys can be empty strings, and the code in fillObjectKeys(...) should allow/check for this possibility. In the skeleton below, an empty subsystem key results in an empty object key. If an empty object key is encountered by O2O, no payload for that record is written, and no IOV is updated for this run, so that the payload of the previous run remains valid.

Instructions for translating SQL queries into C++ can be found at SWGuideOMDSReaderSQLQueries.

#include "CondTools/L1Trigger/interface/L1ObjectKeysOnlineProdBase.h"
#include "FWCore/MessageLogger/interface/MessageLogger.h"

class MYSUBSYSTEM_TSCObjectKeysOnlineProd : public L1ObjectKeysOnlineProdBase {
   public:
      MYSUBSYSTEM_TSCObjectKeysOnlineProd(const edm::ParameterSet& iConfig)
         : L1ObjectKeysOnlineProdBase( iConfig ) {}
      ~MYSUBSYSTEM_TSCObjectKeysOnlineProd() {}

      virtual void fillObjectKeys( ReturnType pL1TriggerKey ) ;
   private:
};

void
MYSUBSYSTEM_TSCObjectKeysOnlineProd::fillObjectKeys( ReturnType pL1TriggerKey )
{
      // kMYSUBSYSTEM = kCSCTF, kDTTF, kRPC, kGMT, kRCT, mkGCT, kGT, or kTSP0
      // subsystemKey = TRIGGERSUP_CONF.{CSCTF_KEY, DTTF_KEY, RPC_KEY, GMT_KEY, RCT_KEY, GCT_KEY, GT_KEY}
      std::string subsystemKey = pL1TriggerKey->subsystemKey( L1TriggerKey::kMYSUBSYSTEM ) ;

      if( !subsystemKey.empty() )
      {
         // Execute SQL queries to get data from OMDS (using key) and make C++ object.
         // Example: SELECT A_PARAMETER FROM CMS_XXX.XXX_CONF WHERE XXX_CONF.XXX_KEY = subsystemKey
         l1t::OMDSReader::QueryResults objectKeyResults =
         m_omdsReader.basicQuery(
            "A_PARAMETER",
            "CMS_XXX",
            "XXX_CONF",
            "XXX_CONF.XXX_KEY",
            m_omdsReader.singleAttribute( subsystemKey  ) );

         std::string objectKey ;

         // check if query was successful
         if( objectKeyResults.queryFailed() )
         {
             edm::LogError("L1-O2O")
                     << "Problem with key for record MYOBJECTRcd: query failed ";
         }
         else if( objectKeyResults.numberRows() != 1 )
         {
             edm::LogError("L1-O2O")
                     << "Problem with key for record MYOBJECTRcd: "
                     << (objectKeyResults.numberRows()) << " rows were returned";
         }
         else
         {
            objectKeyResults.fillVariable( objectKey ) ;
         }

         pL1TriggerKey->add( "MYOBJECTRcd", "MYOBJECT", objectKey ) ;

         // Repeat for additional object keys for this subsystem.
      }
}

DEFINE_FWK_EVENTSETUP_MODULE(MYSUBSYSTEM_TSCObjectKeysOnlineProd);

Skeleton for MYSUBSYSTEM_TSCObjectKeysOnline_cfi.py for objects in the TSC key

import FWCore.ParameterSet.Config as cms
MYSUBSYSTEM_TSCObjectKeysOnline = cms.ESProducer("MYSUBSYSTEM_TSCObjectKeysOnlineProd",
    onlineAuthentication = cms.string('.'),
    subsystemLabel = cms.string('MYSUBSYSTEM_'),
    onlineDB = cms.string('oracle://CMS_OMDS_LB/CMS_TRG_R')
)

When there are multiple object key producers for a given subsystem, each producer must be assigned a different (unique) subsystem label.

-- WernerSun - 27 Feb 2009

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2009-03-05 - WernerSun
 
    • 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