Description of the cmsRun Python Configuration Syntax

Complete:

Goals of this page

This page describes how to use the Python language to create configuration files.

For an introductory discussion of configuration files, see the WorkBook page WorkBookConfigFileIntro.

Translation Utilities (how to change old config files to PYTHON files)

To get used to the python configuration syntax, please have a look at e.g. the slides of the July 2008 python tutorial.

As most of the old configuration files have been deleted from the release, the last coherent version (i.e. CMSSW_2_1_0_pre6) is only accessible via AFS at CERN. To make these files known to the translation utilities you have to set (not needed for pre9 and following versions):

setenv CMSSW_SEARCH_PATH /afs/cern.ch/cms/sdt/misc/oldConfig/CMSSW:$CMSSW_SEARCH_PATH  (csh)
export CMSSW_SEARCH_PATH=/afs/cern.ch/cms/sdt/misc/oldConfig/CMSSW:$CMSSW_SEARCH_PATH (bash)

The following scripts will help you to translate your configuration files into python. The scripts cfg2py.py, translate.py, and comments.py can be found in the FWCore/ParameterSet/python directory. For now, we recommend copying these scripts to your CMSSW src/ area and working from there.

python cfg2py.py <your cfg, cff, or cfi>

Dumps to the screen a translation of your configuration file. Any dependent cffs or cfis which need to be translated will be translated and put in the appropriate directory.

python translate.py <subsystem/package/dir/your cfg, cff, or cfi>

Similar, but puts the output file in the appropriate python/ subdirectory of your package. This script catches exceptions, so if you get an error, try again with cfg2py.py to see what went wrong.

This script needs to be run from the CMSSW release src/ area.

python comments.py <your cfg, cff, or cfi>

This second-pass script finds the comments in your old file, and tries to translate them over to the python file. It sometimes gets confused when there's more than one variable of the same name, or when the comments appear inside vectors. When that happens, it just dumps the comments in the top of the python file.

edmTestCfgTranslation <your cfg>

This script will do the translation of your full cfg, create dumps of the ParameterSet that results from both the cfg and python versions, and checks the two versions for differences. Any differences are likely due to differences in some underlying cfi or cff, and need to be investigated. Another possibility is that a (python) 'replace' on a member of a 'block' is done after its usage. Then simply move the replacing line in front of its usage in python.

Finally, test if your new python file will compile:

python <subsystem/package/python/your py file>

The automatic translation has a few quirks. We can't maintain the order of statements in the original files, comments inside vectors can't be translated properly, and modules default to the type EDFilter.

The reason order isn't maintained is because the python system uses python dictionaries internally, and python dictionaries can't maintain order. Your new python file may require a bit of manual cleanup.

The translation tries to guess which type of module, EDProducer, EDFilter, or EDAnalyzer, to make, based on the name. If it's not obvious to the system, the default is EDFilter, because a few of the Path operators, '~' and '-', only accept EDFilters. If you're module is really an EDProducer or an EDAnalyzer, please fix the translated python file by hand.

Introduction

A configuration document, written using the Python language, is used to configure the cmsRun executable. A Python configuration program specifies which modules, inputs, outputs and services are to be loaded during execution, how to configure these modules and services, and in what order to execute them. It is a file which can be self-contained, or can read in any number of external Python configuration fragments using Python's standard import statement. Here is an illustration of the structure of a configuration file:

# Import configurations
import FWCore.ParameterSet.Config as cms

# Import contents of a file
import Foo.Bar.somefile

#set up a process , for e.g. RECO in this case
process = cms.Process("RECO")

# this inputs the input files
process.source = cms.Source("PoolSource", 
        fileNames = cms.untracked.vstring("test.root")
   )

process.tracker = cms.EDProducer("TrackFinderProducer")

# talk to output module
process.out = cms.OutputModule("PoolOutputModule",
      fileName = cms.untracked.string("test2.root")
   )

#add the contents of Foo.Bar.somefile to the process
process.extend(Foo.Bar.somefile)

# define output path
process.p = cms.Path(process.tracker * process.out)

There must be exactly one cms.Process with the name process in a top level configuration file.

Python Quick Tips

SWGuidePythonTips

Python has a few features that take some getting used to.

Python program flow is controlled by the indentation of the statements, so there's no need for 'endif' statements, or the curly braces from the old config language.

Objects in python are usually passed by reference. One difference between C++ and python is that when you assign an object to a variable using the '=' sign, python doesn't make a copy of the object. In general, assume that python shares references unless you explicitly make a copy, so when you modify an object, you modify it everywhere it's used.

Objects are built using constructor syntax. It's easy to forget the commas.

You can validate the syntax of your configuration using python

python <your file>

Python allows you to explore your configuration from the python command prompt

> python
>>> from Configuration.Examples.RecoExample_CMS.GlobalTag_cfg import process
>>> process.ecalRecHit
cms.EDProducer("EcalRecHitProducer",
    EEuncalibRecHitCollection = cms.InputTag("ecalWeightUncalibRecHit","EcalUncalibRecHitsEE"),
    ChannelStatusToBeExcluded = cms.vint32(),
    EBuncalibRecHitCollection = cms.InputTag("ecalWeightUncalibRecHit","EcalUncalibRecHitsEB"),
    EBrechitCollection = cms.string('EcalRecHitsEB'),
    EErechitCollection = cms.string('EcalRecHitsEE')
)

Python and SCRAM

To make objects in your python files visible to other python files, they first need to be put in your package's python directory, or a subdirectory of python. Then, you need to run scramv1 build once in your python area, to initialize the symbolic links. Later, when you change your python file, you won't need to re-build.

Objects

A Python configuration program is structured as a hierarchy of objects, nested or adjacent with respect to each other. Each object specifies a recognizable component or feature of the cmsRun program (e.g., a module) and configures it via its parameter set. Each object is introduced by a class name that identifies the type of component it configures and gives the name of the component. The contents of the object (the parameter settings) are held by the object:

NAME1 = className("someC++Class",
parameter declarations

    NAME2 = className2( 
    parameter declarations for nested object
     ...
    )
...
)

Comments may be added within a block's scope using "#" where the comment continues to the end of the line. It is clearest to define each parameter on a separate line in your configuration file, e.g.,:

VtxSmeared = cms.EDProducer("VertexGenerator",
    # Setting parameters:  <-- First comment
    type = cms.string ("IOMC/EventVertexGenerators/GaussianEventVertexGenerator"),
    MeanX = cms.double(0.),
    MeanY = cms.double(0.),
    MeanZ = cms.double(0.),
    # Second comment
    SigmaX = cms.double(0.015),
    SigmaY = cms.double(0.015),
    SigmaZ = cms.double(53.0)  # in mm (as in COBRA/OSCAR) <-- Third comment
   )

