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:
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:
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.
<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.
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.
The LHCb XmlDDDB DTD allows an optional condition path in the definition of an IGeometryInfo. A specialised convertor in Det/DetDescCnv to construct an AlignmentCondition object when an XML string like the one used above to describe a 3D transformation is found by the parser. To enable off-nominal geometry in a detector element, it is necessary to give the detector element's geometryinfo definition a condition path, and modify the XML catalogue such that this path resolves to an XML string defining an AlignmentCondition.
This is an example of how to define a detector element with an AlignmentCondition path:
<detelem name="MUB_Up_Left_In_Plank13;"> <author> Juan Palacios </author> <version> 1.0 </version> <geometryinfo lvname ="/dd/Geometry/Delphi/MUB/UpLeft/lvMUB_Inner_13;" support="/dd/Structure/Delphi/MUB/UpperLeft/Inner/Plank13" condition="/dd/Conditions/Alignment/MUB/UpperLeft/Inner/Plank13" npath ="pvInnerPlank13"/> </detelem>
For a more full and realistic example check the VELO description in versions of XmlDDDB v26r0 or higher, Velo/v200507, for a good example on how to do this. For instructions on how to write this information into a copty of CondDB, or how to create a local copy, bypass CondDB for specific conditions and more, see the Conditions database How-to
This is done by default. GeometryInfoPlus uses the combined nominal and off-nominal transformation for all internal calculations. It is possible to access the nominal geometry, if necessary, via calls to the methods IGeometryInfo::toLocalMatrixNominal(), IGeometryInfo::toGlobalMatrixNominal(), etc. Note that in order to obtain the full alignment information of a sub-component of LHCb, its detector element must be queried via the detector data service, since this triggers the initialization of the off-nominal transformations. For example, accessing /dd/Structure/LHCb/Velo will not trigger the creation of the off-nominal geometry for the daughters of the Velo system, but will initialise that of the LHCb system. This has implications for the simulation of misaligned and visualization of detectors, since typically Gauss and Panoramix load the top element, and this initialises the static geometry of all its daughters. Therefore, special care has to be taken in order to access the full (nominal + off-nominal) geometry in these domains.
This geometry framework has been designed in order to make its incorporation into the detector descriptions of the LHCb subsystems and the use of misalignment information in all detector description client code as straight forward as possible. The use of the detector element guarantees that wherever the detector detcription data service is used, the misalignment information is automatically available. This has advantages, but also places constraints on the XML detector description. These are the requirements on a detector description:
This is all that's needed in order to incorporate the dynamic geometry functionality into the detector description of any given subsystem. This will allow users of the data service to move detectors, be it at initialisation via information stored in the conditions database, or in the course of a job via explicit modifications to the dynamic geometry information of differenc detector element objects. The framework takes care of coherently propagating the corrections such that all volumes dependent on the these also get moved.
To simulate misalignments at the moment GaussEnv v20r1 or higher is needed. This uses LHCb v18r8, which has the required Det/!DetDesc functionality.
-- JuanPalacios - 02 Oct 2007
I | Attachment | History | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|---|
LHCb_Palacios_v1.1.pdf | r1 | manage | 918.6 K | 2006-09-27 - 01:47 | JuanPalacios | LHC Alignment Workshop, Aug 2006: LHCb Detector Description | |
txt | cond.txt | r2 r1 | manage | 0.3 K | 2005-08-26 - 16:47 | UnknownUser | |
txt | detElem.txt | r1 | manage | 0.4 K | 2005-10-10 - 17:47 | UnknownUser |