Difference: GeometryFramework (23 vs. 24)

Revision 242007-10-02 - JuanPalacios

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

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:

Changed:
<
<

New AlignmentCondition class

>
>

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.
Changed:
<
<

New IGeometryInfo implementation

>
>

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

Line: 29 to 29
 
  • 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:
<
<

New Det/XmlConditions package

>
>

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:
Line: 130 to 130
 

Presentations

Added:
>
>
 
Line: 138 to 140
 
Added:
>
>
-- JuanPalacios - 02 Oct 2007
 
Changed:
<
<
-- JuanPalacios - 23 Aug 2006

Post your questions

>
>

Questions and Answers

 
-- JuanPalacios - 10 Oct 2005
 
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