L1Trigger Offline FAQ

Frequently asked questions about using/accessing L1 trigger information offline.

HELP! I have a problem with my L1 trigger study! What should I do?

"The First L1 trigger FAQ"

First, congratulation that you perform a trigger study. Without understanding the trigger, without a functional and high-performance trigger, the collaboration will have NO DATA TO ANALYSE.

Second: don't panic, even if the time you need the solution is too short.

• Read first these FAQ, they give you almost all basic answers. If what you look for is not here and it is of general interest, it will be added here.
• Read the L1 trigger documentation from the software guide. It is not always up to date, but it is the best we have - and we try to improve it, so you can volunteer to help. Don't assume that you know what it means, so why read the documentation. You can cross-check sometime looking directly to the code in CVS or LXR.
• Look now again at your problem. If you do not find the solution, explain your problem to one of your colleague. Even if she/he does not understand, when trying to explain it you could understand yourself better and possibly find the solution.
• Still no solution? Look again at the problem.
• If you did not find the solution yet, it is time to ask for qualified advice.
• Write a mail to the HN list. Depending on the problem, you can use the general L1 trigger list, the L1 trigger offline software list (preferred) or the L1 trigger emulator list. See SWGuideL1Trigger#Contacts in the paragraph "Communication".
• DO NOT SEND the mail personally to L1 offline coordinators, L1 DPG coordinators, code author, etc. Don't even put them in CC - they all read these lists with incommensurate pleasure. But they are heavily overloaded, get far too many mails, have a lot of urgent/critical things to do, are at P5 or are (in rare cases) in holiday. Send it to HN list, you improve your chances to get an answer.
• Write the following in the mail (please do not forget anything from the list below):
  • release you are using
  • tags on top of the release you are using
  • modification you made to the software
  • environment (full framework cmsRun or FWLite)
  • attach the full configuration file you are using or provide a place where it can be read/downloaded/copied. Do not include it in the mail, indentation in python is important, no one wants to copy / paste your configuration file, introducing other errors.
  • always give the exact dataset or file from the dataset you are using (normally, this is the one in the configuration file you attach). Various samples are produced under various conditions, so saying "my sample was produced with release CMSSW_X_Y_Z" is not enough.
  • add everything else relevant in your opinion to understand the problem.
• Remember: if a recipient is not able to reproduce your problem, the chances to solve it are slim, so it is very important to provide the recipe and all the information to reproduce the problem.
• Wait (patiently) for an answer and be reasonable for the interval you expect to get the answer.
• If you do not get an answer in reasonable time, send a kind reminder as Reply to your mail.
• No question remains unanswered and most of the problems get solved in time.

Are the L1 trigger menu, the L1 prescale factors and the trigger masks automatically associated with the data in CMSSW?

Starting from releases from the cycle 31X, the L1 trigger configuration is managed via the global tags, with content specific for each global tag. The L1 records included can be seen at the usual wiki page SWGuideFrontierConditions.

The L1 trigger menu, the L1 prescale factors and the trigger masks are all included in the global tags.

In order to correctly include the L1 configuration, one must use the global tags only, by including in your cfg file

# configure modules via Global Tag
# https://twiki.cern.ch/twiki/bin/view/CMS/SWGuideFrontierConditions
process.load('Configuration.StandardSequences.FrontierConditions_CMS.GlobalTag_cff')
process.GlobalTag.globaltag = 'THE_GLOBAL_TAG_I_NEED::All'

with the desired global tag.

All records are retrived as Event Setup (see SWGuideGlobalTriggerEventSetup for detailed presentation).

IMPORTANT note for MC analyses with other global tag than the tag used for production: please read the following hypernews message StaticGlobalTagsMC.

For 2XX, the global tags do not contain the L1 records, therefore the following recipe has to be used.

To select the appropriate menu, please add to your python file the corresponding *_cff.py file

Example: L1Menu_startup_v3 from CMS.GlobalTriggerMenu_L1Menu_startup_v3

# L1 GT EventSetup
process.load("L1TriggerConfig.L1GtConfigProducers.L1GtConfig_cff")
process.load("L1TriggerConfig.L1GtConfigProducers.Luminosity.startup.L1Menu_startup_v3_Unprescaled_cff")

