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

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Systems Analysis, Prototyping and Iteration Systems Analysis.
Key-word Driven Automation Framework Shiva Kumar Soumya Dalvi May 25, 2007.
Maria Grazia Pia, INFN Genova 1 Part V The lesson learned Summary and conclusions.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
University of Leeds Department of Chemistry The New MCM Website Stephen Pascoe, Louise Whitehouse and Andrew Rickard.
1/18 CS 693/793 Lecture 09 Special Topics in Domain Specific Languages CS 693/793-1C Spring 2004 Mo, We, Fr 10:10 – 11:00 CH 430.
Lecture Nine Database Planning, Design, and Administration
Database System Development Lifecycle Transparencies
Introduction to Software Testing
DATA PRESERVATION IN ALICE FEDERICO CARMINATI. MOTIVATION ALICE is a 150 M CHF investment by a large scientific community The ALICE data is unique and.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Chapter 9 Database Planning, Design, and Administration Sungchul Hong.
Database Planning, Design, and Administration Transparencies
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Overview of the Database Development Process
Framework for Automated Builds Natalia Ratnikova CHEP’03.
1 Shawlands Academy Higher Computing Software Development Unit.
Zhonghua Qu and Ovidiu Daescu December 24, 2009 University of Texas at Dallas.
REVIEW OF NA61 SOFTWRE UPGRADE PROPOSAL. Mandate The NA61 experiment is contemplating to rewrite its fortran software in modern technology and are requesting.
RUP Implementation and Testing
ITEC224 Database Programming
Database Design - Lecture 2
STAR Simulation Overview Maxim Potekhin STAR Collaboration Meeting BNL February 28, 2003 February 28, 2003.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
Database System Development Lifecycle 1.  Main components of the Infn System  What is Database System Development Life Cycle (DSDLC)  Phases of the.
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
The european ITM Task Force data structure F. Imbeaux.
1 Introduction to Software Engineering Lecture 1.
1 Geospatial and Business Intelligence Jean-Sébastien Turcotte Executive VP San Francisco - April 2007 Streamlining web mapping applications.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
1 Planning for Reuse (based on some ideas currently being discussed in LHCb ) m Obstacles to reuse m Process for reuse m Project organisation for reuse.
XML in Atlas: from generic to parametric detector description Stan Bentvelsen NIKHEF Amsterdam XML workshop, CERN, May 22.
Mumbai - India 1 Using XML for Detector Geometry Description in the Virtual Monte Carlo Framework V.Fine, J.Lauret, M.Potekhin STAR Collaboration, Brookhaven.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
FLUKA dose and fluence simulations for CBM experiment I.Kadenko, O.Bezshyyko, V.Pluyko, V.Shevchenko National Taras Shevchenko University of Kiev.
Virtual Monte Carlo and new geometry description in STAR Maxim Potekhin STAR Collaboration Meeting, BNL July 17, 2004 July 17, 2004.
The GeoModel Toolkit for Detector Description Joe Boudreau Vakho Tsulaia University of Pittsburgh CHEP’04 Interlaken.
The Software Development Process
The CMS Simulation Software Julia Yarba, Fermilab on behalf of CMS Collaboration 22 m long, 15 m in diameter Over a million geometrical volumes Many complex.
Introduction What is detector simulation? A detector simulation program must provide the possibility of describing accurately an experimental setup (both.
Firmware - 1 CMS Upgrade Workshop October SLHC CMS Firmware SLHC CMS Firmware Organization, Validation, and Commissioning M. Schulte, University.
Design Reuse Earlier we have covered the re-usable Architectural Styles as design patterns for High-Level Design. At mid-level and low-level, design patterns.
TSS Database Inventory. CIRA has… Received and imported the 2002 and 2018 modeling data Decided to initially store only IMPROVE site-specific data Decided.
Status of the LAr OO Reconstruction Srini Rajagopalan ATLAS Larg Week December 7, 1999.
 Programming - the process of creating computer programs.
Click to add text Systems Analysis, Prototyping and Iteration.
Detector Description in LHCb Detector Description Workshop 13 June 2002 S. Ponce, P. Mato / CERN.
23/2/2000Status of GAUDI 1 P. Mato / CERN Computing meeting, LHCb Week 23 February 2000.
Foundations of Geospatial System Development Todd S. Bacastow Professor of Practice for Geospatial Intelligence John A. Dutton e-Education Institute The.
Highlights from Parallel session 10 - Simulation and Modeling - Makoto Asai (SLAC) CHEP03 - UC San Diego.
STAR VMC project Maxim Potekhin for the STAR Collaboration VMC workshop at CERN Nov
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Investigate Plan Design Create Evaluate (Test it to objective evaluation at each stage of the design cycle) state – describe - explain the problem some.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Chapter 9 Database Planning, Design, and Administration Transparencies © Pearson Education Limited 1995, 2005.
1 SLAC simulation workshop, May 2003 Ties Behnke Mokka and LCDG4 Ties Behnke, DESY and SLAC MOKKA: european (france) developed GEANT4 based simulation.
Complex Geometry Visualization TOol
A C++ generic model for the GLAST Geometric Description
Markus Frank CERN/LHCb CHEP2013, Amsterdam, October 14th–18th 2013
HEP detector description supporting the full experiment life cycle
Linear Collider Simulation Tools
CS310 Software Engineering Lecturer Dr.Doaa Sami
Simulation Framework Subproject cern
Simulation and Physics
From Use Cases to Implementation
Presentation transcript:

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

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

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 

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 

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 ,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.

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

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

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

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

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)

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

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

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)

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

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