| EMC Geometry handling. [message #9775] |
Tue, 24 November 2009 17:02  |
Aleksandra Biegun
Messages: 64
Registered: May 2007
Location: Groningen
|
continuous participant |
From: *KVI.nl
|
|
Dear All,
Elwin Dijck (from KVI) made some changes
concerning the crystal geometry (shape)
in ../trunk/emc/EmcTools/
PndEmcStructure.cxx
PndEmcXtal.cxx
PndEmcXtal.h
It was submitted with the rev. 7071.
More information will be provided by Elwin.
Best regards,
Ola.
Aleksandra Biegun
University of Groningen/KVI
Zernikelaan 25, 9747 AA Groningen
tel. +31 50 363 3630
fax. +31 50 363 4003
|
|
|
|
| Re: EMC Geometry handling. [message #9776 is a reply to message #9775] |
Tue, 24 November 2009 17:39  |
Elwin Dijck
Messages: 16
Registered: June 2009
Location: Groningen, The Netherland...
|
occasional visitor |
From: *KVI.nl
|
|
Dear all,
I proposed a few changes in the geometry handling in the EMC classes to fix some problems I ran into. This does not change the geometry used in simulation at all, but relates to the PndEmcXtal class. There are several changes so it's a bit of a long read I'm afraid.
- In the PndEmcXtal class I changed the code in the constructor to check the actual orientation of the crystals instead of just the module number when determining which end of the crystal is the front side. It seems that the orientation of the crystals in module 3 changed between the original .dat geometry and the .root geometry, so using the module number is not really robust and gave wrong results for the new forward endcap.
- In addition, I changed the calculation of the center of the front face to take the skewing of TGeoTraps into account. The difference with the old calculation is minimal however.
- In the constructor of PndEmcStructure, the PndEmcXtal classes are created from the loaded geometry. Because different geometry files of the EMC use different geometry classes (TGeoTrap, TGeoBBox), there was a check of the module number here to do the correct conversion. When trying to use some information of the crystals I found out that the new geometry of the forward endcap (emc_module3new.root) contains TGeoArb8 crystal geometry instead of TGeoTrap, although I don't know why. In any case, the geometry pointers from emc_module3new.root were cast to TGeoTrap* and this worked because only the Dz value was used, but it is not a valid cast and might give undefined results.
- I changed the code to check the actual type of the geometry and, if needed, convert TGeoBBoxs or TGeoArb8s into TGeoTraps for the PndEmcXtal class. For this I added code that converts a TGeoArb8 into a TGeoTrap that should be pretty close. It might be nicer to place the conversion code in a separate function, but it works as it is.
- Finally I added two functions to PndEmcXtal to access the geometry and the rotation matrix, which I wanted to use in a macro. The TGeoTrap geometry was anyway stored already, but not accessable. The rotation matrix was not stored so I added that. Whether or not this is useful in general I don't know.
These changes assume that using TGeoTraps in the PndEmcXtal class is preferred over TGeoArb8. I tried to make the code a little more robust to remove/prevent issues with the different MapperVersions and geometry files. Anyway these were my thoughts on the matter, perhaps there are better solutions to these issues.
Best regards,
Elwin Dijck
[Updated on: Tue, 24 November 2009 17:41] Report message to a moderator |
|
|
|
GSI Forum
Search
Help
Members
Login
Home