where the first load can be replaced with a more general configuration file including the L1GtConfig_cff fragment.

Which product should I use to get the L1 trigger results for algorithm triggers and technical triggers?

Recommended method for general users: use utility class L1GtUtils. See documentation at L1GtUtils wiki page

The L1 trigger results for algorithm triggers and technical triggers can be found in principle in three ED products:

• L1GlobalTriggerReadoutRecord the Global Trigger hardware record, sent via Slink64 to the CMS DAQ system
• L1GlobalTriggerEvmReadoutRecord another Global Trigger hardware record, sent via Slink64 to the CMS EVM. Partial overlap with the L1GlobalTriggerReadoutRecord.
• L1GlobalTriggerRecord Physics-analysis oriented record: stripped-down record obtained from the L1GlobalTriggerReadoutRecord.

Depending on the data tier (HLTDEBUG, RECO, AOD) you are using, these records may be or may be not all present.

Eventually, L1GlobalTriggerRecord will be only kept in AOD.

The hardware records (DAQ and EVM) give the results of the algorithm triggers and technical triggers before masking, therefore the user must apply herself/himself the trigger masks in order to get the correct algorithm decision which was used to compute the final OR.

How can I access the L1 trigger quantities (decisions, prescale factors, trigger masks, etc) in an CMSSW module?

Note that the trigger bit numbers themselves should never be used for filtering or in analysis, as a particular bit may correspond to a different trigger algorithm from one to another. Instead, the trigger algorithm names should be used, as these have constant meaning.

Method A: use L1GtUtils methods

See documentation at L1GtUtils wiki page

See L1GtUtils class for details on the implementation.

Method B: use directly L1CMS.GlobalTriggerReadoutRecord - DEPRECATED, please use Method A.

• GlobalTriggerReadoutRecord

How can I access the L1 technical trigger bits in an CMSSW module?

Recommended method for general users: use utility class L1GtUtils. See documentation at L1GtUtils wiki page

Alternative method:if one can not use L1GtUtils or if one needs the result in another bunch cross as the bunch cross 0(L1A)

From the L1CMS.GlobalTriggerReadoutRecord record, the values before masking are obtained - the user must apply the masks herself/himself. Usage of the bit number must be avoided; for all menu having the names of the technical triggers included, the usage of name is favoured (bit number can be different in different menus).

In the interface file (assumed to be called L1GtAnalyzer.h), define two private members

std::string m_nameAlgTechTrig;
int m_bitAlgTechTrig;

Add the necessary headers in L1GtAnalyzer.cc

#include "DataFormats/L1GlobalTrigger/interface/L1GlobalTriggerReadoutSetupFwd.h"
#include "DataFormats/L1GlobalTrigger/interface/L1GlobalTriggerReadoutSetup.h"
#include "DataFormats/L1GlobalTrigger/interface/L1CMS.GlobalTriggerReadoutRecord.h"

#include "CondFormats/L1TObjects/interface/L1GtTriggerMenuFwd.h"
#include "CondFormats/L1TObjects/interface/L1GtTriggerMenu.h"
#include "CondFormats/DataRecord/interface/L1GtTriggerMenuRcd.h"

In the constructor, initialize the name of the technical trigger, read from the cfi/cfg file

// constructor(s)
L1GtAnalyzer::L1GtAnalyzer(const edm::ParameterSet& parSet) :
            // a trigger (algorithm or technical trigger) name - the bit number is dummy
            m_nameAlgTechTrig(parSet.getParameter<std::string> ("AlgorithmName")), 
            m_bitAlgTechTrig(-1) {

}

In the beginRun, get the bit number for that trigger from the L1T menu used for that run (see also the corresponding FAQ) - avoid to use the name in analyze as string comparison is an expensive operation

