Appendices (Including Glossary)

A.1 Specific Information for Remote Sites and Institutions

Complete: 5
Detailed Review status


Goals of this page:

This page is intended to provide links to CMS-affiliated, non-CERN, site-specific and institution-specific information that is essential for users working from these institutions to complete the tutorials and exercises in the workbook.


Site administrators and/or system administrators are encouraged to provide any necessary information that deviates from the workbook instructions such that a CMS user working from your site/institution can accomplish all the tasks in the workbook. If the information is brief, you may include it directly in the current page. Otherwise, please provide links on this page pointing to the information. The information may reside on web pages that you maintain elsewhere, or you may create new workbook pages from this page. For the latter, see the twiki formatting help (available from any editing screen) and WorkBookContributors.

Examples include but are not limited to:

  • how to get computing privileges and accounts at the site/institution,
  • login information to local clusters that maintain the CMS environment,
  • information about grid resources (besides LCG) that are available, and so on.
We organize the sites/institutions by affiliation with Tier-1 sites.



There are various facilities provided at CERN for CMS usage. Please see the facility page to see if it is available to you. To interact with CERN storage systems a set of tools is available.

U.S. Tier-1 site affiliates

U.S. CMS is a collaboration of US scientists participating in the CMS experiment. The CMS T1 site in the U.S. is at Fermilab (also known as FNAL), which houses the LHC Physics Center (, a location for CMS physicists to find experts on all aspects of data analysis, particle ID, software, and event processing within the US, during hours convenient for U.S.-based physicists.

Find USCMS-specific software and computing information at User Computing ( We collect some of the information from the USCMS web site here for convenience.



Getting a Fermilab Account

You must be registered with Fermilab before you can get any accounts. NOTE: This can take 4-6 weeks to process for both new and yearly renewals, and be sure to follow instructions emailed to you. The following web page: How to get a CMS Computing Account at Fermilab (, outlines all necessary steps to get a CMS specific account at Fermilab together with Fermilab registration and points you to the online forms that have to be filled out. Please comment to request the same account name at both CERN and Fermilab.

Login to CMSLPC

The most up to date instructions on how to get access to cmslpc-sl7 cluster and how to configure your /etc/krb5.conf and ~/.ssh/config are given at How to get access to the (CMSLPC) cluster (

You can get the CMSSW environment with the following command (tcsh shell) every time you login (or add to your ~/.tcshrc or ~.bash_profile to be done automatically upon login):

source /cvmfs/
or if you have changed your default shell to bash:
source /cvmfs/

And then you can Setup your CMSSW environment as you would elsewhere:

Only if not setup previously, make a new CMSSW

cmsrel CMSSW_11_0_1
To set the CMSSW environment:
cd CMSSW_11_0_1/src

Mass Storage

Users generally have an LPC FNAL EOS area automatically made with their account (eosls /store/YourUsername), but it is not automatically linked to your personal grid certificate, and therefore not usable with CRAB by default. You will need to follow the instructions to [[][Get your EOS area linked to your CERN username]], note that this step takes up to 1 business day to take effect.

Grid computing

The US CMS Grid is part of the worldwide LHC Computing Grid for LHC science analysis. The US CMS grid environment is part of the Open Science Grid (OSG) infrastructure. The instructions on page Starting on the GRID are valid for Fermilab users.

For information on grid certificates, Fermilab users should obtain CERN CA personal certificates CERN CA personal certificates (


Like other sites, you have to set up the Grid UI, your CMSSW release, and then CRAB but the commands are slightly different. They are listed here.

CRAB, as set up at FNAL, has a couple of extra features that you may find useful. FNAL users can have their jobs run exclusively on the LPC tier3, which may in some cases allow their jobs to start faster. The pool of users who are requesting time on the tier3 might be smaller than the group of people in the global pool. Also, LPC users are the only ones allowed to have CRAB jobs run on T3_US_FNALLPC. Only a couple of modifications need to be made to the users CRAB configuration file for the jobs to be run here.

config.Data.ignoreLocality = True
config.Site.whitelist = ['T3_US_FNALLPC']
config.Site.ignoreGlobalBlacklist = True

More information about this can be found at the CRAB3HATS2016 twiki page twiki and the Indico page for the same event.

Batch system

The batch system available for users of the CMSLPC cluster is condor which allows the user to submit jobs into the production farm. The use of this batch system is described on the following page: Batch System ( Note that you will need to have Fermilab link your personal grid certificate in the CMS VO to your Fermilab account to use this batch system, to do that follow instructions here: link your grid certificate to Fermilab account: for both FNAL EOS and condor batch It is recommended that if you are submitting cmsRun jobs, you use the CRAB mechanism described above as this does everything correctly for you already. It is much easier, both for users and for the support group.

Getting help at Fermilab

Go to to find out how to get help with computing at the LPC CAF at Fermilab, in particular you can open a LPC Service Portal ticket.

Germany Tier-1 site affiliates

This information is included from original FSP-CMS Analysys Support page. No permission to view CMS.GermanUsersComputingSupport

DESY Hamburg

Information about local computing resources at DESY Hamburg can be found in LocalComputingIssuesHamburg.

Italy Tier-1 site affiliates

UK Tier-1 site affiliates

Imperial College London

Complete information for users willing to work from Imperial College London can be found in ImperialCollegeLondonWorkBook.

Login platforms at OSG Tier-2s

Some of the OSG Tier-2s provide a login platform for their "local users". To get access to this login platform you should email the site contact listed in CMS.SiteDB.

CVMFS should be available on all of the OSG sites. To get started, you generally need to first setup your environment by doing one of the following:
source $OSG_APP/cmssoft/cms/cmsset_default.csh
source $OSG_APP/cmssoft/cms/
depending on what shell you are working in.

Review status

Reviewer/Editor and Date (copy from screen) Comments
MargueriteTonjes - 2-July-2021 major changes for Fermilab - point to documents which are actively kept up to date and fixing links
JohnStupak - 15-September-2013 Review with minor changes
FedorRatnikov - 10-Feb-2010 added DCMS details
Main.fkw - 22 Jul 2007 added info on OSG Tier-2s login platforms
AnneHeavey - 03 Aug 2006 more additions to FNAL info
JennyWilliams - 05 Dec 2006 tidied up a bit
Main.gartung - 23 May 2007 updated instructions for running at Fermilab
AlanStone - 14 Oct 2008 Updated links to new USCMS & FNAL Computing docs

Responsible: SudhirMalik
Last reviewed by: SudhirMalik - 26 Nov 2008 (FNAL)

A.2 Troubleshooting Guide: Understanding and Solving Common Software Issues


Programming and especially using CMSSW is a complicated thing. And even though the quest of common tools such as Physics Analysis Toolkit (PAT) is to simplify things they are still far from trivial to use it. When you start using PAT, CMSSW or just start programming there is a bunch of problems you will always encounter. During a normal evolution process you start with parse and linking errors during compile time and via the mysteries of python errors finally arrive at CMSSW complaints during runtime. Gaining the experience to recognize these errors is an important but painful process. This page should give you some assistance to cope with very typical errors that always occur when beginners get started.

ALERT! Note: By construction this page is evolving with time. We will try to add more and more typical errors with increasing experience.

Compiler Errors

In modern software architectures not all source code, that is used is compiled into a single very heavy executable. It is rather split into a set of clearly structured pre-compiled shared library object files ( .so). These shared library object files will be loaded dynamically when really needed during the compilation of the actual executable. Consequently the compilation of a new cmsRun executable consists of two parts:

  • Parsing:
    The grammar of the source code you wrote is checked for its correctness. The compiler checks that you did not forget any key signs (like '#', or ';'), that all functions and their arguments are known and understood and their return values match to the expected types. The declaration of new functions can be found in the header files ( .h) files that were added in the implementation of the source code.

  • Linking:
    Some functions that were used in the source code might be implemented in different pre-compiled shared library objects ( .so). In this step all .so files needed for the compilation of the executable are searched and linked.
In CMSSW all packages are compiled into individual .so files. When ever you added a .h file in your source code to declare a function you did not implement yourself the probability is high that you will also have to make the implementation of this function known to the complier by pointing to the corresponding .so file. We list a few parsing and linker errors below:

Error: expected `;' before...

For the error below we commented a ';' from line 104 of the source file of the PatExamples package:

>> Entering Package PhysicsTools/PatExamples

>> Compiling /afs/ 

/afs/ In member function 'virtual void PatBasicAnalyzer::analyze(const edm::Event&, const edm::EventSetup&)':
/afs/ error: expected `;' before 'histContainer_'

ALERT! Note: This is a simple error. The compiler explains you exactly what going in. The error occurs for line 107 (and not in line 104, which was modified by us) as there the next statement starts.

  • What's going on?
    The compiler found a statement that was not finished by a ';'.

  • What happened?
    You added a few lines of code to your module and forgot the ';' at the end of the input line.

  • What is the remedy?
    Add the ';' at the end of the indicated line.
In our example we uncommented the ';' in line 104 of the source file of the PatExamples package:


Error: expected `}' at end of input...

For the error below we commented a '}' from line 103 of the source file of the PatExamples package:

>> Compiling /afs/ 

/afs/ In member function 'virtual void PatBasicAnalyzer::analyze(const edm::Event&, const edm::EventSetup&)':
/afs/ error: a function-definition is not allowed here before '{' token
/afs/ error: a function-definition is not allowed here before '{' token
afs/ error: expected `;' before '__attribute__'
/afs/ error: expected `}' at end of input
gmake: *** [tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/PatBasicAnalyzer.o] Error 1

ALERT! Note: This error can be tricky as during the parsing a lost opening '{' or closing '}' brace may still lead to code that might be syntactically correct, but in the first places changes its meaning. Only after a few lines the grammar parsing fails and leads to this error. In our case of a missing '}' latest at the end a characteristic error occurred.

  • What's going on?
    The compiler found a missing '}', the following lines mit grammatically still be OK or lead to first parse errors. Latest at the end of the file the missing '}' beomes apparent.

  • What happened?
    You got mixed up with opening and closing braces. At the end you forgot one of them.

  • What is the remedy?
    This error is nasty as it is not always clear where it appears. The easiest way is to follow the indentation of your editor and in hard cases to comment and uncomment parts of the code step by step.
In our example we uncommented the '}' in line 103 of the source file of the PatExamples package:

Error: 'XXX' is not a member of 'yyy'...

For the error below we commented the .h file for the declaration of pat::Muons from the in the PatExamples package:

>> Entering Package PhysicsTools/PatExamples

>> Compiling /afs/ 

/afs/ In member function 'virtual void PatBasicAnalyzer::analyze(const edm::Event&, const edm::EventSetup&)':
/afs/ error: 'Muon' is not a member of 'pat'

ALERT! Note: This error equally holds for any other objects that you might have introduced in your code without declaring them to the compiler: reco::Muons, edm::InputTags or pat::Jets, ...

  • What's going on?
    The compiler found an object that has never been declared when parsing your source file. In our example this is the pat::Muon.

  • What happened?
    You added an object to your code which is not known a priori to the compiler. You have to make the declaration known in a .h file.

  • What is the remedy?
    Add the corresponding .h file that contains the declaration of the object you defined in your source code.
In our example we uncommented the corresponding .h file again:

#include "DataFormats/PatCandidates/interface/Muon.h" 

Error: undefined reference

All .so files needed to compile the executable are defined in the CMS.BuildFile of your package or corresponding subdirectories. The complete name of each corresponding .so file inherits from the name of the package and the subsystem the referred function is declared and implemented in. If you add the corresponding .so file of this package the error should be gone.

Some plugins in the PatExamples package make use of function that have been defined in the PatExamples package itself. For the error given below we commented the .so file of the PatExamples package from the CMS.BuildFile located in the plugins directory of the PatExamples package:

tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/ undefined reference to `PatBTagCommonHistos::~PatBTagCommonHistos()'
tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/ undefined reference to `PatBTagCommonHistos::Set(std::basic_string<char>, std::allocator >)'
tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/ undefined reference to `PatBTagCommonHistos::PatBTagCommonHistos(edm::ParameterSet const&)'
tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/ undefined reference to `PatBTagCommonHistos::Fill(boost::indirect_iterator<__gnu_cxx::__normal_iterator<pat::Jet const* const*, std::vector<pat::Jet const*, std::allocator<pat::Jet const*> > >, boost::use_default, boost::use_default, boost::use_default, boost::use_default>&, std::basic_string<char>, std::allocator >)'
tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/ undefined reference to `PatBTagCommonHistos::Sumw2()'
collect2: ld returned 1 exit status
gmake: *** [tmp/slc5_ia32_gcc434/src/PhysicsTools/PatExamples/plugins/PhysicsToolsPatExamples_plugins/] Error 1

ALERT! Note: This is a rare error, unless you start a project from scratch the BuildFiles you are using are pretty complete.

  • What's going on?
    The linker does not find the implementation of a function that you use in your code.

  • What happened?
    You used a function somewhere in your code and added the .h file where the declaration of the function can be found. You forgot to make the .so file known to the compiler in which the implementation (located in the .cc file in the corresponding package) is defined.

  • What is the remedy?
    Add the corresponding .so file in the CMS.BuildFile of your package. A safe way is to check for all packages that you used in your source code to declare your objects from the start on.
In our example we uncommented the corresponding .so file again:

<use   name="CMS.PhysicsTools/PatExamples"/> 

Python Errors

The common configuration language for cmsRun is python. Have a look at WorkBookConfigFileIntro to learn more about the structure of cmsRun configuration files. Have a look at this tutorial to learn more about python itself. Before starting cmsRun we recommend you to parse your configuration file for its syntactical correctness using the python interpreter. The way to do this is shown below for the examples of a typical configuration file in the PatExamples package:

python PhysticsTools/PatExamples/test/

A set of typical python errors is given below:

Error: 'Process' object has no attribute 'XXX'

Traceback (most recent call last):
  File "CMS.PhysicsTools/PatExamples/test/", line 137, in 
    process.step7      *
AttributeError: 'Process' object has no attribute 'step7'

ALERT! Note: For this error we introduced a typo in line 67 to the configuration file of the more complex analysis example in the PatExamples package.

  • What's going on?
    At least one module is not know to the python interpreter when checking the process path of the configuration file.

  • What happened?
    Most probably you introduced a typo in the definition of your modules or in the process path or you introduced a module in the path that you forgot to define before. Note that module definitions might also be hidden in imported file.

  • What is the remedy?
    The best cure might be to check all module definitions for their consistency. The linux tool grep might be of help for you.
In our example we corrected the typo in line 67:

process.step7 = countPatJets.clone(src = 'goodJets' , minNumber = 4) 

Error: No module named XXX

Traceback (most recent call last):
  File "CMS.PhysicsTools/PatExamples/test/", line 35, in 
  File "/afs/", line 409, in load
    module = __import__(moduleName)
ImportError: No module named topObjectSelection

ALERT! Note: For this error we introduced a typo in line 35 to the configuration file of the more complex analysis example in the PatExamples package. We omitted the "_cff" in the load command.

  • What's going on?
    There is a file specified an import or load statement that does not exist.

  • What happened?
    Either you introduced a file vie import or load that does not exist, or you introduced a typo in the file name or path.

  • What is the remedy?
    Check the path and name of the corresponding file in your working directory. Note that python directories are always omitted in the configuration file.
In our example we corrected the typo in line 35:


Error: XXX does not already exist

Traceback (most recent call last):
  File "CMS.PhysicsTools/PatExamples/test/", line 67, in 
    process.step7  = countPatJets.clone(src2 = 'goodJets'   , minNumber = 4)
  File "/afs/", line 297, in clone
  File "/afs/", line 221, in __raiseBadSetAttr
    raise TypeError(name+" does not already exist, so it can only be set to a CMS python configuration type")
TypeError: src2 does not already exist, so it can only be set to a CMS python configuration type

ALERT! Note: Again for this error we introduced a typo in line 67 to the configuration file of the more complex analysis example in the PatExamples package.

  • What's going on?
    At least one parameter of which you wanted replace a value does not exist in the definition of the module.

  • What happened?
    Either you introduced a typo, when specifying the parameter name or you really try to replace a parameter that does not exist. in rare cxases it happens that the module definition indeed changed under the hood from release to release.

  • What is the remedy?
    Check with the original definition of the module in the corresponding cfi file.
In our example we corrected the typo in line 67:

process.step7 = countPatJets.clone(src = 'goodJets' , minNumber = 4) 

Error: more than 255 arguments

Problem with configuration file ---- Configuration BEGIN
python encountered the error:  more than
255 arguments (, line 11) ---- Configuration END

ALERT! Note: This is a typical error that occurs if you have more than 255 input files for your source module.

  • What's going on?
    The python interpreter encountered a vector with more than 255 input arguments.

  • What happened?
    You introduced a vector or list in your python configuration file which has more than 255 arguments.

Runtime Errors

Runtime errors only occur when you execute cmsRun. In the following we are dealing with errors that occur in the use of cmsRun and in the interplay of different module in the communication among each other or with the event content. These are errors that can not by traced by syntactical checks of the compiler or python interpreter. we summarise a few very typical errors and their remedy below:

Error: Failed to open the file

%MSG-s CMSException:  AfterFile 15-Sep-2010 13:06:41 CEST pre-events
cms::Exception caught in cmsRun
---- FileOpenError BEGIN
---- StorageFactory::open() BEGIN
Failed to open the file 'wjets/patTuple_0_wjets10_madAODs.root' because:
---- File::sysopen() BEGIN
open() failed with system error 'No such file or directory' (error code 2)
---- File::sysopen() END
---- StorageFactory::open() END

RootInputFileSequence::initFile(): Input file file:wjets/patTuple_0_wjets10_madAODs.root was not found or could not be opened.

Error occurred while creating source PoolSource ---- FileOpenError END %MSG

ALERT! Note: For this error we specified an input file which does not exist.

  • What's going on?
    The cmsRun executable cannot open the specified input file.

  • What happened?
    Either the input file you specified does not exist, or you introduced a typo. Also take care that cmsRun needs the keyword file: to specify that the given file is to be specified locally.

  • What is the remedy?
    Check the file name and file location.
We give a typical example for a locally stored input file

process.source = cms.Source("PoolSource", fileNames = cms.untracked.vstring( 'file:wjets/patTuple_0_wjets10_madAOD.root' ) ) 

Error: Unable to find plugin 'XXX'

%MSG-s CMSException:  AfterModConstruction 15-Sep-2010 13:30:37 CEST pre-events
cms::Exception caught in cmsRun
---- PluginNotFound BEGIN
Unable to find plugin 'PatTopSelectionAnalyser'. Please check spelling of name.
---- PluginNotFound END

ALERT! Note: For this error we introduced a typo in the module definition of the file of the more complex analysis example in the PatExamples package. We replaced the 'z' by an 's' in the first argument, which specifies the corresponding plugin "PatTopSelectionAnalyzer".

  • What's going on?
    In the configuration file a module is called for which no plugin exists.

  • What happened?
    Either you introduced a module in your configuration which really has no correspondence in the list of plugins (this can happen if you forgot to compile the package you are working with) or you introduced a typo what specifying it.

  • What is the remedy?
    Check the plugin name you were really out for. The first step would be to grep in what module definition the plugin is specified. Next you can check whether this module really has no correspondence in the list of plugins (in our example typing edmPluginDump | grep PatTopSelectionAnalyser would do the trick). Finally you can check the correctness when looking into the plugin registry step (in our example indicated in the last line of
We summarise again the steps to trace this error down:

grep -r PatTopSelectionAnalyser PhysicsTools/PatExamples
CMS.PhysicsTools/PatExamples/python/ = cms.EDAnalyzer("PatTopSelectionAnalyser",
Binary file PhysicsTools/PatExamples/python/PatTopSelectionAnalyzer_cfi.pyc matches
edmPluginDump | grep PatTopSelectionAnalyser
emacs PhysicsTools/PatExamples/plugins/

Error: No "JetCorrectionsRecord" record found in the EventSetup

cms::Exception caught in cmsRun
---- EventProcessorFailure BEGIN
---- ScheduleExecutionFailure BEGIN
---- NoRecord BEGIN
No "JetCorrectionsRecord" record found in the EventSetup.
 Please add an ESSource or ESProducer that delivers such a record.

ALERT! Note: This error can occur in two ways. The most direct way is indeed that you want to make use of a jet energy corrections service in you code, but did not not specify it in the configuration file. In the transition from CMSSW_3_6_X to CMSSW_3_8_X it might also happen that you specified the proper jet energy correction service but did not use the correct CMS.GlobalTag. As a transition of the jet energy correction constants from bare txt files to the conditions data base took place between these two release cycles even when you specified the proper jet energy correction service you will get the same error in this special case.

  • What's going on?
    In one of your modules you try to use a jet energy correction service, which is not known to cmsRun.

  • What happened?
    Either you added a jet correction service in on of your modules but did not specify it in your configuration file or (in rare cases) you did everything right but do not use the proper CMS.GlobalTag.

  • What is the remedy?
    Specify the jet energy correction service in you configuration file or move to the porper CMS.GlobalTag.
We give the example of specifying the correct jet energy correction service in your configuration file, as this might be the most common source of this error. Therefore add the following lines to you configuration file:

## load jet corrections process.load("JetMETCorrections.Configuration.JetCorrectionServicesAllAlgos_cff") process.prefer("ak5CaloL2L3") 

The exact choice of the correction service might depend on the jet collections you are going to use. Please have a look to SWGuideJetMet, or contact the corresponding experts for more details.

Error: Found zero products matching all criteria

cms::Exception caught in cmsRun
---- EventProcessorFailure BEGIN
---- ScheduleExecutionFailure BEGIN
---- ProductNotFound BEGIN
getByLabel: Found zero products matching all criteria
Looking for sequence of type: reco::Candidate
Looking for module label: goodJet
Looking for productInstanceName: 
cms::Exception going through module PATCandViewCountFilter/step6a run: 1 lumi: 2 event: 1369557
If you wish to continue processing events after a ProductNotFound exception,
add "SkipEvent = cms.untracked.vstring('ProductNotFound')" to the "options" PSet in the configuration.
---- ProductNotFound END
Exception going through path looseEventSelection
---- ScheduleExecutionFailure END
an exception occurred during current event processing
cms::Exception caught in CMS.EventProcessor and rethrown
---- EventProcessorFailure END

ALERT! Note: For this error we introduced a typo in line 64 to the configuration file of the more complex analysis example in the PatExamples package. We introduced a collection which is not part of the event content and has not been produced before.

  • What's going on?
    One of the modules that is scheduled in the process path of your configuration file is looking for a object collection which is not part of the event content.

  • What happened?
    Either the object type, module label or instance label of the collection your module is trying to load is not correct or you forgot to produce the corresponding collection beforehand.

  • What is the remedy?
    Make sure that the collection your module is trying to load really exists.
There is two ways to check the event content of the file you are processing. With the edmDumpEventContent tool you will get an overview of all persistent objects, which are part of the event content of the input file you are using. We give an example for a special PAT tuple below:

[rwolf@tcx061]~/scratch/CMSSW_3_8_2/src% edmDumpEventContent top/patTuple_top_madgraph.root_ttbar10_madAOD.root 
edm::TriggerResults               "TriggerResults"        ""            "HLT8E29."     
edm::TriggerResults               "TriggerResults"        ""            "HLT."         
edm::TriggerResults               "TriggerResults"        ""            "REDIGI."      
edm::TriggerResults               "TriggerResults"        ""            "RECO."        
vector              "offlinePrimaryVertices"    ""            "RECO."        
edm::OwnVector >     "selectedPatJets"       "tagInfos"    "PAT."         
edm::TriggerResults               "TriggerResults"        ""            "PAT."         
vector                 "selectedPatJets"       "caloTowers"    "PAT."         
vector             "selectedPatElectrons"    ""            "PAT."         
vector                  "selectedPatJets"       ""            "PAT."         
vector                  "patMETs"               ""            "PAT."         
vector                 "selectedPatMuons"      ""            "PAT."         
vector              "selectedPatJets"       "genJets"     "PAT."         
vector         "selectedPatJets"       "pfCandidates"    "PAT." 

Alternatively you can define the EventContentAnalyzer module and place it at an arbitrary position in front of the module which causes you trouble:

## check the event content
process.content = cms.EDAnalyzer("EventContentAnalyzer")
process.p = cms.Path( ... process.content * ... ) 

Error: InvalidReference

%MSG-s CMSException:  AfterFile 02-Jun-2010 14:31:43 CEST PostEndRun
cms::Exception caught in cmsRun
---- EventProcessorFailure BEGIN
---- ScheduleExecutionFailure BEGIN
---- InvalidReference BEGIN
BadRefCore Attempt to dereference a RefCore containing an invalid
ProductID has been detected. Please modify the calling
code to test validity before dereferencing.
cms::Exception going through module PatMCMatching/analyzePatMCMatching run: 1 lumi: 666672 event: 305
---- InvalidReference END
Exception going through path p
---- ScheduleExecutionFailure END
an exception occurred during current event processing
cms::Exception caught in CMS.EventProcessor and rethrown
---- EventProcessorFailure END

ALERT! Note: In CMSSW composed (or high analysis) objects very often internally refer to the lower level analysis objects they are composed of via pointer relations. A typical example is a reco::Muon pointing to the inner track it was created from. The above problem occurs if you try to dereference such a object pointer to a lower level analysis object which is not part of the event content any more. In our example the reco::Muon would still point to an inner track which has been dropped from the event content at some earlier processing step.

  • What's going on?
    There is an object in your analysis code that is referring to another object which is not in the event content any more.

  • What happened?
    You try to read out some information via a pointer to a lower analysis object. You did not check whether this pointer still refers to a valid object or not.

  • What is the remedy?
    Make sure that each pointer you are calling refers to a valid object via a NULL pointer request. The information you wanted to address does not exist anymore on the input file that you are using.
In our example add the following line to your analysis code:

if(!muon.innerTrack().isNull()){ //now go on if the innerTrack pointer really corresponds to a valid object... } 

Unfortunately the information you wanted to have is most probably lost from the input file you are using. Due to the 'hidden' reference structure of the hogh analysis objects it is non trivial to reduce the file size of an AOD/RECO input file without loosing analysis relevant information. The Physics Analysis Toolkit (PAT) tries to assist you on this quest. Have a look at SWGuidePATEmbeddingExercise to learn more about this.

Useful tools for debugging your code

Useful tools for debugging your code are documented here

Review status

Reviewer/Editor and Date (copy from screen) Comments
JohnStupak - 16-September-2013 Review
RogerWolf - 15 Sept 2010 Complete overhaul

Responsible: SudhirMalik and MargueriteTonjes

A.3 Basic Linux Commands

Complete: 5
Detailed Review status

Goals of this page:

This page is intended to provide some basic linux commands and references to more linux information.



With the commands listed in this topic you can do most basic operations for file management and executing scripts. CMS-specific commands, such as running the CMS software, are discussed in other sections of the WorkBook.

Linux Basics

Linux has a hierarchical filesystem, supporting many levels of directories, with case-sensitive filenames, directory names and commands. Filenames should not be stored with spaces (as this can cause problems for some scripts, and needs special care in any case), and the only punctuation that should be used in filenames is the dot (.), underscores are allowed. Generally filenames in linux are of the form, where xyz is a 2- or 3-letter combination which indicates the file type (e.g. txt for a text file, .C for a C-based macro (usually root), ps for a postscript file, ...).

In Linux the slash (/) is used to separate directories, by contrast with the backslash (\) used in Windows. There are three 'special' directories

  • . indicates the current directory
  • .. refers to the directory above the current directory (the parent directory)
  • ~ is the users 'home' directory - the directory you start in when you login
Each user belongs to one or several groups and when working will be using one of these groups. Each file and directory has an owner and a group associated. In addition to that there are several permission flags which specify if the file(directory) is readable, writable and/or executable. In example:

-rw-r--r-- 1 livio zh 22769 Jan 17 16:26 myfile.txt

permissions are summarized by -rw-r--r-- which is composed by 4 different fields :

  "-"       "rw-"      "r--"      "r--" 

First field "-", specifies if it's a file, a directory or a link. Other fields define the "user", "group" and "others" permissions by a set of 3 characters "rwx" (read, write and execute). In the analyzed example "livio" is the user and "zh" is the goup related to the file. Summarizing the permissions for file "myfile.txt": all the users can read the file but only the user "livio" can modify it.

When working in Linux, you will activate a terminal , and inside the terminal shell will be running, i.e. a program interpreting your commands. Commands are typed inside this shell, and you press ENTER to issue them. For most commands, additional arguments can be issued by using minus signs (where \ signs are used in Windows), e.g. command -a - b -c or command -abc. To find out what options are available for a given command, and what those options do, type command --help, which works in most cases, or try to see more detailed information with the man command.

Filenames can be specified using two types of wildcards:

  • a * represents 0 or any combination of characters, e.g. for* can refer to fore, forest, fort, for etc if such files exist,
  • a ? represents any signal character, i.e. in this example for? can refer to fore or fort, but not forest. nor for

You need to be very careful when deleting files using wildcards to specify filenames (just rm * removes everything!! rm -i * will ask you interactively)

Different shells

Linux comes in 2 different flavours: Bourne shells (sh, ksh, bash,zsh) and C shells (csh,tcsh), which differ only in some small respects (environment variables, redirection,...) but not in the principles. Shells have more or less been developed as given in these lists from left to right, i.e. bash will be more powerful than its ancestor ksh, and tcsh more powerful than csh. Where necessary, both forms will be given in what follows

You can switch from one shell to the other just by typing , e.g., /bin/bash, or /bin/tcsh, which can be useful in case a macro or a documentation comes only in one flavour (you may prefer to do bash --login for instance to properly run login scripts). But attention, in some cases this may screw up your environment!

In order to know which shell is the default for you (as decided by the system administrator), type echo $SHELL.

In order to know which shell you are actually using, type echo $0.

Commonly used Linux Commands

Command Usage
pwd Find out directory you are currently in
cd dir1 Change to directory dir1 below the one you are in
cd /home/user/dir2 Change to directory dir2 from anywhere
cd .. Change to the parent directory of the one you are currently in
cd Change to your home directory
mkdir dir1 Create directory dir1 as a subdirectory of the one you are in
mkdir /home/user/top/dir2 Create directory dir2 from anywhere (requires directory structure above dir2, already exists)
rmdir dir1 Delete directory dir1 below the one you are in. (rmdir only works if the directory is empty.)
rmdir /home/user/top/dir2 Delete directory dir2 from anywhere
ls list the contents (files, symbolic links and directories) of the current directory
ls dir1 List contents of subdirectory dir1 of the directory you are in
ls /home/user/top/dir2 List directory dir2 from anywhere
ls -ltrA Produce a long listing (-l) with the latest modification date (-t) last (-r), showing almost all hidden files (those starting with a dot, except "." and "..") (-A)
cat file.txt Display the contents of a (text) file on the screen
tail file.txt Display the last 10 lines of a (text) file on the screen
more file.txt Display the contents of a (text) file on the screen, one screen at a time
less file.txt Display the contents of a (text) file on the screen, allowing to scroll both upwards and downwards; use less -S file.txt to also scroll sideways
rm file1 Delete file file1 from the current directory
rm /home/user/top/file2 Delete file file2 from anywhere
rm *.txt Delete all the files ending in .txt in the current directory
rm -i *.txt Delete all the files ending in .txt in the current directory after having asked for confirmation
rm -R dir1 Recursively delete all files in all directories below dir1 including dir1 itself
mv oldfile newfile Rename (move) oldfile to newfile in the current directory
mv oldfile /home/user/top/oldfile Move oldfile to the directory /home/user/top
chmod ug+rx file1 Change permissions on file1 for user and group to readable and executable (+rx)
chmod go-r file1 Change permissions on file1 for group and other users to unreadable (-r)

Checking the directory quota

You can check how much space you have available in your directory with the command fs lq (at lxplus).

Environment variables

You can define 'environment variables' which you can use to change the behaviour of your shell scripts or programs. echo $Var will print the value of the environment variable Var, printenv will print all environment variables that are defined in your shell.

Syntax for setting a variable is different for Bourne shells and C shells. To set the environment variable Var to contain the string xyz you will type

  • in Bourne Shells

export Var=xyz

  • in C Shells

setenv Var xyz

Redirection of output

A command in UNIX will very often issue some normal output (called stdout), and some error output (called stderr). You may redirect output to a different destination in various waysusing > (= redirect to) or >> (= append to). For example, if Var1 was set to =xyz, and Var2 to 123, and you type echo $Var1 >myfile, followed by echo $Var2>>myfile, the file myfile will contain the 2 lines xyz and 123.

Redirection to /dev/null will suppress the output.

There are 2 output streams, stdout for normal output, stderr for warnings. Here syntax is different in the 2 shell families:

  • in Bourne Shells
command> myfile will redirect the stdout of command to myfile

command 2> myfile will redirect the stderr of command to myfile

command 1 > myfile 2>&1 will redirect the stdout of command to myfile, and the stderr to the stdout, ie.e to the same file

  • in C Shells
command> myfile will redirect the stdout of command to myfile

command >& myfile will redirect the stderr of command to myfile

command  >& myfile will redirect the stdout and the stderr to myfile

(command >out) >& err will redirect the stdout of command to out, and the stderr to err

You may also redirect output from one command to be input for a second command using a pipe (= |):

ls -l | more

will display the output from ls inside more, i.e. one screen at a time.

Running Commands from a File

The command source myfile (. myfile in C-shells) executes the commands stored in myfile. This would normally be a shell script or file.csh. You can search the internet for "shell script reference" or a similar string, and find many references to help you get started writing shell scripts.

There are several powerful scripting languages used in Unix, like python or perl.

More information on scripting can be found in the documentation links given below, or by carrying out a basic internet search.


grep is a filter, i.e. searches for strings inside a file:

command | grep txt will show all output lines of command containing the string txt.

command | grep -v txt will show all output lines of command except those containing the string txt.


  • vi
is a text editor which is , in its simplest form, present on all Linux systems.

  • emacs
is a very powerful and popular GNU text editor

  • nano
Very simple on screen text editor

Links to further documentation

Information Sources

SteveLloyd is the original author - see WorkBookAcknowledgements.

Review status

Reviewer/Editor and Date (copy from screen) Comments
MargueriteBeltTonjes - 16 Nov 2020 fix broken links, ensure information up to date
AnneHeavey - 17 May 2006 updates after review by Kati L-P
JennyWilliams - 18 May 2006 updates after review by Kati L-P
UrsulaBerthon - 23 Jan 2008 updates
-- JohnStupak - 18-September-2013 Review

Responsible: SudhirMalik
Last reviewed by: UrsulaBerthon - 23 Feb 2008

A.4 ROOT Basics

Complete: 5

Goals of this workbook page

When you finish this page, you will be able to

  • Open and close an interactive ROOT session
  • Create and manipulate simple histograms
  • Use provided resources to learn how to do further tasks with ROOT
For further information on fitting a distribution, go to the page WorkBookHowToFit.



ROOT is an analysis package written in an object-oriented structure in C++. It uses built-in functions and user-compiled code to produce graphics and histograms, as well as trees with data objects. ROOT files can be easily navigated using a GUI Object Browser.

The new CMS event data model (EDM) is based around the idea that people will use ROOT both in a normal "framework application", and by interactive manipulation of tree objects and histograms. The full CMS software structure to use ROOT has an analysis environment is currently under construction, and will become a powerful tool for CMS physics analyses.

Interactive ROOT sessions are conducted using an extension to C++ called CINT. This allows a slightly lazy use of C++, including allowing the use of a dot '.' to access a pointer object rather than the strict C++ arrow '->', and further shortcuts in creating new pointer objects. A help menu of CINT commands can be accessed using '.?'.

Most objects in ROOT can be accessed by familiar names, adding a '_t' as a suffix to data types, and a 'T' prefix to object classes, e.g. Float_t, Double_t, TClass, TFile, ...

The ROOT homepage

The ROOT system homepage is hosted at CERN, and contains many example files, tutorials, How-Tos, FAQs, program downloads and other help. The homepage URL is

Starting a ROOT session


These instructions enable you to start a ROOT session when logged into a CERN lxplus machine. You will need to contact your local system expert for information on using ROOT on local machines.

The best way to use ROOT is to run it from a software release that you have already checked out and you are working in. Details of how to set up a software release are given in the WorkBook chapter on Setting up your Working Environment.

If you don't have a release checked out, you can quickly set one up in order to continue this workbook chapter and learn about ROOT with the following commands:

setenv SCRAM_ARCH slc6_amd64_gcc700

cmsrel CMSSW_10_2_18

cd CMSSW_10_2_18/src


If you already have a software release setup, leave out the cmsrel command and do the rest.

You need to do this (apart from cmsrel) every time you want to use the CMS software environment and to use ROOT, as this method sets up the correct paths for you to be able to access the ROOT program which is compatible with the software release that you are currently using.

With those preliminaries completed, start your ROOT session:

root -l

The -l is optional and it speeds up the startup by skipping the start screen.

You are now in an interactive ROOT session, and should see the root prompt.

Most commands in ROOT are delimited by a semicolon, and all commands saved in macros (small files containing several ROOT commands designed to work together to complete a specific task) should be written in strict C++. Additionally, most objects created in ROOT are really pointers to objects. To fully appreciate this distinction you will need to become familiar with the concepts of pointer objects in C++, though the greatest necessity to understand pointer objects when using ROOT is in writing correct C++ syntax for macros, which comes a little later in this WorkBook topic.

Omitting the semicolon at the end of a command, ROOT can be used as a quick calculator, e.g.


The system should respond with something like:

(int) 51

If you put the semicolon at the end of this line, no return value would be displayed.

The next important step that you must know if you are to use ROOT is how to end a session. To exit a root session, use a dot followed by a q:


Windows and Macintosh (10.12/10.13)

Instructions to set up processes like X11 forwarding to run ROOT remotely from Windows and Macintosh machine are on WorkBookSetComputerNode#XeleVen

Enough ROOT to Run WorkBook Tutorials

Say you have a file called MyOutputFile.root that you wish to examine using one of the analysis modes described in WorkBook chapters 3 and 4. The following sequence of commands loads the file and opens a browsing window, known in ROOT as a TBrowser.

$ root 
root[0] TFile f("MyOutputFile.root");
root[1] new TBrowser

Once you get to the browser, double click down the chain till you get what you're looking for (for example tracks: MyOutputFile.root -> Events -> recoTracks_generalTracks__RECO -> recoTracks_generalTracks__RECO.obj). When you get to a plottable "leaf" (the end of a branch in the tree structure), a double-click will create the plot.

Instead of going through the TBrowser each time, you can set an alias for a branch you want to access. Select a branch name visible in the TBrowser, add obj at the end, and think of a short alias. It's up to you to choose which aliases to use. E.g., set the alias for an object named recoTracks_generalTracks__RECO.obj to tracks:

root[2] Events->SetAlias("tracks","recoTracks_generalTracks__RECO.obj");

Using this alias, go ahead and plot some aspect of the track, e.g., its normalized chi-squared (chi-squared over number of degrees of freedom) :

root[3] Events.Draw("tracks.chi2_/tracks.ndof_");

To use the Python interpreter in ROOT rather than the CINT interpreter, the commands for startup are:

>>> from ROOT import *
>>> gSystem.Load("")
>>> FWLiteEnabler.enable()

To load a file and to open a browser, type:

>>> myFile = TFile("MyOutputFile.root")
>>> myBrowser = TBrowser()

For more information, see FWLite in Python.

ROOT Histograms

The main analysis use in ROOT is the production of histograms to represent usefully-binned data. ROOT can produce 1-D, 2-D and 3-D histograms. This WorkBook section will teach you to make create your first histogram, display it, put some data in it, and perform basic histogram manipulations.

Making your first ROOT histogram

We shall create a basic 1-D histogram, declaring it as a pointer object, and will fill it with floating point numbers - the most general histogram application you are likely to want. The required syntax to "book" a histogram is:

TH1F *hist_name= new TH1F("hist_name","hist_title",num_bins,x_low,x_high);

where the various components are:

the ROOT 1-D histogram class
the name of your histogram - this is how you refer to your histogram to perform manipulations on it. If you save the histo into a file this will be the name by which the histo is stored
this title will appear when you print your histogram (either to screen or in hardcopy)
an integer defining the number of bins that will appear in the histogram
the value of the lower edge of the first bin
the value of the upper edge of the last bin

Histograms in ROOT have two additional bins which are reserve for entries that fall below the bin limits (underflow - bin 0), and for entries that are equal to or larger than x_high (overflow - bin num_bins+1). When booking your histograms you should specify x-low and x-high as real numbers rather than integers, using 10. rather than 10 for example, if you want a bin limit to be the value 10 but to store real numbers rather than have them truncated to integers before being stored.

To book 2-D or 3-D histograms, an analogous syntax is used, for example:

TH2D *h2= new TH2F("2","2d hist title",num_xbins,x_low,x_high,num_ybins,y_low,y_high);

Now to put this into practice. Start up a ROOT session, and book a brand new histogram by entering:

TH1F *hist1= new TH1F("hist1", "My First Histogram", 100, 5., 50.);

Nothing happens! While you have booked your histogram, and therefore created a pointer to a 1-D histogram, to be filled with floats which will be put into 100 bins ranging from 5 to 50, you haven't yet told ROOT to draw it. Do this now with:


The system should respond with something like:

root [1] hist1.Draw()
<TCanvas::MakeDefCanvas>: created default TCanvas with name c1

and a new window (a ROOT "canvas") will be with your new histogram. You should see an empty histogram with the title "My First Histogram", which should look something like:


Histogram manipulations

Filling a histogram with discrete data

Histograms can be filled using the Fill() function in ROOT. Depending on the type of histogram you have declared (number of dimensions, type of data to be input - double/float/...), you can pass numbers to your histogram of the appropriate datatype and the corresponding bin will be incremented. Our new histogram, hist1 has type TH1F, which means that it expects data in the form of floating point numbers. The Fill() function can take individual numbers (which are then filled with weight 1), or can accept weights for numbers (e.g. representing a number of entries at the particular x-value). For example, enter:


The last command gets ROOT to draw the updated histogram, producing a result which should look something like:


The ROOT histogram "Print" function

To see information about a particular histogram you need ROOT's Print() function


For the histogram created and filled above, the system should respond with:

TH1.Print Name = hist1, Entries= 3, Total sum= 6

To see the entire histogram contents, you want:


for which the system responds by printing the bin number, the number of entries in each bin, and the values for the upper edge of each bin. Our histogram is fairly empty, so most entries are zero, however a snippet of the output which contains a non-zero entry is:

 fSumw[61]=0, x=32.225, error=0
 fSumw[62]=0, x=32.675, error=0
 fSumw[63]=0, x=33.125, error=0
 fSumw[64]=0, x=33.575, error=0
 fSumw[65]=3, x=34.025, error=3
 fSumw[66]=0, x=34.475, error=0
 fSumw[67]=0, x=34.925, error=0
 fSumw[68]=0, x=35.375, error=0
 fSumw[69]=0, x=35.825, error=0
 fSumw[70]=0, x=36.275, error=0
 fSumw[71]=0, x=36.725, error=0
 fSumw[72]=0, x=37.175, error=0
 fSumw[73]=0, x=37.625, error=0

To save these numbers, you can dump the contents of a histogram into an ASCII (text) file by directing this output to a file with

hist1->Print("all"); > hist1contents.txt

(remembering to use the semicolon in the command).

Using the stats box

When you plot a histogram using ROOT's default settings, a statistics box appears at the top-right of the plot showing information such as the histogram's name (the histogram title appears at the top left, and is separate to the stats box), the number of entries, mean, etc. The attributes shown in this box are set with the command:


where mode is a 6-digit number with 1's (on) and 0's (off), represented by the quantities (ourmen)

o number of entries in overflow box
u number of entries in underflow box
r rms of distribution
m mean of distribution
e total number of entries
n histogram name
The default is (001111) which means that rms, mean, total number of entries and histogram name are shown in the stats box.

Some useful points about the stats box:

  • if less than 6 numbers are given, e.g. gStyle->SetOptStat(11);, the parameters are read from the right - i.e. in this example, only the number of entries and the histogram name will be shown.
  • after changing the SetOptStat() options, you need to redraw the histogram using Draw() to display these updated options
  • the stats box options are a property of the ROOT pad - as such, all histograms plotted on the same pad will have a stats box made with the current settings
  • to reset to the default settings, use: gStyle->SetOptStat();
  • to turn off the stats box entirely, use: gStyle->SetOptStat(0);

Changing the histogram appearance

Other improvements can be made to the readability and presentation of your histogram - for example changing colours, labelling axes, changing font types and sizes. Some of these options are described in this section, while further options for improving the presentation of your histogram are given in the section on legends.

Colours in ROOT are defined through 8 default numbered colour references (plus White) and through a selection of enumerated colour types. The numbers you can use to refer to colours are:

Colour Number
White 0
Black 1
Red 2
Light Green 3
Blue 4
Yellow 5
Magenta 6
Cyan 7
Green 8
While the enumerated types that can also be used are: kWhite, kBlack, kRed, kGreen, kBlue, kYellow, kMagenta, kCyan.

To change the colours of the lines plotted in your histogram, try


Please do not use colours 3 (light green), 5 (yellow) and 7 (cyan) in your presentations as they will not be visible when your slides are projected.

A few other options that you can explore to enhance the appearance of your histogram are:

hist1->GetXaxis()->SetTitle("Label of x axis");
hist1->GetYaxis()->SetTitle("Label of y axis");

gROOT->SetStyle("Plain");             // Turns off ROOT default style
gPad->UseCurrentStyle();              // removes red box about histo, all Black/White
gROOT->ForceStyle();                  // ROOT needs encouragement to change its style

Finally, to get larger labels, put in some axis titles and add Greek fonts to your histogram:

gPad->SetLeftMargin(0.15);    // experiment with the best value for you.
                              // Depends on font size for your text



hist1->SetXTitle("`f[#circ]"); // degree symbol, just like LaTeX,
                                // (using "#" instead of "\")
hist1->SetYTitle("Entries / bin");

Comparing two histograms

A common use of histogramming ROOT is to compare two (or more) distributions. This can be achieved by plotting the histograms on the same canvas (in fact, on the same pad, to see them overlapped). More usefully, the histograms should be plotted in different colours and a key (referred to in ROOT as a legend) should be provided to clearly distinguish between the distributions.

Plotting two histos on one canvas

To show how to plot two histograms on one canvas (one pad, in fact, in this example), we need to quickly book and fill a few bins of a new histogram:

TH1F *hist2 = new TH1F("hist2","Another Histogram", 100,2.,100);

When you draw the histogram, hist2->Draw();, by default ROOT clears the current active pad and freshly draws the new histogram. We can however force ROOT to display both histograms at the same time, with:

hist2->Draw();             //draw our brand new histogram
hist1->Draw("same");   //draw our original histogram on the same pad as hist2

Putting this new knowledge together with what we have learned about setting colours, we can clear the canvas and plot both histograms with different colours:

c1->Clear();                   //remember that this is the name of the default canvas

hist1->SetLineColor(8)       //green
hist2->SetLineColor(4)       //blue
gStyle->SetOptStat(11);      //Display title and total number of events only
hist2->Draw();               //draw hist2 first as it has a larger range

The two histograms on the same canvas should look something like:


Note that unless you manually set the axis ranges, these will be set to the most appropriate values for the first histogram which was drawn.

Adding a legend and further text to your histogram

We now need to add a legend to our masterpiece to be able to distinguish between the two plots. It is often also useful to add some additional descriptive text. Since these tasks are similar, they will both be handled in this section.

To add a legend to your histogram, we can do:

leg = new TLegend(0.6,0.7,0.89,0.89);  //the coordinates put the legend corners
                                       //various fractions of the way along the canvas
leg->AddEntry(hist1,"First histo","l") //"l" for a line
leg->AddEntry(hist2,"2nd histo","l")   //use "f" for a box to show which colour
leg->SetHeader("My first histos");     //Might as well add a label to the legend box
leg->Draw();                           //Draw updated legend with title

Other useful legend drawing options include:

leg->SetTextSize(0.04);                //change size of legend text
leg->SetFillColor(0);                  //have a white background on the legend box

Text boxes are added similarly, they are called TPaveText objects.

TPaveText *pt = new TPaveText(0.20,0.7,0.5,0.87,"NDC");
                 //note the strict C++ syntax (not required for interactive CINT)
                 // NDC sets the coordinates relative to the dimensions of the pad
                 // useful if you might change the layout of your histos
pt->SetFillColor(0);  //text now is black on white

text = pt->AddText("Whatever you want");

pt->Draw();       //to draw your text object

Copying histograms

Identical copies of histograms can be made by cloning, with the command

TH1F *new_hist=(TH1F*)hist1->Clone();

Adding error bars

Error bars can be added to ROOT histograms by drawing the histogram with the option esame:


By defaut, errors shown are the square root of the bin entries. To show error bars as sqrt(sum of weights), before filling your histogram, issue the command:


Some drawing options for 2-dimensional histograms

There are many different drawing options available for histogramming in ROOT - you could consult to discover some of the possibilities. Drawing options that you might like to experiment with for 2-D histograms include


Saving and printing histograms

Saving histograms as image files

Histograms can be saved from the ROOT canvas as image files in ps, eps or gif formats (as well as in C++ macros see Source Code section)

To save your histogram to an image file, plot it (assuming here it is plotted on the default canvas c1), then save your file in the desired format by stating the extension you want:


Alternatively you can click on "File" in the upper left corner of the canvas and use the save options in that menu.

Saving histogram source code

Any histogram which is plotted is described by an underlying set of C++ source code. You can save that source code in a file to later rerun (e.g. to change titles or other attributes of the histogram) with the command (assuming your histogram is printed on the default canvas, "c1"):


Alternatively, you can save the file by clicking on the options "File", "Save", and selecting c1.C.

You can then recreate the histogram in exactly the same from that you saved it in a brand new ROOT session by entering:

.x c1.C

(or select "SaveAs", and select myImage.C). To execute the macro c1.C and create a histogram with the entries and layout that you saved. It is also possible to directly edit the c1.C file that you created.

You should try saving an empty histogram (so that the data doesn't hide the details of the histogram definition) and look through the resultant source code file, as it contains useful commands for defining how your histogram looks.

Inspecting histograms saved infiles

You can look at histograms which were created in ROOT and saved to files, generally with the extension .root. Say you have a ROOT file called "myHistofile.root", you can open it with:

TFile f("myHistofile.root");

where this command is a CINT shorthand to open the file and and load its contents into a temporary file in your ROOT session called "*f*". To look at the contents of the file enter:;

And a listing will show the filename, list histograms, and also list any directories or other objects that are present in the ROOT file. Having just opened the file, the ROOT focus is on that file, and you can draw the contents, say of a histogram called h1d4 if it was contained within that file with:


As in the earlier examples, you can add entries to the bins in the histogram with the Fill(...) command, and redraw the output with another Draw() command.

Accessing histograms saved in files

Loading an existing ROOT histogram

A histogram which is already loaded into a ROOT session, e.g. having been created or loaded from a file, can be accessed by creating a pointer to it with the command

TH1F myHist=(TH1F) gDirectory->Get("name of histogram");

Changing between active files

When you have more than one open ROOT file, ROOT keeps its focus on only one file at a time. You can operate on any of the opened files by referring directly to those files using their reference names (e.g. "file1" in the example below). Additionally, if you have opened two files with, say,

TFile *file1=new TFile("firstfile.root");
TFile *file2=new TFile("secondfile.root");

you can perform actions on the first file you opened by changing ROOT's focus to that file with:;

Similarly, you can change back to the other file when you want to address file2. This enables you to open several files and move between them using potentially the same commands on objects saved in each file.

Getting help with ROOT

ROOT tutorials

Many useful ROOT tutorials can be found on the web. Often these provide solutions to problems, or at least some sample code to get started on a particular task. You should beware that some of the information in the following tutorials is specific to the particular experiment or institute the tutorial was designed for, however the following tutorials contain very useful information:


This Introduction to ROOT WorkBook topic originates from the Babar Workbook chapter Root I (original author: JennyWilliams).

Review Status

Editor/reviewer and date comments
JennyWilliams - 19 Nov 2006 Removed stuff on X11 forwarding to WorkBookSetComputerNode
JennyWilliams - 29 May 2007 fixed get/set axistitle command errors
JohnStupak - 20-September-2013 Review and change to 5_3_5
jhovanny.andres.mejia.guisao 06-November-2017 Review and update to 9_3_2
NitishDhingra - 2020-10-14 Review, fixed typos and updated to 10_2_18
Responsible: SudhirMalik
Last reviewed by: JennyWilliams - 21 Nov 2006

A.5 A 30-Second Introduction to SCRAMv1

Complete: 5
Detailed Review status

SCRAM (Source Configuration, Release, And Management tool) is the CMS build program. It is responsible for building framework applications and also making sure that all the necessary shared libraries are available. There are two versions of SCRAM. SCRAM v0.2 is used for the LCG projects SEAL and POOL and early versions of ORCA, while SCRAM v1 is used for the newer CMSSW. We will only talk about SCRAM v1 here.

Main Commands

There are a few main commands:

1. To build subdirectories of the current directory:

$ scram build
$ scram build MyAnalysis
2. To setup your runtime environment (for cmsRun for example). Do a cd to your project directory.
$ cmsenv
3. To make a new work area
$ scram project CMSSW [version]
4. To rebuild, clean up (needed sometimes)
$ scram build 
$ scram build clean

Useful Options

There are other build command options which are useful (these options can be used in combination):

scram b -f
Skip reading the cache; useful for when you know that no BuildFiles or source files have been modified, added or removed. Seems that modified source file (under src/) are no problem, as they are build as expected.
scram b -v
Verbose mode: show the full compilation/linking commands.
scram b -k
Continue building after any errors from Make
scram b -j [n]
For building in parallel using [n] processes (same as -j of GMake)

For more detail on SCRAM please read SWGuideScram
For more detail on SCRAM Buildfiles please read the WorkBookBuildFilesIntro.

Review status

Reviewer/Editor and Date Comments
JohnStupak - 20-September-2013 Review
ShahzadMuzaffar -17 Nov 2009 Replace scramv1 by scram, updated for -j option and common way of setting runtime environment
pieta - 07 May 2007 update of scramv1 b -f
AnneHeavey - 13 Nov 2006 update per Shaun Ashby's review comments
AnneHeavey - 06 Apr 2006 updated links and format
AnneHeavey - 17 Feb 2006 new page

Responsible: ShahzadMuzaffar
Last reviewed by: ShahzadMuzaffar - 17 Nov 2009

A.6 On BuildFiles

Complete: 5
Detailed Review status

Package BuildFiles

SCRAM uses a file called CMS.BuildFile in each package directory which describes what the package will produce and what dependencies the package has. Consider the following CMS.BuildFile from the tutorial:

<use name="root"/>
<use name="DataFormats/HcalRecHit"/>
<use name="TBDataFormats/HcalTBObjects"/>
<use name="FWCore/Framework"/>
<use name="FWCore/ParameterSet"/>
<flags EDM_PLUGIN="1"/>

The first part of the CMS.BuildFile tells SCRAM what packages or external libraries (e.g., ROOT) are needed to build this package. The <flags> line is needed because this package contains a framework module (in this case, your analyzer) which must be registered with the plugin system .

Other BuildFiles

Here we give some examples of CMS.BuildFile snippets for test executables, test libraries and normal (application) executables.

Public shared libraries

In the MySubsystem/MyPackage/CMS.BuildFile, defines shared libraries which others CMSSW packages can link using

<use name="MySubsystem/MyPackage"/>

in their BuildFiles. The convention for library names in CMSSW is SubsystemPackage, where the directory containing the BuildFile is Subsystem/Package. Those familiar with ORCA might be used to libraries named after only the Package, but this change was made to simplify code management in CMSSW.

<use name="root"/>
<use name="DataFormats/HcalRecHit"/>
<use name="TBDataFormats/HcalTBObjects"/>
<use name="FWCore/Framework"/>
<use name="FWCore/ParameterSet"/>
  <lib name="1"/>

EDM Plugins

In the plugins directory of a package, define EDM plugins using library tags. More than one plugins can be defined. If they share dependencies, a common dependencies block can be used. If there are dependencies which are unique to one plugin, they should be placed inside the library tags:

<use name="tool1"/>
<use name="Subsystem/Package1"/>

<library name="myplugin1" file="">

<library name="myplugin2" file="">
  <use name="tool3"/>

Test executables

In the test/CMS.BuildFile directory of a package, define a binary executable using "bin" tags.

<use name="tool1"/>
<use name="Subsystem/package1"/>

<bin name="mytest1" file="main.cpp"/>

<bin name="mytest2" file="main.cpp">
  <use name="tool3"/>

Note that the same treatment of dependencies follows as described above in plugins.

Binary executables for real applications

Binary executables which are real applications should be executable from the command-line, i.e. they will be found in the user PATH after scram runtime is set. These executables are defined in a CMS.BuildFile in a bin directory in a package (i.e. package/bin/CMS.BuildFile). For example:

<bin name="myApp1" file="main.cpp">                                                          
  <use name="tool1"/>                                                               
  <use name="Subsystem/package1"/>

Note that the same treatment of dependencies follows as described above in test.

Building binary and test executables from more than one source file

This might come up when linking a main() against a private class. Assume that the class is called XYZ, is declared in XYZ.h, and contains the implementation:

<bin name="myPrivateApp1" file="main.cpp,">                                       
  <use name="tool1"/>                                                                         
  <use name="Subsystem/package1"/>
  <use name="Subsystem/package2"/>                                            

For more detail on SCRAM Buildfiles please read SWGuideBuildFile

Review status

Reviewer/Editor and Date (copy from screen) Comments
JohnStupak - 21-September-2013 Review
ShahzadMuzaffar - 17 Nov 2009 Fixed some BuildFiles examples, added BuildFiles examples for shared libs and plugins
AnneHeavey - 13 Nov 2006 update after review and additional content by Shaun Ashby
AnneHeavey - 17 Feb 2006 new page from J. Mans and P. Dudero

Responsible: ShahzadMuzaffar
Last reviewed by: ShahzadMuzaffar - 17 Nov 2009

Glossary and Index

Complete: 5

A reference document for information and explanations of acronyms and common terms in the CMS computing, grid-computing, detector, high energy physics and analysis environments.

The WorkBook Glossary is continually being updated with new and improved definitions of acronyms and concepts relating to the CERN, the CMS experiment, the LHC and GRID computing.

The context for the glossary item is given in brackets in italics at the start of the item dealscription.



Algorithm Board
  • Alternating Current
  • (organisation) Authorship Committee
(workbook) WorkBookAcknowledgements
(detector) Analog to Digital Converter
(physics) Arkani-Hamed-Dimopoulos-Dvali (ADD) model, arXiv:hep-ph/9803315
(safety) Automatic Fire Detection
(detector) Anode Front-End Board, CSC system
(computing) Andrew File System
Application Gateway
(safety) Alarm Level 3
(analysis) Alignment and Calibration Reconstructed files: AlcaReco data is the special RECO data for the alignment and calibration tasks. It is produced similar to Prompt Reconstruction, in that RAW data is reconstructed using standard CMSSW algorithms to produce the standard RECO data format. However, only regional reconstruction is performed, and only the parts of the event needed for the specific alignment or calibration task are written out. AlcaReco RAW data is likely to be written as a separate online stream, because it must be processed with very low latency.
Anode Local Charged Track trigger primitive, CSC system
(analysis) In the RecAlgorithm system, algorithm objects are entities that create new resulting objects or transform input objects. In the EDProducer systems, we distinguish between EDProducers and other algorithms that can perform smaller steps of reconstruction, and that may be composed (i.e. combined) to form an EDProducer.
A Large Ion Collider Experiment
Analysis Object Data (AOD)
(analysis) AOD are derived from the RECO information. They are intended to contain, in a convenient, compact format, enough information about the event to support all the typical usage patterns of a physics analysis. They are usable directly by physics analyses. AOD data are produced by the same, or subsequent, processing steps as those that produce the RECO data, and are available at Tier-2 sites (unlike the full RECO data). Reference: WorkBookDataFormats#AoD
(analysis) Artificial Neural Network
(analysis) see entry for Analysis Object Data entry.
(detector) Analog Opto-Hybrid - front-end readout optoelectronics board for CMS Tracker
(detector) Avalanche Photo-Diode
alignment position errors : an additional error applied to the reconstructed hits in order to take misalignment into account in the tracking and refitting.
(computing) Application Program Interface
(detector) Analogue Pipeline (Voltage mode), front-end read-out chip of Tracker
(detector) APV emulator. Reference: CMS.APVeOverview
(detector) Analogue Pipeline chip, Voltage-mode, 0.25 micrometer technology. Reference: CMS.APVeOverview
(analysis) Analysis Review Committee
(grid) Advanced Resource Connector (Grid middleware used in the Nordic countries)
(detector) Application Specific Integrated Circuit
(safety) ATmosphere EXplosible
(detector) A Toroidal LHC ApparatuS experiment
Asynchronous Trigger Throttle System
AUP Acceptable User Policy
(grid) the document you sign to get grid access that tells you what you can and can not do
American Wire Gauge


Beam 1
Beam 2
(analysis) Using the ROOT framework to analyse data without accessing the full functionality of the CMS framework. Accesses only member data of classes stored in data files, not the methods of those classes. Reference: WorkBookMakeAnalysis#BareRoot
(detector) Beam Condition Monitor
(detector) Beam Condition Monitor "Fast"; part of the BRIL sub-system.
(detector) Beam Condition Monitor for Losses; part of the BRIL sub-system.
Bunch Count Number
Beam Scintillation Counters
Back Disk
Beam Radiation Monitor (BRM)
(detector) Monitoring and early-warning system for onset of dangerous beam conditions. Designed to protect personnel and particularly the CMS detector, as well as other LHC systems. Reference: CMS.BrmWikiHome
(safety) Beam Interlock Controller
(safety) Beam Injection Warning
(detector) Barrel Muon system
Beam Observation system Beam synchronous timing Receiver
(computing) DBS - Database Book-keeping System: WorkBookDataSamples#RvS
Back Petal
Barrel Pixel
Beam Pickup for Timing for the eXperiments, part of BRM
Branching Ratio
Beam RAte of Neutrals
Branch Name
(analysis) For all data that will exist in a form that is traversable and browsable from the ROOT prompt, a branch name is provided. The branch name is composed of a "friendly" product type name, a process name and a module label.
(detector) the Beam Radiation, Instrumentation and Luminosity sub-detector system. Composed of three sub-detectors (BCM1F, BCM1L, PLT) segmented into four modules.
see entry for Beam Radiation Monitor
Beam Scintillation Counter
(physics) Beyond Standard Model. Includes such models as SuperSymmetry and Technicolour, but generally describes any physics that extends the current standard model of particle physics.
Beam Synchronous Timing
B-tagging associates a single, real number - a discriminator - with each jet.
Bunch and Track Identifier trigger primitive, DT system
Builder Unit
b Tag & Vertexing Physics Object Group
Build File
(analysis) Each CMSSW package directory has a file called a "BuildFile" that describes what the package will produce (executable files, etc) and what dependencies the package has. Reference: WorkBookBuildFilesIntro
Find onsite CERN building locations: WorkBookHelp#SearcHingCERN
Bunch crossing
Bunch Crossing Number


Primary programming language used in CMS. Programme reference: WorkBookComputingConcepts#ProgLan
Certification Authority (Grid)
(analysis) CMS Analysis Database
(analysis) CMS Analysis Database Interface
(CERN Analysis Facility) Integrates services associated with T1 and T2 centers and performs latency critical, non-automated activities.
(computing) CERN Advanced STORage Manager. Reference:
(detector) Forward Calorimeter: Centauro And STrange Object Research in nucleus-nucleus colllisions at the LHC. Reference: CASTOR
Candidate Combiners
Candidate Selectors
(organisation) Collaboration Board
  • Cosmic Challenge
  • (organisation) Conference Committee (CMS)
  • CERN Control Centre
  • (organisation) Conference Committee Chairperson (CMS)
(detector) Charge Collection Efficiency
(detector) Clock and Control Module
Clock and Control Board, CSC peripheral crate electronics board, 1 per pcrate
(computing) Combined Computing Readiness Challenge: four weeks challenge in May 08 prepared by preliminary tests in February.
(detector) Clock and Control System
(detector) Communication and Control Unit
(detector) Communication and Control Unit Module
  • Central Data Recording
  • Conceptual Design Review
CERN Document Server
(grid) Computing Element
(organisation) European Laboratory for Particle Physics
Grid Certificates: WorkBookStartingGrid#BasicGrid
(detector) Carbon Fiber Composite
(detector) Cathode Front-End Board of the CSC system
cfi files
(safety) Control and Indication Equipment
A C/C++ interpreter that is embedded in ROOT
(detector) Cathode Local Charged Track trigger primitive, CSC system
Class Library for HEP (Software)
(deprecated) WorkBookGeneration#CmkiN
(detector) Coordinate Measuring Machine
(detector) Common Mode Noise
(detector) Complementary Metal Oxide Semiconductor
(detector) Compact Muon Soleniod Detector. Reference: WorkBookCMSExperiment#DetectorComponents
CMS Notes
Cms Remote Analysis Builder (CRAB)
(computing) A programmable shell written in python, see WorkBookCmsshTutorial
CMS Software used in offline data analysis including event generation, simulation, and digitisation (for simulated data) as well as reconstruction and analysis (for both simulated and real data). It is also used online e.g. by the StorageManager application.
CMS Object-oriented Code for optical Alignment
Color Octet Mechanism
Composite Particle Candidates
Computing Account
Computing Model
Conditions Database
A database containing information relating to the state of the detector in a particular time interval. Contains information such as calibration details giving accurate positions of detector components. Ecal elements reference: SWGuideEcalOverview#ConditionsDatabase
(computing/analysis) see entry for Conditions Database
A configuration database, browser, editor and GUI for the HLT menues
Conference Agendas
Conference Committee
Configuration File (.cfg)
A document specifying which modules, inputs, outputs and services are to be loaded during execution of the cmsRun executable, how to configure these modules and services, and in what order to execute them. Reference: WorkBookConfigFileIntro
An organizational unit within an event, used to collect particular types of data separately.
Contributor Guide
Consistent Online Software INtegration Environment, project integrating online with offline software
(deprecated) Computing, Physics and Trigger-DAQ. The CMS CPT group essentially covers all computing aspects of CMS operations: including PRS (physics reconstruction and selection), software and development and operations of CMS computing.
(detector) Cluster Parameter Estimator: algorithm used to determine the position and errors of the CMS Pixel and Strip clusters
(computing) Central Processing Unit
CRAB (CMS Remote Analysis Builder)
CRAB is a Python program intended to simplify the process of CMS analysis job creation and submission to the grid environment. Reference: WorkBookCRAB2Tutorial
(detector) Cosmic Rack, a set of TOB rods
(commissioning) Cosmic Run at Four Tesla: Global run of CMS closed and with magnet on.
Crate Regulator Board - CSC peripheral crate backplane mounted LV power regulator board
Cyclic Redundancy Check error detection
(computing) Computing Run Coordinator
(commissioning) Cosmic RUn at ZEro Tesla
(computing) Computing, Software and Analysis challenge in 2006. Reference: CSA06
(computing) Computing, Software and Analysis challenge in 2007. Reference: CSA07
(computing) Computing, Software and Analysis challenge in 2008. Reference: CSA08
(computing) Computing, Software and Analysis challenge in 2014.
(safety) CERN System for Alarm Management
(detector) Cathode Strip Chamber muon system
Cathode Strip Chamber Trigger Track Finder
(physics) Color Singlet Model
(safety) Cryogenic Safety Officer
(computing) Computing Shift Person
Combined Secondary Vertex
(detector) CMS-TOTEM Precision Proton Spectrometer. Reference:
Concurrent Versioning System: WorkBookComputingConcepts#CvsCheckoutModules
CVSweb - web-based tool for searching through CVS repositories, e.g. the CMS Release code. Reference
(analysis) Collaboration Wide Review: procedure for reviewing the CMS scientific papers


(data/computing) Data to Surface
Digital to Analog Converter
(data/computing) Data Aggregation System
(data/computing) Data Acquisition System
Data Acquisition Motherboard, CSC L1 trigger
Data Formats
(data/computing) (DAQ-RAW, RAW, RECO, AOD, TAG, FEVT) WorkBookDataFormats
Data Samples
(data/computing) Finding data samples: WorkBookDataSamples
Data Summary Tape (DST)
(data/computing) deprecated name used to refer to a reduced size dataset containing the most interesting reconstructed objects (see also RECO and AOD formats).
Database Book-keeping System (DBS)
(computing) Tracks dataset locations around the globe. Also sometimes known as Dataset Bookkeeping System. Reference: WorkBookDataSamples#RvS
(computing/data) files containing information (list of tracks, momentum, high-level reconstructed objects) about a set of physics collision events recorded from the CMS detector. A dataset might
be a general collection or a more restricted set of events selected using certain filter settings for specific studies. Data is classified in Tiers depending on what types of data the events contain. Dataset labels usually contain a list of tier labels indicating what data they contain eg. RAW, GEN, SIM, RECO, AOD etc.
(computing) Database. Also used often in the context of CMS Computing to refer to the Dashboard monitoring project.
(computing) Database Management System
(computing) See entry for Database Book-keeping System
(computing) Data Challenge: a learning exercise to test operations of large scale computing systems.
(computing) Data Certification
(detector) Direct Current
(detector) Data Concentrator Card
(detector) DC Current Transformer
(detector) Digital Cathode Front-End Board of the (upgraded ME1/1) CSC system
(detector) Detector Control Systems
(detector) Detector Control Unit
(physics) Double Diffractive
Detector Description Database
Data Description Language
(organisation) Dataset Definition Team, replaces (announced Mar 2012) Physics Datasets Working Group
Detector Dependent Unit in DAQ system
(computing) See: SWGuideUsersFAQ#Debugging
(detector) The CMS Detector: WorkBookCMSExperiment#DetectorComponents
Detector Simulation
(analysis) Reference: WorkBookSimDigi#DetSim
Detector Simulation Model (OscarProducer)
(analysis) Reference: WorkBookSimDigi#DetSimMod
Microsoft Distributed File System deployed at CERN. Web access (requires NICE login), your quota.
(analysis/data) detector event data as output by the electronics (in simulation: as output by digitizer modules. See also Digitizer). Reference: WorkBookDataFormats
(analysis) Reference: WorkBookSimDigi#DigI
(analysis) A digitizer software module takes event input in units appropriate to the readout, e.g., energy from the simulator, or number of photoelectrons from the ECAL subdetector readout, and converts it to digitized (On/Off) data prior to sending it to the trigger. Each subdetector necessarily has its own digitizer, according to the type of readout data. For generated data, the digitizer can be viewed as part of the simulation application.
Data Interchange Protocol (CERN)
(computing) Data Location Service
(computing) Data Management
DAQ MotherBoard of CSC system
(analysis) Distribution of Median of Residuals, used in alignment of the Tracker
Data Management Workflow Management
(grid) Distinguished Name, a.k.a. the Subject of a GRID certificate, -- a globally-unique GRID-user name consisting of a hierarchical set of the following components: Country (C), Organisation (O), Organisational Unit (OU), Locality (L), Common Name (CN). Example: ​/C=RU​/O=RDIG​/OU=users​/​/CN=Vladimir Ivanov.
(CERN/CMS) CERN and CMS documentation: WorkBookHelp#DocumenTation
(detector) Diffusion Oxygenated Float Zone Silicon
Digital Opto-Hybrid - front-end control ring optoelectronics board for CMS Tracker, ECAL, RPC, TOTEM
Digital Opto-Hybrid Module
Data Operations and Release Planning
(radiation protection) Radiation dose measurement devices. Reference: WorkBookComingToCERN#DoSi
(programming) Automatic code-generating system for inter-related C++ packages. Reference: WorkBookHelp#DogyGeN
(detector) Detector Performance Group
(data-taking) Data Quality Monitoring: task or application for checking the quality of CMS (event) data.
(data-taking) Data Quality Monitoring Collector
(detector) Detector Safety System
(detector) Detector Control System
(analysis) see entry for Data Summary Tape
(detector) Drift Tube muon system
(trigger) Drift Tube Track Finder system, DT L1 trigger
(_ detector _) Data Valid, a bit set by the HCAL Half-HTR for each signal sample


(safety) Experimental Area Manager
(data acquisition) Event Builder
(detector) ECAL Barrel
(management) Executive Board
(detector) ECAL Barrel Trigger Concentrator Card (see TCC)
Electromagnetic Calorimeter. CMS.ECALWikiHome
ECAL Correlated Noise Analysis
(computing) Evolution of Computing Model Group (2008)
A CMSSW framework module that analyzes event data and may or may not store output into a ROOT output ntuple. The analyzer does not alter the stored the Event. Reference: WorkBookMakeAnalysis#EdAnalyzer
A CMSSW framework module that can read an event and make a decision whether or not to process it
European Data Grid project
Event Data Model. Reference: EDM
Engineering Database Management System
A top-level, reconstruction-developer written CMSSW framework component that performs a quantifiable step of reconstruction by creating and storing persistable data in the Event. An EDProducer instance produces an EDProduct instance. Any EDProducer class may be used for scheduled and unscheduled applications. Reference: WorkBookEDMTutorialProducer
The output of a CMSSW EDProducer module. An EDProduct is the base class for all objects inserted into the Event.
Engineering Design Review
(detector) ECAL Endcap
Eta-extended electrons
(detector) ECAL Endcap Trigger Concentrator Card (see TCC)
Event Filter, see entry for event filter
The Enabling Grids for E-sciencE (EGEE) project, funded by the European Comission, is aimed to build on existing grid technology to develop a constantly-available grid infrastructure for scientists
EGI European Grid Initiative
an European Community project to operate seemlessly a network of National Grid Initiatives (NGI) after EGEE is over
Electromagnetic Isolation Card, regional calorimeter trigger
Embedded Local Monitoring Board (ECAL)
Equipment Management DataBase
Endcap Muon system
Equivalent Noise Charge
a procedure that renders the contents of a file unintelligible to anyone not authorized to read it
Environment Setup
(computing) an XRootD-based storage system (a disk pool) at CERN for analysis-style data access. Web references: cern, cms
Event Processor
Experimental Physics Responsibility, name given to the service work that should be provided by each CMS institution/author
Endcap preShower detector
Event Server
Event Setup.
ESsource, ESproducer
Event Summary Data
Event Server Proxy
(organisation) Experiment Services and Pledges, the tool ( which is used to manage and account the services to the experiment provided by Institutes and Members under the Memorandum of Agreement (MoA)
ECAL Safety System
(physics) Transverse Energy
Eta Track Finder, DT regional muon trigger
EVent Builder
an event is set of signals in the detector resulting from a pp collision, or several such coincident collisions, either in reality in CMS or as produced by a simulation program. It includes raw signals (e.g. tracker hits, calorimetric energy deposits, etc.) and derived quantities (e.g. tracks, jets, etc.). In software terms, an event starts as a collection of the raw data from an event, stored as a single entity in memory, but organized into containers. The contents of the event change as it is processed; in particular, products (of producer modules) get added to the event, and are stored in separate containers. The Event is the interface through which one gains access to detector output and derived quantities that are associated with a single colllision.
Event Collection
A set of events typically with similar characteristics - e.g. similar detector conditions, similar event characteristics, ...
Event Data Model
Event Display
The CMS Event Display is IGUANACMS: WorkBookEventDisplay
Event Filter (EF)
A module whose primary purpose is to render a decision on the quality of an event, based on the EDProducts in the event.
Event Formats
Event Generation
Event Mixing Module
An EDProducer module that superposes events and delivers them to the detector-dependent digitization modules. For simulated data, it merges hits from a number of pileup simulated events into a single simulated event.
Event Setup
An event setup is a code block that might be included in a general information process block. The block source grabs information from an external source, for example the calibration database, in preparation for beginning an analysis job.
Event Filter Farm
Event Manager
Enabling Virtual Organization (video conferencing/colloboration system). "EVO is an advanced collaboration system based on a completely new and revolutionary distributed architecture capable of automatic self-correction to provide the best possible quality/experience for the end-users", WorkBookHelp#EvO
Electroweak. Also: Electroweak physics group.
(data-taking) The Expressline is 10% of the data that is tagged by Online and then processed (reconstructed) as quickly as possible, even before getting the calibration constants from the PromptCalibration. The Expressline data fully overlaps the main stream of data, i.e. there is no event in the Expressline that is not also in the non-express data streams. The Expressline data will be made available in the CERN CAF disk pool as fast as possible, to allow immediate analysis.


(organisation) Funding Agency
(general) Frequently Asked Questions
  • (organisation) Finance Board
  • (safety) Fire Brigade
(DAQ) Fedbuilder Output: xdaq-applicaton running in the computers hosting the RU that receives the superfragments of the fedbuilder. See also the DAQ Glossary.
(computing) File Catalogue
Future Circular Collider, the working name for a proposed project at CERN
(detector) Forward Calorimeter
(computing) Final CSA08: further exercises for LHC collisions to be performed in July (if beam is not imminent).
Forward Detector Concept Working Group, aiming at the development of long-range strategies for the CMS Upgrade Program in the endcap and forward regions including tracking, calorimetry, muons and trigger (concept Mar 2012)
Final Decision Logic
(detector) Front End
(detector) Front End Controller
(_ detector_) Front End Driver
(general) providing feedback: WorkBookUsage#ProvideFeedback
(detector) Front End Hybrid
Work from FNAL computers: WorkBookRemoteSiteSpecifics#CMS.FermiLab
Full Event information - this is the RAW (straight from the detectors) plus RECO (undergone some reconstruction) data - the two streams are kept together in CMS. Reference: WorkBookDataFormats
(safety) Flammable Gas Safety Officer
see entry for event filter
Find data
Finding data samples: WorkBookDataSamples
(organisation / trigger) Field Operations Group within the Trigger Studies Group (TSG). Responsible for the online deployment and monitoring of the HLT. Reference: CMS.FieldOperationsGroup
Programming Language. Mostly superceded in high energy physics by C++ (e.g. Herwig Monte Carlo is now Herwig++)
Field Programmable Gate Array
a C++ class library that defines the form of all user classes and the interactions between these classes. It provides the mechanism for job control to be passed from the operating system (i.e., the computer) to CMSSW code. The CMSSW framework implements a software bus model wherein there is one executable, called cmsRun, and many plug-in modules that run algorithms. The modules are chained together to process data. The same executable is used for both detector and Monte Carlo data. This framework is distinct from a more traditional approach in which several executables are used, one per task or set of tasks.
Forward Pixel Detector
Analysis modality whereby all functions and data members of a class are accessible by automatically-loaded ROOT libraries in an interactive ROOT session. Reference: WorkBookMakeAnalysis#FwLite
Framework services
These are services, such as the error logger and debugging service, that provide feedback about the state of the Framework (e.g. what module is presently running and meaningful error messages for debugging).
(data) Front End Readout Link
the Fast and Realistic OpenGL event displayer is a generic tool to visualize events. It can be use in CMS as well as in other experiment. More informations can be found on FROG webpage : or on the TWiki page :
A world-wide distribution and caching system for the Conditions Database. An online version is used by the HLT.
(detector) Forward Shower/Scintillator Counters -- subdetectors to detect particle showers along the beam pipes (installation: 2012?)
(detector) Finite State Machine
(organisation) the Forward and Small-x QCD Physics Analysis Group (PAG), the result of a merge in 2012 of Forward PAG and Low pT QCD subgroup. Subgroups as of Jan-2012: (1) Small-x QCD, (2) Soft QCD & MPI, (3) Diffraction & Exclusive processes (more details).
Final State Radiation
(organisation) Full-Time Equivalent -- a fraction of the full working time (usually over the time period of one year) that a person devotes to a project
File Transfer Protocol
(data) Filter Unit
(analysis) Framework
see entry for Framework-Lite


(computing) Grid Access Control List
Geiger avalanche photo diode (also called SiPM)
(analysis) LHCb Data Processing Applications Framework
(trigger) Global Calorimeter Trigger (part of the L1 trigger). Reference: SWGuideGCTEmulator
Pan-European Gigabit Research and Education Network
Global Event Description, aka PF (the Particle Flow approach)
(detector) Gas Electron Multiplier
GENerator level data. Reference: WorkBookDataFormats
Geant 4
A toolkit for simulation of the passage of particles through matter
Generator (of Events)
A physics event generator is software that uses Monte Carlo methods to simulate particle collisions and subsequent decays according to theory. Simulated particle events may then be run through the detector simulation to account for the effects of interactions with matter such as energy loss and bending of charge particles in the magnetic field. Pythia is the primary generator used in CMS to model the multiparticle output of a "real" collision of a given type. A generator called a "single particle gun" is used to generate a single particle of a given type; this is particularly useful for testing purposes.
Geom (.geom file extension)
This is the file extension of the FROG file containing the geometry data.
CMSSW entity that provides an interface through which a single EDProduct is obtained.
Gas Gain Monitoring system for the RPC muon detector
Global Event Identifier
Global muon reconstruction. It is made out of the fit of the hits from the track build in the tracker with the ones from the STA.
(safety) Group Leader In Matters of Safety
Lightweight middleware for Grid Computing
Global run
(data taking) data taking exercise involving central DAQ, triggered by Global Trigger and with at least one subdetector read-out
Global tag
(analysis) entry point for a coherent set of detetcor conditions, see SWGuideFrontierConditions
Grid Middleware
(trigger) Global Muon Trigger. Reference: SWGuideL1GMTEmulator
Physics of the CMS Experiment at the LHC: WorkBookCMSExperiment#PhysicsGoals
(detector) Gigabit Optohybrid - front-end readout optoelectronics board for CMS ECAL
gigabit optical link
Global Run
Grid Certificates
(grid) WorkBookStartingGrid#BasicGrid
GRID computing
(grid) WorkBookStartingGrid
(grid) Protocol Extensions to FTP for the Grid
(data taking) Global Run Mid-March
(safety) General Infrastructure Services Department
(pixel reconstruction) Gaussian Sum Filter
(grid) Grid Security Infrastructure
(trigger) Global Trigger. Reference: SWGuideGlobalTriggerEmulator
Global Trigger Logic
(general computing) Graphical User Interface
(grid) Globally Unique IDentifier


one of two processing units hosted on one HCAL Trigger and Readout card. See DCC and Spigot. (detector)
(data taking) second step of the DQM workflows for offline data or MC - merging of histograms across several files, postprocessing and automated tests. Reference: DQMOffline#SecondStep
(detector) CMS Hadronic Calorimeter, barrel section. Hadron Barrel Calorimeter. Reference: CMS.HCALWikiHome
(analysis) Legacy histogramming package based on Fortran
(detector) Hadronic Calorimeter
(detector) CMS Hadronic Calorimeter, end-cap section. Hadronic End-cap Calorimeter.
High Energy LHC -- an option for the LHC machine development aiming at 16+16 TeV pp collisions after ~2030, see a timeline in CERN Bulletin
(software) Particle transport software. Reference: HECTOR
(general) High Energy Physics
HepMC package
(analysis/computing) An object oriented event record written in C++ for High Energy Physics Monte Carlo Generators. See HepMC home page .
(detector) Hadron Forward Calorimeter - hadronic calorimetry instrumentation at each end of the main CMS barrel. Reference: CMS.HFWikiHome
(detector) the "minus" part (z < 0) of Hadron Forward Calorimeter
(detector) the "plus" part (z > 0) of Hadron Forward Calorimeter
(physics) Highly Ionizing Particle
(analysis) WorkBookWriteFrameworkModule#AddHisto
High Luminosity LHC -- a project to upgrade LHC around the year 2020 aiming at a substantional increase of the luminosity by a factor of ~10, see a timeline in CERN Bulletin
(trigger) Higher Level (software) Trigger
(detector) Hadron Outer calorimeter: hadron calorimetry outside the soleniod
(detector) a scientific instrument that detects the passage of a charged particle
(analysis) High Priority Analysis, e.g. HPAs 2012
(detector) Hybrid Photo Diode
(detector) High Precision Spectrometer(s), new subdetectors being proposed for forward proton measurement.
(physics) Hadron-Plus-Strips algorithm (Particle Flow based algorithm for reconstructing hadronically decaying taus with improved treatment of pi0 reconstruction)
(physics) Heavy Stable Charged Particle
(safety) Occupational Health, Safety and Environment Protection
(internet) Hypertext Mark-up Language - used to specify the contents and format of a hypertext document on the WWW
HCAL trigger and readout card - location of two Half-HTR's, a top one and a bottom one, by the position of their respective FPGA's.
(internet) HyperText Transfer Protocol - a set of instructions for communication between a server and a WWW client
(detector) High Voltage
A web and email-based collaboration tool used widely in the BaBar and LHC Collaborations. Reference: WorkBookHelp#CMS.HyperNews


Intelligent Input/Output
Main CMS information site (web pages). Reference:
(computing, software) Initial CSA08 activities (iCSA08): CMS offline workflows to demonstrate readiness for LHC data (calibration, skims, express analyses).
(analysis) CMS Event Visualization: a generic Interactive Graphics and User ANAlysis software toolkit (C++). Reference: WorkBookEventDisplay#InfoSources
(analysis) is a visualization system for CMS reconstruction and simulation (now part of CMSSW). Reference: WorkBookEventDisplay#InfoSources
(general) CERN/CMS etc pictures and photos: WorkBookHelp#ImaGes
Input Module
(software) In CMSSW, a module responsible for obtaining events.
Installing CMS software on local systems
(infrastructure) WorkBookInstallingCMSSoftware
(data) Interval of Validity. For example, the range of dates for which detector conditions data is valid
(physics) Interaction Point
(physics) Interaction Region
(physics) Initial State Radiation
(general) Intersecting Storage Rings


(programming) Programming Language
Narrow cone of hadrons and other particles produced by the hadronization of a quark or gluon in a particle physics or heavy ion experiment
JetMET Physics Object Group
January CMS wide educational workshops


(computer security) An authentication protocol


(trigger) Level 1 (hardware) trigger.
(trigger) Level 1 Accept signal
(safety) LHC Access Control System
(safety) LHC Access Safety System
(computing) Local Area Network - used to connect computers over a short distance - e.g. in the same office/building
Large files
(computing) Working with large files: WorkBookSetComputerNode#LargeFiles
(detector) Laser Alignment System
(computing) Live Access Service
LHC Beam Dump System
(grid) Worldwide LHC Computing Grid project (WLCG): WorkBookStartingGrid#LcG
(computing) Lightweight Directory Access Protocol
LDT (as in EE LDT)
LED Diode Timing
Look-Elsewhere Effect: CMS.LookElsewhereEffect
(documentation) Using the "leftbar" facility on CMS twiki pages: WorkBookContributors#CMS.LeftBar
LFN (Logical File Name)
(computing) a site-independent name for a file. WorkBookDataSamples#LfN
Large Hadron Collider. See a timeline of possible developments in CERN Bulletin
Large Hadron Collider beauty experiment
(organisation) LHC experiment Committee
Les Houches events - samples made with matrix element generators (madgraph, Sherpa, Alpgen,...) where the generation is done in a separate step using the Les Houches convention
Large Hadron-Electron Collider, a project aiming at collisions after ~2020 of 7 TeV protons/nucleons from HL-LHC with electrons from a new e-machine with the energy of ~50 GeV (e-ring option) or ~70 GeV (e-linac option), see a timeline in CERN Bulletin
CERN LInear hadron accelerator, provides 50 MeV Protons
Linux commands
Logging in
Logical File Name (LFN)
see entry for LFN
Lumi Sections
LHC Long Shutdown 1 -- up to 19? months in 2013-2014
LHC Long Shutdown 2 -- year 2018?
LHC Long Shutdown 3 -- year 2022?
(computing) Least Significant Bit
(computing) Load Sharing Facility (Batch system)
(safety) Laser Safety Officer
(Trigger) Local Trigger Control
LHC Tunnel and Experiments Study Group: meetings
(detector) luminosity. Reference: CMS.LumiWikiHome
(software) Look-Up Table
Lumi section
Sub-section of a run during which time the instantaneous Luminosity is unchanging. Initially this was defined as 2^20 orbits ~ 93 seconds; it was later redefined to be 2^18 orbits ~ 23.3 seconds. Unit of accounting for integrated luminosity. Production data files will contain one or many whole luminosity sections.
(general) Low Voltage
Low Voltage Power Supply
(computing/documentation) Linux Cross Reference. Used, for example, to produce a cross-referenced display of the CMS source code. References: WorkBookHelp#LxR,


(organisation) Maintenance and Operation
(organisation) Maintenance and Operation Funds, category A (contributed by Funding Agencies to the experiment)
(organisation) Maintenance and Operation Funds, category B (contributed by Funding Agencies to individual sub-detector projects)
MAB (Module pour Alignement de Barril)
Carbon-fibre structures where videocameras (on some of them ASPDs and DCOPs, too) are installed in order to be able to perform the hardware alignment of the DT chambers. There are 36 such modules installed on the CMS Barrel.
(safety) Material Access Device
the program produced by MadGraph to integrate the cross-section of the given process and produce unweighted events in the Les Houches format. Reference: SWGuideMadGraphInterface
a matrix element generator that generates amplitudes for relevant subprocesses of specified particle physics interactions. Reference: SWGuideMadGraphInterface
Mailing Lists
(detector) CAEN A3486 ACDC power converter (380V 3-phase to 48V dc) are also called MAOs. This name has been given by the CAEN engineers.
Low voltage for the CSCs and peripheral crates is supplied by a MARATON power supply, which provides two lines to the CSC's junction box: 6 V DC and 7 V DC, and two lines to the peripheral crates: 4.5 V DC at 40 A and 6.5 V DC at 10 A.
Minimum Bias
(organisation) Management Board
Minimum Bias Underlying Event
(computing/general) Monte Carlo simulation
(safety) Magnet Control System
(LHC) Machine Development
Prefix designating the Muon End Cap sub-system, EMU, CSC
Meeting Agendas
(organisation) [WorkBookHelp#AgendaM]]
Message Logger
(physics) Missing Transverse Energy
(detector) Minimum Ionising Particle
(detector) DT on-detector electronics (one minicrate per DT chamber hosts front-end, readout and trigger electronics)
MMM - My Mail and More
(organisation) Memorandum of Agreement, the document describing the service work obligations of Institutes and Members toward the experiment
(organisation) Maintenance and Operation Funds, category A (contributed by Funding Agencies to the experiment)
(organisation) Maintenance and Operation Funds, category B (contributed by Funding Agencies to individual sub-detector projects)
An event-processing element, a plugin (C++ class) to the CMSSW executable. All modules derive from one of the three worker base classes: EDProducer, EDFilter or EDAnalyzer.
Module Label
In CMSSW, a "human friendly" string that acts as a unique identifier (within a job) used for EDProducts created by the module configured by this label. Changing this label within a job will spawn a new module.
Monte Carlo Generators
see entry for event generation
Memorandum of Understanding
Muon Port Card, CSC peripheral crate electronics board, 1 per pcrate
(physics) Multiple Parton Interactions (in hadron-hadron and other collisions)
(calibration) Multi-Run Harvesting
(safety) Magnet Safety System
Minimal SuperSymetric Model
(experiment) Magnet Test and Cosmic Challenge. References: CMS.CMSComputingForMTCC , CMS NOTE 2007/005
(analysis) Multivariate Data Analysis
middle week global run


Non-Evaporable Getter -- a powder used in NEG pumps;
also an abbreviation for a NEG pump
NGI National Grid Initiative
a project in one or few single countries to run a computing grid infrastructure
NICE email system. This password is used across several CERN computing. NICE Services.


(organisation) Offline and Computing
(safety) Oxygen Deficiency Hazard
Online WorkBook
CMS Online/Shifter's WorkBook: CMS.MtccWB
(databases) Online Master Data Storage
Online Monitoring Service
Object Oriented (Software)
Power Factor Corrector module, part of the Maraton LVPS system
deprecated CMS software for digitisation of simulated electronics response (for Monte Carlo events) and reconstruction and analysis (for real and MC events)
(databases) Offline Reconstruction Conditions DB at Online, used by CMSSW applications at P5 (HLT, DQM)
(databases) Offline Reconstruction Conditions DB at Offline, used by CMSSW applications outside P5
Offline Run Manager
Operating System
(physics) Oppositely-Signed (physics objects of opposite electric charge)
deprecated CMS software for running generation and GEANT4 detector simulation of Monte Carlo events
(grid) Open Science Grid
Output Module
Reads data from the Event, and once all paths have been executed, stores the output to external media. An example is PoolOutputModule, which writes data to a standard CMS format ROOT file


CMS.ProdAgent, a tool for submitting jobs for large mass production.
Preshower Analogue CMS Electronics - the front-end chip designed for the CMS Preshower project. It comprises two separate chips: Delta (a 32-channel pre-amp and switchable-gain shaper) and PACE-AM (32 channel, 192-cell deep analogue memory with multiplexed output of 3 consecutive cells for every level-1 trigger received)
(safety) Personnel Access Devise
(computing) Processing And Data Access Task Force
(detector) Pressure ADC board
(organisation) Physics Analysis Group
Parameter Set
A collection of name/value pairs used to configure an element in a framework application.
In CMSSW, a vector of the unique identifiers of the EDProducts used as inputs for this bit of reconstruction.
Particle Candidates
Particle gun (simulations)
(analysis) Physics Analysis Summary, a public list of CMS PASes
(analysis) Physics Analysis Toolkit WorkBookPAT
PAT Glossary
(analysis) Glossary of commonly used PAT expressions WorkBookPATGlossary
The user's expression of requirements regarding which modules (including their configurations) make up a single high-level trigger. (Also a listing of directory areas that the system should search to find user executables and files.)
Physics Analysis Workstation (Fortran-based legacy data analysis package)
Portable Batch System
Publication Committee
(calibration) Prompt Calibration Loop
Peripheral Crate Monitor Board - plugs into the CSC system pcrate CRB
Peripheral Crate, CSC off-chamber front end electronics crate
(data) Primary Data Sets
(organisation) Physics Data/MC Validation -- a group within the PPD Project
People Search
peripheral crate
CSC off-chamber front end electronics crate
(physics) Particle Flow algorithm (algorithm for identification of hadronically decaying taus on the level of individual and unique particles)
prompt feedback group
Physical File Name: site-dependent name for a file. Reference: WorkBookDataSamples#PfN
(detector) Power Group
Physics Experiment Data Export (data transfer and placement system) - moves data around CMS. Reference: CMS.PhEDEx
Phone conferences
Phone numbers search
CERN phone directory: WorkBookHelp#SearcHingCERN
CERN/CMS etc pictures and photos: WorkBookHelp#ImaGes
Physical File Name (PFN)
site-dependent name for a file: WorkBookDataSamples#PfN
CERN/CMS etc pictures and photos: WorkBookHelp#ImaGes
Pile-up (PU)
Pile-up occurs when the readout of a particle detector includes information from more than one event. This specifically refers to cases where there are other (background) collisions somewhere within a timing window around the signal collision.
(organisation) Physics Interest Group, within the Heavy-Ion PAG
a circuit generating an output clock whose frequency is the same of an input "reference" clock and its phase is related to the reference clock phase
(detector) Pixel Luminosity Telescope; part of the BRIL sub-system.
Photo multiplier tube
PN (as in ECAL PN)
PIN Diode
(organisation) Physics Object Group
Popularity of the DataTier in terms of # Accesses, CPU time and Users*day, in a specific time window - popularity
(data) Pool Of persistent Objects for Lhc (Data management) implements a common persistency framework for the LHC Computing Grid (LCG) application area. POOL can store multi-Petabyte experiment data and metadata in a distributed and grid enabled way, providing navigational access to distributed data without exposing details of the particular storage technology. Reference:
(organisation) Physics Performance & Dataset Project (home page)
(detector) Precision Proton Spectrometer. Reference:
Printing WorkBook pages and chapters
Provenance (of a CMSSW EDProduct)
Collectively, the information that allows users to unambiguously identify how each reconstruction result was produced. Each EDProduct is associated with a provenance object that records this information. Also see WorkBookMoreOnCMSSWFramework
Physical File Name - site-dependent name for a file.
'Previously Known As Monsters': Events with exceptionally high occupancy in the pixel detector (see this link for the acronym definition).
(organisation) (deprecated) Physics Reconstruction and Selection organisational structure - PRS is split into two top-level groups covering the detector and analysis
(software) Parameter Set
(detector) Power Supply Controller
PVSS SOAP Interface
(detector) Power Supply Unit
(trigger) Partition Controler
(software) Prozessvisualisierungs- und Steuerungssystem (Process visualization and control system)
(physics) Primary Vertex (i.e. the interaction point)
Physics Validation Team
PYTHIA Event Generator
(computing) A program for generation of high-energy physics events. Reference: WorkBookGeneration#PythiA
(programming) An interpreted, interactive, object-oriented, open-source programming languange


(physics) Quantum Chromo-Dynamics
(physics) Quantum Electro-Dynamics
Quality Flag
HCAL charge integrator and encoder
(detector) a Quartz crystal based Phase-Locked Loop. The device function is to act as a jitter-filter for clock signals operating synchronously with the LHC bunch-crossing clock. See QPLL home page
Quarkonium Working Group


(physics) Reference Analysis groups (may be SUSY specific)
(safety) RAdiation Monitoring System for the Environment and Safety
(data) Raw Data event format. Reference: WorkBookDataFormats#EvenT
Resource Broker (Grid)
Readout BoX
Replica Catalog (Grid)
Run Control and Monitoring System
Regional Calorimeter Trigger (part of the L1 trigger). Reference: SWguideRegionalCaloTrigger
Relation Database Management System
Data after reconstruction. RECO is a CMSSW Data Format containing the relevant output of reconstruction. It is derived from RAW data and provides access to reconstructed physics objects for physics analysis in a convenient format. (more information: WorkBookDataFormats#RecO, SWGuideRecoDataFormat, REO)
Reconstructed data
see entry for RECO
A module whose primary purpose is to perform some step of reconstruction and to place the result into the Event.
Reference Manual
Generated by DoxyGeN (not part of the CMS Offline WorkBook):
Release Validation Samples
(analysis) WorkBookDataSamples#RvS
Remote Site
(computing/infrastructure) Working from computer sites outside CERN: WorkBookRemoteSiteSpecifics
(safety) Retour d'EXperience (lessons learnt)
Radio-Frequency (group) to Trigger Timing and Control format conversion
(computing) Remote File I/O
Run Field Manager
RFRX (or maybe better RFRx), means it's a Radio-Frequency receiver (RX=receiver). The second part, the D, means the digital version of the board (i.e. the second generation, the fist was analog)
(computing) Redhat Enterprise Linux
(grid) Replica Location Service
(analysis) Reconstruction Input Object
(computing) Read-Out Buffer
(experiment) Read-Out Chip
Remote Operations Center at FNAL
(computing) Read-Out Driver
(analysis) Region of Interest
(analysis) a project to create statistical tools built on top of RooFit and distributed in ROOT. It is a joint project between the LHC experiments and the ROOT team. Reference:
(analysis) a CMS-specific extension to the RooStats project. Reference: SWGuideRooStatsCms
(computing/analysis) A class library / application for data analysis. Reference: WorkBookBasicROOT
(experiment) Roman Pot: movable beam-pipe insertion dedicated to host detectors for measuring protons scattered to very small angles
(experiment) Resistive Plate Chamber
(safety) RadioProtection Expert
(computing) Run Registry
(organisation) Resources Review Board
(physics) Randall-Sundrum: RS model, RS graviton
(grid) Resource Specification Language
(safety) Radiation Safety Officer
(grid) Requirements Technical Assessment Group (LCG)
(DAQ) Readout Unit


(data) Super Cluster
(detector) Switched Capacitor Array (in CSC front-end readout electronics)
(detector) The online Scalers subsystem provides a way to introduce asynchronous data into the synchronous CMS data acquistion stream. The data injected into the data stream are: Level 1 Gobal Trigger counters, Luminosity counters, DCS subsystem voltage status, magnet currrent and temperature, and the synchronous history of the prior four L1 accept bunch crossing and orbit numbers. The CMSSW package DataFormats/Scalers has DIGI class files produced by the SCAL. SCAL also provides a number of monitoring and recording functions, such as writing Trigger and Luminosity rates into the online database, and receiving and recording LHC state changes through an LHC GMT (General Machine Timing) serial cable interface (see CmsLhcGmt for details). SCAL detects such events as the beginning and ending of LHC fills and records them as such in the Run Time Logger database; to assist in operational efficiency calculations, SCAL detects the absence of L1 triggers in excess of 93 seconds and records downtime in the same database.

Scheduled Application
In CMSSW, a style of application that is similar to the CDF and D0 trigger and reconstruction frameworks; more "linear" than the scheduled style. A scheduled application is configured by specifying a module instance path through which the event will flow.
schedules a set of modules for execution
invokes modules
(safety) Safety Control Room (Fire Brigade (FB), on the Meyrin site, b. 65)
Source Configuration, Release, And Management: a software tool responsible for building framework applications and also making sure that all the necessary shared libraries are available. Reference: WorkBookScramV1Intro
Semiconductor Tracker (Inner Detector)
(safety) Surface Control eXperiment building
(physics) Single Diffractive events; (CMSSW) Secondary Dataset
Software Development Process
Software Detector Physics Validation
Simulation Data Objects
Storage Element (Grid)
The Shared Environment for Applications at LHC, which provides common core and services (such as system, utility, framework, and mathematics) libraries for LCG applications in order to improve their coherency. Refer to the project seal for documentation, releases, and other details. Workbook reference: SWGuideDeclarePlugins
Searching for info at CERN (keywords, people, phone numbers, buildings, ...): WorkBookHelp#SearcHingCERN
Segment (in the muon chamber)
linear fit of the hits within a single chamber. It is the basic brick for the STA and TM building.
A predicate used to identify interesting EDProducts. It does so by examining the Provenance associated with that EDProduct. It encapsulates the user's requirements (i.e., features of interest) for products.
(detector) Single Event Upset -- (?) a failure of electronics induced by a single particle interaction
Sun Grid Engine (Batch Job System)
Shifter's WorkBook
see entry for Online WorkBook
SpecInt2000 (CPU Benchmark)
Simulated Data (RAW Format)/SIMulated hits. Reference:WorkBookDataFormats
Detector Simulation: WorkBookSimDigi#DetSim
Simulator (detector simulation of generated events)
The CMSSW simulation code, based on Geant4 concepts, is configured with CMS-specific information as to the detector geometry and materials, and knowledge of how various particles of given characteristics interact with the materials. The simulator takes input from a generated event, processes it, and writes back to the event a new (hit) container for each subdetector. In each of these containers it writes the position and energy of the virtual hits as seen by that subdetector.
silicon photomultiplier (also called GAPD)
Synchronization and Link Board
Scientific Linux CERN 3 operating system
Scientific Linux CERN 5 operating system
(safety) Shift Leader In Matters of Safety
(detector) Super LHC
simple link interface developed at CERN
64 bit S-LINK used in CMS
running selection criteria over a collection of events and writing only selected events to a new, and therefore smaller, file. This is used to speed up analysis jobs by producing a smaller sample of more-likely useful events to run over.
(physics) Standard Model
(data) Storage Manager
Standard Model Physics Analysis Group
(data) Storage Manager Proxy Server
mixtures of different physics processes in a simulated event sample
Source (for Event Generation)
A source is a module that can put generated data into an event in memory from where other modules can access it on-the-fly. There are generator sources (e.g. Pythia or single particle gun) and input sources that recreate the event in memory from its ROOT file.
Source Configuration, Release And Management tool (SCRAM)
Source Module
Reads in an Event from a ROOT file or generates an Event for Monte Carlo, gives the Event status information (such as Event number), and can add data directly or set up a call-back system to retrieve the data on the first request. Examples include the DaqSource, which reads in Events from the global DAQ, and the PoolSource, which reads Events from a ROOT file.
(detector) One of 15 input sockets on an HCAL DCC. Commuicates to one Half-HTR.
Storage Resource Manager (Grid)
(physics) Same-Signed (physics objects of same electric charge)
Stand alone muon. Track fit in the muon chambers. It involves more than a chamber at a time.
Statistics committee
(data analysis) forms recommendations on statistical issues identified in CMS physics analyses, etc. see StatisticsCommittee
Standard Template Library (C++)
summary of changes to WorkBook pages: WorkBookSummary
(physics) Super Symmetry
Software Validation Suite (SDP Validation)
Secondary Vertex


Event-level metadata. Very brief event summary data. Reference: WorkBookDataFormats#EvenT
(physics) Tau Neural Classifier (neural net algorithm for reconstructing hadronically decaying taus)
Generally refers to Test Beam
  • (software) Tag Collector
  • Technical Coordinator
Trigger Concentrator Card (detector ECAL) - VME modules that generate the ECAL Trigger Primitives in conjunction with the ECAL Front-End boards. They come in two flavors ie EBTCC (or TCC68, this type has 68 inputs) for the barrel part or EETCC (or TCC48, this type has 48 inputs) for the endcap parts. There are 36 EBTCC and 72 EETCC installed in the ECAL Off Detector Electronics crates.
Timing and Control Distribution System
network Transmission Control Protocol / Internet Protocol
Trigger Control System
Time to Digital Converter - a very fast timer
(safety) Total Discharge with the Power Converter (inverter mode, current ramped down to zero)
(documents) Technical Design Report
Triple Gauge Couplings
(detector) CMS Tracker End Cap
Telephone conferences
Tracker Finance Board
(detector) CMS Tracker Inner Barrel
Tracker Institution Board
(detector) Tracker Inner Disks
Tiered Architecture
(computing/infrastructure) The structure used by the computing centres used by CMS around the world. The tiered architecture functions as a single coherent system with three levels that provide different resources and services. Reference: WorkBookComputingModel#TieRs
Tier0 Computing Centre
(computing/infrastructure) This is the first computing tier of the CMS model, and is based at CERN. It deals with raw data - storage, analysis, processing. It runs prompt reconstruction, classifies data into ~50 event streams, and distributes the data among tier 1 sites. Reference: WorkBookComputingModel#TierZero
Tier1 Computing Centre
(computing/infrastructure) Major computing sites that have custodial responsibility for a defined part of the data. Tier1s provide substantial CPU power for re-reconstruction, skimming, calibration and other data-intensive analysis tasks. It also distributes reconstructed data sets to its associated Tier 2 sites. Reference: WorkBookComputingModel#TierOne
Tier2 Computing Centre
(computing/infrastructure) Smaller computing centres with substantial CPU resources that are available for user analysis, calibration studies and Monte Carlo production. They obtain real data from Tier1 sites, and send generated Monte Carlo samples to Tier1s for secure storage. Reference: WorkBookComputingModel#TierTwo
(detector) CMS tracking system
Tracker muon. Track in the tracker with matched segments in the muon system (the so-called inside-out approach).
Trigger Mother Board, CSC peripheral crate electronics board, 9 per pcrate
(organisation / trigger) Trigger Menu Integration group within the Trigger Studies Group (TSG). А.k.a. the Online Operations group. Since the beginning of Run 2 it has been superseded by FOG.
(detector) CMS Tracker Outer Barrel
(physics/detector) Time Of Flight
(physics/detector) TOTal Elastic and diffractive cross section Measurement - TOTEM Experiment. TOTEM has been installed near the point where protons collide in the center of the CMS detector. It will complement the results obtained by the CMS detector and uses 'Roman pots'.
(detector) Trigger Primitive
(detector) Trigger Primitive Generator
Tracker Project Office
Trigger Performance and Strategy Working Group, aiming at the development of long-range strategies for the CMS Upgrade Program in triggering (concept Mar 2012)
Trac is a part of CERN Central SVN Service
Track Reconstruction
(trigger) Trigger and Data Acquisition System: the trigger task is to select the most interesting events. Reference: CMS.TriDASWikiHome The first level trigger is the hardware trigger, which reduces the event rate from 40 Mhz to O(100)kHz. The subsequent HLT further selects events to yield an output rate of a O(100)Hz. The TriDAS makes events available to the offline Tier0 Centre. See also: WorkBookHLTTutorial
Trigger is combination of hardware and software system that uses certain criteria (based on physics algorithms) to rapidly decide to keep(record) or drop a proton-proton collision event in the CMS detector. Each physics group (SUSY, Higgs, Exotica etc. ) would like to trigger on events interesting to their physics hence leading to different trigger paths. $ Trigger path: A trigger path is a sequence of CMSSW modules which ultimately makes a boolean decision to keep or drop an event. Also see definition of a Trigger.
(LHC) Technical Stop
(trigger) Trigger Studies Group
(detector) Trigger Timing and Control
(detector) TTC CMS interface
(detector) TTC encoder/transmitter
Trigger Throttle System
Tracker Upgrade Project Office
(grid) Transfer URL
Tracker Upgrade Steering Committee


Underlying Event
Unscheduled Application
In CMSSW, a style of application that supports reconstruction on demand. An unscheduled application may be configured in a few ways: selecting top-level EDProducers, high level triggers, an analysis module, or some combination of these.
User Interface: grid, computing
Universal Resource Locator (Web or Grid)
(safety) Underground Service Cavern at LHC Point 5
User Support and help
User's Office FAQ
(safety) Underground eXperimental Cavern at LHC Point 5


(physics) Vector Boson Fusion
VME Crate Controller - CSC peripheral crate electronics board, 1 per pcrate
(detector) Velocity Drift Chamber
(software) Virtual Data Toolkit. Reference:
- Site Cleaning Monitoring interface - Victor
Vis (.vis file extension)
This is the file extension of the FROG file containing events data.
The CMS Event Display is IGUANACMS: WorkBookEventDisplay
Versa Module Europa bus
Virtual Organization (Grid)
Virtual Organization Membership Service (Grid)
VOMRS Virtual Organization Memebership Registration Service (Grid)
an interface to VOMS to manage applications by VO members
(detector) Vacuum Phototriode - A single stage, magnetic field tolerant phototube, deployed in the endcaps of the ECAL
(deprecated) Virtual Room Video Conference System - internet-based meeting tool. See also entry for EVO. Reference: WorkBookHelp#EvO


Wide Area Network
(planning) Work Breakdown Structure
CMS Online Web Based Monitoring is a suite of web based tools used for monitoring the online real-time and historical status of the CMS detector, trigger, and data acquisition. See the WBM link at or at http://cmswbm.cms if you are inside the P5 network.
Web pages
Useful CERN/CMS web pages: WorkBookHelp#MainWeb
Weekly General Meeting. See the list of WGMs in Indico .
(physics) weakly interacting massive particle, wikipedia
Worldwide LHC Computing Grid project: WorkBookStartingGrid#LcG
Work Management System (Grid) - manages remote jobs
Worker Node (Grid)
collection of libraries and components that provide a grid workload management system. It is written in python and interacts with multiple grid systems. WMAgent


the CMS Online software platform -- a software platform designed for the development of distributed data acquisition systems. See project page .
(meeting) Cross Coordination
Extended Executive Board
XDAQ Monitoring and Alarming System
Extensible Markup Language
(CMSConventions) Axes according to CMS IN 2000/054: X points towards the center of LHC ring, Y -- upwards, Z = X × Y


(detector) Yoke Barrel
Year-End Technical Stop


(detector) Zero Degree Calorimeter. Reference: CMS.ZDCWikiHome
Legacy data management system

-- LucasTaylor - 27 Nov 2006 (reviewed and revised complete glossary)
-- JennyWilliams - 23 Nov 2007 (combined with WorkBook Index and CMSAcronyms and deleted index)

Responsible: KatiLassilaPerini and SudhirMalik
Last reviewed by: LucasTaylor - 27 Nov 2006

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r13 - 2010-01-19 - KatiLassilaPerini
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback