the user guide - department of physics · versions starting with orca 5.1.0 use for linux gcc...

ORCA 6 3 0- User Guide

November 27, 2002

Contents

I Introduction 1

1 Welcome to ORCA 3

1.1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 What is ORCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 The basic structure of ORCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Required software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Exportability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Getting Started 7

2.1 Recipe for the impatient USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Accessing ORCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Using the predefined Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Building and running ORCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Setting the .orcarc parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Populating a database - the full chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 A simple example analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 Overview of BuildFile options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.9 Shallow copies, UserCollections and deep copies of a UserFederation . . . . . . . . . . . . . . . 27

2.10 Adding new Digis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.11 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

II Sub-System Descriptions 31

3 CommonDet 33

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Detector view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

iii

4 Calorimetry 39

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Ecal Realistic Digitization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Hcal Realistic Digitization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5 Preshower Realistic Digitization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Ecal Realistic Calorimeter Hit Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.7 Hcal Realistic Hit Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.8 Preshower Realistic Hit Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.9 Detailed digitization of ECAL hits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.10 EcalSelectiveReadoutTower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Tracker 57

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Overview of the object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Geometrical layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4 Detector response simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 CommonStripDet: Does something ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.6 Pixel detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.7 SiStripDet: Silicon Strip Detectors: digitisation and cluster reconstruction . . . . . . . . . . . . . 60

5.8 Interface to Geant3/cmsim data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 CommonReco 67

6.1 Track Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2 Track finding and fitting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7 The Muon Subsystem 75

7.1 Muon reconstruction in barrel region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2 The Endcap Muon CSC system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.3 Digi-SimHit associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8 Trigger code in ORCA 79

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2 Calorimeter Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.3 Muon Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.4 Global Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9 JetFinders, design, implementation, and usage 87

9.1 Noun List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

9.3 Responsibilities and mapping to design elements . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4 Object Oriented Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

9.5 Concrete Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

9.6 Usage of the Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10 TrackerReco 97

10.1 Track reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

10.2 Pixel Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

10.3 Tracker Alignment Tools in ORCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

10.4 TkRecHitValidation: Reconstructed Hit Validation . . . . . . . . . . . . . . . . . . . . . . . . . 114

11 Electron and Photon Reconstruction 117

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11.2 ElectronPhoton modular reconstruction and analysis . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.3 Calorimetric clustering and position reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.4 Energy reconstruction and brem recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.5 Candidate identification and selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.6 Analysis helpers and toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

12 Examples 119

12.1 Histograms, Ntuples and Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

12.2 Accessing MC generator information and GEANT tracks and vertices . . . . . . . . . . . . . . . 131

12.3 Simple matching between tracks and clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

12.4 Comparing MC particles with their reconstructed equivalents . . . . . . . . . . . . . . . . . . . . 133

12.5 The prototyping library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

III COBRA Sub-System Descriptions 137

13 GeneratorInterface 139

13.1 HEP particle properties and identification numbers . . . . . . . . . . . . . . . . . . . . . . . . . 139

13.2 Classes to handle particles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

13.3 Classes to handle HEPEVENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

13.4 Utility classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

13.5 .orcarc parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

14 Magnetic Field 145

14.1 Magnetic Field with 2D map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

14.2 Magnetic Field Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

15 CARF: CMS Analysis & Reconstruction Framework 147

15.1 Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

15.2 Persistency Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

16 CMS Service and Utility Toolkit 155

16.1 User Inerface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

IV Appendices 157

A Using Objectivity commands (Examples) 159

B Changing from ORCA 3 to ORCA 4 165

B.1 General changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

C .orcarc Parameters 167

V Glossary 177

Bibliography 181

Part I

Introduction

1

Chapter 1

Welcome to ORCA

1.1 About this document

This UserGuide is supposed to give general information about the CMS reconstruction program: ORCA. It consistsof two major parts, an introduction into the usage of ORCA for beginners and a part giving general informationabout the different subsystems of the program like Calorimetry, Tracker, GeneratorInterface, CARF or Examples.The information is completed by appendices on related technicalities like Objecitiviy/DB commands.

Complementary to this UserGuide a ReferenceManual is created for each version of ORCA that contains moretechincal details of the program like a list of all classes, the methods of each class, the inheritance structure andrelations between different classes.

All information about ORCA can be found from the main WWW page at CERN:

http://cmsdoc.cern.ch/orca

This page contains links to the Manuals of all important releases, to talks and tutorials, to the remedy feedbacksystem, information on how to install ORCA and how to subscribe to the existing mailing lists.

1.2 What is ORCA

ORCA is a framework for reconstruction and is intended to be used for final detector optimisations, trigger studiesor global detector performance evaluation [3]. It is an object oriented system for which C++ has been chosen asprogramming language. The acronym ORCA stands for Object Oriented Reconstruction for CMS Analysis.

ORCA is a work in progress. The development takes place on a roughly four month schedule. Its design is basedon CARF, the CMS Analysis and Reconstruction Framework, which was developed to prototype reconstructionmethods, initially for testbeam applications. It is still a prototype, but one that is already usable by CMS physicists.This causes inevitably accidental conflicts between developers, who need to correct their prototypes sometimes andusers who expect them to remain valid for a long period of time. It is hoped that both these groups adopt a respectfor the others problems, the developers trying to avoid rapid fluctuations and the users accepting the occasionalchanges that can result in them having to modify their code. Nevertheless, there is a system of code versions in useso it should always be possible for users to work with a fixed version - however of course with the rapid devlopmenttaking place at the moment they will soon get out of date.

3

4 CHAPTER 1. WELCOME TO ORCA

1.3 The basic structure of ORCA

ORCA has two logical layers, subsystems and then within a subsystem packages. For an overview of the currentlyavailable subsystems see Figure 1.1.

Calorimetry

CommonDet ElectronPhoton

bTauAnalysis

Visualisation

Workspace

TestBeams

DAQ

H4Ecal

Tracker

Muon

Trigger

CommonReco

MuonReco Documentation

Data

Jets

ORCA

JetMetAnalysis

MuonAnalysis

TrackerReco

Examples

Vertex

Figure 1.1: Subsystems of ORCA.

The packages within a subsystem typically produce a single library dedicated to cope with a certain aspect of thecorresponding sub-detector (e.g. for Calorimetry: G3EcalDigits, G3HcalDigits, EcalCluster, . . .) or reconstructionutility. For this note the subsystem Examples is of special interest. There the packages correspond to typicalanalysis tasks performed by “normal” users. The subsystem Workspace has the same task, only that it is ment as aworking environment for the users private code.

For each standard package at least the following four sub-directories are present, where only the first two areof interest for external users of the packages:

• doc The documentation related to the package.

• interface The C++ header files that can be referenced from other packages in the same or in differentsubsystems. In case of missing documentation these header files reveal the implemented functionality of thepackage.

• src The actual source code and C++ header files local to the package.

• test Source code of test programs for quality control of the package.

Besides the individual packages a subsystem has a directory domain containing files and documentation whichare common to the packages of the subsystem.

1.4 Required software

1.5 Supported platforms

It has been agreed to support ORCA on SUN and Linux (currently CERN Redhat 6.1) machines. With most of thedevelopers working on Linux PCs usually ORCA is better tested on that platform. Running on any other Linux

1.6. EXPORTABILITY 5

COBRA IGUANA

ORCA

FAMOS

OSCAR

Figure 1.2: Relation with other CMS OO projects.

flavour (e.g. Redhat 7.2 or Suse 7.x/8.0) is probably not covered by the Objectivity licenses of CERN.

Versions starting with ORCA 5.1.0 use for

Linux gcc 2.95.2

Solaris Workshop 6.2 with CC 5.3 (not yet for ORCA 5.1.0)

1.6 Exportability

Version 1 of ORCA was in practice usable only on CERN machines and not exportable. The architectures SUN(e.g. cms.cern.ch) and Linux are supported, a special version for Windows NT is available.

Version 2 has been successfully exported to Fermilab and Dubna machines. There will be a special chapter onhow to install ORCA on a remote site.

Starting with Version 3 ORCA is exported to a multitude of different sites. The tool scram can be used toaccess the different versions of ORCA.

To run ORCA on a non-CERN machine a lot of additional software is needed. In particular, the CERN libraries(2001), LHC++ (3.6.6), doxygen, dot and various CMS utilities as well as the cmsim (v125) Simulation programand the SCRAM configuration management tool (V0.19.3). ORCA 6 uses the basic CMS OO tools and frameworkfrom COBRA (6.1.0). If you intend to use the visualisation options of ORCA also IGUANA (2.7.6) is needed withOpenInventor and OpenGL.

6 CHAPTER 1. WELCOME TO ORCA

Chapter 2

Getting Started

This chapter gives an introduction in the usage of ORCA. The intended audience are “normal” users who want todo physics analysis or detector studies – things they did in the past with CMSIM [2] . People participating in codedevelopment for ORCA itself need a deeper understanding of the framework; they may however also profit fromthis document. The general layout of the system and some technical or slang expressions used will be discussed.Also a step by step instruction on how to use the Workspace and Examples subsystems will be given. Specialemphasis is put on the predefined Workspace for private programs of the users. Finally an example application isdiscussed in detail.

As for the other CMS offline software projects, the tool SCRAM is used to build, configure and even distributethe ORCA code.

The recipe section is ment just as such. You should in any case read the rest of this introduction. When usingthe recipe execute every single step one by one, unless you have read the detailed explanation and know whatyou are doing.

The recipe applies only to users on CMS machines at CERN. Everybody else: check the details! The commandsin the recipies are given for csh/tcsh only, since this is the default for CMS. The detailed explanation gives thecommands for sh/bash/zsh as well.

2.1 Recipe for the impatient USER

1. Prepare the ORCA environment:scram project ORCA ORCA 6 3 0cd ORCA 6 3 0/src

2. Initialise the environment (PATH and path to search shared libraries):

eval ‘scram runtime -csh‘

The apostrophes in this command are the backward-single-quotes. On PC keyboards the key is located leftof the 1-key, on SUN keyboards it is the rightmost key on the line with the numbers. Make sure you issuethis command before any scram b to avoid problems!

3. Checkout the Workspace from the CVS server:

7

8 CHAPTER 2. GETTING STARTED

cmscvsroot ORCAcvs login

When prompted for the password, enter 98passwdcvs co -r ORCA 6 3 0 Workspacecd Workspace

You should always specify the name of the release you are using when checking code out of the CVSrepository.

4. Copy your source code to this directory. The directory already contains a simple Example program ExRun-Event.cpp printing run and event number.

5. Edit the BuildFile to make your executables known. (The BuildFile is setup to compile ExRunEvent.

6. Build the stuff, first the library, then the executables. (To simply try this, please do touch ExRun-EventInfo.cc first.)

scram b sharedscram b bin

7. Rescan your path for new executables

rehash

8. Setup the ORCA environment (OO FD BOOT, DETINPUT, GEANEUSED)

eval ‘scram runtime -csh examples.env‘ (*)

(*) This works at CERN only.This sets the environment to read from an Objectivity database. If you want to read from a different database,change the environment variable OO FD BOOT correspondingly. See Section 2.6.7 on how to access theofficial production databases. For more details on ORCA environment variables see Section 2.2.4.

9. Run your program by simply typing its name, e.g. ExRunEvent. The first 10 events will be analysed. Theprogram simply prints run end event numbers for the trigger events and event numbers for pileup events

2.2 Accessing ORCA

2.2.1 Where to find the code

The CVS server

ORCA is available from a dedicated CVS1 server running at CERN. Standard cvs commands have to be used toget files from the repository, or, as an authorised developer, store the files in the repository.

The public checkout area

A public checkout area (/afs/cern.ch/cms/Releases/ORCA) contains the most important versions avail-able. There one has easy access to the full source code, e.g. of the header files and the examples. A snap-shot version of the HEAD of the ORCA repository – updated approximatly every four hours – can be found in/afs/cern.ch/cms/OO/Software/snapshots/ORCA.

1Concurrent Versioning System, [4]

2.2. ACCESSING ORCA 9

2.2.2 Versions of ORCA

The versions of ORCA follow a special naming scheme, containing three numbers, e.g. ORCA 5 4 2. Thenumbers indicate the major release number (5), changes in interfaces within a minor release (4) and bug-fixeswithin the release (2). Releases of ORCA are announced in the CMS news system. A list of all releasesand their “release notes” (a brief description of what changed with respect to the last version) can be found athttp://cmsdoc.cern.ch/orca. It is recommended to always use the latest release and the latest interface version. Ifunaffected by the bugs fixed in bugfixes (check the release notes!) older version with the same interface can beused. But since a bug is a bug it is certainly a good idea to use the release including the fix.

Using cvs tags

Developers have also the possibility to tag code with names to their liking. This tagging can be done on package orsubsystem level. In principal any meaningful tagname is allowed, e.g. dbIOworks. Some tag names are reservedand can only be used by the CMS librarien (those containing ORCA for example).

In addition during the release phase of a new major or minor version tags with names like ORCA 5 1 0 pre6are used to tag code that is fully tested and integrated for the new release. These pre-releases contain mostly onlya subset of all ORCA code. The tags will be put by the CMS librarien and their use is prohibited for everybodyelse. The same applies to the official release tags like ORCA 5 1 0.

Only developers may want to access the “HEAD” version of the code. This version contains the latest changesdone by the developers and does not necessarily work. Caution: When checking code out of the repository thedefault is to get the “HEAD” version. Unless beeing a developer working on your own code you always want tospecify a tag using the -r tagname flag.

2.2.3 Access to the ORCA CVS server

Users and developers access the CVS server in different ways.

Normal users In a CMS environment you can simply type

cmscvsroot ORCA

to set the CVSROOT shell variable. If this doesn’t work, try it by hand:

CSH-style: setenv CVSROOT :pserver:[email protected]:/cvs_server/repositories/ORCASH-style: export CVSROOT=:pserver:[email protected]:/cvs_server/repositories/ORCA

Then type cvs login and give 98passwd as password.

Developers have three different ways to access the CVS server. At CERN and as member of the CMS group(ZH) they can use the command project ORCA to preset their environment for work with ORCA. Alternativly,they can use kerberos tickets or the secure shell (ssh) to access the server.

For more information on accessing the CVS server seehttp://cmsdoc.cern.ch/cmsoo/projects/cvs server.html

The CVSROOT variable has to be set every time you login and want to use the CVS server.


2.2.4 Setup the private working environment

To actually build ORCA the tool SCRAM [8] is used2. This introduction will not discuss all details of SCRAM.A powerful online help is available with the command “scram help”. The first thing to do is to choose a directorywhich will contain source files, libraries and executables. Again there is a difference between regular users ofORCA and ORCA developers.

A normal user will check out only a few files from the CVS server, since everything else is present in the centralinstallation. Typically the only thing to get is the subsystem Workspace, where then the private code is put. Forusers the setup should be somewhere in the users home directory structure, where regularly backups are made. ForCERN/CMS users their AFS directory is recommended. You can ask for 500 MByte of AFS scratch space with anemail to [email protected].

A developer will typically check out a larger amount of code, but this code is only taken from the CVS serverand modifications to it can (and should) be saved there frequently. Therefore they should work in some scratchspace.

To perpare to work with ORCA,

1. go to the directory where you want to create your local copy

2. Type scram project ORCA release. A subdirectory with the nameORCA release will be created. The command scram list will print a list of valid releases. The nameof the subdirectory can be choosen with the -n NAME option of the scram project command.

3. Go into src subdirectory of the directory that has just been created (cd ORCA release/src).

4. Use eval `scram runtime [-csh|-sh]` to initialise the shell environment variables. The apos-trophes in this command are the backward-single-quotes. On the keyboard the key is located left ofthe 1-key or on SUN keyboards it is the rightmost key on the line with the numbers. This sets the PATHand initialise the search path for shared libraries. It is important to execute this command before trying tobuild any binary.

5. Add the subsystems/packages you want to work on using standard cvs commands. A normal user shouldnormally only get the subsystem Workspace: cvs co -r ORCA 6 3 0Workspace. A developer maycheck out whole subsystems: cvs co -r tag subsystemname, e.g. cvs co -r dbIOworksCARF. It is also possible to get only a single package from a subsystem, e.g. cvs co -r ORCA 2 1 0Examples/MCinfo. This command can be used in several ways. You can choose the “HEAD” versionwith cvs co Examples or any other valid tag. If you have checked out a tagged version you need to usecvs update -A to move to the “HEAD” version to be able to commit the changes3.

2.3 Using the predefined Workspace

2.3.1 Setup the user files

The subsystem Workspace is provided to allow the user to easily compile his private analysis code and link itagainst the central ORCA libraries. The Workspace has no specific structure like the other subsystems, it containsonly a default BuildFile. BuildFiles are used to tell SCRAM what libraries to use and what executables tobuild.

2For ORCA version 1 another tool, SRT, was used. Since it is no longer supported it will not be described in this and future version of thisdocument.

3When working with branches you need to update to the head of the branch with -r branchname instead of -A.

2.4. BUILDING AND RUNNING ORCA 11

Then copy your source files i.e. your own C++ analysis code to the new subsystem Workspace and definethe (executable) targets in the Buildfile by adding lines like

<bin file=MyProgram.cpp></bin>

The BuildFile is setup to use only libraries CARF and Utilities for a SimReader application by default. If youneed additional libraries, e.g. because you want to use Calorimetry, you have to uncomment the correspondinglines. For a brief introduction to BuildFiles see Section 2.8. Source files that are not defined as bin targets will becompiled and put into a library. The convention is to have the extension .cpp for bin targets and .cc for classesthat should go into the library.

RULE: Every .cc and .cpp file must have the line

#include "Utilities/Configuration/interface/Architecture.h"

as first line.

2.3.2 Build and run the programs

To build your executable and library you can use the commands discussed in Subsection 2.4.1.

2.4 Building and running ORCA

2.4.1 Building libraries and executables

Once you have checked out some code from the repository or added your code to the Workspace you will want tobuild the libraries and programs you got. For this a single command scram build is sufficient. This commandcan be given at any level of the checkout area, starting in the directory .../ORCA release/src and below.Only code that has changed with respect to the central installation in /afs/cern.ch/cms/Releases/ORCA/...will be recompiled. For the compilation step the debug options are enabled by default.

A package in a standard subsystem like Calorimetry or Tracker usually contains a test suite to verify thecorrect functioning of the corresponding library. The source code for these executables are located in the testsubdirectory of the package. They are created when a scram build (or simply scram b) is issued in thatparticlular test directory.

Executables in the Example and Workspace subsystems are created by default.

The command scram b clean can be used to delete all dependency files, object files, libraries and executa-bles related to the level where you give it. Typing it in .../ORCA release/src will delete all created filesand you can restart like after the cvs co command.

2.4.2 Running an executable

Starting from ORCA 4 we distiguish between different types of ORCA applications. To start with there exist

• G3Readerto read a CMSIM FZ-file and populate an Objectivity database with the simulated hits for the differentsubdetectors,


• SimReaderto reads that database and to do the digitization and reconstruction of higher level objects if asked for. In thisstep signal (trigger) and minimum bias (pileup) events are added corresponding to the required luminosity.It is possible to store some of the objects back into the database,

• RecReaderto read Digis and RecHits from the database that have been stored by the SimReader.

These names correspond to CARF group names that can be used in BuildFiles. Most users will run RecReaderapplications.

Currently ORCA G3Reader applications read the detector geometry from RZ files created with CMSIM. Thegeometry is stored in the database and SimReader and RecReader read it from there.

Configuring the application

In addition to the “scram runtime” command one needs to define additional environment variables. ORCA pro-grams need to know where to find the Objectivity federation (the collection of databases) to use. This is specifiedwith the variable OO FD BOOT or with the .orcarc paramenter BootFile.

For a G3Reader - the RZ-file that contains the CMSIM geometry needs to be specified with the DETINPUTvariable.

Finally, to successfully reconstruct muon tracks GEANE is required to trace particles through the magnet yoke.This is enabled by setting the variable GEANEUSED to the value TRUE.

Everything else, i.e. the selection of input files or databases to read or to write and all parameters to algorithmsare specified in .orcarc files. For that purpose simple scripts are provided with the various packages, choosingreasonable values and linking to existing example input files.

To read from the central test federeation at CERN only one environment variable has to be set:

Variable ValueOO FD BOOT suncmsc.cern.ch::/data/valid/ORCA 6 0 2/VALIDATION.boot

Table 2.1: The most important ORCA environment variable

In addition the data to read from this federation has to be specified in a .orcarc file in the local directory.

MaxEvents = 10InputCollections = /System/SimHits/single_mu_pt50/single_mu_pt50

This example specifies (to an ORCA SimReader application) to use the dataset single mu pt50 with the ownername SimHits. The dataset name specifies normally the kind of events (here single muons with 50 GeV transversmomentum) and has to be repeated. The owner name indicates how the events have been treated. Here for exampleit is just the simulated hits. Other examples are NoPileup or Lumi1034 for data that has been digitised for no pileupor for pileup corresponding to a luminosity of 1034cm−2s−1.

For SimReader applications the information on pileup treatment can be given4. Pileup can be switched off bysetting PUGenerator:AverageEvents to zero.

4Only up-to 4.2.0. For later versions no Pileup is used if no PUGenerator: datacard is given.

2.5. SETTING THE .ORCARC PARAMETERS 13

RecApplication:MaxEvents = -1

PUGenerator:Collection = /System/SimHits/minbias/minbiasPUGenerator:AverageEvents = 4.67PUGenerator:MinBunch = -5PUGenerator:MaxBunch = 3PUGenerator:FirstEvent = -2

Selecting runs and events

The selection of a specific run is done with the InputCollections parameter. For example

InputCollections = /System/NoPileup/single_mu_pt50/EvC_Run2

selects run number 2 in the dataset single mu pt50.

Individual events can be selected with SelectEvents or rejected with RejectEvents. They are identifiedin the form run:event

SelectEvents = 1:3 1:9 2:39RejectEvents = 1:111 2:6

And execution...

Finally one can run the program by just typing its name. This works because the PATH has been adopted bythe scram runtime command. Eventually the unix command rehash is needed to make the shell find theexecutable.

2.5 Setting the .orcarc parameters

Some of the most important .orcarc parameters from COBRA are given in Table 2.2. More details on the.orcarc parameters defined in ORCA are given in Appendix C and in the ReferenceManual.

2.6 Populating a database - the full chain

Even with many important dataset available from the official HLT UserFederations, a physicist may want to studyhis own private set of events. This chapter tries to explain how to create an Objectivity/DB federation on a localdisk and store the events in it.

2.6.1 From the event Generator to a cmsim FZ file

Most people are familiar with this step. For details please check the cmsim documentation. Here only a fewreminders.

Examples of geometry and FZ-event files are available in/afs/cern.ch/cms/oo/reconstruction/datafiles.There also the datacards used for the production of the FZ files are stored. They can be used as examples for private


TYPE NAME DEFAULTVector<int> CMSRandom:Seedsbool Verbose:info truebool Verbose:test falsebool Verbose:debug falseVector<string> FZInputFilesint G3FZ:SkipEv 0float DBPopulator:MaxDBSize 1.0int DBPopulator:CommitInterval 200bool DBPopulator:UseMutex truebool DBPopulator:UnNamedContainers falseint DataSet:JobsPerDB 4int DataSet:DBPoolIncrement 1string EDLocation::EventDB EventsVector<string> EDLocation::OtherDBsbool GoPersistent falsebool Digi:Update falsestring InputCollectionsstring OutputDatasetunsigned int InputRun 0unsigned int FirstEvent 0int MaxEvents -1bool MemoryDebug falseEnum<PUGenType> PUGenerator:Type Poisson (Auto, Fixed, Poisson, HIC)bool PUGenerator:NoReusebool PUGenerator:AllEvents falsestring PUGenerator:xxxint PUGenerator:FirstEvent -1float PUGenerator:MaxRange 10.float PUGenerator:AverageEvents 0.int PUGenerator:MinBunch 999int PUGenerator:MaxBunch -999

Table 2.2: Some CARF parameters for the .orcarc files. For more check the sections of the different subdetectors.

2.6. POPULATING A DATABASE - THE FULL CHAIN 15

simulation jobs. One hint: Make sure to give enough arguments (1.0 as last) to the “KINE” datacard to storethe Monte-Carlo generator information to the FZ file.

A geometry file can be created with the datacardsCFIL ’DETO’ xxxx.rzRSAV ’INIT’in the CMSIM run.

2.6.2 How to create and initialise your own federation

First thing to do is to create a new federation if one doesn’t have one. To do so

1. Go to the directory where you want to store your database. It should have some enough disk space, e.g.$SCRATCH, but careful! On central machines files in $SCRATCH may (and will) be removed.

2. Create the federation with one of makefd scripts (in the PATH after a scram runtime) makefd.central5. If you are using bash, ksh or zsh, you should give “-sh” as argument. It will create a subdirectoy callmyoofd.

3. Execute the script fdinit.csh (or fdinit.sh in the myoofd directory, using source or . (dot),respectivly.

Make sure you don’t have the OO FD BOOT environment variable set when you run this script! If youalready have a federation, just execute the fdinit.(c)sh script. This script will set the neccessary environmentvariables. Databases corresponding to different versions of ORCA are a priori not compatible. It is technicallypossible to upgrade databases, but for time beeing it is recommended to create a new database for each major andminor ORCA release.

Running private lockservers and ams

When working on a private PC or workstation, we recommend to run on this machine a private lockserver and aprivate ams. This increases the performance (when contacting the lockserver, it’s only a local access) and makes iteasier to recover from some problems that can happen when an ORCA program is aborted at inappropriate times.Do NOT run ams on the central machines!

First thing to do is to initialise our shell for Objectivity/DB if you have not yet done so. Type:

eval ‘scram runtime -csh‘

Then start the lockserver and the ams:

oolockserveroostartams

These commands have to be executed once and repeated only after a reboot of the machine. To use the privatelockserver, the makefd.local script needs to be modified. Copy it from the bin/system directory of the central

5Several versions of makefd scripts exist. On machines in the CMS cluster at CERN makefd.central should be used. For private machinesuse makefd.local. To use a laptop, make sure the hostname is constant. This can be insured by specifying the line127.0.0.1 myhost myhost.mydomain localhost localhost.localdomainin the file /etc/hosts.


release area you use and change the lockserver mentioned in that file to your local machine. Every federationcreated after that with the script will use your lockserver.

Running the ams will allow you to access your federation from different machines, setting the OO FD BOOTvariable to host::/localpath/ORCATEST.boot.

2.6.3 Storing the SimHits from FZ file to Objectivity

The first thing to store in an ORCA database are the simulated GEANT hits from the FZ files. An example programto do this is Examples/ExProduction/writeHits.cpp. This file is empty - choosing the correct libraries when linkingthe application is the crucial point. This piece of code obviously doesn’t do much – the secret is in the BuildFile.Here the relevant part:

<environment><External ref=cmsim><External ref=Objectivity><External ref=HepODBMS>

<Group name=G3><Group name=G3Reader><external ref=COBRA Use=CARF></Use>

<ignore> To produce all Ecal, Hcal and Preshower hits </ignore><Group name=CaloHitWriter><Use name=Calorimetry>

<ignore> To produce Muon barrel, endcap and RPC hits </ignore><Group name=MuonHitWriter><Use name=Muon>

<ignore> To produce all Tracker hits </ignore><Group name=TkHitWriter><Use name=Tracker>

<lib name=PBasicDet></lib><Use name=CommonDet></Use>

<external ref=COBRA Use=Utilities></Use>

<bin file=writeHits.cpp></bin></environment>

Before running the program several environment variables have to be set and a database has to be created andinitialised (makefd, fdinit). Mandatory environment variables are:

Variable DescriptionOO FD BOOT bootfile of the federationDETINPUT Input geometry

Table 2.3: the remaining ORCA 5 environment variables for writing SimHits into a database


In addition some entries have to be made in the .orcarc file:

# where is the CMSIM input file?FZInputFiles=/afs/cern.ch/cms/oo/reconstruction/datafiles/cms125/single_mu_pt50.fz# configure the number of events to process (-1 means everything)MaxEvents = 1000# specify the output owner and dataset nameOutputDataSet = /System/SimHits/single_mu_pt50# we certainly want to store the hitsGoPersistent = 1

2.6.4 Mixing signal and pileup events and storing RecHits into the database

To read the SimHits from a database one needs not only the correct code, but also a different set of libraries. Mostimportantly instead of using G3Reader one needs SimReader from CARF. Again, private source code is notneeded.Here is an Example (Examples/ExProduction/writeDigis):

<environment><External ref=Objectivity><External ref=HepODBMS><Group name=G3><Group name=SimReader><external ref=COBRA Use=CARF>

<ignore> To produce Calorimetry digis</ignore><Group name=CaloHitReader><Group name=CaloRHitWriter><Group name=CaloRHitReader><Group name=TriggerPrimitiveWriter><Use name=Calorimetry>

<ignore> To produce all Muon digis </ignore><Group name=MuonDigiWriter><Use name=Muon>

<ignore> To produce Tracker digis </ignore><Group name=TkDigiWriter><Use name=Tracker>

<Use name=CommonDet>

<external ref=COBRA Use=Utilities></Use>

<bin file=writeDigis.cpp></bin></environment>

The only environment variable to set is this time OO FD BOOT. Everything else is specified in the .orcarcfile:

Where to read the pileup, the number of events to process and/or to skip and many parameters for the digitisationare defined in the .orcarc file:


# This will skip the first 10 events and process 5 signal events in total.FirstEvent = 10MaxEvents = 5

InputCollections = /System/SimHits/single_mu_pt50/single_mu_pt50

# general pile-up specificationsPUGenerator:Collection = /System/SimHits/minbias/minbiasPUGenerator:AverageEvents = 4.67PUGenerator:MinBunch = -5PUGenerator:MaxBunch = 3

#owner and dataset name for the outputOutputDataSet = /System/Lumi1033/single_mu_pt50

# and to really save itGoPersistent = 1

# parameters for calorimeter codeCaloRecHit:EcalBarrel = 1CaloRecHit:EcalEndcap = 1CaloRecHit:HcalBarrel = 1CaloRecHit:Preshower = 1Ecal:Barrel:noise = 0.03Ecal:Barrel:threshold = 0.06Ecal:Endcap:noise = 0.15Ecal:Endcap:threshold = 0.30Hcal:noise = 0.0006Hcal:threshold = 0.300Presh:noise = 0.000015Presh:threshold = 0.000054Calo:Preshower:MinBunch=-2Calo:Preshower:MaxBunch=1

# parameters for muon codeMuon:Barrel:MinBunch = 0Muon:Barrel:MaxBunch = 0Muon:EndCap:MinBunch = 0Muon:EndCap:MaxBunch = 0Muon:Rpc:MinBunch = 0Muon:Rpc:MaxBunch = 0

# parameters for trigger codeEcalTrigPrim:Threshold = 0.3HcalTrigPrim:Threshold = 0.3

# how often to saveDBPopulator:MaxDBSize=1.0DBPopulator:CommitInterval=50

In principal it is possible to run this step without saving the RecHits/Digis database. But since the digitisation stepis where a lot of CPU time is needed storing the RecHits/Digis is probably what you want.


2.6.5 Reading RecHits from database

Finally the database is nicely populated and you want to read from it. This corresponds to a CARF/RecReaderapplication. Again here is the BuildFile as taken from Examples/Statistics:

<environment><Group name=G3><Group name=RecReader><external ref=COBRA Use=CARF>

<lib name=CaloHitItr></lib><lib name=CaloHit></lib><lib name=CaloRecHit></lib><lib name=CaloReadout></lib><lib name=CaloDetector></lib><lib name=CaloCommon></lib>

<lib name=MRpc><Group name=MuonB><Group name=MuonE><Group name=MuonRpc><Use name=Muon>

<Group name=TkDigiReader><Use name=Tracker>

<Use name=CommonDet>

<external ref=COBRA use=MagneticField><external ref=COBRA Use=Utilities>

<bin file=ExRecHitStatistics.cpp></bin></environment>

Again, only the OO FD BOOT environment variable has to be set.

The .orcarc needs less options, actually it’s only needed to specify what data to read:

# This will skip the first 10 events and process 5 signal events in total.FirstEvent = 10MaxEvents = 5InputCollections=/System/Lumi1033/single_mu_pt50/single_mu_pt50

2.6.6 Upgrading a private database to a new schema

Populating a private database is timeconsuming and means some work. Logically one wants to avoid this. NewORCA versions may have a different schema that prevents parts of the new code to use the an older database.Often the database can be upgraded to the new schema - this means makeing the new additional or modifiedobjects known to the database. To do so simply type


ooschemaupgrade -infile .../Data/domain/ORCAschema.dmp \\..../myoofd/ORCATEST.boot

where the dots obviously need to be replaced with the correct paths. ORCAchema.dmp is the schema dump ofthe new version of ORCA, ORCATEST.boot is the boot file of the old federation. Warning: It is not possible toupgrade an ORCA5 federation to ORCA6.

2.6.7 Reading from the official production databases in the UserFederation

To read from the official production databases that have been created for the Jet/missing Et and Muon groups,please use the command

setenv OO_FD_BOOT xxxxxx

to specify the userfederation you need. To access specific datasets it is necessary to specify the correct values inthe .orcarc file. The HLT groups maintain tables with the corresponding information. Follow the link on theORCA web page to access information about the official UserFederations.

2.7 A simple example analysis

In this subsection a simple example analysis will be discussed. The example demonstrates how to tell ORCA tobuild clusters in the electro-magnetic calorimeter, how to access the information (E, η, φ) of the clusters and howto fill some histograms. The source code is contained in five files in the directory Examples/ExCalorimetry:ExClusterHistograms.cpp,ExClusterHistos.cc,interface/ExClusterHistos.h,ExClus-terInfo.cc and interface/ExClusterInfo.h. The first file contains the minimal required code for anORCA application, in the next two a histogram class is defined and the last two contain the code and definitionof the analysis class. The reason to split the code into several source files is to minimise compile and link timeto make fast development possible. Haveing the analysis code which is more likely to change in a shared librarymakes it possible to avoid the very time consuming linking step to a large extend. To understand the examples theuser should have some basic familiarity with the C++ programming language [6].

2.7.1 Basic building blocks of an ORCA application

The way to register a private analysis class, i.e. usually a class that inherits from ActiveObserver or Lazy-Observer is largly simplified in ORCA 4. Here what is in ExClusterHistogramss.cpp:


#include "Utilities/Notification/interface/PackageInitializer.h"

#include "Examples/Histograms/interface/ExClusterInfo.h"

PKBuilder<ExClusterInfo> mybuilder("ExClusterInfoBuilder");

The small file consists of three include directives, Architecture.h which is mandatory for all .cc and.cpp files, PackageInitializer.h for definition of the package builder and finally the header file for theuser analysis class. Then an object of class PKBuilder, templated with the user analysis class is declared.Several objects are possible, corresponding to several analyses. They have to be distinguished by the name givenas argument (here ExClusterInfoBuilder).

2.7. A SIMPLE EXAMPLE ANALYSIS 21

2.7.2 User-provided classes

In addition, to do any kind of analysis one needs an observer class (that does the analysis) and a histogrammingclass (to define, fill and to save histograms or ntuples). An observer is an object that will be automatically notified ifcertain things happen. Here, the analysis class inherits from the class ActiveObserver to become an observer.ActiveObserver is templated6 and here precisely it will be an observer of objects G3EventProxy, i.e.events produced by GEANT3. This results in the analysis class being notified when ORCA has read a new eventand handed over a pointer to this event. Here is the class definition (from ExClusterInfo.h):

class ExClusterInfo : private ActiveObserver<G3EventProxy *> {public:/// default constructorExClusterInfo();/// default destructor˜ExClusterInfo();/// this method will do the user analysisvoid myAnalysis(G3EventProxy * ev);

private:/// don’t change the name "upDate" - this method is mandatory.void upDate(G3EventProxy * ev) { if (ev!=0) myAnalysis(ev);}

private:unsigned int eventsAnalysed; //!< just to count events that have been analysedunsigned int runsAnalysed; //!< count the runsunsigned int lastrun; //!< number of the last run analysedExClusterHistos * UserHists; //!< pointer to the Histogram class

};

The class has a constructor, a destructor and a public method myAnalysis. This method will actually dothe analysis. Furthermore there is a private method upDate. This method is mandatory for ActiveOberversand will be called if a new event is processed by ORCA. Here it will then just call the analysis method of theclass, provided the pointer to the event is not the NULL pointer. To do some statistic of the events processed someprivate data members are defined. Since they are private they can only be modified by methods of our analysisclass. Finally a pointer to an instance of a histogram class is available.

Let’s now look at the implementation of the methods (in the file ExClusterInfo.cc) - first the constructor. Itis automatically called when a new instance of the class is created. Therefore one can do here the necessaryinitialisations. Since we want to fill some histograms here the histogram class is instantiated.

ExClusterInfo::ExClusterInfo() {cout << "===========================================================" << endl;cout << "=== Start create new ExClusterInfo ===" << endl;eventsAnalysed = 0;runsAnalysed = 0;lastrun = 0;

// Instantiate the user histogram (capitals in filenames are ignored by ZEBRA)UserHists = new ExClusterHistos("exhistogram.hbook");// UserHists = new ExClusterHistos(); // an alternative,

// default filename is calohistos.hbook

cout << "=== Done create new ExClusterInfo ===" << endl;

6C++ terminus. If something is templated it works with different types or objects in the same way. E.g. it works with int, float or likehere with pointers to different kinds of classes.


cout << "===========================================================" << endl;}

Similarly the destructor is automatically called whenever an instance of the class is deleted. Consequently onecan do here some final calculations and print a summary.

ExClusterInfo::˜ExClusterInfo() {cout << "===========================================================" << endl;cout << "=== Start delete ExClusterInfo ===" << endl;cout << " Number of events analysed: " << eventsAnalysed << endl;cout << " Number of runs analysed: " << runsAnalysed << endl;UserHists->FillEventStat(eventsAnalysed,runsAnalysed);// Cleanup the Histograms - here they will be saved to filedelete UserHists;cout << "=== Done delete ExClusterInfo ===" << endl;cout << "===========================================================" << endl;

}

Some of the summary information is filled into a histogram in this case. To avoid a crash of a program thehistogram object must still exist at that point. Only then the instance of our histogram class is deleted (and duringits deletion the histograms are saved to file).

Finally follows the method where the analysis is done:

void ExClusterInfo::myAnalysis(G3EventProxy * ev) {

int nClusters=0; // just to count the clusters

// We want to loop over all calorimetric clusters -> get an iterator.// The iterator needs to know about the event to use.// What kind of clusters we use is determined by the libraries specified in// the BuildFile, here:<lib name=EcalFixedWindow>

RecItr<CaloCluster> MyCluster(ev->recEvent());

// Just print the event number (see CARF/G3Event/interface/G3EventHeader.h)cout << "===========================================================" << endl;cout << "=== Private analysis of event #"<< ev->id().eventInRun()

<< " in run #" << ev->id().runNumber() << endl;

eventsAnalysed++; // some statistics: count events and runs processedif (ev->id().runNumber() != lastrun) {

lastrun = (unsigned int) ev->id().runNumber();runsAnalysed++;

}

// Here is the loop over all clusterswhile (MyCluster.next()) {

nClusters++; // count the clusters// Print some of the cluster properties// see Calorimetry/CaloCommon/interface/CaloCluster.hcout << "Cluster " << nClusters <<": E=" << MyCluster->Energy()

<< ", eta="<< MyCluster->Eta()<< ", phi="<< MyCluster->Phi() << endl;

// Fill them to (our) histograms. Defined in ExClusterHistos.hUserHists->FillEepCluster(MyCluster->Energy(), MyCluster->Eta(),


MyCluster->Phi());}// Fill (our) histogram for statisticsUserHists->FillNCluster(nClusters);

cout << "===========================================================" << endl;};

The important point here is the use of an iterator, RecItr. Again this is a template - here it is used for objectsof the class CaloCluster. It reduces loops over all clusters to the simple statementwhile (MyCluster.next()) {} .Then member functions of the CaloCluster class are used to access information about the current cluster, likeits energy,E, (Energy()), its pseudo-rapidity, η, (Eta()) and its azimuthal angle, φ, (Phi()). This informationis filled into histograms with member functions of the EcalHisto class.

The last missing part is the histogramming class. Here the definition from the file ExClusterHistos.h:

class ExClusterHistos : private HB4Histogrammer {public:/** The default constructor with the default arguments.* Missing arguments will be added automatically with the value given here. */

ExClusterHistos(const char * filename = "calohistos.hbook", int lun=10): HB4Histogrammer(filename, lun)

{ BaseInit(); }/// The destructor. Here the final cleanup is done.˜ExClusterHistos() { BaseEnd();}

// Public methods to access the user histograms/** Fill histograms for the energy \a e , the pseudorapidity \a eta and* the azimuthal angle \a phi .*/

void FillEepCluster(float e, float eta, float phi);/** Fill histograms for the number of clusters \a n . */void FillNCluster(int n);/** Fill histograms for statistics with the number of events* \a events and runs \a runs analysed. */

void FillEventStat(unsigned int events, unsigned int runs);

private: // private methods both are mandatoryvirtual void book(); //!< book the histogramsvirtual void hend(); //!< save the histograms to file

public: // public data is forbidden by CMS coding rules

private:// Define some abbreviation. These are pointers to one and// two-dimensional histograms. Put these into the class. This// avoids conflicts in the global namespace, which you should not// pollute anyway.typedef auto_ptr<CHBookHisto> HP1;typedef auto_ptr<CHBookHisto2> HP2;typedef auto_ptr<CHBookHistoProf> HPP;

private: // private data// Since they are private, histograms are accessable only via public methodsHP1 hCalo1,hCalo1b, hCalo2, hCalo3, hCalo4, hGlobal;HP2 hCalo5;


HPP hCalo6;};

The class inherits its general functionality from the HB4Histogrammer class. This is taking care of theZEBRA bookkeeping (no more hlimit) and the file handling. The constructor of ExClusterHistos has asarguments a filename and a unit where to open the file. Sensible default values are provided. These are automati-cally used when the constructor is called with one or both arguments left out.

Three public methods are defined to provide access to the (private) user histograms. The use of public classdata is prohibited by the CMS coding rules [7], so one cannot fill histograms directly. Another good reason for thisis to avoid changes to the analysis class. If you for instance decide to fill the cluster information to Ntuples insteadof histograms the analysis class need not change. It’s only using the public Fill... methods and does not care ifthese methods fill histograms or ntuples.

There are two mandatory private methods: book() and hend(). They are required by HB4Histogrammerand called in the constructor and destructor of the class, respectively. Finally a number of pointers to histogramsare defined. HP1 and HP2 are abbreviations for pointers to one- and two-dimensional histograms, defined inExClusterHistos.h.

The source code for the methods is located in ExClusterHistos.cc. Here is the booking of the histogramsdone:

void ExClusterHistos::book() {cout << "===========================================================" << endl;cout << "=== Start booking user histograms ===" << endl;

// ID Name Nbins Min MaxhCalo1 = HP1(new CHBookHisto (100, "Calo:E(cluster) ", 100, 0., 100. ));hCalo1b = HP1(new CHBookHisto (101, "Calo:E(cluster) ", 50, 0., 500. ));hCalo2 = HP1(new CHBookHisto (200, "Calo:n cluster" , 101, -0.5, 100.5 ));hCalo3 = HP1(new CHBookHisto (300, "Calo:eta(cluster)", 100, -2.5, 2.5 ));hCalo4 = HP1(new CHBookHisto (400, "Calo:phi(cluster)", 100, 0., 3.15 ));hCalo5 = HP2(new CHBookHisto2(500, "Calo:eta_vs_phi (cluster)",

100, -2.5, 2.5, 100, 0., 3.15 ));hCalo6 = HPP(new CHBookHistoProf(600,"Calo",100,-2.5,2.5,0.,3.2, " "));hGlobal = HP1(new CHBookHisto ( 1, "Events/Runs", 2, 0.5, 2.5 ));

cout << "=== Done booking user histograms ===" << endl;cout << "===========================================================" << endl;

}

The arguments needed to define a histogram are the same as in FORTRAN/HBOOK commands. If the his-togram ID is omitted an ID will be generated automatically.

From the destructor of the class hend() will be called. Here one can do some printout or final manipulationsof the histograms.

void ExClusterHistos::hend() {cout << "===========================================================" << endl;cout << "=== Start cleanup user histograms ===" << endl;

hCalo1->print();hCalo1b->print();hCalo2->print();

cout << "=== Done cleanup user histograms ===" << endl;


cout << "===========================================================" << endl;}

The histograms are filled using the public methods. These methods can include type conversions and rangecheckings.

// fill the histos with Energy, Pseudorapidity and Azimuthal anglevoid ExClusterHistos::FillEepCluster(float energy, float eta, float phi) {hCalo1->fill(energy);hCalo1b->fill(energy);hCalo3->fill(eta);hCalo4->fill(phi);hCalo5->fill(eta,phi);hCalo6->fill(eta,phi);

}

// fill the number of Ecal clustersvoid ExClusterHistos::FillNCluster(int ncl) {hCalo2->fill((float) ncl);

}

// fill the number of events and runs analysedvoid ExClusterHistos::FillEventStat(unsigned int events, unsigned int runs) {hGlobal->fill(1.,(float) events);hGlobal->fill(2.,(float) runs);

}

2.7.3 Adapting the BuildFile

The SCRAM BuildFile used to compile and link follows below.

<External ref=cmsim>

<ignore>This is the library with out local analysis classes</ignore><lib name=ExCalorimetry>

<environment><ignore>A RecReader application reads from a database where

signal & pileup have already been mixed.</ignore><Group name=RecReader><external ref=COBRA Use=CARF>

<Group name=CaloHitReader><Group name=CaloRHitWriter><Group name=CaloRHitReader>

<ignore>Here we specify our clustering algorithm</ignore><lib name=EcalFixedWindow>

<ignore>We want clusters</ignore><lib name=CaloData><lib name=CaloCluster><lib name=PersistentCaloCluster><Use name=Calorimetry>


<external ref=COBRA Use=Utilities>

<bin file=ExClusterHistograms.cpp></bin></environment>

Because the histogramming and analysis classes are defined in separate source files a library will be created.By default this will be a shared library with debug information. It will be called libExCalorimetry.so (thename is always that of the package we work in) and all *.cc files will be compiled and put into this library .Naming the source files for library classes with the extension *.cc and those for binaries *.cpp is used as aconvention here.

Next the target program is defined in the line starting with< bin file=. ExClusterHistograms.cppis added to compile the file ExClusterHistograms.cpp and then link it to produce an executable calledExClusterHistograms.

The tricky part in ORCA is to choose the right set of libraries to be used. Here some of them are specified ex-plicitly, like ExCalorimetry, CaloCluster and EcalFixedWindow. But for each subsystem predefinedgroups of libraries exist for standard task. These are selected with the Group tags that have to preceed Use tagof the corresponding subsystem. Refer to the ReferenceManual and to the sections on the different subsectionsin this UserGuide for more details.

That’s it! All that is left is to issue scram b to create the program, set the environment and run it. A normalHBOOK file called exhistogram.hbook will be created. It contains the histograms and can be used withPAW.

2.8 Overview of BuildFile options

The most important when editing BuildFiles is to either define additional binary targets or to change the list oflibraries to be linked against.

The first point is very straightforward. To each binary target, i.e. to each program that one wants to be able torun, a line like

<bin file=NAME.cpp></bin>

corresponds. Note the default extension .cpp which should be used for source files of binary targets.

Choosing the correct libraries is a bit more delicate, especially with shared libraries that ORCA uses now.Basically, you add for each subsystem that you are using a line like

<Use name=SUBSYSTEM>

To add a subsystem from a different CMS project (only COBRA for time beeing) the same is done like

<external ref=PROJECT Use=SUBSYSTEM>

For some subsystems (like Muon and Trigger) things are more complicated. There one has to use lines like

<Group name=GROUPNAME>

2.9. SHALLOW COPIES, USERCOLLECTIONS AND DEEP COPIES OF A USERFEDERATION 27

to select e.g. the libraries needed for the muon barrel code (MuonB) or the calorimeter trigger code (L1Calo).Important: These lines with the Group tag have preceed the line with the Use tag of the corresponding subsystem.Some subsystems will not give any library if you don’t specify a group tag. Important: Before anything else theCARF subsystem (from COBRA) has to be specified.

For the available group tags, see the documentation of the corresponding subsystem.

Another complication is that some subsystems depend on other subsystems. For example Tracker and Muonboth need CommonDet and MagneticField or CombinedDet needs Tracker and Calorimtery. For information onthis, please also check the documentation of the corresponding subsystems

2.9 Shallow copies, UserCollections and deep copies of a UserFederation

This section is currently beeing written. Information may be incomplete!

The most likely scenario when using ORCA is to analyse events that are stored in one of the UserFederations.These UserFederations are read-only, so a user can not store any HTL-Histograms or UserCollections in them. Therecommended way to bypass this problem are shallow copies of the UserFederation.

Typically most of the events in a database of the UserFederations are not very interesting for an analysis. Tospeed things up one can run a filter on the database and store pointers to the interesting events in what is called asUserCollections. Since Objectivity databases have random access (contrary to the sequential access to FZ files)this allows to read the selected events in a much shorter time.

Even running over the subset of events in a UserCollection access can be slowed down due to tape mounts andstaging into the (finit size) disk pool of the UserFederation. If sufficiently large disk space is available locally partof the event, i.e. MetaData, Monte-Carlo information and Digis/RecHits, can be cloned. (Currently no cloning ofSimHits is implemented). If event data is cloned the shallow copy becomes a deep copy. This section explainshow to create a shallow copy, write a UserCollection, clone the selected events and add Tracker digis for them.

2.9.1 Creating a shallow copy

A shallow copy of a UserFederation is a normal federation located in a directory that the user can fully control,e.g. myoofd. This federation has it’s own .boot-file and .FDDB-file and can use all databases in that arein the UserFederation (at the time when you copy). These databases are accessed via the AMS defined for theUserFederation. The important difference is that a user can add databases to this copy - simply because it’s hisprivate federation.

A script is available that does the shallow copy. To create for example a shallow copy of the Muon UserFeder-ation, one would enter the following commands on the cmslx cluster (after setting the runtime environment in anORCA area):

cd $SCRATCHmkdir myclonefd; cd myclonefdshallow-federation-copy.pl \--source nobj03.cern.ch::/usr/objy/cmsprod/reconstruction/user/egam0102_600/egam0102.boot \--lockserver shift19.cern.ch

To work with this federation set the OO FD BOOT environment variable to $SCRATCH/myclonefd/muonDIGI0300.bootand run your ORCA applications as usual.


2.9.2 UserCollections

A typical use case for a UserCollection is the selection of events based on pt. The program writeUserCol-lection.cpp in Examples/ExProduction shows how to do this. Accessing pt is already an advancedexample that uses a helper class (PSE). The most simple case is to have a class that inherits from UserFilter.This CARF class requires a method

virtual bool filter(G3EventProxy * ev)

that gets a pointer to the event data and returns true or false. If true is returned the event (more precisely anObjecitvity pointer to the event) is put into the UserCollection. It is important to name the collection so that onecan distinguish between a multitude of collections. The following line would give the name MyPtHatFilter to thecollection.

MyUserFilter() : UserFilter("MyPtHatFilter")

The collection is stored in the database as specified by parameter with the filter name in the .orcarc file:

MyPtHatFilter = /MyDB/selectOnPtHat/ptHatLarger50GeV

In this example the collection is stored in a private database called MyDB with the owner name selectOnPtHat andthe dataset name ptHatLarger50GeV. In addition the line

ExtraPackages = CaloCommon:CaloReadout

may be required for technical reasons to read old data.

Further parameters are needed in the .orcarc file where Filtername needs to be replaced with ... guesswhat! MyPtHatFilter in this case:

• Filtername:IOModehas New and Append as possible values. Append allows to combine events from different datasets in asingle UserCollection.

2.9.3 Cloneing Digis or how to make a deep copy

As for the writeHits and writeDigis applications described early all the magic when cloning digis is inBuildFile and the .orcarc file. The applicationcloneDigis is available in Examples/ExProduction.

The BuildFile defines a standard RecReader. Currently the Muon libraries need to be required for technicalreasons.

In the .orcarc file one needs to set Digi:Replica = 1 to clone all Calo and Muon digis andMCInfo:Replica= Signal to clone the Monte-Carlo information for the signal, i.e. not pileup, events. If the dataset contains al-ready Tracker digis, SetUpClone:Reference=1 is needed in addition (see Examples/ExProduction/cloneAllDigis).

To store the clones into new databases GoPersistent = 1 is required as in a writeDigis application.Finally one needs to select the UserCollection and the database where it is stored, for the pt example it looks likethis:

InputCollections=/MyDB/selectOnPtHat/ptHatLarger50GeV

The output datset name is specified as usual with the OutputDataSet card.

2.10. ADDING NEW DIGIS 29

2.10 Adding new Digis

The most frequent case when one wants to add digis is currently the reconstruction of the Tracker. This is notyet done by the standard production (to save space and time), so that the events in the UserFederations don’t havetracker digis. Other scenarios are the redigitisation of Calorimetry or Muon with improved algorithms.

To add digis to a federation no specific source code is needed. For the BuildFile the same rules apply asfor a writeDigi application, see Section 2.6.4. As usual, specify the input collectios and the output dataset.

The selection of what do digitize is done in the .orcarc file. To tell the application that digis are added orchanged, set Digi:Update = 1. How the digis should be updated can be specified for each ReadoutUnit typeseparatly. Up to ORCA 5 the possible values of a 2-chararcter code were used: CR, HR, CT, HT for Calorimetry(ECAL RecHits, HCAL RecHits, ECAL Trigger primitives and HCAL Trigger primitives), TA, TD for Tracker(associations and digis) and more explicit names for Muon barrel, endcap and RPC digis. Table 2.4 lists the namesfor the Readout units in ORCA 6.

The requests are defined as XX:Request = value where XX is one of the codes just listed and value canbe

Auto Will produced digis if they do not yet exist. This is the default.

Construct Forces digitisation even if persistent digis exist already.

Nop Switch off digitisation even if the code has been loaded and no persistent digis exist

DontTouch To avoid re-digitization (and hit loading) of empty detectors (for instance digi created with ORCA versionsolder than 4.3)

The application addDigis in Examples/ExProduction can be used to add Tracker digis to the events.In the same package there is also the script writeAndCloneAndTkdigiUserCollection.shwhich doeseverything from building a UserCollection based on a pt cut, with cloning and digitisation of Tracker in one go.

2.11 Tags

Tags are small pieces of user event data stored in the database, with optionally a link back to the original event.These tags are intended to be used for

• Fast event selection

• Ntuple replacement

Fast event selection is done by placing in the tags the data you’d be most likely to cut on. Then, you can cutevents by only reading the tags, without reconstructing or fetching the data for the event.

Generic tags (see Section 12.1.2) are based on the HepODBMS package, which is the ntuple format used bythe Lizard plotter, so (simple) data in these tags can be plotted independent of ORCA.

COBRA implements a more complicated version of tags (see Section 12.1.3). They can store objects of moresophisticated classes and allow in addition to get a link back to the full event. The very familar sentence “But Idon’t have this in my Ntuple” that required a full rerun over all data recomputing the same quantities again is notrequired anymore.


Name SubdetectorHits

TrackerHitsPixelBarrelHighTof TrackerTrackerHitsPixelBarrelLowTof TrackerTrackerHitsPixelEndcapHighTof TrackerTrackerHitsPixelEndcapLowTof TrackerTrackerHitsTOBHighTof TrackerTrackerHitsTOBLowTof TrackerTrackerHitsTIBHighTof TrackerTrackerHitsTIBLowTof TrackerTrackerHitsTECHighTof TrackerTrackerHitsTECLowTof TrackerTrackerHitsTIDHighTof TrackerTrackerHitsTIDLowTof TrackerCH EcalHH HcalMuonHitsBarrel MuonMuonHitsEndcap MuonMuonHitsRPC Muon

DigisTD TrackerCR Ecal RecHitsHR Hcal RecHitsCS Ecal selective readoutCT Ecal Trigger towersHT Hcal Trigger towersMuonDigisBarrel MuonMuonDigisEndcap MuonMuonDigisRPC Muon

Digi to SimHit assiciationsTA TrackerMuonAssociationsBarrel MuonMuonAssociationsEndcap MuonMuonAssociationsRpc Muon

Table 2.4: Names for the readout units in ORCA 6.

Part II

Sub-System Descriptions

31

Chapter 3

CommonDet

3.1 Introduction

The CommonDet subsystem contains classes general enough to be used in more than one detector subsystem.These include

• Basic geometry classes

• Primitives and general utilities for tracking

• Classes for simulated and reconstructed hits, digis, and base classes for detector, readout etc.

• General utilities that are here for maintenance easons

3.2 Detector view

The detector-centric view of the event data is based on detector objects that provide reconstructed hits, digis, sim-ulated hits, and all other detector-related objects. Each detector object provides only the reconstructed/simulatedobjects contained in itself. The granularity of the detector-associated event data is thus determined by the granu-larity of the detector objects in the model.

Combined with the idea (or design pattern) of composite objects, which boils down to build composite objectsfrom components of the same type as the composite, we can introduce several levels of granularity, each tuned fora specific task.

3.2.1 The Det

The most general view of a detector is represented by the Det interface (CommonDet/Basic/Det/interface/Det.h).The Det interface is an abstraction for a detector that measures the passage of particles through a “detectionsurface”, for example a silicon strip detector or a layer of a calorimeter. The number of parameters measuredis not fixed. In most cases these include the position of the particle crossing on the detection surface, but forsome detectors they may include a measurement of the direction or of the momentum/energy. For example, aRecHit from the Tracker measures only the local position, while a RecHit from the Muon system measures alsothe direction of the particle.

33

34 CHAPTER 3. COMMONDET

Accessing RecHits

The mesurement of a Det is a RecHit (a reconstructed hit), and we can always obtain all the RecHits of a Det usingthe

virtual RecHitContainer recHits() const;

method. Note that the ReacHit container is returned by value and should be stored in a local variable beforeiterating over it, like this:

const Det& aDet(...); // any Det objectDet::RecHitContainer hits = aDet.recHits();for ( Det::RecHitIterator i=hits.begin(); i!=hits.end();i++) {... // correct iteration

}

and not like this:

const Det& aDet(...); // any Det objectfor ( Det::RecHitIterator i =aDet.recHits().begin();

i!=aDet.recHits().end(); i++) {... // WRONG WAY OF ITERATING!

}

In the second example the recHits() method is invoked twice, returning two different RecHitContainer objects, andthe iteration is going from the begin() of the first one to the end() of the second one, with unpredictable results(usually a segmentation fault at a later stage in the program).

The RecHit interface will be described in section ??.

Surface and frame transformations

A Det has a BoundSurface associated with it, accessible via the surface() method. The surface defines a localcoordinate system or refernce frame, which is the refernce frame of the detector. All transformations from/tolocal/global frame are performed by the Surface of the Det. Reconstructed/simulated objects associated witha detector only store their local position/direction in the Det frame. The transformation to the global frame isperformed on-the-fly by the methods toLocal() and toGlobal() of the Surface, which are also provided inthe Det interface for convenience. This automatically insures that all hits move together with the Det they belongto, when it is displaced, e.g. in misalignment studies.

The measurements() method

From track reconstruction point of view the Det has to provide RecHits efficiently. Most of the time what isneeded is not all hits, but just those which are compatible with some track candidate. “Efficiently” in this casemeans to find all the hits that are compatible without iterating over many hits that are incompatible. The criteriaof compatibility is (track reconstruction) algorithm dependant. To satisfy this request, the Det provides anothermethod,

virtual vector<TrajectoryMeasurement>measurements( const FreeTrajectoryState&, const Propagator&,

const MeasurementEstimator&) const;

3.2. DETECTOR VIEW 35

The FreeTrajectoryState (see ??) encapsulates the information about the predicted track parameters,and can be defined anywhere in space (e.g. on a previous layer of the Tracker or Muon system).

The Propagator (see 6.1.2) is needed to move the predicted parameters to the surface of the Det. Since theoptimal way to do this is algorithm-dependant the Propagator is provided as an argument.

The MeasurementEstimator is an object that defines what it means for a RecHit to be compatible with a track.It has just one method that takes as arguments a RecHit and a TrajectoryStateOnSurface (which encapsulates thetrack parameters on the Det surface), and returns 0 if they are incompatible or a non-zero compatibility measure ifthey are compatible. An example is an estimator based on the χ2, with some fixed cutoff.

What the measurements() method returns is not a container of RecHits, but a container of TrajectoryMeasure-ments. These objects hold a RecHit, but also the predicted track state on the Det surface and the value of thecompatibility estimate. This is done to avoid losing the information which has been computed while searching forcompatible hits, since it is likely that it will be needed again later in the track reconstruction algorithm.

The responsibility to search for compatible hits is given to the Det rather than to an external algorithm sincedifferent Dets may have very different structure (as we’ll see later), but each one “knows” it’s own structure verywell, and is thus more likely to perform the search in the most efficient way for it’s structure.

3.2.2 The DetUnit

While the Det is a very abstract detector that need not correspond to a physical detector, the DetUnit correspondsexactly to one physical detector unit.

The DetUnit publicly inherits from Det, which means that it is a det. It extends the Det interface in severalways relevant for unit level reconstruction and simulation of response.

An important simplification, which is valid for all tracking detector units in CMS, is that the surface of theDetUnit is a BoundPlane, i.e. the DetUnit is flat. The method

virtual const BoundPlane& specificSurface() const;

gives access to the BoundPlane interface of the surface.

The DetUnit performs all reconstruction and response simulation locally, it is helped in this by two container-like objects, a Readout and a SimDet, and two algorithmic objects, a Digitizer and a Clusterizer.

Readout

The DetUnit has a Readout, accessed by the readout() method, through which the Digis (the amplitudes onthe readout channels) are accessed. Since the different DetUnits have different Digi types (e.g. StripDigi andPixelDigi), the Readout cannot provide directly access to them. It provides methods that are meaningful for allDigis, and leaves to specialized derived classes (like StripReadout and PixelReadout) the task of providing fullaccess to concrete Digis.

The Digi access methods available from a Readout are empty() (true if there are no Digis), ndigis() (thenumber of Digis), and channelAdc( Digi::ChannelType), which returns the amplitude in ADC countsfor a given channel, zero if no Digi with the given channel number is present.

These methods, as all other Digi access methods in derived Readout classes, may trigger digitization (detectorresponse simulation), access to the persistant Digi store, or whatever action is needed to produce the Digis for thecurrent event in case they are not already up-to-date. This is done by the virtual updateDigis() method.


SimDet and access to SimHits

The DetUnit holds all the simulation-related event information in a separate object, the SimDet, which need notbe peresent (e.g. in case of real data). It is accessed via the simDet() method, which returns a SimDet* whichmay be zero, so it is necessary to check for the presence of a SimDet (i.e. the non-zeroness of the returned pointer)before using it.

The SimDet provides access to the simulated hits, represented by SimHit objects, that are produced externally(usually by Geant) and serve as input to the detector response simulation and reconstruction. This is done via thmethod

const SimHitContainer& simHits() const;

which returns the container by reference, so, unlike for the recHits() method of the Det, it is not a good idea tostore the returned container in a local variable, since you will produce an unneeded copy (although this is certainlynot an error - it’s just inefficient).

For an example of SimHit access see ??. The SimHit interface is described in ??.

Digitization

This is the historical name used for detector response simulation, i.e. the process of producing Digis (which aresupposed to be the same objects as what we’ll get from the real detector) from the SimHits.

Since the result of the digitization is a container of some concrete type of Digis, to be put in some concretetype of Readout, it is not meaningful to define a base class for Digitizers of DetUnits. The Digitizers appear lowerin the inheritence tree of the DetUnit.

Digitization happens transparantly when one of the Digi access methods is invoked (see 3.2.2)

DetUnit::measurements

In the case of a DetUnit the measurements method (see 3.2.1) simply propagates the candidate trajectory to theDetUnit’s surfece and invokes the estimator method

estimate( const TrajectoryStateOnSurface& ts,const RecHit& hit) const;

on all or part of it’s RecHits (depending on it’s level of sophistication) in order to return only compatible RecHits.

In the case of no compatible hits the DetUnit reacts differently depending on whether it is geometrically com-patible with the trajectory or not.

• If it is geometrically compatible (according to the estimator method

estimate( const TrajectoryStateOnSurface& ts,const BoundPlane& plane) const;

) the DetUnit is considered inefficient, and a TrajectoryMeasurement with an invalid RecHit is returned toallow continuation of the trajectory through this DetUnit with taking into account of the material effects.

• If it is geometrically incompatible ther result is empty

3.2. DETECTOR VIEW 37

The DetUnit reurns a TrajectoryMeasurement with an invalid RecHit only if there are no valid compatibleRecHits to return. This is different from the DetLayer behaviour (see 3.2.3)

3.2.3 DetLayer

The modelling of the CMS Tracker or Muon system as a collection of DetUnits is well suited for chamber levelsimulation and reconstruction, since all such algorithms operate locally, and the DetUnit is not affected by thecomplexity of the full system (in fact the same DetUnit is used in test beam environments).

However, the DetUnit granularity if not appropriate for track reconstruction: There are about 30000 DetUnit inthe Tracker, and about 1000 in the Muon system. Iterating over them efficiently in search for tracks requires verycomplicated networks of connections between them.

Instead, the track reconstruction is done using complete layers of DetUnits, called DetLayers (Common-Det/DetLayout/interface/DetLayer.h). A layer is defined as a collection of DetUnits that lie approximately ona simple surface (like a cylinder or a plane). Although this is not a general requirement, the current track findingalgoritms require layers that have geometric coverage of the surface close to 100%. A well reconstructed trackthus has close to one hit per crossed layer (it can have less due to geometrical or detector inefficency, it can havemore in case of DetUnit overlaps).

This model is not appropriate for all possible layouts (the early CMS barrel tracker had a spiral arrangment ofDetUnits) but it is appropriate for the current CMS layout.

Navigation

There are currently 13 barrel layers in the Tracker, a few tens in the forward Tracker, and four in each Mounsystem. With this level of granularity the links between layers become quite manageable: they are trivial in thebarrel part and in the forward muon part, and can be derived from the layer layout in reasonable amount of time(seconds) for the other regions.

The initialization of the inter-layer links is not the task of the DetLayer, it is done by an external object (a“navigation school”) specific to the track reconstruction algorithm. The navigation from layer to layer is doneusing the

Access to specific surface

Concrete DetLayers are currently of type BarrelDetLayer or ForwardDetLayer (both derived publicly from Det-Layer). These interfaces add an additional method, specificSurface(), which returns respectively a Bound-Cylinder or a BoundDisk. This is the only clean way to access the radius of a barrel layer, or the inner and outerradius of a forward disk, since the general BoundSurface returned by the surface() method of the DetLayerdoes not have a radius() method.

The DetLayer as a Det

The DetLayer is a Det, and thus has the Det interface. The measurements(...) method (see 3.2.1) reallycomes into play when applied to a DetLayer. In this case the DetLayer determines the minimal number of Detsthat have to be queried for RecHits, collects all the compatible hits and returns them in a sorted container (the mostcompatible hit first). The layer uses the MeasurementEstimator in two different ways to achieve this:

It first uses the method


estimate( const TrajectoryStateOnSurface& ts,const BoundPlane& plane) const;

to determine the range of detectors to query, starting from the best candidate (the one that contains the trajectoryextrapolation) and extending the search in all directions untill it encounters an incompatible Det or untill it reaches“the other side” of the layer with respect to the beam spot.

Then the layer queries each compatible det for compatible RecHits using the Det’s measurements method.Depending on the complexity of the layer this may result in direct query of the DetUnits of the layer or in aindirect one via intermidiate composite Dets (like GluedDet or TurbineBlade). Ultimately the minimal necessaryset of DetUnits, i.e. only those geometrically compatible with the input trajectory, are queried for RecHits. Thebehaviour of the DetUnit::measurements is described in section 3.2.2

There is one important difference between the DetLayer and the DetUnit measurements behaviour: the Det-Layer always appends a TrajectoryMeasurement with an invalid RecHit to the end of the container of compatiblemeasurements, while the DetUnit only returns such a “invalid” measurement if there are no valid compatible hits.This behaviour is needed to allow crossing of the DetLayer without using any RecHits from it, but with inclusionof the material of the crossed Det in the layer. In fact, it would be difficult to determine which invalid measurementto use for this purpose if only valid measurements from several different Dets are returned (especially if the Detactually crossed is inefficient), or if several invalid measurements are returned.

The DetLayer returns an empty result only if it is geometrically incompatible with the candidate trajectory.

Chapter 4

Calorimetry

4.1 Introduction

All basic calorimeter reconstruction is included in the Calorimeter sub-system. That is ECAL and HCAL (includ-ing the HF or VCAL) and the EndCap preshower reconstruction. Under the heading reconstruction is included:

• conversion of GEANT hits to pseudo-digits

• construction of trigger primitives for use in trigger simulation

• conversion of pseudo-digits to reconstructed hits

• grouping of reconstructed hits into towers (including ECAL and HCAL)

• clustering in the separate calorimeters

• inclusion of Endcap PreShower clusters with ECAL and HCAl clusters

For an overview of the package dependency structure within Calorimetry see Figure 4.1.

4.2 Configuration

Many parameters of Calorimetry can be configured using the .orcarc mechanism. Values are read from a local file.orcarc in the directory in which the job is running.

The full list of parameters and their default values can be found on the web in the reference manual (follow thelinks to Calorimetry -¿ CaloConfigurables)

You do not have to supply any values for parameters you do not want to change - they get their defaults currentlyfrom the code itself)

39

40 CHAPTER 4. CALORIMETRY

Figure 4.1: Calorimetry Package Dependency.

4.3. ECAL REALISTIC DIGITIZATION 41

4.3 Ecal Realistic Digitization

4.3.1 Introduction to Realistic Digitization

The software implemented for the realistic calorimeter digitization in ORCA4 is based on the readout descriptionof the ECAL as found in Appendix A of CMS NOTE 1999/024. The CMS calorimeters consist of the ECAL barreland endcaps, HCAL barrel and endcaps, VFCAL and preshower detectors. All of these calorimeters have differentfront-end characteristics. These range from pulse shape, noise properties, pedestals, gain factors, bit-range andtime-frame lengths. The realistic packages load the needed front-end parameters into the digitization frameworkof the CaloReadout calorimetry package. These parameters provide an accurate representation of the front-endcharacteristics. The digitization of pile-up events is integral to the digitization framework, and is most affected bythe pulse shape.

4.3.2 Signal Processing in the Time Domain

An essential aspect of the digitization process with LHC electronics is the time domain. The detector simulationrecords the arrival time and the amount of energy deposited by each particle which is incident on a calorimetersensitive volume. This information is formatted into a CaloHit object. The arrival time effectively corresponds toa particle’s time-of-flight from the primary vertex of the simulated event.

The mechanism for particle detection and conversion to an analog electrical signal is approximated by a simplemodel. Each simulation hit is converted to a preamp pulse, a fixed shape for each individual channel, whosemaximum (peak) amplitude corresponds to the energy deposited in the sensitive volume. The time at which thepeak amplitude occurs is related to the hit time by the relationship,

tpeakTime = thitTime − ttimeOfFlightEstimate + ttimeOfBunch (4.1)

where:1) ttimeOfFlightEstimate is the distance, between the nominal center of the CMS detector and the calorimeter cell,divided by the speed-of-light, and2) ttimeOfBunch is the event time with respect to the trigger, which takes on the values of i · 25 ns for i =−NminBunch, ...,−2,−1, 0, 1, 2, ..., NmaxBunch (the trigger occurs at bunch i = 0).

It is useful to define the quantity,

tjitter = thitTime − ttimeOfFlightEstimate . (4.2)

This value corresponds to the deviation in time between the expected arrival time of a particle to a detector elementand its actual arrival time.

The quantity ttimeOfFlightEstimate represents the clock phase for the channel. It is assumed that this phase willbe adjusted according to the timeOfFlight, but this is not a requirement.

4.3.3 Pulse Shape

The pulse shape is a function which is particular to the signal collection and preamplifier electronics. For theECAL, a pulse shape was fit from test beam data with the parameterization,

f(t) = A0

(

xf + c2 · [xf ]2 + c3 · [xf ]3)

× exp[

−xf + d2 · [xf ]2 + d3 · [xf ]3]

(4.3)

with, for t0 being the beginning of the pulse,

xf =t− t0τ

(4.4)


where t is the time in nanoseconds. The pulse height normalization is chosen such that f(tpeakTime) = 1.0 GeV,see Table 4.1. The actual test beam pulse had an undershoot in the tail. The undershoot was truncated as itoriginated from a capacitance mismatch not expected in the final pulse shape. This also causes the ECAL pulseshape to have a tail which is shorter than expected from the theoretical preamp response.

Parameter ValuetpeakTime 47.6683 ns

τ 182.64 nsA0 8.6315c2 -1.3924c3 0.3445d2 -2.1681d3 0.6719

Table 4.1: ECAL Pulse Parameterization in ORCA4.

4.3.4 Photostatistics and Constant Term

The simulated hit energies in the CaloHit object do not contain photostatistics, and some contributions to theconstant term of the energy resolution are neglected. Photostatistics is applied by converting the simulated hitenergy into a Poisson distributed Monte Carlo trial for the number of photoelectrons observed in the dual APD.The conversion factor used is 4 photoelectrons/MeV.

The constant term δ is applied after the photostatistics simulation.

Ecorrected = (1 + δ) · E (4.5)

The value of δ is generated with a Gaussian distributed Monte Carlo trial with a standard deviation of 0.005 for theECAL barrel and endcap.

4.3.5 Pile-Up Handling

No distinction is made between a triggered event and a pile-up event with regard to the signal processing. Thequantity ttimeOfBunch, described in the previous section, takes on the values of i · 25 ns for

i = −NminBunch, ...,−2,−1, 0, 1, 2, ..., NmaxBunch .

Both the triggered event hits and in-time pile-up hits correspond to bunch i = 0. Out-of-time pile-up hits corre-spond to non-zero values of i.

4.3.6 Digital Time-Frame

The hardware is designed to extract out of a pipeline a set of consecutive digital readings for each level-1 triggeraccept. This set of readings, which is provided for every channel, is called a time-frame. The number of readingsin the set is the length of the time-frame. As the digitization clocks run at the same frequency as the LHC bunch-crossings (40 MHz), each time sample in the time-frame corresponds to a 25 ns interval of time. In a voltage-sampling ADC, this means that the value of the preamp output is digitized every 25 ns.

A particular optimization, which can be achieved by adjusting clock phases, is to have one of the 25 ns digiti-zations correspond to the peak amplitude of the preamp pulse. Therefore, from equation (4.1),

k · 25 ns + φclock = tpeakTime , for k =binOfMaximum (4.6)

4.4. HCAL REALISTIC DIGITIZATION 43

where φclock is the clock phase and binOfMaximum is the number of the digital reading within the time-framewhich is expected to be the peak amplitude of a pulse from an in-time particle hitting the calorimeter.

A particular advantage of sampling-ADC data is to make use the digital readings which occur before the preamppulse, as an estimate of the pedestal. This eliminates channel-to-channel correlated noise as neighboring channelwill have their pedestals computed and subtracted independently for every trigger. With an ECAL preamp pulsewhich peaks in 47 ns, a time-frame of 10 time samples and a binOfMaximum of 6, the time-frame values for a1 GeV pulse are shown in Table 4.7. As reading 5 is on the rising edge of the preamp pulse, readings 1 to 4are pedestal. Time samples 5 to 10 are all signal readings. As the time-sample times are adjusted according toequation (4.6), there is a phase difference between the bunch-crossing times and the time-sample times.

The length of the digital time-frame and the number of pedestal and signal readings needed for optimal perfor-mance depends on the calorimeter. These parameters are adjustable in the ORCA4 digitization.

4.3.7 Noise Injection

Currently, Gaussian uncorrelated noise is injected into each individual time sample of the time-frame. The valuesof the noise injected into the ECAL barrel and endcap are given in Table 4.2.

Sub-Detector Noise (GeV) Threshold (GeV)ECAL Barrel 0.03 0.06

ECAL Endcap 0.15 0.30

Table 4.2: Noise and Zero Suppression Thresholds in ORCA4.

4.3.8 Bit Coding

The integer representation of the digital time-frame depends on the full energy scale (which depends on the gainrange for floating-point preamps) and the number of bits in the ADC. The least significant bit on the highest gainrange of the ECAL electronics is expected to be 10 MeV. This corresponds to a full energy scale on the lowest gainrange of 2 TeV.

4.4 Hcal Realistic Digitization

Readout parameters specific to the HCAL are described here.

4.4.1 Pulse Shape

The parameterization of the HCAL pulse shape was provided by Dan Green. The pulse shape for the HCAL isa convolution of three contributions. The scintillator tile plus wave-length shifter contribute to an effective timeconstant for an exponential describing the light pulse. The time jitter due to optical path length variation is notenabled, nor are the photostatistics effects on the pulse shape. This approximation corresponds to a pulse shapewhich does not vary in time or with amplitude. The second contribution is the HPD which ramps from a current Ito 2I in a time tHPD. The third contribution is the Binkley preamp pulse response. This is expressed as follows,with the parameters found in Table 4.3.

ntd(t) = exp(−t/τs) (4.7)


nth(t) = 1.0 + (t/τhpd) (4.8)

ntp(t) = t · exp(−(t/τpre)2) (4.9)

f(t) =C0

∫ t

0ntd(td)

∫ t

0nth(th − td)ntp(t− th)dthdtd

∫

∞

0 ntd(td)dtd∫

∞

0 nth(th)dth∫

∞

0 ntp(tp)dtp(4.10)


τs 11.0 nsτhpd 10.0 nsτpre 25.0 nsC0 37.14

Table 4.3: HCAL Pulse Parameterization in ORCA4.

The HCAL QIE response has not been included in this convolution. The front-end modeling is, therefore,incomplete.


Currently, Gaussian uncorrelated noise is injected into each individual time sample of the time-frame. The valuesof the noise injected into the HCAL are given in Table 4.4. The HCAL only measures a fraction of the particleenergy, and, therefore, the noise is given in measured energy (before the sampling-fraction rescaling).

Sub-Detector Noise (GeV) Threshold (GeV)HCAL (and VFCAL) 0.0006 0.3

Table 4.4: Noise and Zero Suppression Thresholds in ORCA4. The noise is given in measured energy units whilethe threshold is applied after sampling-fraction corrections.

4.5 Preshower Realistic Digitization

Readout parameters specific to the preshower detector are described here.

4.5.1 Pulse Shape

For the preshower, the clock phase is adjusted such that the pulse is sampled at -5 ns, 20 ns and 45 ns for a peakingtime of 25 ns. The pulse shape is given by

f(t) =Qcf · x2

f

2 ·N · exp−ωc·t (4.11)

wherexf = A · ωc · t (4.12)

where t is the time in nanoseconds. The pulse height normalization is chosen such that f(tpeakTime) = 1.0 GeV,see Table 4.5.

4.6. ECAL REALISTIC CALORIMETER HIT RECONSTRUCTION 45


A 6.0Qcf 4.0/350.0ωc 2.0/25.0N 0.11136

Table 4.5: ECAL Preshower Pulse Parameterization in ORCA4.


Currently, Gaussian uncorrelated noise is injected into each individual time sample of the time-frame. The value ofthe noise injected into the ECAL preshower is given in Table 4.6. The ECAL preshower only measures a fraction ofthe particle energy, and, therefore, the noise is given in measured energy (before the sampling-fraction rescaling).

Sub-Detector Noise (GeV) Threshold (GeV)ECAL Preshower 0.000015 0.000054

Table 4.6: Noise and Zero Suppression Thresholds in ORCA4. The noise abd threshold are given in measuredenergy units (before sampling-fraction correction).

4.6 Ecal Realistic Calorimeter Hit Reconstruction

4.6.1 Introduction to Realistic Hit Reconstruction

The software implemented for the realistic calorimeter hit reconstruction in ORCA4 is based on the sampling ADCsignal analysis of the ECAL as found in Appendix B of CMS NOTE 1999/024.

4.6.2 Energy Calculation

The energy calculation is described in Appendix B of CMS NOTE 1999/024 and can be found in P. Bevington,“Data Reduction and Error Analysis for the Physical Sciences,” McGraw-Hill:New York, 1992. The inverse ofthe noise correlation matrix is used as a weight matrix for an analytic χ2 minimization for the pulse amplitude.

As mentioned in the previous section, the noise is approximated to be Gaussian and uncorrelated. Therefore,the weight matrix, W, is proportional to the unit matrix. The vectors

~y =

y1......yM

, ~f(φ) =

f1(φ)......

fM (φ)

, ~p =

1......1

(4.13)

are respectively the Measured Time Samples, the Unit Pulse Shape and the Unit Pedestal. The parameter φ isthe 40 MHz clock phase.

The pulse height is computed with the vector dot product of a vector of weights and the measured time samples,as shown

Energy =1

∆

(

~pTW~p

[

~f(φ)TW

]

− ~f(φ)TW~p

[

~pTW

]

)

· ~y (4.14)


where

∆ = ~f(φ)TW ~f(φ)

[

~pTW~p

]

− ~pTW ~f(φ)

[

~f(φ)TW~p

]

(4.15)

and φ is chosen so that peak amplitude is in the binOfMaximum (defined above).

In the case where the pulse comes from an out-of-time particle, the energy which is computed from the mea-sured time samples is suppressed. The amount of suppression is a function of how sharply the preamp pulse shapeis peaked. In the ECAL, this suppression is exponential with a time constant of roughly 25 ns. The justification forusing an analytic χ2 minimization to compute the energy for the ORCA4 release comes from these sources:a) The results of this calculation gave the optimal energy resolution with good linearity for the ECAL test beamdata;b) The weights are not tied to a particular pulse shape, making the calculation reusable for preamp pulse shapesfor the HCAL and preshower; andc) As will be described in the next section, a probability can be computed which identifies whether the measuredtime samples are compatible with the signal shape hypothesis.The energy calculation is performed with 3 pedestal samples and 5 signal samples (which is again tied to a perfor-mance choice based on ECAL test beam results). The weights are shown in Table 4.7.

Time Unit Energy PedestalSample Pulse Shape Weight Weight

1 0.0000 0.0000 0.00002 0.0000 -0.3613 0.28263 0.0000 -0.3613 0.28264 0.0000 -0.3613 0.28265 0.7628 0.2707 0.00696 1.0000 0.4672 -0.07887 0.8547 0.3468 -0.02628 0.5705 0.1114 0.07649 0.3006 -0.1122 0.1739

10 0.1069 0.0000 0.0000

Table 4.7: ECAL Unit Pulse Shape, Energy and Pedestal Weights in ORCA4.

4.6.3 Pedestal and χ2 Calculations

In addition to the energy calculation, the pedestal and χ2 are also computed from the measured time samples. Thepedestal is given by

Ped =1

∆

(

~f(φ)TW ~f(φ)

[

~pTW

]

− ~pTW ~f(φ)

[

~f(φ)TW

])

· ~y (4.16)

where ∆ is given in equation (4.15). The goodness-of-fit is given by

χ2 =(

~y − Ped · ~p−Energy · ~f(φ))T

W

(

~y − Ped · ~p−Energy · ~f(φ))

. (4.17)

The distribution of the χ2 probability for M − 2 degrees of freedom is a flat distribution from 0 to 1, when theweight matrix W is an accurate representation of the voltage correlations between time samples. This probabilityand, in some cases, the pedestal can be used to reject energies computed from out-of-time particles.

4.7. HCAL REALISTIC HIT RECONSTRUCTION 47

4.6.4 Peak Finder

The coarse evaluation of bunch-crossing identification is done with a peak finder. The energy calculation is appliedto the digital time-frame with the weights shifted by -1, 0 and +1. If the maximum energy is found in with the -1shift, the digit time is set to -25 ns. Similarly, if the maximum is in-time, the digit time is 0 ns, while shift +1 isassigned 25 ns. The χ2 goodness-of-fit is a more sensitive variable for detecting pile-up, while the peak finder ismore representative of a hardware calculation within the level-1 trigger primitive generation.

4.7 Hcal Realistic Hit Reconstruction

The weights specific to the HCAL hit reconstruction are described here.

4.7.1 Energy and Pedestal Calculations

The energy and pedestal calculations are performed with 3 pedestal samples and 5 signal samples. The weightsare shown in Table 4.8.


1 0.0000 0.0000 0.00002 0.0000 -0.2077 0.16253 0.0000 -0.2077 0.16254 0.0000 -0.2077 0.16255 0.0602 -0.1384 0.15006 1.0000 0.9423 -0.04527 0.3545 0.2006 0.08888 0.0289 -0.1744 0.15659 0.0005 -0.2070 0.1624

10 0.0000 0.0000 0.0000

Table 4.8: HCAL Unit Pulse Shape, Energy and Pedestal Weights in ORCA4.

4.8 Preshower Realistic Hit Reconstruction

The weights specific to the preshower hit reconstruction are described here.

4.8.1 Energy and Pedestal Calculations

For the ECAL preshower, only 1 pestestal and 2 signal samples are used for the energy and pedestal calculations.The weights are shown in Table 4.9.



1 0.0000 0.0000 0.00002 0.0000 0.0000 0.00003 0.0000 -1.1252 0.93684 0.9548 0.8780 -0.13755 0.6542 0.2472 0.20076 0.2142 0.0000 0.0000

Table 4.9: Preshower Unit Pulse Shape, Energy and Pedestal Weights in ORCA4.

4.9 Detailed digitization of ECAL hits

4.9.1 Why a detailed digitization?

The package Calorimetry/EcalDetailed in ORCA is designed to give a detailed description of all processes from aGEANT simulated hit in any ECAL cell to the corresponding reconstructed energy in this cell.

The steps are the following :

• Readout of the GEANT hits or SimHits from a database for each cell (both trigger and pileup events)

• Translation of these hits (using their energy and time) into a superposition of signal shapes.

• Reproduction of the electronic chain (amplifiers and sample/hold circuits), for each signal.

• Determination of the energy, time and matrix error from the sampled and digitized signal.

Now, If you want to:

• study the bahaviour of the front-end electronic (multi slope amplifier)

• inject complexe electronic noise (based on autocorrelation function)

• test different scenario of coding of the rawdata

• reconstruct the hits in this context

then, EcalDetailed is for you !

3 notes [1], [2], [3] are available for the interested reader.

4.9.2 Readout of the simulated hits

A simulated hit (coming from GEANT or objectivity database) is characterized by the energy deposit and the timeof arrival of a particle in a crystal. Each crystal can be hit by one or more particles belonging either to the triggerevent or to any pileup event.

Since the CMS data will arrive in a continuous flow and be analysed with a 40MHz clock, one tries to reproducethis time-behaviour by encoding the informations every 25 ns in a range of N sampling times (default = 10)

4.9. DETAILED DIGITIZATION OF ECAL HITS 49

The bunch of the trigger is here supposed to be known and will be taken as the Mth bin among the N bins, withdefault M = 5.

One applies the same treatment to any hit in each crystal (cell), namely :

• The shape of the crystal response is taken from the readout properties of this cell , cf fig.4.2.a,(CellID.Readout()->Shape()). It is normalized to one, starting from t = 0, with a typical peaktime (CellID.Readout()->PeakTime()) of about 66 ns.

• The actual time is the time of the hit, incremented by the bunchtime (zero for a trigger hit) and decrementedby the average time-of-flight in the cell.

• The shape is time-shifted so that, for a ”zero jitter” hit (i.e. when the time of the hit is equal to the averagetime-of-flight), its maximum coincides with the center of the Mth bin.

• The shape is time-shifted again by the actual time of the hit.

• The value of the shape is then computed at N different times spaced by 25 ns multiplied by the energy of thehit, and stored into a N-dimensional object of the classCalorimetry/CaloCommon/CaloTimeSample.

There is one CaloTimeSample per crystal, so that, if several hits occur in the same crystal, the N values will beincremented for each hit occurence.

As an example, the fig.4.2 displays the signal in a cell hit by a trigger particle as well as by particles in twodifferent bunches (pileup) before (b) and after (c) summation.

shap

e

0 4 8 12 16t (25ns units)

(a) (c)(b)

1

EE

t (25ns) t (25ns)

Figure 4.2: Signal frames.

4.9.3 Front-End simulation

The N samples of the signal are first incremented by the electronic noise of the cell in which one takes into accountthe correlation of the noise between successive samples (CellID.Readout()->AutoCorrelation()).

A simulation of the ”floating-point unit” (cf fig.4.3). is then performed : one of the four amplification chains(defaults values for the gains are = 1, 5, 9, 33) is chosen after addition of the corresponding baseline by comparisonwith a threshold (fullScaleEnergy(CellID.Position())) and each sample is then converted into an integer of 12 bitsmantissa + 2 bits (gain), giving a N-dimensional object of the class Calorimetry/CaloCommon/CaloDataFrame.


Con

vers

ion

x8

x1

x4

x1

x4

x1

Sam

ple/

Hol

d ci

rcui

t

Preamp. Ampli.

Gain =

1

4

8

32

Figure 4.3: Schematic view of the ”floating point unit”

4.9.4 Hits reconstruction

From the digital signals generated by the ECAL front-end (CaloDataFrame class), the reconstruction of the digis1

(CaloRecHit class) is performed. The algorithms determine:

• the energy measurement2

• a timing measurement of the signal

• an evaluation of the quality of the two previous measurements by the mean of a χ2 probability and an errormatrix.

These attributes of the CaloRecHits are then available for further reconstruction. For example, the energy mea-surement is used for the clustering (and at a higher level electron reconstruction) whereas the timing measurementallows to recognize which bunch crossing is responsible for the generation of the signals registered by the ECALfront-end.

The default algorithms are based on the studies described in [3]. We give here a brief summary.

Energy measurement

Around the maximum of the signal, each sample contains information relative to the energy of the signal itself.Combining several samples can give an optimal estimate. Therefore, a weighted sum over a set of samples is used.The weights are determined by χ2 minimization (see [3] for the details). The weights depend on the signal shapeand the properties of the electronic noise (autocorrelation function).

Time measurement

The same procedure is followed as for the energy measurement (see [3]).1this term could be confusing. In the Calorimetry package jargon, digis mean reconstructed hits.2more precisely, we should speak about amplitude reconstruction. The conversion of the amplitude to the energy need a calibration. Here,

by simplicity we don’t distinguish the amplitude and the energy

4.10. ECALSELECTIVEREADOUTTOWER 51

Evaluation of errors measurement

According to [3], it is straightforward to compute the covariance matrix of the estimates of the energy and time.Moreover, the minimal χ2 is a given as a by-product of the alogorithm. A χ2 probability is then computed knowingthe number of samples used.

In principle, the χ2 probability should be flat. However, in the calculation above, the non linear effects dueto quantisation (i.e. effects coming from the coding of the CaloDataFrame) have not been taken into account. Inorder to get a flater distribution, we add in the error matrix a term LSB/

√

(12), where the LSB is choosen to bethe one corresponding the maximum gain (the most probable one).

4.9.5 first results

see [3] !

4.9.6 Users guide

Architecture

EcalDetailed is devided in 3 packages:

• EcalDetailedSim: contains what is needed to perform the simulation/creation of CaloDataFrames.

• EcalDetailedRec: reconstructs the CaloRecHits from the CaloDataFrames.

• EcalDetailed: gathers what is common to the 2 previous packages.

Each package contains a test program (.cpp) with the same name as the package and a .orcarc containing therelevant configurable parameters.

Configurable parameters

4.9.7 References

1. D. Chamont et al., “A package for a detailed digitization of ECAL hits in ORCA : Software description” (2000)CMS IN 00-0022. Pascal Paganini and Albert Romana, “A package for a detailed digitization of ECAL hits in ORCA : Physicsdescription and results” (2000) CMS IN 00-0033. P. Paganini, “Reconstruction of the energy and time of ECAL hits” (2000) CMS IN 00-056

4.10 EcalSelectiveReadoutTower

4.10.1 Introduction

In order to comply with the data rate constraints placed upon the ECAL, the size for a LVL1 accepted event mustbe reduced from ≈ 1.5Gb to ≈ 100Mb. Up till now ORCA has implemented control of the dataset size duringsimulation by applying indiscriminate zero suppression equally across the barrel and endcap. However, while ascheme like this is simple to implement it does not provide a linear response over the potential energy range of


parameters default value comments

Ecal:framesize 10 number of samplesEcal:Barrel:noise 0.03 barrel electronic noise (RMS) in GeVEcal:Endcap:noise 0.15 endcap electronic noise (RMS) in GeVEcal:Barrel:baseline 0.3 barrel baseline level in GeVEcal:Endcap:baseline 1.5 endcap baseline level in GeVEcal:photostatistics 4 stochastic term in photoelectron/MeVEcal:constantterm 0.005 constant termEcalDetailed:TriggerReferenceBin Ecal:framesize/2 = 5 the sample corresponding to the

expected maximum of the signalEcalDetailed:FPUGain1 1 gain corresponding to the full dynamic: highest energyEcalDetailed:FPUGain2 5EcalDetailed:FPUGain3 9EcalDetailed:FPUGain4 33 gain corresponding to the lowest rang of energy:

maximum amplificationEcalDetailed:NumberOfBit 12 number of bit used in the ADC

Table 4.10: Digitisation parameters

parameters default value comments

EcalDetailedRec:NumberOfSamples Ecal:framesize (10) nunmber of samples used toreconstruct the hit energy and time

EcalDetailedRec:PositionFirstSample 0 position of the first sample in the frame usedfor the reconstruction (starting from 0)

EcalDetailedRec:minExpectedPosition 0 Some signals could be out of time with respect tothe trigger bunch. The reconstruction is done byassuming a possible shift of the real bunch betweenminExpectedPosition and maxExpectedPosition.0 means same as trigger bunch, -1 one bunch beforeand +1 one bunch after...

EcalDetailedRec:maxExpectedPosition 0Ecal:Barrel:threshold 0.06 only barrel hits above this energy are createdEcal:Endcap:threshold 0.3 only endcap hits above this energy are created

Table 4.11: Hit reconstruction parameters

incident particles. That is to say, the higher the energy of the electro-magnetic shower, the greater the numbercrystals that will be read out, the greater the fraction of the shower energy that will be measured, and visa versa.

4.10.2 The Algorithm

The algorithm implemented from ORCA 6 onwards for the selective readout takes a more global view of the energydeposited in the ECAL than simple zero suppression implemented in ORCA 5 and before. The level of suppressionto apply to an individual crystal is decided by taking into account not only it’s energy (as was the case with straightzero suppression), but also the energy of the trigger tower it belongs to and the energy of certain neighbouringtowers. This process occurs in essentially two phases (although the code combines these for efficiency):

1) Thresholds are defined for upper and lower energy levels and the trigger towers iterated over and markedaccording to their energy as follows:

1. CENTER : energy> upper threshold


2. SINGLE : lower threshold< energy<= upper threshold

3. SUPPRESSED : energy<= lower threshold

In ORCA only trigger towers over 300MeV are stored, so in fact it is only these that are iterated over tofind an events CENTERS and SINGLES. However, the hardware implementation envisions passing 3 bits (viathe ‘ROSE’ boards) containing energy information for each of the 4032 towers in the ECAL for each event to aSelectiveReadout Manager (analogous to the EcalSelectiveReadoutTowerFormatter class described later), whichwill then return the 4032 x 2 bits describing the suppression levels to be applied (Philippe Busson - ECAL SelectiveReadout&Zero Suppression, http://cmsdoc.cern.ch/Physics/egamma/transparencies/m47-3.pdf), as shown in figure4.4.

Selective Readout

Manager

LVL1 Accept 1 bit @ 40MHz

From ROSE boards4032 x 3 bits

@40 MHz

To ROSE boards4032 x 2 bits

@ 40 MHz1 bitSelf Trigger

Ecal

Figure 4.4: Possible hardware implementation of Selective Readout

2) A pattern of towers is defined to be readout around each CENTER tower. This pattern can effectively beany collection of towers containing the CENTER tower, but only two have been implemented so far, as shown infigures 1 and 2 (the implementation of further patterns is described later in this note). With the pattern decided thealgorithm then iterates over the CENTER’s and labels all towers within the pattern of towers defined by each asNEIGHBOURS. If one of the NEIGHBOURS is already marked as a CENTER it will not be renamed, howevera SINGLE will be. As well as the alpha-numeric label each tower is also given a two bit state, where CENTER

Figure 4.5: Towers around CENTER (in black) marked as neighbours for 3x3

= [1][1], SINGLE = [1][0], NEIGHBOUR = [0][1] and SUPPRESSED = [0][0]. This is intended to mimic thepotential hardware implementation of the threshold flags as mentioned above.

For each of these labels a different level of zero suppression can be defined to be applied to the crystals inthat tower. These are shown in table 4.12, where the ’appropriate sub-detector level’ refers to that set by theEcal:Barrel:threshold and Ecal:Endcap:threshold configurables.

4.10.3 The Classes

The classes incorporated into the EcalSelectiveReadoutTower package are shown in table 4.13.


Figure 4.6: Towers around CENTER (in black) marked as neighbours for 5x5

Towerlabel Default Available via configurablesCENTER No suppression Any level of suppressionSINGLE No suppression Any level of suppression

NEIGHBOUR No suppression Any level of suppressionSUPPRESSED Suppressed at appropriate sub-detector Any level of suppression

level (see text)

Table 4.12: Suppression levels for different tower labels

Filename EndingsEcalSelectiveReadoutTower .h .cc ref.h ref.cc .ddl

EcalSelectiveReadoutItr .hEcalSelectiveReadoutTowerMap .h .cc

EcalSRTowerVListBase .h (purevirtual)EcalSRTower3x3NList .h .ccEcalSRTower5x5NList .h .cc

EcalSelectiveReadoutTowerConfigurables .h .ccEcalSelectiveReadoutTowerFormatter .h .cc

EcalSelectiveReadoutTowerPersistentSetUp .h .ccEcalSelectiveReadoutTowerROUFactory .h

InitPackage .cc

Table 4.13: EcalSelectiveReadout source files

Upon running an ORCA application that uses the selective readout, the first thing that happens is the staticinitialisation of the package. This is defined in InitPackage.cc and consists of instantiating (using the packagebuilder), an EcalSelectiveReadoutPersistentSetup object which in turn instantiates an EcalSelectiveReadoutFor-matter object. This formatter will not be destroyed until the end of the program, and is triggered at the start of eachevent to control the administration of the 4032 EcalSelectiveReadoutTowers that make up the Ecal. The instanti-ation of the formatter also causes the initial instantiation of the EcalSelectiveReadoutTowerMap singleton. Thismap contains pointers to all 4032 EcalSelectiveReadoutTower objects in the Ecal and for each tower a pointer toan EcalSRTowerVListBase object. The package at present contains two possible list objects which inherit fromEcalSRTowerVListBase, the EcalSRTower3x3NList and the EcalSRTower5x5NList which govern the pattern oftowers marked as NEIGHBOUR’s around a CENTER (as described in the previous section, figs 1, 2).

Initially the internal states of all towers in the map are set to UNDEFINED, a state which can be achievedby simply calling the resetMap() method of the map object. When the reconstruct method of the formatter iscalled at the start of an event it first resets the map, then iterates over all the available trigger primitives for that


event (ROU - CTETOW01) and marks all CENTER and SINGLE towers. Any CENTER tower found also hasit’s NEIGHBOUR’s marked according to the pattern being used. A copy of the appropriate tower is then addedto the cache inherited from PRecDet, so making it available in the CSETOW01 readout unit. To make a desicionon whether a crystal is to be suppressed the CaloRecHitFormatter iterates over this ROU and by calling the ze-roSuppressionLevel method of the EcalSelectiveReadoutTower object gains access to the appropriate informationfor that crystal.

The class supports the methods in table 4.14 for access the various data members.

Method Returnstower.name() returns ”ECALSR”

tower.getName() returns ”ECALSR”tower.getCache() returns internal cache

tower.reset() reset tower to UNDEFINED statetower.setState() set internal state of tower

tower.setAsNeighbour() set as neighbourtower.zeroSuppressionLevel() level to suppress crystals at

tower.myCell() CellID of towertower.state() current state of tower (e.g CENTER)

tower.theSelectiveReadoutBits() two boolian bits representing statetower.nSelectiveReadoutBits() number of bits(2)

Table 4.14: EcalSelectiveReadoutTower public methods

4.10.4 Simple Configurables

In order to make this package as versatile as possible several new configurables have been introduced, these areshown in table 4.15, and are all defined in the EcalSelectiveReadoutTowerConfigurables class. These are mostlyself explanatory and are to be used in conjunction with the existing zero suppression variables. The behaviourof the two ‘usethreshold’ configurables is perhaps the least obvious. These allow the user to turn off the defaultbehaviour of reading out all crystals inside CENTER, SINGLE or NEIGHBOUR towers, and to set a level ofsuppression using the corresponding Barrel:threshold and Endcap:threshold variables.

4.10.5 Extending the Patterns base

To include new patterns in the selective readout, simply inherit from EcalSRTowerVNListBase following the ex-amples of those already implemented, and then add your new class to the switch structure found in EcalSelec-tiveReadoutTowerMap.cc.

4.10.6 Using the Iterator

If you wish to investigate different schemes but do not wish to re-digitise every time, the package supplies aniterator class which will re-trigger the reconstruct method in the formatter when instantiated. This works by fillinga proxy for the PRecDet cache instead of the actual cache. The iterator then moves over this collection, instead ofthe persistent one. The iterator constructor follows the example of CaloItr and takes the string ”CSETOW01” asan argument. e.g EcalSelectiveReadoutItr myItr(”CSETOW01”).


Configurable Default EffectCaloRecHit:ZeroSuppressionOnEt False Zero suppress using Et

CaloRecHit:SuppressionStyle 0 selective readout(0), zero suppression(1), nothing(2)Ecal:SelectiveReadoutGridSize 1 Readout 3x3(0) or 5x5(1) tower blocks

Ecal:SelectiveReadoutThreshold:low 2.5 Set lower SR thresholdEcal:SelectiveReadoutThreshold:high 5.0 Set upper SR threshold

Ecal:SelectiveReadoutSingles False Turn singles on / offEcal:SelectiveReadoutSingles:usethreshold False Use a ZS threshold(Singles)

Ecal:SelectiveReadoutSingles:Barrel:threshold 0.0 Set barrel thresholdEcal:SelectiveReadoutSingles:Endcap:threshold 0.0 Set endcap threshold

Ecal:SelectiveReadoutTowers:usethreshold False Use a ZS threshold(Towers)Ecal:SelectiveReadoutTowers:Barrel:threshold 0.0 Set barrel threshold

Ecal:SelectiveReadoutTowers:Endcap:threshold 0.0 Set endcap threshold

Table 4.15: Simple Configurables for EcalSelectiveReadoutTower package

Chapter 5

Tracker

5.1 Introduction

5.2 Overview of the object model

5.3 Geometrical layout

5.4 Detector response simulation

5.5 CommonStripDet: Does something ...

5.5.1 .orcarc Steering Parameters

Table 5.1: .orcarc parameters used in CommonStripDet.Name Possible Default Meaning

Values ValueStripDigi:zeroSuppressedAdcBits int 1–12 12 Number of ADC bits for raw data

5.6 Pixel detector

All pixel related digitization and clusterization software is in the Tracker/SiPixelDet sub-package.

5.6.1 Digitization

The signal digitization is done in the module SiPixelDigitizer.

The signal is generated in following steps:

57

58 CHAPTER 5. TRACKER

• The entrance point and the exit point together with the energy deposited in the sensor by the incident particleare obtained from the simulated hits.

• The track segment inside the sensor volume is divided into sub-segments (default is 20). Each sub-segmentis assigned a fraction of the energy according to the distribution given by the GEANT3 routine GLANDZ.This distribution takes into account Landau fluctuations in thin material layers.

• The charge from each track sub-segment is drifted to the detector surface and simultaneously diffused inthe perpendicular plane. The diffusion is assumed to be Gaussian and is proportional to the square-root ofthe drift length. The diffusion constant can be modified through an adjustable parameter. The final chargedistribution on the detector surface is calculated as a sum of folded two-dimensional Gaussian distributions.The effect of Lorentz drift in magnetic is included. The magnitude of the Lorentz drift is defined by the driftlength and the Lorentz angle.

• The resulting two dimensional charge distribution is mapped to the pixel geometry and the fraction of chargecollected by each pixel is determined. The cut-off value for integration is an adjustable parameter.

• The noise is assumed to have a Gaussian distribution centered at zero. All hit pixels have the noise contri-bution added to them. In addition noisy pixels, with charge amplitude larger than the pixel threshold, aregenerated according to the tail of the Gaussian distribution. The width of the noise Gaussian is entered asone of the digitization parameters.

• The pixel inefficiency can be included. There are 3 types of inefficiencies: at the pixel level, column leveland readout-chip level. Each is controled independently. There are 2 sets of default oarameters, on for lowand the other for high luminosity.

• The pixel charge is multiplied by a gain factor. It is then converted into an integer number simulating ADCdigitization. Signals which exceed the ADC range are assigned saturation value which depends on the ADCmaximum bit number. Both the gain and the number of ADC bits can be adjusted.

• The digitized signal is compared with the pixel threshold (called the ‘readout pixel threshold), signals whichfall below it are eliminated. The pixel threshold is defined in units of noise width and is adjustable. Thetypical threshold value is equal to 5σ of the noise distribution. This is the lowest value which keeps thenumber of noisy pixels within a resonable limit (on average two noisy pixels per single detector module).

Most of the relevant parameters are defined in the SiPixelDigitizer.cc file. The exception are the Lorenz anglewhich is defined SiPixelDet.cc and the readout pixel threshold defined in SiPixelDetType.cc.

5.6.2 Cluster reconstruction

The pixel cluster reconstruction procedure groups hit pixels into clusters and than, for each cluster, estimates thecluster position in two dimensions.

This is done in the module SimplePixelClusterizer in the following steps:

• The list of hit pixels (within one detector module) is searched for separate clusters. Only pixels having thesignal larger than a pre-defined pixel threshold are considered (this threshold can be different from the pixelreadout threshold mentioned in the digitization step). The search is initiated by pixel cells with the signallarger than the seed threshold. The algorithm used treats any touching pixels as members of the same cluster.Even pixels connected just with their corners belong to one cluster. Both, the pixel threshold and the seedthreshold are defined in units of noise.

5.6. PIXEL DETECTOR 59

• For each cluster it’s width in two dimensions and its total charge are estimated. The cluster charge is com-pared with the requested cluster threshold, if it falls below, it is treated as noise and is deleted from thecluster list. This is a very effective noise discriminator. Noisy pixels, which have charge above the pixelthreshold, tend to form isolated single pixel clusters and very seldom exceed the cluster threshold which istypically set to be slightly more than 2 times the pixel threshold. Clusters from real tracks, however, havecharge at least equal to the MIP signal. The cluster threshold is again defined in units of adc counts.

• Clusters that pass all required cuts have their mean position evaluated. The position is estimated indepen-dently in both dimensions and a range of different algorithms are available. Standard methods like simple,linear analog average or the digital average can be used, the best results, however, are obtained with morespecialized algorithms. In the case of the barrel pixels the best r-φ resolution is obtained with the nonlinearanalog method. In the z direction, for one or two pixel wide clusters, the nonlinear analog method is usedas well. For long, larger than two, clusters the ”edge” method is used where the main position informationcomes from the charge ratio of the two edge pixels. In the case of end-caps the clusters tend to be short inboth dimensions and therefore the analog method is always used. Both, the nonlinear analog and the ”edge”methods use some information about the impact angle between the track and the detector. Initially this angleis not known and therefore all tracks are assumed to come from the detector center. Later, once the track isfitted or when the primary vertex is known one can reevaluate the reconstructed hit position using a betterimpact angle knowledge.

• Finally the errors of the cluster position are estimated. Average errors cannot be used since they do not takeany topological information into account. Instead the errors have been parametrized using the cluster shape,detector thickness and pixel size and charge spreading information.

Most of the relevant parameters are defined in the SimplePixelClusterizer.cc file. An exception is the pixel noise(in adc units) defined SiPixelDet.cc. This is just the initial value since it is overwritten in the SiPixelDigitizer.ccby the value recalculated from the noise in electrons.

5.6.3 Parameters

Digitizer parameters

Some parameters can be modified by the configurable class in the .orcarc file. These are :

// Lorentz angle, default is 28deg at 4T.PixelDigitizer:TanLorentzAnglePerTesla = 0.133// Readout threshold in noise units, default = 5.PixelDigitizer:ThresholdInNoiseUnits = 5.// Gain calibration, electrons per adc count, default = 135.PixelDigitizer:ElectronPerAdc = 135.// Pixel noise in electrons, default = 500e.PixelDigitizer:NoiseInElectrons = 500.// ADC max number counts, the signal will saturate at this value, 8bits=256.PixelDigitizer:AdcFullScale = 255// TOF cut in nanoseconds, default 1 LHC clock, so +-12.5ns.PixelDigitizer:TofCut = 12.5// Flag which controls adding noise to existing pixels, default=1=true.PixelDigitizer:AddNoise = 1// Flag which controls adding noisy pixels in addion to the hit pixels, def=1.PixelDigitizer:AddNoisyPixels = 1// Flag which controls if charge fluctuation along the track segment is done.


PixelDigitizer:FluctuateCharge = 1 // Default = true// Flag which controls the pixel inefficiency.// 0-non (def), 1-lowlumi data losses, 10-highlumi losses.PixelDigitizer:AddPixelInefficiency = 0// The inefficencies can be also forced to certain values.//PixelDigitizer:PixelEfficiency = 1. // pixel efficiency//PixelDigitizer:PixelColEfficiency = 1. // column efficieny//PixelDigitizer:PixelChipEfficiency = 1. // chip efficiency.

The so-called readout noise (in units of adc counts) is defined in the SiPixelDet class.

readout().setNoiseInAdcCounts(counts); // Noise in units of adc counts.

The value of “counts” is calculated using the value of noise in electrons and the gain calibration (adc countsper electron) defined through the configurable parameters : ElectronPerAdc and NoiseInElectrons. This noisedefinition is used to calculate the readout threshold and the three clusterization thresholds.

Some parameters are hardwired in the code :

• In SiPixelDigitizer.cc

NumberOfSegments = 20; // Number of track segment divisions.ClusterWidth = 3.; // Charge integration spread, sigma units.GeVperElectron = 3.7E-09; // 1 electron = 3.7eV.Sigma0 = 0.0007; // Charge diffusion constant.Dist300 = 0.0300; // Normalized to 300micron Silicon.

Clusterizer parameters

All needed parameters is configurable through the .orcarc file.

// All thresholds are in units of noise.// The individual pixel threshold, pixel below it are ignored.PixelClusterizer:PixelThreshold = 5.0// Seed threshold, only pixels above this threshold are considered as// cluster seeds.PixelClusterizer:SeedThreshold = 6.0// Cluster threshold, clusters below are ignored.PixelClusterizer:ClusterThreshold = 10.1

These values are converted to adc units by using the noise parameter in units od adc counts defined in SiPix-elDet.cc (readout.noiseInAdcCounts()).

5.7 SiStripDet: Silicon Strip Detectors: digitisation and cluster recon-struction

This section describes the implementation of the simulation and reconstruction algorithms for the Silicon Stripdetectors. All the relevant files can be found in the SiStripDet package.

The main functionalities it provides are:

5.7. SISTRIPDET: SILICON STRIP DETECTORS: DIGITISATION AND CLUSTER RECONSTRUCTION61

• description of the detector modules (position, dimension, readout pitch,...);

• digitization;

• zero suppression;

• cluster reconstruction;

The simulation of particle interaction with the detectors is handled elsewhere (CMSIM or OSCAR).

The basic principles of Silicon Strip detectors and a full description of the simulation of signal and noise canbe found in the Tracker TDR: in the following only the differences with respect to it are addressed in full details.

5.7.1 The SiStripDet

Each detector module is an instance of the SiStripDet class. The constructor requires a BoundPlane, which de-fines the global position and orientation, and a SiStripDetType, which handles detector specific informations andconstructs the SiStripDetDigitizer and the SiStripDetClusterizer.

A SiStripDet is a DetUnit, and more specifically a StripDet, so it provides all the functionalities of the latter.The only virtual method which needs to be implemented here is driftDirection(), which returns the driftdirection of the ionization charges collected on the strips (the holes, for p tipe silicon) inside the detector volume.The drift direction is:

u =~E + µH

~E × ~B

| ~E + µH~E × ~B|

,

where µH is the Hall mobility. In the Tracker design, the silicon detectors are tilted to compensate for the effectof the Lorentz angle θL = arctanµHB in the charge drift. Unfortunately in the geometry files up to the versioncms118 (at least) this tilt angle has the wrong sign1. By default the Lorentz angle in the digitization is reversedso that the final result is as if the detectors would have the right tilt angle. This correction is NOT applied if the tiltangle in the geometry file is correct or the environment variable SI TILT CORRECTION is set to 0.

To speed up the digitazion, the drift direction u is calculated at construction time and stored in a private datamember, which will be returned by any following call to driftDirection(). The drawback is that any changeto the MagneticFieldMap after a SiStripDet has been instanciated won’t be reflected in a change of the Lorentzdrift in that detector.

In addition to a StripDetType, a SiStripDetType has, has private member, SiStripParameters, which is returnedby params(). A SiStripParameters object stores the parameters needed for the digitization and clusterization.All these parameters are presently read from CMSIM title files. This is an unpleasant situation because it is difficultto change them in ORCA in a coherent way. In addition most of these parameters are meaningless to non-experts,not allowing to tune the simulation to different analysis needs. A solution to these problems is presently understudy.

5.7.2 Simulation of signal and noise

The SiStripDetDigitizer is responsible for the simulation of signal and noise in the detector.

For each incident particle, the entry and exit points, as well as the energy deposited in the silicon (Eion), areretrieved from the corresponding SimHit. Inside the silicon wafer, the track path is subdivided intoNseg segments,such that the length of each segment, projected onto the strips plane, is less than 1/10 of the pitch in the directionorthogonal to the strips. A fraction of the deposited energy Eseg = Eion/Nseg is assigned to each segment. By

1Anti-compensation results in a better single hit resolution, but increases the occupancy and may affect the hit reconstruction efficiency.


default, independent Landau fluctuations are then applied to the energy in each segment. Optionally, a simplerapproach in which no Landau fluctuations are applied to Eseg and only the total energy Eion fluctuates can beused.

For each segment a cluster of hole-electron pairs is created using a calibration factor of 2.78 · 102 pairs/keV.Each holes cluster is drifted to the strip plane, accordingly to the driftDirection(), which takes into accountthe Lorentz angle. The drift time and the diffusion are calculated and the fraction of charge Qi collected by eachstrip within 3σ of the diffusion cloud is determined. To take into account the inter-strip capacitive coupling thecharge is evaluated by the formula:

Q′

i =

7∑

j=0

Cj · (Qi−j +Qi+j)

where Q′

i is the charge collected on the read-out strips and Ci are the capacitive coupling coefficients. The lattercan be changed from their default values via .orcarc parameters.

On each strip where Q′

i 6= 0, a noise is generated according to a Gaussian with r.m.s. equal to the EquivalentNoise Charge (ENC) of the read-out electronics. Correlation between the noise of each fired strip and the noiseof closest strips is very small and has not been taken into account. In order to reduce computational time, in allremaining strips where Q

′

i = 0 the noise is generated using a GaussianTailNoiseGenerator: the probability q forthe noise on a strip to be above the readout threshold is calculated; the noise is then generated according to the tailof the Gaussian above the threshold, only in a subset of the strips randomly choosen with binomial probability q.

The final signal in silicon detectors is processed by a deconvolution chip (APV), with a response function whichdepends on the time the signal is collected. The shaping time of this amplifier is therefore the main responsible ofsignal pile-up due to off-time bunch crossings.

An image of the output pulse of the APV can be built using the chip internal test pulse system by sampling thepulse at a fixed time and progressively shifting the timing of the test pulse. The normalised output obtained whileworking in deconvolution mode is shown in Fig. 5.1; a Gaussian fit is also superimposed to the plot. The origin of

P1 1.000P2 0.1902E-01P3 12.77

Time (ns)

Nor

mal

ized

out

put

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

1.2

-40 -20 0 20 40 60 80

Figure 5.1: Normalised output shape of the APV in deconvolution mode obtained by internal calibration scan.

the time scale is arbitrary; in the figure it has been chosen so that the maximum signal is reached in correspondence

5.7. SISTRIPDET: SILICON STRIP DETECTORS: DIGITISATION AND CLUSTER RECONSTRUCTION63

of 0 ns, that is referred to as trigger time. The effect of the deconvolution algorithm on the signal can be taken intoaccount by weighting the hit charge with the output pulse shown in figure 5.1 according to the hit impact time. Thetrigger time origin has been adjusted for each layer and ring according to the time of flight of a mip coming fromthe collision point. The procedure has been tested using simulated pT = 30GeV single muon events, for whichthe cluster charge and the cluster finding efficiency are shown respectively in Fig. 5.2a and 5.2b as a function of theimpact time. A disagreement between the expected output charge shown in Fig. 5.1 and the reconstructed cluster

18.73 / 6P1 175.3P2 -0.3055E-01P3 13.15

Impact Time (ns)

Cha

rge

(AD

C c

ount

s)

60

80

100

120

140

160

180

200

-30 -20 -10 0 10 20 30

Impact Time (ns)

Clu

ster

fin

ding

Eff

icie

ncy

(%)

0

20

40

60

80

100

-40 -30 -20 -10 0 10 20 30 40

(a) (b)

Figure 5.2: a) Cluster charge and b) cluster finding efficiency as a function of the impact time while working indeconvolution mode. Simulated events containing pT = 30 GeV muons.

charge in Fig. 5.2 can be noticed when a normalisation to the peak charge be taken into account. The tails of theGaussian distribution are biased to higher values in the second plot due to clustering thresholds.

The signal on each strip is finally converted from the number of electrons to the number of ADC counts and, ifabove threshold and selected by the zero suppression algorithm, it is saved in the Readout.

5.7.3 Zero Suppression

In the real tracker, the FEDs will apply a zero suppression algorithm to the digitizings, to reduce the data volume.This has been implemented in ORCA, as it not only allows one to simulate possible FED algorithms, but alsosubstantially reduces the size of the datasets produced by ORCA.

By default, a very simple zero suppression algorithm has been implemented in SiStripDigitizer. This rejects allstrips on which the pulse height is less than 2σ, and then applies a tighter cut of 5σ to isolated strips. These cutsare 100% efficient for strips which would be selected by the default offline clusterizer.

Optionally, a more realistic (and slower) zero suppression algorithm can be used. This is implemented inFEDSiStripDigitizer. Unlike SiStripDigitizer, this class not only simulates a Gaussian noise on each strip, but alsosimulates common-mode noise and adds a pedestal. It then attempts to reconstruct and subtract the common-modeand pedestal. This is done using an iterative procedure:


1. In each event, estimate the pedestal plus common-mode offset in each APV, by taking the median (or option-ally, the mean) pulse height of all the strips in that APV. (An APV represents a group of 128 neighbouringstrips in a detector module.)

2. Subtract the pedestal plus common-mode

3. Flag strips with a pulse height exceeding, e.g. 3σ, on the grounds that they may contain a signal, which isbiasing the common-mode estimate.

4. Repeat step (i).

The number of iterations can be specified by the user. After subtraction of the pedestal plus common-mode,FEDSiStripDigitizer selects interesting strips using one of the following three algorithms. Here pi and σi are thepulse height and noise, respectively, on strip i, and Tl and Th represent programmable low and high thresholds:

• Algorithm 1: Accept strip i if pi/σi > Tl.

• Algorithm 2: Accept strip i if pi/σi > Th or (pi/σi > Tl and max(pi−1/σi−1, pi+1/σi+1 > Tl).

• Algorithm 3: Accept strip i if pi/σi > Th or (pi/σi > Tl and max(pi−1/σi−1, pi+1/σi+1 > Th).

The .orcarc parameters controlling the behaviour of FEDSiStripDigitizer are defined in Table 5.2.

5.7.4 Cluster reconstruction

The clusterization is performed by the SiStripClusterizerEdge which is little else than a ThreeThresholdStripClus-terizer. The channel, seed and cluster thresholds, in ADC counts, are calculated such that they corresponds to 2,3and 5 noise sigma’s. They can be changed using respectively:

setChannelThresholdInNoiseSigma(float x)setSeedThresholdInNoiseSigma(float x)setClusterThresholdInNoiseSigma(float x)

Whereas ThreeThresholdStripClusterizer determines cluster positions from their centroids, SiStripClusteriz-erEdge only does this for narrow clusters (1–4 strips wide). For wider clusters, it estimates the cluster positionjust using those strips at the cluster edge, so reducing its sensitivity to Landau fluctuations. It also includes aparametrization of the estimated resolution as a function of the number of strips crossed by the track. Optionally,one can used the centroid algorithm for all clusters, as indicated in Table 5.2.

5.7.5 .orcarc Steering Parameters

5.8 Interface to Geant3/cmsim data

5.8. INTERFACE TO GEANT3/CMSIM DATA 65

Table 5.2: .orcarc parameters used in SiStripDet.Name Possible Default Meaning

Values ValueSiStripDigitizer:APVpeakmode 0, 1 0 Use APV peak mode instead of decon-

volution mode. (Affects time resolu-tion).

SiStripDigitizer:LandauFluctuations 0, 1 1 Use full simulation of Landau fluctua-tions.

SiStripDigitizer:SignalCoupling vector〈float〉 0.89 0.055 Fraction of charge deposited on centraland neighbouring strips. (First valueplus twice sum of others must equal 1.)

SiStripClusterizer:AcceptAll 0, 1 0 Set thresholds of offline cluster finderto zero, so that it accepts all strips out-put by the zero suupression algorithm.This is useful for studying the latter.

SiStripClusterizer:EdgeAlgo 0, 1 1 Determine cluster positions using theedge algorith instead of the centroidone.

FEDSiStripDigitizer:Enable 0, 1 0 Use FED zero suppression instead ofthe simple alternative.

FEDSiStripDigitizer:UseRecPedCM 0, 1 1 If zero, FED will cheat by tak-ing common-mode value from MonteCarlo truth instead of trying to recon-struct it.

FEDSiStripDigitizer:cmFromMedian 0, 1 1 Estimate common-mode offset frommedian instead of mean pulse height

FEDSiStripDigitizer:NumIter int 1 Number of iterations to get common-mode.

FEDSiStripDigitizer:Pedestal float 100. Generated pedestal in ADC counts.FEDSiStripDigitizer:rmsCM float 5. rms of generated common-mode noise

in ADC counts.FEDSiStripDigitizer:cmSigRejThresh float 2. Strip threshold for flagging signal

strips during common-mode estimate,in units of rms noise.

FEDSiStripDigitizer:algorithm 1, 2, 3 2 Choose FED clustering algorithm.FEDSiStripDigitizer:lowThresh float 2. Low threshold of FED clustering algo-

rithm, in units of rms noise.FEDSiStripDigitizer:highThresh float 5. High threshold of FED clustering algo-

rithm, in units of rms noise.

Chapter 6

CommonReco

6.1 Track Reconstruction

6.1.1 Abstract interfaces for Simulated and Reconstructed Objects

Abstract classes with pure virtual methods are provided for tracks and vertices. They are inherited both fromreconstructed and simulated tracks and vertices and provide some common methods.

Track

Track (CommonDet/PatternPrimitives/interface/Track.h) is a base class for tracks both from Tracker and muontracking system. It is a pure abstract class and it can’t be instantiated but it can be inherited. Among its method thefollowing are available:

• virtual ˜Track() pure virtual destructor

• virtual TrajectoryStateOnSurface stateAtPoint( const GlobalPoint&) state ofthe trajectory with the minimum distance from a given point

• virtual TrajectoryStateOnSurface stateAtLine( const Line&) state of the trajectorywith the minimum distance from a given line

• virtual TrajectoryStateOnSurface stateOnSurface(const Surface &) state of thetrajectory in the intersection with a given surface

• virtual TrackCharge charge() track’s charge

• virtual Measurement1D transverseImpactParameter() track’s impact parameter with re-spect to the associated vertex calculated in the transverse projection

• virtual Measurement1D zImpactParameter() difference between z coordinate of the mini-mum distance point of the track from the associated vertex in the transverse view and the z coordinate of thevertex itself

• virtual Measurement1D transverseImpactParameter() track’s tridimensional impact pa-rameter with respect to the associated vertex

67

68 CHAPTER 6. COMMONRECO

stateAtPoint, stateAtLine and stateOnSurface are provided by ImpactPointExtrapolator, Tra-jectoryExtrapolatorToLine and propagators, bearing the same frames orientations.

Furhermore, a Track has an associated vertex and a pointer to its base class is provided by

virtual Vertex * vertex()

and its momentum in the closer point to it is provided by

virtual GlobalVector momentumAtVertex()/.

Vertex

Vertex (CommonDet/PatternPrimitives/interface/Vertex.h) is an abstract interface for vertices. It contains the fol-lowing pure virtual methods:

• virtual ˜Vertex() pure virtual destructor

• virtual GlobalPoint position() const providing the position of the vertex

• virtual TrackPtrContainer tracks() const providing the container of pointer to the baseclass of the tracks associated with it

6.1.2 Propagators

Propagators take care of track extrapolation in the magnetic field, taking into account multiple scattering andenergy loss in the detector material. Their functionality is described by the Propagator interface (Common-Det/PatternPrimitives/interface/Propagator.h).

A track can either be extrapolated in the direction of its momentum vector, or in the opposite direction. Some-times the direction in which extrapolation should be performed is known. In this case, the Propagator should notloose time in determining that direction. UnidirectionalPropagators (CommonDet/PatternPrimitives/interface/UnidirectionalPropagator.h)are provided for that case, with a direction of propagation that can be set at construction:

UnidirectionalPropagator(PropagationDirection dir = alongMomentum);

the meaning of PropagationDirection being described later in this section. To allow fast (and approximate) or pre-cise (and slower) extrapolation, two implementations of the abstract UnidirectionalPropagator class are provided.They are described later.

Sometimes the user just wants to propagate a track onto a surface or in the vicinity of a space point, but withoutknowing the direction to follow. The BidirectionalPropagator (CommonDet/PatternPrimitives/interface/BidirectionalPropagator.h)takes care of determining the direction of propagation before performing extrapolation. It is a concrete class, usingthe fast UnidirectionalPropagator as default propagation algorithm.

The Propagators also make it possible to extrapolate track parameters without computing the transformation oftheir covariance matrix. This speeds up things when, for instance, one only wants to know the crossing point of atrack in a given detector without paying heed to the extrapolated errors.

6.1. TRACK RECONSTRUCTION 69

Extrapolating track parameters onto a surface

Track parameters at a given point in space can be extrapolated onto a surface using the

virtual TrajectoryStateOnSurface propagate (const FreeTrajectoryState&,const Surface&) const;

method of the Propagator. If error propagation is not needed, the FreeTrajectoryState passed should be constructedwithout error matrix, using constructor FreeTrajectoryState(const GlobalTrajectoryParame-ters& aGlobalParameters) of the FreeTrajectoryState.

In case of failure, the TrajectoryStateOnSurface returned is invalid, which can be tested by the bool Tra-jectoryStateOnSurface::isValid() const method of the TrajectoryStateOnSurface.

Extrapolating track parameters to the point of closest approach of a space point

There are two useful definitions of “point of closest approach”: the first one refers to a minimum distance in 3Dspace, and the second one refers to a minimum distance in the transverse projection. To avoid this ambiguity,specific objects are provided, instead of having a Propagator with an extended interface.

The ImpactPointExtrapolator object takes care of computing the point of closest approach in 3D while theTransverseImpactPointExtrapolator does it in the transverse plane. As far as regards the ImpactPointExtrapolatorthe method to be used is:

TrajectoryStateOnSurface ImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx) const;

or if the user wants to specify the Propagator:

TrajectoryStateOnSurface ImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx,const UnidirectionalPropagator& u) const;

TrajectoryStateOnSurface ImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx,const BidirectionalPropagator& p) const;

where vtx is the space point to which the track parameters are propagated.

In the first case, BidirectionalPropagator is used.

The Surface of the TrajectoryStateOnSurface returned has its local reference frame oriented in a practical way.The local x-axis is oriented along the vector joining vtx and the point of closest approach. The correspondingelement of the covariance matrix expressed in the local frame is thus the error on the distance of closest approachsquared.

Besides, as regards the TransverseImpactPointExtrapolator both the interface than the implementation are sim-ilar to those of ImpactPoinrExtrapolator: the only difference that the calculation is performed in the transverseplane and thus no approximation is needed.

The methods that should be called are the following:

TrajectoryStateOnSurface TransverseImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx) const;


or if the user wants to specify the Propagator:

TrajectoryStateOnSurface TransverseImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx,const UnidirectionalPropagator& u) const;

TrajectoryStateOnSurface TransverseImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const GlobalPoint& vtx,const BidirectionalPropagator& p) const;

Extrapolating track parameters to the point of closest approach to a line

The TrajectoryExtrapolatorToLine provides the state of closer approach in 3D of a FreeTrajectoryState to a Line(CommonDet/DetGeometry/Line.h). Its interface is the following:

TrajectoryStateOnSurface TrajectoryExtrapolatorToLine::extrapolate(const FreeTrajectoryState& fts, const Line& aLine) const;

TrajectoryStateOnSurface ImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const Line& aLine,const UnidirectionalPropagator& u) const;

TrajectoryStateOnSurface ImpactPointExtrapolator::extrapolate(const FreeTrajectoryState& fts, const Line& aLine,const BidirectionalPropagator& p) const;

The TrajectoryStateOnSurface is returned in a way such that the surface has its local frame with the x axisalong the minimum distance direction pointing from the line to the trajectory, the z axis along momentum and y inorder to form a right handed frame (the rotation on xy plane is not already performed).

GtfPropagator

The GtfPropagator extrapolates the track parameters along a helix of axis parallel to the global z-axis and of radiusinversely proportional to the z-component of the magnetic field. It takes the material traversed into account in anapproximate way: the correction applied corresponds to the material thickness of the target surface. 1

The GtfPropagator can thus be used in the tracker, where the magnetic field is reasonably homogeneous andalong z, and where the material can be approximated as being concentrated in the detection layers. It should alsobe used only from one detection layer to the next one, or along a path crossing no material, so that the materialtraversed can be accounted for in an appropriate way.

GeaneWrapper

For track extrapolation in regions of inhomogeneous magnetic field, or with a large transverse field component, orwhere the material cannot be considered as concentrated in thin layers, the GeaneWrapper should be used. It is awrapper to the Fortran GEANE package [?]. It performs precise iterative track propagation in a 3D magnetic fieldand through the material defined in the GEANT description of the detector.

1For the multiple scattering, it increases the angular components of the error covariance matrix (using a Gaussian model); for the energyloss, it decreases the particle momentum by an average value computed from the Bethe-Bloch formula (without density term) and increases theq/p component of the error covariance matrix.

6.1. TRACK RECONSTRUCTION 71

PropagationDirection

The PropagationDirection is an enum defined in CommonDet/PatternPrimitives/interface/PropagationDirection.h.It can take two values:

enum PropagationDirection {oppositeToMomentum, alongMomentum};

which mean what their names say: oppositeToMomentum means that the propagation of the track parameterswill be performed in the direction opposite to the momentum vector defined by these parameters.

6.1.3 Reconstructed Track

RecTrack class (CommonDetPatternTools/interface/RecTrack.h) is a concrete class for both Tracker’ s than muonsystem’ s reconstructed tracks. It inherits the base class Track.h [?] and provides an implementation of its methods.

RecTrack has two constructors

RecTrack()RecTrack(const Trajectory & aTrajectory)

and allows to get the informations regarding the Trajectory it is created from by the following methods:

const Trajectory& trajectory() constTrajectory& trajectory()

for direct access to the Trajectory and

TrajectoryMeasurement stateAtFirstPoint() constTrajectoryMeasurement stateAtLastPoint() const

to access the first and last measurements of the associated Trajectory.

Among the other methods there are:

• TrackCharge charge() track’ s charge

• Vertex * vertex() pointer to the vertex associated to the tracks: it is set 0 by default from the con-structor.

• void setVertex(Vertex* aVertex) to set the pointer to the associated vertex

• TrajectoryStateOnSurface impactPointStateOnSurface() const and Trajecto-ryStateOnSurface impactPointStateOnSurface( const BidirectionalPropagator &) constcalculate the minimum distance point from the associated vertex or to the point (0,0,0) in case vertex()is returning 0. The extrapolation starts from the first measured point. A copy of it (TrajectoryStateOnSurface theIm-pactPointState ) is kept in the private area in order not to calculate it more than once

• GlobalVector momentumAtVertex() track’ s momentum at the impactPointStateOnSur-face()


• FreeTrajectoryState impactPointState() and FreeTrajectoryState impactPointState( const Bidi-rectionalPropagator &) providing the FreeTrajectoryState at the closer point to the associated ver-tex

• a bool operator==(const RecTrack & rt) const to compare two tracks (returning true ifthey are the same)

An implementation for Track’ s methods

• TrajectoryStateOnSurface stateAtPoint( const GlobalPoint&)

• TrajectoryStateOnSurface stateAtLine( const Line&)

• TrajectoryStateOnSurface stateOnSurface(const Surface &)

described in [?] is provided as well. A first extrapolation starts from the impactPointStateOnSurface(). Inorder to take into account the propagation through matter, a second extrapolation starts from the closest measuredpoint to the output of the first extrapolation. The closer measured point from a GlobalPoint is provided by theprivate method TrajectoryMeasurement closestMeasurement(GlobalPoint &). As far as re-gards TrajectoryStateOnSurface stateOnSurface(const Surface &) GeaneWrapper Prop-agator is used by default. A BidirectionalPropagator may be used as well with

TrajectoryStateOnSurface stateOnSurface(const Surface &, const Bidirectional-Propagator &)

Extrapolation to Geant Volume is allowed by the methods

• FreeTrajectoryState stateOnVolume(string & volumeName) const

• FreeTrajectoryState stateOnVolume(string & volumeName, const Propagator &) const

The first one uses GeaneWrapper by default while the second one allows to choose the Propagator.

Track.h’s methods

• Measurement1D transverseImpactParameter() const

• Measurement1D zImpactParameter() const

• Measurement1D impactParameter3D() const

are implemented as well: in the calculation of the Measurement1D’s the uncertainty on the associated vertexis not taken into account. In case the extrapolation fails due to bad reconstruction of the track the uncertainty andsignificance are set 0..

6.2. TRACK FINDING AND FITTING 73

6.2 Track finding and fitting

The abstract TrackFinder class is the class responsible for providing the reconstructed tracks of the current event,through the method:

virtual void reco (vector<RecTrack>&) = 0;

The track finding and fitting algorithms can be divided into logic steps, which consist in, e.a., choosing whichlayer to try next, which hit to include, and when to stop tracking; and mathematical steps, which consist in prop-agating the track parameters and their errors from layer to layer, and updating the track parameters taking intoaccount the measurements of the track crossing points provided by the tracking layers.

The logic and mathematical steps are the responsibilities of different objects with well-defined interfaces. Eachconcrete track finder can then be implemented using different versions of these objects, realizing more or lessfast, more or less precise tracking algorithms. Section refug:track-fitting-tools describes the mathematical toolsavailable for tracking. Section refug:iterative describes two-pass iterative algorithms, typical of Kalman filterbased track fitting.

6.2.1 Mathematical tools

The mathematical tools required by such algorithms are:

• a Propagator, which propagates the track parameters and their error matrix from a layer to the next one,and takes into account multiple scattering and energy loss in the detector material. This tool is described insection ??.

• an Updator, which is a mathematical object that updates the track parameters and their errors using theinformation of the RecHit. This object is described below.

The Updator

The interface of the Updator consists of one single method:

virtual TrajectoryStateOnSurface update(const TrajectoryStateOnSurface &,const RecHit &) const;

which takes a TrajectoryStateOnSurface and a RecHit and returns a TrajectoryStateOnSurface updated using theRecHit information.

The KFUpdator is the implementation of Updator which mathematics is that of the Kalman Filter algorithm [?].It is-a MeasurementEstimator also, which means that it implements method:

virtual double estimate(const TrajectoryStateOnSurface &,const RecHit &) const;

That method returns the χ2 formed with the residuals between the track parameters on a given surface and a RecHitfrom that surface.

The KFUpdator is constructed with a maximum χ2 value. If the χ2 between the track parameters and theRecHit exceeds that maximum value, they are not compatible with each other, and the χ2 estimate returned is 0.


6.2.2 Iterative track fitting

Iterative track fitting usually consists of two phases: filtering and smoothing. Filtering starts from a coarse esti-mation of the track parameters at a given layer, then proceeds iteratively, propagating the track parameters to thenext layer, accounting for multiple scattering and energy loss in the material between the layers, and updating thepropagated track parameters using the compatible RecHit(s) found in the layer.

The estimation of the track parameters is more and more precise as more and more RecHits are included in thefit. However the precision may be poor in the first layers. Therefore filtering is usually followed by a smoothingphase, proceeding in the direction opposite to the filter, and correcting the estimation of the filter layer per layer,using the information of all the hits. A simple way of implementing the smoothing is to combine the estimationsof two filters proceeding in opposite directions.

An abstract class for such algorithms is KfReconstructor. It is-a TrackFinder constructed with a SeedGeneratorfor generation of starting track seeds, a TrajectoryBuilder which is the first pass of the track finding algorithmtogether with a Propagator which determines the direction into which the TrajectoryBuilder proceeds, a Trajecto-rySmoother which is the second pass of the track finding algorithm together with a Propagator with a direction ofpropagation opposite to the one of the TrajectoryBuilder, a MeasurementEstimator which determines the proba-bility of compatibility of a hit with the track on a given surface, and an Updator wich computes the updated trackparameters using the measured hit coordinates.

Available KfReconstructors are:

The default one is the FkfReconstructor. Its first and second pass algorithms are the GtfTrajectoryBuilder,proceeding from the innermost detection layer outwards, and the KalmanSmoother, proceeding from the outermosthit used by the GtfTrajectoryBuilder inwards. These algorithms are described below.

GtfTrajectoryBuilder

KalmanSmoother

The KalmanSmoother is a concrete implementation of TrajectorySmoother, i.e. it implements the followingmethod:

virtual TrajectoryContainer trajectories(const Trajectory&) const = 0;

which takes a Trajectory and returns smoothed Trajectories made from it. Currently it can only make use of thesame hits as those of the initial trajectory, and is only able to produce zero or one smoothed trajectory out of it.

The KalmanSmoother starts from the last Measurement included in the Trajectory and initiates a backwardKalman filter. At each layer the predicted states from the forward and backward filters are combined, providing anestimate of the track parameters which uses the information of all measurements but the one of the current layer.Therefore, that estimate allows the most selective compatibility test between a hit and a track.

The compatibility test between the combined state and the hit is performed by the MeasurementEstimatorpassed to the KalmanSmoother at construction. If compatible, the combined state is updated with the hit using theUpdator of the KalmanSmoother (also set at construction). The smoothed state is then stored together with the hitand the χ2 between the hit and the combined state.

To increment the track total χ2, one cannot use the χ2 between the hit and the combined state, because thecombined states at the different layers are not independent. One thus accumulates the χ2 between the hit and thepredicted state of the backward filter.

If a hit is found incompatible with the track at smoothing, the backward filter proceeds further without using it,which means that the next smoothed states will not include the information of that hit anymore.

Chapter 7

The Muon Subsystem

7.1 Muon reconstruction in barrel region

7.1.1 Introduction

All basic muon barrel reconstruction is included in the Muon domain.

7.1.2 Package structure

The muon reconstruction package is presently organised as follows (the most important sub-packages being indi-cated in parenthesis):

• geometry initialisation and access to simulated hits through GEANT3 interface (cms115 and cms116 ver-sion) (MBG3Interface);

• digitisation (MBDigitizer);

• creation of RHITs through time-space conversion (MBCalib);

• reconstruction of 2-dimensional segments in every chamber, from now on referred to as clusterisation(MBClusterizer);

• track fitting: (MuonTrackFinder)

7.1.3 Basic reconstruction classes

The different steps of the reconstruction are performed by means of CARF lazy observers (LO) and reconstructors(R) (see the CARF and Utilities section of this guide) to provide a reconstruction and simulation on demand:

• MuBarrelSetup (LO) is responsible for geometry initialisation and allows to choose the algorithms fordigitisation, hits reconstruction and clusterisation;

• MuBarTrackFinder (R) takes care of the whole reconstruction procedure, starting from 2-dimensionalsegments;

75

76 CHAPTER 7. THE MUON SUBSYSTEM

7.1.4 Access to track information

The information on the fitted tracks is accessed by means of the TTrack class, which inherits from the CARFRecObj and the RecTrack class (see CommonDet description). The following lines of code show how to obtainthe TTrack objects in the specific RecEvent:

// get the iterator over the tracksRecItr<TTrack> TrackItr(ev->recEvent(),’’reconstructor name’’);// ev is a G3EventProxy

// loop over all tracks in the current RecEventwhile( TrackItr.next() ){

// access to muon barrel chamber wheel, sector, ...// for the innermost fitted segmentTrajectoryMeasurement meas = (*recmuon).stateAtLastPoint();TrajectoryStateOnSurface traj = meas.trajectoryStateOnSurface();GlobalVector dir = traj.globalDirection();GlobalVector mom = traj.globalMomentum();GlobalPoint pos = traj.globalPosition();

...// chi2double chi2 = (*recmuon).trajectory().chiSquared();

...}

7.1.5 Build and run the test program

The file Muon/MBTracker/test/muon_reco.cpp provides an example of a main program (empty!!). Toinsure that the program will work properly, the following environment variables must be set in addition to the usualones (geometry file, etc.):

# mandatory: activates DE MEDI to read materials for GEANEsetenv GEANEUSED TRUE

The output CWN ntuple will be stored in the HBOOK file muon_track.hbook. The ntuple blocks are describedbelow:

• GENER BLOCK: information on generated particles

• GEANT BLOCK: state vector of generated muons in every chamber

• SEG BLOCK: contains the output of the local pattern recognition (i.e. 2D-Track segments) in the BarrelMuon Stations

– ox,oy,oz: position in global CMS frame

– dx,dy,dx: cosine directors

7.2. THE ENDCAP MUON CSC SYSTEM 77

– npt: nr. of hits used in the track segment (> 0 if it’s an r-phi track segment, < 0 is it’s an r-z one)

– st: station number: st=100*nst+ sector where nst=1-4 and sector is the sector number (1-12), countedcounter-clockwise starting from phi=0.

• MUON BLOCK: contains the output of the ’off-line’ (i.e. Kalman filtering) reconstruction code in theBarrel;

– variables ending with ’m’ (i.e. Xm,Ym,Zm,...ecc) refers to quantities as measured at the last measure-ment surface (e.g. MB1 inner layer) of the track (no primary vertex constraint is used here) ;

– variables ending with ’v’ (i.e. Pv,Thetav,...) refers to quantities at production vertex (assumed to be thebeam spot) after the fitting with the beam spot constraint imposed.

7.2 The Endcap Muon CSC system

• Please refer to CMS Note 2001/013 for information.

• For a quick overview of the Endcap Muon CSC system see the ORCA documentation for the MEDetectorsubpackage, accessed from the web page for the ORCA reference manual via the link to Muon and then toPackages in Muon subsystem.

• The link to MEUser explains how to access various objects (hits, digis, rhits, etc.) for the CSCs.

• The Muon web page in the reference manual also has a link to the CMS note mentioned above.

7.3 Digi-SimHit associations

For each digi in the three subdetectors, we store the information about which SimTracks in the signal event con-tributed to the hit. The list of SimTracks can be obtained from the G3EventProxy using:

BaseSimEvent::track_container tkcont = ev->simSignal()->tracks();

The associations are stored in the SimDet, which you get from DetUnit::simDet(). Our DetUnits are the MuBar-Chamber, MRpcDetUnit, and MuEndLayer. The method you use in SimDet::simTrackIds(int channel, float frac-tion), where fraction is the minimum fraction of the total charge a track should contribute. This method returns avector of ints, which are the indices into the vector of SimTracks. The channel is coded as follows: BARREL:

MuBarIDPacking pack;int wireId = pack.packInDetUnit(digi.wire(), digi.layer(), digi.slayer());vector<int> simTrackIds = chamber->simDet()->simTrackIds(wireId, 0.1);

ENDCAP: Channel numbers 1-80 are strips. For wiregroups, use the wiregroup number+ 100.

vector<int> simTrackIds = layer->simDet()->simTrackIds(wireDigi.channel()+100, 0.1);

RPC:

vector<int> simTrackIds = detUnit->simDet()->simTrackIds(digi.giveStripId(),0.1);

78 CHAPTER 7. THE MUON SUBSYSTEM

Chapter 8

Trigger code in ORCA

8.1 Introduction

The Trigger package includes simulation of Level 1 trigger.

8.2 Calorimeter Trigger

8.3 Muon Trigger

8.3.1 Muon DT on-chamber Trigger

Description

Implementation of Level 1 Muon Drift Tube on-chamber Trigger. This is the interface package with higherlevel objects.

Access to the system is done through the L1MuDTTrig object, which is also responsible for system setup.

The other related packages are:

• L1DTUtilities . Configuration parameters and geometry

• L1DTBti . BTI simulation

• L1DTTraco . TRACO simulation

• L1DTTriggerServerPhi . Track Sorter (phi-view) simulation

• L1DTTriggerServerTheta . Track Sorter (theta-view)simulation

79

80 CHAPTER 8. TRIGGER CODE IN ORCA

System setup

The L1MuDTTrig object is instantiated by the user as a Singleton. It is a LazyObserver¡G3SetUp*¿: whena new run in read in it is notified and the first time it is asked for any information it instantiates a newL1MuDTTrigUnit for each muon chamber (MuBarChamber).

The L1MuDTTrigUnit can access geometry information through the L1MuDTTrigGeom object whichhas a link to the corresponding MuBarChamber.

The L1MuDTTrigUnit also has all the trigger card objects (L1MuDTBtiCard, L1MuDTBtiCard, L1MuDTTSPhiand L1MuDTTSTheta) which are LazyObserver¡G3EventProxy*¿: when a new event is read in they are no-tified and they activate themselves when their output is asked for.

Input data

Input to the simulation are the MuBarDigi which are accessed through the MuBarChamber object.

Deliverables

The main use-case requires access to the track segments in the phi-view and BTI patterns in the theta viewfor a given chamber and bunch crossing. The sintax is:

L1MuDTTrig* dttrig = Singleton<L1MuDTTrig>::instance(); // get L1MuDTTrig objectint iwh=...; // wheel: [-2,2] (-z to +z)int ist=...; // station: [1,4] (inner to outer)int ise=...; // sector: [0,11] (phi 0 to 2pi)int is=...; // in-time triggers have BX is=dttrig->correctBX();// get first and second phi segments and the theta view BTI pattern:L1MuDTChambPhSegm* first = dttrig->chPhiSegm1(iwh,ist,ise,is);L1MuDTChambPhSegm* second = dttrig->chPhiSegm2(iwh,ist,ise,is);L1MuDTChambThSegm* theta = dttrig->chThetaSegm(iwh,ist,ise,is);

Note that sectors 3 and 9 in MB4 (horizontal chambers) are split in two. To access them individually youneed to use their MuBarChamberId:

L1MuDTTrig* dttrig = Singleton<L1MuDTTrig>::instance(); // get L1MuDTTrig objectint iwh=...; // wheel: [1,5] (-z to +z)int ist=...; // station: [1,4] (inner to outer)int ise=...; // sector: [1,12] in MB1,MB2,MB3 (phi 0 to 2pi)

// [1,14] in MB4 13 is pi/2, 14 is 3/2 piMuBarChamberId chid(iwh,ist,ise);// get first and second phi segments and the theta view BTI pattern:L1MuDTChambPhSegm* first = dttrig->chPhiSegm1(chid,is);L1MuDTChambPhSegm* second = dttrig->chPhiSegm2(chid,is);L1MuDTChambThSegm* theta = dttrig->chThetaSegm(chid,is);

Access to intermediate results is also possible. Output by BTI’s, TRACO’s, TS-phi and TS-Theta arecopied to temporary STL vectors and pased to the user:

8.3. MUON TRIGGER 81

L1MuDTTrig* dttrig = Singleton<L1MuDTTrig>::instance(); // get L1MuDTTrig objectvector<L1MuDTBtiTrigData> btitrigs = dttrig->BtiTrigs(); // BTI outputvector<L1MuDTTracoTrigData> tracotrigs = dttrig->TracoTrigs(); // TRACO outputvector<L1MuDTChambPhSegm> tsphtrigs = dttrig->TSPhTrigs(); // TS-phi outputvector<L1MuDTChambThSegm> tsthtrigs = dttrig->TSThTrigs(); // TS-theta output

Example

Examples are in Trigger/L1DTTrigger/test/RunL1DTTrig.ccand Trigger/L1DTTrigger/test/NtupL1DTTrig.cc(see also Trigger/L1DTTrigger/src/L1MuDTMakeCWN.cc)

8.3.2 Muon DT Track Finder

8.3.3 Muon CSC Track Stubs

Description

Implementation of Level 1 Cathode Strip Chamber Trigger. Includes Cathode and Anode LCT, TriggerMotherboard, Muon Port Card and Sector Receiver functionalities.

System setup

The L1MuCSCPrimitiveSetup object is instantiated by the user as a Singleton. It is a LazyObserver¡G3SetUp*¿:when a new run is read in it is notified and the first time it is asked for any information it instantiates a newset of electronics from Sector Receivers all the way through Anode and Cathode LCT cards. The Anode andCathode LCTs retrieve wire and strip DIGIs from the Muon Endcap digitizers.

When the Sector Receiver is instantiated, it makes a corresponding lookup table. This is done by query-ing the chambers for their geometry so the table is always correct for a given run-time geometry.

Input data

Input to the simulation are the MuEndWireDigi and MuEndStripDigi which are accessed through theMuEndCapSystem object:¡p¿ ¡pre¿ MuEndcapSetUp* theEmu = Singleton¡MuEndcapSetUp¿::instance();MuEndcapSystem* emu = theEmu-¿MEndcap(); ¡/pre¿

Deliverables

Output data are the CSC Trigger Primitives (track stubs) in phi and eta views. They are accessed asL1MuCSCTrackStubs (as a function of endcap, station, sector, subsector and bunch crossing):¡p¿

#include "Trigger/L1CSCTrigger/interface/L1MuCSCPrimitiveGenerator.h"#include "Trigger/L1CSCTrigger/interface/L1MuCSCPrimitiveSetup.h"L1MuCSCPrimitiveSetup* primSetup = Singleton<L1MuCSCPrimitiveSetup>::instance();L1MuCSCPrimitiveGenerator* primGen = primSetup->PrimitiveGenerator();

L1MuCSCTrackStub tsA;


int bx = L1MuCSCSetup::currentBx();

for (int endcap = 1; endcap <= 2; endcap++)for (int station = 1; station <= 4; station++)

for (int sector = 1; sector <= 6; sector++)for (int subsector = 1; subsector <= (station == 1 ? 2: 1); subsector++)for (unsigned int stub = 0;

stub < primGen->trackStubList(endcap, station, sector,subsector, bx).size();

stub++) {tsA = *(primGen->trackStubList(endcap, station, sector,

subsector, bx).begin()+stub);

See L1MuCSCTrackStub for details about what can be accessed.¡/p¿

There is also an ntuple created when one uses

#include "Trigger/L1CSCTrigger/test/L1MuCSCMakeStubCWN.h"PKBuilder<L1MuCSCMakeStubCWN> makeNtuple("L1MuCSCMakeStubCWN");

See L1MuCSCMakeStubCWN for ntuple contents.

Example

Examples are in Trigger/L1CSCTrigger/test/RunL1CSCStubs.cpp.

8.3.4 Muon CSC Track Finder

8.3.5 Muon RPC Trigger

author: Marcin Koneckicontact persons: Marcin Konecki ([email protected]), Grzegorz Wrochna ([email protected])

RPC Trigger Idea

The RPC based muon trigger operates on four (logical) trigger planes chosen (direction dependent) out ofpossible (hardware) RPC chambers from barrel and endcaps of the CMS detector. Each plane is equippedwith strips (of about 5/16o width each). A muon, passing solenoidal magnetic field of the detector crossesRPC planes, lighting strips on its way (Fig. 8.1). Due to bending in the magnetic field, the combinationof lighted strips is correlated with the muon transverse momentum. Thus, comparison of lighted stripsconfiguration (called pattern) with the set of predefined combinations (called set of valid patterns or masks)gives information about muon momentum, enabling triggering. The actual comparison of given patternwith masks is done by the PAttern Comparator (PAC) - the core of RPC trigger.

The dead areas and chamber inefficiencies force us to introduce algorithm in which the event may betriggered even if only three hits in four chambers match a predefined pattern (called 3 out of 4 algorithm).The resolution of trigger is limited by the multiple scattering and energy losses causing different pT tracks

8.3. MUON TRIGGER 83

4T

2T

Figure 8.1: RPC trigger principle

corresponding to the same pattern (while tracks with the same pT can give several patterns). On the otherhand the resolution of trigger is limited by the strip size and the number of valid patterns that can be loadedinto PAC.

In the chosen implementation, the increasing variation from the straight line is treated with patternsbased on groups of strips (grouped by up to 8). Moreover for low pT muons (pT less than approximately6 GeV) a dedicated block in PAC chip is added making Trigger more flexible (for example it enables usageof RPC planes MB1,MB1’,MB2,MB2’ for low pT triggering in barrel, instead of MB1,MB2,MB3,MB4 usedusually)

Functionality

The full simulation chain of RPC trigger consists of the following 3 steps:

• hit formatting (with the subpackage MRpcSimHitFormatter under Muon);

• hit digitisation (with the subpackage MRpc under Muon)

• running trigger algorithm itself (L1RpcTrigger under Trigger).

The role of the L1RpcTrigger subpackage is to mimic RPC trigger action that is, to reconstruct triggeredmuons starting from digis. The assigned pT value is the one associated to the matched pattern defined asthe ”maximal” pT corresponding to the pattern. All the base functionality of RPC trigger is implemented,namely: connections of chambers to given PAC processors, PAC behaviour and answer, GhostBuster andsorter. Still missing in implementation (but in preparation) are chamber timings, clustrisation and declus-trisation.

Configuration and Setup Files

The RPC trigger simulation has to be provided with information about chamber-PAC connections (MRT3DAT)and set of valid patterns (MRT1DAT). Apart from that the user may want to set the debug level (0-7) (if in-formation about internal trigger process flow is required) or switch on/off declustrisation. Here are thedefaults (modifiable with .orcarc):

L1RpcTrigger:MRT1DAT = /afs/cern.ch/user/k/konec/public/orca/mrt1.datL1RpcTrigger:MRT3DAT = /afs/cern.ch/user/k/konec/public/orca/mrt3.datL1RpcTrigger:Decluster = 1L1RpcTrigger:Debug = 0


User Interface Overview

The user has to instantiate L1Rpc object as the singleton. That time RPC Trigger is initialised.

L1Rpc* l1rpc = Singleton<L1Rpc>::instance();

Than it is possible to ask for reconstructed RPC muons. The Trigger action is computed on demand,once per event taking digis generated by MRpc as the input. The result can be returned as vector of fourL1RpcCandidate objects from barrel and endcaps. The L1RpcCandidate inherits from L1VCandidate – ageneral interface for L1 trigger output.

vector<L1RpcCandidate> rpcBmu = l1rpc->giveBarrelMuons();vector<L1RpcCandidate> rpcEmu = l1rpc->giveEndcapMuons();

The number of non-empty reconstructed trigger muons for barrel and endcaps may be obtained by separatecalls:

l1rpc->giveNumberOfBarrelMuons()l1rpc->giveNumberOfEndcapMuons()

The following access methods of L1VCandidate supported by L1RpcCandidate may be of user interest:unsigned int pt(), float ptValue() pT of reconstructed muon (its integer code and corre-

sponding value in GeV/c)unsigned int phi(), float phiValue() ϕ, i.e. RPC segment number (ϕ code [0 ÷ 143] and ϕ

value corresponding to the lower edge of segment inradians)

unsigned int eta(), float etaValue() pseudorapidity of reconstructed muon i.e. the RPCtower (code TOWEROFFSET+[-16 ÷ 16] and η valuecorresponding to the middle of the tower)

int charge() can be -1,1unsigned int quality() flag (0,1,2 or 3) accompanying reconstructed muons

specifying how trustworthy the result (especially re-constructed momentum) should be. For the high pT

mode (assigned pT not less than approx. 6 GeV) thevalue of 3 is set if current pattern match exactly thepredefined one (4 out of 4), the value of 2 is set if sta-tion 3 or 4 is missing. Values 1 and 0 corresponds tomissing station 1 and 2 respectively. For the low pT

algorithm 4 out of 4 is marked with a flag of 3 againbut any missing plane gives a flag of 0.

The position of the reconstructed muon (ϕ,η) is defined with respect to reference plane i.e. station 2. Theempty muon is marked by pt code set to 0 (in this case numbers returned by other methods are meaningless).

Example

To simulate full chain or RPC behaviour starting with cmsim hits one has to create and initialise the fed-eration at first as described at the beginning of the manual. Cmsim hits can be converted to orca ones us-ing MRpcSimHitFormatter (example in Muon/MRpcSimHitFormatter/test directory) and then digi-tised with MRpc (see the example in Muon/MRpc/test). Using the digis the L1RpcTrigger trigger codecan be run. To do that the example BuildFile in Trigger/L1RpcTrigger/test generates executableExL1RpcFromDigis.

8.4. GLOBAL TRIGGER 85

8.3.6 Global Muon Trigger

8.4 Global Trigger

Chapter 9

JetFinders, design, implementation, andusage

The exploitation of hadronic final states played a key role in the successes of all recent HEP collider exper-iments, and the ability to use the hadronic final state will continue to be one of the decisive issues duringthe LHC era. Jet finders play a key role in this endeavour, and strong activities in this area have beenprogressing since many years.

We use the advantages of the abstractions enabled by object technology, in order to extend the flexibilityof the jet finding possibilities during analysis. The jet finder library described provides a comprehensiveframework for jet-finding. It starts from any kind of consistent collection of reconstruction objects or par-ticles, and results in a collection of user-defined jet class instances.

We provide the jet-finding framework for CMS, and use this opportunity to exercise industrial softwareengineering processes to establish the proof of concept of physics object reconstruction for hadronic finalstates.

9.1 Noun List

In order to go by the book, we base our design and analysis phase on the noun list in the application domain.The nouns we find are

• Jet finder

• Jet algorithm

• Jet variable

• Jet collection

• Jet

• Cluster, track, particle, cell

87

88 CHAPTER 9. JETFINDERS, DESIGN, IMPLEMENTATION, AND USAGE

9.2 Requirements

User requirements on jets:

JET-1 A jet shall be able to construct from various inputs.

JET-2 A jet shall be able to compute jet energy.

JET-3 A jet shall be able to compute jet mass.

JET-4 A jet shall be able to compute jet rapidity.

JET-5 A jet shall be able to compute jet azimuthal angle.

JET-6 A jet shall be able to compute jet polar angle.

JET-7 A jet shall be able to provide access to its constituents.

JET-8 A jet shall be able to provide pointers to its constituant.

All other requests, like b-tag or estimators for τ identification, seem specific to a given analysis, and thedesign is required to allow for extendibility of the system such that the jet-finder can be used together withany user-defined jet class.

User requirements on jet-finders:

JETF-1 A jet finder shall allow for input filters.

JETF-2 A jet finder shall provide the possibility of using different jet-algorithms during one job.

JETF-3 A jet finder shall be able to run on any consistent set of inputs (cells, tracks, clusters, particles,tracks and clusters, etc..)

JETF-4 A jet finder shall be able to provide access to any type of jets.

JETF-5 A jet finder shall allow for more than one input/algorithm combinations per event.

JETF-6 A jet finder shall allow for filters (cuts) at the input of jetfinding.

JETF-7 A jet finder shall allow for hadronic calibration prior to, and after jetfinding.

JETF-8 A jet-finder shall allow to change jet-algorithm parameters, and re-invoke for the same event.

User requoirements on jet algorithms:

JETA-1 A jet algorithm shall give a warning, if is is not intended for complete LHC events.

JETA-2 Seeded jet algorithms (cone like algorithm) shall have adjustable seed-threshold.

JETA-3 A cone-type algorithm shall allow for jet(candidate) direction dependent jet-algorithm pa-rameters.

User requirements on auxillary tools:

JETT-1 Auxillary tools shall allow to find objects within a given collection (say muons, tracks orgenerator particles) that are within an eta-phi cone arround a given jet or direction.

9.3. RESPONSIBILITIES AND MAPPING TO DESIGN ELEMENTS 89

9.3 Responsibilities and mapping to design elements

Responsibilities

The above list of requirements served as starting point for designing the functionality in the abstractions ofthe system. We assign the following responsibilities to the main classes in the system.

Jet finderThe jet finder is the entity that steers the jet finding and manages the message passing between the differentclasses in the system.

Cluster, track, particle, cell, etc.Cluster, track, particle, or cell are examples of the input classes to the jet-finder.

Jet algorithmThe jet algorithm is a class that knows to build jets from a concrete set of input class instances.

JetThe jet in general is a user-designed class. Its design might depend very much on the objective of the analy-sis (like QCD, B-physics, H→WWjj, etc.). The jet class is responsible to guarantee access to the elementaryproperties of the jets and their constituents and to the constituants themselfes.

Jet collectionThe jet collection is able to hold a list of jets, and to allow access to these jets.

Mapping of user requirements on design elements

The requirements can be mapped to design elements as described in the following. Note that in general morethan one possibility is considered before a decision is taken, but that the set of possibilities considered is notmeant to be complete.

Requirements on Jet finder A jet finder shall allow for input filters:– The jet finder can be templated with the filter. This allows for exactly one filter.– The jet finder can have a pointer to a filter base class that defines the protocol for the filter. This enablesthe possibility to have a cascade of filters. A registration mechanism, along with a clearing mechanism isnecessary. It also implies a coherent interface for the inputs on which the filter can run. A base class filterwith a well defined interface is needed, which implies the need for a JetableObject class.– An user defined input generator class the interface of which is defined by a base class can provide thisfunctionality.

A jet finder shall provide the possibility of using different jet-algorithms during one job:– To separate the jet-algorithm from the jet-finder and use a concrete jet-algorithm in the jet-finder througha jet-algorithm base class interface, can provide this functionality.

A jet finder shall be able to run on any consistent set of inputs:– Templating with the input solves the problem, if there is only one type of inputs in one job, and the inputhas by convention a well defined interface.– A JetableObject class that can construct from the various inputs is an alternative. In this case, theJetFinder still either needs a loading mechanism for all possible inputs, or a separate class takes this re-sponsibility.


– A third possibility is to template the jet finder with a user-definable JetableObject class that obeys aninterface given by a base class, and hence can allow polymorphic access to the constituents while keepingperformance.

A jet finder shall be able to provide access to jets:– Returning an iterator over jets will do this job. Since the Jet will be user defined, the JetFinder could betemplated with the Jet.

Requirements on Jet A Jet base-class that defines the interface to the required functionality will satisfy allrequirements. The requirement of having access to the constituants directly can be left to the user, or can beimplemented in the jetable object class by adding the corresponding functionality to the constructors andadding access methods. Alternatively, one can template the JetableObject Class with the constituent type,and use dynamic cast in the application to sort out the type of the constituant.

9.4 Object Oriented Design

9.4.1 Base-line design

The design choices made are to template the JetFinder with the concrete jet-type, i.e. to write genericalgorithms for jet-finding, and hence de-couple the algorithm from the concrete analysis.

The input is handled via an input generator base class, providing maximum flexibility for the user to doselections and cuts, and decoupling the jet-finding algorithm from the concrete input data types.

The jet-finding is done internally on a JetableObject class that is templated with the input type, and hasa base class, used in the jet-finding.

The interface to the application framework is done via a facade class, following the component approach,and allowing to easily follow changes in application framework functionality.

For more information on the design, please see figure9.1.

9.5 Concrete Algorithms

Several concrete jet-finders as commonly used in e+e− and hadron colliders have been implemented todemonstrate the flexibility of the system. They are described below in some detail.

Simple Cone Algorithm

A trivial cone-based algorithm is implemented in the SimpleConeAlgorithm class. The algorithm searchesthe maximum transverse energy object and throws an η−φ cone around its direction. Any object within thatcone will be merged to form a jet. The constituents are removed from the list of objects, and the procedureis repeated until no objects are left in the list.

9.5. CONCRETE ALGORITHMS 91

Iterative Cone Algorithm

An iterative, cone-based algorithm [9] is implemented in the IterativeConeAlgorithm class. The algorithmagain searches the maximum transverse energy object and throws an η − φ cone around its direction. Anyobject within that cone will be merged to form a proto-jet. The proto-jet direction is calculated from theenergy weighted directions of the constituents, and a cone in η − φ is thrown around the new direction toform a new proto-jet. The procedure is repeated until the proto-jet does not change significantly betweentwo iterations, which is that the jet energy change is smaller than a tunable value (1% by default) and√

(∆η2 + ∆φ2) is below a tunable value (0.01 by default). The constituents are removed from the list ofobjects, and the procedure is repeated until no objects are left in the list.

Successive Combination Algorithm

In the successive combination [10] algorithm of S.D. Ellis and E. Soper, the test criterion is defined as

dij = min(E2T,i, E

2T,j)[(ηi − ηj)

2 + (φi − φj)2]/R2.

Here R is a free parameter of the algorithm that should be of order 1, ET,i is the transverse energy of anobject under test, and i, j refers to a pair of candidate objects.

Any object in the input is considered a jet candidate object. The minimum dmin of all dij is comparedto the minimum E2

T,min of all E2T,i. Is dmin smaller than E2

T,min, the corresponding pair of jet candidates ismerged into a single jet candidate. The new direction is calculated from the ET weighted directions of theconstituents. Otherwise, the candidate jet corresponding to E2

T,min is considered a jet and is removed fromthe iteration loop. The iteration continues until no jet candidates are left.

The algorithm is implemented in the SuccessiveCombinationJetAlgo class.

kt algorithm for hadron hadron colliders

In the kt [14] algorithm for hadron hadron colliders, the test-criterion used is

yij =2min(E2

i , E2j )

E2t

(1 − cos θij).

In contrast to other jet-algorithms there is a pre-clustering stage that aims at identifying the beam-jets.During this stage, macro jets are formed by comparing for each pair of hadronic objects the values of yij

with yip, the equivalent quantity with respect to beam direction p:

yip =2E2

i

E2t

(1 − cos θip)

If the minimum y is one of the yip, the associated hadronic object is moved into the corresponding beamjet. Otherwise the particles i, j are merged into a new hadronic object. The procedure is repeated on thenew set of hadronic objects, until no yij or yip is smaller than 1. The beam-jets are identified, and the otherhadronic objects are now considered to be macro-jets with sub-structure.

In a second step, the jet-structure in the macro-jets is resolved by successively merging minimum yij

objects into jet prototypes, which themselves are subject to the iteration. The iteration is done separatelyfor each macro-jet, and is stopped once the yij within each macro-jet are above a tunable cut-off value.

The algorithm is implemented in the HadronHadronK T Algorithm class.


Inverse colour dipole model

The inverse colour-dipole model [15] is an intriguing algorithm in so far, as it generates jets in such a mannerthat one cannot associate one constituent to exactly one jet. The reason lies in the usage of three clustercombinations and will become apparent from the description. For the practical reasons of performance andthe desire to use and recalibrate constituents, the algorithm is considered an exercise of the framework.

The algorithm considers all three particle combinations as candidates for colour dipoles that have radi-ated. The scale p2

t for the emission in a colour dipole is

p2t = Sdip

(

1 − x1 +m2

1 − (m2 +m3)2

Sdip

) (

1 − x3 +m2

3 − (m2 +m1)2

Sdip

)

.

Here x1 and x3 are the energy fractions in the final state of the two particles forming the emitting dipole,x2 is the energy fraction of the emitted particle, and Sdip is the dipole strength. Note that p2

t is a Lorentz-invariant quantity.

The final state particle configuration is identified for a given set of three particles by minimising p2t . Inthe commonly used implementation of the colour dipole model, the relation between the relative angles ofthe three particles in the the center of mass system of the radiating colour dipole is

θ =x2

3

x21 + x2

3

(π − ψ).

Here θ is the angle between the initial colour dipole axis and the direction of particle 1, and ψ is the anglebetween the two radiating particles in the final state. We use this convention in our implementation.

The algorithm takes the minimum p2t configuration of all 3-particle combinations, and merges the ra-

diated particle into the two radiating particles. The 3-particle system is then replaced by two mass-lessparticles along the dipole axis with opposite directions, each carrying half the dipole strength in energy.

The procedure is iterated, until the minimum pt of all 3-particle combinations is above a cut-off, and theremaining particles are considered to be jets.

JADE Algorithm

In the Jade [11] clustering algorithm pairs of objects are formed, based on the ordering in the test-variableyij , where

yij =2EiEj

E2vis

(1 − cos θ).

Here Ei and Ej denote energies of the candidate constituent objects, and Evis is the total energy in theevent. θ is the opening angle between the two candidates. The pair of objects with the smallest value of yij

is found, and combined into a new candidate constituent object in case yij < ycut. ycut is a free parameterof the algorithm, and defines the structural resolution of the jet algorithm. The new direction is calculatedfrom the ET weighted directions of the constituents. The iteration stops, when the minimum value of yij isfound to be larger than ycut.

The JADE algorithm is implemented in the JADEAlgorithm class.

Durham Algorithm

The logic of the Durham [12] clustering algorithm is analogous to the JADE algorithm. The test criterion ischanged to

yij =2min(E2

i , E2j )

E2vis

(1 − cos θ).

9.6. USAGE OF THE PACKAGE 93

The algorithm is implemented in the DurhamAlgorithm class.

Cambridge Algorithm

In the Cambridge [13] algorithm the test-criterion is identical to that of the Durham algorithm, but the test-criterion is only used to terminate the iteration loop. The ordering criteria differs from the test criterion,and is defined as

vij = 2(1 − cos θ).

The logic is the following. First select the pair of candidate jets with the smallest value of vij . If the corre-sponding value for yij is below cut-off, combine the candidates to form a new candidate jet, where the newdirection is calculated from the ET weighted directions of the constituents. If the corresponding yij is abovea tunable cut-off, the candidate jet that has the lowest energy in the pair is considered a jet. The iteration iscontinued, until only one candidate jet is left, which then is considered to be a jet.

This algorithm is implemented in the CambridgeAlgorithm class.

9.6 Usage of the Package

This package provides the framework for jet-finding, a set on input generators, a set of jet algorithms, andone concrete jet class with the possibility to user-define other jet-classes.

How to build an application

The elementary building blocks of a concrete instance of the JetFinder package are the input generator, theconcrete algorithm you would like to use, the framework, and the concrete jet type you want to reconstruct.

The jet-finder is designed to be able to run on any input. Currently provided are mechanisms to runon calorimeter digits (JetFinderDigiInput), Higher Lever Trigger towers (JetFinderCaloTowerInput), tracks(JetFinderTrackInput), and generator particles (JetFinderGeneratorInput). Any filtering for the moment ismeant to be done in the input generator class. The VJetFinderInputFilter class is currently a placeholder forfuture functionality. The possibility to add user-defined input generators will be added in the next iteration.

The concrete algorithms provided are described in the previous section. Flexibility that allows for user-defined algorithms will be released in the next iteration.

For use with the CARF application framework, we provide the JetFinderCARFFacade class. It is madeto be registered with CARF in the Reconstructor::buildDict() method in your analysis program. It allowsto register a jet algorithm through the JetFinderCARFFacade::setAlgorithm(...) method, and to register theinput generator of your choice through the JetFinderCARFFacade::setInputGenerator(...) method. Only onealgorithm and input generator are allowed at a time. Note that the JetableObject class used internally forjet-finding can construct from many different types. This allows in a first iteration to write input generatorsfor mixed input. A superior design is in preparation.

The concrete jet type to build is a user defined class, and the JetFinder package is templated with thejet-type. This allows to use the jet-finder package in different analysis, where the services the jet-type hasto provide might be entirely different (b-jets, or QCD jets, etc..), but the algorithm and input generator forfinding the jets can still be the same. The following methods are currently required in a jet-type for use withthe JetFinders package.


ConcreteJet(HepLorentzVector & aLorentzVector);double getEta();double getPhi();double getTheta();double getEnergy();double getMass();HepLorentzVector getLorentzVector(;void addConstituent(const JetableObject * aPart);

Here an example program snippet.

JetFinderCARFFacade<ConcreteJet> * aFacade =new JetFinderCARFFacade<ConcreteJet>();

VJetAlgorithm<ConcreteJet> * anAlgo;anAlgo = new IterativeConeAlgorithm<ConcreteJet>;JetFinderDigiInput * anInput = new JetFinderDigiInput;aFacade->setAlgorithm(anAlgo);aFacade->setInputGenerator(anInput);addDefault(aFacade);

9.7 Conclusions

One of the goals of this note is the demonstration of physics object reconstruction using object orientedprogramming, and the exploration of this new technology in this context.

This was done by achieving decoupling of algorithms, jet types, and analysis, so the CMS jet-finders canbe used in different contexts without duplication of basic functionality, and without dependence on data-structures that are outside the scope of jet reconstruction. OO techniques have been explored and exercisedto provide a variety of jet-finding algorithms and input generators.

The basic concepts inherent to the C++ language employed to achieve decoupling of algorithms, outputfunctionality, and analysis are:

• Function overloading, to allow for a variety of inputs, and to decouple the algorithms from theirinputs.

• Polymorphism, to allow user defined input generators and filters that are switchable at run-time, asto make the algorithms independent from data structures outside the scope of jet-finding.

• Generic programming to allow for decoupling of the algorithms from the functionality of a concreteJet-type necessary for a given analysis.

Note that none of the above techniques are available in procedural languages like C or FORTRAN.

A brief field-test in the context of the higher level trigger studies and τ reconstruction showed that thebuilt-in flexibility is sufficient to allow re-use of the package in the different contexts. The prove of conceptof physics object reconstruction in the context of the reconstruction of hadronic final states was successful.

9.7.C

ON

CL

USIO

NS

95

ConcreteJet

JetType

DummyJetAlgorithm

JetType

IterativeConeAlgorithm

JetFinderCaloTowerInput

JetFinderClusterInput

JetFinderDigiInput

JetFinderGeneratorInput

JetFinderTrackInput

JetableObject

JetableObject(aCell : const Cell&) : JetableObjectJetableObject(aTrack : TTrack&) : JetableObjectJetableObject(aTower : const CaloTower&) : JetableObjectJetableObject(aDigi : const CaloDigi&) : JetableObjectJetableObject(aParticle : const RawRecParticle&) : JetableObjectJetableObject(aCluster : const CaloCluster&) : JetableObjectJetableObject(aTrack : const Track&) : JetableObjectJetableObject(aVJet : const VJet&) : JetableObjectJetableObject(aStub : const JetFinderInputStub*) : JetableObjectgetEta() : doublegetPhi() : doublegetTheta() : doublegetEnergy() : doublegetTransverseEnergy() : doubleisUsed() : intuse() : voidreUse() : void

JetType

ARCLUSAlgorithm

JetType

CambridgeAlgorithm

JetType

HadronHadronK_T_Algorithm

JetType

SuccessiveCombinationJetAlgo

VJetFinderInputGenerator

prepareInput()

JetType

JetFinderCARFFacade

reconstruct()addInput()setAlgorithm()setInputGenerator()dump()myUpdate()amValid()

0..1

1

0..1

1

JetType

VJetAlgorithm

findJets()

JetType

JetFinder

setAlgorithm()addInput()findJets()

VJet

getEta()getPhi()getTheta()getEnergy()getMass()getLorentzVector()addConstituent()

JetType

JetCollection

addJet()getJets()

example

Figure9.1:

Baseline

designof

thejetfinder

package.Fam

ework,basic

algorithm,and

inputgeneratorclasses

areshow

n.Detailed

designsare

omitted

forbetter

readability.

Chapter 10

TrackerReco

10.1 Track reconstruction

10.2 Pixel Reconstruction

10.2.1 Introduction

This software reconstructs tracks and vertex candidates using 3 hits (per track) provided by the pixel detec-tor. It has been explained in detail in the CMS Internal Note 2000/22, here only the most important detailswill be given. The pixel reconstruction works also with 2 pixel hits per track. In this case the number ofghosts will be higher and the precision of the pT estimate will be poorer.The software is contained in the ORCA sub-packageTrackerReco/PixelReconstruction.

10.2.2 Algorithm

Pixel hit pairs from the first two layers (barrel+barrel or barrel+endcap) are matched in r − φ and z − r toestablish track candidates. The cuts are optimized for a minimum track pT (typically 1 GeV) and permit amaximum impact parameter in r − φ (default value is 1 mm). In the z − r place the hit pairs have to pointto a region in z within 3σ (+/- 15 cm) of the LHC luminous region. Valid pixel pairs are matched with a 3rd

pixel hit, which can be either in the 3rd barrel layer or in one of the endcap disks, forming a track candidate.Using these tracks a list of primary vertices (PV) is formed at z values where at least N tracks (typically setto 3) cross the z axis. Tracks which do not point to any PV candidate are erased.

Due to the detector overlaps in the r − φ direction for some Monte Carlo tracks more than one trackcandidate is found. To reduce this effect track pairs which share pixel hits and are closer than 10 mradsfrom each other are identified. A cleaning procedure then erases one of the tracks in each pair.

The primary vertex candidates found during the track finding stage are reanalyzed. Only PVs with atleast N valid tracks (default = 3) are kept and the position of each vertex is estimated as the mean value of thez impact parameters of all tracks assigned to it. In addition to the main (“signal”) PV, 6 more PVs per eventare found, on the average, at high luminosity. The list of found PVs is searched for the most likely signalevent PV, the criteria being the number of tracks above 1 GeV and the sum of pT . The chosen “signal” PVis always returned as the 1st on the list. It can usually be found with a very high accuracy of about 50 µm.

97

98 CHAPTER 10. TRACKERRECO

10.2.3 The Main Class PixelReconstruction

Description

The reconstruction algorithm is in the PixelReconstruction class. This class obtains reconstructedpixel hits from ORCA, performs the reconstruction (using 2 or 3 hits) and provides the results.

To use this class one needs to include the PixelReconstruction.hfile.An example how to use the class is shown in PixelRecoTest.cpp.

The Constructor and the doIt() Method

The PixelReconstruction class is initialized with the constructor below, the default values of all parametersare also shown.

PixelReconstruction(bool vertexConstraint = true,bool vertexFit = true,bool calculatePtAndImpacts = true,bool overlapFlag = true,bool twoHitRecovery = false,bool doRecHitCleaning = false,int pixelLayout = 0);

Where the parameters are :

• vertexConstraint, if false no PV constraint will be used to clean the track candidates;

• vertexFit, if false the PVs found in the tracks finding step will not be reanalyzed to obtain a betterposition;

• calculatePtAndImpacts, if false the pT and impact parameters of the reconstructed track can-didates will not be calculated;

• overlapFlag, if false there will be no cleaning of close tracks which share hit, this might be usefulif maximum efficiency is required but track purity is not important;

• twoHitRecovery, if true then tracks with less than 3 pixel hits will be recovered, this increases thetrack finding efficiency but also generates many ghost tracks (especially at high luminosity);

• doRecHitCleaning, if true then an attempt will be made to clean recHits generated by the sametrack in the same detector layer (due to detector overlaps), it will reduce the number of multiple trackcandidates but also reduce the track finding efficiency;

• pixelLayout, the pixel detector configuration, the default configuration = 0 includes 3 pixel layersand 2 endcap disks. One can use the predefined values for this parameter THREE HIT RECO orTWO HIT RECO, they are included in PixelRecoParameters.h. One can also specify the exactconfiguration e.g. 761 for 3 layers or 61 for 2 layers. The full list of possible options is listed inPixelReconstruction.h.

A default constructor PixelReconstruction() with no arguments is also provided.

The algorithm is actually executed by the following method.

10.2. PIXEL RECONSTRUCTION 99

int status = pixelReconstruction.doIt(const double ptcut = 1.0,const double z0cut = 0.15);

Where the parameters are :

• ptcut, the minimum pt value of the reconstructed tracks in GeV, the default is 1 GeV;

• z0cut, the maximum distance in cm of the track’s z impact parameter from the reconstructed zposition of the primary vertex, the default is 0.15 cm;

The return status = 0 signals successful completition.

Accessing the Results

The PixelReconstruction class gives access to two containers. The 1st one contains all reconstructed vertices:

const map<int, PixelVertex, less<int> >& vertex =pixelReconstruction.getVertices(); //Get the vertex list

Iterating over the vertex map gives access to the PixelVertex elements (defined in PixelVertex.h), e.g.

// PV z positiondouble z = (idVertex->second).getPosition().z();// Number of tracks assigned to the PVint i2 = (idVertex->second).getTracks();// Number of tracks actually used in fit of the z positionint i1 = (idVertex->second).getTracksUsed();// Summed pt of all tracks assigned to the vertexfloat sumPt = (idVertex->second).getPt();// The magnitude of summed momentum of all tracks assigned.double sumP = (idVertex->second).getPmom().mag();

One also has access to a vector with the pointers to the tracks assigned to this vertex :

// Get tracks associated with this vertex.const vector<PixelLine*> lineIndex =

(idVertex->second).getTracksIndex();

The 1st vertex in the container is the one assigned to the “signal”.

The 2nd container is the list of all reconstructed tracks. It is accessed with :

const vector<PixelLine *>&line = pixelReconstruction.getLines();

The PixelLine elements (defined in PixelLine.h) give access to various reconstructed parameters of thetracks, e.g.


// Reconstructed ptfloat pt = (*viter)->getPt();// Reconstructed phifloat phi = (*viter)->getPhi();// Reconstructed etafloat eta = (*viter)->getEta();// Reconstructed chargefloat charge = (*viter)->getCharge();// Id of the PVint vtxId = (*viter)->getVertexId();// Access ORCA hitsRecHit ptr1 = (*viter)->get_hit1_id()->recHit(); //layer1RecHit ptr2 = (*viter)->get_hit2_id()->recHit(); //layer2

Internals

Inside the PixelReconstruction three classes are used :

• PixelDetsContainer - handles reconstructed pixel hits;

• PixelLineContainer - handles reconstructed track candidates;

• PixelVertexContainer - handles reconstructed vertex candidates;

The processing (done in doIt()) is split into several steps which can be disabled and enabled independently,e.g. by setting the input arguments in the PixelReconstruction constructor.

10.2.4 User classes

A number of interface user classes have been added in order to simplify the access to the pixel reconstructionobjects.

Primary Vertex Generation

A list of all reconstructed PVs can be obtained through the standard ORCA vertex interface (defined in theVertex/PrimaryVertexFromPixelHits subpackage). The PrimaryVertexSeedGeneratorFromPixelRHitsclass provides primary vertices using data from the pixel detectors only. It is meant for fast primary vertexfinding and trigger studies.The primary vertices are obtained from the

// Define the pixel PV interfacePrimaryVertexSeedGeneratorFromPixelRHits aPVSGFPR;//Create// Declare an empty track containervector<const RecTrack *> dummyTracks; //Dummy input tracks// Get the PVsvector<RecVertex> vertex = aPVSGFPR.vertices(dummyTracks);

with an empty track container dummyTracks.The description how to use this class can be found in the Vertex/PrimaryVertexFromPixelHitsdoc-umentation.

10.2. PIXEL RECONSTRUCTION 101

To use this class one needs to include theVertex/PrimaryVertexFromPixelHits/interface/PrimaryVertexSeedGeneratorFromPixelRHits.h.An example showing how to use that object is given inVertex/PrimaryVertexFromPixelHits/test/PixelPVTest.cpp.

Track Seed Generation

The pixel reconstruction can be used to generator track seeds used later in the full track finding. To obtaintrack seeds from the pixel reconstruction one needs :

PixelSeedGenerator psg( const bool vertexConstraint = true,const bool overlapFlag = true,const bool twoHitRecovery = false,const int pixelLayout = 0,const double ptcut = 1.0,const double z0cut = 0.15)

SeedGenerator::SeedContainer seeds = psg.seeds(); // Get seeds.

In this case all pixel reconstruction is hidden inside the seeds() method. The meaning of the input argumentsis like in the main class. The user does not get access to the reconstructed track or vertex candidates.To use this class one needs to include the interface/PixelSeedGenerator.hfile.An example how to use the class is in PixelSeedTest.cpp.

Track Seed Filter

Another option is to generate the track seeds externally and use the PV information to filter the valid seeds.Only track seeds which point to a PV candidate are passed. This class is called PixelSeedCleaner andits use is shown below:

SeedGenerator* mySeedGenerator = // Standard seed generatornew CombinatorialSeedGeneratorFromPixel( 0.8, 0.1, 15.);

PixelSeedCleaner* mySeedCleaner = // Pixel Seed Cleanernew PixelSeedCleaner(SeedGenerator* mySeedGenerator,

const double maxZImp,const int numOfVtx,const int pixelLayout=0);

// Test seedsconst SeedGenerator::SeedContainer goodSeeds =

mySeedCleaner->seeds();

One needs an external track seed generator, in this caseCombinatorialSeedGeneratorFromPixel.The PixelSeedCleaner passes only seeds which are within a certain distance maxZImp (default = 1mm)from the first numOfVtx PVs (0, all by default). Setting numOfVtx=1 makes only the seeds associated withthe “signal” PV valid, numOfVtx=0 includes seeds from all PVs. Again in this case the whole pixel recon-struction is done internally in the seeds() method.

To use this class one needs to include the interface/PixelSeedCleaner.h.An example how to use the class is included in CleanSeedsTest.cpp.


Selective Seed Generation

In some cases one wants to create track seeds from a selected list of pixel track candidates (e.g. for tracksabove some pT cut or inside a selected cone).

PixelSelectiveSeeds pss(const vector<PixelLine*>* trackCandidates,const map<int, PixelVertex, less<int> >* vertexContainer);

or

PixelSelectiveSeeds pss(const vector<PixelLine*>* trackCandidates,const double zPositionPV);

SeedGenerator::SeedContainer seeds = pss.seeds(); // Get seeds.

In this case the pixel reconstruction is done externally to the PixelSelectiveSeeds class. The userpasses the address of the vertex container and the address of the container with the list of selected trackcandidates. The vertex information is needed because track seeds need the PV information. The vertexcontainer can be taken directly from the getVertex() method. As an alternative one can just specify the zposition of the primary vertex with the 2nd constructor.

To use this class one needs to include the interface/PixelSelectiveSeeds.h.An example how to use the class is included inPixelRecoTestWithSelectiveSeed.cpp.

Pixel Cone Trigger

This class can be used if one wants to use pixel reconstructed tracks for trigger selections (e.g. track isolationin a cone given by the calorimeter). The constructor is:

PixelConeTrigger(const int layoutFlag = 0,const double ptcut = PT_MIN,const double z0cut= MAX_Z_OFFSET);

There are many methods available, please look inside the class to see all off them. One can define the isolationcone, ask for track candidates inside the cone, check triggering conditions and generate track seeds fromthe accepted track candidates.To use this class one needs to include the interface/PixelConeTrigger.h.An example how to use the class is included inPixelConeTrigerTest.cpp.

10.2.5 Parameters

All parameters used in the reconstruction are stored in the include filePixelRecoParameters.h. Many of these parameters are for test purpose only and should not be modi-fied. Others can be modified if needed.

10.3. TRACKER ALIGNMENT TOOLS IN ORCA 103

10.3 Tracker Alignment Tools in ORCA

10.3.1 Introduction

This manual is intended to describe the motivation and the implementation of the Alignment Tools for theCMS tracker. In the ideal case (no energy loss, no errors in the cluster reconstruction), all hits in the CMStracker will lie on a perfect helix. In the real CMS tracker however, the position of the modules and hencethe position of the reconstructed hits will not be known exactly. Such a misalignment of CMS tracker willresult in reconstructed hits that are not on the perfect helix of the tracks (even if we think of a case wherethere is no ”error” in the cluster reconstruction of multiple scattering of the particles), simply because thecoordinates that are assigned to the hits are wrong. This situation can easily be simulated by simulatingevents with a perfect geometry. The misalignment of CMS can then be introduced afterwards by displacingthe DetUnits which host the reconstructed hits while leaving the local hits in place. The only effect that isnot simulated by this procedure is related to hits at the boundary of detector modules. If a misplacementwould have caused a hit to be generated in an adjacent module rather than the one that got hit in the caseof the ideal geometry, this is not simulated. This however should be a second order effect, only.

Hence for studying effects on misalignment or testing alignment algorithms, for a start we don’t need togenerate events with a distorted CMSIM/OSCAR geometry, but simply apply the distortions afterwards.

This functionality is provided by the Alignment Tools described in this ”manual”. These Alignment Toolsalso allow for the implementation of more complicated distortions of the geometry compared to what willbe achievable by the CMS geometry description. In this geometry description the Geant-volumes probablywill be typical geometric elements that can be misplaced. However it is questionable whether any intrinsicdistortions for example of Discs or Rods will be implemented at this level. In this case the Alignment Tools(or something similar) are the only straightforward way of simulating this kind of displacements. Once themisalignment of the detector is determined, the same tools can also be used at the time of reconstruction ofthe CMS data to correct for the displacement.

In figure10.1 the situation of a misaligned detector is sketched in order to clarify the situation of howthe Alignment Tools work.

a) shows a perfect detector with a track and its hits

b) shows the situation with a misaligned detector if the same track is passing as in a). The hit in themisaligned outer layer has a different local position compared to a), but the same global position.

c) shows the situation how this situation is simulated using an event generated with perfect geometry asin (a), but the assumed position of the module is change afterwards for the reconstruction of the trackusing the Alignment Tools. Note that the hit in the outer layer has the same local position as in a) buta different global one. The actual reconstructed track is the same as in (d)

d) shows how the track in (b) is reconstructed if the misalignment in (b) is unknown and perfect geome-try is assumed for the detector. The situation of the reconstruction is the same as for the simulation ofmisalignment shown in (c). Note that in this case the hit in the outer layer has the same local positionas in b) but a different global position.

Note in addition, that a real misaligned detector ( b) ) with i.e. a shift in negative x-direction is simu-lated by a positive shift using the Alignment Tools. But any alignment procedure should find out byanalysing situation c) or d) that the real position of the outer layer is given by the negative shift shownin (b).


a) b)

c) d)

Figure 10.1: The figure illustrates the effects of misalignment on hits that are generated (a) with perfect geometry,and (b) using a distorted geometry. Figure (d) shows how the reconstruction is performed if the misalignment in (b)is not taken into accound and (c) shows how this can be simulated using events generated with perfect geometry.A more detailed description is given in the text.

10.3.2 Layout of Alignment Tools

It is supposed that every type of misplacement that will be encountered within CMS will be related tothe physical structures that are actually build. Hence misalignment is introduced at various hierarchicallevels, like for example at the level of misplacing1 the whole forward endcap or just one rod or detectormodule in the outer barrel. Such hierarchical structure allows for correlated movements of all groupeddetector modules. This allows for a more realistic simulation of a possible misalignment of the detector aswell as it minimises the necessary parameters which need to be adjusted within an alignment procedure2.Furthermore correlated movements between the modules due to sag of barrel rods for example can beimplemented at various levels of the hierarchy.

This hierarchical structure is organised in the following parts (see also figure10.2):

• Tracker: The Tracker is decomposed into various parts, which currently are envisaged to be theinner/outer barrels and the barrel pixels, the endcap, mini endcap and pixels. So far the inner andouter barrel part is implemented and the whole endcap structure. Only the barrel pixel parts aremissing at the moment. The outer and inner barrel are each separated into two halfs, forward and

1 Misplacement here refers the various kind of misplacements like global movements, rotations or torsions of a barrel for example.2At least for the first iterations of large scale structures. In a final step, one will of course also align every single detector module, however

the size of the displacements of single detector modules within its host structure will be much smaller than possible displacements of the largescale structures.


backward (+ and − z, respectively). All three endcap parts are naturally divided into forward andbackward according to + and − z.

• Barrel structure:

– HalfBarrels: The half barrels, although made out of two discs, connected by several layers ofrods, are firstly divided in their various layers.

– BarrelLayers: The various layers (6 in the outer and 4 in the inner barrel) of the half barrels arecomposed of all the rods within this layer:

– Rods: The rod is a collection of detector modules (DetUnits).


AlignableHalfBarrel

AlignableBarrelLayer

AlignableRod

AlignableTracker

AlignableEndcap

AlignableEndcapLayer

AlignableWedge

AlignableDetUnit

AlignableDet

AlignableRodBuilderAlignablePetalBuilder

AlignableTurbineBuilder

− Endcap

− MiniDisks− inner Barrel

− outer Barrel

− PixelEndcap

Figure 10.2: Sketch of the hierarchical structure of the Alignment Tools

• Endcap structure:

– Endcaps: The endcap parts contain the associated discs which are called layers inside the Align-ment Tools. Depending on the part (endcap, mini endcap, pixel endcap) the number of layersvaries (9,3,2(3?)).

– EndcapLayers: The layers are build out of wedges, which are either 16 petal-like structures(endcap, mini endcap) or 24 blade-like topologies which are turbine-like oriented (pixel endcap).

– Wedges: A wedge is a collection of its corresponding DetUnits.

• Dets: The dets host either two DetUnits for glued stereo modules or simply one DetUnit for singlesided layers.

• DetUnits: The lowest level are the DetUnits, which correspond to the SI-detector modules.

Implementation

The Alignment Tools are implemented in ORCA. This allows one to use them together with the reconstruc-tion algorithm, providing a possibility of testing the effects of misalignment on our reconstruction and thephysics results. Any alignment algorithm will use tracks or the laser beams from the position monitoringsystem which both give signals in the SI-detector modules of the Tracker. The signals/hits are also recon-structed within ORCA. Exactly these reconstructed hits are manipulated by moving the corresponding de-tector units by means of the Alignment Tools. Furthermore once the alignment parameters are determined,the same tools can be used for the final reconstruction of the events within ORCA.


There are two packages:

• CommonReco/DetAlignment: This directory hosts the general purpose classes that need not necessar-ily be limited to the tracker. Here the general interfaces for any “Alignable” object are defined. Alsothe way things are grouped to collections of “Alignable” objects, so called “AlignableComposites”which in turn again are of the type “Alignable”, is defined. If this whole concept is pursued further,also the other detector components could use these interfaces.

– Alignable

– AlignableComposite

– AlignableDet (This is a special AlignableComposite consisting of AlignableDetUnits) They areused to treat GluedDets (stereo layers) in an equivalent way like single sided DetLayers by simplyaddressing them as AlignableDets. In its constructor, it looks for the DetUnits (1 or 2) that itscorresponding Det consists of instantiates the corresponding AlignableDetUnits. )

– AlignableDetUnit

• TrackerReco/TkAlignment: Here the tracker specific implementations of the various structures arefound. At the highest level the

– AlignableTracker.

The barrel section with:

– AlignableHalfBarrel,

– AlignableBarrelLayer,

– AlignableRod.

The endcap partition with:

– AlignableEndcap,

– AlignableEndcapLayer,

– AlignableWedge.

Classes for grouping the Dets into rods, petals or blades of the corresponding layer:

– AlignableRodBuilder (inner and outer barrel),

– AlignablePetalBuilder (endcap and mini disks),

– AlignableTurbineBuilder (pixel endcap).

And finally a test program which shows users how to use the Alignment Tools:

– AlignableModTracker to perform random misplacements/rotations on collections of Alignableobjects and

– RamdomMisalign in the test directory, with the track reconstruction.

All of these composite structures, as well as the AlignableDetUnit as a starting point, are of the type“Alignable” as they all inherited from it. Every Alignable object of course has a position and an orientation(its local coordinate system) which is changed in the process of (mis)aligning. To every “Alignable” object apossible movement and rotation can be applied and it stores the sum of all displacements and rotations thatit has been subjected to. The detailed description of these methods/quantities is given below.


The starting point for building composite structures within the Tracker is the detector unit, called DetU-nit in ORCA3. The DetUnit class itself in ORCA provides already a lot of functionality that is not needed foralignment purposes. New “move” and “rotate” methods are introduced for the DetUnits, however they arenot accessible from outside the DetUnit itself as they are “private”. This is done in order to prevent anyonedealing with DetUnits to “accidentally” change its position and orientation. For the alignment purposes,the AlignableDetUnit is introduced. This is basically a pointer to a DetUnit and it is the only class whichis actually allowed to use the “move” and “rotate” methods on the coordinate frame of the DetUnit. Thetotal sum the displacements of the DetUnit is stored in the AlignableDetUnit. The access methods for theposition or orientation of the AlignableDetUnit simply forward the call to the corresponding quantities ofthe DetUnit. No additional copy of these quantities are stored anywhere, but everything is related to the“original” DetUnit in ORCA.

All elements but the basic AlignableDetUnit are composite elements. The general AlignableCompositeclass defines how rotations, movements of composite objects are performed. The DetUnit stores its positionand orientation, which is used also for the track reconstruction, in global CMS coordinates. Hence every-thing is always related to global coordinates. Because the global position and orientation of a componentchange when a composite structure is moved or rotated, the composite takes care of applying the relevantmovements and rotations to the components. It also provides a method of moving the components w.r.t. thelocal frame of the composite. This method is provided because presumably survey data that e.g. give thedisplacements from the nominal positions of detector module within a rod, will be given in local coordinates.The composite also provides the actual implementation of the method to access the position and orientationfor composites.

Access to the different components

Each composite provides a method of accessing its components (components()) and in addition to this gen-eral method, each particular composite, like, e.g. the AlignableHalfBarrel has an additional method e.g.layer(i) which just returns the i-th AlignableBarrelLayer (start counting from zero) of the AlignableHalf-Barrel.

outerHalfBarrel(int i ) to access the i-th outer half-barrel from the AlignableTracker

layer(int i) to access the i-th layer from the AlignableHalfBarrel

rod( int i) to access the i-th rod from the AlignableBarrelLayer

det(int i) to access the i-th DetUnit from the AlignableRod

detUnit(int i) to access the i-th DetUnit from the AlignableDet, which is a GluedDet (stereo layer) or ajust simply 1 DetUnit.

Similar methods are implemented for the inner barrel:

innerHalfBarrel(int i ) to access the i-th inner half-barrel

layer(int i), rod( int i), detUnit(int i) as defined above.

and for the endcap:

endCap(int i ) to access the i-th endcap from the AlignableTracker

layer(int i) to access the i-th layer from the AlignableEndcap3If the same package would be used for other parts of the detector, additional seeds for building composite structures could be introduced.


wedge( int i) to access the i-th wedge from the AlignableEndcapLayer

det(int i) to access the i-th DetUnit from the AlignableWedge

detUnit(int i) to access the i-th DetUnit from the AlignableDet, which is a GluedDet (stereo layer) or ajust simply 1 DetUnit.

For the moment the sequence of the AlignableTracker components are as follows:0: forward inner barrel 1: backward inner barrel 2: forward outer barrel 3: backward outer barrel4: forward endcap 5: backward endcap 6: forward mini endcap (mini disks) 7: backward mini endcap(mini disks) 8: forward pixel endcap 9: backward pixel endcap.

Attention: A component does not “know” if it is e.g. forward inner barrel or backward mini endcap, butit has access to its substructure.

Especially for testing purposes of misalignment it is convenient to have access to various collections ofalignable elements. This is given by the following methods accessable from the AlignableTracker:

barrelDets(), which returns all inner and outer barrel Dets

innerBarrelDets(), which returns all inner barrel Dets, and similary:

outerBarrelDets(), endcapDets(), miniEndcapDets(), pixelEndcapDets(), barrelRods(), innerBarrel-Rods(), outerBarrelRods(), endcapWedges(), miniEndcapWedges(), pixelEndcapWedges(), barrelLay-ers(), innerBarrelLayers(), outerBarrelLayers(), endcapLayers(), miniEndcapLayers(), pixelEndcapLay-ers()

Functionality

At present, apart from twist methods for the barrel, only the “trivial” movements, rotations are imple-mented. Individual distortions of particular composites, like for example a twist or sag of a rod is not yetprovided. These kind of movements can be added one by one to the existing composite structures.

The methods that characterise an align-able object completely and which every “Alignable” objects hasto provide are the following:

• surface which returns the “surface” (position and orientation) according to the definition of a “sur-face” in ORCA. These are the position and orientation w.r.t. the global CMS coordinate system

• globalPosition and globalRotation which for convenience directly return the position and orientationof the object. (This is equivalent to accessing these quantities via the surface, using surface().position()or surface().rotation(), respectively)

• displacement which returns the total displacement to which the object has been subjected to in globalcoordinates.

• rotation which returns the total rotation to which the object has been subjected to in global referenceframe.

• move(GlobalVector v) which allows to move the element in global coordinates by the vector v

• rotateInGlobalFrame(Rotation m) which allows to rotate the element around it’s own centre by therotation matrix m. The orientation of the rotation axis given in global coordinates (see also figure10.3for an example)


zx

y

x

y

z

global

global

global

local

local

local

DetUnit

Rod and its local frame

φ

global CMS frame

Figure 10.3: The figure shows a rod and the local coordinate frame attached to it. The rotation methods rotatethe rod always around its own centre. The orientation of the rotation axis may be specified either w.r.t. the localframe (rotateInLocalFrame) or the global CMS reference frame (rotateInGlobalFrame). For the specific situationdepicted in the figure, rotateAroundLocalY would be equal to rotateAroundGlobalZ, as the orientation of the localy-axis of the Rod is parallel to the CMS z-axis.

• set-/addAlignmentPositionError which allows to set and additional uncertainty in the assumed RecHitpositions due to misalignment (see section 10.3.5).

• addAlignmentPositionErrorFrom(Local)Rotation which allows to add the corrsponding errors for re-sulting from misalignment due to rotations.

For convenience, there are also various other methods that allow to rotate the object with respect to it’s localframe and also methods where the rotation is not given by the complete rotation-matrix but rather an axisand a rotation angle phi.

• rotateInLocalFrame(Rotation m) which allows to rotate the element in it’s local coordinate system

• rotateAroundGlobalAxis(GlobalVector v, phi) v is the vector indicating the orientation of the rotationaxis interpreted in global coordinates.

• rotateAroundLocalAxis(LocalVector v, phi) v is the vector indicating the orientation of the rotationaxis interpreted in local coordinates.

• rotateAroundGlobalX(phi)

• rotateAroundGlobalY(phi)

• rotateAroundGlobalZ(phi)

• rotateAroundLocalX(phi)

• rotateAroundLocalY(phi)

• rotateAroundLocalZ(phi)


• the printout operator<<

We chose to store for each object the position in global CMS coordinates. The corresponding localposition of a component within a composite is then simply calculated from both their global position andorientation of their local reference frames. Doing this, every composite needs to know it’s components(which it naturally does) whereas the components don’t need to refer back to any higher level structure.This implementation has advantages w.r.t. storing only local positions of components within their hoststructures because at present within ORCA, every detector module (DetUnit) already has a position inglobal coordinates attached to it, which is used for the track reconstruction. It is exactly this positionwhich is manipulated with the Alignment Tools and no second copy of the DetUnit position in some othercoordinate frame is stored anywhere. This treatment of calculating the local position always “on the fly”when needed has then the advantage that one doesn’t need to take care of “updating” the global positionsonce local positions might have changed. If “gP” is the global position of a component from a compositestructure C, the local positions are simply obtained via C.surface().toLocal(gP);

The actual implementation of the rotations are such, that they are always interpreted in the global frame.When working the way down the hierarchy in rotating the composites and its components, one always hasto apply the ”same” rotations. However, if the rotations were always interpreted in the LOCAL frame,the actual rotation matrix would have to be transformed into each individual LOCAL frame. In order toprevent this complication everything is related to (the orientation of ) the global coordinates. However thecentre of the rotation is always taken as the centre of the composite or respective component as also indicatedin figure10.3.

10.3.3 Construction

Currently the detector description which is read by the simulation OSCAR/CMSIM, which already containsphysical structures like barrel-rods or endcap-petals in some format, is not transparent for ORCA. This willchange in the future, when a common detector description is developed. At the moment only the positionsof the DetUnits are know in ORCA, none of the other physical structures are defined. Hence the Rods(Wedges), BarrelLayers (EndcapLayers), HalfBarrels(Endcaps) first need to be constructed by groupingthe corresponding DetUnits. This procedure will probably be changed when the common detector descrip-tion is available. Then it will also be much simpler to choose the proper centre of the composites, whichshould be at the position where the most constraint point of the quasi-isostatic mount is located. Definingthe rotations around these centres, will minimise the number of parameters needed to describe the mostprobably distortions. In the meantime the centre is simply chosen as follows:

• The centre of the AlignableRod (AlignableWedge) is at the mean position of the corresponding DetU-nits. The orientation is computed such, that the z-axis points along the r-phi direction, y-axis alongthe global z direction and the x-axis is oriented such that you get a right handed coordinate system.After construction the centre remains of course unchanged when the DetUnits are subjected to localrotations or displacements(e.g. no new average position is calculated).

• The AlignableHalfBarrel (AlignableEndcap) and AlignableBarrelLayer (AlignableEndcapLayer) havethe orientation just like the global frame and the origin at the average z-position of the componentsBarrelLayers (EndcapLayers) and Rods (Wedges), respectively (x=y=0).

• The AlignableTracker just uses the original global frame, as its initial local reference system.

The construction of the “Alignable” elements is performed by instantiating an AlignableTracker. In theconstructor of the AlignableTracker, the constructors for the inner half barrels, for the outer half barrelsand the three different types of endcaps are called. They in turn ask for the layers to be constructed which


form the half barrels or endcaps. DetUnits are grouped already into DetLayers within ORCA. Therefore,the constructor for the AlignableBarrelLayer (AlignableEndcapLayer) gets the ORCA DetLayer (Forward-DetLayer) as an argument. The DetUnits in this DetLayer (ForwardDetLayer) are then grouped into thevarious rods (wedges) by the “AlignableRodBuilder” (“AlignablePetalBuilder” and “AlignableTurbineB-uilder”). The Builder gives back a vector of a vector of DetUnits (DetUnit pointers) corresponding to a set ofrods (wedges), each consisting of a set of DetUnits. From this output the AlignableRods (AlignableWedges)are created and then put into the AlignableBarrelLayer (AlignableEndcapLayer).

The AlignableTurbineBuilder class is special, as it uses the already existing classes TurbineForwardDet-Layer and DetBlade. For the track reconstruction the turbine-like structure of the pixel endcap has alreadybeen build and inside AlignableTurbineBuilder this structure is just forwarded.


RecHit

misalignment

TrackRecHit error + uncertainty of module position

Figure 10.4: The figure shows the situation of a track fit with and without a misaligned detector. In order to treatcorrectly the errors of the RecHit in case of the misaligned detector module, the displacement has to be taken intoaccount in the assumed global position of the hit.

10.3.4 Testing

In the TrackerReco/TkAlignment/test directory there is an ”example” job called RandomMisalign. Thereare several different switches one can set in .orcarc which perform simple default tests or random mis-alignemts of detunits usable for studies of efficiency and fake-rate of the track reconstruction in the presenceof misalignment.

For example the setting:RandomMisalign:distort = 1RandomMisalign:rotatePhi = 0.0001will run a job which rotates the barrel layers. The first one is rotated by 0.0001 rad, the second by 2*0.0001and so on. This results in positively charged tracks to become less bended and hence being measured withhigher momentum. This can be observed when comparing the reconstructed momenta in the hbook ntuplefrom two jobs run with and without the distortion.

10.3.5 AlignmentPositionError

If the Tracker gets misaligned, the assumed error on the reconstructed hits need to be assumed largerthan the errors from the local hits on the module as sketched in figure reffig:ape. The latter (or moreprecisely, the parametersErrors) are used currently in the track fitting procedure. The local errors withina detector module don’t change, but only the errors viewed in the global space and those used in the track-fit. Therefore each Det can be asked for its AlignmentPositionError (APE). This is an additional errormatrix which is added to the error matrix from the local RecHit reconstruction. Only diagonal elements areimplemented, no correlations are taken into account and it acts only on the 3-spatial coordinates. Rotationsare treated such, that on the DetUnit level, the average x,y,z displacement of the strips caused by a rotationis taken as error. Whenever GlobalErrors or ParametersErrors are asked for, it is checked whether anAlignmentPositionError is set and if so, it is added in quadrature. The AlignmentPositionError is onlyimplemented at the level of the DetUnits. Hence it has to be set individually and it cannot take into accountthe fact that once there is a misalignment of the whole Barrel, this in principle doesn’t affect the trackingpart which is just inside the this Barrel. For GluedDets in the stereo layers, the AlignmentPositionErroris simply taken from the first DetUnit, just like it’s done for the Surface. This gives a correct treatment aslong as GluedDets are always misaligned as a whole. The APE which is set for the second DetUnit is simply


ignored as it doesn’t affect the error on the position due to the misalignment in any other way as the firstone does. Only if one introduces misalignment on the both sides of the stereo-layer individually. However, ifboth of them were rotated by say 0.001mrad against each other, and this number would be used also for anadditional uncertainty in the APE, just as it could be done for all other components in the Tracker, then thisgives too large an error for the RecHit, because the parameters of the RecHit are first averaged from bothlayers and afterwards the APE is added. However in this case it should be divided by

√2. Apparently within

the hit matching procedure this doesn’t cause any problem. However, whether the Hit matching is affectedmaybe in a High luminosity environment when within the hit matching procedure also the total APE errorof the DetUnits are also added (as apparently it is done automatically) has NOT been tested yet.

10.4 TkRecHitValidation: Reconstructed Hit Validation

Two programs exist for checking the quality of reconstructed hits (RecHit), for example, during MonteCarlo production runs. These are:

• RecHitTest.cpp which performs those tests which can be done without reconstructing any tracks.

• TrackRecHitTest.cpp which performs tests after track reconstruction.

Note that the algorithms used for reconstructing hits are modified if they are associated with tracks, sothe reconstructed hits seen by these two programs will not be identical.

A full list of the .orcarc parameters associated with these programs can be found in TkRecHitValida-tion/test/.orcarc

10.4.1 RecHitTest.cpp

This program checks reconstructed hits, without using reconstructed track information.

It produces an hbook file “rechit.his” containing 11 histograms and an ntuple.

Output Histograms

These are for non-experts to check the Monte Carlo. They show S/N ratios (corrected to that expected forperpendicular tracks), position residuals/resolution, cluster finding inefficiency, fake cluster rates, clusterwidths, strip occupancies and (FED) zero suppression performance.

A simple check would just involve looking at histograms 3, 5, 7 and 9 which are profile histograms show-ing the mean values of the first four of these quantities as a function of detector module type (defined inTrackRecHitTest.cpp). These mean values show a relatively small dependence on detector type, which sim-plifies understanding if the Monte Carlo has “passed”. Furthermore, these histograms look almost identicalregardless of whether single muon or minimum bias events are used, so they could be used to check anyMonte Carlo.

Output Ntuple

Intended for more detailed understanding. The size of the ntuple can be limited by two .orcarc parameters,of which the simplest is RecHitTest:ntupleMaxEvents = 1000, which stops filling the ntuple after 1000 eventshave been read in. For each detector module, the following variables are plotted -

10.4. TKRECHITVALIDATION: RECONSTRUCTED HIT VALIDATION 115

• DETECTOR variables

– EVENT:I, PIXEL:L, BARREL:L, STEREO:L,

– LAYER[1,16]:I, (layer in barrel and disk in endcap, with seperate numbering scheme for pixel).

– DETTYPE[1,64]:I, (Wolfgang’s detector type code)

– R:R, PHI:R, Z:R, (detector position)

– NCHAN[1,65536]:I, (number of channels)

– THICK:R, (thickness)

– NOISE:R (rms noise in ADC counts)

• RecHit variables

– NREC[0,2047]:I, (no. of rechits)

– WIDTH(NREC)[1,1024]:I, (cluster width in strips)

– FAKE(NREC):L (.true. if not associated to a SimHit)

• SimHit + associated RecHit variables

– NMC[0,2047]:I, (no of simhits)

– PT(NMC):R, TOF(NMC):R, (Pt of SimTrack and time at which hit was produced. N.B. .orcarcparameters allows cuts on these).

– ANGLE2D(NMC):R, ANGLE3D(NMC):R, (crossing angle of track to silicon (i) projected intoplane perpendicular to strips (ii) in 3-d.)

– TRUEPOS(NMC):R, (strip or x-pixel at which the SimTrack hit the detector)

– ELOSS(NMC)[0,8191]:I, (true energy loss in ADC counts)

– PITCH(NMC):R, (local pitch)

– ERRMEASX(NMC):R, (RecHit - SimHit position in units of strip pitch)

– RESMEASX(NMC):R, (RecHit resolution in unit sof strip pitch)

– FOUND(NMC):L (.true. if reconstructed as RecHit)

10.4.2 TrackRecHitTest.cpp

This program checks reconstructed hits, without using reconstructed track information.

If the .orcarc parameter twoPixelLayerFilter = 1 it will ignore the innermost pixel layer (can be usedtogether with the detFilter from Michela). General comment: matched rechits are always treated as twosingle ones.

Output Ntuple “trackrechit.hbook”

• Blocks Recpars, Simpars, Hitstat

– Same as in TrackTest.

• Block Hits

– NRH .. #Rechits associated to simhits


– NSH .. #Simhits

– then one entry / simhit:

∗ part ... 0 = barrel, 1 = forward∗ module . 1 = pixel, 2 = SiStrips, 3 = MSGC∗ asso ... 0 = no / 1 = (≥ 1) associated rechit∗ stereo . 0 = mono side, 1 = stereo side∗ type ... integer corresponding to one detector type (see log file for ”added to map (id=xxx)”

lines)∗ shgr, shgphi, shgz ... global r, phi, z of simhit∗ shmx, shmy, shmz ... simhit coordinates in measurement frame∗ xpitch . local pitch∗ xclw ... #strips in cluster∗ lxres .. rechit - simhit in local x (local y fixed to simhit position)∗ lxerr .. error associated to lxres∗ mxres .. rechit - simhit in measurement x∗ mxerr .. error associated to mxres

You can get lots of plots using TrackRecHitTest.kumac: first open(chain) your histogram file(s), thencall macro cms121 or cms118 in TrackRecHitTest.kumac. You will get individual plots and then summaries.You can give one argument concerning the stereo sides: ’-’ = all, ’N’ = only mono, ’Y’ = only stereo. Recentlyonly ’N’ has been used, so everything else at your risk ...

Chapter 11

Electron and Photon Reconstruction

11.1 Introduction

The ElectronPhoton package implements algorithms and helper classes for reconstruction and analysis ofelectron and photon candidate objects.

117

118 CHAPTER 11. ELECTRON AND PHOTON RECONSTRUCTION

11.2 ElectronPhoton modular reconstruction and analysis

11.3 Calorimetric clustering and position reconstruction

11.3.1 Clustering algorithms

11.3.2 Position Reconstruction

11.4 Energy reconstruction and brem recovery

11.4.1 Brem recovery in barrel

11.4.2 Preshower clustering and energy corrections

11.4.3 Brem recovery in endcap

11.5 Candidate identification and selection

11.5.1 Electron identification

11.5.2 Photon identification

11.6 Analysis helpers and toolkit

Chapter 12

Examples

The purpose of this subsystem is to demonstrate how to work within the OO reconstruction framework.Special emphasis is put on examples for a possible user analysis program, in particular:

• how to access information from the tracker, the calorimeters or the muon system

• how to access particle information from MC generators or GEANT KINE particles

• how to write histograms or ntuples in HBOOK or in HTL

• how to find muons, electrons, photons, jets or other reconstructable objects

This list will be extended with increasing complexity of the framework. In addition a workspace for theuser is provided to make the compilation and linking of private programs as easy and straightforward aspossible.

12.1 Histograms, Ntuples and Tags

12.1.1 Saving Histograms and Ntuples with HBOOK

ORCA provides a set of utility classes for histogramming. Good old HBOOK histograms can be easilycreated and saved to file, but also their successors in the LHC++ packages, HTL histograms are supported(see Section ??). HBOOK column-wise Ntuples are available as well.

HBOOK histograms

The use of HBOOK histograms is in principle very straightforward. There are certain simplifications andcertain complications compared to their use in a FORTRAN program. The booking is done using theCHBookHisto constructor, the filling using the fill method. The familiar options are available. See theprogram ExHistograms.cpp and the introduction (Section 2.7) for a detailed explanation.

119

120 CHAPTER 12. EXAMPLES

HBOOK Ntuples

Within ORCA there are currently different classes to support HBOOK column-wise Ntuples. The older row-wise Ntuples are not supported. The word Ntuples in the following always refers to column-wise Ntuples.

The most advanced class is CHBook4CWNtuple. It allows to write as well as to read Ntuples. Its useis demonstrated in the programs ExNtuples2.cpp (writing) and ExDumpHepNtuple.cpp (reading).Both programs are described below. ExNtuples.cpp and ExNtupleAndHisto.cpp use the older andless powerful class CHBook4CWTuple.

Writing Ntuples To write data to an Ntuple several steps are needed. Firstly the Ntuple has to be defined,then for each entry the data has to be filled into some buffer variables and finally the contents of thesevariables is written to file.

Defining the Ntuple First the Ntuple name and ID are fixed when calling the constructor for a newNtuple. Then for each block in the Ntuple the book method is called. The arguments are the block nameand the block definition, both as character strings. It is very important to separate the different variables inthe block definition by spaces. Otherwise the syntax of the definition is the same as when booking an Ntuplein FORTRAN. Currently only up to 2-dimensional arrays are supported.

// create the NtuplenUser = NCWP(new CHBookCWNtuple("USERNTPL", 99));// define the blocks - always indicate the type (I or R).nUser->book("GENERAL" ,"IRUN:I, EVNT:I, EECAL:R");nUser->book("CLUSTERS",

"nclu[0,90]:I, ECLUS(nclu):R, PHICL(nclu):R:15:[0,6.5], ETACL(nclu):R");nUser->book("TRACKS" ,

"ntrk[0,100]:I, PTRAK(ntrk):R, PHITK(ntrk):R:15:[0,6.5], ETATK(ntrk):R");

The definition of the Ntuple has to be reflected by some private data members of the Ntuple class:

private:// these are accessible only via public methodsNCWP nUser;// the blocks to put into the Ntuple// GENERALint irun,ievent;float energyEcal;// CLUSTERSint ncl;float ECl[NCLMAX], PhiCl[NCLMAX], EtaCl[NCLMAX];// TRACKSint ntk;float PTk[NTKMAX], PhiTk[NTKMAX], EtaTk[NTKMAX];

These variables are used to buffer the data before writing it to file.

Filling the buffer variables As for the histograms the Ntuple class needs some public methods to fill the(private) buffer variables. These methods can also take care of the correct filling of arrays.

12.1. HISTOGRAMS, NTUPLES AND TAGS 121

Writing the buffer to file Finally, a fill method is used to save the contents of the buffer variables to file.

void UHB::fill() {int i;nUser->set("GENERAL","IRUN",irun);nUser->set("GENERAL","EVNT",ievent);nUser->set("GENERAL","EECAL",energyEcal);

nUser->set("CLUSTERS","nclu",ncl);for(i=0;i<ncl;i++) {

nUser->set("CLUSTERS","ECLUS",i, ECl[i]);nUser->set("CLUSTERS","PHICL",i, PhiCl[i]);nUser->set("CLUSTERS","ETACL",i, EtaCl[i]);

}

nUser->set("TRACKS","ntrk",ntk);for(i=0;i<ntk;i++) {

nUser->set("TRACKS","PTRAK",i,PTk[i]);nUser->set("TRACKS","PHITK",i,PhiTk[i]);nUser->set("TRACKS","ETATK",i,EtaTk[i]);

}

nUser->fill();}

Reading Ntuples The same class that is used to write Ntuples, has also methods to read Ntuple files.

Open the file The file handling is provided by the class CHBookFile:

CHBookFile hf;char filename[256] = "h_eemm.ntpl";// open the filehf.setFile(filename,20,0);if (!hf.isGood()) {

cerr << "Opening file " << filename << " failed." << endl;exit(2);

}

Initialising the Ntuple in memory Next the Ntuple is initialised. After creating an empty Ntuple, thedefinition is automatically read from the file. No matching representation as variables (like FORTRANcommon blocks) is needed.

auto_ptr<CHBookCWNtuple> HEPNtuple;int ntplID = 100;HEPNtuple = auto_ptr<CHBookCWNtuple>(new CHBookCWNtuple(ntplID));HEPNtuple->getdefinition(ntplID);


Getting the information Once the definition is read, the contents of the file can be retrieved using theget method. It needs the block and variable name. If arrays are accessed for each dimension an index hasto be provided.

cout << "Dumping event " << HEPNtuple->get("HEPEVT","NEVHEP")<< " of " << HEPNtuple->get("HEPEVT","NHEP") << " particles."<< endl;

for(int j=0; j<HEPNtuple->get("HEPEVT","NHEP") ; j++) {.....for(k=0; k<5; k++) {

cout << setw(8) << setprecision(2) << HEPNtuple->get("HEPEVT","PHEP",k,j);}

.....}

12.1.2 Generic Tags

Tags are small pieces of user event data stored in the database, with a link back to the original event. Thesetags are intended to be used for

• Fast event selection

• Ntuple replacement

Fast event selection is done by placing in the tags the data you’d be most likely to cut on. Then, you cancut events by only reading the tags, without reconstructing or fetching the data for the event.

These tags are based on the HepODBMS package, which is the ntuple format used by the Lizard plotter,so data in these tags can be plotted independent of ORCA.

Structure of the Generic Tags

The structure of the tag is defined in interface/L1CaloTagSchema.h. This file will be a base class of theclasses which read, write, and filter on tags. Its fields are TagAttributes and TagAttributeArrays, which can betemplated using the following data types:

• float

• double

• long

• short

• char

These TagAttributes and TagAttribute arrays are read and written using an ’=’ sign, as if they werenormal variables:

These tags have the following structure: Level 1 missing ET , missing ET phi, and sum ET .ET , φ, and η for the five highest-ET :L1 central Jet objects


L1 forward Jet objectsL1 tau candidatesL1 isolated EM objectsL1 non-isolated EM objects

Creating Level 1 Calorimetry Tags

The executable to create these tags is ExL1CaloTagWriter, and the code which fills the values can be foundin L1CaloTagWriter.cc.

Reading and Filtering on the Tags

The executable to create these tags is ExL1CaloTagAnalyzer, and the code which fills the values can befound in L1CaloTagAnalyzer.cc. The user can also apply a selection filter on the tag data using inter-face/L1CaloSelector.h.

Plotting the Tags Using Lizard

To start Lizard, simply type ’lizard’. Then, from the smiley-face prompt, you can read in the tag database:

:-) nt1=ntm.findNtuple("PDB_Tags:TriggerTags:L1CalorimetryTags"):-) nt1.listAttributes()Run signed long intEvent signed long intL1MET floatL1METphi floatL1SumET floatL1CentralJetET1 floatL1CentralJetET2 floatL1CentralJetET3 floatL1CentralJetET4 floatL1CentralJetET5 floatL1CentralJetEta1 floatL1CentralJetEta2 float....

and plot attributes:

:-) h1=cplot1D(nt1, "L1SumET", "L1SumET>20")

12.1.3 COBRA Tags

This subsection will describe how an analysis can be done using COBRA tags. As an example events ofa 300 GeV Higgs, decaying into e+e−µ+µ− is used. The tag will contain the reconstructed electrons andmuons of the event. It also contains the reconstructed invariant masses of the lepton pairs and the Higgs.The quantities are stored on reconstruction- and generator-level.


To create a tag, normally a lot of information is required. This means that one needs many libraries ofORCA. To plot the tags or to read them, only a very small subset of libraries is required. This makes theanalysis part much more lightweight. To allow this separation, the code to write and to read the tags needsto be separated into different libraries. Libraries correspond in ORCA to packages of subsystems, so a taganalysis is done in a subsystem of it’s own.

Creating a tag “subsystem”

A script to create a subsystem in an existing ORCA area is provided. As an argument it expects the name ofthe tag class that will be implemented. The creation of the subsystem is done with

installTag HZZeemm

The subsystem will contain five packages: HZZeemm where the tag class resides, WriteHZZeemm wherethe code used to analyse a dataset and write the tag resides, PlotHZZeemm the package to plot the tagquantities with Lizard, ReadHZZeemmment to read only the tags from the database and SelectHZZeemmthat can also access the full event.

Defining the tag class

Since the tag class will be made persistent its definition is done not in a header file but in a ddl1 file:HZZeemm/HZZeemm/interface/HZZeemm.ddl. From this file a header file will be generated and themodifications of schema of the federation will be done. The ddl-file is however almost identical to a regularC++ header file. In this example it looks like the following While the use of simple types and classes isas usual, the storage of a vector of objects needs some adoption. Here vector needs to be replaced bystdVArray. It is convenient to define public typedefs for the containers.

Adding the tag to the schema

After creating the ddl file the next step is to convert it create the header file from it and to make the tagclass known to the federation. Since this procedure modifies the schema of the federation it should alwaysbe done on a shallow copy. With a shallow copy you can go try again without loosing data if things go wrong.So

• Create a shallow copy (see section 2.9.1)

• Set the OO FD BOOT environment variable to the boot file of the shallow copy

• In the directory HZZeemm/HZZeemm/interface runmakeallddl. You may get some warnings that you can safely ignore. If you get error messages youshould fix the ddl file and try again.

When the script ended successfully, you will find the file HZZeemm.h in the local directory. Don’t everedit it. What you probably have to edit is the corresponding src file in HZZeemm/HZZeemm/src.

1Data Descriptsion Language


// should be first line#include "HZZeemm/HZZeemm/interface/LocalSchema.h"#include "Utilities/dbUtil/interface/stdVArray.h"#include<cmath>#include "GeneratorInterface/Particle/interface/RawParticle.h"#include<utility>

class HZZeemm : public ooObj {public:typedef stdVArray<RawParticle> ParContainer;typedef ParContainer::iterator ParIterator;typedef ParContainer::const_iterator ParConstIterator;typedef pair<ParConstIterator,ParConstIterator> ParRange;

// default constructor (needed...)HZZeemm(){}

void addMCElectron(const RawParticle& el);void addMCMuons(const RawParticle& mu);ParContainer & MCelectrons() { return MCelectrons_;}ParContainer & MCmuons() { return MCmuons_;}const ParContainer & MCelectrons() const { return MCelectrons_;}const ParContainer & MCmuons() const { return MCmuons_;}

void addRECElectron(const RawParticle& el);void addRECMuons(const RawParticle& mu);ParContainer & RECelectrons() { return RECelectrons_;}ParContainer & RECmuons() { return RECmuons_;}const ParContainer & RECelectrons() const { return RECelectrons_;}const ParContainer & RECmuons() const { return RECmuons_;}

void calcMasses();

float mZmMC() { return mZmMC_;}float mZeMC() { return mZeMC_;}float mHMC() { return mHMC_;}

float mZmREC() { return mZmREC_;}float mZeREC() { return mZeREC_;}float mHREC() { return mHREC_;}

private:ParContainer MCelectrons_;ParContainer MCmuons_;ParContainer RECelectrons_;ParContainer RECmuons_;float mZmMC_, mZeMC_, mHMC_;float mZmREC_, mZeREC_, mHREC_;

};// should be last line#include "HZZeemm/HZZeemm/interface/BlankSchema.h"

Figure 12.1: DDL file to define a tag class


Writing the tags

The next step after the definition of the tag and and upgrading of the schema is to loop over an event collec-tion and store the calculated tags in a database. The code for this is located in the packageHZZeemm/WriteHZZeemmin the class FillHZZeemm. This class contains the analysis code required. It has to inherit from theUserTag class and can optionally inherit from the normal Observer classes. Due to the inherintancefrom UserTag two methods are required:

virtual bool filter(G3EventProxy * ev);virtual void tagit(G3EventProxy * ev);

The filter() method is ment to implement a pre-selection of the events, while the tagit() method isused to fill the tag for the selected events. In this example the filter is reconstructing muons and electrons.Only for events with at least two muons and two electrons the event will be accepted and a tag will be written.

If no preselection is required the filter() method can simply be implemented with return true;.

In the tagit() method the analysis of the pre-selected event is continued. The FillHZZeemm examplecalculates the invariant masses of the muon and electron pairs (assumed to originate from Z bosons) as wellas that of the two thus reconstructed Z bosons. With the “set” methods of the tag class the tag data membersare filled. The tag will be stored in the database after finishing the tagit() method.

In the test subdirectory the WriteHZZeemm program can be created. The BuildFile contains thelibraries

<lib name=HZZeemm><lib name=WriteHZZeemm>

and all the normal libraries that are needed for the analysis. A tag-writer is a RecReader application.

In the .orcarc file the input collection and output database for the tag are specified. The exam-ples is shown in Figure 12.2 The UserCollection containing the tags will be created in a private database

ExtraPackages = BatchRecReader:UserWorldInputCollections = /System/NoPileup/h300eemm/h300eemmUserCollection = /HZZeemm/NoPileup/h300eemmUserCollection:IOMode = New

Figure 12.2: .orcarc file for a Tag writer application

(HZZeemm). It will be created from scratch with the IOMode set to New.

Reading the tags

Once the tags are written, it is possible to read them back with a very lightweight application. The simplestcase is to use the tags in the same way Ntuples were used for analysis in the past. They contain all numbersrequired for the final analysis and a dedicated program is written that simply loops over the Ntuple, applyinga final selection and filling histograms with the relevant quantities. In a next step the histograms were thenplotted and beautyfied. The package ReadHZZeemm shows a crude implementation of such an analysisprogram. The code is show in Figure 12.3. In the update() method of the Observer class the analysisis done. This simple examples just prints for all events the reconstructed Higgs mass and the Higgs masscalculated on Monte-Carlo level.


#include "Utilities/Configuration/interface/Architecture.h"#include "HZZeemm/HZZeemm/interface/HZZeemm.h"#include "Utilities/Notification/interface/Observer.h"#include <iostream>

class ReadHZZeemm : public Observer<HZZeemm*> {public:ReadHZZeemm() { init();}virtual ˜ReadHZZeemm(){}void upDate(HZZeemm* tag) {

cout << "MHrec = " << tag->mHREC()<< " GeV, MHgen = " << tag->mHMC()<< " GeV " << endl;

}

};

#include "Utilities/Notification/interface/PackageInitializer.h"

static PKBuilder<ReadHZZeemm> myreader("ReadHZZeemm","MainThread");

Figure 12.3: Reading only the tags

A completly new feature that tags offer is the possibility to gain access to the full event after analysingthe tag attached to it.

#include "Utilities/Configuration/interface/Architecture.h"#include "HZZeemm/HZZeemm/interface/HZZeemm.h"#include "CARF/UserWorld/interface/UserTag.h"#include "CARF/UserWorld/interface/UserSelector.h"

class SelectHZZeemm : public UserSelector {[...]bool SelectHZZeemm::MySel::filter(const Tag & tag) const {Tag *mytag = const_cast<Tag *>(&tag);if (fabs(mytag->mHREC()-mytag->mHMC()) < 30.) {

cout << "Well reconstructed!" << endl;cout << "MHrec = " << mytag->mHREC()

<< " GeV, MHgen = " << mytag->mHMC()<< " GeV " << endl;

return true;} else {

return false;}

}

#include "Utilities/Notification/interface/PackageInitializer.h"static PKBuilder<SelectHZZeemm> myselector("SelectHZZeemm","MainThread");

Figure 12.4: Selection based on tags


At the start of the job a loop over the tags is performed and a transient collection containing the eventsthat were accepted by the filter()method is build. Then for the events of this collection G3EventProxy* is dispatched to the corresponding observers. These Observers have full access to event and to the tagcontence. Figure 12.5 shows the code example. It is a modified version of the most simple example classExRunEventInfo that was shown at the beginning of this introduction. The access to the event is onlyused to print run and event numbers.

Since a lot of effort may have gone into the creation of the tag it is desireable to get access to its contencefor the event under study. Since the tag is stored in the MetaData, from there a pointer to the tag can beobtained:

ObjyHandleCast<HZZeemm> htag(ev->evmd()->userData());

After checking that this pointer is valid, all public methods of the tag can be used.

Plotting with tags

Finally, there is the possibility to use for example the analysis tool Lizard to fill histograms, display andprint them. This will be discussed for three different cases. The histograms will be created in differentlogical subdirectories inside Lizard. They will be identified by a string which is the name.

Filling dynamic histograms This is the easiest way to display information. All that is required is to callthe fill() method for each quantity that should be displayed in a histogramm. Here an example fromExamples/ExHZZeemmTagPlot/Dynamic.cc:

// define the name of the subdirectory in Lizardstring MultiDynPlotter::defName() { return "Dynamic";}

void MultiDynPlotter::plot(const Tag & tag) {histos("mH Rec")->fill(tag.mHREC());histos("mH MC")->fill(tag.mHMC());histos("mH Rec-MC")->fill(tag.mHREC()-tag.mHMC());

}

For each event in the tag collection MultiDynPlotter::plot will be called. Here three different his-tograms are filled. Minimum and Maximum of the X-range of the histogram are determined automaticallyfrom the first events. This is done to avoid to loop twice of all events (like ntuple/plot in HBOOK)however overflows and underflows can occur.

Booking and filling histograms Most of the time dynamic histograms are not sufficent. A single event maymake the automatically chosen range useless. If one is interested in a particular range of some quantities orin a certain number of bins, the histograms have to be booked before filling them. How to do this is shownin the files PreBooked.cc, PreBookedDef.cc and PreBooked.h. Only the first one will contain usercode. PreBookedDef.cc and PreBooked.h simply define the name of the tag to use and the name of thedirectory the histograms will be stored into. Figure 12.6 shows the user code. The pre-booked histogrammerhas three methods book() where the histograms are actually defined. They are identified by a string andboth 1-dimensional and 2-dimensional histograms can be used. (What about profiles?)

The histograms are filled in the plot() method. In this example simply the information of the tags isused, but of course one can do some arithmetics to store show more interesting things. Finally there is theclose() methods were it is possible to manipulate the histograms before publishing them.


#include "Utilities/Configuration/interface/Architecture.h"#include "Utilities/Notification/interface/PackageInitializer.h"#include "HZZeemm/HZZeemm/interface/HZZeemm.h"#include "CARF/G3Event/interface/G3EventProxy.h"#include "Utilities/Notification/interface/Observer.h"#include "Utilities/ObjyUtil/interface/ObjyCast.h"

class ExHZZeemmAnalyser : private ActiveObserver<G3EventProxy *> {public:[...]void myAnalysis(G3EventProxy * ev) {

cout << "===========================================================" << endl;cout << "=== Private analysis of event #"<< ev->simSignal()-

>id().eventInRun()<< " in run #" << ev->simSignal()->id().runNumber() << endl;

eventsAnalysed++; // some statistics: count events and runs processed// ---- this is how to get access to the tag -------ObjyHandleCast<HZZeemm> htag(ev->evmd()->userData());if (htag) {cout << "reconstructed Higgs mass: "

<< htag->mHREC()<< " GeV" << endl;

const HZZeemm::ParContainer electrons = htag->RECelectrons();cout << "The reconstructed (m(Z)=" << htag->mZeREC()

<< "GeV) electrons are: " << endl;HZZeemm::ParConstIterator i=electrons.begin();for (i=electrons.begin(); i!=electrons.end() ;i++) {

cout << (*i) << endl;}const HZZeemm::ParContainer muons = htag->RECmuons();cout << "The reconstructed (m(Z)=" << htag->mZmREC()

<< "GeV) muons are: " << endl;HZZeemm::ParConstIterator j=muons.begin();for (j=muons.begin(); j!=muons.end() ;j++) {

cout << (*j) << endl;}

}if (ev->simSignal()->id().runNumber() != lastrun) {lastrun = (unsigned int) ev->simSignal()->id().runNumber();runsAnalysed++;

}cout << "===========================================================" << endl;

}private:/// don’t change the name "upDate" - this method is mandatory.void upDate(G3EventProxy * ev) {

if (ev!=0) myAnalysis(ev);}

[...]};

static PKBuilder<ExHZZeemmAnalyser> mybuilder("ExHZZeemmAnalyserBuilder");

Figure 12.5: Analysing events selected by tags.



#include "AIDA_HTL/AIDAHist1D.h"#include "AIDA_HTL/AIDAHist2D.h"

#include "Examples/ExHZZeemmTag/interface/ExHZZeemm.h"#include "Examples/ExHZZeemmTagPlot/interface/PreBooked.h"

void PreBooked::book() {add("mH Rec", new AIDAHist1D("mH Rec", 50, 200.,400.));add("mH MC", new AIDAHist1D("mH MC", 50, 200.,400.));add("mH Rec-MC", new AIDAHist1D("mH Rec-MC", 100,-200.,200.));add("mH Rec vs MC", new AIDAHist2D("mh Rec vs MC", 50,0.,600.,

50,0.,600.));}

void PreBooked::plot(const Tag & tag) {cout << "is here!!!" << endl;hist1D("mH Rec")->fill(tag.mHREC());hist1D("mH MC")->fill(tag.mHMC());hist1D("mH Rec-MC")->fill(tag.mHREC()-tag.mHMC());hist2D("mH Rec vs MC")->fill(tag.mHMC(), tag.mHREC());

}

void PreBooked::close() {}

Figure 12.6: Booking and filling histograms as in PreBooked.cc.

Writing the code to fill the histograms (after defining them eventually) is one thing. As show above thisis done in pure C++, the same language as any other code for ORCA. The use of this code however is doneusing Python from within Lizard. Lizard is started simply by typing

lizard

in a shell with scram initialised environment. The first thing after starting lizard is to do some genericinitialisation:

execfile(cobrafile(’g3start.py’))

The libraries that are needed to analyse the tag have currently to be loaded manually:

loader.load("HepPDT:Particle:ExHZZeemmTag:ExHZZeemmTagPlot")

The plotting classes are in the library ExHZZeemmTagPlot. If the classes, for examples in PreBooked.ccare changed, one needs not to restart lizard. Simply unload the library with loader.unload("ExHZZeemmTagPlot"),rebuild it with os.system("scram b") and load it again with loader.load("ExHZZeemmTagPlot").The input collection is specified like this:

icoll = "/ExHZZeemm/NoPileup/h300eemm"ui.modify("InputCollections",icoll)

12.2. ACCESSING MC GENERATOR INFORMATION AND GEANT TRACKS AND VERTICES 131

And we can loop over the events with

loop()

After this the histograms are available. With a little more python one can easily fit and plot some of them.This is done in the rest of the little script doit.py.

12.2 Accessing MC generator information and GEANT tracks and ver-tices

This version of ORCA is reading CMSIM FZ-files as input. In these files the originally simulated particlesare stored in form a GEANT KINE structure. All this information can be retrieved be it when reading theFZ file or when reading from a database. In case the event has been simulated using an event from a MCgenerator as input, also the information from the HEPEVT common block as produced by that generatorcan be accessed. In this section several ways to get these informations are explained.

12.2.1 Access to MC information using G3EventProxy

The ActiveObserver class usually gets a pointer to the current G3EventProxy as an argument. AG3EventProxy has a pointer to the corresponding signal event (simSignal) and to a container with thepile-up events. The simSignal event provides then containers with the GEANT tracks (tracks), theGEANT vertices (vertexes) and the MC generator information (rawgenparts). The program ExM-Cinfo.cpp demonstrates the use of all of these containers. The following code fragment will print the firstGEANT track:

SimEvent::track_container GeantTracks; // this is an STL vectorGeantTracks = ev->simSignal()->tracks();cout << "This event has " << GeantTracks.size() << " GEANT tracks." <<endl;cout << "The first track is:" << endl;cout << (*(GeantTracks[0])) << endl;

Iterators are provided to allow easy access to all tracks, etc.

To facilitate the access to MC generator information the subsystem GeneratorInterface 13 containsa few classes: RawHepEvent, RawHepEventParticle, RawParticle. For a detailed description ofthese classes see there. Currently they provide easy reading of signal an pileup events. The program ExM-Cinfo2.cpp shows how to use these classes:

HepEventG3EventProxyReader EventReader(ev);RawHepEvent MyHepEvent;MyHepEvent.read(&EventReader);

Here ev is a pointer to a G3EventProxy. If the event was generated from a MC event generator the fullHEPEVT structure is obtained. The mother-daughter links between the RawHepEventParticles of theevent are created. If the event was generated from a single particle using the GEANT KINE command, thisparticle will be put into the RawHepEvent.


12.2.2 MC information as RecObjs

The MC generator information of the underlying signal event can also be retrieved in form of RecObjs(see Section 15). To achieve this a fake detector class, RawGenLevelDetector is used. Several classes areprovided to reconstruct particles RawParticleRecon, or partons RawPartonRecon. Filters can be usedto select certain particle types or particles satisfying certain cuts. To create the particles one has to prop-erly setup their reconstructors. They are then reconstructed on demand. The program ExMCinfo3.cppdemonstrates this.

12.3 Simple matching between tracks and clusters

The package MatchTkEcal shows how to access calorimetric clusters (ECAL) and how to access and prop-agate tracks from the (inner) tracker. As an example a simple matching between tracks and clusters isimplemented.

The first task is to retrieve the clusters and copy those that satisfy some quality criteria (energy largerthan 5 GeV and in the barrel) into a private container. This is done exploiting a RecItr:

Hep3Vector vtmp(1.,1.,1.);vector <Hep3Vector> GoodCluster, GoodTracksAtVertex, GoodTracksAtEcal;RecItr<CaloCluster> MyCluster(ev->recEvent(),"EcalFixedWindow_5x5");GoodCluster.clear();while (MyCluster.next()) {.....if (MyCluster->Energy() > 5. && abs(MyCluster->Eta()) < 1.156) {

cout << " is good";vtmp.setMag( (HepDouble) MyCluster->Energy() );vtmp.setTheta( (HepDouble) MyCluster->Theta() );vtmp.setPhi( (HepDouble) MyCluster->Phi() );GoodCluster.push_back(vtmp);

}else {

cout << " is bad";}.....

For tracks the situation is a bit more complicated. Since the tracks are bent by the magnetic field, thedirection of the tangent, i.e. the direction of the particle at a given point on the track, changes from thevertex to the ECAL. Consequently, the Track class provides access to momentum at different positions:

RecItr<TTrack> MyTrack(ev->recEvent(),"TTrack");GoodTracksAtVertex.clear();GoodTracksAtEcal.clear();double phiEcal, phiVertex;string volumeName = "EBRY";while (MyTrack.next()) {

ntracks++;TrajectoryStateOnSurface ipos = (*MyTrack).impactPointStateOnSurface();if (ipos.isValid()) {

// this is at the interaction point

12.4. COMPARING MC PARTICLES WITH THEIR RECONSTRUCTED EQUIVALENTS 133

FreeTrajectoryState ip = *(ipos.freeTrajectoryState());// this is at ECAL (barrel) front faceFreeTrajectoryState ts = (*MyTrack).stateOnVolume(volumeName);cout << setw(3) << ntracks <<": p=" ;cout.setf(ios::showpoint);cout << setw(8) << setprecision(3) << ip.momentum().mag()

<< ", theta=" << setw(8) << setprecision(4) << ip.momentum().theta()<< ", phi=" << setw(8) << setprecision(4) << ip.momentum().phi()<< ", eta=" << setw(8) << setprecision(4) << -log(tan(ip.momentum().theta()/2.))<< " // ";

if (ts.momentum().mag() > 0.00001) {cout << setw(8) << setprecision(3) << ts.momentum().mag()

<< ", theta=" << setw(8) << setprecision(4) << ts.momentum().theta()<< ", phi=" << setw(8) << setprecision(4) << ts.momentum().phi()<< ", eta=" << setw(8) << setprecision(4) << -log(tan(ts.momentum().theta()/2.));

}else {

cout << " is bad";}cout << endl;

}

For the matching the tracks are considered at the ECAL front face (EBRY). With the selected tracks andclusters a simple angular matching is performed, using the angle method of Hep3Vector. The results forany combination of tracks and clusters in events with single 10 GeV pt positrons is shown in Figure 12.7.

tmpdelta=GoodCluster[i1].angle(GoodTracksAtEcal[i2]);if (tmpdelta < delta) {

delta = tmpdelta;icl=i1; itk=i2;

}

12.4 Comparing MC particles with their reconstructed equivalents

In package CompGenRec examples comparing generator level particles or quantities to their reconstructedequivalents are collected. Currently there are two examples: one for reconstructed muon tracks and one forthe Level-1 calorimeter trigger.

12.4.1 Reconstructed muon tracks

In ORCA2 muon tracks are only available for the barrel muon system. They are not yet using informationfrom the inner detector elements, only from up to four muon stations. For this example the muon tracksare only extrapolated to the innermost muon station, no further GEANT tracking back to the event vertexis done. Since the energy loss in the calorimeters is not corrected for the reconstructed energy will besystematically too low. Due to bending in the magnetic field also the φ angle will be different to that one atthe vertex. This should be kept in mind when looking at the result of the comparison in Figure 12.8.

To retrieve the GEANT KINE track for the generated muon the class RawHepEvent is used. This classhas a read method which reads either the MC generator information or – if none is present – the first


dPhi(Cluster,Track)

0

10

20

30

40

50

60

0 5 10 15 20

MeanRMS

4.367 1.769

dTheta(Cluster,Track)

05

101520253035

0 5 10 15 20

MeanRMS

1.388 1.068

Figure 12.7: The difference in φ and θ angle between reconstructed inner tracker track and ECAL cluster forsingle electron events with 10 GeV pt.

GEANT KINE track. See Section 13.3 for details. From the event the barrel muons (η < 1.) are thencopied to a list of fourvectors. The reconstructed muon tracks are retrieved in a similar way as described forclusters and tracks in Section 12.3. The argument to the momentum method means that the the momentumis given at the innermost muon station. Starting with ORCA4 the interface to the muon is the same as to theTracker tracks.

Hep3Vector vtmp(1.,1.,1.);RecItr<TTrack> MyMuonTrack(ev->recEvent(),"MuonReconstructor");while (MyMuonTrack.next()) {

TrajectoryStateOnSurface ipos = (*MyMuonTrack).impactPointStateOnSurface();if (ipos.isValid()) {

FreeTrajectoryState ip = *(ipos.freeTrajectoryState());vtmp.setMag( (HepDouble) ip.momentum().mag() );vtmp.setTheta( (HepDouble) ip.momentum().theta() ) ;vtmp.setPhi( (HepDouble) ip.momentum().phi() );GoodRecMuon.push_back(vtmp);

}}

The matching is finally done as as in ExMatchTkEcal.

12.4.2 Level-1 calorimeter trigger

The trigger subsystem provides a prototype of a Level-1 calorimeter trigger. Its use is demonstrated in theprogram ExCompL1CaloTrigger. The example should be run on single electron files. The access to thetrigger information is in this prototype not via a RecObjmechanism. Instead a set of custom classes is used:

12.4. COMPARING MC PARTICLES WITH THEIR RECONSTRUCTED EQUIVALENTS 135

Mu(Egen-Erec)/Egen [%]

0

5

10

15

20

25

30

35

-100 0 100 200

148.5 / 103Constant 21.44 1.080Mean 31.09 0.5861Sigma 14.74 0.5440

Tk(Egen-Erec)/Egen [%]

0

10

20

30

40

50

60

-10 0 10 20

47.38 / 55Constant 57.04 2.432Mean -0.2964E-01 0.2164E-01Sigma 0.6652 0.1814E-01

dPsi(GenMu,RecTk) [degree[]

0

20

40

60

80

100

120

140

-0.2 -0.1 0 0.1 0.2

70.96 / 27Constant 113.3 5.880Mean 0.2192E-01 0.8517E-03Sigma 0.1846E-01 0.1099E-02

Muon dPsi(Gen,Rec) [degree]

0

10

20

30

40

50

60

-40 -20 0 20 40

50.39 / 42Constant 45.64 1.914Mean 20.81 0.1127Sigma 3.127 0.8208E-01

Figure 12.8: Top: Comparison of the reconstructed energy for muon tracks and inner tracker tracks with that ofgenerated single muons of 10 GeV pt. Botton: The difference in angle between reconstructed and generated muonmomentum.

{cout << "Isolated EM objects: " << endl;L1CIsolatedEMObjects* objects;objects = caloTriggerSetup->IsolatedEMObjects();L1CaloTriggerSetup::IsolatedEMObjects_const_iter o;if (! (*objects->begin()).empty()) {trigtype[ANY]=true;trigtype[ISOLATED_EM]=true;

}


for(o = objects->begin(); o != objects->end(); o++){

cout << *o << endl;}

cout << endl;}

An HBOOK column-wise Ntuple is created which allows to perform topological comparisons betweentrigger and ECAL clusters.

12.5 The prototyping library

This package creates a library for rapid prototyping. The classes defined here may either move to othersubsystems of ORCA or disappear. This kind of changes will however be announced early - probably by amessage in the constructor of the class. Even obsolete classes will continue to exist at least one release afterbeeing declared as such.

Part III

COBRA Sub-System Descriptions

137

Chapter 13

GeneratorInterface

This package implements an interface to Monte-Carlo generator information. It contains a package totranslate Particle IDs to names, and the particle properties, classes to handle particles, as simple four-vectors, according to the HEPEVENT standard or as CARF RecObjs and a class to acommodate a collectionof HepEventParticles.

13.1 HEP particle properties and identification numbers

The HepPDT particle Data Table classes, taken from http://www.thep.lu.se/leif/CLHEP-PDT,are used to map the numeric particle IDs from MC generators using the standard HEP numbering schemeinto particle names and properties. For details check the WWW-page mentioned. The information is readfrom a userdefined file. To specify the file the environment variable EXHEPPDTABLE is used. The classesmay be integrated into CLHEP at some point. Since CLHEP is used by ORCA anyhow they will thendisappear from here.

13.2 Classes to handle particles

Particles are very common objects in any physics analysis. They come in a multitude of different forms butthey all have the basic properties of a Lorentz fourvector. This is the reason to have the basic particle classRawParticle inherit from HepLorentzVector.

13.2.1 Generic particles

A particle generally has an identifier, a status, an electric charge, a mass and a vertex where it starts. Par-ticles can be instantiated with different options. A particle is constructed with id=0 and status=99. Atconstruction one or two HepLorentzVectors can be given as arguments. They are interpreted as fourmo-mentum and creation vertex of the particle. To set and retrieve information a large number of methods areprovided:

class RawParticle : public HepLorentzVector {....public:

139

http://www.thep.lu.se/~ leif/CLHEP-PDT

140 CHAPTER 13. GENERATORINTERFACE

void setID(int id);void setStatus(int istat);void setMass(float m);void setCharge(float q);// methods to be overloaded to include vertexvoid boost(HepDouble bx, HepDouble by, HepDouble bz);void rotate(HepDouble rphi, const Hep3Vector &raxis);void rotateUz(Hep3Vector &nuz);void rotateX(HepDouble rphi);void rotateY(HepDouble rphi);void rotateZ(HepDouble rphi);int pid() const;int status() const;HepDouble charge() const;HepDouble PIDcharge() const;HepDouble mass() const;HepDouble eta() const; // pseudo rapidity of momentumHepDouble et() const; // transverse energyHepDouble x() const; // x of vertexHepDouble y() const; // y of vertexHepDouble z() const; // z of vertexHepDouble t() const; // t of vertexHepLorentzVector vertex() const;void printName() const;void print() const;int isUsed() const {return _used;}void use() { _used = 1;}void reUse() { _used = 0;}

....}

Internally the class HepPDTable is used to provide particle properties (see Section 13.1). The methods use,reUse and isUsed implement a simple locking mechanism. Also a print method is provided to output theparticle information in a formatted way. A RawParticle can also be handed to the stream operator (<<).

13.2.2 Particles in HEPEVENT common blocks

Many MC generators store the generated particles in the (FORTRAN) HEPEVENT common block. Animportant information there is the relations formed from the decays of particles, the mother and daugh-ter relationships. To nicely reflect these relationships the class RawHepEventParticle, inheriting fromRawParticle is used. It stores pointers to mother and daughter particles and has some output methods toprint. Printing can be done for the particle as such or in form of decay trees. In the HEPEVENT commonblock the particles are identified uniquely by line numbers and mother-daughter references are using these.Hence, the numbers are needed to build the mother-daughter relations in the C++ class.

13.2.3 Creating particles as RecObjs

The concept of RecObjs, i.e. objects that are reconstructed on demand and not by default, is an importantingredient of ORCA - implemented in the CARF subsystem (Section 15). The reconstruction is done byRecUnits; upto now actually by TRecUnits which are creating only transient objects.

13.2. CLASSES TO HANDLE PARTICLES 141

TRecUnitRecObj

RawRecParticle

RawParticle

BaseRawFakeDetector<<abstract>>

0..*0..*

BaseRawParticleFilter<<abstract>>

RawParticleRecon

11

0..10..1

LazyObserver

RawGenLevelDetector

RawPartonDetector

RawStableParticleFilter

RawParticleTypeFilter

RawParticleEtaFilter

RawParticleEtFilter

RawTDRDetector

Figure 13.1: Class diagram for the FakeDet mechanism.


Figure 13.1 shows the relationships between the different participants in this mechanism. To accessRawRecParticles an analysis class needs a RawParticleRecon, a BaseRawFakeDetector (e.g.RawGenLevelDetecttor to access particles from the Monte-Carlo generator event) and a BaseRaw-ParticleFilter (e.g. RawParticleTypeFilter to find only electrons) as private data members.

class ExDumpMCElectrons : private ActiveObserver<G3EventProxy *> {public:

ExDumpMCElectrons(); //!< default constructor˜ExDumpMCElelctrons(); //!< default destructorvoid myAnalysis(G3EventProxy * ev); //!< this method will do the user analysis

private:/** don’t change the name "upDate" - this method is mandatory. */void upDate(G3EventProxy * ev) { if (ev!=0) myAnalysis(ev);}

private:// the bits and pieces needed to use RecItrRawGenLevelDetector myRglDet;RawStableParticleFilter myStableFilter;RawParticleTypeFilter myElectronFilter;RawParticleRecon myElectronRecon;

};

In the implementation of the constructor of the analysis class the machanics is then set up:

ExDumpMCElectrons::ExDumpMCElectrons() :myElectronFilter("e-","e+"),myElectronRecon(&myRglDet,&myElectronFilter,"electrons")

{myElectronFilter.addFilter(&myStableFilter);myElectronRecon.setMeAsDefault();

}

The RawParticleTypeFilter is initialised to let only electrons and positrons pass, the RawParti-cleRecon is told to get the input fom the RawGenLevelDetector, use the electron filter and the name“electrons” is given to the RawRecParticles it produces. Then the RawStableParticleFilter isadded to the electron filter to accept only real electrons and the electron TRecUnit is made the default wayto produce RawRecParticles. The access to the electrons is then done via a RecItr:

// dump all electronsRecItr<RawRecParticle> rei(ev->recEvent(),"electrons");cout << "These are the electrons:" << endl;while (rei.next()) {rei->print();

}

Because the our electron TRecUnit is the default we could also write:

RecItr<RawRecParticle> rei(ev->recEvent());cout << "These are the (default) electrons:" << endl;while (rei.next()) {rei->print();

}

13.3. CLASSES TO HANDLE HEPEVENTS 143

Using the names makes things however easier to understand.

13.3 Classes to handle HEPEVENTS

The RawHepEvent class provides a container for RawHepEventParticles just like RawEvent for Raw-Particles. RawHepEvents can be read from a BaseHepEventReader. This is an abstract class defin-ing the interface just the interface. Implemented are HepEventG3EventProxyReader to read events (in-cluding signal and pileup) from within CARF, HepEventCmkinNtupleReader to read from a standardcmkin Ntuple (only signal implemented, see program ExDumpHepNtuple), HepEventTxtReader toread from a standard ASCII file as used by Geant4, HepEventParticleGunReader to create RawHep-Events from ParticleGuns and HepEventPythia6Reader to read events directly from Pythia.

If the SimTrigger event is not generated by a MC generator but from a single GEANT track theHepEventG3EventProxyReader will convert this to a particle and fill it into the event. The particleID is changed from GEANT to HEP convention in the process. When reading a SimTrigger the particlevertices are shifted according to the simulated GEANT event vertex shift. For pileup events vertices and thetimes are adopted. The unit in which vertex positions are given is mm, momenta and energy are given inGeV.

TYPE NAME DEFAULTbool HepEventG3EventProxyReader:ReadPileup falsebool HepEventG3EventProxyReader:ReadVertices trueint HepEventG3EventProxyReader:MinBunch 0int HepEventG3EventProxyReader:MaxBunch 0

Table 13.1: HepEvent parameters for the .orcarc files

Several print methods are available. print() gives a plain listing of the particles with their momentaand vertices just like LULIST. printTree() on the other hand prints the decay relations of the parti-cles in a tree like structure. Some generators create ambiguous mother daughter relations which may notbe resolved correctly. The ORCA way of doing things is demonstrated in the Example ExMCinfo2 (seeSection 12.2).

13.4 Utility classes

The HepGeantConverter class provides conversion between GEANT3 particle indentifiers (a numberfrom 0 to 31) and standard HEP PID numbers. The conversion can be done in both directions, using themethods HepId(geantid) and GeantID(hepid). All ID numbers are of type integer. If the conversionfails, both methods return -99. The class can be used like this:

#include "GeneratorInterface/GIUtils/interface/HepGeantConverter.h"[...]HepGeantConverter* aConverter;aConverter->Instance();

cout << "A photon (Hep=22, GEANT3=0) is "<< aConverter->GeantId(22)<< " in Geant3 and "


<< aConverter->HepId(0)<< " in Hep." << endl;

[...]

13.5 .orcarc parameters

HepEventG3EventProxyReader:ReadPileup bool 0 (false) HepEventG3EventProxyReader Control thereading of MCinfo from pileup events.HepEventG3EventProxyReader:ReadVertices bool 1 (true) HepEventG3EventProxyReader Control thereading and calculation of the real event vertices. For each event the annihilation vertex will be determinedfrom the first Geant SimTrack and the generator-level vertices of this event will be shifted accordingly.HepEventG3EventProxyReader:MinBunch int 0 HepEventG3EventProxyReader First bunch to readpileup information from if asked forHepEventG3EventProxyReader:MaxBunch int 0 HepEventG3EventProxyReader Last bunch to readpileup information from if asked for

ParticleGun:PID int 13 BaseParticleGun Particle identifyer according to Particle Data Group num-beringParticleGun:MinPhi float 0. [rad] BaseParticleGunParticleGun:MaxPhi float 2PI [rad] BaseParticleGunParticleGun:MinEta float -5.5 BaseParticleGunParticleGun:MaxEta float 5.5 BaseParticleGunParticleGun:MinE float 0. [GeV] FlatSteppingEGun, FlatRandomEGunParticleGun:MaxE float 9999. [GeV] FlatSteppingEGun, FlatRandomEGunParticleGun:MinPt float 0. [GeV] FlatRandomPtGunParticleGun:MaxPt float 9999. [GeV] FlatRandomPtGunParticleGun:PhiSteps int 1 FlatSteppingEGunParticleGun:EtaSteps int 1 FlatSteppingEGunVertexGenerator:MinX float 0. [mm] FlatEventVertexGenerator minimal X-valueVertexGenerator:MaxX float 0. [mm] FlatEventVertexGenerator maximal X-valueVertexGenerator:MinY float 0. [mm] FlatEventVertexGenerator minimal Y-valueVertexGenerator:MaxY float 0. [mm] FlatEventVertexGenerator maximal Y-valueVertexGenerator:MinZ float 0. [mm] FlatEventVertexGenerator minimal Z-valueVertexGenerator:MaxZ float 0. [mm] FlatEventVertexGenerator maximal Z-valueVertexGenerator:MeanX float 0. [mm] GaussianEventVertexGenerator average X-valueVertexGenerator:MeanY float 0. [mm] GaussianEventVertexGenerator average Y-valueVertexGenerator:MeanZ float 0. [mm] GaussianEventVertexGenerator average Z-valueVertexGenerator:SigmaX float 1. [mm] GaussianEventVertexGenerator width in XVertexGenerator:SigmaY float 1. [mm] GaussianEventVertexGenerator width in YVertexGenerator:SigmaZ float 1. [mm] GaussianEventVertexGenerator width in Z

Chapter 14

Magnetic Field

This subsystem calculates the value of the magnetic field in a given point inside the CMS detector. It providesan interface where the user defines the point where the field value is calculated as a Hep3Vector and the fieldvalue is returned as a Hep3Vector.

14.1 Magnetic Field with 2D map

In the current implementation the magnetic field value is calculated using a 2D field map. A correction ismade in the return yoke where the field does not have a 2D symmetry. The field map and the calculationalgorithm are similar to what is used in CMSIM.

14.2 Magnetic Field Examples

An example of obtaining magnetic field values is given here.

145

146 CHAPTER 14. MAGNETIC FIELD

Chapter 15

CARF: CMS Analysis & ReconstructionFramework

CARF is the framework for CMS Analysis & Reconstruction software.

CMS software architecture is structured in

• an application framework CARF (CMS Analysis & Reconstruction Framework), customisable foreach of the computing environments;

• physics software modules with clearly defined interfaces that can be plugged into the framework;

• a service and utility Toolkit that can be used by any of the physics modules.

CARF defines the top level abstractions, their behaviour and collaboration patterns. It comprises twocomponents: a set of classes that capture CMS specific concepts like detector components and event featuresand a control policy that orchestrates the instances of those classes taking care of the flow of control, mod-ule scheduling, input/output, etc. This control policy is tailored to the task in hand and to the computingenvironment.

The physics and utility modules are written by detector group and physicists. The modules can beplugged in the application framework at run time, independently of the computing environment. One caneasily choose between different versions of various modules. The physics modules do not communicate witheach other directly but only through the data access protocols that are part of the framework itself.

The service and utility toolkit consists of two major categories of services: physics type services (his-togrammers, fitters, mathematic, geometry and physics calculation routines) and computer services (dataaccess, inter module communication, user interface, etc.) and, in the long run, will most probably notbe CMS specific. This toolkit is based on a solid foundation library, that today has been identified to beLHC++ [?], which provides basic computer services and a set of classes which form a “dictionary” to beused in all module interfaces. This “dictionary” is eventually extended by CMS specific classes.

Both the application framework and the service and utility toolkit shield the physics software modulesfrom the underlying technologies which will be used for the computer services. This will ensure a smoothtransition to new technologies with changes localised in the framework and in specific components of theservice toolkit.

147

148 CHAPTER 15. CARF: CMS ANALYSIS & RECONSTRUCTION FRAMEWORK

15.0.1 Action on Demand

To achieve maximum flexibility CARF implements an “implicit invocation architecture”. Modules registerthemselves at creation time and are invoked when required. In this way only those modules really neededare loaded and executed. Implicit invocation requires some additional mechanisms to construct the requiredmodules, to customise them and to manage dependencies.

Module construction

CMS software is subdivided in “Packages”. A package groups all classes required to perform a given task.A package realizes itself into a shared library. CARF provided a PackageInitializer class which can bespecialised in each package. One instance of this class can be staticly constructed when the correspondinglibrary is loaded. Such an object can be used to construct and register default versions of the modulescontained in the package. Additionally Singletons can be used to publicise and export other more directservices.

Customisation

a CARF application can be customised in several way:

• at loading time: the act of loading a shared library will automatically invoke the corresponding Pack-ageInitializer. CARF will in future support run time dynamic loading to improve flexibility.

• at compilation time: CARF provides hooks where users can overwrite default initialisation and regis-ter their own plug-in modules and define their own preferred configuration.

• at run time: through a user interface (at present a simple ASCII file, in future a database drivenconfiguration control system) packages can be instructed to construct and register particular modulesin some specific configuration.

dependency management

To avoid a central management of dependencies all plug-in modules work in a “lazy-update” mode. In sucha mode the actual code execution is deferred until a service is required to the object in question. A simplestate machine ensures that code is executed once for each “event”. A “lazy-update” approach achieves twogoals:

• code is executed when and if it is really required

• dependencies are automatically taken into account

The major drawback of the absence of a central management of dependencies is the impossibility to per-form a “static check” of the application configuration prior to run time: missing modules and/or circulardependencies will only be detected at run time.

15.1. RECONSTRUCTION 149

Reconstruction is the data reduction process

Parameters

used by the ‘‘user’’ analysis.

DAQ

which creates, out of DAQ data, objects

Detector Description

Detector Status

Analysis

User Options

Analysis can be an event filtering process,or a further data reduction process.

Figure 15.1: Sources of information for a Reconstruction algorithms (arrows indicate the direction of requests, notdata flow)

15.1 Reconstruction

Reconstruction is the data reduction process which produces the information relevant to physics analysisstarting from what is delivered by the data acquisition system.

Reconstruction algorithms share common sources of information or services from common utility tools(which are re-usable components of CMS reconstruction software). Sources of information for a reconstruc-tion algorithm are:

• DAQ or simulation program;

• Other reconstruction algorithms;

• Environmental data including:

– Detector Description;

– Detector Status;

– Calibrations;

– Alignments;

• Reconstruction algorithm parameters;

• User Options.

This is schematically shown in Figure 15.1.

In the reconstruction process we identify two stages: detector reconstruction and global reconstruction.


15.1.1 Detector reconstruction

Detector reconstruction is a data reduction process which can be performed in isolation in a single “De-tector Unit”. It can be considered essentially as a direct continuation of the digitisation process performedonline. It is performed offline mainly because environmental data are not available, or precise enough, atdata acquisition time. Because of its local nature it is natural to assign the responsibility of detector recon-struction to the detector unit which produces the raw information itself. We will denote the deliverables ofsuch reconstruction process “reconstructed hits” (in short RHITs). The granularity of detector units will ofcourse depend on the detector layout. It is supposed that global reconstruction modules will ask directly thedetector units for their RHITs during pattern recognition. a geometry-setup object is therefore required tohold the detector units and eventually provide a navigation tool among them.

It should be noted that Detector reconstruction has several additional distinctive features:

• It is usually stable and rarely is it required to run two concurrent different reconstructions for thesame detector unit (although mechanisms to change algorithm at run time are provided)

• it is usually fast (most of the time just a calibration and a linear clustering algorithm) compared to thecombinatorial reconstruction which will follow

• If it id required to be rerun it invalidates all the results of the global reconstruction which depends onit

Therefore in most of the cases the results of detector reconstruction as such do not require to be madepersistent.

Detector Units are also the natural place where simulation of the digitisation process can take place. Inthis case a mechanism for making persistent the object created in this process is provided.

15.1.2 Global reconstruction

Global reconstruction delivers “Reconstructed objects” (in short RecObjs) suitable for physics analysis orfurther global reconstruction. By their nature they are detached by the detector which provided the originalinformation and should be usable in a Lorenz space common to CMS as a whole. They belong more to theevent rather than to a detector.

Reconstruction is performed by user provided modules which extend the CARF provided ReconstructionUnit (in short RecUnit).

A Reconstruction Unit usually performs the following activities:

• Pattern recognition: the process that, starting from collections of lower level RecObj’s, constructs theRecObj’s of interest. Usually it makes use of time consuming combinatorial algorithms.

• Fit: the process which computes the physical or geometrical attributes of a RecObj starting frominformation provided by its constituent RecObj’s.

• Correction: the process whereby additional detector information (calibrations, alignments, etc), notavailable (or meaningful) at constituent level, is used to build or fit a RecObj.

Although these three basic activities can be interleaved and mixed depending on the actual reconstructionalgorithm, it is current practice to split them in two parts:

15.1. RECONSTRUCTION 151

ReconstructorRecObj( )

Reconstructor( ){persistent}

A

RecObj{persistent}

RecObj

RecObjIteratorRecObjIterator( )

next( ){transient}

RecEvent{persistent}

recObjs 10..n

reconstructors

1

0..n

A

RecUnitReconstruct( )

{transient}strategy0..n1

Figure 15.2: Class diagram showing the classes collaborating in the reconstruction on demand mechanism

• Object creation: it is the process which creates “stable” RecObj’s in terms of, at least, their con-stituents. It includes pattern recognition and “zero-order” corrections. In general changes to algo-rithms or information used in this process do not ensure that the resulting RecObj’s will keep their“identity”. Full consistency requires that previous RecObj’s be deleted if this process needs to bere-run.

• Object updates: it is the process whereby the physical and/or geometrical attributes of a RecObjare updated. It includes fit and “high-order” corrections. It can include some “non-combinatorial”pattern recognition (object extension). In general, algorithms and information used in this process donot modify the identity of a RecObj but only its attributes. If an update process is run, a new versionof a RecObj is created.

It seems natural to assign the responsibility of object creation to the Reconstruction Unit and the respon-sibility of object update to the object itself.

A Reconstruction Unit is identified by a name (ASCII string) which is also used to identify the collectionof RecObjs it creates. A default Reconstruction Unit can be assigned to each RecObj sub-type (usuallyby the corresponding PackageInitializer). This allows the implementation of a simple “Reconstruction onDemand” mechanism:

• a user asks to the Event for the collection of a given type of RecObj;

• (s)he can specify the collection name; if not the default name is assumed;

• the Event checks if this collection is already present:

– if present returns the collection

– if not present requests the corresponding RecUnit to perform the reconstruction and then returnsthe freshly build collection.

Figure 15.2 shows the classes collaborating in this mechanism and their relationships:

• RecEvent: The entry point to all information about a reconstructed event.


user : RecObjIterator theEvent : Event

: Reconstructor strategy : RecUnit

1: RecObjIterator (Event)

2: findRec (char *)

3: Reconstructor (char *)

6: next ( )

4: RecObj (RecObjIterator*)

TheEvent looks if it hasthe requested ReconstructorIf (yes) return it;else return Reconstructor(name);

5: Reconstruct ( )

The Reconstructor checks if the requested RecObjs exist and are still valid.if (yes) return immediatelyan initialized RecObjIterator;elseask its RecUnit to perform the reconstruction;

Finally the user loops overthe RecObjs using the iteratormember function next()

The user instantiates a RecObjIteratorfor a particular type of RecObjover a given event

Figure 15.3: Scenario diagram representing the reconstruction on demand mechanism

• RecObj: An abstract class which needs to be specialised in the various concrete types (track, electron,jet, etc.).

• Reconstructor: For each type of RecObj the event has a reconstructor which manages the correspond-ing RecObj’s and the various reconstruction activities. The Reconstructor class is concrete and doesnot need to be specialised for each RecObj concrete type. In the current design it is identified by thename of the corresponding RecObj.

• RecUnit: The actual Reconstruction Units will be specialisations (by inheritance) of this class. Therelationship Reconstructor–RecUnit implements a well known Strategy Pattern [?].

• RecObjIterator: The user entry point to this mechanism. It is a parametrised class (a C++ templateclass) with instances for each concrete RecObj type. It is an extension of the classical iterator with theadditional feature that the invocation of its constructor will trigger the “reconstruction on demand”mechanism for its parameter type, as shown in the scenario diagram of Figure 15.3.

This architecture has several advantages:

• There is no need to modify the RecEvent class (nor any other class in the top level architecture) whena new concrete RecObj subclass is introduced.

• RecObj’s are reconstructed when needed and if needed. Their reconstruction is triggered by the objectwhich actually uses them: there is no need for a steering routine where the order in the reconstruc-tion process has to be defined and the dependencies among reconstruction units has to be known inadvance.

• Reconstructor can be versioned: the event entry point (the RecEvent object) remains always the samewhile different versions of reconstructed objects are managed at Reconstructor level.

15.2. PERSISTENCY SERVICE 153

• In the present prototype RecUnit is a transient class. It can easily become a persistent class with theresponsibility of keeping a record of all information actually used by the reconstruction unit itself.

Reconstructed objects require to be made persistent and CARF provides full support to store and re-trieve RecObj belonging to a given event. It also support multiple versions of the same RecObj collection.

15.2 Persistency Service

CMS Reconstruction and Analysis Software is required to store and retrieve the results of computing inten-sive processes (and in general of any process which cannot be “easily” repeated). This responsibility coversalso raw-data storage as we plan to use the same software framework in both offline and level-three trigger.

15.2.1 Persistent data

We have identified three major types of information which require to be made persistent:

• Event Data: data associated to a given “triggered beam crossing”. They encompass:

– Raw Data: data read directly from the detector and eventually processed online.These are WORM (Write Once, Read Many) data, to be securely stored and never modified;

– Reconstructed Data: Data produced by the reconstruction process. They can belong to the wholecollaboration, to a physics analysis group or to a single user. (Partial) reprocessing of Event dataproduces new versions of reconstructed data. Reconstructed data maybe further structured inseveral “layers” according to use cases and access patterns.

– Event Tag: a “small” object which summaries the main feature of an event to be used for fastselection

Event data are usually organised in datasets according to run conditions, physics selection criteria andaccess patterns.

• Environmental Data: data describing the state of the environment at the time the Event data wereproduced. They are identified by:

– a validity time period : which allows to relate an event to the corresponding environmental data– a version

Environmental data encompass:

– Machine status– Detector status (setup, calibration, alignment, etc)– Running conditions– Reconstruction configuration, including algorithm parameters and user options

These information can be produced directly from “slow control data acquisition system” or fromoffline processes

Due to the fact that environmental data can be updated producing new versions it is required to put inplace a mechanism which relates the event data (other than raw) with the environmental data actuallyused during the reconstruction process

• Meta-Data: data describing other data

– event catalog– statistics


15.2.2 Persistent object management in CARF

Persistent object management has been always at the centre of CARF development as it has been alwaysconsidered one of the major task of the analysis and reconstruction framework. Indeed already the veryfirst prototypes (notably 1997 test-beam prototype) had already an Objectivity database as key component.

Today, persistent object management is fully integrated into CARF. CARF manages, directly or throughthe utility toolkit:

• database transactions;

• creation of database and containers;

• metadata and event collections;

• physical clustering of event objects;

• persistent event structure and its relation with the transient one;

• deferencing persistent objects.

CARF provides also a software middle-layer, mainly in the form of template classes, which helps devel-opers of detector software in providing persistent versions of their own objects.

To avoid transaction overhead event objects are first constructed as transient instances and made persis-tent (by a copy to their persistent representations) only at the end of the event processing when a decision isfinally taken about the fate of the event (send it to oblivion or save it in a particular dataset) and about itsclassification.

Such a copy is not performed in accessing persistent events: physics modules access directly persistentobjects through simple C++ pointers. CARF takes care of all details to make sure that the required objectsare actually loaded in memory and that their pointers do not become invalid while the event is processed.

This architecture avoids that detector software developers should become Objectivity experts. Indeedthe goal is to make the use of Objectivity completely transparent to physics software developers withoutcompromises in efficiency. This will also guarantee a painless transition to a new persistent technology ifObjectivity proves not to satisfy our requirements.

The present version of CARF (5.1.0) offers persistent object management for:

• event structure and metadata common to test-beams, simulation and reconstruction

• Raw data from test-beam

• simulated particles, simulated tracks and simulated hits

• digis from simulation and test-beams

• reconstructed objects common to test-beams and simulation

• user event data in form of “tags”

Chapter 16

CMS Service and Utility Toolkit

CMS extensions, customisations, wrappers of general computer services and utilities.

The reasons to use these classes instead of those provided by the foundation libraries (LHC++) are mainlysociological rather than technical.

16.1 User Inerface

This package provides a User Interface framework at which any object can be attached.

16.1.1 Basic Principles

The UI package permits to message an object, registered to the UI framework and identified by a simpleunique name, addressing a string to it. The most common usage is to set or modify an object state, but themessage can be interpreted by the object itself to perform whatever other action. The mechanism used is asort of reverse Model-View-Controller (MVC) pattern. The objects to be modified (configurable objects) actas “Views” and should be instances of classes derived from BaseSimpleConfigurable. The user input actsas Model (let me call it “Port”). The Controller is an instance of the UI core class “SimpleConfiguration”.Configurable objects should be registered to a Port (usually at construction time). In principle more than oneobject can be registered to the same Port and one object can register to multiple ports. The most commoncase is one to one association.

For classes for which iostream operators are defined a simple template class “SimpleConfigurable” existswhich allow to make configurable any object belonging to such a class. The most trivial cases are Simple-Configurable¡int¿, SimpleConfigurable¡float¿ etc.

16.1.2 Input Modes

SimpleConfiguration accepts input from ASCII files containing a sequence of “Configuration Records” ordirectly through an API which can be, for instance, invoked by a line mode or graphics user interface.

At present UI is configured to work by default within ORCA. A default SimpleConfiguration is con-structed and made available through the static method SimpleConfiguration::current(). Such a defaultobject will read all files listed in a colon separated list contained in environmental variable CONFFILES.

155

156 CHAPTER 16. CMS SERVICE AND UTILITY TOOLKIT

These files are searched for in the directories listed in a colon separated list contained in environmentalvariable CONFPATH. If no environment is set, the following defaults are used:

CONFPATH = ./:${ORCA_DATA_DIR}/CARFData%$CONFFILES = .orcarc

16.1.3 Intrusive UI

The simplest way to use the UI package with its full power is intrusive. Utilities/UI/test/UIexample.cpppresents the two most common way:

• a class whose attributes are SimpleConfigurable objects

• a class with iostream operators used directly ad template argument of SimpleConfigurable

In the first case each single attribute is bound to a configuration record and can therefore modified indepen-dently of the others.

In the second case the whole oject is bound to a single configuration record and will be modified in oneshot.

16.1.4 Non Intrusive UI

the UI package can also be used non itrusively to initialise objects instance of classes not foreseen to collab-orate with UI in first place.

The most trivial way is to assign the value of a variable from a temporary SimpleConfigurable objectslike in:

int a = SimpleConfigurable<int>(0,"A");

which will initialise a to zero or to the value associated to ”A” if defined. This practice is discouraged. Infactit works fine in batch, where the input comes only from configuration files which are read once when thefirst configurable object is instanciated, but it does not work interactively as “a” is not bound in any way tothe keywork ”A” and will not be modified by a later command.

If a class C defines set and get methods, external iostream operators can be defined and a SimpleConfig-urable¡C¿ could be used. See class C in Utilities/UI/test/UIexample.cpp.

If an object of such a class is instantiated out of our control we can still bound it to a UI record using aUI-envelope class. See class CUI in Utilities/UI/test/UIexample.cpp.

Other, more complex ways, to achieve non intrusive UI are presented in Utilities/UI/test/NItest.cpp.

16.1.5 Advanced Usage

Any user can derive its own Configurable class from BaseConfigurable just reimplementing the virtual getand set methods. The UUI package provides two additional template class for the common case of vectorsand enumerators. Please refer to the reference manual and to Utilities/UI/test/SimpleConfigtest.cpp formore details about their usage.

Part IV

Appendices

157

Appendix A

Using Objectivity commands (Examples)

To initialise your shell for the use of Objectivity commands do:

source $CMS_PATH\utils\objyenv.csh

This is a sample session illustrating the use of certain Objectivity commands. It is not a tutorial per se,but you can repeat the steps here to see things in action for yourself. All the Objectivity commands acceptthe ’-help’ argument, which is normally enough to understand enough to use them. In this session, I createa shallow copy of a federation, add and delete databases, and move them around in the filesystem. Finally, Ihave an example of removing stale locks. The output of the Objectivity commands is somewhat abridged tosave trees.

First I check that the AMS and lockserver are running on my desktop machine (pctony.cern.ch). Thelockserver is there, but I have to start the AMS myself.

:˜> oocheckamsAMS is not running on ’pctony’.:˜> oochecklsThe Lock Server is running on ’pctony’.:˜> oostartamsThe AMS has been started (process ID = 29095).

Next I create a shallow copy of an existing federation on my desktop. I create a subdirectory for it, ’cd’into it, copy the bootfile and the federation file and use ’ooinstallfd’ to make it into a real federation insteadof just a pair of copied files. The first attempt fails because I did not create the journal directory. The’ooinstallfd’ command will not make the directory for me. After creating the journal directory, ’ooinstallfd’succeeds.

:˜> mkdir myfed:˜> cd myfed:myfed> rfcp cmsuf01:/cms/reconstruction/user/jetDIGI0300/jetDIGI0300.boot .272 bytes in 0 seconds through eth0 (in) and local (out):myfed> rfcp cmsuf01:/cms/reconstruction/user/jetDIGI0300/jetDIGI0300.FDDB .9895936 bytes in 12 seconds through eth0 (in) and local (out) (805 KB/sec):myfed> ooinstallfd -fdnumber 2907 -lockserverhost pctony -jnldirpath \/users/wildish/myfed/journal -nocatalog -nocheck \

159

160 APPENDIX A. USING OBJECTIVITY COMMANDS (EXAMPLES)

/users/wildish/myfed/jetDIGI0300.bootUpdating Name Service values...** System Error #3036: Lock Server cannot auto-recover FD. Please verify that

the account running the Lock Server has permission toaccess all the database files and the journal directory.You may need to recover this FD manually. Please checkthe Lock Server log file.

** System Error #2502: Object Manager is unable to start a new transaction** Error #2921: ooinstallfd : Unable to open the Federated Database

"/users/wildish/myfed/jetDIGI0300.boot". Processing terminated.** Error #2928: ooinstallfd : An error has occurred. Processing terminated.

:myfed> mkdir journal:myfed> ooinstallfd -fdnumber 2907 -lockserverhost pctony \-jnldirpath /users/wildish/myfed/journal -nocatalog \-nocheck /users/wildish/myfed/jetDIGI0300.bootUpdating Name Service values...Now updating System Name Space (catalog) values...WARNING: Updating of Database File locations will be skipped...

Federated Database Installation complete.

The federation has been installed locally, as shown by ’oodumpcatalog’. I now have my shallow copy. IfI add or create databases in this federation they will not be known to other federations.

:myfed> oodumpcatalog jetDIGI0300.boot | head -20FD Name = jetDIGI0300FD ID = 2907FD File = pctony::/users/wildish/myfed/jetDIGI0300.FDDBBoot File = pctony::/users/wildish/myfed/jetDIGI0300.bootJnl Dir = pctony::/users/wildish/myfed/journalLock Host = pctony

DB Name = CARF_System.META.jetmetSignal0300DB ID = 11DB Image = cmsuf01::/cms/reconstruction/user/jetDIGI0300/CARF_System.META.jetmetSignal0300.jetmetHitPU.DB

DB Name = LogBook.META.jetmetSignal0300DB ID = 12DB Image = cmsb19::/shift/cmsb19/data0/reconstruction/userfeds/jetDIGI0300/./LogBook.META.jetmetSignal0300.jetmetHitPU.DB

If I create a new database with the ’oonewdb’ command, we can see that the file is created and attachedto the federation. Again I use ’oodumpcatalog’ to show this. Normally you would not create databases likethis, CARF and ORCA between them will create the databases as needed. After creating the database I usethe ’oofile’ command to check its attributes. I can get the pagesize and the DBID.

:myfed> oonewdb -db MyTest jetDIGI0300.bootCreated Database MyTest [DBID = 1903].:myfed> oodumpcatalog jetDIGI0300.boot | grep -C 1903

DB Name = MyTest

161

DB ID = 1903DB Image = pctony::/users/wildish/myfed/MyTest.jetDIGI0300.DB

:myfed> oofile MyTest.jetDIGI0300.DBAttempting to interpret the file...

Data format : LinuxDatabase format compatible with Objectivity release 4.0.10 through 5.x

File Type : DatabaseDB ID : 1903Page Size : 32768

You may only attach this Database file to a Federated Database with thesame Page Size and Schema.

***************************WARNING*************************** You should verify that this file does not belong to an ** active Federated Database before moving or modifying it. *************************************************************

Now I delete the database from my federation. I use the ’oodeletedb’ command, with the ’-catalogonly’flag to ensure that the file is not deleted from the disk.

:myfed> oodeletedb -catalogonly -db MyTest jetDIGI0300.bootAre you sure you want to delete the Database?[Y-N]=> y

Deleted the Database "MyTest" (ID = 1903) from the Federated Database catalog.

’ls -l’ shows the database file is still there, but the database entry has gone from the catalogue.

:myfed> ls -ltotal 10158-rw-rw-rw- 1 wildish zh 1867776 Oct 8 17:45 MyTest.jetDIGI0300.DB-rwxr-xr-x 1 wildish zh 9895936 Oct 8 17:46 jetDIGI0300.FDDB-rw-r--r-- 1 wildish zh 202 Oct 8 17:40 jetDIGI0300.bootdrwxr-xr-x 2 wildish zh 1024 Oct 8 17:46 journal

Now I can re-attach the database to my federation. If I specified a different federation bootfile, I couldattach my federation there instead (providing that DBID 1903 was not already taken!).

:myfed> ooattachdb -id 1903 -db MyTest \-filepath /users/wildish/myfed/MyTest.jetDIGI0300.DB \-host pctony jetDIGI0300.bootFirst pass through ...Attaching database...MyTest

Second pass through ...Attaching database...MyTest


Now for one of the ways to move the database file to a different directory. I create the directory, movethe database file using standard unix commands, but then I have to tell the federation where to find it. Usingthe ’oochangedb’ command I specify the new filepath for this database in the federation catalogue. Again Ihave to use the ’-catalogonly’ flag to do this, because Objectivity runs a variety of checks and will complainif the file is not there. Although you can use the ’-catalogonly’ flag (and others) with many commands tocircumvent some of the checks that Objectivity performs, it is not a good idea to do so without a bit ofreflection. There is a reason Objectivity checks things!

:myfed> mkdir mytags:myfed> mv MyTest.jetDIGI0300.DB mytags/:myfed> oochangedb -db MyTest -filepath \/users/wildish/myfed/mytags/MyTest.jetDIGI0300.DB -host pctony jetDIGI0300.boot \-catalogonly:myfed> oodumpcatalog jetDIGI0300.boot | grep -C 1903DB Name = MyTestDB ID = 1903DB Image = pctony::/users/wildish/myfed/mytags/MyTest.jetDIGI0300.DB

Now for detecting and removing stale locks. Stale locks are locks that are left behind by processes thatdie abnormally. The easiest way to show this is to use ’ootoolmgr’ to view the federation, and select ’Browse’from the ’Tools’ menu. This will create two read locks. Then kill the ’ootoolmgr’ process with the -KILLsignal, and attempt to clean up the locks afterwards. Then use ’oolockmon’ to see the locks. After I kill’ootoolmgr’ I use ’oocleanup’ and give it the transaction ID to tell it which transaction to attempt to recover.

:myfed> ootoolmgr jetDIGI0300.boot &[1] 29842:myfed> oolockmon jetDIGI0300.bootLock Table for Lock Server on node "pctony" - your UID is 2907

UID HostID PID TransID APID Mode Type FdbID DbID OclID---------------------------------------------------------------------2907 pctony 29842 1310719 65535 read Ocl 2907 1 42907 pctony 29842 1310719 65535 read Ocl 2907 1 3

Lock table displayed, 2 entries.

The toolmgr PID is given as 29842. I kill it, brutally, and the locks remain?

:myfed> kill -KILL 29842:myfed> oolockmon jetDIGI0300.bootLock Table for Lock Server on node "pctony" - your UID is 2907


Lock table displayed, 2 entries.

163

The locks are still there, so I clean up with the transaction ID. ’oolockmon’ then shows that the lockshave been removed.

:myfed> oocleanup -transaction 1310719 jetDIGI0300.bootRecovered transaction 1310719 for FD "jetDIGI0300.boot".

Finished processing all autonomous partitions.

Finished attempting to recover all specified transactions.

:myfed> oolockmon jetDIGI0300.bootLock Table for Lock Server on node "pctony" - your UID is 2907

UID HostID PID TransID APID Mode Type FdbID DbID OclID---------------------------------------------------------------------

Lock table displayed, no entries.

I can use the ’oocleanup’ command in another way. Instead of having to find the transaction ID for allthe transactions that are in process, I can tell it to clean up all transactions that were started locally, i.e. onthis host.

:myfed> ootoolmgr jetDIGI0300.boot &[1] 29854:myfed> oolockmon jetDIGI0300.bootLock Table for Lock Server on node "pctony" - your UID is 2907


Lock table displayed, 2 entries.:myfed> oocleanup -local jetDIGI0300.bootRecovering local transactions for FD "jetDIGI0300.boot" on host "pctony".** Error #3104: oocleanup: Failed to recover transaction 1507327 for FD

"jetDIGI0300.boot". Error #0: .

Finished processing all autonomous partitions.

Finished attempting to recover all specified transactions.

:myfed> oolockmon jetDIGI0300.bootLock Table for Lock Server on node "pctony" - your UID is 2907

UID HostID PID TransID APID Mode Type FdbID DbID OclID---------------------------------------------------------------------

Lock table displayed, no entries.

That’s all for now. Don’t forget the ’-help’ argument, and, of course, those fine manuals.

Appendix B

Changing from ORCA 3 to ORCA 4

This chapter is intended to give a brief instruction on how to change a working ORCA 3 user code to theORCA 4 way of beeing.

B.1 General changes

Replace

#include "CARF/G3SimEvent/interface/SimEvent.h"

by

#include "CARF/SimEvent/interface/SimEvent.h"

G3EventProxy has no longer a method id(). To get the event or run number use the new SimTrig-ger() method which in turn has an id() method.

Remove from your .cppfiles almost everything and use the templated PkBuilder class to register youranalysis class.

The cruicial point when building an executable is now to select the correct libraries to link against. Tomake this easier the different subsystems define and maybe even document either in this Guide or in theReferenceManual groups of libraries that can be used for some standard tasks, e.g. makeing some kind ofcalorimetric clusters. The lines you need to add to your BuildFile are like

<Group name=whatever><Use name=theSubsystem>

In the unlikely case that you don’t find any documentation, have a look at the toplevel BuildFiles of thesubsystem. A line

ifdef GROUP_TkHitWriter

defines for instance a group of name TkHitWriter.

165

166 APPENDIX B. CHANGING FROM ORCA 3 TO ORCA 4

Appendix C

.orcarc Parameters

Name Type Default Class DescriptionEcal:SelectiveReadoutGridSize int 1 EcalSelectiveReadoutTowerConfigurablesReadout 3x3(0) or 5x5(1) tower blocksEcal:SelectiveReadoutThreshold:low float 2.5 EcalSelectiveReadoutTowerConfigurablesSet lower SR thresholdEcal:SelectiveReadoutThreshold:high float 5.0 EcalSelectiveReadoutTowerConfigurablesSet upper SR thresholdEcal:SelectiveReadoutSingles bool False EcalSelectiveReadoutTowerConfigurablesTurn singles on / offEcal:SelectiveReadoutSingles:usethreshold bool False EcalSelectiveReadoutTowerConfigurablesUse a ZS threshold(Singles)Ecal:SelectiveReadoutSingles:Barrel:threshold float 0.0 EcalSelectiveReadoutTowerConfigurablesSet barrel thresholdEcal:SelectiveReadoutSingles:Endcap:threshold float 0.0 EcalSelectiveReadoutTowerConfigurablesSet endcap thresholdEcal:SelectiveReadoutTowers:usethreshold bool False EcalSelectiveReadoutTowerConfigurablesUse a ZS threshold(Towers)Ecal:SelectiveReadoutTowers:Barrel:threshold float 0.0 EcalSelectiveReadoutTowerConfigurablesSet barrel thresholdEcal:SelectiveReadoutTowers:Endcap:threshold float 0.0 EcalSelectiveReadoutTowerConfigurablesSet endcap threshold

PSimHit:TofNormalizationFactor float 0.01 PSimHit Time of flight normalizationEgColl:Name string myColl EgammaCollections name of the user collection to be created/appended¿¿¿In case a collection of name CollName is definedthen the following parameter is available

- - - -

Collname string usernameDB/MyObjs/Collnameclassoclass the full qualified path of the collection- - - - -MCKINE PTCUT Float 1.0 MCKineAnalyzer Pt cut on Kine tracks (Chris)MCKINE BREMPTCUT float 0.1 MCKineAnalyzer Pt cut on Brem photons (Chris)- - - - -HEPL1EM PTCUT float 0.3 HepL1emTrigger Pt cut on Hep L1 particles (Chris)HEPL1EM ETIGNORE Float 2.0 HepL1emTrigger max et of ignored particles in HepL1 (Chris)HEPL1EM NCAND int 4 HepL1emTrigger no of stored HepL1 candidates (Chris)- - - - -EGBCluster::MaxEntry int 500 EgammaClusterInit Max no. of entries for BC in ntuple- - - - -EGBasicIsland:BarrelSeedThr float 0.5 EgammaBasicIsland seed thr of barrel island clustering (Et)EGBasicIsland:EndcapSeedThr float 0.18 EgammaBasicIsland seed thr of endcap island clustering (Et)- - - - -EGBLogPosBar:X0 float 0.89 EGBLogPosCorr depth parameter in pos corr for barrelEGBLogPosBar:T0 Float 5.7 EGBLogPosCorr depth constant in pos corr for barrelEGBLogPosBar:CutOff float 4.2 EGBLogPosCorr cutoff in pos corr for barrelEGBLogPosEcn:X0 float 0.89 EGBLogPosCorr depth parameter in pos corr for ecnEGBLogPosEcn:T0 float 5.7 EGBLogPosCorr depth constant in pos corr for ecnEGBLogPosEcn:CutOff float 4.2 EGBLogPosCorr cutoff in pos corr for ecnEGBLogPosEcp:X0 float 0.89 EGBLogPosCorr depth parameter in pos corr for ecpEGBLogPosEcp:T0 float 2.0 EGBLogPosCorr depth constant in pos corr for ecpEGBLogPosEcp:CutOff Float 4.2 EGBLogPosCorr cutoff in pos corr for ecp- - - - -EGLCShape:logW bool FALSE (linear

weighting if false)EgammaLogCShape use log weighting if true

EGLCShape:X0 float 0.89 EgammaLogCShape parameter of log weightingEGLCShape:T0 float 6.2 EgammaLogCShape parameter of log weightingEGLCShape:CutOff float 4.0 EgammaLogCShape parameter of log weighting- - - - -BremRecovery:BarrelEtaRoad float 0.06 EgammaBremRecovery 2*etasize of Island SC road in barrelBremRecovery:BarrelPhiRoad float 0.8 EgammaBremRecovery 2*phisize of Island SC road in barrelBremRecovery:EndcapEtaRoad float 0.14 EgammaBremRecovery 2*etasize of SC road in endcapBremRecovery:EndcapPhiRoad Float 0.4 EgammaBremRecovery 2*phisize of SC road in endcapEGSCSeedGenerator:EtCut float 4.0 EGSCSeedGenerator seed threshold for SC (Et)- - - - -EgammaIsolation:ConeSize float 0.25 IsoCalculator radius of isolation coneEgammaIsolation:GuardSize float 0.08 IsoCalculator radius of isolation guard ringEgammaIsolation:EtaSlice Float 0.05 IsoCalculator size of avoided eta slice in isolationEgammaIsolation:Chi2Cut float 30 IsoCalculator —-EgammaIsolation:GetEtSum bool false (maxet if false) IsoCalculator get sumet if true- - - - -EgPixelIsolation:ConeSize float 0.4 EgammaPixelReconstruction (eta,phi) cone size for Pixel-line counting isolationEgPixelIsolation:ZSpan float 0.1 EgammaPixelReconstruction z region around PV for Pixel-line counting isolation- - - - -PRESHSEEDED NSTR int 15 EgammaPreshSeeded no of strips in presh seeded clusterPRESHOWER NCLUST int 4 EgammaEndcapAssociation no of preshower clusters matching a basic clusterENDCAP SEED THR float 0.0 EgammaEndcapAssociation seed thr for endcap association- - - - -PRESH1 PLANE1 float 1./0.00009 EgammaEndcapCluster plane1 preshower constant (Teresa)PRESH2 PLANE2 float 0.6/0.00009 EgammaEndcapCluster plane2 preshower constant (Teresa)PRESH CALIB float 0.028 EgammaEndcapCluster preshower calibrations constant (Teresa)- - - - -

167

168 APPENDIX C. .ORCARC PARAMETERS

Name Type Default Class DescriptionL1Sele:SingleEMEtThr float 0.0 (no cut) EgammaL1Selection Single em L-1 thresholdL1Sele:DoubleEMEtThr1 float 0.0 (no cut) EgammaL1Selection Double em L-1 threshold (1st)L1Sele:DoubleEMEtThr2 float 0.0 (no cut) EgammaL1Selection Double em L-1 threshold (2nd)L1Sele:DoubleEMEtRelaxedThr1 float 0.0 (no cut) EgammaL1Selection L1 trigger threshold on leg1 of relaxed double em (no isolation)L1Sele:DoubleEMEtRelaxedThr2 float 0.0 (no cut) EgammaL1Selection L1 trigger threshold on leg2 of relaxed double em (no isolation)L1Sele:SingleIso bool true EgammaL1Selection L-1 Isolation on single em candidateL1Sele:DoubleIso bool true EgammaL1Selection L-1 Isolation on double em candidateL1L2Assoc:PhiSize Float 1.044 EgammaL1L2Associator 2*phi window for association of L-2 candidates to L-1L1L2Assoc:EtaSizeB Float 0.522 EgammaL1L2Associator 2*eta window for association of L-2 candidates to L-1L1L2Assoc:EtaSizeE Float 0.87 EgammaL1L2Associator 2*eta window for association of L-2 candidates to L-1L1L2Assoc:InFiducial bool false EgammaL1L2Associator Only create L2 candidates in fiducial region if TRUEL2Sele:sngEt1 Float L1Sele:SingleEMEtT EgammaL2Selection Et threshold for single em candidates at L-2L2Sele:dblEt1 Float L1Sele:DoubleEMEtThr1 EgammaL2Selection Et threshold for double em candidate 1 at L-2L2Sele:dblEt2 Float L1Sele:DoubleEMEtThr2 EgammaL2Selection Et threshold for double em candidate 2 at L-2- - - - -EGBClusters:PositionCorrect bool true EgammaBasicReco perform basic clustering corrections- - - - -EgammaEvent:forceNotify bool false EgammaEvent recostruction on demand only when false, reconstruction forced

when true- - - - -EGCG:HistoSwitch bool true EgammaControlGrabber switch on/off general ntupleEgammaCWNname string egamma.hbook EgammaHbook4Histogrammer filename of the hbook output file (replaces

EGAMMAC W NN AMEenvironmentvariable(stillusable))EGBR:HistoSwitch bool true EgammaBasicReco switch on histogramsEGR:HistoSwitch bool true EgammaReco switch on SC ntuple blockEGMC:HistoSwitch bool true EgammaMC switch on ntuple entries for MC/HepL2EGL1:HistoSwitch bool true L1Selector switch on L1 block in ntupleEGL2:HistoSwitch bool true L2Selector switch on L2 block in ntuple- - - - -EgEcAssoc:HistoPS bool true EgammaEndcapAssociation ECP ntuple block booking/filling- - - - -- - - - -Level1:EleEtCut float 2. Level1EtCut L-1 Et cut on electron candidatesLevel1:TauJetEtCut float 2. Level1EtCut L-1 Et cut on tau candidatesLevel1:CenJetEtCut float 2. Level1EtCut L-1 Et cut on Central jetsLevel1:FwdJetEtCut float 2. Level1EtCut L-1 Et cut on Forward jets- - - - -EGBHybridPosBar:X0 float 0.87 EGBHybridCorrection obsoleteEGBHybridPosBar:T0 float 5.1 EGBHybridCorrection obsoleteEGBHybridPosBar:CutOff float 4. EGBHybridCorrection obsolete- - - - -EgammaBasicDynamic:Verbosity int Verbose::InfoLevel EgammaBasicDynamic This is an output filtering level, going from 1 to 8. With value

1, one will get all the ouput from EgammabasicDynamic. Withvalue 8, one will get only the most important messages.

EgammaBasicDynamic:SeedThreshold float 33.33 EgammaBasicDynamic Minimal energy before a crystal can be the seed of a new cluster.- - - - -EGMC:HepLevel1Switch bool true EgammaMC switch on HepL1- - - - -ElectronFacilities:Hooks string off EFHooksHandler The value can be ”off” or ”on”. If ”on”, the callbacks attached

to the hooks handlers will be invoked. If ”off”, this mechanismis not active and there should be no performance penalty.

- - - - -ElectronFacilities:Setup:Strategy string basic EFSetup The value can be ”basic” or ”best”. This specify which set of

algorithms must be built by the automatic setup.- - - - -ElectronFacilities:Verbosity int ep::threshold() All classes from package Elec-

tronFacilities, except the SHones

This is an output filtering level, going from 1 to 8. With value 1,one will get all the ouput from the classes of the package. Withvalue 8, one will get only the most important messages. If not set,the default threshold is the one of the subsystem (see Electron-Photon:Verbosity).

- - - - -ElectronPhoton:Verbosity int Verbose::InfoLevel Potentially all classes from sub-

system ElectronPhoton, exceptthe ones that have their ownthreshold.

This is an output filtering level, going from 1 to 8. With value 1,one will get all the ouput from the classes of the package. Withvalue 8, one will get only the most important messages. Someother output filtering levels use this one as their default value.

- - - - -ShowerSim:Verbosity int ep::threshold() All classes from package Elec-

tronFacilities that concernshower simulation, with a namestarting with ”SH”.

This is an output filtering level, going from 1 to 8. With value 1,one will get all the ouput from the classes of the package. Withvalue 8, one will get only the most important messages. If not set,the default threshold is the one of the subsystem (see Electron-Photon:Verbosity).

- - - - -EPHitMatch:ePhiMin1 float -0.3 EPHLTMatchSeedGenerator 1rst search lower phi limit for electron candidateEPHitMatch:ePhiMax1 float 0.02 EPHLTMatchSeedGenerator 1rst search higher phi limit for electron candidateEPHitMatch:pPhiMin1 float -0.02 EPHLTMatchSeedGenerator 1rst search lower phi limit for positron candidateEPHitMatch:pPhiMax1 float 0.03 EPHLTMatchSeedGenerator 1rst search higher phi limit for positron candidateEPHitMatch:PhiMin2 float -0.001 EPHLTMatchSeedGenerator 2ond search lower phi limitEPHitMatch:PhiMax2 float 0.001 EPHLTMatchSeedGenerator 2ond search higher phi limitEPHitMatch:ZMin1 float -15.0 EPHLTMatchSeedGenerator 1rst search lower z limitEPHitMatch:ZMax1 float 15.0 EPHLTMatchSeedGenerator 1rst search higher z limitEPHitMatch:ZMin2 float -0.05 EPHLTMatchSeedGenerator 2ond search lower z limitEPHitMatch:ZMax2 float 0.05 EPHLTMatchSeedGenerator 2ond search higher z limit- - - - -ElectronTrack:SeedGenerator bool true EPHLTTrackReconstructor -ElectronTrack:TrajectoryBuilder bool true EPHLTTrackReconstructor -ElectronTrack:Smoother bool true EPHLTTrackReconstructor -ElectronTrack:UpdatorChi2Max float 5. EPHLTTrackReconstructor x2cut on trajectory updateElectronTrack:SmootherChi2Max float 100. EPHLTTrackReconstructor x2cut on trajectory smoothing- - - - -EPHitMatch:ePhiMin1 float -0.03 EPMatchSeedGenerator obsoleteEPHitMatch:ePhiMax1 float 0.02 EPMatchSeedGenerator obsoleteEPHitMatch:pPhiMin1 float -0.02 EPMatchSeedGenerator obsoleteEPHitMatch:pPhiMax1 float 0.03 EPMatchSeedGenerator obsoleteEPHitMatch:PhiMin2 float -0.001 EPMatchSeedGenerator obsoleteEPHitMatch:PhiMax2 float 0.001 EPMatchSeedGenerator obsoleteEPHitMatch:ZMin1 float -15.0 EPMatchSeedGenerator obsoleteEPHitMatch:ZMax1 float 15.0 EPMatchSeedGenerator obsoleteEPHitMatch:ZMin2 float -0.05 EPMatchSeedGenerator obsoleteEPHitMatch:ZMax2 float 0.05 EPMatchSeedGenerator obsolete- - - - -ElectronFromPixels:Setup:Strategy string pixels EPSetup This specify which set of algorithms must be built by the auto-

matic setup.

169

Name Type Default Class Description- - - - -RecApplication:InputUserCollection string collection EgammaStatistics -- - - - -ElectronFacilities:Associator:EtThreshold float 2. EFKernel Minimum cluster transverse energy to build a new track-cluster

associationElectronFacilities:Associator:ConeSizeEta float 0.1/sqrt(2) EFKernel Maximum eta distance between the track extrapolation to the

Ecal entry face and the cluster position (uncorrected) to build anew track-cluster association

ElectronFacilities:Associator:ConeSizePhi float 0.1/sqrt(2) EFKernel Maximum phi distance between the track extrapolation to theEcal entry face and the cluster position (uncorrected) to build anew track-cluster association

ElectronFacilities:Associator:EpCut float 0.5 EFKernel Maximum E/p deviation from 1 between the track momentumextrapolated to the Ecal entry face and the cluster energy (un-corrected) to build a new track-cluster association

ElectronFacilities:Associator:HadVeto bool 1 EFKernel Switch to include or not hadronic veto to build a new track-cluster association

ElectronFacilities:Associator:HadEmCut float 0.1 EFKernel The maximum value of the hadronic over electromagnetic energyratio to build a new track-cluster association. Only used if Elec-tronFacilities:Associator:HadVeto is 1 . The hadronic energy isthe sum of the hadronic tower energies over the set of all tow-ers that have a geometrical part behind an Ecal Xtal from theelectromagnetic cluster.

- - - - -ElectronFacilities:Discriminator:Chi2ThetaCut float 0.1 EFKernel Maximum value of chi2 between track extrapolated to Ecal entry

face theta position and cluster corrected theta position to buildan electron from the track-cluster association

ElectronFacilities:Discriminator:Chi2PhiEpCut float 0.1 EFKernel Maximum deviation from 1 of the electromagnetic cluster cor-rected energy over the track momentum at Ecal entry face ratioto build an electron from the track-cluster association

ElectronFacilities:BremsFinder:MultiplicityCut int 1 EFKernel Minimum number of Ecal crystals in a cluster to be consideredas a bremsstrahlung cluster candidate

ElectronFacilities:BremsFinder:ToleranceEta float 0.01745 EFKernel Maximum deviation in eta from the eta size of the road used inbremsstrahlung search

ElectronFacilities:BremsFinder:TolerancePhi float 0.01745 EFKernel Maximum deviation in phi from the phi size of the road used inbremsstrahlung clusters search

- - - - -ElectronFacilities:Chi2PhiEpQualifier:Errors bool false EFKernel Switch to include errors in the Chi2 calculation from the two

variables phi and E/p when using the corresponding qualifier tobuild an electron from a track-cluster association.

ElectronFacilities:Chi2PhiEpQualifier:FullCorrelations bool false EFKernel Switch to include non diagonal terms in the Chi2 calculationfrom the two variables phi and E/p when using the correspondingqualifier to build an electron from a track-cluster association.

ElectronFacilities:Chi2PhiEpQualifier:PChi2 bool false EFKernel Switch to use Chi2 probability instead of Chi2 value in Chi2 cal-culation from the two variables phi and E/p when using the cor-responding qualifier to build an electron from a track-cluster as-sociation.

ElectronFacilities:Chi2ThetaPhiEpQualifier:Errors bool false EFKernel Switch to include errors in the Chi2 calculation from the threevariables theta, phi and E/p when using the corresponding qual-ifier to build an electron from a track-cluster association.

ElectronFacilities:Chi2ThetaPhiEpQualifier:FullCorrelationsbool false EFKernel Switch to include non diagonal terms in the Chi2 calculationfrom the three variables theta, phi and E/p when using the cor-responding qualifier to build an electron from a track-cluster as-sociation.

ElectronFacilities:Chi2ThetaPhiEpQualifier:PChi2 bool false EFKernel Switch to use Chi2 probability instead of Chi2 value in Chi2 cal-culation from the three variables theta, phi and E/p when usingthe corresponding qualifier to build an electron from a track-cluster association.

ElectronFacilities:Chi2ThetaQualifier:Errors bool false EFKernel Switch to include errors in the Chi2 calculation from the thetavariable when using the corresponding qualifier to build an elec-tron from a track-cluster association.

ElectronFacilities:Chi2ThetaQualifier:PChi2 bool false EFKernel Switch to use Chi2 probability instead of Chi2 value in Chi2 cal-culation from the theta variable when using the correspondingqualifier to build an electron from a track-cluster association

- - - - -ElectronFacilities:ClusterCovarianceMatrix:ScalingFactorfloat 1. EFKernel A scaling factor applied on cluster covariance matrix.- - - - -ElectronFacilities:ElectronTrack:SeedClusterEtMin float 5. EFKernel The minimum transverse energy of an electromagnetic cluster to

build an electron track seed. Only used with the SeededTrack-Reconstructor.

ElectronFacilities:ElectronTrack:SeedEstimatorChi2Max float 0.1 EFKernel The maximum chi2 between a pixel hit and the extrapolation ofthe helix built from the calorimetric cluster to retain the pixel hitas a compatible hit. Only used with the SeededTrackreconstruc-tor.

ElectronFacilities:ElectronTrack:SeedUpdatorChi2Max float 1. EFKernel The maximum chi2 between the predicted position on pixel layerand the measured hit position to build an electron track seed.Only used with the SeededTrackReconstructor.

ElectronFacilities:ElectronTrack:SeedPtMin float 5. EFKernel The minimum transverse momentum of the track seed to retainit as an electron track seed. Only used with the SeededTrackRe-constructor.

ElectronFacilities:ElectronTrack:SeedEtaMax float 2.5 EFKernel The maximum absolute eta value of the track seed to retain it asan electron track seed. Only used with the SeededTrackRecon-structor.

- - - - -ElectronFacilities:ElectronTrack:SeedGenerator bool 1 EFKernel A switch to select or not seed generation. Only used with the

SeededTrackReconstructor.ElectronFacilities:ElectronTrack:TrajectoryBuilder bool 1 EFKernel A switch to select or not trajectory building. Only used with the

SeededTrackReconstructor.ElectronFacilities:ElectronTrack:Smoother bool 1 EFKernel A switch to select or not trajectory smoothing. Only used with

the SeededTrackReconstructor.ElectronFacilities:ElectronTrack:MediumProperties bool 0 EFKernel A switch to use dedicated electron track medium properties in-

stead of standard ones.- - - - -ElectronFacilities:ElectronTrack:UpdatorChi2Max float 100. EFKernel The maximum Chi2 value between the predicted state and the

measured state in the trajectory building.ElectronFacilities:ElectronTrack:SmootherChi2Max float 100. EFKernel The maximum Chi2 value between the predicted state and the

measured state in the trajectory smoothing.- - - - -ShowerSim:MagneticField bool 1 SHKernel Switch to include magnetic field correction in the shower model.- - - - -ElectronFromPixels:Associator:EpCut float 0.5 EPKernel Maximum E/p deviation from 1 between the track momentum

extrapolated to the Ecal entry face and the cluster energy (un-corrected) to build a new track-cluster association. Used in Elec-tronFromPixels associators.


Name Type Default Class DescriptionElectronFromPixels:Associator:HadVeto bool 1 EPKernel Switch to include or not hadronic veto to build a new track-

cluster association. Used in ElectronFromPixels associators.ElectronFromPixels:Associator:HadEmCut float 0.1 EPKernel The maximum value of the hadronic over electromagnetic energy

ratio to build a new track-cluster association. Only used if Elec-tronFacilities:Associator:HadVeto is 1 . The hadronic energy isthe sum of the hadronic tower energies over the set of all towersthat have a geometrical part behind an Ecal Xtal from the elec-tromagnetic cluster. Used in ElectronFromPixels associators.

- - - - -ElectronFromPixels:ElectronTrack:SeedClusterEtMin float 5. EPKernel The minimum transverse energy of an electromagnetic cluster to

build an electron track seed. Only used with the SeededTrackRe-constructor. Used by ElectronfromPixels track reconstructors.

ElectronFromPixels:ElectronTrack:SeedEstimatorChi2Maxfloat 0.1 EPKernel The maximum chi2 between a pixel hit and the extrapolation ofthe helix built from the calorimetric cluster to retain the pixel hitas a compatible hit. Used by ElectronFromPixels track recon-structors.

ElectronFromPixels:ElectronTrack:SeedUpdatorChi2Max float 1. EPKernel The maximum chi2 between the predicted position on pixel layerand the measured hit position to build an electron track seed.Used by ElectronFromPixels track reconstructors.

ElectronFromPixels:ElectronTrack:SeedPtMin float 5. EPKernel The minimum transverse momentum of the track seed to retainit as an electron track seed. Used by ElectronFromPixels trackreconstructor.

ElectronFromPixels:ElectronTrack:SeedEtaMax float 2.5 EPKernel The maximum absolute eta value of the track seed to retain it asan electron track seed. Used by ElectronFromPixels track recon-structors.

- - - - -ElectronFromPixels:ElectronTrack:SeedGenerator bool 1 EPKernel A switch to select or not seed generation. Used by Electron-

FromPixels track reconstructors.ElectronFromPixels:ElectronTrack:TrajectoryBuilder bool 1 EPKernel A switch to select or not trajectory building. Used by Electron-

FromPixels track reconstructors.ElectronFromPixels:ElectronTrack:Smoother bool 1 EPKernel A switch to select or not trajectory smoothing. Used by Electron-

FromPixels track reconstructors.- - - - -ElectronFromPixels:ElectronTrack:UpdatorChi2Max float 100. EPKernel The maximum Chi2 value between the predicted state and the

measured state in the trajectory building. Used by Electron-FromPixels track reconstructors.

ElectronFromPixels:ElectronTrack:SmootherChi2Max float 100. EPKernel The maximum Chi2 value between the predicted state and themeasured state in the trajectory smoothing. Used by Electron-FromPixels track reconstructors.

ExDumpRunEvent:ReadPileup bool 0 (false) ExDumpRunEventRecReader Control the printout of run/event numbers for pileup events.

JetMetAnalysis:MemoryDebug int 0 JetMetAnalysisSetup Debugging memory.JetMetAnalysis:JetDebug int 0 JetMetAnalysisSetup Debugging JetMetJetFinders.JetMetAnalysis:GeneratorDebug int 0 JetMetAnalysisSetup Debugging JetMetGeneratorInterface.JetMetAnalysis:GeneratorPrint int 0 JetMetAnalysisSetup Prints detailed information about generator particles .JetMetAnalysis:CaloDebug int 0 JetMetAnalysisSetup Debugging JetMetCalorimetry.JetMetAnalysis:CaloDigiPrint int 0 JetMetAnalysisSetup Detailed information about calorimeter digis ( ECAL crystals,

HCAL compartments, preshower compartments ) into the logfile.

JetMetAnalysis:ReadCaloHits int 0 JetMetAnalysisSetup The job reads calorimeter hits, and does a simple analysis ofthem.

JetMetAnalysis:EcalBarrelDigiECut double 0.06 JetMetAnalysisSetup Et threshold ( GeV ) of ECAL barrel digis to be analyzed.JetMetAnalysis:EcalEndCapDigiECut double 0.30 JetMetAnalysisSetup Et threshold ( GeV ) of ECAL endcap digis to be analyzed.JetMetAnalysis:HcalDigiECut double 0.01 JetMetAnalysisSetup Et threshold ( GeV ) of HCAL digis to be analyzed.JetMetAnalysis:PreshowerDigiECut double 0.01 JetMetAnalysisSetup Et threshold ( GeV ) of preshower digis to be analyzed.JetMetAnalysis:MinimumDigiEta double -7. JetMetAnalysisSetup Minimum value of η of ( calorimeter ) digis to be analyzed.JetMetAnalysis:MaximumDigiEta double +7. JetMetAnalysisSetup Maximum value of η of ( calorimeter ) digis to be analyzed.JetMetAnalysis:EcalPlusHcalTowerEtAlert double 200. JetMetAnalysisSetup Prints an alert line if a tower Et is above this threshold.JetMetAnalysis:L1CaloDebug int 0 JetMetAnalysisSetup Debugging JetMetL1CaloTrigger.JetMetFast:NtupleName string jetmetfast.ntup FastAnalysis, FastObserver-

AnalysisThe name of the JetMetFast paw ntuple.

JetMetFast:NumberOfEvents int 10 FastAnalysis Number of events to be generated, simulated and analyzed by thestandalone ( non COBRA ) program .

JetMetFastAnalysis:Debug int 0 FastObserverAnalysis Debug.JetMetFastDetector:MagneticField double 4.0 FastCalorimeter Magnetic field in Tesla.JetMetFastDetector:NumberOfForwardTowers int 4 FastCalorimeter Number of towers ( η size is 0.5 ) in the forward calorimeter ( HF

). The default value is the recent design of 4 towers ( 3 < |η|5).

JetMetFastDetector:Debug int 0 FastPathFinder,FastEnergyReconstructorDebug.JetMetFastDetector:RelativeEnergyResolutionScale double 1.0 FastEnergyReconstructor Scales all the energy resolution values with respect to the trigger

and HCAL TDR.JetMetFastDetector:eResponseScale double 3.0 FastEnergyReconstructorJetMetFastDetector:eResponsePlateau double 0.95 FastEnergyReconstructorJetMetFastDetector:eResponseExponent double 1.0 FastEnergyReconstructorJetMetFastDetector:eResponseCoefficient double 1.0 FastEnergyReconstructorJetMetFastGenerator:DoubleParticleEtaMin double -5. FastDoubleParticleGenerator Minimum η of particles to be generated.JetMetFastGenerator:DoubleParticleEtaMax double +5. FastDoubleParticleGenerator Maximum η of particles to be generated.JetMetFastGenerator:DoubleParticlePhiMin double −Π FastDoubleParticleGenerator Minimum Φ of particles to be generated.JetMetFastGenerator:DoubleParticlePhiMax double +Π FastDoubleParticleGenerator Maximum Φ of particles to be generated.JetMetFastGenerator:DoubleParticleEtMin double 10. FastDoubleParticleGenerator Minimum Et of particles to be generated.JetMetFastGenerator:DoubleParticleEtMax double 10.001 FastDoubleParticleGenerator Maximum Et of particles to be generated.JetMetAnalysis:NtupleName string JetMet.ntup JetMetPawNtupleSetup The name of the standard JetMet paw ntuple.JetMetAnalysis:GENPARTtoNtuple int 1 JetMetPawNtupleSetup Generated particles are put to the GENPART block of the ntuple.JetMetAnalysis:GENVERTtoNtuple int 1 JetMetPawNtupleSetup Generated vertices are put to the GENVERT block of the ntuple.JetMetAnalysis:PILEUPtoNtuple int 1 JetMetPawNtupleSetup Generated pile-up information is put to the PILEUP block of the

ntuple.JetMetAnalysis:HLTBINtoNtuple int 1 JetMetPawNtupleSetup Compact pile-up information needed by event weighting is put to

the HLTBIN block of the ntuple.JetMetAnalysis:GENJET5toNtuple int 1 JetMetPawNtupleSetup Generated jets ( first set ) are put to the GENJET5 block of the

ntuple.JetMetAnalysis:GENJET7toNtuple int 1 JetMetPawNtupleSetup Generated jets ( second set ) are put to the GENJET7 block of

the ntuple.JetMetAnalysis:GENMETtoNtuple int 1 JetMetPawNtupleSetup Generated missing Et is put to the GENMET block of the ntu-

ple.JetMetAnalysis:TOWERtoNtuple int 1 JetMetPawNtupleSetup Offline trigger towers ( EcalPlusHcalTower ) are put to the

TOWER block of the ntuple.JetMetAnalysis:TOWSLICEtoNtuple int 1 JetMetPawNtupleSetup Unclustered ( out-of-jet ) offline trigger tower sums ( EcalPlusH-

calTower ) are put to the TOWSLICE block of the ntuple, theyare useful to develop corrected missing Et algorithms from thentuple.

JetMetAnalysis:EMCLUStoNtuple int 1 JetMetPawNtupleSetup EgammaBasicCluster’s are put to the EMCLUS block of the ntu-ple.

171

Name Type Default Class DescriptionJetMetAnalysis:MIDJET5toNtuple int 1 JetMetPawNtupleSetup First set of reconstructed jets are put to the JET5 block of the

ntuple.JetMetAnalysis:JET5toNtuple int 1 JetMetPawNtupleSetup First set of reconstructed jets of the iterative cone algorithm are

put to the JET5 block of the ntuple.JetMetAnalysis:JET7toNtuple int 1 JetMetPawNtupleSetup Second set of reconstructed jets of the iterative cone algorithm

are put to the JET7 block of the ntuple.JetMetAnalysis:METtoNtuple int 1 JetMetPawNtupleSetup Reconstructed missing Et is put to the MET block of the ntuple.JetMetAnalysis:L1JETtoNtuple int 1 JetMetPawNtupleSetup First level calorimeter ( and muon ) objects are put to the L1JET

block of the ntuple.JetMetAnalysis:L1METtoNtuple int 1 JetMetPawNtupleSetup First level missing Et is put to the L1MET block of the ntuple.JetMetAnalysis:SPHERItoNtuple int 0 JetMetPawNtupleSetup Generated and reconstructed sphericity values are put to the

SPHERI block of the ntuple.JetMetAnalysis:FOXWOLFtoNtuple int 0 JetMetPawNtupleSetup Generated and reconstructed Fox-Wolfram momenta are put to

the FOXWOLF block of the ntuple.JetMetAnalysis:AVEDIGItoNtuple int 0 JetMetPawNtupleSetup Average quantities calculated from calorimeter digis are put to

the AVEDIGI block of the ntuple.JetMetAnalysis:DIGItoNtuple int 0 JetMetPawNtupleSetup Calorimeter digis are put to the DIGI block of the ntuple. It is

very space consuming, useful mainly for single or double particlecases only.

JetMetAnalysis:TRIGPRIMtoNtuple int 0 JetMetPawNtupleSetup Calorimeter trigger primitives are put to the TRIGPRIM blockof the ntuple.

JetMetJetFinder:Debug int 0 JetMetJetFinderSetup Debugging level.JetMetJetFinder:JetAlgorithmNumber int 1 JetMetJetFinderSetup The algorithm used to find jets ( 1 = iterative cone algorithm ).JetMetJetFinder:JetAlgorithmInputType int 2 JetMetJetFinderSetup The input for reconstructed jets ( 2 = EcalPlusHcalTower : of-

fline trigger towers ).JetMetJetFinder:JetAlgorithmConeSizeA double 0.5 JetMetJetFinderSetup Cone size for the first set of jets.JetMetJetFinder:JetAlgorithmSeedCutA double 2.0 JetMetJetFinderSetup Seed cut for the first jet cone size.JetMetJetFinder:JetAEtCut double 10. JetMetJetFinderSetup Jet Et threshold for the first jet cone size.JetMetJetFinder:JetAlgorithmConeSizeB double 0.7 JetMetJetFinderSetup Cone size for the second set of jets.JetMetJetFinder:JetAlgorithmSeedCutB double 2.0 JetMetJetFinderSetup Seed cut for the second jet cone size.JetMetJetFinder:JetBEtCut double 10. JetMetJetFinderSetup Jet Et threshold for the second jet cone size.JetMetJetFinder:JetEMConeSize1 double 0.13 JetMetJetFinderSetup Jet internal cone size one to sum up ECAL Et to recognize τ -

jets.JetMetJetFinder:JetEMConeSize2 double 0.40 JetMetJetFinderSetup Jet internal cone size two to sum up ECAL Et to recognize τ -

jets.JetMetJetFinder:JetFakeConeSize1 double 0.25 JetMetJetFinderSetup Jet internal cone size to sum up Et to recognize fake jets.JetMetParticle:Debug int 0 JetMetParticleSetup Debugging level.JetMetParticle:EcalPlusHcalTowerEtCut double 0.5 JetMetParticleSetup Et threshold of towers for calculating missing Et and filling

towers into the ntuple.JetMetParticle:CaloTrigPrimEtCut double 0.1 JetMetParticleSetup Et threshold ( GeV ) of calorimeter trigger primitives to be an-

alyzed.JetMetParticle:RawVertexResolution double 0.05 JetMetParticleSetup Smallest distance (mm) between vertices, that are regarded sep-

arate.JetMetParticle:RawEtThreshold double 0.5 JetMetParticleSetup Et threshold of generated particles.MetBuilders:Debug int 0 MetInputSetup Debugging level.MetBuilders:JetAEtCutForMet double 30. MetInputSetup Et threshold of jets of the first set used to calculate type 2 ( from

jets + out-of-cone offline trigger towers ) corrected missing E t .JetMetSetup:JetBEtCutForMet double 30. MetInputSetup Et threshold of jets of the second set used to calculate type 2 (

from jets + out-of-cone offline trigger towers ) corrected missingEt .

Muon:Barrel:MinBunch int 0 MuBarG3Factory First bunch crossing to be added for pile-up, relatively to currentBx

Muon:Barrel:MaxBunch int 0 MuBarG3Factory Last bunch crossing to be added for pile-up, relatively to currentBx

Muon:Rpc:NoiseRate double 0 MRpcUBackground Set noise rate in RPC’s in [Hz/cm2]Muon:Rpc:JunkFactor double 0 MRpcUBackground Multiplicative factor to increase neutron background rate in

RPC’s.Muon:Rpc:GATESDAT string MuonData/RpcData/gates121.datMRpcSynchronizerMuon:Rpc:Efficiency double 0.95 MRpcDigitizer Sets RPC chambers efficiency.Muon:Rpc:ClusterSizeParameter double 1.5 MRpcDigitizer Sets cluster size parameter.Muon:Rpc:ChamberTimeResolution double 2.5 MRpcDigitizer Sets RPC chamber time resolution [ns].Muon:Rpc:FrontendJitter double 1.0 MRpcDigitizer Sets RPC frontend jitter [ns].Muon:Rpc:GateWidth double 20.0 MRpcDigitizer Sets RPC gate width [ns].Muon:Rpc:SignalTimeOffset double 50.0 MRpcDigitizer Sets signal time offset (delay due cablec, etc.) [ns].Muon:Rpc:ClusterSizeTimeParameter double 3.0 MRpcDigitizer Sets parameter for delay of strips in cluster [ns].Muon:Rpc:SignalSpeed double 0.66 MRpcDigitizer Sets signal propagation speed.

0.66 × clight/10.0[cm/ns]

Muon:Rpc:MinBunch int 0 MRpcDetFactory First pileupped event in BXs relative to current BX.Muon:Rpc:MaxBunch int 0 MRpcDetFactory Last pileupped event in BXs relative to curent BX.

Muon:MuonTrackFinder:debug int 0 MuonDebug Debug flag for MuonTracker: 0-5 (1=max debug, 5=essential de-bug, 0=no debug)

Muon:MuonMCFilter:enable bool 0 MuonMCFilter Activate filter for events with no (MC) muon in the final stateduring the ooHitFormatting

Muon:MuonMCFilter:DataSet string Default MuonMCFilter Type of filter to be applied: PileUp pile-up dataset, nopotential triggering muons, 1muPt1 1mu pt1 sample: etadependent pt-cut (hardcoded), Default Generic datasetwith ptcut given by Muon:MuonMCFilter:PtCut andMuon:MuonMCFilter:EtaCut

Muon:MuonMCFilter:PtCut float -1. MuonMCFilter min muon pt for accepting event inside eta range if dataset isDefault

Muon:MuonMCFilter:EtaCut float 5.5 MuonMCFilter max muon eta for accepting event above pt cut if dataset is De-fault

Muon:MuonMCFilter:debug bool 0 MuonMCFilter switch on/off debugL3MuonSeedGenerator:SeedOption int 2 L3MuonSeedGenerator 0 = primitive seeds, 1 = seeds from consecutive hits, 2 = pixel

seeds, 3 = combined (0+1), 4 = combined (1+2)L3MuonSeedGenerator:UseVertex bool 0 (false) L3MuonSeedGenerator use vertex from pixel reconstruction as constraint for seed gen-

erationL3MuonSeedGenerator:MaxSeeds int 50 L3MuonSeedGenerator maximum number of tracker seeds generatedL3MuonSeedGenerator:MaxLayers int 3 L3MuonSeedGenerator maximum number of tracker layers used to find seedsL3MuonSeedGenerator:ErrorRescaleFactor float 2.0 L3MuonSeedGenerator resacling factor of covariance matrix of trajectory state at outer

tracker surface (defines size of window wehre tracker seeds aresearched for)

L3MuonTrackFinder:DebugLevel int 0 L3MuonTrackFinder debug levelL3MuonTrackFinder:Direction int 0 L3MuonTrackFinder define direction of global muon reconstruction (0 = inside-out, 1

= outside-in)L3MuonTrackFinder:useMuonHits bool 1 (true) L3MuonTrackFinder use hits from the muon chambers for the final track refitL3MuonTrackFinder:ptCut float 1.0 L3MuonTrackFinder minimum transverse momentum of a muon track in order to be

reconstructedMuonReconstructionNtuple:Print bool 1 (true) MuonReconstructionNtuple switch on/off print outputMuonReconstructionNtuple:Hits bool 0 (false) MuonReconstructionNtuple use sim hits


Name Type Default Class DescriptionMuonReconstructionNtuple:L1 bool 1 (true) MuonReconstructionNtuple switch on/off Level-1 Muon TriggerMuonReconstructionNtuple:L2 bool 1 (true) MuonReconstructionNtuple switch on/off Level-2 Muon ReconstructionMuonReconstructionNtuple:L3 bool 1 (true) MuonReconstructionNtuple switch on/off Level-3 Muon ReconstructionMuonReconstructionNtuple:LocalMuonReconstructionAlgostring L2MuonReconstructor MuonReconstructionNtuple name of local muon reconstruction algorithm

(L2MuonReconstructor or MuonReconstructor)MuonReconstructionNtuple:GlobalMuonReconstructionAlgostring L3MuonReconstructor MuonReconstructionNtuple name of global muon reconstruction algorithmMuonIsolation:CaloExtractor:thresholdH float 0.5F MuIsoCaloExtractor Et threshold for contributing hcal towersMuonIsolation:CaloExtractor:thresholdE float 0.2F MuIsoCaloExtractor Et threshold for contributing ecal crystalsMuonIsolation:CaloExtractor:dRV etoH C float 0.1F MuIsoCaloExtractor size of HCAL veto coneMuonIsolation:CaloExtractor:dRV etoE C float 0.07F MuIsoCaloExtractor size of ECAL veto coneMuonIsolation:PixelExtractor:drIdent float 0.005F MuIsoPixelExtractor identity cone against ghostsMuonIsolation:PixelExtractor:dZcut float 0.2 MuIsoPixelExtractor use only lines within +- dZcut around seedMuonIsolation:PixelExtractor:dZcut float 0.2 MuIsoPixelExtractor use only lines within +- dZcut around seedMuonIsolation:TrackerExtractor:maxHits int 5 MuIsoTrackerExtractor number of hit stop conditionMuonIsolation:TrackerExtractor:dRcut float 0.5 MuIsoTrackerExtractor deltaR cut between seed and trackMuonIsolation:TrackerExtractor:dZcut float 0.4 MuIsoTrackerExtractor dz cut around seedMuonIsolation:TrackerExtractor:ptMin float 0.4 MuIsoTrackerExtractor minimal ptMuonIsolation:CaloIsolator:mergerEcalHCal float 1.5 MuIsoCaloIsolator weighting factor for merging Ecal and HCalMuonIsolation:CaloIsolator:nominalEfficiency float 0.97 MuIsoCaloIsolator designed efficiencyMuonIsolation:CaloIsolator:Thresholds string MuIsoCaloThresholds.dat data file for calo isolationMuonIsolation:CaloIsolator:mergerEcalHCal float 1.5 MuIsoCaloIsolator weighting factor for merging Ecal and HCalMuonIsolation:CaloIsolator:nominalEfficiency float 0.97 MuIsoCaloIsolator designed efficiencyMuonIsolation:CaloIsolator:Thresholds string MuIsoCaloThresholds.dat data file for calo isolationMuonIsolation:PixelIsolator:nominalEfficiency float 0.97 MuIsoPixelIsolator designed efficiencyMuonIsolation:PixelIsolator:Thresholds string MuIsoPixelThresholds.dat data file for Pixel isolationMuonIsolation:PixelIsolator:drMatch float 0.015 matching cone between line and

seedMuonIsolation:TrackerIsolator:nominalEfficiency float 0.97 MuIsoTrackerIsolator designed efficiencyMuonIsolation:TrackerIsolator:Thresholds string MuIsoTrackerThresholds.datdata file for Tracker isolationMuonIsolation:TrackerIsolator:drMatch float 0.005 matching cone between line and

seedMuonIsolation:CaloExtractor:thresholdH float 0.5F MuIsoCaloExtractor Et threshold for contributing hcal towersMuonIsolation:CaloExtractor:thresholdE float 0.2F MuIsoCaloExtractor Et threshold for contributing ecal crystalsMuonIsolation:CaloExtractor:dRV etoH C float 0.1F MuIsoCaloExtractor size of HCAL veto coneMuonIsolation:CaloExtractor:dRV etoE C float 0.07F MuIsoCaloExtractor size of ECAL veto coneMuonIsolation:PixelExtractor:drIdent float 0.005F MuIsoPixelExtractor identity cone against ghostsMuonIsolation:PixelExtractor:dZcut float 0.2 MuIsoPixelExtractor use only lines within +- dZcut around seedMuonIsolation:TrackerExtractor:maxHits int 5 MuIsoTrackerExtractor number of hit stop conditionMuonIsolation:TrackerExtractor:dRcut float 0.5 MuIsoTrackerExtractor deltaR cut between seed and trackMuonIsolation:TrackerExtractor:dZcut float 0.4 MuIsoTrackerExtractor dz cut around seedMuonIsolation:TrackerExtractor:ptMin float 0.4 MuIsoTrackerExtractor minimal ptMuonIsolation:CaloIsolator:mergerEcalHCal float 1.5 MuIsoCaloIsolator weighting factor for merging Ecal and HCalMuonIsolation:CaloIsolator:nominalEfficiency float 0.97 MuIsoCaloIsolator designed efficiencyMuonIsolation:CaloIsolator:Thresholds string MuIsoCaloThresholds.dat data file for calo isolationMuonIsolation:PixelIsolator:nominalEfficiency float 0.97 MuIsoPixelIsolator designed efficiencyMuonIsolation:PixelIsolator:Thresholds string MuIsoPixelThresholds.dat data file for Pixel isolationMuonIsolation:PixelIsolator:drMatch float 0.015 matching cone between line and

seedMuonIsolation:TrackerIsolator:nominalEfficiency float 0.97 MuIsoTrackerIsolator designed efficiencyMuonIsolation:TrackerIsolator:Thresholds string MuIsoTrackerThresholds.datdata file for Tracker isolationMuonIsolation:TrackerIsolator:drMatch float 0.005 matching cone between line and

seed

grepApvAnalysisFactory:FactoryName string ReferenceApvAnalysisFactoryApvAnalysisFactoryDispenser Specify which ApvAnalysisFactory to use. GeneralApvAnalysis-

Factory is the most general one, allowing one to use any existingalgorithm.

ApvKillerFactory:KillerName string HipApvKillerPerDetType ApvKillerFactory Selects which concrete instance of the abstract class ApvKillermust be used

HipApvKiller:ProbabilityPerTrackPer300um float 0.0003 HipApvKiller Define the probability that a 300 MeV pion interacting perpen-dicularly in 300 um of silicon generates a HIP

HipApvKiller:ProbabilityOfDeadApv float 0.002 HipApvKiller Defines the probability that a APV is in state of recovery due toa HIP. It is basically the cross section times the number of bunchcrossings it remains dead

StripDigi:zeroSuppressedAdcBits int (see constructor) StripDigi The number of useful hits in the ADC readoutSiStripDigitizer:HIPInefficiency bool false StripReadout Whether to simulate HIP inefficiencies in the APVs

SiPixelDet:TanLorentzAnglePerTesla float 0.133 SiPixelDet Tangent of Lorentz angle per Tesla in deg., default 28deg at 4T.PixelDigitizer:ElectronPerAdc float 135. SiPixelDet Pixel adc calibrationPixelDigitizer:NoiseInElectrons float 500. SiPixelDet Pixel Noise in electronsPixelDigitizer:ThresholdInNoiseUnits float 5. SiPixelDet Pixel Readout Threshold in Noise UnitsTkSiPixelClusterizer:ClusterizerName string SimplePixelClusterizer PixelClusterizerFactory Tracker Silicon Pixel Clusterize NameTkSiPixelDigitizer:DigitizerName string SiPixelDigitizer PixelDigitizerFactory Tracker Silicon Pixel Digitizer Name

SiStripDigitizer:EquivalentNoiseCharge300um float 2160. SiStripDet Silicon Noise in electronsSiStripDigitizer:ElectronsPerAdcCount float 145. SiStripDet Silicon Adc calibration (Conversion factor)SiStripDet:HoleMobilityAtLowField float 470.5 SiStripDet Hole Mobility in silicon at low fieldSiStripDet:HoleSaturationVelocity float 8.37e6 SiStripDet Hole Saturation Velocity in siliconSiStripDet:HoleBeta float 1.213 SiStripDet Hole Mobility in silicon at low field (beta factor)SiStripDet:HoleRHAllParameter float 0.7 SiStripDet Hole Mobility in silicon at low field (rh factor)SiStripDet:Temperature float 297. SiStripDet Temperature in KelvinSiStripDet:AppliedVoltage float 150. SiStripDet Silicon Applied Voltage in VoltSiStripClusterizer:EdgeAlgo bool true SiStripDet Tracker Silicon Pixel Clusterize NameTkSiStripDigitizer:DigitizerName string SiStripDigitizer Tracker Silicon Strip Digitizer

Name. (Using SiStripFedDigi-tizer gives a realistic, but slow,simulation of the FED zero sup-pression).

LayerMediumProperties: layerName: radLen float -1 LayerMediumPropertyReader/-Setter

Material for layer layerName (see TkLayerName:shortName) inunits of X0 . radLen < 0 retains default value from TkCm-simInterface.

LayerMediumProperties: layerName: detTypeName:radLen

float -1 LayerMediumPropertyReader/-Setter

As above, but exclusively for DetType detTypeName (see TkDet-TypeName:shortName). Both parameter types can be mixed inwhich case the definition for the layer applies only to those detec-tors not explicitely specified.

LayerMediumProperties: layerName: xi float -1 LayerMediumPropertyReader/-Setter

Material for layer layerName for use in energy loss calculation(see EnergyLossUpdator). xi < 0 retains default value fromTkCmsimInterface.

LayerMediumProperties: layerName: detTypeName: xi float -1 LayerMediumPropertyReader/-Setter

As above, but exclusively for DetType detTypeName.

TkHitLoader:LoadHits string All TkCARFSimHitLoader Decides which hits to load; valid entries are All, NoSignal, NoPU.

173

Name Type Default Class DescriptionTrackerHits:ElectronicSigmaInNanoSeconds float 12.06 TkMasterSimHitLoader Integration time of the Tracker electronics. Do not change it!TopologyBuilder:ADCFromConfigurables bool true TopologyBuilder Reconfiguring Topologies with ORCA.TIDStereoDcenterRing1 float -2.7665 FixTIDTopology Value for Dcenter for first type of TID Stereo Detectors. Used in

the patch after the bug discovery.TIDStereoDcenterRing2 float -3.671 FixTIDTopology Value for Dcenter for second type of TID Stereo Detectors. Used

in the patch after the bug discovery.HipApvKiller:ProbabilityPerTrackPer300um float 0.001 HipApvKillerPerDetType HIP probability in 300 um of silicon for a 300 MeV pion..HipApvKiller:HighLumi bool false HipApvKillerPerDetType Whether to apply the multiplicative factor for High lumi (5).HipApvKiller:DeadTimeInBunches float 10. HipApvKillerPerDetType The multiplicative factor due to the number of bunch crossing in

which a APV remains dead.HipApvKiller:MultiplicativeFactorForProtons float 10. HipApvKillerPerDetType The multiplicative factor to be applied for protons.

PixelDigitizer:ElectronPerAdc float 135 SiPixelDigitizer The conversion factor for adc.PixelDigitizer:AdcFullScale int 255 SiPixelDigitizer The maximum count for ADC. It means 8 bits.PixelDigitizer:TofCut float 12.5 SiPixelDigitizer The cut on the electronic window. It is NOT gaussian, but fixed.PixelDigitizer:AddNoise bool true SiPixelDigitizer Whether to add noise to pixels.PixelDigitizer:AddNoisyPixels bool true SiPixelDigitizer Add noisy pixels.PixelDigitizer:FluctuateCharge bool true SiPixelDigitizer Allow the charge fluctuations in the division.PixelDigitizer:AddPixelInefficiency int 0 SiPixelDigitizer Include pixel inefficiencies. Default is NO. Other values: 0 = no,

1 = low lumi, 10 = high lumi.

SiStripDigitizer:DepletionVoltage double 140 SiHitDigitizer The standard depletion voltage for silicon microstrips.SiStripDet:AppliedVoltage double 150 SiHitDigitizer The applied voltage to silicon microstrips.SiStripDigitizer:ChargeMobility double 480 SiHitDigitizer Charge Mobility.SiStripDet:Temperature float 297 SiHitDigitizer The temperature of the silicon.

SiStripDigitizer:ChargeDistributionRMS double 6.5 × 10−6 SiHitDigitizer The RMS of the charge distribution.SiStripDigitizer:GevPerElectron double 3.61 × 10−9 SiHitDigitizer GeV needed to create a pair.SiStripDigitizer:APVpeakmode bool false SiLinearChargeDivider,

SiStripDigitizerUse APV peak mode instead of deconvolution mode. (Degradestime resolution.)

SiStripDigitizer:LandauFluctuations bool true SiLinearChargeDivider Enable landau fluctuations in charge division.SiStripDigitizer:IsolatedStripCut float 4.5 SiTrivialZeroSuppress The cut on isolated strips. It is in number of sigmas.SiTrivialDigitalConverter:rawDataAdcBits int 12 SiTrivialDigitalConverter Number of ADC bits for zero suppressed data.SiStripFedDigitizer:UseRecPedCM bool 1 SiStripFedDigitizer If zero, FED will cheat by taking common-mode value from

Monte Carlo truth, instead of trying to reconstruct it.SiStripFedDigitizer:cmFromMedian bool 1 SiStripFedDigitizer Estimate common-mode offset from median instead of mean

pulse height.SiStripFedDigitizer:NumIter bool 1 SiStripFedDigitizer Number of iterations to get common-mode.SiStripFedDigitizer:Pedestal float 100. SiStripFedDigitizer Generated pedestal in ADC counts.SiStripFedDigitizer:rmsCM float 5. SiStripFedDigitizer rms of generated common-mode noise in ADC counts.SiStripFedDigitizer:cmSigRejThresh float 2. SiStripFedDigitizer Strip threshold for flagging signal strips during common-mode

estimate, in units of rms noise.SiStripFedDigitizer:algorithm int 2 SiStripFedDigitizer Choose FED clustering algorithm.SiStripFedDigitizer:lowThresh float 2. SiStripFedDigitizer Low threshold of FED clustering algorithm, in units of rms noise.SiStripFedDigitizer:highThresh float 5. SiStripFedDigitizer High threshold of FED clustering algorithm, in units of rms

noise.PartialTrackFinder:nrecohit int 5 PartialTrackFinder Set the number of hits to stop partial track reconstruction.5

StableSimTracksFromDecay:pidToFind int 25 StableSimTracksFromDecay Set the first parent particle, of which decay the stable particleTkSimTracks will be selected. For the mother partocle, use thecode of the Monte Carlo Particle numbering scheme of the PDG(25 is the first neutral Higgs) For example, in the decay H0 -¿ Z0z0 -¿ 4 mu, the four muon TkSimTracks will be selected.

L1RpcTrigger:Debug int 0 L1Rpc Setting debug level. Range is from 0 to 7.L1RpcTrigger:Decluster int 1 L1Rpc Control of the declusterisation procedure. If set to 1 N-2 declus-

terisation argorithm is used.L1RpcTrigger:MRT1DAT string /TriggerData/L1RpcTrigger/mrt1.datL1Rpc Path to file containing valid patterns for PACT.L1RpcTrigger:MRT3DAT string /TriggerData/L1RpcTrigger/mrt3.datL1Rpc Path to file containing link tables for PACT.CSCTrigger:twentyDegreeSubSectors bool 0 (false) L1MuCSCSetup This is defaulted to 0 which means each sector in ME1 is split

up into 30 degree subsectors (each subsector contains 12 CSCs,each subsector is linked to a Muon Port Card). If set to 0, theneach sector in ME1 is split up into 20 degree subsectors (eachsubsector contains 8 CSCs)

CSCTrigger:DtEtaStop int 5 L1MuCSCSetup Used to define the eta region where a track stub is isolated onlyin the endcap

CSCTrigger:DtEtaCut int 5 L1MuCSCSetup Used to define the eta region where a track stub is important forboth the endcap and the barrel

CSCTrigger:CscEtaStart int 5 L1MuCSCSetup Used to define the boundary between the barrel and endcapCSCTrigger:CscEtaStartCorr float 0.0 L1MuCSCSetup Used to fine-tune the boundary between the barrel and endcapCSCTrackFinder:shareMB1 bool 1 (true) L1MuCSCTrackFinderSetup Control whether track segments from MB1 are used in the

DT/CSC overlapCSCTrackFinder:shareMB2 bool 0 (false) L1MuCSCTrackFinderSetup Control whether track segments from MB2 are used in the

DT/CSC overlapCSCTrackFinder:ghostBustME1 bool 1 (true) L1MuCSCTrackFinderSetup Control whether the ghost-busting feature is enabled for ME1CSCTrackFinder:firstStationConfig int 0xF L1MuCSCTrackFinderSetup Control whether no track segments from ME1 are allowed (0),

ME1/1a only allowed (1), ME1/1b only allowed (2), ME1/2 onlyallowed (4), ME1/3 only allowed (8) or any other binary combi-nation

CSCTrackFinder:fourthStationConfig int 0x3 L1MuCSCTrackFinderSetup Control whether no track segments from ME4 are allowed (0),ME4/1 only allowed (1), ME4/2 only allowed (2), or both allowed(3)

CSCTrackFinder:lowQualityFlag int 1 L1MuCSCTrackFinderSetup Determine whether low quality (Q=1) muons are allowed, andwhere: 0 = none, 1 = DT/CSC overlap, 2 = ME1/1a, 3 = both

CSCTrackFinder:verilog bool 0 (false) L1MuCSCTrackFinderSetup Control whether C++ translation of Verilog description is runCSCTrackFinder:ORedME1A bool 0 (false) L1MuCSCTrackFinderSetup Creates ghost segments in ME1/1a when strips are ganged. Ver-

ilog option must be selectedL1DTTrigger:dttrigdbg string no debugging L1MuDTConfig Debugging levelL1DTTrigger:tmax string 15 L1MuDTConfig Max drift time in 25 ns stepsL1DTTrigger:timindkeqsupp string Theta only L1MuDTConfig Time ind. K-eq. supp.L1DTTrigger:sllts string Theta and phi L1MuDTConfig LTS, adjacent LTRIG supp. in SLL1DTTrigger:sidelts string Both L1MuDTConfig LTS, suppression at sideL1DTTrigger:nbxltsphi string 8 L1MuDTConfig LTS, n. of BX supp. at high side, phi SLL1DTTrigger:nbxltstheta string 8 L1MuDTConfig LTS, n. of BX supp. at high side, theta SLL1DTTrigger:adjbtilts string Enabled L1MuDTConfig LTS on BTI adjacent to a BTI with HTRIGL1DTTrigger:setuptime string 0 L1MuDTConfig BTI setup timeL1DTTrigger:langbticorr string -0.25 L1MuDTConfig Large angle BTIcorrectionL1DTTrigger:kcutphi string 32 L1MuDTConfig Maximum K-parameter accepted in phi viewL1DTTrigger:kcuttheta string 32 L1MuDTConfig Maximum K-parameter accepted in theta viewL1DTTrigger:accpatta string 2 L1MuDTConfig Acceptance pattern AL1DTTrigger:accpattb string 1 L1MuDTConfig Acceptance pattern BL1DTTrigger:kacctheta string 2 L1MuDTConfig BTI angular acceptance in theta viewL1DTTrigger:bendinganglecut string Not enabled L1MuDTConfig Bending angle cut in MB3 and MB4L1DTTrigger:sortkascend1 string Ascending L1MuDTConfig Sorting order for K, first tracks


Name Type Default Class DescriptionL1DTTrigger:sortkascend2 string Ascending L1MuDTConfig Sorting order for K, second tracksL1DTTrigger:prefhtrig1 string Enabled L1MuDTConfig Preference to HTRIG, first tracksL1DTTrigger:prefhtrig2 string Enabled L1MuDTConfig Preference to HTRIG, second tracksL1DTTrigger:singlehflag1 string Always accepted L1MuDTConfig Single HTRIG, first tracksL1DTTrigger:singlehflag2 string Always accepted L1MuDTConfig Single HTRIG, second tracksL1DTTrigger:singlelflag1 string Only with theta coincidenceL1MuDTConfig Single LTRIG, first tracksL1DTTrigger:singlelflag2 string Only with theta coincidenceL1MuDTConfig Single LTRIG, second tracksL1DTTrigger:prefinner1 string Inner L1MuDTConfig Single trigger preference to SL, first tracksL1DTTrigger:prefinner2 string Inner L1MuDTConfig Single trigger preference to SL, second tracksL1DTTrigger:tcktoll1 string 2 L1MuDTConfig K tollerance for correlation, first tracksL1DTTrigger:tcktoll2 string 2 L1MuDTConfig K tollerance for correlation, second tracksL1DTTrigger:tcbxlts string Not enabled L1MuDTConfig Single LTRIG suppression in 4 BX low sideL1DTTrigger:tcreuse1 string Enabled L1MuDTConfig Recycling of candidates in inner SLL1DTTrigger:tcreuse2 string Enabled L1MuDTConfig Recycling of candidates in outer SLL1DTTrigger:nmaxoutcand string 2 L1MuDTConfig Number of tracks passed to TSL1DTTrigger:tssmasking1 string Corr/NotC,H/L,In/Out L1MuDTConfig Priority in TSS for first track selectionL1DTTrigger:tssmasking2 string Corr/NotC,H/L,In/Out L1MuDTConfig Priority in TSS for second track selectionL1DTTrigger:tsshtrigena1 string Enabled L1MuDTConfig Pref. to HTRIG in TSS for first track selectionL1DTTrigger:tsshtrigena2 string Not enabled L1MuDTConfig Pref. to HTRIG in TSS for second track selectionL1DTTrigger:tsshtrigenac string Not enabled L1MuDTConfig Pref. to HTRIG in TSS for carryL1DTTrigger:tssinoutena1 string Enabled L1MuDTConfig Pref. to Inner in TSS for first track selectionL1DTTrigger:tssinoutena2 string Not enabled L1MuDTConfig Pref. to Inner in TSS for second track selectionL1DTTrigger:tssinoutenac string Not enabled L1MuDTConfig Pref. to Inner in TSS for carryL1DTTrigger:tsscorrena1 string Enabled L1MuDTConfig Pref. to Corr. in TSS for first track selectionL1DTTrigger:tsscorrena2 string Not enabled L1MuDTConfig Pref. to Corr. in TSS for second track selectionL1DTTrigger:tsscorrenac string Not enabled L1MuDTConfig Pref. to Corr. in TSS for carryL1DTTrigger:tsmmasking1 string Corr/NotC,H/L,In/Out L1MuDTConfig Priority in TSM for first track selectionL1DTTrigger:tsmmasking2 string Corr/NotC,H/L,In/Out L1MuDTConfig Priority in TSM for second track selectionL1DTTrigger:tsmhtrigena1 string Enabled L1MuDTConfig Pref. to HTRIG in TSM for first track selectionL1DTTrigger:tsmhtrigena2 string Not enabled L1MuDTConfig Pref. to HTRIG in TSM for second track selectionL1DTTrigger:tsmhtrigenac string Not enabled L1MuDTConfig Pref. to HTRIG in TSM for carryL1DTTrigger:tsminoutena1 string Enabled L1MuDTConfig Pref. to Inner in TSM for first track selectionL1DTTrigger:tsminoutena2 string Not enabled L1MuDTConfig Pref. to Inner in TSM for second track selectionL1DTTrigger:tsminoutenac string Not enabled L1MuDTConfig Pref. to Inner in TSM for carryL1DTTrigger:tsmcorrena1 string Enabled L1MuDTConfig Pref. to Corr. in TSM for first track selectionL1DTTrigger:tsmcorrena2 string Not enabled L1MuDTConfig Pref. to Corr. in TSM for second track selectionL1DTTrigger:tsmcorrenac string Not enabled L1MuDTConfig Pref. to Corr. in TSM for carryL1DTTrigger:tssghost1flag string If Outer adj to 1st tr L1MuDTConfig Carry suppression in TSS (Ghost1)L1DTTrigger:tssghost2flag string If Outer same TRACO of uncorr 1st trL1MuDTConfig 2nd track suppression in TSSL1DTTrigger:tsmghost1flag string If Outer adj to 1st tr L1MuDTConfig Carry suppression in TSM (Ghost1)L1DTTrigger:tsmghost2flag string If Outer same TRACO of uncorr 1st trL1MuDTConfig 2nd track suppression in TSM (Ghost2)L1DTTrigger:tssghost1corr string Accepted if correlated L1MuDTConfig correlated carry suppression in TSS (Ghost1)L1DTTrigger:tssghost2corr string Accepted if correlated L1MuDTConfig correlated carry suppression in TSS (Ghost2)L1DTTrigger:tsmghost1corr string Accepted if correlated L1MuDTConfig correlated carry suppression in TSM (Ghost1)L1DTTrigger:tsmghost2corr string Accepted if correlated L1MuDTConfig correlated carry suppression in TSM (Ghost2)L1DTTrigger:tsmgetcarryflag string get best 2ndprevBX 1st L1MuDTConfig second track handling in case of pile-up in TSML1DTTrackFinder:Debug int 0 L1MuDTTFConfig Debug level for barrel track finder (0-6)L1DTTrackFinder:BX min int -9 L1MuDTTFConfig First bunch crossing for which to run the barrel track finder (rel-

ative to signal BX)L1DTTrackFinder:BX max int 7 L1MuDTTFConfig Last bunch crossing for which to run the barrel track finder (rel-

ative to signal BX)L1DTTrackFinder:Overlap bool 1 (true) L1MuDTTFConfig Switch to turn on/off the barrel-endcap overlap regionL1DTTrackFinder:Extrapolation Filter int 1 L1MuDTTFConfig Select extrapolation quality filter (0,1,2,3,4,5)L1DTTrackFinder:Extrapolation 21 bool 0 (false) L1MuDTTFConfig Use extrapolation 21 to cross-check 12L1DTTrackFinder:EtaTrackFinder bool 1 (true) L1MuDTTFConfig Switch to turn on/off eta track finderL1DTTrackFinder:OutOfTime Filter bool 1 (true) L1MuDTTFConfig Switch to turn out-of time track segment filterL1DTTrackFinder:OutOfTime Filter Window int 1 L1MuDTTFConfig Set out-of time track segment filter window (phi)L1DTTrackFinder:Extrapolation nbits Phi int 8 L1MuDTTFConfig Set precision (number of bits) in phi to be used for extrapolationL1DTTrackFinder:Extrapolation nbits PhiB int 8 L1MuDTTFConfig Set precision (number of bits) in phiB to be used for extrapola-

tionL1DTTrackFinder:PT Assignment nbits Phi int 12 L1MuDTTFConfig Set precision (number of bits) in phi to be used for pt-assignmentL1DTTrackFinder:PT Assignment nbits PhiB int 10 L1MuDTTFConfig Set precision (number of bits) in phiB to be used for pt-

assignmentL1DTTrackFinder:PHI Assignment nbits Phi int 12 L1MuDTTFConfig Set precision (number of bits) in phi to be used for phi-

assignmentL1DTTrackFinder:PHI Assignment nbits PhiB int 10 L1MuDTTFConfig Set precision (number of bits) in phiB to be used for phi-

assignmentL1GlobalMuonTrigger:Debug int 0 L1MuGMTConfig Set debug level for GMT (0=off, 5=max)L1GlobalMuonTrigger:BX min int -4 L1MuGMTConfig First bunch crossing for which to run GMT (relative to signal

BX)L1GlobalMuonTrigger:BX max int 4 L1MuGMTConfig Last bunch crossing for which to run GMT (relative to signal

BX)L1GlobalMuonTrigger:EtaWeight barrel float 0.028 L1MuGMTConfig Weight for eta coordinate in Barrel Matcher UnitL1GlobalMuonTrigger:PhiWeight barrel float 1.0 L1MuGMTConfig Weight for phi coordinate in Barrel Matcher UnitL1GlobalMuonTrigger:EtaPhiThreshold barrel float 0.062 L1MuGMTConfig Window size in Barrel Matcher UnitL1GlobalMuonTrigger:EtaWeight endcap float 0.13 L1MuGMTConfig Weight for eta coordinate in Endcap Matcher UnitL1GlobalMuonTrigger:PhiWeight endcap float 1.0 L1MuGMTConfig Weight for phi coordinate in Endcap Matcher UnitL1GlobalMuonTrigger:EtaPhiThreshold endcap float 0.062 L1MuGMTConfig Window size in Endacp Matcher UnitL1GlobalMuonTrigger:EtaWeight COU float 0.316 L1MuGMTConfig Weight for eta coordinate in DT/CSC Cancel Out Matcher UnitL1GlobalMuonTrigger:PhiWeight COU float 1.0 L1MuGMTConfig Weight for phi coordinate in DT/CSC Cancel Out Matcher UnitL1GlobalMuonTrigger:EtaPhiThreshold COU float 0.127 L1MuGMTConfig Window size in DT/CSC Cancel Out Matcher UnitL1GlobalMuonTrigger:COUConfig int 2 L1MuGMTConfig Option for Cancel Out UnitL1GlobalMuonTrigger:DoOvlRpcAnd bool 0 (false) L1MuGMTConfig Option for Cancel Out UnitL1GlobalMuonTrigger:CaloTrigger bool 1 (true) L1MuGMTConfig Flag to switch off inputs from Calo Trigger for faster simulationL1GlobalMuonTrigger:IsolationCellSizeEta int 2 L1MuGMTConfig Cell-size in eta-direction for calorimetric isolation assignment (in

units of regions)L1GlobalMuonTrigger:IsolationCellSizePhi int 2 L1MuGMTConfig Cell-size in phi-direction for calorimetric isolation assignment

(in units of regions)L1CaloTrigger:lowForwardJetEtCut unsigned int 20 L1CGlblTrigger Jet ET cut [low] for forward and backward HF jet counting

(presently unused).L1CaloTrigger:highForwardJetEtCut unsigned int 30 L1CGlblTrigger Jet ET cut [high] for forward and backward HF jet counting

(presently unused).L1CaloTrigger:lowCentralJetEtCut unsigned int 10 L1CGlblTrigger Jet ET cut for central jet counting (presently unused).L1CaloTrigger:mediumCentralJetEtCut unsigned int 20 L1CGlblTrigger Jet ET cut for central jet counting (presently unused).L1CaloTrigger:highCentralJetEtCut unsigned int 30 L1CGlblTrigger Jet ET cut for central jet counting (presently unused).L1CaloTrigger:veryHighCentralJetEtCut unsigned int 40 L1CGlblTrigger Jet ET cut for central jet counting (presently unused).L1CaloTrigger:goodJetEtCut unsigned int 10 L1CGlblTrigger A new good jets list is made if the jet energy is above this cut-

off. The good jets are added to make HT - this trigger is underevaluation.

L1CaloTrigger:noTauVetoLevel float 50 L1CRegion If the ET in a 4x4 trigger tower region is above this value the tauveto is not set, to avoid loss of efficiency for high ET tau jets.

175

Name Type Default Class DescriptionL1CaloTrigger:muonIsolationThreshold unsigned int 3 L1CRegion The value of ET in a 4x4 trigger tower region that is allowed for

muon isolation. The larger this value is the less strict the muonisolation is.

L1CaloTrigger:nEActiveCut unsigned int 2 L1CRegion Used in the old tau algorithm - no longer relevant for the new taupattern algorithm.

L1CaloTrigger:nHActiveCut unsigned int 2 L1CRegion Used in the old tau algorithm - no longer relevant for the new taupattern algorithm.

L1CaloTrigger:ecalTowerETNoiseLevel unsigned int 2 L1CRgnlTrgData Ecal noise cut for all e/g isolation algorithmsL1CaloTrigger:hcalTowerETNoiseLevel unsigned int 2 L1CRgnlTrgData Hcal noise cut for all e/g isolation algorithmsL1CaloTrigger:emTriggerLSB float 0.5 L1CRgnlTrgData The EM trigger least significant bit and scaleL1CaloTrigger:jetTriggerLSB float 1.0 L1CRgnlTrgData The jet trigger least significant bit and scaleL1CaloTrigger:HOverECut float 0.05 L1CRgnlTrgData H/E cut for EM algorithmL1CaloTrigger:emTriggerETActiveLevel float 2.0 L1CRgnlTrgData EM trigger tower activity level for tau algorithmL1CaloTrigger:hdTriggerETActiveLevel float 4.0 L1CRgnlTrgData HB/HE trigger tower activity level for tau algorithmL1CaloTrigger:useCombinedPattern bool 1 (true) L1CRgnlTrgData If enabled used OR of the EM and HD patterns for tau algorithmL1CaloTrigger:ecalInputLSB float 0.5 L1CRgnlTrgData Trigger tower ET LSB for EB/EEL1CaloTrigger:hcalInputLSB float 0.5 L1CRgnlTrgData Trigger tower ET LSB for HB/HE/HFL1CaloTrigger:hfCutOff unsigned int 3 L1CRgnlTrgHFCrate HF towers below this are set to zeroL1CaloTrigger:etaCut float 3.0 L1CClusterCrate The eta cut that separates the central and forward jetsL1CaloTrigger:clusterSeedEt unsigned int 5 L1CClusterCrate The minimum ET in the central region of a jetL1CaloTrigger:noTauBitThreshold unsigned int 10000 L1CClusterCrate Tau bit is ignored if the energy is above this value. By default

this feature is NOT used.L1CNTuple:getPU unsigned int 0 L1CaloTriggerNTuple read pile-up info for L1Calotrigger NtupleL1CNTuple:printHEPEVT unsigned int 0 L1CaloTriggerNTuple print flag for L1Calotrigger NtupleL1GlobalTrigger:Debug int 1 L1GlobalTrigger Debug level for Global TriggerL1GlobalTrigger:Algorithm string ”” L1GlobalTriggerConfig Add one algorithm to the default ones (see WEB documentation)L1GlobalTrigger:InputMask unsigned int 3 L1GlobalTriggerConfig 3 = enable all inputs; 2 = disable Global Calorimeter Input only;

1 = disable Global Muon Input only; 0 = disable BothL1GlobalTrigger:Mask unsigned long 0 L1GlobalTriggerConfig Disable some Global Trigger algorithms (128 bit coding, ”1” at

bit nr. N disable algorithm nr. N)

SimTrackFirstParentFilter:particle string BHadron SimTrackFirstParentFilter Set the first parent particle which originated in cascade decay thefiltered TkSimTrack (possible values: ”BHadron”, ”CHadron”,”BMeson”, ”CMeson”).

JetProvider:jetCone float 0.4 BaseJetProvider and its heirs Set the Region of Interest (RoI) around jets in η − φ plane.

Part V

Glossary

177

179

The glossary is ment to explain all important terms that beginners are usually not familiar with.

ams the Advanced Multithreaded Server from Objectivity/DB. It allows to access federations that are storedon a different machines.

Bibliography

[1] http://cmsdoc.cern.ch/orca/

[2] http://cmsdoc.cern.ch/cmsim/cmsim.html

[3] CMS-IN 1999/001, Object Oriented Reconstruction for CMS Analysis, CMS Software and ComputingGroup

[4] http://cmsdoc.cern.ch/cmsoo/CVS.pdf

[5] http://cmsdoc.cern.ch/cmsoo/taggin1.html

[6] http://cmsdoc.cern.ch/cmsoo/training.html

[7] CMS note 1998/071, CMS Coding rules, J.-P. Wellisch

[8] http://cmsdoc.cern.ch/Releases/SCRAM/current/cgi/scrampage.cgi

[9] Towards a Standardisation of Jet Definition, S.D. Ellis, J. Huth, N. Wauner, K. Meier, N. Hadley, D. Soperand M. Greco, Proceedings of Research Directions For The Decade, Snowmass 1990, Snowmass, July1990, ed. E.L. Berger, p. 134, (World Scientific, Singapore, 1992).

[10] S.D. Ellis, D.E. Soper, Phys. Rev. D48, 3160-3166 (1993)

[11] S. Bethke et al., Phys. Lett. 39, 1436 (1988)

[12] S. Catani et al., Phys. Lett. B269, 432 (1991).

[13] S. Bentvelsen, I. Meyer, Eur. Phys. J. C4 623 (1998)

[14] S. Catani, Yu.L. Dokshitzer, B.R. Webber, CERN-TH.6473/92; S. Catani, Rencontres de Moriond,28th: QCD and High Energy Hadronic Interactions, Les Arcs, France, Mar 20-27, (1993)

[15] L. Lonnblad, Z.Phys.C58, 471-478 (1993)

181

http://cmsdoc.cern.ch/orca/

http://cmsdoc.cern.ch/cmsim/cmsim.html

http://cmsdoc.cern.ch/cmsoo/CVS.pdf

http://cmsdoc.cern.ch/cmsoo/taggin1.html

http://cmsdoc.cern.ch/cmsoo/training.html

http://cmsdoc.cern.ch/Releases/SCRAM/current/cgi/scrampage.cgi

the user guide - department of physics · versions starting with orca 5.1.0 use for linux gcc...

Documents