Overview
The ATLAS experiment's SCT, along with all other sub detectors, is to be
represented in the Atlas Generic Detector Description (AGDD) database.
A first stage is the replication of the detector as described by Fawzi
Fares and Jo Pater in AGE for Geant3 (June 1997). Their original
AGE files for barrel and forward
are here.
It was decided to write a program to generate the SCT's AGDD files from
a core set of fundamental parameters. This program is loosely called
"preXml" and its function can be summarised by the following diagram:
The main idea is that there is a core set of "preXml / agdd tools" which
do not change and just make life easier. The description of the geometry
of the SCT (or any other detector!) lies only in two files:
-
preXml file: This is a short XML file which lists the fundamental
quantities which are sufficient to parametrise the geometry.
These may be lengths, angles, strings, etc, and arrays of the same. The
DTD file defining the format of a preXml file may be viewed here.
-
Geometry code: The geometry code amounts to a C++ program which,
using the tools if necessary, reads the preXml file and outputs the desired
AGDD XML file containing the final geometry description.
There is plenty of scope for arguing about the level of sophistication
appropriate for the tools. Our tools are fairly complicated, allowing
the preXml file and Geometry code to remain independent of
particular AGDD versions and possibly even output formats. The tools
allow the Geometry code to build the geometry in an "internal" representation,
which is finally formatted for XML by the tools in a transparent way.
The downside is that a large set of tools is harder to maintain.
The main motivation for this whole two stage process was to eliminate
some of the duplications/inter-dependancies found in early attempts to
write detailed XML files by hand.
Particular examples for the SCT Barrel and Forward
If you don't like reading XML directly, I recommend using something
like XEENA.
Historical link:
Historians may wish to look here to find information
about very early versions.
Code notes and the obliatory unintelligible inheritance diagram
Recent changes amount
to standardising the separation between the utilities and the user's geometry.
The current plan is that the user must implement one member function :
agdd::UserGeometry::defineUserGeometry() (see agddUserGeometry.hh).
The method requires that the user returns a structure, which contains all
the necessary information for the agdd xml generator to proceed. An example
of such an implementation is Old.SCT.geo.cc.
Here is an inheritance diagram of the classes
which the user interfaces with. The user only creates the most derived
classes , although these will depend on all their base classes.
Feedback
I would welcome comments in the following kinds of areas.
-
Do you spot any obvious limitations of the scheme?
-
What is least intelligible. All of it?
-
Possibilities for improvements.
Christopher Lester
by
following this link.