1. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 1 Future Plans for the LCD WIRED Event Display Joseph Perl SLAC Computing Services perl@slac.stanford.edu

2. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 2 Contents The larger context of WIRED Introduction to HepRep HepRep Current and Future Architecture Evolution from JAS 2 + WIRED 1.x to JAS 3 + WIRED 4 Features to come in WIRED 4 Demonstrations –WIRED HepRep from: BaBar Offline and Online via Corba GLAST via XML Geant4 via XML –FRED HepRep from: GLAST via XML Geant4 via XML

3. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 3 Larger Context of WIRED LCD in JAS3 GLAST BaBar Offline Geant4 Geant4 Web BaBar Offline BaBar Online

4. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 4 Limitations of Early WIRED Versions (from Mark’s talk this morning) One WIRED Plot per Page No Save and Restore No Picking Info No easy way to extend WIRED Memory Consumption In response to these same issues in BaBar WIRED, we developed HepRep. This also gave us an entirely experiment independent form of WIRED.

5. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 5 The Client-Server Paradigm Server deals with physics, interaction with reconstruction algorithms, with our data store files etc etc Client deals only with graphics representations (that may be augmented with additional information that has meaning for the experiment) Client-server does not necessarily imply remote operation. Client and server may be on the same machine or may be on different machines. The client-server separation is in any case a useful construct to cleanly delineate the two parts of the event display solution Client and server communicate with an interface; the crucial point is that this interface should be simple, extensible and should accommodate all the needs seen before HepRep is such an interface: “A Generic Interface for Component or Client-Server Event Displays” provides for the correct distribution of computing work between the two parts of the system and effectively addresses the many important maintenance issues involved in such a system

6. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 6 The HepRep interface breaks the dependency between any particular experiment's event display server and any particular event display client. The HepRep format is independent of any one particular language or protocol. It can be used from C++ or Java and can be shipped as Corba, RMI, XML, C++, Java or JNI for consumption by WIRED, FRED or any other HepRep-enabled event display client. HepRep WIRED Client (Java) Other HepRep Clients BaBar Server LCD Interface GLAST Server Geant4 Server FRED Client (C++/Ruby) HepRep Purpose

7. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 7 HepRep is to Event Displays as AIDA is to Analysis Both interfaces came out of a desire to cleanly separate the desktop tool from the data source. Use well defined interfaces to facilitate a flexible, component architecture. Abstract interfaces that can be implemented in a variety of languages. WIRED Visualization HepRep JAS Data Analysis AIDA Abstract Interfaces BaBar, GLAST, LCD, Geant4 IceCube, CLEO

8. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 8 The “Rep” in HepRep means Representables If one just ships references to the underlying physics objects, there are too many time-consuming callbacks, asking one by one for the points on the tracks, etc. One doesn’t achieve good separation of client-server functionality. The design decision behind HepRep is to serve Representables, not Physics Objects. –A Representable is the Essential Spatial Information of a Physics Object (track, calorimeter hit, etc.) and can be augmented by that object’s Physics Attributes (momentum, energy, etc.). –Serving Representables keeps the detailed reconstruction code, swimmers and detector models on the server side where they belong. Spatial information is assembled and shipped in an efficient manner, avoiding the overhead of too many individual method calls. –Rendering decisions are deferred, as much as possible, to the client.

9. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 9 Example HepRep Representable A precise fitted track could be served as a set of swim step points, each augmented by helix parameters and descriptive information (track number, particle id, etc.). Only in the client is the final decision made whether to Represent this Representable as a dotted line, or as set of individual swim step momentum vectors, or as a set of helix segments. Physics ObjectRepresentable Representation Fitted Track Track Number Particle ID Points(n) Helix Params(n) Track Number: 1 Particle ID: e- Pt 1 Params Pt 2 Params Pt 3 Params Pt 4 Params OR OR…

10. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 10 Example HepRep Object Tree linked by name to Type Track Type Track Instance of Track AttDefs AttVals TypeTree InstanceTree HepRep Type Cluster AttDefs AttVals Points AttVals Points AttVals Track 1Track 2 Type Event AttDefsAttVals Type HitOnTrack AttDefsAttVals GLAST Event multiHad/xxx GLAST Event Types version 1.4 Flexible scheme for incremental download. Client can ask to: include or exclude Attributes only get Instances of a given Type only get Instances that have given Attributes and other options

11. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 11 The HepRep Interface

12. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 12 HepRep Attributes Any number of Attributes can be hung from a Type, Instance or Point. There are four Categories of Attributes: Draw Attributes (such as thickness, color and what shape to draw from the points) can be modified in the client through a draw attribute editor Physics Attributes (such as track momentum or hit error) can be used for visibility cuts (client side or server side) PickAction Attributes define special things to do when the user picks on the Representable (such as remove hit and refit track) Association Attributes define loose associations between Representables (such as track cluster matching) * * 1 1 1 HepRep Instance HepRep Type Linked by TypeName TypeName: String X,Y,Z: Double HepRep Point * * 1 1 HepRep AttDef Name: String Desc: String Category: String Extra: String * Name: String Desc: String InfoURL: String HepRep AttValue AttDefName: String Value: Any ShowLabel: Int Linked by AttDef Name

13. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 13 HepRep Current Use Architecture While all four experiments are now using WIRED, and two can use FRED, they use a variety of HepRep and legacy implementations: BaBar has a HepRep1 Corba server, dependent on BaBar code. LCD passes WIRED java objects using a legacy data format (pre-HepRep). Geant4 has abstract HepRep1 and HepRep2 implementations to XML and Java. GLAST has an abstract HepRep2 implementation to XML and Corba. HepRep1 HepRep2 +legacy data formats LCD (java) Javalegacy format WIRED 3 (Java) XML HepRep2 FRED (C++/Ruby) GLAST (c++) HepRep2 BaBar (c++) CorbaHepRep1 Geant4 (c++) XMLHepRep1 Corba RMI Java XML Corba XML Corba LCD Application GLAST XML/Corba Streamer BaBar Corba Server Geant4 XML Streamer / Java Builder HepRep2 Java XML

14. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 14 HepRep Near-Term Future Architecture HepRep2 LCD (java) XML HepRep2 GLAST (c++) HepRep2 BaBar (c++) Corba Geant4 (c++) Corba RMI Java XML Corba XML C++ C++ Shared HepRep Factory Java All data sources speak HepRep2 to an abstract HepRep factory (from FreeHEP). By instantiation of one or another concrete implementation of HepRep: a C++ program can change from creating HepRep in C++ memory to creating HepRep as an XML streamer (a pure C++ solution with no external library dependencies and no creation of the HepRep in memory) to creating HepRep as Corba streamer (depends on Corba libraries) or creating HepRep as Java (via Java Native Interface) HepRep2 Corba XML Java RMI IceCube (java) Java Shared HepRep Factory WIRED 3 (Java) FRED (C++/Ruby)

15. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 15 Evolution from JAS 2 + Wired 1.x to JAS 3 + Wired 4 Generic Wired 3.x Application BaBarCorbaHepRep1 Geant4XMLHepRep1&2 GLASTXMLHepRep2 LCDJavaNot HepRep JAS 2 LCD Wired 1.x JAS plug-in Up to Last Week Generic Wired 3.11 Application BaBarCorbaHepRep1 Geant4XMLHepRep1&2 GLASTXMLHepRep2 LCDJavaNot HepRep JAS 3 LCD Wired 3.11 JAS plug-in Today JAS 3 BaBar XML, JNI & Corba HepRep2 Geant4 XML, JNI & Corba HepRep2 GLAST XML, JNI & Corba HepRep2 Generic Wired 4 JAS plug-in Eventual Goal LCD Java, XML & RMI HepRep2 Soon Generic Wired 3.x Application BaBarCorbaHepRep1&2 Geant4XMLHepRep1&2 GLAST XML & Corba HepRep2 LCDJavaHepRep2 JAS 3 LCD Wired 3.x JAS plug-in Generic Wired 3.x JAS plug-in Generic Wired 4 JAS plug-in Got all experiments onto same WIRED base version. Many new features for LCD. Get all experiments onto HepRep. Allows attribute picking for LCD. WIRED 4 has HepRep2 as its backbone. Allows us to exploit the full capabilities of HepRep Babar, Geant4 and GLAST users can switch from WIRED 3 to 4 whenever they choose, since either WIRED can handle HepRep2

16. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 16 Features to Come in WIRED 4 Because Wired 4 will use HepRep2 as its backbone, many advanced features anticipated in the HepRep2 design will become possible: Provide a tabular “text” view of the event, showing all attributes and making all attributes editable. Allow easy save and restore of user preferences for attribute settings for any particular HepRep Type. Support interactive cuts on attributes. Allow graphics objects to be labelled with any one or more of their HepRep attributes (e.g., PT=0.4, PID=electron). Use association attributes to do things like: “highlight the calorimetry data associated with the selected track” or color all tracks by particle ID in one view and color them by energy in another view. Wired will pick up various convenient features from JAS 3: Save and restore current configuration such as number, position and orientation of graphics windows. All text entered into input areas of dialog boxes becomes part of pull down menu of options for rest of that session and future sessions JAS 3 BaBar XML, JNI & Corba HepRep2 Geant4 XML, JNI & Corba HepRep2 GLAST XML, JNI & Corba HepRep2 Generic Wired 4 JAS plug-in Eventual Goal LCD Java, XML & RMI HepRep2

17. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 17 Demonstrations WIRED –a HepRep client written in Java based on FreeHEP Full-featured Runs in JAS or as separate app Demos –HepRep from BaBar offline and online via Corba –HepRep from Geant4 and GLAST via XML –HepRep from Geant4 via JNI FRED –a Heprep client written in C++/Ruby based on the Fox toolkit Less features than WIRED, but could be extended Limited functionality, but does include scripting Demo –HepRep from GLAST and Geant4 via XML

18. LCD WIRED FutureLCD Workshop May 19-22 2003 Joseph Perl 18 References HepRep: a generic interface definition for HEP event display representables http://heprep.freehep.org http://heprep.freehep.org HepRep Complete Presentation (most complete description of HepRep) http://heprep.freehep.org/heprep2.Complete.ppt http://heprep.freehep.org/heprep2.Complete.pdf http://heprep.freehep.org/heprep2.Complete.ppt http://heprep.freehep.org/heprep2.Complete.pdf Fred: oh no, another event display (a HepRep client) http://www.fisica.uniud.it/~riccardo/research/fred http://www.fisica.uniud.it/~riccardo/research/fred WIRED: world wide web interactive remote event display (a HepRep Client) http://www.slac.stanford.edu/BFROOT/www/Computing/Graphics/Wired http://www.slac.stanford.edu/BFROOT/www/Computing/Graphics/Wired SLAC HepRep WIRED Work Plan http://www.slac.stanford.edu/~perl/wired http://www.slac.stanford.edu/~perl/wired A Component Approach to HEP Event Displays http://www.slac.stanford.edu/~perl/component http://www.slac.stanford.edu/~perl/component Requirements for a New BaBar Event Display (most parts apply to any exp) http://www-sldnt.slac.stanford.edu/hepvis/paper/paper.asp?id=37 http://www-sldnt.slac.stanford.edu/hepvis/paper/paper.asp?id=37 The FreeHEP Java Library http://java.freehep.org http://java.freehep.org