The GeoModel Toolkit for Detector Description Joe Boudreau Vakho Tsulaia

1. The GeoModel Toolkit for Detector Description Joe Boudreau Vakho Tsulaia University of Pittsburgh CHEP’04 Interlaken

2. Purpose of the toolkit • GeoModel toolkit – library of geometrical primitives that can be used to describe detector geometries • GeoModel is designed as data layer and optimized in order to be able to describe large and complex detector systems with minimum memory consumption • Key features of GeoModel-based detector description • Two layers of geometry description • ‘Raw’ (material) geometry • Readout geometry synchronized to raw geometry layer • Same description for all clients (Simulation, Reconstruction …) • Alignment constants propagate through software via GeoModel • Single database used as source for primary numbers • Geometry versioning system based on versioned data in primary numbers database • Automatic geometry version detection GeoModel, CHEP'04

3. Main components of the toolkit • Geometry kernel • Set of memory-optimized geometrical primitives • Set of primitives for building volume parameterizations • Physical volumes, and full physical volumes • Transformations, and alignable transformations • Base classes for unified access to readout and raw geometry • Set of actions for navigating geometry nodes and physical volumes • Volume and shape parameterizations through “symbolic geometry” • Visual debugging tools based on Open Inventor toolkit • Kernel documentation, several HowTo’s http://atlas.web.cern.ch/Atlas/GROUPS/DATABASE/detector_description GeoModel, CHEP'04

4. Design principles Design rudiments for Raw geometry description: Physical Volume Physical Volume Physical Volume Physical Volume • The atomic unit of raw geometry description is the physical volume • Its substructure is: logical volume and transformation in parents’ coordinate system • Substructure of logical volume is: shape and material • Touch a transform and the subtree is moved GeoModel, CHEP'04

5. Design principles PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV Description of a complicated detector can be assembled from descriptions of its subsystems World CALOR MUON PV PV PV PV PV PV PV SILICON GeoModel, CHEP'04

6. Design principles PV PV PV PV PV PV PV PV PV PV PV FPV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV PV • All volumes are not created equal – Full Physical Volumes cache absolute global-to-local transformation info • All transformations are not created equal – Alignable Transforms have an additional adjustment knob World CALOR MUON PV PV PV PV PV FPV PV SILICON GeoModel, CHEP'04

7. Design principles • Detector subsystems build their geometry trees independently • Readout geometry layer is synched to raw geometry and is described with the use of Detector Elements • Detector Elements have required association with a piece of material geometry (Full Physical Volume) • The interface to Detector Element can be extended by any detector specific information • The Detector Manager objects play the main role in providing an interface to Detector Description client applications • Usually one Detector Manager per subsystem • Holds pointer to Raw geometry tree top • Provides subsystem specific interface to access readout geometry information (Detector Elements) GeoModel, CHEP'04

8. Memory optimizations • Shared instancing of logical volumes • Shared instancing of physical volumes including subtrees • Full physical volume cannot be shared • Shared instancing of transformations • Use of full physical volumes and alignable transforms at discretion of subsystem engineer • tiny::HepTransform3D reducing the size requirement for most transformations • specific transformations from 12 doubles to 1 float • general transformations from 12 doubles to 6 float • Name and identifier (copy number) are not stored within physical volumes • Name Tags and Identifier Tags to label single volumes (instances can be shared) • Serial Denominators and Serial Identifiers to generate name strings and identifiers GeoModel, CHEP'04

9. Memory optimizations – parameterized volumes • Parameterizations are not volumes, they are recipes for generating volumes • Three main ingredients of these recipes • GENFUNCTIONS are function-objects or classes that let one to perform function arithmetic in C++ the same way you perform floating point arithmetic and the functions thus created can be evaluated like: double y = f(x); • TRANSFUNCTIONS evaluate to HepTransform3D and can only be multiplied with each other to yield other functions (of a single variable) that evaluate to HepTransform3D HepTransform3D t = tx(i); • Serial Transformers, a kind of GeoModel Graph Nodes that allow a particular physical volume to be placed according to a TRANSFUNCTION expansion of a rigid body transformation • The Shape Factories which use the similar approach to generate volume shapes will become the part of GeoModel toolkit soon GeoModel, CHEP'04

10. Memory optimizations – parameterized volumes • To construct a recipe for generating volume positions one needs an operator that says: apply a generating transformation • This is done with the use of Pow class constructed like this Pow(HepTransform3D, GENFUNCTION f) • creates a fixed generating transform raised to the power of a function Xf(i) • this can be used to generate absolutely any transformation. Rxf(i)*Ryg(i)*Txh(i)… • Example double a, radius, z; Variable icpy; GENFUNCTION gama = Gama0+a*icpy; TRANSFUNCTION xf = Pow(HepRotateZ3D(1.0),gama)* HepTranslateX3D(radius)* HepTranslateZ3D(z); GeoSerialTransformer *st= new GeoSerialTransformer(vol, &xf, N); parent->add(st); GeoModel, CHEP'04

11. Visual debugging tools • Interactive geometry browser based on Open Inventor toolkit • Various manipulations with volumes including iconization • Additional information about selected volume on demand • Name and copy number (if available) • Mass calculation • Shape dimensions and local transformation • When working with simulated data it is possible to visualize hits and tracks on top of material geometry. GeoModel, CHEP'04

12. GeoModel, CHEP'04

13. Translation to GEANT4 • In ATLAS we have developed a tool called Geo2G4 aimed to translate raw geometry description from GeoModel to GEANT4 • Geo2G4 performs the translation by navigating GeoModel raw geometry tree • Geo2G4 implements several mechanisms to optimize memory usage when performing GeoModel to G4 translation • Shared volumes in GeoModel to shared volumes in G4 • Shared subtrees in GeoModel to shared subtrees in G4 • GeoSerialTransformers to G4 Parameterizations with a possibility to switch this feature on/off GeoModel, CHEP'04

14. Translation to GEANT4 – memory optimizations 1. Shared GeoModel volumes to shared G4 volumes. If some logical volume is shared by leaf physical volumes in GeoModel tree, the corresponding G4 logical volume should also be shared. 2. Shared branches ofGeoModel tree to shared branches ofG4 tree. If some physical volume in GeoModel tree is shared by several parent volumes the corresponding branch in G4 tree should also be shared GeoModel, CHEP'04

15. Translation to GEANT4 – memory optimizations 3. Serial Transformer to G4 parameterization • G4 Parameterization class G4STParameterisation has been developed • Constructed using pointer to GeoXF::Function taken from GeoSerialTransformer G4STParameterisation(const GeoXF::Function*, unsigned int); • The parameterization is performed in the following way void G4STParameterisation::ComputeTransformation(const G4int copyNo,G4VPhysicalVolume* physVol) const { HepTransform3D transform = (*function)(copyNo); G4ThreeVector translation = transform.getTranslation(); G4RotationMatrix* rotation = new G4RotationMatrix(transform.getRotation().inverse()); physVol->SetTranslation(translation); physVol->SetRotation(rotation); } • G4STParameterisation objects can be used in G4 application code (not necessarily connected to GeoModel) directly without subclassing GeoModel, CHEP'04

16. Closing remarks: usage of GeoModel in ATLAS • GeoModel has become the main environment for ATLAS Detector Description software development • GeoModel descriptions of several ATLAS subsystems are already used as single Detector Description sources in ATLAS Data Challenge – 2 • It is planned also to describe all subsequent versions of ATLAS geometries (Initial Layout, Realistic Geometry etc.) using GeoModel toolkit and recently developed geometry versioning system GeoModel, CHEP'04