1. The XML-based geometry description for the STAR experiment Maxim Potekhin BNL CHEP 2003

2. Purpose of this presentation Advertise the fact that the STAR collaboration is renewing its effort to migrate to the XML-based detector geometry description, based on the maturity of a few projects already undertaken in the HEP community, and new developments in this area Describe how STAR is conducting a feasibility study in that regard Invite discussion with interested parties and join a collaborative effort Report our first experience with this technology and present a “case study” that may be of interest for other groups considering the XML-based geometry description, especially those currently using the GEANT 3.21 platform

3. Overview Elements of the STAR simulation infrastructure  Motivations for single source geometry  Choosing the optimal approach for the development of the STAR geometry  Practical exercise in XML migration  Conclusion: the scope and direction of the STAR XML based geometry effort 

4. Elements of the STAR Simulation infrastructure Main simulation tool: STAF/GSTAR –based on GEANT 3.21 –dynamic loading of user libraries on demand, including customized subsystem geometries –high degree of interactivity, with full scripting capability –output in ZEBRA format –persistent data, such as GEANT geometry, in the output Zebra files Translation layer:  –provides mapping of the native GEANT structures to those used in reconstruction. Maintenance requires expert knowledge of GEANT. Detector Geometry Description 

5. Current Detector Geometry Description Number of detector subsystems: 18 Description written in a macro “geometry language” translated into Fortran –user maintainable –facilitates documentation –based on an obscure Fortran preprocessor –ideally suited for application-specific Fortran code structuring –in many cases, helps circumvent limitations of Fortran –can help with the GEANT learning curve for novice users –has been successfully used in a number of projects –Some features: easy to follow mnemonic notation useful features like automatic generation of rotation matrices, media, media stack etc automation of certain other routine operations in GEANT 3.21 11,000 lines of geometry code, largely user maintained As previously mentioned, there is a translation layer: volume maps (not part of the geometry per se) are maintained separately. –May or may not be user maintainable.

6. Current Detector Geometry Description Geometry code example: Block SVTT is the mother of SVT volumes * Material Air Attribute SVTT seen=0 colo=1 Shape TUBE Rmin=svtg_RsizeMin, Rmax=svtg_RsizeMax, dz=svtg_ZsizeMax * End rings to support the ladders: * Create SIRP " inner end ring polygon piece " Position SIRP Z=serg_EndRngZm+serg_EndRngTh/2 AlphaZ=22.5

7. Motivations for single source geometry Geometry: a crucial element of the experiment software Current STAR geometry macro language + Works extremely well for the GEANT 3.21 target language –Employs the technology with a scarce knowledge base –Hard (or impossible) to extend to other applications: GEANT 4 migration Tracking software Other event reconstruction Event display systems Absence of the single source geometry description is a liability –significant complexity of both Monte Carlo and reconstruction geometries –lack of integration with event display –difficulty of reconciliation, no handshake –losing the benefit of a unified geometrical position database

8. Motivations for single source geometry Immediate benefits we may be able to obtain from new geometry –A step towards future migration to GEANT 4, which would require a non-trivial amount of work in any case –A bridge between GEANT 3.21 and 4.* –Facilitation of the ongoing geometry modifications due to the detector upgrades –Increased robustness of the geometry code due to validation –Means for common persistent positioning data (databases) –Handshake between simulation and tracking software –Event display integration

9. Choosing the optimal approach for the development of the STAR geometry Choice of technology: data description languages vs algorithmic + algorithmic languages offer most flexibility and efficiency + ease of integration with the target platform using the same language (e.g. C++ with GEANT 4) + existing (or possible) tools for GEANT4/3 handshake –easy for the code to get obscure –hard to beat the tendency of leaving hardcoded data in the code –no built-in structure or validation –no mechanisms facilitating the database integration –tend to depend too heavily on the target language/platform “Let data be data” –choose marked-up data as the platform

10. Choosing the optimal approach for the development of the STAR geometry XML: pro + tree-like structure of data matches the logic of the most important target applications (GEANT), hence a good modeling tool + well understood and standardized technology with a vast knowledge base, enjoying enormous interest and investment by the industry + integration with databases etc + plethora of well documented and supported tools + platform neutral, i.e. not tied to a particular target language + substantial R&D already under way in the HEP community, in individual groups such as all major LHC experiments (CMS, GDML in GEANT 4, LHCb etc, as well as prior experience in AGDD in Atlas and Alice) + sponsored by the LCG (RTAG7) XML: contra –algorithmic part completely missing in native XML (but see recent developments in CMS geometry) – will depend on the emerging standards –the complexity of HEP detectors may result in unwieldy files –as of yet, lack of widely accepted domain-specific standards for the detector geometry description (work in progress)

