Difference: GeometryFramework (25 vs. 26)

Revision 262007-10-08 - JuanPalacios

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"
Line: 11 to 11
 
  • 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.

Changed:
<
<

Design (under construction)

>
>

Design

 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.
Line: 53 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 - NOW OBSOLETE

>
>

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: 104 to 104
 

Accessing the information

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

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

Deleted:
<
<

Working example: the VELO

General

 
Deleted:
<
<
  • 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.

 
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