Features of GLAST Detector Description

1. Features of GLAST Detector Description J. Bogart, R. Giannitrapani, D. Favretto

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). Detector Description at GLAST

3. What’s Special About GLAST? • Natural coordinate system for GLAST LAT* is rectangular • practically all interesting volumes are boxes • no need for q or f 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 Detector Description at GLAST

4. 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,...) Detector Description at GLAST

5. 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... Detector Description at GLAST

6. 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. Detector Description at GLAST

7. 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. Detector Description at GLAST

8. 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. Detector Description at GLAST

9. 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 Detector Description at GLAST

10. 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. Detector Description at GLAST

11. 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 Detector Description at GLAST

12. 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. Detector Description at GLAST

13. GLAST GDD Volume Hierarchy world volume spacecraft LAT solar panels towers ACD ... ... ...and so forth Detector Description at GLAST

14. 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. Detector Description at GLAST

15. 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. Detector Description at GLAST

16. 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. Detector Description at GLAST

17. 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. Detector Description at GLAST

18. 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 Detector Description at GLAST

19. 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. Detector Description at GLAST

20. 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. Detector Description at GLAST

21. 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. Detector Description at GLAST

22. flightGeo.xml Identifier Forms and Services GDD dict. geoToVol.xml detModel visitor (not shown) uses geoToVol. xml to create volModel, which provides look-up via volume id for, e.g. Reconstruction. GDD dict. detModel Vol dict. Generic ID Services GDD ids volModel Look-up services Generic ID Services idDictUtil Vol ids *validation *field info *conversion Look-up services Detector Description at GLAST

23. 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. Detector Description at GLAST