Difference: GeometryFramework (24 vs. 25)

Revision 252007-10-05 - JuanPalacios

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"

Introduction

Changed:
<
<
This page refers to the alignment section of the LHCb detector description framework. If you are not familiar with the Gaudi detector description framework read about it in the Detector Description chapter of the Gaudi user guide. The use case can be summarised as follows:
>
>
This page refers to the geometry and alignment section of the LHCb detector description framework. If you are not familiar with the Gaudi detector description framework read about it in the Detector Description chapter of the Gaudi user guide. The use case can be summarised as follows:
 
  • Provide users of the LHCb detector data service with geometrical information obtained from two places:
    • Nominal or ideal positions of all the sub-components of LHCb
Changed:
<
<
    • Deviations from the nominal positions. Thought of as deltas or misalignemts. These are to be obtained from user-specified test files of from the Conditions Database.
  • Provide a mechanism for users to modify the alignment deviations for a given sub-component in a coherent, consistent way. Users should be able to change the alignment of a sub-detector and see the changes automatically propageted to all the dependent sub-components.
>
>
    • Deviations from the nominal positions. Thought of as deltas, misalignemts or off-nominal deviations to the above. These should be obtainable from the Conditions Database, and could be modified and propagated at runtime.
  • Provide a mechanism for users to modify the off-nominal deviations for a given sub-component in a coherent, consistent way. Users should be able to change the alignment of a sub-detector and see the changes automatically propagated to all the dependent sub-components.
 
  • Provide a mechanism to write a new set of deviations to the Conditions Database.
Deleted:
<
<
There is new a Q&A page which is largely empty. Please feel free to post your questions there.
 
Changed:
<
<

Implementation in a nutshell

>
>

Design (under construction)

The introduction of an off-nominal alignment to the LHCb detector description is accomplished by mirroring the nominal positioning of detector sub-components in the geometry description, which is in turn achieved through a hierarchical tree-like structure of DetectorElements, as described in the Detector Description chapter of the Gaudi manual, or in this LHCb contribution to the LHC Alignment Workshop, 2006. This mirroring is achieved by giving each node in the DetectorElement hierarchy the necessary off-nominal alignment information, which simply is a correction to its nominal position within the structure. This, coupled with the links between DetectorElement and higher and lower members of the hierarchy, allows for a coherent propagation of the off-nominal deviations from one DetectorElement to those which depend on it (in practice, those which are positioned within it). At all times it is possible to get the nominal geometry information, be it in a local frame or in the global reference frame. We thus have two geometries within the DetectorElement hierarchy tree. These can be thought of as
  • Nominal geometry: Defined by the positioning information in the Geometry DB (which package is this steered from these days?), it should reflect either the design positioning of the elements of LHCb, or the best knowledge of their position, following survey measurements. At the moment of writing it is still not clear which of the two shall define the nominal geometry. An important fact is that this informaiton is loaded by the Gaudi framework at initialisation, and cannot be changed consistently after that. Therefore this geometry is to be considered as fixed in the course of a software job, and shall be refered to in what follows as static.
  • Off-nominal geometry: Describes the corrections or deviations from the nominal geometry, both locally at the level of each node in the hierarchy tree, and globally. Combined with the nominal geometry, it defines the local and global position of each DetectorElement in the hierarchy. The corrections or deviations are 3D transformations that can be modified during the course of a job. This can be done manually by direct manipulation in software, or automatically if the data being analised has been associated to different alignment constants. All the changes are propagated throughout the hierarchy automatically. Since the off-nominal geometry can be modified at will, it shall be referred to in what follows as dynamic.

Implementation

The basic principle behind the implementation of the alignment functionality is that off-nominal information is handled, together with nominal geometrical information, in an implementation of the IDetectorElement interface, via an implementaiton of the IGeometryInfo interface. In practice this means that any LHCb sub-component that needs to use this functionality must be a DetectorElement. Furthermore, its IGeometryInfo must be initialised with an address in the data service which points to an AlignmentCondition, be it in a local file or in the conditions database. The functionality is handled in the Det/DetDesc, Det/DetDescCnv and Det/DescSvc packages for LHCb versions higher or equal to v18r8. Here are a few key points in getting this functionality to work:

 
Deleted:
<
<
The basic principle behind the implementation of the alignment functionality is that alignment information is handled, together with nominal geometrical information, in the detector element, via the IGeometryInfo class. In practice this means that any LHCb sub-component that needs to use this functionality must be a detector element. Furthermore, its IGeometryInfo must be initialised with an address in the data service which points to a condition, be it in a local file or in the conditions database. Changes have been made to the Det/DetDesc and Det/DetDescCnv packages to incorporate this functionality, and a working example exists with a new VELO XML geometry description and specialized detector element suite. The full functionality is available in LHCb releases v18r8 and higher. With LHCb v18r7 it is possible to initialise the detector with deviations from the ideal, but not to change the alignment parameters on the fly. Here are a few key points in getting this functionality to work:
 

