BaBar Graphics: An Architecture to Ride on Other Visualization Systems

David N. Brown

Department of Physics, University of Louisville, Louisville, KY, USA 40292

Serge Du

Laboratoire de L'accelerateur Lineaire, Universite Paris-Sud, 91405 Orsay, France

Joseph Perl

Stanford Linear Accelerator Center, Stanford, CA 94309

Abstract

We discuss the development history, current status, and future plans of the BaBar Graphics system. The system has evolved through specific immediate needs-based goals and response to user feedback. At all stages the design has been aimed at producing a system which allows flexible interaction with BaBar data simultaneously with flexible choice of underlying graphics - allowing us to use freely available graphics libraries to this point in the development. We support the development of a global standard for HEP display models and offer some thoughts on incorporating this standard into various graphics delivery modes.

1. Introduction to BaBar Graphics, Terminology, and the Physics at BaBar

BaBar Graphics refers to a collection of software packages which allow users to produce interactive 3D graphical representations of data and detector elements. The packages produce default Event Display executables based on a basic set of data reconstruction modules with each BaBar software release (approximately every 2 weeks). The graphics modules can also be incorporated by users into their own event-driven programs, to serve as a display for events before and/or after modification. It is also possible to build standalone graphical programs which are not event-related.

All module names in the BaBar Graphics packages include the three-letter code Gra. Many module names also refer to specific BaBar detector elements. These elements also receive 3-letter abbreviations, which are often referred to in a group as Xxx. These elements are introduced here along with a brief discussion of the physics at BaBar to produce a backdrop for the discussion of goals, design, and development.

Dch is the 40-layer cylindrical Drift Chamber operating with Helium-Isobutane in a 1.5 T magnetic field.

Drc is the Detector for Internally Reflected Cerenkov light (DIRC), a barrel-like array of quartz tubes extending the length of the detector and providing particle identification through measurement of Cerenkov angle.

Emc is the Electromagnetic Calorimeter, an array of Cesium Iodide crystals doped with Thallium.

Ifr is the Instrumented Flux Return, used for muon detection.

Svt is the Silicon Vertex Tracker, a near-vertex silicon strip array for precise vertex detection.

Trk refers to the Tracking system, which is not actually a detector system, but rather the collected software for building tracks, especially from the Dch and Svt.

The detector and associated software are still in the construction stage, preparing for data-taking beginning in early 1999. The PEP-II ring at SLAC will provide high-luminosity beams of 9 GeV electrons colliding head-on with 3.1 GeV positrons at the BaBar Interaction Region. BaBar will seek mainly CP-violation physics in the system. The asymmetric beams present a novel experimental technique for directly measuring the time dependence of mixing of the lowest mass open beauty mesons, thus making precise determinations of Standard Model CP-violation parameters. The beam asymmetry makes no intrinsic difference for graphics - the lab system asymmetry can be represented easily in a three-dimensional display. Potential trouble arises as physicists begin to perform analyses and wish to view event topology in the Center-of-Momentum frame or the reference frame of one of the mother particles in the event. This is not serious trouble, however, as one easily introduces transforms on data elements and eliminates detector elements from such pictures.

2. A Brief History of BaBar Graphics

BaBar Graphics received an official launch in December 1995 when David Quarrie set up packages which paralleled OpenInventor structure. The packages were:

The parallels between OpenInventor and the BaBar Graphics packages were designed to allow easy adaptation to OpenInventor by those who chose to support this expensive visualization system, while the independence of the Gra packages assured the ability to adapt to other visualization systems.

2.1 Initial Goals and the Effects Upon Development

The initial goals for the BaBar Graphics system were simple and heavily coupled to the needs of offline (reconstruction) software developers. Though it has always been clear that the system should be extensible to a variety of uses, the reconstruction needs have continuously driven the implementation. The initial goals and guidlines for BaBar Graphics include the following:

2.2 The BaBar Graphics Timeline

Here is a brief rundown of the timeline of developments in BaBar Graphics to date:

 (1)

2.3 User Survey and What was Learned

In March of 1997, BaBar software package coordinators were surveyed for feedback and input on the BaBar Graphics Event Display. The survey is listed here:

Graphics Survey for Package Coordinators.

Name: ______________________________

