Transcript slides - Indico

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


Configuring various geometry layouts



ATLAS Detector Description is implemented completely in GeoModel
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
World
PV
PV
PV
CALOR
MUON
PV
PV
PV
PV
PV
PV
PV
PV
FPV
PV
PV
PV
PV
PV
PV
PV
SILICON
PV
PV
PV
PV
PV
PV
PV
FPV
PV
PV
PV
PV
PV
PV
PV
PV
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




Every new ATLAS geometry tag is assembled by subsystem tags.
After validation of new tags is done the ATLAS tag is locked




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
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


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


Now we are moving to CORAL, see the presentation by I. Papadopoulos
at CHEP06
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



The data necessary to apply alignment corrections on top of regular
geometry is kept within ATLAS 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
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 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


IOVDbSvc provides interface between conditions data objects and
ATHENA Transient Detector Store (TDS)
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.
2.
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
Misaligned geometry in Simulation and
Reconstruction jobs

Different requirements for misaligned geometry by Simulation and
Reconstruction



In order to satisfy these requirements



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 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…