Software Solutions for Variable ATLAS Detector Description

1. Software Solutions for Variable ATLAS Detector Description J. Boudreau, V. TsulaiaUniversity of Pittsburgh R. Hawkings, A. Valassi CERN A. Schaffer LAL, Orsay CHEP 2006 TIFR, Mumbai

2. Contents • GeoModel – toolkit for building the transient representation of detector geometries • ATLAS Detector Description is implemented completely in GeoModel • Configuring various geometry layouts • ATLAS Geometry Database and Hierarchical Versioning System (HVS) • Manual and automatic geometry configurations • Incorporating time-dependent alignment information into the detector model • ATLAS Conditions database as a storage for alignment information • GeoModel mechanisms for volume alignment • Passing alignment parameters from Conditions database to the geometry model

3. GeoModel, general notes • The transient description of complete ATLAS detector geometry is implemented using GeoModel toolkit • See the presentation “The GeoModel Toolkit for Detector Description” at CHEP04 • The key features of GeoModel-based description are • Two layers of geometry description • ‘Raw’ (material) geometry • Readout geometry synchronized to raw geometry layer • Same description for all clients (simulation, reconstruction …). GeoModel description of material geometry is translated to Geant4 using automatic Geo2G4 translator • Several optimization techniques allow to describe complicated geometries with minimal memory consumption • Mechanisms for applying alignments on top of regular geometry

4. GeoModel description basics • GeoModel description tree is assembled by Physical Volumes • Full Physical Volumes cache their absolute transformation • The substructure of a physical volume is: logical volume (shape & material) and transformation in parent’s coordinate system • Transform modification moves entire sub-tree • Alignable transformations can be adjusted later, after the entire geometry was built • There is one top for GeoModel tree – World volume. • ATLAS sub-detectors describe their geometry sub-trees independently • Each system can have more than one Tree Top volumes, which are attached to the World volume • Detector Manager objects cache the pointers to the Tree Tops and provide system specific interfaces to Detector Description client applications

5. 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 PV GeoModel description diagram World CALOR MUON PV PV PV PV PV FPV PV SILICON

6. Various layouts of ATLAS detector geometry • Basic idea: we wanted to have a possibility of building various ATLAS geometry layouts with every single version of ATLAS software • ATLAS geometry versioning system is based on HierarchicalVersioning of detector description primary numbers stored in the ATLAS Geometry Database • In order to switch between different geometry layouts it is enough to change a single parameter – ATLAS top level geometry tag • ATLAS geometry tags can be passed across job boundaries • We use persistent TagInfo objects • Subsequent jobs can pick up correct geometry configuration from the input file bypassing manual configuration through job options

7. ATLAS Geometry DB – general notes • The main purpose of the Geometry DB is to store in one common place all primary numbers for geometry description of ATLAS subsystems together with configuration information (tags, switches…) • The master copy of the database is located at the Oracle cluster ATLAS RAC, which is supported by CERN IT/DB group • The relational schema of the Geometry DB follows the design of Hierarchical Versioning System • The primary numbers are kept within Data Tables • Each Data Table corresponds to a Leaf Node in the logical HVS tree • Branch Nodes in the HVS tree are pure logical entities supposed to group child Nodes and build tree hierarchy

8. ATLAS Geometry DB Browser Tag hierarchy of branch HVS Nodes Leaf node tag and its contents

9. ATLAS Geometry DB – tag locking • ATLAS subsystems manage their primary numbers in the Geometry DB independently • Load new primary numbers into database using SQL scripts • New numbers are validated by building subsystem geometries, checking against volume clashes and using in simulation/reconstruction • Eventually a new subsystem specific top level tag is created • Every new ATLAS geometry tag is assembled by subsystem tags. After validation of new tags is done the ATLAS tag is locked • All children tags are locked recursively • The locked tag cannot be renamed or deleted • Data table records corresponding to some locked tag cannot be updated or deleted • Tag locking also means that it can be used in the production

