Difference: GeometryFramework (1 vs. 28)

Revision 272007-10-08 - JuanPalacios

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

Off-nominal geometry in the XML detector description

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

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:

>
>
This is an example of how to define a detector element with an AlignmentCondition path:
 
Changed:
<
<
/dd/Conditions/ |______Alignment/ | |_______LHCb (single condition) | |_______Velo (flat catalogue) | |_______TT (empty) | |_______Rich1 (empty) | |_______IT (empty) | |_______OT (empty) | |_______Rich2 (empty) | |_______Prs (empty) | |_______Ecal (empty) | |_______Hcal (empty) | |_______Muon (empty) | |______ReadoutConf/ | |_______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 ( " " ) | |______Environment/ | |_______LHCb (flat catalogue) | |_______Rich1 (flat catalogue) | |_______Rich2 (flat catalogue) | |______Calibration/ | |_______Prs (empty) | |_______Ecal (empty) | |_______Hcal (empty) | |_______Muon (empty) | |______Trigger/ (empty)
>
>
Juan Palacios 1.0 <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"/>

 
Changed:
<
<
For more details on how to write conditions in XmlConditions, see the XmlConditions wiki or contact Juan directly.
>
>
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
 

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

Using misalignments in sub-detector descriptions

Changed:
<
<
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:
>
>
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:
 
  • 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.
Changed:
<
<
  • 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.
>
>
  • The IGeometryInfo in the detector element must have a path pointing to an AlignmentCondition in the data service. In practice, this is achieved through a correct XML definition of the detector element, as shown in the DELPHI example above.
  • The caching of geometrical information that might depend on the dynamic geometry 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.
 
Changed:
<
<
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.
>
>
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.
 

Status (LHCb v18r8 or higher)

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.

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

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

Revision 232007-10-01 - JuanPalacios

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"
Line: 129 to 129
 - JuanPalacios - 29 Jul 2005

Presentations

Added:
>
>
 

Revision 222006-09-27 - JuanPalacios

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"
Line: 129 to 129
 - JuanPalacios - 29 Jul 2005

Presentations

Added:
>
>
 
Line: 146 to 148
 
Added:
>
>
 
META FILEATTACHMENT attr="h" autoattached="1" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689088" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" autoattached="1" comment="" date="1125067676" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
Added:
>
>
META FILEATTACHMENT attr="" autoattached="1" comment="LHC Alignment Workshop, Aug 2006: LHCb Detector Description" date="1159314476" name="LHCb_Palacios_v1.1.pdf" path="LHCb_Palacios_v1.1.pdf" size="940620" user="Main.JuanPalacios" version="1"
 
META FILEATTACHMENT attr="h" autoattached="1" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="LHCb SW week, 25-May-2005" date="1121682080" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"

Revision 212006-08-23 - 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 here. The use case can be summarised as follows:
>
>
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.
Line: 129 to 129
 - JuanPalacios - 29 Jul 2005

Presentations

Added:
>
>
 
Changed:
<
<
>
>
-- JuanPalacios - 23 Aug 2006
 

Post your questions


-- JuanPalacios - 10 Oct 2005
Line: 145 to 146
 
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689087" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="Orsay tracking workshop, 19-May-2005" date="1121689218" name="Orsay_19-05-2005.pdf" path="Orsay_19-05-2005.pdf" size="388859" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1125067675" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1128959261" name="detElem.txt" path="detElem.txt" size="392" user="jpalac" version="1.1"
>
>
META FILEATTACHMENT attr="h" autoattached="1" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689088" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" autoattached="1" comment="" date="1125067676" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
META FILEATTACHMENT attr="h" autoattached="1" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="LHCb SW week, 25-May-2005" date="1121682080" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="Orsay tracking workshop, 19-May-2005" date="1121689219" name="Orsay_19-05-2005.pdf" path="Orsay_19-05-2005.pdf" size="388859" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" autoattached="1" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" autoattached="1" comment="" date="1128959261" name="detElem.txt" path="detElem.txt" size="392" user="jpalac" version="1.1"
 
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 202005-11-17 - unknown

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

New Det/XmlConditions package