Package/System: _____________________________________

  1.  Do you have a visual display system/visual debugging tool which is 
      already used by you/your group?


      IF YES:
        Is it located in the standard BaBar release structure, and if so,
        where?



        Who has been most responsible for its development?



      IF  NO:
        Would such a tool be helpful to you?  (If your answer is no, 
	please consider the rest of the survey optional, but please 
	DO return the survey so that we know.  Thanks!!)



  2.  Is it helpful to provide a set of graphical tools so that your 
      group can build a graphical display to its own liking?




  3.  Is it preferable to have a single "canvas" onto which pictures 
      can be pasted, moved, labeled, such as in a MacDraw drawing,... 
      or to maintain single picture per window ability as currently 
      exists.




  4.  Would you like to be able to save a display in a format such 
      that you can call it back later for manipulation?




  5.  Please list graphics features which you would find 
      particularly useful for your group.  (i.e. what do you want 
      to be able to do with it?)



 
  6. The present Graphics package allows for a debugging mode, 
     when the graphics module is called at user-defined breakpoints 
     in other modules (eg, reconstruction) code. Will you use 
     this facility ? In what context ? 



  7.  The present display represents detectors and events in space 
        coordinates. Will you need/wish/suggest other 
	representations, like 
        - lego plots (which coordinates ?), 
        - non-linear space representations, 
        - momentum space representations,
        - special 2-D projections 
        - any other ? 
 
       
        (Please, be accurate in the description of your needs, 
	and in their degree of urgency) 

    8.  Will you need to represent errors ? Which kind : 
        spatial ? energy ?

    
    9.  Which geometrical shapes will you need to represent ? 

    
   10.  The present display uses the physicalOutline method 
        of DetectorModel. 
        Is the geometry of your detector already described in 
	that framework ?
        If NOT, will it be soon ? 
        If NOT, is it a feature ?
    

   11.  Is it preferable to have volumes represented as 
        - outlines 
        - surfaces 
        - opaque surfaces ?

We were fortunate to receive a large number of very specific replys which suggested various desirable features, particularly in terms of useful representations and projections. The two biggest lessons from the survey were not graphics-specific but more general:

3. Current Design of BaBar Graphics

The BaBar Graphics goals list has changed from its original form, reflecting a move away from the idea of Just producing a quick offline debugging tool to a more global idea of creating a general BaBar graphics system. Here is the number one goal which drove the current design of the system:

Modularity! In moving toward a more global system, we have aimed at making the system more modular, separating packages by more well-defined tasks. We have separated code by:

The structure of the packages are represented in the two following diagrams. Figure (2) shows the layering of functioning, with lines indicating approximate layers of dependency, the top (GraDisplay and the detector-specific XxxGra packages) being most dependent. Figure (3) shows the Specific dependencies, for the detector-specific packages and their link into the more general GraDisplayApp.

 (2)

 (3)

This system functions on multiple platforms and displays both locally and via network. Users are capable of using the system and adding their own class representations to it. We are currently addressing performance issues and issues of user interface.

4. Future Directions of BaBar Graphics

Rather than a statement of what will be done, we proceed as we have in the past, with a list of goals, but we present here a much more detailed list than we have included in the history and current status sections. This list is intended to include everything we would like to have in the new BaBar Event Display. We include items here whether or not we absolutely must have it early in the detector checkout. Note that some of our current goals carry over into the future goals list.

With the exception of the first few items, most of these requirements seem as though they might apply to any HEP Event Display. BaBar can therefore make wonderful use of this HEPVis 98 to ask all of you assembled experts three questions:

  1. Are there other requirements that BaBar should include in its document?
  2. Does a system exist that can meet all of these requirements?
  3. If not, are there components we can share with others to meet these requirements?

The following list is too long to discuss in the talk accompanying this paper, so I will just hit on a few points in the talk; all the points are listed here for completeness. But we would very much appreciate feedback from any of you in the coming few days or weeks.

The New BaBar Event Display System Must Be Able To:

BABAR COMPATIBLE:

INTERACTIVE:

FAST:

USER FRIENDLY:

SCALABLE, EXTENSIBLE, MAINTAINABLE:

MANY VIEWS:

DIFFERENT KINDS OF USERS:

The BaBar Graphics group looks forward to providing a system which meets most or all of these goals and proves a useful tool for BaBar's software AND hardware groups and for those doing Physics analyses with BaBar. Furthermore, we look forward to a useful interchange of ideas with the global High Energy Physics community.

Acknowledgements

The authors must acknowledge the many contributors who have helped bring the system to its feet. David Quarrie of Lawrence Berkely Lab (LBL) wrote the original design and coded the skeletons of many of the base classes used in the BaBar Graphics packages. Anne-Marie Lutz of Orsay has managed the detector-specific package for the DIRC detector, has helped with the User Survey, and has taken a strong role in defining goals for the system. Annalina Vitelli of Frascati/LBL added a monumental amount of code in helping to create and develop the detector-specific graphics packages. Zhitang YU of Frascati has taken charge of the detector-specific package for the IFR detector and continues to manage that package admirably. Gerry Lynch of LBL and Stephen Schaffner of SLAC/Princeton have provided helpful feedback. Guy Barrand of Orsay has been very helpful in our implementation of opacs as a base visualization package. Without Bob Jacobsen, BaBar reconstruction software would not be in as good shape as it is today.

References