Labelled vs Unlabelled Objects

A labelled object is an object which is assigned to an arbitrarily named python variable. The variable's name appears immediately before the '=' which preceeds the declaration of the object. The variable's name must be unique within a scope (e.g., all the attributes assigned to the process object's must be uniquely named). The component to which the object gets set is a C++ class:

variable_name =  keyword("component_name",
   ...  # parameter declarations
  )

For example, here is a named EDProducer object:

VtxSmeared = cms.EDProducer("VertexGenerator",
      type = cms.string("IOMC/EventVertexGenerators/GaussianEventVertexGenerator"),
      MeanX = cms.double(0.),
      MeanY = cms.double(0.),
      MeanZ = cms.double(0.),
      SigmaX = cms.double(0.015),
      SigmaY = cms.double(0.015),
      SigmaZ = cms.double(53.0)  # in mm (as in COBRA/OSCAR)
   )

This EDProducer declaration requests an instance of the component (a C++ class) called VertexGenerator, configures it via the parameter declarations, and assigns it the variable name VtxSmeared. This object can be referred to elsewhere in the configuration file by the variable VtxSmeared. One could request a second instance of the same class, configure it differently, and assign it to different variable.

An unlabelled object has a specific variable name to which it must be assigned and thus only one instance of the class will ultimately be assigned to the process object. In this example, a source object calls the class PoolSource:

source = cms.Source("PoolSource",
   ...  # parameter declarations
   ) 

The Process Object

The top-level item of a configuration program is a Process object. Each configuration program must have a Process object assigned to a variable named process. [NOTE: the program may have other Process objects assigned to different variable names, but those Process objects will not be used to configure the job]. This process variable refers to a Process object which aggregates all the configuration information for the cmsRun executable. The Process object must be named by passing the name as the first argument to the Process class' constructor. This name gets carried along with the output data and is used as a branch name to distinguish between otherwise similar objects in a given event.

process = cms.Process("NAME")

Currently, a few names have been defined for process, but not the full set; users are encouraged to use these standard names where they apply:

HLT

Data coming from detector, through High Level Trigger (HLT)

PROD

Data coming from Prompt Reconstruction (PR) done at the T0s.

USER

Post PR data

TEST

Generated/simulated data

For data that don't fit these categories, for the present time, you can make up your own name. Once an event is written to an output file, the name gets put in the list of processes that have touched the event; therefore the name should be as meaningful as possible to other users, and must be different from all the other process names that have touched the event. Eventually, the software may restrict the process name to being one of a recognized set.

Attribute Declarations for the Process Object

Inside the process object there must be at least one object assigned (for data input source), and there may be many. Each object points to a C++ class defined in CMSSW (see the CMSSW_7_4_15 Reference Manual home page). Your job is configured by your choice of classes to invoke, and by the configuration of each class through its object. (This may be done via "import" statements, instead of or in addition to object construction.) The following types of objects may be used, according to the stipulations given:

exactly one unlabelled Source object

Defines the data input source for the cmsRun executable; i.e., where the data comes from. It must be assigned to a variable named source.

zero or more labelled EDProducer, EDFilter, EDAnalyzer or OutputModule objects

The four types are collectively refered to as 'Module's. Module objects configure cmsRun. Each of the four type represents a specific C++ base class. The classes that go here would be subclasses of any of these base classes.

zero or more labelled EDAlias objects

Allows mapping of an EDProducer from its given label to one or more different module labels. Also allows multiple EDProducers to share the same label. This is useful for making multiple jobs with different configurations to appear to make the same Event products.

zero or more unlabelled Service object

Invoke services. They must be assigned to a variable name which matches their C++ class name.

zero or more labelled PSet objects

Define parameter sets.

zero or more labelled VPSet objects

Define vectors of parameter sets.

zero or more labelled SecSource objects

Define secondary data input source, used only with "mixing modules".

zero or more labelled or unlabelled ESSource objects

Grab information from an external input source, e.g., the calibration database, an xml file, etc. If unlabelled, then they must be assigned to a variable with a name which matches the C++ class name.

zero or more labelled or unlabelled ESProducer objects

Describe environmental quantities, e.g., ambient temperature, magnetic field, and so on. If unlabelled, then they must be assigned to a variable with a name which matches the C++ class name.

zero or more labelled Sequence definitions

Define ordered groups of modules, giving each group a name that may be used in other sequences, paths, or endpaths.

zero or more named Path definitions

Specify groups of modules to execute in the order given.

zero or more named EndPath definitions

Define groups of modules to run, in the order given, after all other named paths have been run.

CMSSW classes and modules

"Module" is a generic name for any of four types of "workers" (C++ base classes): EDProducer, EDFilter, EDAnalyzer and OutputModule. Any number of classes can be built from these base classes. A module object in a configuration program instantiates a class based on one of these base classes. The instantiation process is described in Modular Architecture.

To configure a job, you need to determine whether the functionality you need is already available in existing classes, or if you'll need to create any new ones. To examine the existing classes, look in the CMSSW Reference manual. For instance,

CMSSW Documentation

This is main page of the CMSSW Reference Manual. Choose "Class List" from menu bar at top.

CMSSW Class List

Here are the classes, structs, unions and interfaces with brief descriptions. Choose "edm::EDProducer".

edm::EDProducer Class Reference

provides an inheritance diagram for edm::EDProducer, i.e., lists all classes based on the base class EDProducer. Links on each class point to the package documentation. This page also tells which header file to use, provides short description, lists member functions, static attributes, provides constructor and destructor doc, member function doc, member data doc, and so on.

As another example, from the CMSSW Reference manual home page, choose "Calorimetry".

Calorimetry Packages

lists all packages related to calorimetry within the CMSSW repository. Links point to the package documentation. Choose "DataFormats/CMS.CaloTowers".

Package DataFormats/CMS.CaloTowers

gives short package description, lists public interface, collections (products) and status. Choose "CaloTowerDetId".

CaloTowerDetId Class Reference

tells which header file to use, provides short description, lists member functions, static attributes, provides constructor and destructor doc, member function doc, member data doc, and so on.

Note that the reference manual is linked from the CMS Software page; click the "Reference Manual" link, and select the version. The reference manual is generated with Doxygen, which is a command line, open source documentation generator.)

Parameters

Each C++ class that gets created from a Python object can be configured via its associated ParameterSet. For most of the types of objects the framework actually creates a ParameterSet object used to configure the related component of the executable. Each such object can contain any, or all, of the following types of named parameters, in any number or combination. NOTE: the examples assume one has done import ParameterSet.Config as cms so we can use the short name cms rather than the verbose name FWCore.ParameterSet.Config when refering to the Python objects.

