STAR Computing Simulation | |
Technical Requirements Document for the STAR Detector Description Services | |
Maintained by Maxim Potekhin | |
Version 1.01. Introduction1.1 The purpose of this documentThe purpose of this document is to specify the technical requirements for the STAR Detector Description Services (DDS). These requirements will define the design of the DDS, as well as help guide the changes in other elements of the STAR software that will have to be done in the course of the overall system integration. This document does not contain the schema for the Detector Description Language and other related schemas, which will be covered in separate design documents.1.2 MotivationTraditionally, the experiments in High Energy and Nuclear Physics had their geometries decribed separately for the needs of simulation and processing of the experimental data (reconstruction). This was in part due to the fact that the geometry for simulation purposes was typically represented as code written in a traditional programming language (e.g. Fortran) specifically for theGEANT application
(or something similar).
The reconstruction software, on the other hand, was often not based on
GEANT and instead made use of some form of
other geometry model, with geometrical data
fed from a database. Other applications, such as event display,
would often have their own geomtery model, defined from
another set of parameters. One could say that typically
detector models in various parts of the experiment's software
were not integrated with each other.
Due to the increasing complexity of experiments, this situation
is virtually impossible to sustain, as maintenance of the geometry
in a few disparate pieces of code becomes extremely
labor intensive, and so does verification of the geometry model
(or models) existing in various software systems of the same
experiment.
The STAR experiment faces challenges of that
nature as well:
1.3 Recent Developments in the Area of Detector DescriptionRecent years have seen the growing interest in the HEP community in creating software detector models from the "single source", or "unified" geometry description. This breaks away from the tradition of writing application-specific code, in an application-specific language, for such platforms asGEANT 3.21
or GEANT 4 in the respective programming languages,
such as Fortran or C++ , as well as the tendency
to embed the actual numerical data in such code.
Efforts in the area of detector geometry and material modeling,
with varying degree of success, have been undertaken in the
following experiments: ATLAS, CMS, ALICE, LHCb (as well as in a few others).
Despite variety in the ways the work done in these groups,
it was to a large extent based on using the XML ,
the Extensible Markup Language, either as a means
to describe geometrical data or as an exchnage format.
The choice of XML as a platform for geometry description
is based on a large number of factors. Besides those commonly
found in literature, in our experience there are also the following:
XML is the most likely choice for the
STAR geometry description as well.
The LHC Computing Grid (LCG)
project has sponsored a Requirements Technical Assessment Group
on Detector Geometry and Material Description, known as RTAG#7. It included
experts from CMS and other experiments and was able to absorb
most of the accumulated expertise in its published recommendations.
The potential of a widely accepted set of standards emerging form this
activity is unclear at this point.
However, it's clear that the approach featuring a flexible Detector
Description based on a single source (and often using a XML -based
description language) has been established and applied in the software
products created and used in a few experiments. It was decided
that we in STAR should evaluate it as well, as it has the potential
of bringing significant benefits to the STAR physics analyses.
A pilot project was done in February-March of 2003, which was
aimed at gaining experience in expressing the STAR
geometry in a XML -based description language,
and studying the issues inherent in parsing such code. In parallel,
we researched the current status and results of much larger and
ambitious projects undertaken in other groups. We have arrived at
the conclusion that a parser generating the GEANT 3.21
or GEANT 4 code, by itself, may not justify
the very significant effort involved in the geometry migration, and
that a broader definition of the Detector Description Services
is needed.
1.4 The Structure of This DocumentSection 1 contains a short Introduction to the area of detector description, motivations for the STAR experiment to get involved in this, and a summary of recent developments in that area. In Section 2, we present a brief Glossary of Terms which help identify the problem domain. Section 3 provides some further illustrattions in the form of Usage scenarios. Finally, in Section 4 we arrive at the Technical Requirements for the STAR Detector Description Services. It contains the General Requirements as well as a discussion of their application in aXML -based system.
In Section 5, we present some conclusions and notes on the
current status of the project.
2. Glossary of TermsWe will follow, in part, the glossary provided in the RTAG#7 document, as it is close to being standard. It is given here in an abridged format for readibility, and contains some additions and other small differences:
3. Usage ScenariosTypical usage scenarios will include but are not limited to the following:
4. Technical Requirements for the STAR Detector Description Services (DDS)4.1 General Technical RequirementsBased on te above Glossary and Usage Scenarios we formulate the following Technical Requirements:
The above requirements effectively define the composition of the system which can be itemized in a condensed form:
4.2 The XML-based components of the Detector Description ServicesBased on the General Technical Requirements (previous subsection) we can now formulate how those will be met by theXML -based components of the DDS.
In the following we assume that the reader has basic knowledge
of XML and XML schemas.
Most the terminology largely follows that of the RTAG#7
and CMS groups. We will present guidelines for the schemas at this point,
leaving these to be finalized at a later date.
4.2.1 DDLWithin theXML approach, the DDL
denotes a XML schema adpoted for
describing the detector geometry, i.e. tag names, attribute lists, structure
of tags etc. A document conforming to this scheme is called an
instance document of the schema.
XML tags to be included in DDLWhile this is still very preliminary, we make a note of the following tags (or similar) that are likely to be used in DDL:
Partitioning and Cross ReferencingBased on the experience gained in STAR, as well as in other groups, we assume that the DDL document will be partitioned into sections containing the data belonging to the same category (e.g. material section, shape section etc). A hypothetical example of the material section could resemble the following: MaterialSection    CompositeMaterial name="G10" .../     CompositeMaterial name="NOMEX" .../     ElementaryMaterial name="Hydrogen" .../      .... /      .... /      .... / /MaterialSection It will also be necessary to implement document cross referencing, whereby items defined in a particular section are referring to items in different sections located in same or different documents. This in turn mandates the use of namespaces in order to be able to uniquely identify items. As a simple example, if we have a file named material.xml ,
we could refer to a particular material in that file by using a tag:
CompositeMaterial name="materials:Air" .../4.2.2 CDLIn the simplest form, the complete detector description could be contained in a single DDL source file. This, of course, is not practical for our purposes as the STAR detector is quite complex. While this is not a necessary a part of the requirements, it is reasonable to assume that the DDL code will be stored in a potentially large number of files, possibly in different locations and in a different form (such as flat files and database objects, etc). As DDL descriptions of the detector components evolve, so do their respective schemas, therefore there must be a way to correctly retrieve the schema as well, so that validation can take place. Combined with the requirement of Versioning and Configuration Management, this leads us to adopt a protocol for selecting a set ofDDL documents according to the user's
instruction (e.g. a specific timestamp).
Implemented as a XML schema, such
protocol is termed Configuration Description Language, or CDL.
The CDL document helps fulfill
three important functions of the DDS:
CDL document could look like
this:
Configuraion    Include         File url="www.rhic.bnl.gov/star/geo/geometry/year2003/star.xml"          File url="www.rhic.bnl.gov/star/geo/tpcgeo/year2003/tpc.xml"/          File url="www.rhic.bnl.gov/star/geo/ecalgeo/year2003/ecal.xml"/        /File     /Include      .... /      .... /      .... / /Configuration 4.2.3 ADLDue to the symmetries often present in the detector design, it is sometimes desirable and/or necessary to use algorithms to build the geometrical hierarchy. within the DDL. Since DDM has been identified as a representaion layer accessible to a variety of clients, we can no longer rely on simple in-line code or a formula translation for a particular target language. Instead, the interface to such algorithms is formalized in a schema under the name of Algorithm Description Language, or ADL. The ADL schema will contain tags for Algorithm Definitions, as well as means for parameter binding between ADL and DDL tags within which the algorithms are used.5. ConclusionsThere are compelling reasons to migrate the detector description in the STAR experiment from a set of isolated tools and applications, to the Detector Description Services. It will logically include the "single source" geometry model which will be made available to client applications. The present document contains Technical Requirements for such system. We are now conducting a feasibility study trying to determine which existing development projects and frameworks can be adopted by the STAR organization in order to leverage the significant technology investment made elsewhere. Since the existing systems and/or design documents feature a large degree of commonality, which was also reflected in a paper sponsored by the LHC Grid Computing Computing Project, we identified common components such as Detector Description Language, Configuration Description Language and others. The general adoption ofXML schemas as basis for these languages was noted
and it is now assumed that STAR will use this technology as well.
The documents following this one will contain a discussion and specifications
of XML schemas and other design detail.
|