Changed:
<
<
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. In the next few days the structure will be finalised. The last iteration of the structure, Det/XmlConditions v1r2, looks like this:
>
>
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:
 
/dd/Conditions/
Line: 54 to 54
  | |_______Ecal (single cond.) | |_______Hcal (single cond.) | |_______Muon (readout conditions)
Added:
>
>
| |___Grid (flat catalogue)
  | |___Cabling | |_____M1 (flat catalogue) | |_____M2 ( " " )
Line: 75 to 76
  |______Trigger/ (empty)
Changed:
<
<
In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.
>
>
For more details on how to write conditions in XmlConditions, see the XmlConditions wiki or contact Juan directly.
 

Accessing the information

Revision 192005-11-07 - unknown

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

New Det/XmlConditions package

Changed:
<
<
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. In the next few days the structure will be finalised. The last iteration of the structure looks like this:
>
>
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. In the next few days the structure will be finalised. The last iteration of the structure, Det/XmlConditions v1r2, looks like this:
 
/dd/Conditions/

Revision 182005-11-03 - unknown

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

Status (LHCb v18r8 or higher)

Current functionality

Changed:
<
<
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 [[LHCb.CondDBGettingStarted][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.
>
>
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?
Line: 105 to 105
 

General

  • Set an environment that uses LHCb v18r8 or higher
Changed:
<
<
    • LHCbEnv v18r8 (or GaussEnv v20r1, BooleEnv v9r4, EulerEnv v1r3, MooreEnv v1r2, BrunelEnv v27r4, DaVinciEnv v14r4)
  • getpack Det/XmlConditions v1r0p1 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 v26r1 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions v1r0p1 Det -no_auto_imports" after the "use XmlDDDB" line in the requirements file of your application.
>
>
    • 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"
Changed:
<
<
  • Go to Det/XmlConditions/v1r0p1/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.
>
>
  • 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.

Changed:
<
<
  • Set the environment: GaussEnv v20r1
>
>
  • 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:

Revision 162005-10-12 - unknown

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

New Det/XmlConditions package

Changed:
<
<
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 catalogues for alignment, readout and environmental conditions for a small set of subdetectors. In the next few days a more general structure will be defined and implemented. In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.
>
>
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. In the next few days the structure will be finalised. The last iteration of the structure looks like this:

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

In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.

 

Accessing the information

Revision 152005-10-11 - unknown

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"
Line: 42 to 42
  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.
Changed:
<
<
  • 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 beautiful 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 UpdateManager. 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 DetectorElement base class, but specialized, derived classes should take care to implement it correctly. For an example look at the DetectorElement class source code.
>
>
  • 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

Changed:
<
<
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.
>
>
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 [[LHCb.CondDBGettingStarted][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?

Revision 142005-10-10 - unknown

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

New Det/XmlConditions package

Changed:
<
<
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 catalogues for alignment, readout and environmental conditions for a small set of subdetectors. In the next few days a more general structure will be defined and implemented. In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.
>
>
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 catalogues for alignment, readout and environmental conditions for a small set of subdetectors. In the next few days a more general structure will be defined and implemented. In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.
 

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.

Added:
>
>

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 beautiful 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 UpdateManager. 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 DetectorElement base class, but specialized, derived classes should take care to implement it correctly. For an example look at the DetectorElement 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

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

Changed:
<
<

Getting started with the VELO

>
>

Working example: the VELO

 

General

  • Set an environment that uses LHCb v18r8 or higher
Line: 68 to 80
 
  • 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
Added:
>
>

 - JuanPalacios - 29 Jul 2005

Presentations

Line: 77 to 90
 
Deleted:
<
<

Using misalignments in sub-detector desctiptions

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 a weak constraint on the XML detector description. Let's recap on the necessary conditions for using the framweork:

  • 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 help 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 beautiful 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 UpdateManager. 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 DetectorElement base class, but specialized, derived classes should take care to implement it correctly. For an example look at the DetectorElement 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.

 
Deleted:
<
<

 

Post your questions


-- JuanPalacios - 10 Oct 2005
Line: 95 to 98
 
Changed:
<
<
>
>
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
Line: 105 to 108
 
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1125067675" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1128937603" name="detelem.txt" path="detelem.txt" size="382" user="jpalac" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="" date="1128959261" name="detElem.txt" path="detElem.txt" size="392" user="jpalac" version="1.1"
 
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 132005-10-10 - unknown

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

Using misalignments in sub-detector desctiptions

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 a weak constraint on the XML detector description. Let's recap on the necessary conditions for using the framweork:

Changed:
<
<
  • The structure hierarchy should be such that there is a detector element associated to the smallest possible element that needs to have misalignment information. 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 help by the base class, which is constructed when a default detector element is defined in the XMLDDDB description. It is possible to deviate from this through the use of a custom-made detector element. In this way, it would be possible for a single detector element to have the alignment information for many volumes within it. This detector element would then be in charge of assigning the information to each of its daughters. This approach is not straightforward and requires a large commitment from the subsystem software experts.
  • 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 beautiful past detector. In the case where a custom-made detector element is being used to assign misalignments to its daughters, many paths can be given to a single detector element by declaring them as "conditions", this time outside the geometryinfo field.
>
>
  • 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 help 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 beautiful 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.
Changed:
<
<
  • 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 UpdateManager. This step requires careful attention and thought from the subsystem experts, as there is no automatic recipe to apply it.
>
>
  • 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 UpdateManager. 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 DetectorElement base class, but specialized, derived classes should take care to implement it correctly. For an example look at the DetectorElement 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.

Revision 122005-10-10 - unknown

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

New 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.

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

New 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 catalogues for alignment, readout and environmental conditions for a small set of subdetectors. In the next few days a more general structure will be defined and implemented. In the mean time subsystems wanting to implement new conditions catalogues are requested to contact Juan.

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.

 

Status (LHCb v18r8 or higher)

Current functionality

Line: 64 to 77
 
Added:
>
>

Using misalignments in sub-detector desctiptions

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 a weak constraint on the XML detector description. Let's recap on the necessary conditions for using the framweork:

  • The structure hierarchy should be such that there is a detector element associated to the smallest possible element that needs to have misalignment information. 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 help by the base class, which is constructed when a default detector element is defined in the XMLDDDB description. It is possible to deviate from this through the use of a custom-made detector element. In this way, it would be possible for a single detector element to have the alignment information for many volumes within it. This detector element would then be in charge of assigning the information to each of its daughters. This approach is not straightforward and requires a large commitment from the subsystem software experts.
  • 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 beautiful past detector. In the case where a custom-made detector element is being used to assign misalignments to its daughters, many paths can be given to a single detector element by declaring them as "conditions", this time outside the geometryinfo field.
  • 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 UpdateManager. This step requires careful attention and thought from the subsystem experts, as there is no automatic recipe to apply it.

This is all that's needed in order to incorporate the alignment framework functionality into the detector description of any given subsystem.


 

Post your questions


Changed:
<
<
-- JuanPalacios - 04 Aug 2005
>
>
-- JuanPalacios - 10 Oct 2005
 

Added:
>
>
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689087" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
Line: 79 to 105
 
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1125067675" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
Added:
>
>
META FILEATTACHMENT attr="h" comment="" date="1128937603" name="detelem.txt" path="detelem.txt" size="382" user="jpalac" version="1.1"
 
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 112005-08-26 - unknown

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: AlignmentCondition is a very simple class which contains six alignment parameters and a transformation matrix. The parameters describe translations and rotations with respect to the Cartesian axes, in the local reference frame of the parent detector element. 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 parameters, or to update the transformation matrix by changing the values of the parameters.
>
>
  • New 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.
 
  • New 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.
Line: 69 to 69
 -- JuanPalacios - 04 Aug 2005
Added:
>
>
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689087" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
Line: 76 to 78
 
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1123170815" name="cond.txt" path="cond.txt" size="219" user="jpalac" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="" date="1125067675" name="cond.txt" path="cond.txt" size="299" user="jpalac" version="1.2"
 
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 102005-08-04 - unknown

Line: 1 to 1
 
META TOPICPARENT name="Main.JuanPalaciosLHCbWork"
Line: 17 to 17
 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:
  • New AlignmentCondition class: AlignmentCondition is a very simple class which contains six alignment parameters and a transformation matrix. The parameters describe translations and rotations with respect to the Cartesian axes, in the local reference frame of the parent detector element. 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 parameters, or to update the transformation matrix by changing the values of the parameters.
  • New 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.
Changed:
<
<
  • 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:
>
>
  • 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.
Line: 41 to 41
 
  • Make sure your application uses Det/XmlDDDB v26r1 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions v1r0p1 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"
Changed:
<
<
  • Go to Det/XmlConditions/v1r0p1/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 - 29 Jul 2005
>
>
  • Go to Det/XmlConditions/v1r0p1/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.

Line: 66 to 66
 

Post your questions


Changed:
<
<
-- JuanPalacios - 20 Jul 2005
>
>
-- JuanPalacios - 04 Aug 2005
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
Line: 74 to 75
 
META FILEATTACHMENT attr="h" comment="Orsay tracking workshop, 19-May-2005" date="1121689218" name="Orsay_19-05-2005.pdf" path="Orsay_19-05-2005.pdf" size="388859" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="h" comment="" date="1123170249" name="alignment.xml" path="alignment.xml" size="30623" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="" date="1123170815" name="cond.txt" path="cond.txt" size="219" user="jpalac" version="1.1"
 
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 92005-07-29 - unknown

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

General

  • Set an environment that uses LHCb v18r8 or higher
Changed:
<
<
    • LHCbEnv v18r8 (or BooleEnv v9r4, EulerEnv v1r3, MooreEnv v1r2, BrunelEnv v27r4, DaVinciEnv v14r4)
    • setenv Gauss_release_area $LHCBDEV
>
>
    • LHCbEnv v18r8 (or GaussEnv v20r1, BooleEnv v9r4, EulerEnv v1r3, MooreEnv v1r2, BrunelEnv v27r4, DaVinciEnv v14r4)
 
  • getpack Det/XmlConditions v1r0p1 or higher. XmlConditions has a dummy catalogue of AlignmentConditions that can be edited by hand in order to create misalignments.
Changed:
<
<
  • Make sure your application uses Det/XmlDDDB v26r0 or higher. If not, modify the requirements accordingly.
>
>
  • Make sure your application uses Det/XmlDDDB v26r1 or higher. If not, modify the requirements accordingly.
 
  • Add "use XmlConditions v1r0p1 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/v1r0p1/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.
Changed:
<
<
- JuanPalacios - 26 Jul 2005
>
>
- JuanPalacios - 29 Jul 2005
 

Simulating misalignments

Changed:
<
<
To simulate misalignments at the moment GaussEnv v20r1 in needed. This uses LHCb v18r8 but is in the DEV area.
  • Set the environment: GaussEnv v20r0
>
>
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
 
  • Get the Det/XmlConditions package as described above
Changed:
<
<
  • From your CMT build directory: getpack Det/XmlDDDB v26r1 (unless using DEV area)
  • From your CMT build directory: getpack Sim/Gauss v20r0
  • modify Sim/Gauss/v20r0/options/SimGeometry.opts:
>
>
  • 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
Changed:
<
<
- JuanPalacios - 26 Jul 2005
>
>
- JuanPalacios - 29 Jul 2005
 

Presentations

Revision 82005-07-26 - unknown

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

Implementation in a nutshell

Changed:
<
<
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 will be available from LHCb release v18r8. With LHCb v18r7 it is possible to initialise the detector with deviations from the ideal, but it does not yet allow to change the alignment parameters on the fly. Here are a few key points in getting this functionality to work:
>
>
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:
 
  • New AlignmentCondition class: AlignmentCondition is a very simple class which contains six alignment parameters and a transformation matrix. The parameters describe translations and rotations with respect to the Cartesian axes, in the local reference frame of the parent detector element. 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 parameters, or to update the transformation matrix by changing the values of the parameters.
  • New 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:
Line: 34 to 34
 

Getting started with the VELO

General

Changed:
<
<
  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run. If misaligning detectors once at initialisation is enough, then LHCb v18r7 (released) compatible applications can be used.
  • Set the DEV environment
    • setenv HCb_release_area $LHCBDEV
>
>
  • Set an environment that uses LHCb v18r8 or higher
    • LHCbEnv v18r8 (or BooleEnv v9r4, EulerEnv v1r3, MooreEnv v1r2, BrunelEnv v27r4, DaVinciEnv v14r4)
 
    • setenv Gauss_release_area $LHCBDEV
Deleted:
<
<
    • If using Boole, Brunel, DaVinci, or anything built on these, setenv Lbcom_release_area to $LHCBDEV
    • setenv Boole_release_area Brunel_release_area etc., to $LHCBDEV
 
  • getpack Det/XmlConditions v1r0p1 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 v26r0 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions v1r0p1 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/v1r0p1/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.
Changed:
<
<
- JuanPalacios - 21 Jul 2005
>
>
- JuanPalacios - 26 Jul 2005
 

Simulating misalignments

Changed:
<
<
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7. However, XmlDDDB v26r1 is needed to have the full VELO material. This is at the moment only in the DEV area.
>
>
To simulate misalignments at the moment GaussEnv v20r1 in needed. This uses LHCb v18r8 but is in the DEV area.
 
  • Set the environment: GaussEnv v20r0
  • Get the Det/XmlConditions package as described above
  • From your CMT build directory: getpack Det/XmlDDDB v26r1 (unless using DEV area)
Line: 59 to 57
 
  • 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
Changed:
<
<
- JuanPalacios - 21 Jul 2005
>
>
- JuanPalacios - 26 Jul 2005
 

Presentations

Revision 72005-07-25 - unknown

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

Introduction

Line: 10 to 10
 
    • 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.
Changed:
<
<
There is new a Q&A page which is largely empty. Please feel free to post your questions there.
>
>
There is new a Q&A page which is largely empty. Please feel free to post your questions there.
 

Implementation in a nutshell

Line: 28 to 28
 

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

Changed:
<
<
  • Simulating misaligned detectors: This is not as trivial as it seems. The problem is explained here.
>
>
  • 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.

Line: 68 to 68
 
Changed:
<
<

Post your questions

>
>

Post your questions

 
-- JuanPalacios - 20 Jul 2005
Line: 78 to 78
 
META FILEATTACHMENT attr="h" comment="Orsay tracking workshop, 19-May-2005" date="1121689218" name="Orsay_19-05-2005.pdf" path="Orsay_19-05-2005.pdf" size="388859" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
Changed:
<
<
META TOPICMOVED by="jpalac" date="1121687354" from="Main.GeometryFramework" to="Main.LHCbGeometryFramework"
>
>
META TOPICMOVED by="jpalac" date="1122302805" from="Main.LHCbGeometryFramework" to="LHCb.GeometryFramework"

Revision 62005-07-21 - unknown

Line: 1 to 1
 
META TOPICPARENT name="JuanPalaciosLHCbWork"
Line: 35 to 35
 

Getting started with the VELO

General

  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run. If misaligning detectors once at initialisation is enough, then LHCb v18r7 (released) compatible applications can be used.
Added:
>
>
  • Set the DEV environment
    • setenv HCb_release_area $LHCBDEV
    • setenv Gauss_release_area $LHCBDEV
    • If using Boole, Brunel, DaVinci, or anything built on these, setenv Lbcom_release_area to $LHCBDEV
    • setenv Boole_release_area Brunel_release_area etc., to $LHCBDEV
 
  • getpack Det/XmlConditions v1r0p1 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 v26r0 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions v1r0p1 Det -no_auto_imports" after the "use XmlDDDB" line in the requirements file of your application.
Line: 43 to 48
 - JuanPalacios - 21 Jul 2005

Simulating misalignments

Changed:
<
<
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7. However, XmlDDDB v26r1 is needed to have the full VELO material.
>
>
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7. However, XmlDDDB v26r1 is needed to have the full VELO material. This is at the moment only in the DEV area.
 
  • Set the environment: GaussEnv v20r0
  • Get the Det/XmlConditions package as described above
Changed:
<
<
  • From your CMT build directory: getpack Det/XmlDDDB v26r1
>
>
  • From your CMT build directory: getpack Det/XmlDDDB v26r1 (unless using DEV area)
 
  • From your CMT build directory: getpack Sim/Gauss v20r0
  • modify Sim/Gauss/v20r0/options/SimGeometry.opts:
    • comment out Geo.StreamItems += {"/dd/Structure/LHCb/Velo"};

Revision 52005-07-21 - unknown

Line: 1 to 1
 
META TOPICPARENT name="JuanPalaciosLHCbWork"
Line: 37 to 37
 
  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run. If misaligning detectors once at initialisation is enough, then LHCb v18r7 (released) compatible applications can be used.
  • getpack Det/XmlConditions v1r0p1 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 v26r0 or higher. If not, modify the requirements accordingly.
Changed:
<
<
  • Add "use XmlConditions 1r0p1 Det -no_auto_imports" after the "use XmlDDDB" line in the requirements file of your application.
>
>
  • Add "use XmlConditions v1r0p1 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/v1r0p1/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.
Changed:
<
<
>
>
- JuanPalacios - 21 Jul 2005
 

Simulating misalignments

Changed:
<
<
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7.
>
>
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7. However, XmlDDDB v26r1 is needed to have the full VELO material.
 
  • Set the environment: GaussEnv v20r0
Added:
>
>
  • Get the Det/XmlConditions package as described above
  • From your CMT build directory: getpack Det/XmlDDDB v26r1
 
  • From your CMT build directory: getpack Sim/Gauss v20r0
  • modify Sim/Gauss/v20r0/options/SimGeometry.opts:
    • comment out Geo.StreamItems += {"/dd/Structure/LHCb/Velo"};
    • uncomment #include "$GAUSSOPTS/SimVeloGeometry.opts"
Added:
>
>
  • 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
Added:
>
>
- JuanPalacios - 21 Jul 2005
 

Presentations

Revision 42005-07-20 - unknown

Line: 1 to 1
 
META TOPICPARENT name="JuanPalaciosLHCbWork"
Line: 34 to 34
 

Getting started with the VELO

General

Changed:
<
<
  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run.
>
>
  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run. If misaligning detectors once at initialisation is enough, then LHCb v18r7 (released) compatible applications can be used.
 
  • getpack Det/XmlConditions v1r0p1 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 v26r0 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions 1r0p1 Det -no_auto_imports" after the "use XmlDDDB" line in the requirements file of your application.
Line: 42 to 42
 
  • Go to Det/XmlConditions/v1r0p1/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.

Simulating misalignments

Changed:
<
<
  • Link to the DEV area
    • setenv LHCb_release_area $LHCBDEV
    • setenv Gauss_release_area $LHCBDEV
  • Set the environment: GaussEnv (pick v20r0 or higher)
  • From your CMT build directory: getpack Sim/Gauss head
>
>
To simulate misalignments the functionality in the latest release of LHCb (v18r7) is enough, as the misalignments do not have to be updated in the course of a job. Gauss v20r0 has been recently released and uses LHCb v18r7.
  • Set the environment: GaussEnv v20r0
  • From your CMT build directory: getpack Sim/Gauss v20r0
 
  • modify Sim/Gauss/v20r0/options/SimGeometry.opts:
    • comment out Geo.StreamItems += {"/dd/Structure/LHCb/Velo"};
    • uncomment #include "$GAUSSOPTS/SimVeloGeometry.opts"
Line: 62 to 61
 

Post your questions


Changed:
<
<
-- JuanPalacios - 19 Jul 2005
>
>
-- JuanPalacios - 20 Jul 2005
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"

Revision 32005-07-19 - unknown

Line: 1 to 1
 
META TOPICPARENT name="JuanPalaciosLHCbWork"
Line: 10 to 10
 
    • 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.
Changed:
<
<
>
>
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 will be available from LHCb release v18r8. With LHCb v18r7 it is possible to initialise the detector with deviations from the ideal, but it does not yet allow to change the alignment parameters on the fly. Here are a few key points in getting this functionality to work:

Line: 22 to 23
 
    • 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.
  • 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.
Added:
>
>

 

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

 

Getting started with the VELO

General

  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run.
Line: 49 to 52
 
    • uncomment #include "$GAUSSOPTS/SimVeloGeometry.opts"
  • 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
Added:
>
>

 

Presentations

Changed:
<
<
-- JuanPalacios - 18 Jul 2005
>
>

Post your questions


-- JuanPalacios - 19 Jul 2005
 
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"

Revision 22005-07-18 - unknown

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="LHCbWork"
>
>
META TOPICPARENT name="JuanPalaciosLHCbWork"
 

Introduction

Added:
>
>
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 here. 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.

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 will be available from LHCb release v18r8. With LHCb v18r7 it is possible to initialise the detector with deviations from the ideal, but it does not yet allow to change the alignment parameters on the fly. Here are a few key points in getting this functionality to work:

  • New AlignmentCondition class: AlignmentCondition is a very simple class which contains six alignment parameters and a transformation matrix. The parameters describe translations and rotations with respect to the Cartesian axes, in the local reference frame of the parent detector element. 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 parameters, or to update the transformation matrix by changing the values of the parameters.
  • New 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.
  • 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.

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.

Getting started with the VELO

General

  • To use the full functionality, LHCb v18r8 or higher should be used. This is in the DEV area at the moment and is accessible by setting LHCb_release_area to $LHCBDEV. Do similarly with Gauss_release_area, Boole_release_area, Brunel_release_area, etc. depending on the application you want to run.
  • getpack Det/XmlConditions v1r0p1 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 v26r0 or higher. If not, modify the requirements accordingly.
  • Add "use XmlConditions 1r0p1 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/v1r0p1/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.

Simulating misalignments

  • Link to the DEV area
    • setenv LHCb_release_area $LHCBDEV
    • setenv Gauss_release_area $LHCBDEV
  • Set the environment: GaussEnv (pick v20r0 or higher)
  • From your CMT build directory: getpack Sim/Gauss head
  • modify Sim/Gauss/v20r0/options/SimGeometry.opts:
    • comment out Geo.StreamItems += {"/dd/Structure/LHCb/Velo"};
    • uncomment #include "$GAUSSOPTS/SimVeloGeometry.opts"
  • 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
 

Presentations

Changed:
<
<
>
>
 
Added:
>
>
 
Changed:
<
<
- JuanPalacios - 18 Jul 2005
>
>
-- JuanPalacios - 18 Jul 2005
 
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="LHCb T-Rec meeting, 09-May-2005" date="1121689087" name="AlignmentStatus9-05-2005.pdf" path="AlignmentStatus9-05-2005.pdf" size="82122" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="Orsay tracking workshop, 19-May-2005" date="1121689218" name="Orsay_19-05-2005.pdf" path="Orsay_19-05-2005.pdf" size="388859" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706174" name="Alignment25-04-2005.ppt" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.ppt" size="131584" user="jpalac" version="1.1"
META FILEATTACHMENT attr="h" comment="First talk to core SW group. Outlines problem, possible solutions." date="1121706354" name="Alignment25-04-2005.pdf" path="G:\Users\p\palacios\Public\Talks\Alignment Framework\Alignment25-04-2005.pdf" size="96382" user="jpalac" version="1.1"
META TOPICMOVED by="jpalac" date="1121687354" from="Main.GeometryFramework" to="Main.LHCbGeometryFramework"

Revision 12005-07-18 - unknown

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="LHCbWork"

Introduction

Presentations

- JuanPalacios - 18 Jul 2005

META FILEATTACHMENT attr="" comment="" date="1121681713" name="veloChanges.pdf" path="veloChanges.pdf" size="46993" user="jpalac" version="1.1"
META FILEATTACHMENT attr="" comment="LHCb SW week, 25-May-2005" date="1121682079" name="AlignmentFrameworkStatus2.pdf" path="AlignmentFrameworkStatus2.pdf" size="459768" user="jpalac" version="1.1"
 
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