Muon identifiers
D. Adams
Version 1.2.1
14nov01 1010
Here we present a design for the ATLAS muon identifiers.
These identify components of the muon detector.
The present motivation for this package is the muon digit
container. Other users are invited to submit use cases and
requirements.
Definitions
Here we define some of the terms used in the design of muon digit
identifiers. We try to be consistent with the terminology of the
muon TDR
and the
ATLAS note
describing the ATLAS identification scheme.
Identifier
An identifier is a label used to identify a piece of the ATLAS
detector. We use a hierarchical description.
Technology
The muon spectrometer incorporates four detector technologies:
- MDT - Monitored Drift Tube
- CSC - Cathode Strip Chambers
- RPC - Resistive Plate Chamber
- TGC - Thin gap chamber
The MDT and and CSC are used for precision measurement and the
RPC and TGC are used for triggering. Most of the coverage is is
with MDT and RPC. The CSC and TGC are used in forward regions
where the rates are too high for the other technologies.
Channel
A channel is an an independently read out detector element such
as a strip or wire.
Station
The ATLAS identification scheme first divides the muon system
into station types (named BIL, BIR, ...) corresponding to
detector locations. These locations are then divided into eta-phi
bins to form stations.
Module
A module is a collection of channels organized into a mechanical
structure and read out together.
For the MDT the natural choice is a chamber (which may have
one or two multilayers) and there is a one-to-one (or one-to-zero)
correspondence between stations and chambers.
Some MDT chambers have RPC detectors on either side.
We choose to refer to both sets of RPC detectors as a single module.
We make the general definition that for each technology, all
detector elements associated with a particular station constitute
a module.
Digit
A digit (or digitization) is the data associated with one
channel. The implementation is self-describing, i.e.
includes the identifier as well as the data.
Use cases
The primary purpose of identifiers is to provide labels.
For example, a digit is associated with a detector channel.
The association by labeling the digit with a channel identifier,
A user can ask the digit for its channel identifier or can ask
a collection of digits to return the digit corresponding to
a given channel identifier.
The latter implies a need to sort associated objects by their
detector location, e.g. create an ordered list of digits. This
implies that we must be able to order the identifiers.
The identifiers form a hierarchy: technologies contain modules which
in turn contain channels. The identifiers are used to navigate up
and down this hierarchy. A user holding a module identifier can find
the identifiers of the channels that are associated with the module.
A user holding a channel identifier can find the identifier for the
associated module.
The previous use cases have been generic. Here we consider a
very specific example. A user wishes to loop over all the
muon digits from one muon technology.
See the muon digit container design.
This processing might be accomplished in the following sequence:
-
The user creates an identifier for the technology (e.g. MDT).
-
The technology identifier is queried for the list of
associated module identifiers.
-
For each module, the list of digits is extracted from the digit
container using the module identifier as a key.
-
Each digit is queried for its channel identifier.
-
The channel identifier can then be used as a key to access
geometry or calibration information from the appropriate
database.
Requirements
Here we specify requirements for muon identifiers.
They should provide the following:
1. Identities for the following detector elements:
- muon system
- technology
- module (layer and technology)
- channel
These form a hierarchy with each element associated with a distinct
collection of elements in the next level down.
2. This hierarchy is consistent with that of the
ATLAS identification scheme.
The labeling of the identifiers must be consistent with this
document.
3. The identifiers carry the structure of the muon system.
Combinations of hierarchy indices which do not correspond to
existing detector elements should not be allowed to exist or
or should be labeled as invalid.
4. A default ordering of each type of identifier must be provided.
5. There must be mechanisms to navigate up and down the hierarchy.
For example, for a given module identifier, there must be a way
determine the identifier for the containing technology and the
list of identifiers for the contained channels. Downward
navigation makes it possible to discover the identities of all
valid detector elements.
6. Our identifiers must convert to and from
Identifier objects
so they can be used to access geometry and calibration data in
a manner common with other subdetectors.
Design issues
We have required that it be possible to navigate up and down the
identifier hierarchies. However we do not want to introduce
circular couplings such as having module and channel identifiers
know about each other.
Choice
We allow identifiers to know about identifiers above them in the
hierarchy but not about those below. For example channel identifiers
will know about module identifiers and will be able to return
their associated module. However, module identifiers will not
know about their channels. If we want to know the channels for a
module, we have to ask the channel class or some higher level
class or function.
Does the ATLAS environment place any constraints on our design?
I.e. do we want to following naming or syntax conventions used
by any other subdetector identifiers? Should all channel identifiers
(or all identifiers) inherit from a common base so they can be
accessed generically?
Here are some issues that have been raised:
-
1. Are we required to inherit from the common base
DetectorDescription/Identifier/Identifier.h ?
-
2. What is the source of the structure of the muon system?
Is it these identifiers or do they depend on something else?
-
3. Are we required to add Ma/Meesen hash conversion?
Choices
(See comment 4 and
comment 5.)
1. Our identifiers must provide access to the corresponding
Identifier object.
This is added to the requirements.
Our choice is to have our identifiers provide a method to
return the corresponding Identifier object.
We do not inherit from class Identifier.
2. The structure of the muon (and other) ATLAS subdetectors will
be specified in XML files interpreted by an identifier dictionary
package. The muon identifiers will use this dictionary to discover
information such as the number of and indices for elements at
a given level in the identifier hierarchy.
Information such as the position in the hierarchy (e.g. module
is specified by the first five indices) is built into the muon
identifier classes. See the
Detector structure design issue.
3. The Identifier class will provide a compact representation
which may also be used for hash conversion.
Detector elements have geometrical and other data associated with them.
For example modules and channels can have geometry
(location, orientation, ...) and calibration (ADC or TDC conversions)
attributes. Should our identifiers provide direct access to such
information?
Choice
No. The concept of identity does not depend on such attributes
We should not add dependencies on complicated systems like geometry
or calibration. Instead these systems can use the identifiers as
keys for accessing a table or database.
The muon identifiers specify the structure of the detector. They
know their level in the identifier hierarchy: for example, a module
requires five indices, e.g. 7/BOL/1/2/MDT.
The number of elements at each level is not built into the muon
identifier classes. Instead this is fetched from the identifier
dictionary. For example, the module identifier class would ask
the dictionary the number of and identifiers for its multilayers
(e.g. 7/BOL/1/2/MDT/0, 7/BOL/1/2/MDT/1). The dictionary can then
be used to discover the layers in a multilayer and finally
the channels in a layer.
Identifiers are constructed from indices specifying detector
elements. How do we manage invalid combinations of indices and
how do implement the default constructor (no arguments) required
for standard containers? There are two choices:
- 1. We can guarantee the indices are always valid by resetting
to some valid state or aborting if an invalid request is received.
- 2. We alllow identifiers to be in an invalid state.
Choice
We have chosen the second option.
Classes
We begin our design by identifying the classes and other types
needed to implement the muon identifiers.
There are four muon technologies. Below we will use Xyz or XYZ
to stand in for each of these:
- Xyz = Mdt, Csc, Rpc and Tgc
- XYZ = MDT, CSC, RPC and TGC
Muon system identifier
This would be called MuonDetectorId but is not needed in the
simple model we have developed so far.
Station identifiers
A station identified by a class XyzStationId.
Module identifiers
Classes XyzModuleId identify modules for each technology.
Each knows its station. A static of free function is able
to return the modules associated with a specified station.
Channel identifiers
Classes XyzChannelId (e.g. MdtChannelId) identify channels
for each technology. These know their module, multilayer
and layer. Static or free functions return the channel
identifiers associated with any of these elements.
dladams@bnl.gov