Hi, Pasha.
Did you see:
http://root.cern.ch/root/htmldoc/TVolumeView.html#TVolumeView:Local2Master
> I've been trying to solve a pretty simple problem of
> how to define a subdetector, rotated wrt the global coordinate
> system and to transform components of a 3-vector (track momentum)
> into the local system of this subdetector. This Christmas exersize
> turned out to be couple of orders of magnitude more difficult than I
> expected, and here are the reasons:
> - an illustrated way of describing the detector geometry suggests
> using TRotMatrices to describe the rotations of coordinate systems.
> However the only way to rotate a TVector3 using a TRotMatrix
> goes through convertion of a TRotMatrix into array of doubles and
> then coding of multiplication formulae by hands
This is why TCL class http://root.cern.ch/root/htmldoc/TCL.html
was introduced. We did not want "coding of multiplication
formulae by hands"
See for example:
http://root.cern.ch/root/htmldoc/src/TVolumePosition.cxx.html
The coordinate transformation there done with 3 lines of C++ code:
for (int i =0; i < nPoints; i++, local += 3, master += 3) {
TCL::mxmpy(matrix,local,master,3,3,1);
TCL::vadd(master,fX,master,3);
}
Class TVolumePosition.cxx does contain (TRotMatrix *).
One can use TArrayD or STL vector<double>.
> - alternatively one can rotate a TVector3 using a TRotation, but
> initialization-wise
Hmm, it seems to me the rotation ( I mean generating the 3 x 3 matrix)
can be done at once by some extra "helper" classes. The class like
TVolumePositions is not to change this matrix. Therefore I see no
strong need providing the "rotation" method for class TVolumePosition
itself.
> the latter class seems to be almost self-encapsulated - I didn't find
> an easy and intuitive way to initialise a TRotation object starting
> from either 6 angles (GEANT3 way), or 9 direction cosines (regular math
> approach) - any help would be greatly appreciated.
> - one more comment about TRotMatrix: it is 9 doubles plus 2 strings
> (name ant title), which make the object substantially more heavy.
> In case of complicated geometry, when one needs to define many
> rotation matrices this also leads to significant amount of waisted
> memory. I'm wondering if there is a real need for a rotation matrix
> to be named - to identify it uniquely it seems to be quite enough
> to give a TRotMatrix an integer ID... I also failed to find a use
> case of a TRotMatrix which needs a title...
This is true but not too hard. For example to define the full ATLAS
geometry one needs about 2000 matrices. This means the overhead is about
4000 "strings", If they are about 10 bytes we are arriving at 40 Kbytes
overhead. it is large but doesn't sound huge enough to be the first
priority target.
>
> Anyway, I ended up with deriving my own class from TRotation, but I believe,
> we can do much better than that. My favorite solution would be to have an
> "anonymous" (nameless and title-less) TRotMatrix with defined operations
> on the 3-vectors, but I'm not sure about all the
> implications, for example, if there are people building geometries of their
> detectors and relying on the rotation matrices being named etc.
> Any other proposals?
If the "transformation" member of the class TVolumePosition is a simple
class to keep the "plain" 3x3 array of doubles (like TRotMatrix) then
everybody is free to choose any method initiating this array.
I would vote to make this member simpler (by removing names from
that class for example).
Did you try to build your geometry with TVolume class rather TNode ?
> Merry Christmas to everybody, Pasha
Happy New Year,
Valeri
>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:40 MET