Software Solutions for Variable ATLAS Detector Description

J. Boudreau, V. Tsulaia University of Pittsburgh

R. Hawkings, A. Valassi CERN

A. Schaffer LAL, Orsay

CHEP 2006 TIFR, Mumbai

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

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

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

GeoModel description diagram

PV

PVPVPV

PV

PVPVPV

PV

PVPVPV

PV

PVPVFPV

FPV

PV

PVPVPV

PV

PVPVPV

PV

PVPVPV

PV

World

PV

PVPVPV PV

MUON

SILICON

CALOR

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 Hierarchical Versioning 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

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

ATLAS Geometry DB Browser

Tag hierarchy of branch HVS Nodes

Leaf node tag and its contents

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

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

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)

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 see http://lcgapp.cern.ch/project/CondDB and two

presentations by A. Valassi at this conference

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

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?

1. Identify a list of alignable volumes in the system and attach GeoAlignableTransform objects to each of them

2. Develop a routine which retrieves Conditions objects with alignments constants from TDS and alters appropriates GeoAlignableTransforms

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.

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…