Adding misalignment of pixel sectors to the geometry
Updated on Thu, 2015-11-05 12:26. Originally created by jwebb on 2015-10-23 16:52.
11/05/2015
c++ side:
Implemented AgTransform class to handle the general matrix transformation case. Supports defining the full translation/rotation matrix by
1) Direct specification of the matrix elements
2) Rotations about the x, y and/or z axes
3) Specification of the polar and azimuthal angles of the x, y and z axes relative to the mother reference system (G3 style).
4) Translation along x, y or z.
Unit test constructed and items 1, 2 and 4 verified correct. Item 3 in process.
fortran side:
To be defined
agml syntax:
Current syntax defines the placement of a volume with respect to its mother volume as a single translation and one or more rotations. Rotations are evaluated before the translation is evaluated (AgSTAR convention).
Currently, the AgML class which handles placement -- AgPlacement -- is not very extendable. So...
Lift common functionality to one or more base classes
Management of an std::map<string, double> is replicated many times in StarAgmlLib. Functionality is moved to AgParameterList.
AgTransform class should assume the repsonsabilities for executing translations / rotations.
Test test test -- quickest way is to export geometries to a CINT file, strip out any pattern which looks like "_(pointer to object)", and do a diff on the files.
Figure 1 -- First quick and dirty test
Some addition notes:
AgML / AgSTAR position syntax looks like the following:
In the event that the two styles of roation are mixed, the order of rotations will be preserved. But the translation still occurs at the end.
This behavior is a limitation which does not exist in ROOT. One can take a general rotation/translation matrix and perform multiple transformations, and the order will be preserved.
We must handle the general case. To illustrate this, consider the pixel detector. Mechanically it is divided into two halves, with 5 sectors per half. Each half is rotated / translated independently (with some constraints). The sector alignments are with respect to each half. The geant model does not implement a "half" volume. So we must handle the translation / rotation of each half and *then* apply the sector-by-sector translation / rotations.
11/05/2015
c++ side:
Implemented AgTransform class to handle the general matrix transformation case. Supports defining the full translation/rotation matrix by
1) Direct specification of the matrix elements
2) Rotations about the x, y and/or z axes
3) Specification of the polar and azimuthal angles of the x, y and z axes relative to the mother reference system (G3 style).
4) Translation along x, y or z.
Unit test constructed and items 1, 2 and 4 verified correct. Item 3 in process.
fortran side:
To be defined
agml syntax:
Current syntax defines the placement of a volume with respect to its mother volume as a single translation and one or more rotations. Rotations are evaluated before the translation is evaluated (AgSTAR convention).
PLACEMENT VOLU in MOTH x=x0 y=y0 z=z0 alphaz=15 alphax=5 alphay=-5New syntax will need to generalize this
PLACEMENT VOLU in MOTH { """ Placement by rotations and translation """
Translate x=x0
Translate y=y0
Rotate alphax=+15
Rotate alphay=-15
Translate z=zprime
}
PLACEMENT VOLU in MOTH { """ Placement by rotations and translation, followed by a *mis*alignment specified by DB """
Translate x=x0
Translate y=y0
Rotate alphax=+15
Rotate alphay=-15
Translate z=zprime
Misalign table="Calibrations/Detector/Table"
}
PLACEMENT VOLU in MOTH { """ Placement by rotations and translation, with alternate placement by DB table
Translate x=x0
Translate y=y0
Rotate alphax=+15
Rotate alphay=-15
Translate z=zprime
Alternate table="Calibrations/Detector/Table"
}
Currently, the AgML class which handles placement -- AgPlacement -- is not very extendable. So...
Lift common functionality to one or more base classes
Management of an std::map<string, double> is replicated many times in StarAgmlLib. Functionality is moved to AgParameterList.
AgTransform class should assume the repsonsabilities for executing translations / rotations.
Reduce the responsabilties of AgPlacement
AgPlacement class should be responsible for evaluating the placement commands from the language.
Test test test -- quickest way is to export geometries to a CINT file, strip out any pattern which looks like "_(pointer to object)", and do a diff on the files.
Figure 1 -- First quick and dirty test
Some addition notes:
AgML / AgSTAR position syntax looks like the following:
POSITION VOLU in MOTH x=x0 y=y0 z=z0 alphaz=15 alphax=5 alphay=-5
Applies rotations about the z axis, x axis and y axis in the specified order. Performs a translation of the rotated object to the specified position. Order of translation and rotation is not preserved, i.e.the translation will always be applied last.
POSITION VOLU in MOTH x=x0 y=y0 z=z0 thetax=tx phix=px thetay=ty phiy=py thetaz=tz phiz=pz
Rotates the x, y and z axes relative to the axes in the mother volume according to the specified angles. Will throw an error if orthonormality is violated. Then translates the rotated volume to the specified position. Again, order of rotation and translation is not preserved.
In the event that the two styles of roation are mixed, the order of rotations will be preserved. But the translation still occurs at the end.
This behavior is a limitation which does not exist in ROOT. One can take a general rotation/translation matrix and perform multiple transformations, and the order will be preserved.
We must handle the general case. To illustrate this, consider the pixel detector. Mechanically it is divided into two halves, with 5 sectors per half. Each half is rotated / translated independently (with some constraints). The sector alignments are with respect to each half. The geant model does not implement a "half" volume. So we must handle the translation / rotation of each half and *then* apply the sector-by-sector translation / rotations.
»
- jwebb's blog
- Login or register to post comments