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:

  • 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
    • 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.
  • Provide a mechanism to write a new set of deviations to the Conditions Database.
There is new a Q&A page which is largely empty. Please feel free to post your questions there.

Implementation in a nutshell

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

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.

IGeometryInfo implementation

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

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.
  • Give the geometryinfo definition of the relevant detector element a condition path.
  • 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.

Det/XmlConditions package

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:

        |          |_______LHCb  (single condition)
        |          |_______Velo  (flat catalogue)
        |          |_______TT    (empty)
        |          |_______Rich1 (empty)
        |          |_______IT    (empty)
        |          |_______OT    (empty)
        |          |_______Rich2 (empty)
        |          |_______Prs   (empty)
        |          |_______Ecal  (empty)
        |          |_______Hcal  (empty)
        |          |_______Muon  (empty)
        |          |_______Velo (flat catalogue with examples)
        |          |_______Prs (single cond.)
        |          |_______Ecal (single cond.)
        |          |_______Hcal (single cond.)
        |          |_______Muon (readout conditions)
        |                    |___Grid (flat catalogue)
        |                    |___Cabling
        |                           |_____M1 (flat catalogue)
        |                           |_____M2 ( "      "     )
        |                           |_____M3 ( "      "     )
        |                           |_____M4 ( "      "     )
        |                           |_____M5 ( "      "     )
        |          |_______LHCb  (flat catalogue)
        |          |_______Rich1 (flat catalogue)
        |          |_______Rich2 (flat catalogue)
        |           |_______Prs  (empty) 
        |           |_______Ecal (empty)
        |           |_______Hcal (empty)
        |           |_______Muon (empty)
        |______Trigger/ (empty)

For more details on how to write conditions in XmlConditions, see the XmlConditions wiki or contact Juan directly.

Accessing the information

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.

Using misalignments in sub-detector descriptions

This alignment 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:

  • The structure hierarchy must be such that there is a detector element associated to each element that needs to have misalignment information. This means that the leaves of the structure tree should correspond at least to the smallest alignable object. The detector elements do not need to be specialised. It will suffice to have a default one, since all the functionality is handled via the IGeometryInfo held by the base class, which is constructed when a default detector element is defined in the XMLDDDB description.
  • The geometryinfo in the detector element must have a path pointing to an AlignmentCondition in the data service. In practice, the detector element definition should look something like this example from a past detector.
  • A catalogue structure to support the paths to AlignmentConditions must be set up. This should be done in the Det/XmlConditions package. The package is new and in a somewhat volatile state. For this reason, it is better to contact me in order to set the catalogues up. The catalogue structure is under review and there should be a more stable version soon.
  • The caching of geometrical information that might be alignment-dependent must be done in a controlled manner. Caching should be steered from a minumal number of methods, and each of these should be registered appropriately to the update manager service. This step requires careful attention and thought from the subsystem experts, as there is no automatic recipe to apply it. This is already implemented in the DetDesc classes, but specialized, derived classes should take care to implement it correctly. For an example look at the GeometryInfoPlus class source code.

This is all that's needed in order to incorporate the alignment framework 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 stored misalignment information, or in the course of a job. The misalignments will be propagated coherently such that all volumes dependent on the misalignment also get moved. Note that the misalignments will not necessarily be seen by the simulation, since this does not use the full detector element tree, but rather starts from a top level and thus ignores the misalignments of the branches and leaves.

Status (LHCb v18r8 or higher)

Current functionality

Detector elements can be freely moved around with respect to their nominal positions during the course of a job. The changes are propagated correctly via the UpdateManagerSvc, and can be visualised using the Gauss visualisation tools or Panoramix. AlignmentCondition objects can be created by hand, or existing ones can be modified. These can be turned into XML strings and stored in the conditions database. A full working example with the VELO has been developed. It is possible to simulate a misaligned VELO, but NOT to an arbitrary depth in the detector element hierarchy. It is only possible down to the module level (R-Phi sensor pair plus hybrid and support). There is at the moment no automatic way of accessing all the misalignment information up to the leaf level in the detector element hierarchy while guaranteeing that all the components which are not detector elements are also simulated.

Work in progress

  • Simulating misaligned detectors: This is not as trivial as it seems. The problem is explained here.
  • AlignmentCondition interface: Waiting for feedback. Does this simple class satisfy the requirements of users?
  • Tools for AlignmentCondition creation. Would be nice to generate AlignmentConditions in a more general ways. Axes of rotation, pivot points, etc. Tools should allow the AlignmentCondition interface to remain largely unchanged.

Working example: the VELO


  • Set an environment that uses LHCb v18r8 or higher
    • LHCbEnv or compatible GaussEnv, BooleEnv, EulerEnv, MooreEnv, BrunelEnv, DaVinciEnv, etc.)
  • getpack Det/XmlConditions v1r1 or higher. XmlConditions has a dummy catalogue of AlignmentConditions that can be edited by hand in order to create misalignments.
  • Make sure your application uses Det/XmlDDDB v26r2p2 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions v1r1 Det -no_auto_imports" after the "use XmlDDDB" line in the requirements file of your application.
  • In the relevant options file, point to the LHCb with the new VELO geometry: DetectorDataSvc.DetDbLocation = "$XMLDDDBROOT/DDDB/lhcb-200507.xml"
  • Go to Det/XmlConditions/v1r1/DDDB and look at file conditions.xml. File conditions.xml points to a location for the VELO misalignments: Local/Velo/alignment.xml#Velo. This contains a flat catalogue with default misalignment parameters for the Velo, the halves, the modules. You can change these default parameters to what you like.
-- JuanPalacios - 04 Aug 2005

Simulating misalignments

To simulate misalignments at the moment GaussEnv v20r1 or higher is needed. This uses LHCb v18r8, which has the required Det/!DetDesc functionality.

  • Set the environment: GaussEnv v20r1 (or higher)
  • Get the Det/XmlConditions package as described above
  • From your CMT build directory: getpack Sim/Gauss v20r1 (or higher, must match GaussEnv)
  • modify Sim/Gauss/v20r1/options/SimGeometry.opts:
    • comment out Geo.StreamItems += {"/dd/Structure/LHCb/Velo"};
    • uncomment #include "$GAUSSOPTS/SimVeloGeometry.opts"
  • Modify $GAUSSROOT/cmt/requirements to use XmlDDDB v26r1 and your XmlConditions
  • go to $GAUSSROOT/cmt and source setup.csh. Check that the $CONDITIONS_PATH points to your XmlCondiitons directory.
  • Modify the alignment parameters in $XMLCONDITIONSROOT/DDDB/Local/Velo/alignment.xml

- JuanPalacios - 29 Jul 2005


-- JuanPalacios - 02 Oct 2007

Questions and Answers

-- JuanPalacios - 10 Oct 2005

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf LHCb_Palacios_v1.1.pdf r1 manage 918.6 K 2006-09-27 - 01:47 JuanPalacios LHC Alignment Workshop, Aug 2006: LHCb Detector Description
Texttxt cond.txt r2 r1 manage 0.3 K 2005-08-26 - 16:47 UnknownUser  
Texttxt detElem.txt r1 manage 0.4 K 2005-10-10 - 17:47 UnknownUser  
Edit | Attach | Watch | Print version | History: r28 | r26 < r25 < r24 < r23 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r24 - 2007-10-02 - JuanPalacios
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

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