1 / 18

Future Plans for the LCD WIRED Event Display

Future Plans for the LCD WIRED Event Display. Joseph Perl SLAC Computing Services perl@slac.stanford.edu. 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

finna
Download Presentation

Future Plans for the LCD WIRED Event Display

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Future Plans for the LCD WIRED Event Display Joseph Perl SLAC Computing Services perl@slac.stanford.edu

  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 in JAS3 BaBar Offline BaBar Online Geant4 GLAST Geant4 Web Larger Context of WIRED BaBar Offline

  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. 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. HepRep Purpose BaBar Server WIRED Client (Java) GLAST Server FRED Client (C++/Ruby) HepRep LCDInterface Other HepRep Clients Geant4Server 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.

  7. Visualization Data Analysis AIDA HepRep JAS WIRED 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. BaBar, GLAST, LCD, Geant4 Abstract Interfaces IceCube, CLEO

  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. 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 Object Representable Representation Track Number: 1Particle ID: e- FittedTrack OR Track NumberParticle IDPoints(n)Helix Params(n) Pt 2 Params Pt 3 Params Pt 1 Params Pt 4 Params OR OR…

  10. Example HepRep Object Tree HepRep GLAST Event multiHad/xxx GLAST Event Types version 1.4 InstanceTree TypeTree Track 1 Track 2 TypeEvent Instance of Track Instance of Track linked by name to Type Track linked by name to Type Track Points Points AttVals AttVals AttDefs AttVals Type Track Type Cluster AttVals AttVals AttDefs AttVals AttVals AttDefs 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 Type HitOnTrack AttDefs AttVals

  11. The HepRep Interface

  12. HepRep Attributes * Any number of Attributes can be hungfrom 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 HepRepType HepRepInstance Name: StringDesc: StringInfoURL: String TypeName: String Linked by TypeName 1 * HepRepPoint 1 X,Y,Z: Double 1 Linked by AttDefName * * HepRepAttValue HepRepAttDef AttDefName: StringValue: AnyShowLabel: Int Name: StringDesc: StringCategory: StringExtra: String

  13. HepRep Current Use Architecture BaBar(c++) BaBar Corba Server HepRep1 Corba RMI HepRep1HepRep2+legacydata formats Java LCD(java) LCD Application legacy format Java WIRED 3 (Java) Corba HepRep1 XML Geant4 XML Streamer / Java Builder Geant4(c++) XML Java HepRep2 XML GLAST XML/Corba Streamer XML XML GLAST(c++) HepRep2 FRED(C++/Ruby) HepRep2 Corba Corba 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.

  14. HepRep Near-Term Future Architecture RMI LCD(java) Java Shared HepRep Factory HepRep2 Java RMI Corba IceCube(java) Java WIRED 3 (Java) XML HepRep2 Corba XML BaBar(c++) Java C++ Shared HepRep Factory Corba Geant4(c++) HepRep2 XML Corba FRED(C++/Ruby) HepRep2 GLAST(c++) C++ XML 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)

  15. Evolution from JAS 2 + Wired 1.x to JAS 3 + Wired 4 Up to Last Week JAS 2 BaBar Corba HepRep1 Generic Wired 3.x Application LCD Wired 1.x JAS plug-in Geant4 XML HepRep1&2 LCD Java Not HepRep GLAST XML HepRep2 Today JAS 3 BaBar Corba HepRep1 Generic Wired 3.11 Application LCD Wired 3.11 JAS plug-in Geant4 XML HepRep1&2 LCD Java Not HepRep GLAST XML HepRep2 Soon JAS 3 BaBar Corba HepRep1&2 Generic Wired 3.x Application LCD Wired 3.x JAS plug-in Geant4 XML HepRep1&2 LCD Java HepRep2 XML & Corba GLAST HepRep2 XML, JNI & Corba Eventual Goal BaBar HepRep2 JAS 3 XML, JNI & Corba Geant4 HepRep2 Generic Wired 4 JAS plug-in XML, JNI & Corba GLAST HepRep2 Java, XML & RMI LCD HepRep2 Got all experiments onto same WIRED base version. Many new features for LCD. Get all experiments onto HepRep. Allows attribute picking for LCD. Generic Wired 3.x JAS plug-in Generic Wired 4 JAS plug-in 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. Features to Come in WIRED 4 XML, JNI & Corba Eventual Goal BaBar HepRep2 JAS 3 XML, JNI & Corba Geant4 HepRep2 Generic Wired 4 JAS plug-in XML, JNI & Corba GLAST HepRep2 Java, XML & RMI LCD HepRep2 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

  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. References • HepRep: a generic interface definition for HEP event display representableshttp://heprep.freehep.org • HepRep Complete Presentation (most complete description of HepRep)http://heprep.freehep.org/heprep2.Complete.ppthttp://heprep.freehep.org/heprep2.Complete.pdf • Fred: oh no, another event display (a HepRep client)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 • SLAC HepRep WIRED Work Planhttp://www.slac.stanford.edu/~perl/wired • A Component Approach to HEP Event Displayshttp://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 • The FreeHEP Java Libraryhttp://java.freehep.org

More Related