void L1GtAnalyzer::beginRun(const edm::Run& iRun,
        const edm::EventSetup& evSetup) {

  edm::ESHandle<L1GtTriggerMenu> menuRcd;
  evSetup.get<L1GtTriggerMenuRcd>().get(menuRcd) ;
  const L1GtTriggerMenu* menu = menuRcd.product();

  for (CItAlgo techTrig = menu->gtTechnicalTriggerMap().begin(); techTrig != menu->gtTechnicalTriggerMap().end(); ++techTrig) {
    if ((techTrig->second).algoName() == m_nameAlgTechTrig) {
       m_bitAlgTechTrig = techTrig->first;
       break;
  }

// if the trigger is not in the menu, do what is appropriate for your purpose
    if (m_bitAlgTechTrig < 0) {
       ....
    }

}

In the analyze method, looping over all events

// analyze each event: event loop
void L1GtAnalyzer::analyze(const edm::Event& iEvent,
        const edm::EventSetup& evSetup) {

    // get L1GlobalTriggerReadoutRecord
    edm::Handle<L1GlobalTriggerReadoutRecord> gtReadoutRecord;
    iEvent.getByLabel(m_l1GtDaqReadoutRecordInputTag, gtReadoutRecord);

    if (!gtReadoutRecord.isValid()) {

        LogDebug("L1GtAnalyzer") << "\nL1GlobalTriggerReadoutRecord with \n  "
                << m_l1GtDaqReadoutRecordInputTag
                << "\nrequested in configuration, but not found in the event."
                << "\nExit the method.\n" << std::endl;

        return;
    }

 
  // trigger results before mask for BxInEvent -2 (E), -1 (F), 0 (L1A), 1, 2 
  const TechnicalTriggerWord&  technicalTriggerWordBeforeMaskBxE = gtReadoutRecord->technicalTriggerWord(-2);
  const TechnicalTriggerWord&  technicalTriggerWordBeforeMaskBxF = gtReadoutRecord->technicalTriggerWord(-1);
  const TechnicalTriggerWord&  technicalTriggerWordBeforeMaskBx0 = gtReadoutRecord->technicalTriggerWord();
  const TechnicalTriggerWord&  technicalTriggerWordBeforeMaskBx1 = gtReadoutRecord->technicalTriggerWord(1);
  const TechnicalTriggerWord&  technicalTriggerWordBeforeMaskBx2 = gtReadoutRecord->technicalTriggerWord(2);

  // trigger results before mask for the considered trigger in BxInEvent -2 (E), -1 (F), 0 (L1A), 1, 2 
  bool techTriggerResultBxE = false;
  bool techTriggerResultBxF = false;
  bool techTriggerResultBx0 = false;
  bool techTriggerResultBx1 = false;
  bool techTriggerResultBx2 = false;

    if (m_bitAlgTechTrig > 0) {
        techTriggerResultBxE = technicalTriggerWordBeforeMaskBxE.at(m_bitAlgTechTrig);
        techTriggerResultBxF = technicalTriggerWordBeforeMaskBxF.at(m_bitAlgTechTrig);
        techTriggerResultBx0 = technicalTriggerWordBeforeMaskBx0.at(m_bitAlgTechTrig);
        techTriggerResultBx1 = technicalTriggerWordBeforeMaskBx1.at(m_bitAlgTechTrig);
        techTriggerResultBx2 = technicalTriggerWordBeforeMaskBx2.at(m_bitAlgTechTrig);
    } else {
        // do whatever is appropriate for your purpose if the trigger is not in the menu
    }
 
} 

m_l1GtDaqReadoutRecordInputTag is the input tag for L1GlobalTriggerReadoutRecord, usually "gtDigis", it is preferable to be given as parameter.

How can I filter events based on L1 trigger results?

There are two options.

1) Use the L1Filter module, as in the python config fragment below. This can skim events based on an OR of L1 trigger algorithm triggers.

process.load('L1Trigger.Skimmer.l1Filter_cfi')
process.l1Filter.algorithms = cms.vstring('L1_SingleEG15', 'L1_SingleEG20')

process.p = cms.Path ( process.l1Filter )

2) Use the HLTLevel1GTSeeds filter module (preferred method, as the module is always up-to-date and working). This can skim events based on more complex boolean combinations of L1 trigger algorithm triggers or on complex boolean combinations of technical trigger bits. One can not mix algorithm triggers and technical triggers in the same logical expression. For algorithm triggers, one has to use in the logical expression the names of the algorithms (bit numbers will not work), while for technical triggers one has to use (for the time being) the bit numbers.