10. ATLAS Geometry DB – data access • ATLAS Detector Description applications get tagged primary numbers from Geometry DB using RAL interface • Now we are moving to CORAL, see the presentation by I. Papadopoulos at CHEP06 • RAL provides an uniform access interface to the data residing in different RDBMS • The appropriate client library is chosen at run time using plug-in mechanisms • Thanks to this feature of RAL we can provide three equivalent sources of Geometry DB data • Oracle master copy is replicated to MySQL and SQLite • The concrete replica is selected either explicitly by setting job option parameters or automatically through usage of DB Connection Service • See the presentation “ATLAS Distributed Database Services Client Library” at CHEP06

11. Different ways of ATLAS geometry configuration • We have developed a special ATHENA service (RDBAccessSvc) which can retrieve HVS leaf node data from geometry database by providing tag of one of its parent branch nodes • Usually it is enough to provide just one ATLAS tag to the whole application for proper retrieval of all necessary leaf nodes • We can pass the geometry configuration tags across job boundaries by using persistent Tag Info objects • This allows us to have two options for ATLAS geometry configuration • Manual: the geometry tags are provided to the application through job option parameters (simulation) • Automatic: geometry tags are retrieved from Tag Info objects recorded by previous jobs. This mechanism guarantees the consistency of geometry layouts used in job chain (simulation-digitization-reconstruction)

12. Incorporating time-dependent alignments • Two sources of non-event data for Detector Description: Geometry DB versus Conditions DB • Geometry DB. Contains values that are constant over simulation cycle or data-taking period • Conditions DB. Contains values that change within a cycle, or get better determined between reconstruction phases • The data necessary to apply alignment corrections on top of regular geometry is kept within ATLAS Conditions DB • Conditions DB is organized primarily by Interval Of Validity (IOV) • ATLAS applications access Conditions DB data through COOL interface developed within LCG project • For more information seehttp://lcgapp.cern.ch/project/CondDBand twopresentations by A. Valassi at this conference

13. Accessing COOL data from ATHENA • Access to COOL from ATHENA is done via the dedicated IOV DB Service (IOVDbSvc) • IOVDbSvc provides interface between conditions data objects and ATHENA Transient Detector Store (TDS) • IOVDbSvc takes care of the low level interactions with COOL • IOVDbSvc ensures that the correct conditions objects are loaded into TDS for the event currently being analyzed • In order to read data from Conditions DB the client application just needs to request conditions objects from TDS • Conditions data clients can also register callbacks on conditions objects so that they are notified whenever the objects change • When new constants are retrieved at the start of an event for which the previous constants are no longer valid

14. GeoModel mechanisms for volume alignment • GeoModel comes with intrinsic mechanisms of putting alignments into the geometry and getting them out • To put alignment in, one alters one or more GeoAlignableTransform objects by calling its setDelta(HepTransform3D) • To get alignments out, one just needs to query physical volume for its transformation • What has to be done in order to make it work in GeoModel based DD applications? • Identify a list of alignable volumes in the system and attach GeoAlignableTransform objects to each of them • Develop a routine which retrieves Conditions objects with alignments constants from TDS and alters appropriates GeoAlignableTransforms

15. Misaligned geometry in Simulation and Reconstruction jobs • Different requirements for misaligned geometry by Simulation and Reconstruction • Simulation needs static geometry snapshot for the entire job. Alignments can be applied only once at initialization • Reconstruction should be able to deal with alignment changes event by event • In order to satisfy these requirements • In Simulation: IOVDbSvc loads Conditions objects into TDS store at initialization • In Reconstruction: DD applications register callback routines, which are called for every event for which the previous constants are no longer valid • … and in both cases DD clients get properly misaligned geometry.

16. Conclusion – Status & Outlook • Using ATLAS Geometry Versioning System we have already implemented many different layouts of ATLAS geometry • Geometry of the entire detector with different level of realism • Various configurations for Commissioning • Test beam setup configurations • Implementation of misaligned detector geometries has started recently • We have the complete infrastructure in place and simple prototype examples • The implementation of realistic misaligned subsystem geometries is yet to come…