Setting alignment properties
Since geometries described with GeoModel
typically aim to represent a detector which will (or might be) physically constructed in future, it is important to be able to model issues which commonly face detectors once constructed. A significant issue for many detectors is that contruction tolerances and/or effects due to changing temperature, magnetic fields, etc, can result in measurable differences between the real and expected positions of detector elements.
While these effects can be explicitly modeled in the geometry if known, it is more typical to include such effects by allowing for misalignments to be applied to the geometry, which represent external corrections to be applied to the positions of volumes, having been determined by an alignment procedure (typically a minimization of certain parameters with high sensitivity to the positions of sensor elements).
Making volumes alignable¶
In GeoModelXML
, elements are made alignable through using the alignable
property. This has several functions.
- When creating a
logvol
orassembly
, this property indicates that aGeoFullPhysVol
1 should be created rather than aGeoPhysVol
2 (see GeoModelKernel for more details).
<logvol name="SingleBox" shape="BoxShape" material="Air" alignable="true"/>
- When creating a
transformation
, this property indicates that aGeoAlignableTransform
should be created rather than aGeoTransform
.
<transformation name="RotateABox" alignable="true">
<rotation zcos="1.0" angle="-PI/4"/>
</transformation>
transformations
, it is also possible to define an empty transformation
to which alignments can be applied (since the final position will be the product of all transformations
applied):
<logvol name="SingleBox" shape="BoxShape" material="Air" alignable="true"/>
<assembly name="AlignableBox">
<transform>
<transformation name="DummyTransform" alignable="true">
<translation/>
</transformation>
<logvolref ref="SingleBox"/>
</transform>
</assembly>
- The final use of
alignable
is a little different; when defining atransform
,multicopy
, orReplicaArray
, thealignable
property expects anint
rather than abool
. This is because this use ofalignable
propagates the objects which are to be made alignable toGmxInterface
, in order that they can be accessed and used externally toGeoModel
, e.g. within an experiment’s simulation or reconstruction framework. The value passed as anint
represents the alignment “level”; different levels may be treated differently as they can be defined to distinguish e.g. large, medium, and small structures which should be processed one after the other in the alignment procedures of the experiment.
Putting this all together, you should have something that looks like the following:
<logvol name="SingleBox" shape="BoxShape" material="Air" alignable="true"/>
<assembly name="AlignableBox">
<transform alignable="1">
<transformation name="RotateABox" alignable="true">
<rotation zcos="1.0" angle="-PI/4"/>
</transformation>
<logvolref ref="SingleBox"/>
</transform>
</assembly>
DEBUG
message from GmxInterface
(if the output verbosity is high enough):
GmxInterface::addAlignable called for a physvol. Logvol name [...]
Known issues¶
Currently alignment with GeoModelXML
is in a development and testing phase, and so issues are in the process of being discovered and solved. The current known issues are:
- when using
splitLevel
to split up volumes into multiple readout elements, only the first of these currently gets aGeoAlignableTransform
passed on. Since these split volumes should always be physically bound, they should not need alignment relative to each other and so can all use a singleGeoAlignableTransform
. This propagation of a commonGeoAlignableTransform
for split volumes is not yet implemented. - when defining a
multicopy
without aloopvar
,GeoAlignableTransforms
are not being properly created. Until this is fixed, it is suggested that aloopvar
is used in all cases (can be a “dummy” which simply implements the implicit behaviour) - using the same name for the
bool
andint
alignable
properties can be confusing; a newalignmentLevel
(or similar) property should be defined that can optionally be used in place of theint
version, and eventually replace it as the standard.
-
Class definition states: “This class represent a physical volume whose absolute default and aligned positions are known and held in cache.” ↩
-
Class definition states: “A GeoPhysVol is a physical volume for normal recursive access only. This means, normally, that it represents a piece of detector that nobody cares about except for tracing engines like GEANT” ↩