The XML-based geometry description for the STAR experiment

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 seen0 colo1
• Shape TUBE Rminsvtg_RsizeMin,
  Rmaxsvtg_RsizeMax, dzsvtg_ZsizeMax
• End rings to support the ladders
• Create SIRP " inner end ring polygon piece "
  
• Position SIRP Zserg_EndRngZmserg_EndRngTh/2
  AlphaZ22.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 RD 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 DTDs 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

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

• ltVolumesgt
• ltvolume name"CAVE" shape"BOX " par"1000.0
  1000.0 1000.0" medium"Air_Medium"gt
• ltvolume name"ECAL" shape"CONE" par"dZ
  wheelRmin1 wheelRmax1 wheelRmin2 wheelRmax1"
  medium"Air_Medium"gt
• ltvolume name"EAGA" shape"CONS"
  par"dZ wheelRmin1 wheelRmax1 wheelRmin2
  wheelRmax1 PhiMin PhiMax" medium"Air_Medium"gt
• ltvolume name"EMSS" shape"CONS"
  par"dZ wheelRmin1 wheelRmax1 wheelRmin2
  wheelRmax1 PhiMin PhiMax" medium"Iron_Medium"gt
• ltvolume name"EFLP" shape"CONS"
  par"Front/2.0 Eflp_rmin1 Eflp_rmax1 Eflp_rmin2
  Eflp_rmax2 PhiMin PhiMax" medium"Iron_Medium"/gt
• ltposition volume"EFLP"
  positionXYZ"0.0 0.0 ZOrig-centerFront/2.0"
  copy"1"/gt
• ltvolume name"ECVO" shape"CONS"
• 
  par"(SMDcentr-GapSMD/2.0-zslice)/2.0
• 
  zsliceTan_Low-dd
• 
  zsliceTan_Uppdup
• 
  (SMDcentr-GapSMD/2.0)Tan_Low-dd
• 
  (SMDcentr-GapSMD/2.0)Tan_Uppdup
• PhiMin
  PhiMax" medium"Air_Medium"gt
• ltvolume name"EMOD"
  shape"CONS"
• 
  par"(SMDcentr-GapSMD/2.0-zslice)/2.0

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