Geant 'MANY' vs 'ONLY'
The silicon endcaps are built up out of 24 identical wedges.
This is a cross section of a piece of this shade. The cut plane is perpendicular to the beam axis, so the coordinates appear stretched. (Command: next; satt sips seen 0; dcut si09 3 0 18 5 2 2 )

What you see is the black support panels, red standoffs on both sides, small black readout chips, and on top of that the pink silicon. The is repeated 24 times around, to build a full shade.

Clearly, the way to build this structure is to make one volume that contains all the little pieces, and place this 24 times around.



The mother volumes that contain the little pieces are shown in black, and they necessarily overlap. (These are SIPS, SIPM, SIPB) These must therefore be declared 'MANY' when you place them with GSPOS.

In GEANT this causes problems, because it needs to search up the geometry tree until it encounters a unique ('ONLY') volume, and then go down again and check volumes lower down for the overlap.

In order to minimize this searching, I place these overlapping pie pieces in a cone-shaped enclosure (light blue in the picture), which is unique. This minimizes the searching. Before, the pie pieces were placed directly in the SVX master volume, which would lead to an enormous amount of searching.



In this figure part of the Geant tree of volumes is shown. The light blue endcap cones correspond to volumes SI05-SI12. The GEANT searches through the tree due to 'MANY' declaration of volumes SIPB, SIPM, SIPS is limited to the purple box. Without encapsulation of the 'MANY' volumes in this way, GEANT would have to search a much larger portion of the volume tree (red box).


In the source code you can declare the volumes 'ONLY' or 'MANY'. Of course there probably are internal problems when you declare overlapping volumes 'ONLY', but I ignore these here. Here are some run times in seconds:
  100 200 1000 tracks time per track
'ONLY' 0.68 0.92 3.58 3.22 ms
'MANY' 0.72 1.02 3.97 3.61 ms

It appears that properly declaring SIPS, SIPM and SIPB as 'MANY' increases the SVX time by 0.4 ms/track or about 12%. Not too much.

Last update 13 Sep 2005 - HvH
back