ATLAS Graphics

Julius Hrivnac
(http://hrivnac.home.cern.ch/hrivnac/)
CERN Geneva, FzU Prague

Abstract

The design of the Atlas(1) Graphics Domain is described as well as current status of its development.

1. Mission

The aim of the Atlas Graphics is to enable visual representation of the objects existing in the Atlas software. The Design of the Atlas Graphics is based on the believe that both  requirements and graphics software abilities will be very broad at any time and will constantly evolve. The Atlas Event Display should be able to accommodate all that diversity and changes . This can be accomplished only by extreme flexibility and modularity of the core control structure. The Atlas Graphics is part of the full Atlas software package.

2. Components

There are many graphical components available today, either commercial, free or developed inside of HEP. We hope to offer our users unified access to most of them. Where we feel that some component is missing, we will initiate development or develop it ourselves. At present, we are working on following components:

3. Design(14)

Graphics is one of the domains inside Atlas software. The central part of the Graphics in Atlas is Graphics Control subdomain, which defines interfaces between Graphics packages, and the rest of the Atlas software (whole Arve).

3.1. Component

 Each graphical package used in Atlas software represents one component inside Graphics domain. It has standard interface both to the controlling part of the Graphics and to the rest of Atlas software.

Any object, which is to be plottable (Plottable object), should offer its graphical information via PlottableModel to the graphical system. PlottableModel carries general graphical informations and methods, not suited to any particular graphical package. Each kind of graphical package (possibly external) is represented by its AbstractScene object providing connection to the graphical renderer itself. For each combination of Plottable (and PlottableModel) and AbstractScene specific object PlottableRepresentant should exist. PlottableRepresentant implements specific behavior used by concerned AbstractScene. The generation of PlottableRepresentant is to high level automatized. If one is able to construct new PlottableModel from existing PlottableModels , new PlottableRepresentants is created automatically without the need of defining new C++ class.

4. Atlas Software Design(15)

The position of the Graphics domain in the Atlas software design is defined by the requirement that any graphics should be seen as a kind of User Interface. This requirements also defines the relationship between Graphics and Control domain.

4.1. Control(16)

Atlas is at present evaluating the possible use of the Components Based Framework for the central Control structure. Design of the Graphics system is well compatible with such approach - "AbstractScenes" would become modules inside framework.

4.2. Object Browser

The general access to objects in OO database will be performed by the Objects Browser. It will allow access to both objects (like files inside file manager) and collections (like directories in file manager). All AbstractScenes available for each object will be available for displaying. Public object features will be accessible through standard (default) AbstractScene, which will allow displaying of every object.

5. Problems

We have already encountered several problems with current design, mostly associated with its generality:

5.1. Packages availability and interoperability

It is not possible to have every package available on every supported platform (and operating system) with the same compiler and all other necessary libraries.  We shall develop system which would automatically select packages available in actual configuration. This should be done on the level of package handling mechanism as well as by defining coding rules.

5.2. Packages philosophy

Some more complex graphical packages offer usage philosophy hardly compatible with our chosen design. They quite often try to define the whole visualization environment making their incorporation into our environment complicated task. In that cases, we will introduce bridges making external package conformant with our design.

6. Status

The main other domains of the Atlas software, on which Graphics domain depends, are Control and Database. The Control domain is needed to put Graphics into overall environment, the first (pre)version is expected to be available in the first quarter of this year. The Database domain will serve data to be shown on Graphics. Currently, big amount of data generated with Geant3 and stored in traditional Zebra structure exist and they will be made available to the C++ world soon. The new, first Geant4(17) based generation of the data, is expected later this year.

First version of the User requirements of Design of the Graphics system has passed the external Review last year. Basic infrastructure of the Graphics with limited functionality already exists and will be submitted for code Review soon. Also several AbstractScenes already exist, others are worked on. Only examples of PlottablModels exist so far. The alpha version of the graphics domain is planed for the middle of this year.

References

  1. Atlas: http://atlasinfo.cern.ch/Atlas/Welcome.html
  2. Aravis: http://wwwcn.cern.ch/~burnett/arve/event.htm
  3. Arve: http://wwwcn.cern.ch/~burnett/arve/
  4. Atlantis:
  5. Dali: http://alephwww.cern.ch/DALI/
  6. HEPVis:
  7. VRWave: http://www2.iicm.edu/vrwave
  8. VRWeb: http://www2.iicm.edu/Cvrweb
  9. LHC++:
  10. HEP-Explorer: http://wwwinfo.cern.ch/asd/lhc++/IEtraining/program.html
  11. Root:
  12. Paw: http://wwwinfo.cern.ch/asd/paw/index.html
  13. Atlas Graphics Design:
  14. Atlas Software Design: http://www.cern.ch/Atlas/GROUPS/SOFTWARE/OO/
  15. Atlas Control Design: http://hepunx.rl.ac.uk/atlas/control/
  16. Geant4: http://asdwww.cern.ch/pl/geant/geant4.html