CMS FPix Geometry Workpage

CMS Forward Pixels Simulation Geometry

This page provides technical information on the CMS Forward Pixels simulation geometry description based on the DDD framework.

Forward Pixels detector geometry

The forward pixels detector consists of two endcaps that are point-symmetric with respect to the CMS IP. Each endcap has two disks located inside service cylinders. Each disk contains 24 blades. There is a shift in Z between the adjacent blades, and each blade is rotated by 20 degrees around its axis to provide overlap in angular coverage. The blades consist of an aluminum base with a cooling channel and two panels, one on each side of the blade. Cooling channels of adjacent blades are connected by nipples. Each panel has a panel base (beryllium base plus HDI) and three of four sensor plaquettes.

Design goals and principles

The package was developed to replace the old forward pixels geometry description that was machine-translated from the format of the previously used Geant-3 based simulation code. The old geometry was out-of-date, not human-readable, and impossible to modify. Therefore, the new package was developed from scratch.

Requirements:

Produce DDD-based description of the forward pixels detector based on latest drawings.
- Maximize use of symmetry.
Make it flexible and easily extendable
- Critical since the design of some components is not final.
Keep most of the description in XML, avoid shifting complex placements into C++ algorithms.
- Only one custom algorithm has been introduced.
Reference frames of all sensitive volumes should be right-handed, with Y pointing along the longer side of the sensor, Z in the direction of the electric field. X axis points away from the beam line for all 3-plaquette panels, towards beam line for all 4-plaquette panels.
- This requirement is imposed by digitization and reconstruction software that directly uses local reference frames of sensitive volumes as seen by Geant4 tracking, without any conversions.
- To satisfy this requirement, a lot of code had to be duplicated instead of using reflections.

Implementation notes:

Each file describes a subsystem or a set of related components, and does not use any references (constants, volumes, etc.) from files higher in the volume tree. Each subsystem has a single entry point (root volume), and is assigned an "anchor point" (see annotated drawings). The file that describes a subsystem defines constants AnchorX, AnchorY, AnchorZ that correspond to the coordinates of the anchor point in the subsystem's root volume reference frame (if some of these constants are not defined, they are assumed to be zero). Subsystems are positioned by placing their anchor points using these constants.

Therefore, each subsystem can be visualized and tested independently. Changes in one subsystem do not affect code for the others. It is easy to reposition a whole subsystem, and any changes inside the subsystem code do not affect its positioning as long as AnchorX, AnchorY, AnchorZ are still defined correctly.

Orientation of the local reference frames of sensitive volumes is shown on this sketch.

Package Structure

Click on the file name for more information :

Imagemap

The order of files in the configuration should follow the dependency flow - this might be important for files that contain algorithm invocations. Sample configuration file is provided.

Source code

The current production version can be checked out from CMS CVS:

CVSROOT:   :pserver:anonymous@cmscvs.cern.ch:/cvs_server/repositories/CMSSW
Package:   Geometry/TrackerCommonData

Development and archive versions are available from

/afs/fnal.gov/files/home/room3/onoprien/public/FPix/

In addition to CVS tags assigned to officially committed versions, each development version is given an internal version number in the AA.BB.CC format. This number can be found in the header of every file. The major version number "AA" is changed whenever there are major changes in the geometry described by the code (like adding a new subsystem), or there are major changes in the implementation of the package. The minor version number "BB" is changed whenever there are minor changes in the geometry (more elaborate description of some component, for example). Build number "CC" is changed when minor bugs are fixed or minor changes transparent to the user are made to the implementation.

I expect this "internal versioning" scheme will become unnecessary once the package is sufficiently mature, but it proved to be highly useful in the active development stage.

Current development version: 3.02.02
Current committed version: 3.02.01
Brief summary of changes made in each version can be found in the change log.

Last updated : June 6, 2006 by Dmitry Onoprienko