Use case: filter events according to L1 trigger results as used to compute the FinalOR (L1A)

L1 trigger writes in the trigger decision per algorithm and technical trigger from L1GlobalTriggerReadoutRecord the results before applying the L1 trigger masks. In order to gets the results after masks, which are the results for computing the FinalOR, one has to apply the masks for the corresponding partition.

This use case deals with the case where one wants to filter events based on the L1 trigger decision as used for the FinalOR (events which were selected at L1 based on the provided criteria). In this case, the L1 trigger masks must be used as they were used to get the FinalOR. The trigger masks are available via event setup.

HLTLevel1GTSeeds uses the trigger masks by default retrieving them from event setup. There is (and very likely will not be due to timing reasons - this is an filter used online in HLT seeding, its usage as skimming filter is a byproduct) a parameter to unmask all the L1 triggers. To select events as used by L1 trigger to select the L1 sample, use the following lines in your configuration file.

Example for skimming on algorithm triggers:

process.load('HLTrigger.HLTfilters.hltLevel1GTSeed_cfi')
process.hltLevel1GTSeed.L1TechTriggerSeeding = cms.bool(False)
process.hltLevel1GTSeed.L1SeedsLogicalExpression = cms.string('(L1_SingleMuBeamHalo OR L1_SingleMuOpen)  AND NOT L1_SingleJet6U')

process.p = cms.Path ( process.hltLevel1GTSeed )

Example for skimming on technical triggers:

process.load(HLTrigger.HLTfilters.hltLevel1GTSeed_cfi)
process.hltLevel1GTSeed.L1TechTriggerSeeding = cms.bool(True)
process.hltLevel1GTSeed.L1SeedsLogicalExpression = cms.string('27 OR  25')

process.p = cms.Path ( process.hltLevel1GTSeed )

Use case: filter events from the sample (L1 + HLT) according to some criteria based on L1 algorithm and technical triggers.

If one want to select events from a (L1 + HLT) sample which fulfil some L1 trigger criteria (events which would have triggered at L1 trigger level) irrespective if they actually were used in the FinalOR (aka L1A) or not, one has to reset the L1 trigger masks before using the HLTLevel1GTSeeds filter as outlined above.

To reset the masks, follow the instructions from the FAQ How can I reset the trigger masks?.

The most frequent use of this case is to split the minimum bias sample (selected at L1 usually by some BPTX and BSC triggers only) into sub-samples which would have passed some L1 trigger combinations. These events were selected at L1 trigger by minimum bias criteria only; having the decision for other algorithm or technical triggers available, one can split that sample in sub-samples (e.g. minimum bias events which passes also the L1_SingleMu7).

Note: the algorithm and technical trigger results are written by both hardware and MC emulation after the prescale factors are applied. There is no way to access the results before prescaling, neither for data nor for MC events.

As such, the prescale factors are not involved in the filtering process (available events are already prescaled).

How can I find out what L1 algorithms or technical triggers are available?

The algorithms implemented in a given L1 Trigger Menu can be found by going to GlobalTriggerAvailableMenus and clicking on the menu version number. Starting with L1Menu_Commissioning2009_v7, the menu includes also the technical triggers by name.

How can I get a list of current L1 algorithm triggers in a CMSSW module?

The following code fragment demonstrates how to get the current menu, from the edm::EventSetup, and extract the L1 algorithm trigger names. Note that this will provide the full list of algorithm triggers in the menu - it will not tell you which were masked/disabled! (See next FAQ)

#include "CondFormats/L1TObjects/interface/L1GtTriggerMenuFwd.h"
#include "CondFormats/L1TObjects/interface/L1GtTriggerMenu.h"
#include "CondFormats/DataRecord/interface/L1GtTriggerMenuRcd.h"

  edm::ESHandle<L1GtTriggerMenu> menuRcd;
  eventSetup.get<L1GtTriggerMenuRcd>().get(menuRcd) ;
  const L1GtTriggerMenu* menu = menuRcd.product();

  for (CItAlgo algo = menu->gtAlgorithmMap().begin(); algo!=menu->gtAlgorithmMap().end(); ++algo) {
    edm::LogVerbatim("L1Menu") << "Name: " << (algo->second).algoName() << " Alias: " << (algo->second)->algoAlias() << std::endl;
  }

