GCT (Global Calorimeter Trigger) Emulator

Schedule

Features to be included in a future release :

• move LUT classes to L1TriggerConfig/GctConfig, and include EventSetup access (and trivial ESProducer)
• change Source Card setup to new scheme (additional card type, and more cards)
• include Source Card type as argument in L1CaloRegion (and L1CaloRegionDetId) constructor from GCT indices
• move file reading capabilities to separate Producer that mimics the RCT (and include muon bits in Region)
• hardware Jet Finder algorithm to become the default
• write Raw2Digi module

Using the Emulator

Within CMSSW

Look at the SWGuideL1CaloTrigger. You may analyze the output using SWGuideGCTMonitor. The beginnings of an Analysis project are on the GCTAnalyzerPage

Standalone

To compile the GCT library and test programs, do the following :

cd L1Trigger/CMS.GlobalCaloTrigger
scramv1 b

To run the test programs :

eval `scramv1 runtime -sh` (or -csh for tcsh users)
cd test
../../../../test/slc3_ia32_gcc323/testJetFinder

If you're adding a test program, you will need to add some lines to GlobalCaloTrigger/test/CMS.BuildFile

Object Model

This section will eventually include all details of the numbering scheme used in the emulator code.

Regions

The jet regions are numbered in eta from 0-21 corresponding to the eta co-ordinate running from -5 to +5, and are numbered in phi from 0-17 corresponding to the phi co-ordinate running from 0 to 2pi.

Source Cards

0-26 cover the -z (minus) half of the detector. 27-54 cover the +z (plus) half of the detector. SourceCard 0 receives data from the RCT electron cables, SourceCard 1 receives RCT region cables 3 & 4, SourceCard 2 receives data from RCT region cables 5 & 6 (and the same is true for 3i, 3i + 1, 3i + 2 respectively). SourceCard 3i receives data from RCT crate i.

The RCT cable mapping for jet regions into source cards follows this diagram, which also explains the orderings of these regions in the vector returned by the L1GctSourceCard::getRegions() method.

Jet Leaf Cards

JetLeafCards 0-2 cover the minus half of the detector, 3-5 cover the plus half. Each JetLeafCard contains three JetFinders. To do this, it needs to take data from fifteen source cards. The numbering of the source cards within the m_sourceCards vector is shown here. It will need to be changed whenever the JetFinder mapping is changed (see next topic).

Jet Finders

Each JetFinder object in the emulator currently receives data from 9 SourceCards like this. Only the first three SourceCard inputs are needed by the JetFinding algorithm implemented in the hardware. The remainder are used by the TDR JetFinder, which is currently the default.

JetFinders 0-8 cover the minus half of the detector, 9-17 cover the plus half (ordered in increasing phi).

Wheel Cards

The Wheel cards themselves are not modelled in the GCT emulator, but the two FPGAs are; the WheelJetFpga and WheelEnergyFpga. The 0 Fpga of each type covers the minus half of the detector, the 1 Fpga of each type covers the plus half of the detector.

EM Leaf Cards

EmLeafCard 0 covers the minus half of the detector, EmLeafCard 1 covers the plus half of the detector. Each EmLeafCard receives data from 9 SourceCards.

Electron Sorters

Each EmLeafCard contains four electron sorters. ElectronSorter 0 (for isolated electons) and ElectronSorter 1 (for non-isolated) process data from SourceCards 0-4 (as received by the EmLeafCard). ElectronSorters 2 and 3 (again for isolated and non-isolated respectively) process data from SourceCards 5-8.

Concentrator Card

The Concentrator card is not modelled itself, instead the three functional processing units are represented; ElectronFinalSort, GlobalEnergyAlgos, JetFinalStage.

CVS

The GCT Emulator lives in the CMSSW repository

The following packages are used by the emulator :

• DataFormats/!L1CaloTrigger - RCT output data
• DataFormats/!CMS.GlobalCaloTrigger - GCT output data
• L1TriggerConfig/!GctConfig - GCT configuration data (retrieved from the OMDB)
• L1Trigger/!CMS.GlobalCaloTrigger - the emulator itself

The following packages are related to the emulator :

• DQM/!SWGuideGCTMonitor - data quality monitoring for the GCT
• L1Trigger/!L1GctAnalyzer - offline analysis and MC studies

Coding Rules

• only #include headers required by the file
• using namespace std is not allowed in header files. Use std:: instead.
• global functions/typedefs/constants are not allowed
• get methods on data types don't start 'get'.
• set methods on data types do start 'set'
• private members start 'm_'
• do use doxygen comments, eg ///
• don't use bitset<N>, do use uintX_t (requires #include <boost/cstdint.hpp>)
• always use internal GCT data types for passing trigger data between processors
• fix compiler warnings

Review Status

Responsible: JimBrooke
Last reviewed by: MostRecentReviewer and date