The AlignmentCondition class

Changed:
<
<
AlignmentCondition is a very simple class which contains nine alignment parameters and a transformation matrix. The six first parameters are mandatory and describe translations and rotations with respect to the Cartesian axes, in the local reference frame of the parent detector element. By default this is done wrt. the origin in that frame of reference. Three optional parameters define a position, or pivot, in the local frame, about which the rotation takes place. The transformation matrix is calculated from these parameters. Typically, an alignment condition is constructed automatically from an XML string by a specialised XML convertor. It is also possible to make an alignment condition by hand from six or nine parameters, or to update the transformation matrix by changing the values of the parameters.
>
>
AlignmentCondition is a very simple class which essentially contains a 3D transformation object and the nine double precision parameters required to generate one following an LHCb convention, and has awareness of time-validity. The LHCb convention to combine the parameters to get a 3D transformation is described below. It is possible to update the 3D transformation directly, or feed the AlignmentCondition new parameters. Internally, it either calculates the parameters by decomposing the new 3D transformation, or calculates the transformation from a new set of parameters. In this way, parameters and 3D transform are always synchronised. This is important since the conditions database stores an XML string which encodes the nine parameters, but all numerical calculations are performed using the transformation object. The XML string encoding the parameters is obtainable on-demand from the AlignmentCondition, and must always reflect the state of the 3D transformation. The calculation of the 3D transformatin, together with its decomposition into nine parameters, are implemented in the DetDescFunctions set of helper functions.

The LHCb recipe to create a 3D transformation

