   |  |
Computing Technical Design Report
| | |
Computing Technical Design Report
The description of the ATLAS detector relies on two main software components: first, a relational database which implements a schema capable of hierarchical version control, and second, a set of geometrical primitives in terms of which the ATLAS detector is described.
A detector version tag, described in Section 3.5.1 , is specified at simulation time, or at the time that real data is recorded, and that version is persistified along with the event data. The tag is used as a key into the relational database in order to retrieve a configuration, including all switches governing the detector geometry, and other properties related to the detector itself; in practice there is a fine line between certain types of detector description data and calibration data: e.g. magnetic fields. All data related to detector description should (ultimately) reside in that database.
The detector description is then built from the primary numbers describing the detector and switches. It includes all material geometry (the part which is seen directly by the simulation engine, Geant4 [3-11]) in addition to the readout geometry; for example, implant layers within silicon detectors; projective towers in the calorimeters, and similar. The geometry kernel provides mechanisms for expressing the geometry description into a minimal amount of memory. Subsystem developers have been made aware of memory optimization techniques. The current requirement for the entire ATLAS detector is 48 MB.
The detector description supports misalignment, both at simulation time or at reconstruction/analysis time. These misalignments are obtained from an alignment database and injected into the geometry description.
The IOVSvc is intended to be used during data-taking operations to map the time and date onto particular detector geometries. This does not interfere with the geometry tag definitions or the management of such tags, but can be considered as a separate, higher-level activity.
It should be noted that much of the work of defining the detector geometry is carried out on a subsystem-by-subsystem basis, where considerable customization is possible. Only the common aspects of detector description are described here. The following sections describe the hierarchically versioned relational database schema (HVS), and the geometry kernel which provides the set of geometrical primitives used to store the detector configuration.
All primary numbers in the Geometry DB are logically grouped into ATLAS subsystem-specific "structures", which map to rows within data tables. The structures are logically grouped into "directories". Each directory can simultaneously contain child structures and subdirectories, and thus form a kind of hierarchy. In the Hierarchical Versioning System (HVS) the directories are called branch nodes and the structures leaf nodes. Characteristics of the tagging schema are:
The relational database schema of the Geometry DB can be decomposed into two main components:
The HVS component consists of three tables:
Each HVS leaf node (structure) has two tables on the data component side:
To manipulate the data in the Geometry DB effectively we have introduced three user accounts: Administrator, Writer and Reader. The person responsible for an ATLAS subsystem inserts the data into the Data component tables directly, executing SQL scripts via the SQLPLUS command line utility. For this purpose the Writer account is used.
Various manipulations with HVS nodes and tags can be done through a password-protected interactive Web interface. These operations include: creating new HVS node (branch and leaf); creating new HVS tag, deleting unlocked records from data tables, collecting tags and tag locking.
To read the data from the Geometry DB within Athena applications a dedicated Athena service, RDBAccessSvc, has been developed, which resides in the Database/AthenaPOOL container package. The RDBAccessSvc has been developed using the POOL Relational Access Layer, which provides the mechanism of uniform access to the data residing in the different RDBMS (Oracle, MySQL, SQLite). The RDBAccessSvc service allows simple manipulations with database connection (connect/disconnect) and also provides a uniform access to the versioned data in the Data component tables via the recordset objects. The recordset represents a snapshot of some data table, which includes only the records corresponding to the requested tag.
The GeoModel toolkit is a library of geometrical primitives that can be used to describe detector geometries. The toolkit is designed as a data layer, and especially optimized in order to be able to describe large and complex detector systems with minimum memory consumption. Some of the techniques used to minimize the memory consumption are: shared instancing with reference counting, compressed representations of Euclidean transformations, special nodes which encode the naming of volumes without storing name-strings and, especially, parametrization through embedded symbolic expressions of transformation fields. A faithful representation of a GeoModel description can be transferred to Geant4. Native capabilities for geometry-clash detection and for material integration are foreseen for the near future. GeoModel's only external dependency is CLHEP.
The GeoModel toolkit provides application developers with a complete set of mechanisms for the description of the entire ATLAS detector with minimal memory consumption. The main purpose of GeoModel is to support a central store for detector-description information that can be accessed by two main clients - simulation and reconstruction programs. GeoModel provides a scheme for accessing both the raw geometry of a detector and arbitrary subsystem-specific geometrical services synchronized to the raw geometry, while incorporating time-dependent alignments. An automatic version detection system has also been developed.
In ATLAS, visual debugging tools developed with the use of the Open Inventor toolkit complement the GeoModel toolkit. These debugging tools include an interactive Geometry Browser1 that allows various manipulations with volumes: navigation of volume hierarchy, iconization, printing of volume characteristics such as mass, shape dimensions, name and copy number. When used together with simulated data the Browser can also visualize tracks and hits on top of raw geometry.
In the following sections the design principles of the GeoModel toolkit are described, together with memory optimization techniques and also the mechanism for converting GeoModel descriptions to Geant4.
Material geometry consists of a set of classes that resembles closely the Geant4 material geometry classes. These classes, however, are designed to take a minimal size in memory. This requirement determines the basic data structure used to hold the data for the geometry description. That structure is a graph of nodes consisting of both physical volumes and their properties (name, identifier, transformation in local coordinate system). The tree is built directly and accessed in a way that provides users with access to volumes and, simultaneously, to the properties accumulated during graph traversal that apply to the volumes.
Physical volumes are the main building blocks of the geometry graph. The structure of a physical volume consists of an associated logical volume (describing just shape and material) and a set of child physical volumes and their properties. In GeoModel two types of physical volumes are identified:
When one adds a transformation in the graph, it controls the position of the subsequent volume with respect to the parent. If one adds more than one transformation to the volume before adding a parent, they will be applied successively. The last transformation to be added is applied first to the child. Like physical volumes, transformations come in two types:
GeoModel includes also three mechanisms for giving names to physical volumes:
The readout geometry layer consists of geometrical information that is not declared directly to the particle-tracking engines (Geant4), for example: projective towers within a calorimeter, or the boundaries of ion implant layers in silicon detectors. Information such as the position of the boundaries of these regions is not required in the simulation of basic physics processes, though it certainly is required in the digitization, and possibly hit-making phase of simulation (Sensitive Detectors).
Detector-specific geometrical services can and should include services that derive from the basic raw and readout geometry of the detector. Such services could include point-of-closest-approach calculations, global-to-local coordinate transformations, calculations that compute the total number of radiation lengths within a cell etc.
The description of the detector-readout system can be realized with the use of Detector Elements. The detector element has a required association with a piece of material geometry (full physical volume), and has access to that piece. The rest of the interface - all of the geometrical services discussed above, such as the boundaries of implant layers, strip pitches, etc., can be placed in the detector element.
In GeoModel applications, the Detector Manager objects play a central role in providing an interface to Detector Description clients. Detector Managers manage raw and readout geometry and are responsible for providing a fast mechanism for accessing the detector elements in a detector-specific way.
Thus in general the subsystems developers have a lot of flexibility, but need to devise an interface to both the detector manager and the detector element that satisfies their needs. The basic framework requires only that
Additional readout information appears in the interface to the detector manager and the detector element.
The requirement of minimizing the memory consumption has resulted in a design in which objects in the detector description can be re-used. This is called shared instancing. It essentially means that an element, compound volume, or entire tree of volumes may be referenced by more than one object in the detector description. The following use-cases for shared instancing exist: a small number of physical volumes can share the same logical volume, the same name tags and identifier tags can label different volumes, and the transformations can be used more than once in the geometry graph.
GeoModel includes some other memory optimization techniques: Serial Denominators can generate name strings for physical volumes so that the memory does not fill up with nearly identical ASCII name tags; "tiny" transforms (where the footprint for a simple translation along z, for example, is the size of one floating point number) reduce the size requirement for most transformations; finally, volumes can be parametrized (this mechanism is discussed in the next section).
Parametrizations are mathematical recipes for creating volumes. There are three main ingredients to these recipes:
This combination allows a single entity to be placed on the geometry graph which will then appear to contain multiple physical volumes at different locations. However, only the memory of a single physical volume and a TRANSFUNCTION is actually allocated.
In order to run the Geant4 simulation of a detector described in GeoModel it is necessary to build a Geant4-specific raw geometry based on the GeoModel description. A tool called Geo2G4 has been developed for this purpose. This automatically translates the GeoModel description to Geant4 by navigating the GeoModel raw geometry graph. To make the resulting geometry memory-efficient a set of memory optimization techniques has been implemented, which are applied during the translation:
The capability of translating GeoModel serial transformers into Geant4 parametrizations is provided through the G4STParameterisation class. This can be used directly in Geant4 applications for the purpose of creating G4 parametrizations without subclassing. G4STParameterisation objects perform volume parametrizations as in GeoModel, in particular with the use of TRANSFUNCTIONS.
The ATLAS GeoModel project started in summer 2002. Since then the geometries of all ATLAS detector subsystems have been described using GeoModel mechanisms. Reference [3-12] describes the way in which all of ATLAS is described in terms of GeoModel. The GeoModel descriptions of tracking detectors have been extensively used in simulation since ATLAS Data Challenge 2. The tile calorimeter was also used in the simulation of data for the Rome Physics Workshop. The liquid argon calorimeter detector description using GeoModel has been completed recently, and will be used in future productions. Reference [3-13] describes the simulation of ATLAS and the operational experience in DC2. It is also planned to develop all subsequent versions of ATLAS detector (Initial Layout, Realistic Geometry etc.) using GeoModel and the Geometry Versioning System.
The data coming from the ATLAS detectors require access to the appropriate "detector description" information in order to be used. For example, one needs to calibrate the individual channel responses, calculate their positions and correct for misalignment. This can be done in many ways, but ultimately relies on a key-lookup to match the readout data with its detector-description data.
The solution that has been chosen in ATLAS consists of an identification scheme that follows the logical hierarchical structure of the detector. For example, the SCT, silicon strip tracker, is composed of a barrel and two endcaps, and several layers of two-sided modules distributed in η and φ. Following this structure, the identifier specification of each silicon strip is:
InnerDetector/SCT/barrelorendcap/layer/phi_module/eta_module/side/strip
where each level is represented by a number. The hierarchical structure allows one to extract identifiers with the full or partial hierarchy - readout identifiers correspond to the full hierarchy. In ATLAS the following "three-level" model has been found to be useful:
Detector subsystem ⇒ detector elements ⇒ readout channels
where for the silicon tracker one would have SCT ⇒ wafer (side) ⇒ strip. The interest is in "projecting out" from this specification the identifiers for the detector subsystem, detector elements and readout channels. This three-level model is reflected in both the event and detector-description models. Identifiers are used as look-ups both within and between these models.
The software infrastructure to support this identification system consists of:
The basic infrastructure has been in place since 1998, using identifiers in an expanded form (vector<short>). A complete specification of the identifiers for each detector system was completed in 2001, specified in an ATLAS software note [3-14]. In 2002 a migration to the use of an identifier dictionary was completed, which allowed the use of compact and hash identifiers that are more efficient in terms of space and look-up speed.
Two forms of identifiers are currently in use:
The compact id contains the information of the identifier in bit-packed form. They can be used to extract the level information or as a binary look-up key. Hash identifiers have been introduced to improve upon the binary-lookup, reducing this to a constant-time look-up2. This is possible within a certain "context" or rather for a specific set of identifiers: the set of detector elements for a given sub-detector can be enumerated and each assigned its "hash" id that is simply a number from 0 to N-1. This hash id can be used in a table look-up.
The identifier dictionary formally defines a logical hierarchy and provides a name for each of the hierarchy levels. The identifier dictionary describes the set of non-overlapping regions of valid values for the hierarchy levels. The regions are divided into separate dictionaries for convenience, for example for each detector system, and are kept in separate files. This allows a representative for each detector system to maintain their part. These files can be versioned in the Hierarchical Versioning System (HVS) of the geometry database. As a first step, the file name is stored in the geometry database, and the contents of the file itself will eventually replace this.
A dictionary is first described as an XML file. Then a XML parser converts this dictionary into an IdDictDictionary object, which calculates the number of bits and allowed values for each identifier level. This allows efficient mask-and-shift operations to be performed for each level of the different dictionaries.
Identifier helper classes have been developed for each detector system to simplify the interactions with the dictionary. They localize to a single place in the software where identifiers may be created or decoded. Each helper is tailored to the specific detector identifiers, for example for decoding the specific levels. The helpers are initialized from their corresponding dictionary. The helpers transform a set of compact identifiers into their corresponding hash identifiers. The helpers can provide iterators over the set of identifiers. Finally, the helpers can provide fast access to neighbouring identifiers since this knowledge can be obtained from the dictionary, where one can specify, for example, that some hierarchy levels "wrap-around" in 2π for the cylindrical ϕ coordinate.
The constant-time access of the hash identifiers is used in a variety of ways for each of the detector systems. For the calorimeters, the individual readout channels have identifier hashes so that the data (e.g. CaloCells) or their description (e.g. eta/phi) may be easily accessed. For the tracking detectors, a three-level container (IdentifiableContainer) has been developed:
container ⇒ collection ⇒ object
where the collection granularity corresponds to the detector elements, for example a silicon wafer, and the object may be a silicon strip/pixel. This is used for fast access to data in different contexts: for example in tracker pattern recognition or in the online software where a region of interest is transformed into a set of detector element identifier hashes, and the corresponding "collections" are decoded by the byte-stream converters.
1. The Geometry Browser is described in Section 3.6.3 , "HEPVis/v-atlas".
| | |
Copyright © CERN 2005