11. Practical exercise in XML migration Assumptions about what we can (or soon will be able to) borrow from, and contribute to, the XML development done in other groups: –Detailed DTD’s and schemas –Persistent data solutions –Naming conventions and other elements of syntax –A parser generating GEANT 3.21 geometry –Hopefully, complete parsers generating GEANT 4 geometry (best case scenario), plus presentation tools –Expanded functionality of existing implementations Design considerations: –simply transforming XML to the target language –OR –creating an internal representation of the geometry Observations: –convergence and commonality in the existing XML geometry implementations –tendency to implement the second solution as listed above Assessment of the difficulties encountered so far –Controlling complexity and exploiting symmetry –algorithmic features in XML are relatively hard to implement

12. Practical exercise in XML migration STAR is studying the feasibility of migrating its detector geometry to XML, leveraging the experience accumulated in the HEP community Emphasis put on platform neutrality as we intend to generate both GEANT 3.21 and GEANT 4 geometries from the same XML source A pilot project under way, with the practical goal to migrate a complete subsystem of the STAR detector to XML, as a feasibility study Content of the pilot project: –Creation of a parser that generates GEANT 3.21 code from an XML document. Java DOM toolkit chosen for the development of the parser, for completeness and support reasons –Evaluation of the other groups experience and technology with a view to possibly reuse it and contribute to it

13. Practical exercise in XML migration Design parameters for the pilot STAR XML parser –simplicity –at this stage, does not necessary have to comply with any of the existing XML geometry implementation (pending final selection) –in future, should be compliant with the emerging standards to leverage the tools developed in other groups –devoid of any knowledge of the concrete features of the STAR detector (i.e. the all the information resides in the XML document) –allows for certain types of formulas and constructs like loops to be included –in general, contains all of the functionality of the existing STAR parser that generates GEANT 3.21 code –contains classes that can be subclassed according to the target language (i.e. provides a basic toolkit that can be used to built implementations for different target platform)

14. XML migration: an example of the code fragment <Volumes> <volume name="ECVO" shape="CONS" <volume name="ECVO" shape="CONS" par="(SMDcentr-GapSMD/2.0-zslice)/2.0 par="(SMDcentr-GapSMD/2.0-zslice)/2.0 zslice*Tan_Low-dd zslice*Tan_Low-dd zslice*Tan_Upp+dup zslice*Tan_Upp+dup (SMDcentr-GapSMD/2.0)*Tan_Low-dd (SMDcentr-GapSMD/2.0)*Tan_Low-dd (SMDcentr-GapSMD/2.0)*Tan_Upp+dup (SMDcentr-GapSMD/2.0)*Tan_Upp+dup PhiMin PhiMax" medium="Air_Medium"> PhiMin PhiMax" medium="Air_Medium"> <volume name="EMOD" shape="CONS" <volume name="EMOD" shape="CONS" par="(SMDcentr-GapSMD/2.0-zslice)/2.0 par="(SMDcentr-GapSMD/2.0-zslice)/2.0 zslice*Tan_Low-dd zslice*Tan_Low-dd zslice*Tan_Upp+dup zslice*Tan_Upp+dup (SMDcentr-GapSMD/2.0)*Tan_Low-dd (SMDcentr-GapSMD/2.0)*Tan_Low-dd (SMDcentr-GapSMD/2.0)*Tan_Upp+dup (SMDcentr-GapSMD/2.0)*Tan_Upp+dup PhiMin/Nsupsec PhiMax/Nsupsec" medium="Air_Medium"> PhiMin/Nsupsec PhiMax/Nsupsec" medium="Air_Medium"> </volume> </Volumes> Comment: variables declaration and definition part was omitted for brevity

15. Conclusion The STAR collaboration is undertaking a feasibility study to determine whether and how we should proceed with migrating the detector geometry description to XML, from the existing customized macro language Seeking to join a collaborative effort in that direction, adopt emerging standards and leverage the expertise and tools being created in the HEP community As a part of this study, a parser is being developed using the DOM technology and the available Java software, with the purpose of understanding difficulties and pitfalls of such migration As a demonstration of principle, simple hierarchies of volumes described in XML have been successfully translated into GEANT 3.21 code (Fortran) Planned milestone: a detector subsystem geometry ported to XML