Identifier Thoughts

• Requirements
• Identifier assignment and look-up
• Identifier verification
• Examples of GLAST identifiers
• Identifier dictionary
• "Features"

Requirements

The xml geometry description file needs to provide sufficient information that an application can..

• ..generate unique and reproducible readout ids for each separately-digitizable element of the LAT
• ..generate unique and reproducible ids which partition the collection of all non-vacuum media as needed for energy accounting. There may be cases where the full granularity of the volume hierarchy is not of interest for this purpose, in which case a single identifier may be used to identify a subtree rather than a leaf of the volume hierarchy. There may be other cases (calorimeter log) where it is desirable to segment a single leaf volume.

Identifier assignment and look-up

Recall that volumes are described in the new xml file in two stages: first a logical volume is described, then it is positioned (by specifying a reference to it in the appropriate context) to give a physical volume. A single logical volume description may be referred to by more than one physical volume; only physical volumes need identifiers (and not necessarily all of them, either).

Any positioning element may optionally include a idField element. (In the ATLAS dtd and, so far, in our modified version, it's called an identifier element, but that's misleading and confusing for this discussion, so I'll continue to call it an idField.) Such an element specifies a field name and a value, or, in the case of multiple positionings, a prescription for assigning a value to each of the copies to be positioned. The value is always ultimately a non-negative integer; either literally an integer to begin with or a label which translates to an integer. The full identifier for a (physical) volume can be formed by concatenating all the idFields of its ancestor volumes in order, from the root of the volume hierarchy on down, including its own idField, if any. It should be possible for the generic model classes to form these identifiers, either in the process of forming the hierarchy of volumes or on request.

Identifier verification

Only certain sequences of identifier fields make sense. Only certain values may appear for a given field; the set of values which are allowed may also depend on the sequence of ancestor volumes. Verification that the identifier assignments are in accord with the constraints will need to be done by the application, presumably the generic model classes (as opposed to the xml parser).

Examples: identifier ranges

I'll use notations here of the form fieldname="value", fieldname="val1,val2,...", or fieldname="lowerLimit-upperLimit", to denote possible entries for a field. Values ultimately will be numbers, but in some cases these will come from translating a string from an enumerated list. The fieldnames are just off the top of my head and are not meant to be final choices; something more descriptive would be better. Since I don't yet have information on the support components for the ACD, the following only includes tiles and scintillating tape. The total set of identifiers for the ACD is the union of those coming from an expansion of each line

/obj="LAT"/part="ACD"/face="top"/sens="tile"/row="0-4"/col="0-4"
/obj="LAT/part="ACD"/face="side"/side="0-3"/sens="tile"/row="0-1"/col="0-4"
/obj="LAT/part="ACD"/face="side"/side="0-3"/sens="tile"/row="2-3"/col="0-9"
/obj="LAT"/part="ACD"/face="top"/sens="tape"/row="0-4"/col="0-3"
/obj="LAT"/part="ACD"/face="side"/side="1-4"/sens="tape"/col="0-3"

where possible values for obj might be "LAT", "spacecraft", "solarPanels", etc.; values for part would include "ACD", "towers" and probably some structural components. Parts of the tracker, for example, would have identifiers starting out something like

/obj="LAT"/part="towers"/towerId="0-15"/towerPart="TKR"/tray="0-18"
        /layer="core"
/obj="LAT"/part="towers"/towerId="0-15"/towerPart="TKR"/tray="0-18"
        /layer="face"/face="bot,top"
/obj="LAT"/part="towers"/towerId="0-15"/towerPart="TKR"/tray="0"/layer="Si"
       /Si="top"
/obj="LAT"/part="towers"/towerId="0-15"/towerPart="TKR"/tray="18"/layer="Si"
       /Si="bot"
/obj="LAT"/part="towers"/towerId="0-15"/towerPart="TKR"/tray="1-17"/layer="Si"
       /Si="top,bot"
/obj="LAT"/part="towers"/towerId="3-18"/towerPart="TKR"/tray="1-17"
       /layer="conv"

Identifier dictionary

The identifier dictionary will be an xml description of what identifiers are allowed; that is, what sequence of field names taking on what values. In particular, it will

• make the association between enumerated field values and non-negative integers
• specify all allowed sequences of field names
• for each allowed sequence of field names, it will specify the range of values allowed for each field. In general, the values allowed for a field will depend on the sequence of fields preceding it.

The driving application for the Dictionary is verification, but it will have other uses. For example, a calibration manager might organize calibration information by partial identifiers (identifiers whose right-most field is not a leaf or which do not start at the root of the tree, or both). The Identifier Dictionary could provide services to generate some subset of identifers. Both for modularity of development and to support applications which don't need or want access to the full geometry description, the xml specification for the Identifier Dictionary ought to be in a separate physical file from the geometry description, thought perhaps included in that file in the logical sense.

"Features"

• The number of fields in an id (even for a leaf, that is, an object with no identified inner components) varies. It even takes more fields to identify a side ACD tile than a top ACD tile.
• Fields concatenated in an order reflecting the nesting of volumes, as is done in the examples, may lead to "unnatural" looking identifiers. For example, it might be nice to have "CAL" and "TKR" appear as parts, as "ACD" does, but the hierarchy of volumes just doesn't go this way.

---

Last revised: 7 March 2001