Difference: GeometryFramework (26 vs. 27)

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)

 
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