In the LHCb detector description framework, the convention for a 3D transformation is combine a 3D translation and a 3D rotation by applying the rotation first and the translation second (see the LHCb XML detector descripton DTD note. For the purposes of off-nominal corrections, the possibility to provide a pivot point for the rotation has been added. This is, at the time of writing, not accessible to the static geometry description. There are many ways to express a rotation in terms of a set of parameters (different 3D coordinate systems, different Euler angles representations, Quaternions, Axis angles) and the detector description geometry XML DTD allows for a number of these. These are being reviewed at the time of writing so I will swiftly skip on to what is currently essential in the context of off-nominal deviations. For a discussion of proposed changes and extensions to the DTD see slides 1 to 7 of this T-Rec talk. However, the off-nominal geometry is limited to a cartesian representation of a rotation. A dynamic geometry 3D transformation is defined by three sets of three double precision parameters, as can be seen here in the XML definition of an AlignmentCondition:
    <condition classID="6" name="VeloSystem">
      <paramVector name="dPosXYZ" type="double">0*mm 0*mm 0*mm</paramVector>
      <paramVector name="dRotXYZ" type="double">0*rad 0*rad 0*rad</paramVector>
      <paramVector name="pivotXYZ" type="double">0*mm 0*mm 0*mm</paramVector>
    </condition>
Each set represents a translation about cartesian axes, a rotation about cartesian axes, and a cartesian pivot point about which the rotation is performed. The rotation is described by the Euler 321 co-moving axes representation, that is, a rotation about the Z axis, followed by one about the Y' axis, followed by one about the X'' axis. The rotation is performed about the pivot point, and the translation is applied last. The calculation of the 3D transform is performed inside the AlignmentCondition implementation via a call to a publically available free function from DetDesc/3DTransformationFunctions.h:
const Gaudi::Transform3D localToGlobalTransformation(const std::vector<double>& translationParams,
                                                     const std::vector<double>& rotationParams,
                                                     const std::vector<double>& pivotParams )
It is expected that the future changes to the DTD will do away with the use of simple but unsafe std::vectors of doubles and unify the description of 3D transformations for static and dynamic geometries.
 

IGeometryInfo implementation

Changed:
<
<
This new implementation, class GeometryInfoPlus, contains a pointer to an AlignmentCondition, which it obtains from the data service via an address passed to it upon construction. Each detector element contains one of these, and each one of these contains one, and only one, AlignmentCondition. The task of the GeometryInfo is to calculate the transformation matrices relating it to the global LHCb frame. For this it needs to navigate through the hierarchy of detector elements, picking up the ideal and delta transtofmations of its parents and calculating the total transformation matrix. It also must ensure that if the transformation in its own AlignmentCondition changes, the changes are propagated to its daughters, as their relation to the global frame depends on their parents. The new implementation also makes use of the CondDB data store interface, allowing for retrieval of AlignmentConditions from the conditions database if necessary, and of the UpdateManager, which establishes a network of dependencies between objects and conditions to allow for the coherent propagation of changes. The combined ideal and delta transformation replaces the ideal transformation inside this implementation of IGeometryInfo, meaning that all delta information is made accessible to the user automatically when they query the detector element.

Changes to XML detector description

>
>
This implementation, class GeometryInfoPlus, contains a pointer to an AlignmentCondition, which it obtains from the data service via an address passed to it upon construction. Each detector element contains one of these, and each one of these contains one, and only one, AlignmentCondition. The task of the GeometryInfo is to calculate the transformation matrices relating it to the global LHCb frame. For this it needs to navigate through the hierarchy of detector elements, picking up the nominal and off-nominal transformations of its parents, and calculating the total transformation matrix. It also must ensure that if the transformation in its own AlignmentCondition changes, the changes are propagated to its daughters, as their relation to the global frame depends on their parents. The new implementation also makes use of the CondDB data store interface, allowing for retrieval of AlignmentConditions from the conditions database if necessary, and of the UpdateManager, which establishes a network of dependencies between objects and conditions to allow for the coherent propagation of changes. The combined nominal and off-nominal transformation defines the local and global position of each IGeometryInfo, meaning that all off-nominal corrections are made accessible to the user automatically when they query the detector element. The IGeometryInfo also keeps the nominal information, such that, at each level in the hierarchy, it is possible to know where the nominal global position of a DetectorElement is.

Off-nominal geometry in the XML detector description

  The LHCb XmlDDDB DTD has been modified to add an optional condition path to the definition of a geometryinfo. A specialised convertor has been added to Det/DetDescCnv to construct AlignmentConditions when the right kind of XML string is found by the parser. The changes required from users are:
  • Make whatever you want to align/misalign into a detector element.
Line: 29 to 53
 
  • Make sure this path resolves to something, for example an XML string defining an AlignmentCondition in an XML catalogue.
  • Check the VELO description in versions of XmlDDDB v26r0 or higher, Velo/v200507, for a good example on how to do this.
Changed:
<
<

Det/XmlConditions package

>
>

Det/XmlConditions package - NOW OBSOLETE

  This package is designed to hold a persistent, local copy of conditions for use by the detector data service in the absence of a real working database. It allows to check most of the features of the alignment framework and the update manager system. It also allows users to change conditions without having to affect the whole of XmlDDDB. It is here that the detector-specific conditions catalogues should be placed. At the moment it contains largely empty catalogues for alignment, readout configuration, calibration, trigger settings and environmental conditions for different set sof subdetectors. The last iteration of the structure, in the head revision Det/XmlConditions, looks like this:
Line: 80 to 104
 

Accessing the information

Changed:
<
<
This is done by default. GeometryInfoPlus uses the combined ideal and delta transformation for all internal calculations and in its public interface. It is possible to access the ideal transformations if necessary. Note that in order to obtain the full alignment information of a sub-component of LHCb, its detector element must be queried. For example, accessing /dd/Structure/LHCb/Velo will not get the information for the daughters of the Velo system. This has implications for the simulation of misaligned detectors, as is explained below.
>
>
This is done by default. GeometryInfoPlus uses the combined nominal and off-nominal transformation for all internal calculations and in its public interface. It is possible to access the ideal transformations if necessary. Note that in order to obtain the full alignment information of a sub-component of LHCb, its detector element must be queried. For example, accessing /dd/Structure/LHCb/Velo will not get the information for the daughters of the Velo system. This has implications for the simulation of misaligned and visualization of detectors, as is explained below.
 

Using misalignments in sub-detector descriptions

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