1 / 22

A C++ generic model for the GLAST Geometric Description

A C++ generic model for the GLAST Geometric Description. J.Bogart D.Favretto R.Giannitrapani. Contents. The detModel Visitors The HTML visitor The VRML visitor The GEANT4 visitor The ROOT visitor Some images A VRML graphic gallery A G4 simulations gallery

dlord
Download Presentation

A C++ generic model for the GLAST Geometric Description

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A C++ generic model for the GLAST Geometric Description J.Bogart D.Favretto R.Giannitrapani Detector Description Workshop

  2. Contents • The detModel • Visitors • The HTML visitor • The VRML visitor • The GEANT4 visitor • The ROOT visitor • Some images • A VRML graphic gallery • A G4 simulations gallery • A primitive ROOT hits display • What next? Detector Description Workshop

  3. detModel • detModel is a C++ library that implements the geometry description contained in a GDD compliant XML document • Information is represented by a C++ classes hierarchy • Some of the classes have a direct interpretation as GDD elements (e.g. GDDbox, GDDstack, GDDcomposition) • Some other classes are support ones (e.g. GDDmanager, GDDvolume, GDDvisitor) • The detModel is divided in 3 main packages • Constants this represent the constants part of the XML document • Sections: this represent the sections part of the XML document • Management: this provides classes to manage, navigate and query the hierarchy Detector Description Workshop

  4. detModel • The GDD class (the root of the hierarchy) is the access point to the Sections and the Constants packages • The GDDmanager (that is a singleton) gives access to the GDD class and to all the functionalities of detModel (queries, start of a visitor, parsing of a file etc etc) • The detModel will be accessed by external clients that need the information contained in flight.xml (simulations, reconstruction, analysis, event display, documentation etc.) • Not all the clients needs all the information • detModel is modular, in the sense that it is possible to use only the packages that are needed • We are planning a new package for identifiers dictionary and a new one for material definition (almost similar to AGDD) Detector Description Workshop

  5. detModel (cont’d) The Management package Detector Description Workshop

  6. detModel (cont’d) The Constants package Detector Description Workshop

  7. detModel (cont’d) The Sections package Detector Description Workshop

  8. detModel (cont’d) • How to access the hierarchy • Two main way • Direct access to the hierarchy, by classes methods • Access through visitor pattern (see later) • not recursive visitor • recursive visitor • The direct access can be useful when not all the hierarchy has to be accessed, but only some information is relevant for the client • The visitor pattern is useful when the full hierarchy has to be accessed (visited) by the client Detector Description Workshop

  9. The Visitor Pattern • What is a visitor? • It is a pattern (a sort of reusable paradigm of object oriented programming) • It can navigate through a classes hierarchy • It is a very flexible way to add new functionalities to classes without modifying them • This can be useful for a client mechanism; each client can implement the functionalities that it needs • Why we choose this pattern for detModel? • GDD was inspired by Atlas AGDD; Atlas people use this pattern, why don’t we use it? • More seriously, it is very useful for this kind of problem. • We have defined two visitors • A sections visitor • A concrete visitor Detector Description Workshop

  10. The Visitor Pattern (cont’d) • How does it work? • An abstract visitor class is defined • For each concrete class the visitor has a pure abstract method for its visit • Each concrete class has an accept method for the visitor (double dispatch) • Each client has to implement a concrete subclass of the abstract visitor • The visit is started from the root of the hierarchy • The visit can be recursive (each accept method is responsible to recurse on the objects contained in the element) • Or not recursive (this responsibility is delegated to the visitor) GDDconcreteVisitor subclass of GDDvisitor (abstract class) void GDDconcreteVisitor::visitBox(GDDbox* b) {do something with b} void GDDbox::accept(GDDvisitor* v) {v->visitBox(this);} Detector Description Workshop

  11. The Visitor Pattern (cont’d) • HTML visitor • It is a constants visitor • It generates a well formatted web page with all the constants specified in the flight.xml • Data are arranged on tables • Colors help to separate primary constants from derived ones (colors and format from Joanne) • Uses: • As an example of visitor for detModel • For reference Detector Description Workshop

  12. The Visitor Pattern (cont’d) • VRML visitor • It is a sections visitor • The Virtual Reality Markup Language is a standard format for 3D representations • Pros: • It is simple • It permits navigation and easy manipulation of the 3D world • It is an ASCII format • It can be seen on a Web Browser (with a plugin) • Cons: • If the geometry is too complex it can require a dedicate hardware (this is true for most 3D applications ...) • Uses: • As an example of a visitor for detModel • As a check for the geometric consistency of flight.xml • For fun Detector Description Workshop

  13. The Visitor Pattern (cont’d) • GEANT4 visitor • It is a sections visitor, invoked inside the user DetectorConstruction class of a standard G4 simulation (in collaboration with F.Longo from Trieste) • It permits to visit all the geometry hierarchy and to instantiate all the G4 relevant things • Shapes • Logical Volumes • Physical positioning • Right hierarchical relations • Sensitive detectors • With the use of a G4 messenger it is possible to • Load an XML file • Change the envelope volume • This permits to simulate, without any need to exit from the simulation, any part of the detector independently Detector Description Workshop

  14. The Visitor Pattern (cont’d) • ROOT visitor • It is a sections visitor (in a very starting phase) • It builds a TGeometry object containing the detector hierarchy • A list of TShape containing the shapes (mainly boxes) • A list of TNode containing the physical instances • Relationship between the nodes (the hierarchy) • This object can be saved and used in any ROOT application • As a first example we are working on an Hits display (see later) • We have still some problems with rotation, but we are working on it Detector Description Workshop

  15. A VRML Graphics Gallery Detector Description Workshop

  16. A VRML Graphics Gallery (cont’d) Detector Description Workshop

  17. A VRML Graphics Gallery (cont’d) Detector Description Workshop

  18. A G4 Simulations Gallery • Some GEANT4 client results • A mu-, an e- and a gamma at 10 MeV Detector Description Workshop

  19. A G4 Simulations Gallery (cont’d) • A mu-, an e- and a gamma at 1 GeV Detector Description Workshop

  20. A G4 Simulations Gallery (cont’d) • Some more examples Detector Description Workshop

  21. A Primitive ROOT Hits Display • The detModel is used to display the exact geometry of the tracker superimposed to the hits generated with G4 • The hits are retrieved from an ASCII file (temporary) • For clarity we set as visible only the converter planes of the tracker Detector Description Workshop

  22. What next? • The GDD generic model is far from perfect • Not all the GDD parts are yet implemented • A new design iteration is needed, especially for positioning classes • We need to improve the documentation (Doxygen) • Integration with the rest of GLAST software (GAUDI) • Improvement of the management package • New query functions • Need for user requirements • Improvement of the clients • GEANT4 client needs a new organization for hits persistency (Root) • Hits display needs to develop in a full event display (Root or Wired 2, we are still evaluating) • Stay tuned (http://www.fisica.uniud.it/~riccardo/GDD) Detector Description Workshop

More Related