Keyword	C++ type	Example
bool	bool	b = cms.bool(False)
int32	int	i = cms.int32(-234)
uint32	unsigned	i = cms.uint32(2112)
vint32	std::vector<int>	v = cms.vint32( 1, -3, 5 )
vuint32	std::vector<unsigned>	v =cms.vuint32( 0, 1, 0 )
int64	long long	i = cms.int64(-234)
uint64	unsigned long long	i = cms.uint64(2112)
vint64	std::vector<long long>	v = cms.vint64( 1, -3, 5 )
vuint64	std::vector<unsigned long long>	v =cms.vuint64( 0, 1, 0 )
string	std::string	s = cms.string("spaces are allowed")
		s = cms.string('single quotes allowed')
vstring	std::vector<std::string>	v = cms.vstring( 'thing one', "thing two")
double	double	d = cms.double(-3.43e-34)
vdouble	std::vector<double>	v = cms.vdouble(1.2, 3, 4.5e-100, -inf)
FileInPath	edm::FileInPath	particleFile = cms.FileInPath("SimGeneral/HepPDTESSource/data/particle.tbl")
InputTag	edm::InputTag	inputTag = cms.InputTag("simrec","jets")
VInputTag	std::vector<edm::InputTag>	jetTags = cms.VInputTag( cms.InputTag("simrec","jets"), cms.InputTag("cone5CMS.CaloJets"))
ESInputTag	edm::InputTag	inputTag = cms.ESInputTag("hbconditions")
VESInputTag	std::vector<edm::InputTag>	inputTag = cms.VInputTag(cms.ESInputTag("hbconditions"))
EventID	edm::EventID	e = cms.EventID(1,1,1)
VEventID	std::vector<edm::EventID>	events = cms.VEventID(cms.EventID(1,1,1),cms.EventID(2,3,4))
EventRange	edm::EventRange	r = cms.EventRange(1,1,1,5,3,999) (0 corresponds to MAX)
		r = cms.EventRange("1:1:1-5:3:999") ('min' and 'max' are allowed)
VEventRange	std::vector<edm::EventRange>	ranges = cms.VEventRange( cms.EventRange(1,1,1,5,0,0), cms.EventRange(8,1,1,9,1,10))
LuminosityBlockID	edm::LuminosityBlockID	l = cms.LuminosityBlockID(1,1)
VLuminosityBlockID	std::vector<edm::LuminosityBlockID>	lumis = cms.VLuminosityBlockID(cms.LuminosityBlockID(1,1),cms.LuminosityBlockID(2,3))
LuminosityBlockRange	edm::LuminosityBlockRange	r = cms.LuminosityBlockRange(1,1,5,0) (0 corresponds to MAX)
		r = cms.LuminosityBlockRange("1:1-5:max") ('min' and 'max' are allowed)
VLuminosityBlockRange	std::vector<edm::LuminosityBlockRanget>	ranges = cms.VLuminosityBlockRange( cms.LuminosityBlockRange(1,1,5,0), cms.LuminosityBlockRange(8,1,9,1))
PSet	edm::ParameterSet	see below
VPSet	std::vector<edm::ParameterSet>	see below

Note that empty vectors are legal; e.g.,

    c = cms.vint32( )

creates an empty integer vector named "c".

The system keeps track of what parameters are used to create each data item in the Event. This can be used later to help understand how the data was made. However, sometimes a parameter will have no effect on the final objects created, e.g., the parameter just sets how much debugging information should be printed to the log. Such parameters are 'untracked'.

To see how parameters are defined, here is a sample :

import FWCore.ParameterSet.Config as cms
source = cms.Source("FlatRandomEGunSource",     
    # Here we define a parameter set (PSet) to be used by the source, 
    # and give it the name PGunParameters:
    PGunParameters =cms.PSet(
         # you can request more than one particle, e.g.:
         # PartID = cms.vint32(211,11)   # but we just request one this time:
         PartID = cms.vint32(211),
         MinEta = cms.double(-3.5),
         MaxEta =  cms.double(3.5),
         MinPhi = cms.double(-3.14159265358979323846), # in radians
         MaxPhi =  cms.double(3.14159265358979323846),
         MinE   =  cms.double(9.99),
         MaxE   = cms.double(10.01)
      ),
      Verbosity = cms.untracked.int32(0) # set to 1 (or greater)  for printouts
   )

For modules with many parameters, it can be painful to have to write every single one of them in a job's configuration program. Instead, you may consult the module's "configuration fragment include" ( cfi) file which specifies the module's parameters and their default values. The cfi file is used as the default configuration; you only need to specify (replace) parameters in your configuration ( cfg) program whose values differ from the default values. The cfi files are located in the data directory of the package which contains the module. The name of the file should match the 'module label' assigned to the module from within the cfi file, and should end with the suffix _cfi.py.

For example, in SimG4Core/Application/test/runP-WithPythiaAndQGSP.cfg, see the "include" statement, followed by a "replace" statement:

   from IOMC/GeneratorInterface/data/PythiaSourceMinBias_cfi import source
   source.pythiaVerbosity = True

This reads in the specified cfi file which starts with this contents:

import FWCore.ParameterSet.Config as cms
import IOMC.GeneratorInterface.pythiaDefault_cff as defaults

