Event Display - Document 1

Items for Event Display

Here are my thoughts on items for consideration by the BaBar Event Display group. I have marked with asterisks the items I consider to be of the greatest priority. I have also included my personal opinion on certain of the items.

1. User Interface ***
   • Window Layout
   • Menu/Button/Pop-up or text-based control? (DNB suggest: Menu/Button/Pop-up control)
   • Click on graphics options (zoom, rotate, etc.)? (DNB suggest: Yes, but not top priority)
   • Is there a different version for common user, "super" user, on-line (is there on-line?)?? (DNB suggest: No)
   • Allow user to choose reference frame for display (not all imply a meaningful difference in all views)
     • Laboratory frame - default
     • Experiment COM frame
     • COM frame as defined by 2 or more tracks (needs particle ID assignments)
     • COM frame as defined by a specified 3-vector
   • Can we quickly and simply write code for a window with pop-up menus, entry boxes, and pushbuttons as an existence test? (DNB suggest: Should be easy - I'd like to try ASAP).
2. Display Items***
   • Is the package strictly standard Event Display - pictorial representation of real 3-space signals associated with a single event; or is it a more general tool for visualization??
   • Make list of things to display
     • Ifr
     • vtx- outline,hits
     • dch- outline, hits
     • tracks- with or w/o associated hits
     • Drc - outline, how to represent hits?
     • Emc - outline, showers represented as at CLEO?
     • Muon - outline, hits.
     • magnet coil - show outline?
     • More!
   • Allow different views
     • Plan
     • Elevation
     • End-on
     • 3-d, variable viewing angles.
     • Rapidity?
     • More??
   • Default list of items to display? (DNB suggest: yes - end view of Dch, Ecm, Ifr, vtx, tracks)
   • Use color as an integral part of the package? (i.e. more than just dressing?)
3. Graphics Class Libraries**
   • Which Graphics Class Libraries to use?
     • OPACS - GraKit? (Lot of work has gone in - is it where it needs to be?)
     • vtk? (Can be done absolutely free - I have it at U of L)
     • OpenGL, OpenInventor? (costly.)
   • Can we write EvtDisp code with maximum flexibility wrt user's choice of GCL?
   • Do we make our efforts into something like HepVisB - an extension of Joe Boudreau's HepVis project?
4. File Handling**
   • What kinds of files will be handled - Ntuples, database, HBOOK?, PS? ??
   • Do we use file extensions to recognize allowed filetypes, or do we look in files to decide?
5. Geometry Specification**
   • Separately specify outlines and details of detector geometry?
   • Do we integrate separate geometry specifications for each detector into a single geometry repository?
   • Do we create a geometry database with run-dependent on/off's for detector elements?
   • Do we want to create a single geometry specification for use by simulation, reconstruction, and EvtDisp?
6. Special Features
   • Selecting individual hits and refitting tracks, etc.
   • More!?
7. Error Handling
   • Special code for trapping exceptions in a non-traumatic way?
8. Coding
   • Standards/C++
   • Who is responsible for which parts of the code?
9. Testing
   • Who is responsible for assuring multi-platform operation?
   • Who tests that EvtDisp works over a network?