Parameters for Modules (Release cycles 6_1_X and later)

Complete:

Goal of this page

This page lists and describes configurable parameters in important EDM modules in release cycle CMSSW_6_1_X and later cycles.

For release cycles CMSSW_3_8_X through CMSSW_6_0_X inclusive, refer to the following link in the TWIKI history:

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMParametersForModules?rev=64

For releases prior to CMSSW_3_8_0, refer to the following link in the TWIKI history:

https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMParametersForModules?rev=51

edmPluginHelp

One might consider using the executable edmPluginHelp instead of this TWIKI. It provides information that complements the information on this TWIKI. It can be used to get information about the configurable parameters of any producer, filter, analyzer, output module, source, ESSource, ESProducer, or service, not just the ones related to the EDM or Framework. For edmPluginHelp to work, the function in the C++ code that describes the parameters of the module must have been implemented. The function is named "fillDescriptions". For almost all Framework related modules this function has been implemented. The number of other modules where it has been implemented is increasing.

For example for PoolSource, give the following command within the working area for a specific release:

           edmPluginHelp -p PoolSource

Or for a brief version

           edmPluginHelp -b -p PoolSource

edmPluginHelp gets its information from the same source as the configuration validation system. The list of parameters printed by edmPluginHelp will always automatically be consistent with the list of parameters allowed by the validation. With the TWIKI, there is always a possibility that we forgot to update it when a new parameter was added.

There are advantages to the TWIKI. The output of edmPluginHelp is intentionally more terse and has less information than this TWIKI. If a mistake is found the TWIKI can be immediately corrected. The edmPluginHelp documentation is hard coded in the C++ and cannot be fixed until a new release is made.

We try to keep both edmPluginHelp and this TWIKI up to date and consistent, but if you notice an error in the output of edmPluginHelp or this TWIKI, post it to the Framework hypernews so it can be fixed.

The options Parameter Set

One can define a parameter set named options at the top level that is attached directly to the process object. This parameter set will affect event processing for all modules. All the parameters within "options" are optional as is the parameter set itself. For example, it might look like this in a top level configuration file:

process.options = cms.untracked.PSet(
  fileMode = cms.untracked.string('FULLMERGE')
)

(A new option will be added in release 10_1_X soon, you will be able to use "edmPluginHelp -t options" or "edmPluginHelp -b -t options" to print out the description of the parameters from the command line.)

NOTE 1: The behavior after exceptions described above only applies during a call to a user module function while processing an Event (EDProducer::produce, EDFilter::filter, EDAnalyzer::analyze or OutputModule::write). At all other times the behavior is similar to the Rethrow behavior described above.

NOTE 2: The behavior described above for SkipEvent and FailPath does not apply if the exception is thrown while processing an event in a module on an EndPath. In this case, SkipEvent and FailPath behave as IgnoreCompletely. This is because all modules on an EndPath are considered independent.

The default for all exception categories is Rethrow. (This is correct as of the time this documentation was written, look in FWCore/Framework/src/Actions.cc for the actual defaults for a given release).

The maxEvents Parameter Set

One can define a parameter set named maxEvents at the top level that is attached directly to the process object. This parameter set will affect event processing for all modules. Both parameters within "maxEvents" are optional. as is the parameter set itself. For example, it might look like this in a top level configuration file:

process.maxEvents = cms.untracked.PSet(
  input = cms.untracked.int32(100),
  output = cms.untracked.int32(20)
)

The above parameter set will cause processing to terminate after 100 events are read from the primary input source. It will also cause processing to terminate after every output module in the configuration has output 20 events. Both parameters default to -1, which means no limit.

One can also customize the output limits to individual output modules. For example:

process.maxEvents = cms.untracked.PSet(
    input = cms.untracked.int32(100),
    output = cms.untracked.PSet(
       outputModule1 = cms.untracked.int32(20),
       outputModule2 = cms.untracked.int32(10)
    )
)

The above parameter set will cause processing to terminate after 100 events are read from the primary input source. It will also cause processing to terminate the output module with a module label of outputModule1 has output 20 events and the output module with a module label of outputModule12 has output 10 events.

Note that when processing reaches the point where the Framework says it has reached the output limit, all events already being processed will be completed. For example if you were processing 50 events concurrently, you could get anywhere from 0 to 49 additional events written to output after the output limit is reached. This behavior only applies to the output parameter, not the input parameter.

The maxLuminosityBlocks Parameter Set

One can define a parameter set named maxLuminosityBlocks at the top level that is attached directly to the process object. This parameter set will affect event processing for all modules. For example, it might look like this in a top level configuration file:

process.maxLuminosityBlocks = cms.untracked.PSet(
  input = cms.untracked.int32(10)
)

The above parameter set will cause processing to terminate after 10 luminosity blocks are read from the primary input source.

InputSources

Producer Sources (e.g. EmptySource, Generator Sources, Test Beam sources)

PoolSource

See Example 7 in SWGuidePoolInputSources for an example of how to use inputCommands to implement drop on input.

noEventSort The processing order is determined as follows. If noEventSort is true, processing is ordered by the following criteria listed in order of precedence: input file, ProcessHistory/RunNumber ordered by first appearance in current file, ProcessHistory/RunNumber/LumiNumber ordered by first appearance in current file, and entry number in Events TTree. If noEventSort is false, then processing is ordered by the following criteria listed in order of precedence: input file, process history in order of appearance in the process, run number, luminosity number, event number, and Event TTree entry order.

branchesMustMatch See SWGuideMultipleFiles for more information

See also:

SWGuidePoolInputSources - How to specify a POOL/ROOT file as a source of events.

SWGuideMultipleFiles - How to read multiple POOL/ROOT files in one job.

OutputModules

PoolOutputModule

The outputCommands and SelectEvents parameters are supported for all output modules, not just PoolOutputModule.

For a more detailed explanation of outputCommands, see SWGuideSelectingBranchesForOutput - How to configure output modules to write specific branches

If dropMetaData is "ALL", all per product per event metadata will be dropped. If dropMetaData is "PRIOR", all per product per event metadata for products produced in prior processes will be dropped. If dropMetaData is "DROPPED", all per product per event metadata for dropped products produced in prior processes will be dropped.

compressionAlgorithm was not supported in releases before CMSSW_5_0_0_pre1.

The maxSize parameter is checked only when a primary input file is closed. So, events from the same input file will always go into the same output file, regardless of the value of maxSize.

The catalog and logicalFileName parameters are passed to the job report, and are otherwise unused.

See also Paths and trigger bits - How to configure output modules to write specific events

EDProducers

EDAnalyzers

EventContentAnalyzer

This module prints to standard out a list of all products within the Event. A 'verbose' option will actually print the contents of the requested products.

EventSetupRecordDataGetter

This module can be configured to get any data from any EventSetup Record.

Parameters expected in toGet parameter

EDFilters

ESSources

EmptyESSource

This module creates empty EventSetup Records using the IOVs provided.

Services

Tracer

Prints 'tracing' information to standard out which tells you what cmsRun is doing.

Use this command to get information about allowed parameters for this and other services.

edmPluginHelp -p Tracer

or

edmPluginHelp -b -p Tracer

Review Status

Responsible: WilliamTanenbaum
Last reviewed by: Reviewer