How can I get a list of current L1 technical triggers in a CMSSW module?

The following code fragment demonstrates how to get the current menu, from the edm::EventSetup, and extract the names of the technical triggers. Note that this will provide the full list of technical triggers in the menu - it will not tell you which were masked/disabled! (See next FAQ)

#include "CondFormats/L1TObjects/interface/L1GtTriggerMenuFwd.h"
#include "CondFormats/L1TObjects/interface/L1GtTriggerMenu.h"
#include "CondFormats/DataRecord/interface/L1GtTriggerMenuRcd.h"

  edm::ESHandle<L1GtTriggerMenu> menuRcd;
  eventSetup.get<L1GtTriggerMenuRcd>().get(menuRcd) ;
  const L1GtTriggerMenu* menu = menuRcd.product();

  for (CItAlgo techTrig = menu->gtTechnicalTriggerMap().begin(); techTrig != menu->gtTechnicalTriggerMap().end(); ++techTrig) {
    edm::LogVerbatim("L1Menu") << (techTrig->second).algoName() << std::endl;
  }

How can I find out which L1 algorithms were enabled in a particular run

Recommended method: use L1GtUtils to get the trigger masks, see FAQ above.

Get the trigger menu, get the algorithm trigger mask, extract the mask for the corresponding partition and see which mask factor is used for each algorithm.

See the method described above implemented in L1GtTriggerMenuTester.cc

L1GtTriggerMenuTester is an analyzer which can be used to print the L1 trigger menu in various formats (including the wiki format you see at GlobalTriggerAvailableMenus wiki page, which includes the masks for the physics partition).

How can I reset the trigger masks?

In some cases (like the peculiar way we are triggering for the first beam, where one gates with BPTX and one select at HLT from the events selected by BPTX), one needs to reset the L1 trigger masks.

In your cfg file, to reset the masks for algorithm triggers, add

process.load("L1TriggerConfig.L1GtConfigProducers.L1GtTriggerMaskAlgoTrigConfig_cff")

process.es_prefer_l1GtTriggerMaskAlgoTrig = cms.ESPrefer("L1GtTriggerMaskAlgoTrigTrivialProducer","l1GtTriggerMaskAlgoTrig")

In your cfg file, to reset the masks for technical trigger, add

process.load("L1TriggerConfig.L1GtConfigProducers.L1GtTriggerMaskTechTrigConfig_cff")

process.es_prefer_l1GtTriggerMaskTechTrig = cms.ESPrefer("L1GtTriggerMaskTechTrigTrivialProducer","l1GtTriggerMaskTechTrig")

How can I change the prescale factors or the trigger masks for a given menu?

L1 menu, prescale factors from trivial producers, not included in global tag.

To be added later.

L1 menu, prescale factors from trivial producers, not included in global tag.

If in the directory python/Luminosity/(luminosity) a file (L1MenuName)_PrescaleFactorsAlgoTrig_cff.py exists, modify the values in that file to the desired values. The nth element of the vector corresponds to the algorithm with bit nth (starting from 0). Check that CMSSW uses this menu as default, otherwise set it as default in Configuration/StandardSequences/python/L1TriggerDefaultMenu_cff.py

The following must be done if no prescaled version of the menu already exists.

Check out in your local area the package L1TriggerConfig/L1GtConfigProducers with the release tag or with the tag containing the desired menu.

In the python/Luminosity/(luminosity) directory create a file (L1MenuName)_myString_cff.py with content similar to L1Menu2007_cff.py setting

l1GtTriggerMenuXml.TriggerMenuLuminosity = 'myLuminosity'
l1GtTriggerMenuXml.DefXmlFile = '(L1MenuName).xml'
l1GtTriggerMenuXml.VmeXmlFile = ''

and replace the menu name and the directory in the importing of (L1MenuName)_PrescaleFactorsAlgoTrig_cff.py and (L1MenuName)_TriggerMaskAlgoTrig_cff.py to the correct values.