source = cms.ESSource("PythiaSource",  
  pythiaVerbosity = cms.untracked.bool(False)

This parameter gets replaced in the cfg file. Further along in the cfi file:

• a parameter set (PSet) is defined whose parameters refer to the card file and the vstring parameters (discussed below)

  PythiaParameters = cms.PSet(
    # This is a vector of ParameterSet names to be read, in this order
    # The first two are in the include files below
    # The last one are simply my additional parameters
    parameterSets = cms.vstring(
      "pythiaDefault", 
      "pythiaMinBias", 
      "myParameters"
    )

• two vstring parameters are defined (pythiaMinBias and myParameters)

    pythiaMinBias = cms.vstring(
      'MSEL=0         ! User defined processes',
      'MSUB(11)=1     ! Min bias process',
       ...
      'MSTJ(11)=3     ! Choice of the fragmentation function',
      'MSTJ(22)=2     ! Decay those unstable particles',
      'PARJ(71)=10 .  ! for which ctau  10 mm',
      'MSTP(2)=1      ! which order running alphaS',
      'MSTP(33)=0     ! no K factors in hard cross sections',
       ... (many more parameter definitions follow)
      )
    myParameters = cms.vstring(
    #  'MRPY(1)= 123456789 ! Automatically random if -1')

• add the contents of the pythiaDefault_cff file,

    ).extend(defaults)

Using each type of Object

Input Source Objects

The data input source for the cmsRun executable is declared using exactly one unlabelled Source object. The Source must be assigned to the source attribute of a Process object. For generated data (see WorkBookGeneration) the choices are PythiaSource (to generate a collider-type event), FlatRandomEGunSource, PoolSource, and others. The instantiation of a "Source" object has this form:

source = cms.Source("SomeClass", 
     ... # parameter declarations and/or sub-blocks here
   )

For example,

   source = cms.Source("FlatRandomEGunSource",
      PGunParameters = cms.PSet(            # a sub-block
         PartID = cms.vint32(211),         # parameters of the sub-block
         MinEta = cms.double(0.),
         MaxEta = cms.double(0.5),
         MinPhi = cms.double(0.),
         MaxPhi = cms.double(360.),
         MinE   = cms.double(9.99),
         MaxE   = cms.double(10.01)
      ),
      Verbosity = cms.untracked.int32(1)    # parameter of source block
   )

Processing Component Objects

There are four types of dynamically loadable processing components (in addition to the source type which provides the event to be processed). These are known as "modules". As mentioned above,

• "Module" is a generic name for 4 types of "workers" (C++ base classes): EDProducer, EDFilter, EDAnalyzer, and OutputModule.
• Zero or more labelled module blocks can be present assigned to a Process object.
• The classes that go here would be subclasses of any of the worker base classes.

The component types are:

Producer

Based on the EDProducer class; creates new data to be placed in the Event

Filter

Based on the EDFilter class; decides if processing should continue for an Event

Analyzer

Based on the EDAnalyzer class; studies properties of the Event

OutputModule

Stores the data from the Event

The label given to a module may be used elsewhere in the configuration, (e.g., in sequence, path and endpath specifications).

For example,:

process.filter = cms.EDFilter("PythiaFilter",
       moduleLabel = cms.untracked.string('source'),    
       MinMuonPt = cms.untracked.double(20.)
       )
process.out = cms.OutputModule("PoolOutputModule", 
       fileName = cms.untracked.string("mcpool.root"),
       SelectEvents = cms.untracked.PSet( 
       SelectEvents = cms.vstring("p")
       )
    )
...
process.p = cms.Path( process.filter )
process.e = cms.EndPath(process.out)

Service Objects

A service is a facility that performs a well-defined task that is globally acessible and that does not affect physics results. Any number of unlabelled services can be attached to a Process object.

This example shows the form of the service object:

RandomNumberGeneratorService = cms.Service("RandomNumberGeneratorService",
      sourceSeed = cms.untracked.uint32(54321)
   )

RandomNumberGeneratorService is the name of the C++ class of the service the program will use. The specific parameters required are determined by the class used.

Parameter Set (PSet) Objects

(See also Declaring configuration fragments for shared use, below.)

Any number of labelled parameter sets ("PSet") objects can be attached to the Process object. Parameter sets are used to define a list of parameters, most usefully, a list of parameters that are shared by multiple modules, i.e. can be used to configure multiple modules. The PSet concept allows a single point of maintenance for such a set of parameters.

The PSet object is of the form:

somename = cms.PSet(
   ... # parameter declarations here, e.g.,
   s = cms.string("thing zero"),
   v = cms.vstring( 'thing one', "thing two")
}

Example:

from IOMC.GeneratorInterface.data import pythiaDefault_cff

PythiaParameters = cms.PSet(

    # This is a vector of ParameterSet names to be read, in this order
    parameterSets = cms.vstring(
      "pythiaDefault",  # This is the vstring listed in the "included" cff file
      "pythiaMinBias",  # This is the first vstring listed directly in this file
      "myParameters"    # This is another vstring listed directly in this file
    ),

    pythiaMinBias = cms.vstring(  
    # Notice this is 2nd in the "parameterSets" vstring.
      'MSEL=0         ! User defined processes',
      'MSUB(11)=1     ! Min bias process',
      'MSUB(12)=1     ! Min bias process',
      ...
      )
...
   myParameters = cms.vstring(  
   # Notice this is 3rd in the "parameterSets" vstring.
   #  'MRPY(1)= 123456789 ! Automatically random if -1'
    )
  ).extend(pythiaDefault_cff) # See contents below

and the cff file reads:

import FWCore.ParameterSet.Config as cms
pythiaDefault= cms.vstring(
# Notice this is 1st in the "parameterSets" vstring.
'PMAS(5,1)=4.8 ! b quark mass',
'PMAS(6,1)=172.3 ! t quark mass'
)

Any of the parameter declarations listed under Declaring Parameters, above, may appear in a PSet object, as may other PSet objects.

To import an external PSet into a module, put the PSet in the constructor of whatever you're constructing, after its name, but before any named variables:

myBlock = cms.PSet( a = cms.int32(1) )

myModule = cms.EDAnalyzer("MyModule",
  myBlock,
  b = cms.int32(2)
)

Copies of the parameters from the PSet will be inserted into the module. These copies can then be modified, without affecting the original PSet.

Parameter Set Vector (VPSet) Objects

A parameter set vector, VPSet, is a vector (a list) of PSets. (This is not currently being used.) There may be any number of uniquely labelled vectors of parameter sets in the process object, and such a vector may be referred to, by name, from places where a ParameterSet is needed. There may be any number of vector entries. Each vector entry must be comma-separated from the next. Its format would look like:

MyParameters = cms.VPSet(       

The VPSet object is of the form:

somename = cms.VPSet(
  cms.PSet(
    ... # parameter declarations for vector entry 0
  ) ,
  cms.PSet(
    ... # parameter declarations for vector entry 1
  ) ,
  cms.PSet(
    ... 
  ) ,
...
  cms.PSet(
    ... # parameter declarations for vector entry _n_
  ) 
)

Note that it is also possible to use a VPSet which creates a std::vector<edm::ParameterSet> which is empty; this is done by:

somename = cms.VPSet()

EventRange, LuminosityBlockRange, VEventRange, VLuminosityBlockRange objects

These types are used to describe ranges of luminosity sections and events within runs. Both type follow the same syntax which is easiest to explain by looking at the text representation: cms.EventRange("1:1-5:6") which is the range begining with event (or lumi) number 1 of run 1 and continuing to event number 6 in run 5. You can also represent this as cms.EventRange(1, 1, 5, 6). The text form also takes a pair of wild-card like options, so cms.EventRange("1:min-5:max") represents the event number 1 of run 1 through the last event of run 5. This is represented as cms.EventRange(1, 1, 5, 0) as well (0 is invalid as a run, event, or lumi section, so we use it as a wildcard).

You can also supply vectors of range objects in a VEventRange or VLuminosityBlockRange objects that look like this: cms.VEventRange("1:2-3:4", "5:MIN-7:MAX").

The vector forms of these types are used to specify lumis or events to process or skip in the PoolInputSource configuration for CMSSW releases > 3_0_0.

In release 3_9_0 and later, an EventRange may optionally specify luminosity block numbers, in this representation: cms.EventRange("1:1:1-5:4:6"). If this form is used, events are ordered by run number, luminosity block number, and event number, in that order of significance. In contrast, if luminosity block numbers are not used, as in: cms.EventRange("1:1-5:6"), luminosity block numbers are ignored in determining the range, If given EventRange specifies a luminosity block number, it must specify it for both ends of the range. However, a given VEventRange may include both types of EventRange.

Secondary input source (secsource) objects

NOTE: This is a special feature, and is intended for use only by "mixing modules". Mixing, used in Monte Carlo generation and simulation, refers to adding a secondary source of events to the simulated hard scatter event. A mixing module is one that reads in both types of generated data and simulates the detector response accordingly.

Any number of uniquely labelled secondary data input source ( secsource) objects may be attached to the process object.

The object is of the form:

somename = cms.SecSource("SomeClass",
  ... # parameter declarations here
)

SomeClass is the name of the C++ class of the secondary input source the program will use. For example:

pu = cms.SecSource("PUSource",
         fileNames = cms.untracked.vstring("file:test/minbias.root")
) 

Event Setup Source (ESSource) Objects

Any number of labelled or unlabelled EventSetup objects (ESSources) may be attached to the process block. An ES source grabs information from an external source, e.g., the calibration database, an xml file, etc. You can use an unlabelled ESSource unless you plan to include more than one instance of an ESSource.

The labelled object is of the form:

SomeClass = cms.ESSource("SomeClass",
  ... # parameter declarations here
)

The labelled object is of the form:

somename = cms.ESSource("SomeClass",
  ... # parameter declarations here
)

In both cases, SomeClass is the name of the C++ class of the ESSource the program will use.

Event Setup Producer (ESProducer) Objects

Event Setup producer describe environmental quantities, e.g., ambient temperature, magnetic field, and so on. Any number of uniquely labelled or unlabelled EventSetup producer objects (ESProducers) may be attached to a Process object. This is non-event data. You can use an unlabelled ESProducer unless you plan to include more than one instance of that same ESProducer.

The unlabelled object is of the form:

SomeClass = ESProducer("SomeClass",
  ... # parameter declarations here
)

The labelled object is of the form:

somename = ESProducer("SomeClass",
  ... # parameter declarations here
)

In both cases, SomeClass is the name of the C++ class of the ESProducer the program will use. The specific parameters required are determined by the specific class used.

Module sequences

Module sequences are used to define an ordered group of modules, giving the group a name that may be used in other sequences, paths, or endpaths in the configuration document. Any number of uniquely named sequence defintions may be attached to a Process object. Sequencing is a good organization tool if you have lots of modules to load, or if you want to easily switch in and out groups of modules from the execution path.

The sequence definition is of the form:

somename = cms.Sequence( ref1 + ref2 ... )

The entries in the definition (e.g., ref1 ref2 ...) must be variable of modules or sequences declared elsewhere in the configuration program. The plug ( +) or sequencing operator, specifies that the operand on the left is executed first, followed by the operand on the right, but they are not dependent on each other. See path syntax.

Here is an example taken from the WorkBookSimDigi topic:

trDigi = cms.Sequence( pixdigi + stripdigi )
calDigi = cms.Sequence( ecaldigi + hcaldigi )
muonDigi = cms.Sequence( muoncscdigi + muondtdigi  )
doDigi = cms.Sequence( trDigi + calDigi + muonDigi   )
p1 = cms.Path( VtxSmeared * SimG4Object * mix * doDigi )

#EDA

EDAlias

EDAlias allows mapping of an EDProducer from its given label to one or more different module labels. Also allows multiple EDProducers to share the same label. This is useful for making multiple jobs with different configurations to appear to make the same Event products.

The label assigned to the the EDAlias is the new module label that can be used to lookup the data item. The EDAlias parameters accepted by an EDAlias are of the form

   <old module label> = cms.VPSet( cms.PSet( type = cms.string(<friendly class name>),
                                            [fromProductInstance = cms.string(<old product instance label>)],
                                            [toProductInstance = cms.string(<new product instance label>)] ))

Where

• <old module label> is the EDProducer's label from which the data originally derived.
• <friendly class name> specifies exactly what class type is to be obtained from the original EDProducer. The name is not the C++ class name and is instead the name used when specifying what data should be stored in the OutputModule. This name also corresponds to the first part of the TBranch name. One can also find the friendly class names of collections available in a job by adding the EventContentAnalyzer to the job.
• <old product instance label> specifies the product label used by the EDProducer when storing the data product. By default EDProducer's use an empty string. If fromProductInstance is not specified, the value of <old product instance label> defaults to '*' and therefore matches all data products of type <friendly class name> produced by the Producer with module label <old module label>.
• <new product instance label> specifies a product label different from the one from the original one used by the EDProducer. If toProductInstance is not specified, <new product instance label> defaults to the value '*' which means the new label should match the old label.

Here is an example where we want to be able to get the data product Bars from module label otherbar but using the label bar

bar = cms.EDAlias( otherbar = cms.VPSet( cms.PSet(type=cms.string('Bars') ) ) )

Say the module otherbar makes two data products of different types Bars and BarExtras. Then if we want to be able to get both by the label bar

bar = cms.EDAlias( otherbar = cms.VPSet( cms.PSet(type=cms.string('Bars') ),
                                         cms.PSet(type=cms.string('BarExtras') ) ) )

If you want to make data coming from two different modules, foo and fee, appear to come from one module, bar, where foo makes data of type Foos and fee makes data of type Fees

bar = cms.EDAlias( foo = cms.VPSet( cms.PSet(type=cms.string('Foos') ) ),
                   fee = cms.VPSet( cms.PSet(type=cms.string('Fees') ) ) )

If you want to make data coming from two different modules, foo and fee, appear to come from one module, bar, where both modules create the same type, Bars. If both modules use the default product instance label then you will need to assign at least one of them to a different label.

bar = cms.EDAlias( foo = cms.VPSet( cms.PSet(type=cms.string('Bars') ) ),
                   fee = cms.VPSet( cms.PSet(type=cms.string('Bars'), 
                                             fromProductInstance = cms.string(''),
                                             toProductInstance = cms.string('refined') ) ) )

If you want to to data products, of type Fees and Foos coming from one module, bar, appear to come from two different modules then you can use two EDAlias both of which refer th to the same EDProducer.

foo = cms.EDAlias(bar = cms.VPSet( cms.PSet(type=cms.string('Foos'))))
fee = cms.EDALias(bar = cms.VPSet( cms.PSet(type=cms.string('Fees'))))

Statements

Processing and trigger path (path) statements

Processing and trigger paths are declared via Path objects. Any number of uniquely labelled Path defintions may be attached to a Process object.

The Path definition is of the form:

somename = cms.Path( ref1 OPERATOR ref2 ... )

The entries in the definition (e.g., ref1 ref2 ...) must be module labels or sequences declared elsewhere in the configuration program. OPERATOR is either + or *. In the old configuration language, the ! operator was used to invert the result of a module in the path. In the new python configuration, the equivalent operator is ~.

For example:

process.mypath = cms.Path (process.p1*process.p2*process.p3*process.p4*process.p5*process.p6*process.p7*process.p8*process.p9*process.p10)

You can also write this out as

process.mypath = cms.Path (process.p1+process.p2+process.p3+process.p4+process.p5+process.p6+process.p7+process.p8+process.p9+process.p10)

You can also write this as, in case of too many or too long paths (and one can replace * with +)

process.mypath = cms.Path (process.p1*
                           process.p2*
                           process.p3*
                           process.p4*
                           process.p5*
                           process.p6*
                           process.p7*
                           process.p8*
                           process.p9*
                           process.p10)

You can also write it as (again * can be replaced by +)

process.mypath = cms.Path(process.m1*process.m2*process.m3)
process.mypath *= process.m4*process.m5*process.m6
process.mypath *= process.m7*process.m8*process.m9*process.m10

A comment from experts about difference between '+' and '*' usage:

The only difference in behavior between the operators is that
when "*"  is used extra error checking is performed. This error
checking is not performed when "+" is used.  There is no other
difference.  It does not affect which modules run, other than
by throwing a configuration exception and letting none run.
The purpose of the operators is to allow error checking on paths.
If in one path a module is declared to depend on a specific set of modules,
then the module must depend on the same modules in the same order in
all other paths in that process. If not the error check will fail.

EndPath statements

An EndPath object is used to define an ordered group of modules which are to run after all other labelled Paths have been run. Any number of uniquely labelled EndPath defintions may be attached to a Process object. EndPaths are used e.g. for PoolOutputModules.

The EndPath definition is of the form:

somename = cms.EndPath( ref1 OPERATOR ref2 ... )

The entries in the definition (e.g., ref1 ref2 ...) must be the variable names of modules or sequences declared elsewhere in the configuration program.

Schedule statements

To define the final series of paths to be run, you can define a Schedule. If you don't define a Schedule, all paths and endpaths will be used, in an unspecified order.

To specify a schedule, use only Paths and EndPaths, separated by commas.

process.schedule = cms.Schedule(process.generation_step,process.out_step)

The import statement

The standard Python import statement is used to inject the objects from another file into the current file, therefore it can be used to include shared-use configuration fragments. The import statements may be "nested", meaning that a configuration document may import a fragment which itself imports another fragment. There is no limit (other than that caused by memory exhaustion) on the number of levels of inclusion allowed.

Use of import does not guarantee that the objects defined in the python configuration file will actually be used to configure the job. In order to be used to configure a job, the objects must be attached to the Process object which is referenced by the process variable. The attachment can either by done for each object individually by assigning them to attributes of process, e.g.,

import somemodule
process.somename = somemodule.somename

or the all variables of a python module can be attached to a process by using the extend() member function

import somemodule
process.extend(somemodule)

When using 'extend' the variable names used in the imported module are assigned as the 'labels' for the process' attributes. Because the labelled assigned to a module comes from the process attribute's name assigned to the object and not from the original variable to which the object was assigned, the individual object assignment method allows one to 'relabel' a module to be different from the imported file

import somemodule
process.someothername = somemodule.somename

There are two framework scheduling modes. For the scheduled case, if the imported cf* file has module objects in it, you have to add those modules to a Path object which is assigned to process. For the unscheduled mode (documented here) the EDProducers will get invoked when an analyzer or filter requests data that it knows how to make.

There are several different syntaxes for the import statement depending on how you want wish to access the variables defined:

#must use full name to get to a variable
import Subsystem.package.filename
v = Subsystem.package.filename.variable



#must use short name to get to a variable
import Subsystem.package.filename as shortname
v = shortname.variable



#variable is added directly to this file
from Subsystem.package.filename import variable
p = variable



# Convenience method to insert every cms object in the module into a process
# In the following example, the module is declared in the file 
#     Configuration/StandardSequences/python/Analysis_cff.py
# Please note that it is necessary to 
#   - change each "." by a "/", 
#   - add to the path the python subdirectory of the package
#   - add the .py termination
process.load("Configuration.StandardSequences.Analysis_cff")

Example:

import FWCore.ParameterSet.Config as cms
process =cms.Process("TEST")

from IOMC.GeneratorInterface.PythiaSourceMinBias_cfi import source
source.maxEvents = 20
process.source = source

#will automatically assign the correct label to the service
process.add_( cms.Service("RandomNumberGeneratorService",
   #this sets the random number seed used by Pythia
   sourceSeed = cms.untracked.uint32(123456789)
    )
)

process.out = cms.OutputModule("PoolOutputModule", 
   fileName = cms.untracked.string("mcpool.root"),
)

process.p = cms.Endpath(process.out)

An assignment statement can replaces the maxEvents value set in the included cfi file:

import FWCore.ParameterSet.Config as cms
source = cms.Source("PythiaSource", 
  maxEvents = cms.untracked.int32(0),
  pythiaVerbosity = cms.untracked.bool(False)
...
)

It is recommended that the author of each module create a sample configuration fragment (a cfi file), put into the package's python directory. Then, users are encouraged to include the module (and replace parameter values as needed), rather than configure each module from scratch in their config files.

Blocking imports

Occasionally, a cfi.py or cff.py file may wish to declare itself "unimportable" except by certain files. As of CMSSW 3_1_2, this is possible by including the following statements at the start of the imported file:

import FWCore.ParameterSet.Config as cms

cms.checkImportPermission(allowedPatterns = ['Module','Module/Submodule'])

where the list can include any number of modules and/or submodules which are allowed to import the file. A user's top-level _cfg.py is allowed, by default, to import such a file. This behavior can be changed by setting the value of minLevel = 1 as another parameter to checkImportPermission()

Including Standard Module definitions

Configuration File Initializer files ( cfi files) are used to initialize modules with all of its default parameter settings. Each module is supposed to have one in its python directory, with the module label as its filename. This file is intended for use in end-users' cfg files; the user can then reset only the parameters that require non-default values. Cfi files may also be pulled into cff files, below. The file extension is _cfi.py.

Configuration File Fragment files ( cff files) are like cfi files, but are not associated with modules one-for-one. They are used to contain (or pull in) pieces of a configuration which may be either larger than cfi files (e.g. contain multiple modules or multiple cfi files) or smaller than cfi files (e.g. contain just one or a few parameter specifications). These files may also be included in cfg files. The file extension is _cff.py

For Component developers

Developers of modules should put standard configuration file fragments ( cff and cfi files) in a standard place, namely in the python subdirectory of the package:

<Subsystem>/<Package>/python/<moduleLabel>_cfi.py

Developers of ESSources and other components which have no module labels are asked to use the full class name as the cfi file name.

For example, the SimCalorimetry/HcalSimProducers package has a file named:

SimCalorimetry/HcalSimProducers/python/hcalUnsuppressedDigis_cfi.py

which contains:

import FWCore.ParameterSet.Config as cms

from SimCalorimetry.HcalSimProducers.hcalSimParameters_cfi import *
simHcalUnsuppressedDigis = cms.EDProducer("HcalDigiProducer",
    hcalSimParameters,
    doNoise = cms.bool(True),
    doHPDNoise = cms.bool(False),
    doTimeSlew = cms.bool(True),
    hitsProducer = cms.string('g4SimHits')
)

where HcalDigiProducer is the class name. #CptUse

For Component Users

Users who wish to include the above module ( SimCalorimetry/HcalSimProducers/python/simHcalUnsuppressedDigis_cfi.py) can say in their cfg file:

from SimCalorimetry.HcalSimProducers.simHcalUnsuppressedDigis_cfi import simHcalUnsuppressedDigis

Users may user to include multiple copies of a module, but with slightly different parameters. This can be done using the 'clone' method.

For example, if the user wishes to find jets with a cone size of 0.6 instead of 0.5, he can say:

# defines a module named "midPointCone5CMS.CaloJets"
from  RecoJets.JetProducers.CaloJetMcone5_cfi import midPointCone5CMS.CaloJets

midPointCone6CMS.CaloJets = midPointCone5CMS.CaloJets.clone()
midPointCone6CMS.CaloJets.coneRadius = 0.6
# or simply:
# midPointCone6CMS.CaloJets = midPointCone5CMS.CaloJets.clone(coneRadius = 0.6)

This was discussed in The Include Statement, above.

Calling copy() is required since multiple Python variables are allowed to reference the same Python object.

midPointCone6CMS.CaloJets = midPointCone5CMS.CaloJets #BAD
midPointCone6CMS.CaloJets.coneRadius = 0.6
#now modPointCone5CalJets.coneRadius also equals 0.6!

Modifying Parameters

Now if the user wants to modify parameters imported from other files, one option is to check out the package where the cfi file lives, and edit it there. The framework will use the FileInPath mechanism to ensure that files from the user's local area are used instead of files from the release areas.

We also have a syntax to let users edit pre-existing configurations more easily. Users shouldn't need to explicitly re-specify types, or tracked/untracked. It is enough to just say something like:

from SimG4Core.Application.SimG4Object_cfi import SimG4Object
SimG4Object.UseMagneticField = False 

Replacement of more than one parameter is allowed.

Starting from the standard definition of FlatRandomEGunSource, the user might want to modify things:

from IOMC.ParticleGuns.FlatRandomEGunSource_cfi import source
source.PGunParameters.MinE = 5.0
source.PGunParameters.MaxE = 50.0
source.PGunParameters.PartID = ( 211, 11 )

Warning: If you wish to modify a vector and set it equal to a single-element array, then you must insert a comma after that element:

source.PGunParameters.PartID = ( 211, )

Starting from the standard definition of SimG4Object, the user may want to replace an entire ParameterSet:

from SimG4Core.Application.SimG4Object_cfi import SimG4Object
SimG4Object.SteppingAction = cms.PSet(
    KillBeamPipe = cms.bool(True)      # same as standard
    CriticalEnergyForVacuum = cms.double(1.0) #changed
    CriticalDensity = cms.double(1.0e-10)     # changed
    Verbosity = cms.untracked.int32(1)         # changed    
  )

All vector style parameters behave like normal Python lists and therefor allow append, extend and other list manipulations.

The syntax is as follows:

a.composers.append("Beethoven")
a.painters.extend( ("Picasso", "da Vinci"))

Modifying Sequences and Paths

Sequences and paths have a "replace()" command, which lets you replace all occurences of a module or a sequence within a module or path with something else.

mySequence.replace(oldModule, newModule)
myPath.replace(oldSequence, newSequence)
myPath.replace(oldModule, newSequence)

If you wish to replace a module or a sequence in a process, and have the change propagated through to all sequences, paths, and endpaths which use that object, you should use

process.globalReplace("label", newObject)  # note the quotes!!

Passing Command Line Arguments Through cmsRun

Starting in CMSSW_3_0_0, you will be able to pass command-line arguments through to the Python system. For example, if you start your job via this command

> cmsRun -m grid my_cfg.py myOpt myValue=True

Then, from anywhere in the Python configuration system, you could do:

import sys
print sys.argv

and see

['cmsRun', '-m', 'grid', 'my_cfg.py', 'myOpt', 'myValue=True']

Arguments beginning with '-' or '--' are handled by the C++ options parser in cmsRun, and other options which come after the Python file are used in Python.

Additionally, you can use FWCore.ParameterSet.VarParsing module to handle the parsing of the command line objects for you (see next section for documentation).

VarParsing Example

Here's a quick example of how to use the VarParsing Module

import FWCore.ParameterSet.VarParsing as VarParsing

# set up process
process = cms.Process("StarterKit")

# setup 'analysis'  options
options = VarParsing.VarParsing ('analysis')

# setup any defaults you want
options.outputFile = '/uscms/home/cplager/nobackup/outputFiles/try_3.root'
options.inputFiles= 'file1.root', 'file2.root'
options.maxEvents = -1 # -1 means all events

# get and parse the command line arguments
options.parseArguments()

# Use the options

process.source = cms.Source ("PoolSource",
                             fileNames      = cms.untracked.vstring (options.inputFiles),
                             debugVerbosity = cms.untracked.uint32(200),
                             debugFlag      = cms.untracked.bool(True),
                             )
...

process.maxEvents = cms.untracked.PSet(
    input = cms.untracked.int32 (options.maxEvents)
)

# talk to output module
process.out = cms.OutputModule("PoolOutputModule",
                               process.patEventSelection,
                               process.patEventContent,
                               verbose = cms.untracked.bool(False),
                               fileName = cms.untracked.string (options.outputFile)

Here's how I might call it:

unix> cmsRun Reco2Pat1_withVarParsingExample_cfg.py print \
inputFiles=one.root inputFiles=two.root inputFiles_load=Zjets_2_2_3.list > & output&

where inputFiles=one.root inputFiles=two.root tells it to append one.root and two.root to the list of files to use as input. inputFiles_load=Zjets_2_2_3.list tells it to look at the file Zjets_2_2_3.list and append all files listed to the list of files to use as input as well. print tells it to print out the current values of all user access variables (very useful for log files)

Reco2Pat1_withVarParsing_example_cfg.py.txt is a complete example configuration script.

VarParsing Documentation

The idea behind VarParsing package is simple: make it easy to set up variables that can be changed from the command line. When hooking up a variable, you need to tell the module certain information about the object:

• name of object
• default value of object
• whether the object is a single number (VarParsing.VarParsing.multiplicity.singleton) or a list (VarParsing.VarParsing.multiplicity.list)
• whether the object is a string (VarParsing.VarParsing.varType.string), integer (VarParsing.VarParsing.varType.int), or float (VarParsing.VarParsing.varType.float)
  • use integer for boolean flags (1 = True, 0 = False)
• information string on object (shown when user types 'help' or 'print' from command line)

Note: Instead of typing VarParsing.VarParsing., you can simply type options. where options is the name of the VarParsing object you created.

Here's an example of hooking up an integer called someInt:

options.register ('someInt',
                  -1, # default value
                  VarParsing.VarParsing.multiplicity.singleton, # singleton or list
                  VarParsing.VarParsing.varType.int,          # string, int, or float
                  "Number of events to process (-1 for all)")

If when you create a VarParsing instance, you pass in the string 'analysis', you will get the following objects by default:

Analysis Options:

Option	Purpose
maxEvents	Number of events to process (singleton integer)
inputFiles	List of files to process as input (list string)
secondaryFiles	List of secondary files (if needed; list string)
outputFile	Name of output file (singleton string)
secondaryOutput	Name of secondary output (if needed; singleton string)

To set another default value, you would:

object.someInt = 4

If you have a list variable, you can load default values as follows:

options.someList = 'one.txt', 'two.txt'
options.someList = 'three.txt'
options.loadFromFile ('someList', 'nameOfFiles.list')

After this, options.someList will contain 'one.txt', 'one.txt', 'one.txt', and any files listed in 'nameOfFiles.list'.

Note that the format of 'nameOfFiles.list' text file is the same as the format that DBS will give to you. Comments (or lines you want to temporarily exclude) starting with the hash character (#) can be embedded in the text file and will be ignored.

Command Line Options

To assign a variable defined above from the command line, you simply use variable=value syntax.

If the variable (object) is a list, you have several options:

• You can repeat variable=value many times to load different values into the list
• You can type variable_clear to clear the variable list of all entries
• You can type variable_load=nameOfFiles.list to load all files listed in nameOfFiles.list into the variable list

Finally there are two other commands you can put on the command line

• print will print the current values of all of the settable variables
• help will do the same as print, but also display possible commands and will then exit.

IMPORTANT: The configuration script MUST end with .py. If it does not, VarParsing will not know where to start looking at the commands and will assume that everything is for cmsRun.

VarParsing Tags

VarParsing has the ability to append tags to the name of the output file given the values of the command line options. This can be very useful, for example, when running different reconstruction algorithms so that 1) it is obvious which file goes with which options and 2) so you don't accidentally overwrite files you want to compare with each other.

object.setupTags (tag = 'someBool',
                  ifCond = 'someBool > 0')
object.setupTags (tag = 'someInt%d',
                  ifCond = 'someInt > 0',
                  tagArg = 'someInt')

The first case sets up a tag if the user variable someBool is greater than 0. The second case will setup a tag if someInt is greater than 0, and then it will embed the value into the tag ('%d').

An annotated example

Here we present an annotated sample configuration program that demonstrates many of the features found in a typical configuration program. The details of the file and the configuration objects are explained in the previous sections.

# Python is very picky about leading spaces on a line

# Comments (obviously!) are introduced by a sharp ('#'), and continue
# to the end of line.

# Eventually, the software may restrict the process name to being one
# of a recognized set (such as HLT, PROD, TEST, USER). This is not yet
# implemented.

#Bring in the configuration python objects
import FWCore.ParameterSet.Config as cms

process = cms.Process("TEST")
  # Each process block must assign a source
  # attribute. As the first argument of the constructor, one must specify the
  # name of the class to be instantiated. This name is the same name
  # that the plug-in was associated with, generally done in the
  # class's implementation file. This is usually the name of the
  # class, stripped of any namespace specification.

process.source = cms.Source("PoolSource",
    fileNames      = cms.untracked.vstring('file:no_real_file_here')
  )

process.a = cms.EDProducer("AProducer",
    a = cms.int32(32),
    b = cms.vdouble( 1.1, 2.2 )
    c = cms.vstring( )            # empty vectors are accepted
    d = cms.vstring( 'boo', "yah" )
  )

 # Configuration file fragments may be included by naming 
 # the file to be included...  
 # The 'import' statement below shows the syntax.

import SomeSubsystem.SomePackage.partial_configuration_cff as _partial
process.b = cms.EDProducer("BProducer",
    a = cms.untracked.int32(14),
    b = cms.string('sillyness ensues')
    c = cms.PSet(
      a = cms.string('nested')
    )
  ).extend(_partial)

process.y = cms.OutputModule("PoolOutputModule",
    fileName = cms.untracked.string('myfile_y.root')
  )


process.z = cms.OutputModule("PoolOutputModule",
    fileName = cms.untracked.string('myfile_z.root')
 )

process.s1 = cms.Sequence( process.a+process.b )
process.s2 =  cms.Sequence( process.b )
process.s3=  cms.Sequence( process.a )
# It is not an error for two sequences (here, s3 and s4) to be identical.
process.s4=  cms.Sequence( a )

process.p1 = cms.Path( (a+b)* c )
process.p2 = cms.Path( s1* (s3+s2) )
  
process.ep = cms.EndPath( y + z )

Review status

Reviewer/Editor and Date (copy from screen)	Comments
-- ChrisDJones - 01 May 2007	translate config language page to python equivalent
-- JennyWilliams - 08 Aug 2007	moved page from workbook into SWGuide and put more basic introduction into the workbook
-- ChristopherJones - 19 Aug 2008	removed .data. from all import statements to match present day usage
-- CharlesPlager - 09 Jan 2009	Added information on VarParsing.py and command line arguments to configuration scripts
-- WilliamTanenbaum - 27 Sep 2010	Allow specification of luminosity block numbers in EventID and EventRange
-- StefanoBelforte - 17 Sep 2014	fix reference to SWGuideEDMPathsAndTriggerBits to use CMSPublic twiki

%RESPONSIBLE% ChrisDJones, Liz Sexton-Kennedy
%REVIEW% Sudhir Malik- 24 January 2009