features of glast detector description

Features of GLAST Detector Description

J. Bogart, R. Giannitrapani, D. Favretto

22 May 2001 Detector Description at GLAST 2

Outline

• What’s special about GLAST? • Some requirements• Acknowledgements• Constants and arithmetic• Identifiers• Observations

Riccardo will be talking about the core of the project, the realization of the geometry (detModel & clients).


What’s Special About GLAST?

• Natural coordinate system for GLAST LAT* is rectangular– practically all interesting volumes are boxes– no need for or divisions

• It’s small – roughly 1600 x 1600 x 900 (all in mm)– two of three subdetectors have very modest

channel count

*LAT Large Area Telescope, one of two instruments aboard GLAST


What’s Not Special

• Detector components are familiar (calorimeter, tracker, cosmic veto device)

• Same client programs: simulation, display, reconstruction, etc.

• Collaborators are widely distributed (U.S., Italy, France, Japan,...)


Requirements

• Enforce consistency among different clients of geometry description– Get the detector description out of the code!– Single source of (ideal) geometry description.

• Maintainability, flexibility, etc...


Implications and Philosophy• Different clients need not have quite the same input, but all

such inputs should be derived from a single source in some automated fashion. The single source should be optimized for humans (i.e., maintainers); derived inputs may be optimized for individual clients.

• Derived inputs in most cases can and should be in the same form as the original so that the same software tools may be used for several applications. In particular, a single facility provides access to the geometry, insulating clients from the raw XML description.


Acknowledgements

We owe two large debts to ATLAS with regard to dtd design.

The first concerns description of volumes and their placement. To first order we just incorporated the AGDD elements into our own dtd.

The other area concerns identifiers and identifier dictionaries. An early glimpse at work done by Stan Bentvelsen and Christian Arnault got us started in a useful direction.


Constants and Arithmetic

Even for the relatively small LAT, keeping track of constants (e.g., dimensions and position offsets) is a headache. Would like to

* refer to constants symbolically

* use simple arithmetic (at least) to derive new constants

Using XML elements for these functions allows clients to see all or part of this information if they want to. Chief drawback: it’s verbose.


Elements to Support Constants

Primary constants: Have name, type, value, description.

Derived constants: May be named or anonymous. May have value or be computed from other constants.

References to constants: May appear in derived constant definitions or in other parts of the XML file, e.g. for volume dimensions.

See these things in action:

http://www.slac.stanford.edu/~jrb/glast/xml/display/flight-extracts.xml.html

http://www.slac.stanford.edu/~jrb/xml/glast/xml/display/flight-extracts.xml.html




Utilities to Support Constants

Class Arith, member functions evaluate() and saveValue()

Class Substitute, configured with attribute suffix to look for (default ”REF”), will substitute values for symbolic names (new attribute without suffix; old is deleted).

Utilities may be called by any client, or may be invoked by standalone which writes a preprocessed xml file (significantly smaller than the original).

At a higher level, the detModel code discussed in Part II provides a visitor interface and a query interface to the constants.


Dcoumenting Constants

Because constants are xml elements it is easy to automate the process of documenting them. See, for example

http://www.slac.stanford.edu/~jrb/glast/xml/constsDoc.html

http://www.slac.stanford.edu/~jrb/glast/xml/constsDoc.html


Identifier Dictionary

An identifier dictionary is a construct for describing the constraints on a set of identifiers: what fields they can have, in what order, and what values may appear in a field in a particular context.

Backing up a bit, an identifier is (conceptually) a sequence of pairs (fieldname0, value0), (fieldname1, value1),... Values are always non-negative integers.


GLAST GDD Volume Hierarchy

world volume

spacecraft solar panelsLAT

ACD towers

... ...

...and so forth


Traversing the Volume Tree

The world volume contains the LAT

which contains a tower #3

which contains a CAL

which contains layer #2

which contains a CsI crystal #4

It would be natural to associate an identifier which is a sequence of fields, like /0/3/1/2/4, with this object.


Assigning Id Fields

Detector geometry XML allows assignment of one or more idFields (a name and a value) each time a volume is positioned (this comes from AGDD).

Form complete GDD Identifier for a volume by concatenating idfields of all ancestor volumes, starting with (implicit) world volume.

Use an id dictionary like

http://www.slac.stanford.edu/~jrb/glast/xml/display/flightIdDict.xml.html

to check that ids so generated are valid.

http://www.slac.stanford.edu/~jrb/glast/xml/display/flightIdDict.xml.html


Why We’re Not Done

There are constraints imposed by simulators on exactly how the volumes can be put together. Also the xml syntax we’re using provides shortcuts for certain kinds of positioning.

As a result the nesting described in the input xml file can be less than ideal for other purposes. E.g., fields can be in the “wrong order” or just irrelevant for some clients.


Three Kinds of Identifiers at least

• GDD identifiers as just described

• Readout identifiers, used for digis

• Volume identifiers, used to identify hits (both integrating* and position).

* To satisfy request from CAL for “energy accounting”. Even non-readout volumes are sensitive (sort of), and in particular need to be identified for clients of simulated data.


One Approach• Although GDD identifiers aren’t always ideal for

a particular application, they can be constructed to contain all the information any client might want

• Readout and volume identifiers have a similar form (sequence of field names with values). Their constraints may also be defined by an id dictionary.

• Describe (in XML) transformations for, e.g.,– GDD identifier to Volume id

– GDD identifier to Readout id


One Approach (cont’d)

• Generic identifier dictionary classes and identifier conversion classes can do much of the work.

• Classes specific to the kind of identifier (GDD identifier, volume id, etc.) will be needed for some services, such as look-up of information associated with the identifier.


Simulation

• detModel uses input xml to build the geometry. GDD ids are supplied to simulator to label volumes

• During simulation as hits are instantiated GDD ids are converted to volume ids, which are used to label the hits.

• Do something similar (translate volume ids to readout ids) for digis.


Event Data Client

• detModel uses input xml to build the geometry as before.

• Invoke a detModel visitor whose output is a data structure associating volume ids with the “original” volumes in the detModel.

• The new data structure supports look-up operations by volume id.

• Do the same thing for readout ids.


Identifier Forms and ServicesflightGeo.xml

detModel

GDD ids

Generic ID Services

volModel

Vol ids

geoToVol.xml

Generic ID Services

idDictUtil*validation*field info*conversion

GDD dict.

Vol dict.

Look-up services

Look-up services

GDD dict.detModel visitor (not shown) uses geoToVol. xml to create volModel, which provides look-up via volume id for, e.g. Reconstruction.


Remaining Issues, Part I

Identifier Dictionary and Conversion: XML exists; utility classes are in progress. Remains to be seen if adequate services (whatever those are) can be implemented.

File Maintenance: The scheme is now dependent on several (xml, hence ascii) files which must be consistent with each other.

features of glast detector description

Documents