For prescale factors, copy the file L1Menu2007_PrescaleFactorsAlgoTrig_cff .py to (L1MenuName)_PrescaleFactorsAlgoTrig_cff.py and for trigger masks, copy the file L1Menu2007_TriggerMaskAlgoTrig_cff .py to (L1MenuName)_TriggerMaskAlgoTrig_cff.py.

Edit the above two files, setting the desired values for the prescale factors and/or for trigger masks: the nth element of the vector corresponds to the algorithm with bit nth (starting from 0).

Set (L1MenuName)_myString_cff.py as default in Configuration/StandardSequences/python/L1TriggerDefaultMenu_cff.py

L1GtTriggerMenuTester is an analyzer which can be used to print the L1 trigger menu in various formats. Check first that the correct menu is set in the test cfg file.

How do I produce L1Extra particles if they are not in the event file

In case L1Extra particle are missing, but one has either the L1 GT/GMT and GCT raw data or the L1 GCT and GMD "digi", the L1Extra particle can be produced adding the following code snippets to your configuration file.

From raw data:

# RawToDigi all data
process.load('Configuration.StandardSequences.RawToDigi_cff')
process.load('L1Trigger.Configuration.L1Extra_cff')

...

process.p = cms.Path(...* process.RawToDigi * process.L1Extra * ...)

From L1 "digi" data, with the L1 GCT and GMD "digi" products present

# L1 Extra
process.load('L1Trigger.Configuration.L1Extra_cff')

...

process.p = cms.Path(... * process.L1Extra * ...)

In case the input tags of the GMT and GCT digis are not the default one ("gtDigis" and "gctDigis", respectively), one has also to add the correct labels (for example "hltGtDigis" and "hltGctDigis")

# replacing arguments for L1Extra
process.l1extraParticles.muonSource = cms.InputTag('hltGtDigis')
process.l1extraParticles.isolatedEmSource = cms.InputTag('hltGctDigis', 'isoEm')
process.l1extraParticles.nonIsolatedEmSource = cms.InputTag('hltGctDigis', 'nonIsoEm')
process.l1extraParticles.centralJetSource = cms.InputTag('hltGctDigis', 'cenJets')
process.l1extraParticles.forwardJetSource = cms.InputTag('hltGctDigis', 'forJets')
process.l1extraParticles.tauJetSource = cms.InputTag('hltGctDigis', 'tauJets')
process.l1extraParticles.etTotalSource = cms.InputTag('hltGctDigis')
process.l1extraParticles.etHadSource = cms.InputTag('hltGctDigis')
process.l1extraParticles.etMissSource = cms.InputTag('hltGctDigis')
process.l1extraParticles.htMissSource = cms.InputTag("hltGctDigis")
process.l1extraParticles.hfRingEtSumsSource = cms.InputTag("hltGctDigis")
process.l1extraParticles.hfRingBitCountsSource = cms.InputTag("hltGctDigis")

How do I get the LHC quantities (beam momentum, beam intensity, etc) from the BST message received by L1 GT?

L1 GT receives the BST message from LHC CCC, where the Beam Synchronous Timing (BST) crates are installed. BST is a system similar to TTC, which sends every orbit a message of 64 bytes in a given format, some of the bytes reserved for internal use. L1 GT just writes the first 52 bytes from the message via GTFE in the L1 GT EVM product / record (FED 812), without any change. In CMSSW, the L1 GT EVM product / record is available as L1GlobalTriggerEvmReadoutRecord. L1GlobalTriggerEvmReadoutRecord is available only in RAW data, and not in RECO or AOD data tier in order to save storage space. The BST information is a small part of the product and most of the other relevant information is saved in another product.

The following quantities are included in the BST message (these are also public methods in CMSSW L1GtfeExtWord class)

    const boost::uint64_t gpsTime() const;
    const boost::uint16_t bstMasterStatus() const;
    const boost::uint32_t turnCountNumber() const;
    const boost::uint32_t lhcFillNumber() const;
    const boost::uint16_t beamMode() const;
    const boost::uint16_t particleTypeBeam1() const;
    const boost::uint16_t particleTypeBeam2() const;
    const boost::uint16_t beamMomentum() const;
    const boost::uint32_t totalIntensityBeam1() const;
    const boost::uint32_t totalIntensityBeam2() const;

The GPS time is included in the edm::Event, read from the L1 GT product by EvF. It is updated once per turn.

