Requirements

Requirements for a New BaBar Event Display: 

Requirements for a New BaBar Event Display Joseph Perl, David Brown, Serge Du, Anne-Marie Lutz HEPVis 98 28 January 1998

Introduction: 

Introduction 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. 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:

Introduction: 

Introduction 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 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: 

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)

Requirements:BaBar Compatible: 

Requirements: BaBar Compatible 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

Requirements:Interactive: 

Requirements: Interactive 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

Requirements:Interactive: 

Requirements: Interactive 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)

Requirements:Fast: 

Requirements: Fast 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)

Requirements:User Friendly: 

Requirements: User Friendly 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

Requirements:User Friendly: 

Requirements: User Friendly 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

Requirements:Scalable, Extensible, Maintainable: 

Requirements: Scalable, Extensible, Maintainable 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)

Requirements:Scalable, Extensible, Maintainable: 

Requirements: Scalable, Extensible, Maintainable 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

Requirements:Many Views: 

Requirements: Many Views Support many different kinds of representations (such as 3D, 2D, fish eye, vee plot, tabular display, decay chain, etc.). Treat the real-world 3D view as just one option among many. Support multiple, well correlated views of one or more different events (show which feature in one view matches which feature in another view through such means as correlated highlighting) Show overall event information (such as event number, time stamp, etc.) Let the user to annotate views with text, lines, arrows, circles, etc. Let the user select different reference frames on-the-fly (such as laboratory, experiment Center of Momentum, other COMs) Support drawing of wire frames and area fills on any output device Allow future inclusion of more elaborate drawing systems (such as hidden line removal, transparent volumes, lighting models) Display magnetic and electric fields in addition to detector data and detector geometry?

Requirements:Different Kinds of Users: 

Requirements: Different Kinds of Users Be useful for the BaBar online as well as the offline, interactive as well as batch Support web distribution of interesting events for education and public relations Support kiosk-mode displays (e.g., a display at a museum of “the latest events from your local accelerator”) providing at least low level interactivity while insulating against malicious activity Provide high quality hard copy for papers, posters, etc. with the hard copy match the online image as closely as possible. Output formats must at least include PostScript plus one of either GIF or JPEG. Perhaps support PDF output. Support one of the 3D output formats (such as VRML WRL)

Conclusion: 

Conclusion 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?

References: 

References ATLAS Event Display Requirements J.Hrivnac ATLAS Internal Document, 1997 http://www.cern.ch/Atlas/GROUPS/GRAPHICS/Texts/EventDisplay/Requirements/ BaBar OPACS Early Design Notes David Brown, Serge Du, Anne-Marie Lutz, David Quarrie BaBar Internal Documents, 1996 http://www.physics.louisville.edu/www/public/faculty/hep/evtdisp1.html http://babar-hn.slac.stanford.edu:5090/HyperNews/get/graphics/10.html 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 http://preprints.cern.ch/yellowrep/1997/97-01/Chapter08.pdf http://www.phys.ufl.edu/~hepvis/version0_4/cleo3dHelp/cleo3d_help_overview.html http://www.phys.ufl.edu/~hepvis/cleo3d.html http://www.phys.ufl.edu/~hepvis/Spectator.html

References: 

References 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) http://fnpspa.fnal.gov/workshop/talks/drevermann1/page1.html Event Display for the CMS Experiment Lucas Taylor Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996 http://preprints.cern.ch/yellowrep/1997/97-01/Chapter10.pdf Event Visualization in High Energy Physics (LHC) Howard Stone Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996 http://preprints.cern.ch/yellowrep/1997/97-01/Chapter04.pdf

References: 

References Event Visualisation Tools at LEP David McNally Proceedings of the HEPVis 96 Workshop, CERN, Geneva, Switzerland, Sep 1996 http://preprints.cern.ch/yellowrep/1997/97-01/Chapter05.pdf 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 http://cactus.phyast.pitt.edu/~joe/hepvis/hepvis.ps 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 http://fnpspa.fnal.gov/workshop/talks/drevermann2/index.html

References: 

References Towards Future HEP Event Displays Joseph Perl Presented at the HEPVis 95 Workshop, Fermilab, Batavia, IL, U.S.A, Aug 1995 http://www-sld.slac.stanford.edu/sldwww/hepvis95/hepvis.html WIRED Event Display Requirements M. Dönszelmann and P. Gunnarsson WIRED Internal Document, IRED-URD-DRAFT-0.2, 1996 http://iptnt.cern.ch/public/WIRED/design/URD/html/URD_1.html 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 http://www.hep.net/conferences/chep95/html/abstract/abs_52.htm