Joseph Perl

David N. Brown

Serge Du

Anne-Marie Lutz

BaBar is in the process of specifying a new Event Display. Because most of the requirements for such as system might apply to any new HEP Event Display, the BaBar graphics group has three questions to ask the experts assembled at HEPVis 98.

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

The following requirements list is intended to include everything we would like to have in a new BaBar Event Display. We include items here whether or not absolutely must have them early in the detector checkout.

The following list is too long to discuss in detail today, so I will just hit on a few points. But we would very much appreciate feedback from any of you in the coming few days or weeks.

Requirements: BaBar Compatible

• Interact with analysis code running on any of the four BaBar-supported Unix platforms through a C++ API.
  This API should operate in both directions:
  the event display should be able to get data from the analysis code.
  the analysis code should be able to control the event display (including doing anything that is normally done by through the user interface)
• Allow the user to work from any of the desktops common in BaBar (including desktops in users homes)
  such as Unix workstations, Win NT, Macintosh, Win 95, X-Terminal
• Display all domains known to Geant 4
• Display all domains known to the BaBar Detector Model (BOGUS)
• Restrict public access to specific event data if so required by the collaboration
• Perform error handling in a manner well integrated into overall BaBar framework
• Provide a successful environment for many developers to work in parallel
  consistent with BaBar’s CVS and SRT
• Have acceptable developer and run-time license costs (with the understanding that higher license costs may be acceptable to offset high salary costs)
• Achieve major goals early in the life of BaBar,
  being ready for Drift Chamber cosmic rays in July 1998

• Support low, medium and high level interactivity

• low level interactivity: transform the display
  (zoom, translate, rotate, change coordinate system, control visibility of pieces, change reference frame)
• medium level interactivity: interrogate the display
  (tell the user about the thing they clicked on)
• high level interactivity: drive analysis from the display
  (perform an arbitrary analysis callback based on some action the user takes in the display)

• Allow the user to reassign mouse actions on-the-fly
• Allow the user to change display properties of objects (color, line thickness, etc)
• Allow the user to have displayed objects labeled with user-selected
  non-display information
• Allow the user to graphically represent simple structures that were not present at initialization time (such as displaying a particular space point calculated by them during the session)
• Help with the limitations of the human brain by providing tools to remove clutter on-the-fly such as:

• isolate: show only specified objects of a given class.
• highlight: apply different drawing characteristics to specified objects of a given class.
• cut: only show tracks above a certain momentum, etc.

• Allow the user to perform operations on groups of display objects as well as on single display objects
• Allow the user to specify what object is to be acted on when a given object of a different related class is picked
  (i.e., when I click on a drift chamber hit, I now want to be told about the associated track, which itself may or may not currently be displayed)

• Minimize network traffic
• Perform low level interactivity without additional network traffic
• Avoid retransmission over the network of data which does not change from one event to the next (such as detector geometry)
• Update the display progressively as data arrives
• Pre-load the next event in background while the user studies the current event
• Transmit data that lies on the screen before data that lies off the screen
  (allow option to entirely skip transmitting data that lies off the screen)

• Include a graphical user interface
• Include keyboard equivalents for all GUI commands
• Allow keyboard commands to be assembled into macros (to simplify user input and to allow groups of users to develop their own standard displays)
• Maintain a history file of keyboard equivalent commands
  (so that one can store, edit and replay sessions or parts of sessions)
• Have keyboard command language be hierarchical (to conserve name space and keep things easy to remember as the system scales up)
• Avoid defining an entirely new keyboard language
  (start from an existing language such as tcl, java, etc)
• Avoid providing too many ways to do the same thing (generally support
  just one keyboard command and one GUI command for a given action)
• Have the user able to discern basic functionality without reading a manual
• Include easily-accessible, detailed online help
• Provide lots of feedback for the user, giving every user action some visible result (a visible change to the display or an informational or error message)
• Provide appropriate notice, such as progress bars, for any actions that are expected to take significant time
• Allow the user to control verboseness of feedback
• Support simple and expert user levels
  (so that non-expert users are not distracted by expert-level options)
• Provide defaults to let users to accomplish standard tasks with minimal input
• Optimize mouse actions
• Be easy for users to install and maintain
• Make efficient use of screen space

• Scale well to hundreds of detector system specific modules
• Be prepared to take advantage of new software developments
  (maintain hooks to allow change of underlying graphics package)
• Be prepared to quickly adopt new features developed by other collaborations
  (such as new kinds of representations)
• Be prepared to take advantage of improvements in desktop hardware
  (such as new graphics hardware accelerators)
• Run on both low and high end machines
• Survive failure of any particular detector system module to link, load or run
• Maintain separation between detector hardware description and physics data
• Minimize the user’s need to recompile and/or re-link
  (through such means as shared libraries, dynamic linking, dynamic loading)
• Pipe all input through a consistent single interface
• Have consistent handling of everything in the display window
  (no special handling for axes, or detector geometry, or collaboration logo, etc.)
• Give detector system experts high level tools to write their own modules
  rather than having central event display developers do all the work.
  These tools should include high level graphics objects such as boxes and tracks.
  The detector system experts should be responsible for implementing details specific to their subsystems (e.g., the drift chamber experts need to worry about the lorentz angle). They should not need to know the event display’s internals

BaBar would very much appreciate you input in the next few days or weeks.

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

ATLAS Event Display Requirements

J.Hrivnac

ATLAS Internal Document, 1997

BaBar OPACS Early Design Notes

David Brown, Serge Du, Anne-Marie Lutz, David Quarrie

BaBar Internal Documents, 1996

The Cleo3D Event Display

C.D. Jones, P.R. Avery and D.D. Roscigno

Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996

Event Display, Can We See What We Want to See?

H. Drevermann, D. Kuhn and B.S. Nilsson

Presented at the CERN School of Computing, Arles, France, 1995

CERN/ECP95-25 (1995)

Event Display for the CMS Experiment

Lucas Taylor

Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996

Event Visualization in High Energy Physics (LHC)

Howard Stone

Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996

Event Visualisation Tools at LEP

David McNally

Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996

The Hepvis Class Library for Event Visualization

George Alverson, Amber Boehnlein, Joseph Boudreau,

Xiaoling Fan, Lucas Taylor and Jeff Kallenbach

Proceedings of the CHEP 97 Conference, Berlin, Germany, 1997

Is There a Future for Event Display?

H. Drevermann, D. Kuhn and B.S. Nilsson

Proceedings of the 1992 CERN School of Computing, L’Aquila, Italy, Sep 1992

Towards Future HEP Event Displays

Joseph Perl

Presented at the HEPVis 95 Workshop, Fermilab, Batavia, IL, U.S.A, Aug 1995

WIRED Event Display Requirements

M. Dönszelmann and P. Gunnarsson

WIRED Internal Document, IRED-URD-DRAFT-0.2, 1996

3D Graphics Module for Modeling, Visualization and Analysis

Minato Kawaguti and Satoshi Tanaka

Proceedings of the CHEP 95 Conference, Rio de Janeiro, Brazil, Sep 1995