Starting with CMSSW_3_6_0, some quantities from the BST message are also available in the RECO and AOD samples (produced with these releases) through the ConditionsInEdm products (ConditionsInRunBlock for quantities constant per run), the producer being run in the L1Reco sequence. ConditionsInEdm is filled, in the corresponding part, with the BST information received by L1 GT, available in L1CMS.GlobalTriggerEvmReadoutRecord.

Method	Description	Branch
turnCountNumber	Turn count numbers, 0 .. 4294967294 (106 hours - reset on first injection), updated on each turn	EventBlock
bstMasterStatus	BST Master Status, updated on each turn	EventBlock
totalIntensityBeam1	Total Intensity beam 1, measured in Integer × 10E10 charges, updated at a rate of 1Hz	LumiBlock
totalIntensityBeam2	Total Intensity beam 2, measured in Integer × 10E10 charges, updated at a rate of 1Hz	LumiBlock
beamMode	Beam mode (RAMP, STABLE, etc), updated at a rate of 1Hz	RunBlock
beamMomentum	Beam Momentum (beam 1 = beam 2), 2 bytes in GeV/c, updated at a rate of 1Hz	RunBlock
lhcFillNumber	LHC Fill Number, updated at a rate of 1Hz	RunBlock

Beam mode (source CERN BE-BI - visible inside cern.ch domain)

ByteValue	Interpretation
1	NOMODE
2	SETUP
3	INJPILOT
4	INJINTR
5	INJNOMN
6	PRERAMP
7	RAMP
8	FLATTOP
9	SQUEEZE
10	ADJUST
11	STABLE
12	UNSTABLE
13	BEAMDUMP
14	RAMPDOWN
15	RECOVERY
16	INJDUMP
17	CIRCDUMP
18	ABORT
19	CYCLING
20	WBDUMP
21	NOBEAM

The L1Reco sequence is run for RECO (data and MC) and for CMS.RelVal first step & second step.

A provisional ConditionsInEdm documentation page is available. The coordination of the ConditionsInEdm is the responsibility of the RECO coordinators (Jean-Roch), in collaboration with EDM Framework (Liz) and L1 Trigger (Vasile).

To retrieve the quantities from ConditionsInEdm, please copy / paste the code from the following methods in L1GtAnalyzer.cc (Revision > 1.21)

    /// analyze: usage of ConditionsInEdm
    ///
    /// to be used in beginRun
    void analyzeConditionsInRunBlock(const edm::Run&, const edm::EventSetup&);
    /// to be used in beginLuminosityBlock
    void analyzeConditionsInLumiBlock(const edm::LuminosityBlock&, const edm::EventSetup&);
    /// to be used in analyze/produce/filter
    void analyzeConditionsInEventBlock(const edm::Event&, const edm::EventSetup&);

For users running on RAW data, the preferred method is to run the ConditionsInEdm producer which is found in the L1 GT unpacker package, after unpacking the L1CMS.GlobalTriggerEvmReadoutRecord product (for releases newer as CMSSW_3_6_0).

# conditions in edm
import CMS.EventFilter.L1GlobalTriggerRawToDigi.conditionDumperInEdm_cfi
conditionsInEdm =CMS.EventFilter.L1GlobalTriggerRawToDigi.conditionDumperInEdm_cfi.conditionDumperInEdm.clone()

Alternatively, one can unpack L1CMS.GlobalTriggerEvmReadoutRecord product and uses the public methods mentioned before.

For CMSSW_3_5_X, if access to RAW data is possible, the only solution is to unpack the L1GlobalTriggerEvmReadoutRecord product and to use the public methods mentioned before, following the example of the ConditionsInEdm producer.

Details, in case of problems, upon request on the L1 trigger software HN.

How do I make trigger studies with MC Summer2009 production?

As mentioned in CMS.L1TriggerEventContent wiki page, the L1 content in the Summer 2009 MC production does not have all the required products to be able to perform trigger studies. Recipes to solve this problem are available in the following L1 trigger Summer2009 MC wiki page.

-- VasileGhete - 09 Sept 2008 - Corrections & extended FAQ

-- JimBrooke - 23 Aug 2008