HEPVis May, 2001 Lassi A. Tuura, Northeastern University Coherent and Non-Invasive Open Analysis Architecture Lassi A. Tuura Northeastern University, Boston

May, 2001 Lassi A. Tuura, Northeastern University 2Overview v Context r The Analysis Environment Challenge r Short-term IGUANA Planning Strategy r Architecture at a Glance r Architecture Background r Objectives v Technicalities r Quick Overview r Illustration: 3D Visualisation r Application Personalities r Browsers and Sites r Putting It All Together r Other Practical Examples

May, 2001 Lassi A. Tuura, Northeastern University 3 The Analysis Environment Challenge v Analysis involves a lot more than just the interactive tool v The “PAW revolution” began closer integration with data r The move continues today with much richer object and access models àThe analysis environments will need considerable links with the rest of the experiment’s computing and software infrastructure (dangerous!) v A great range of user activities with fuzzy boundaries beyond interactive analysis and data presentation Batch, interactive, scripting, setting up applications, frameworks and configuration management tools, data store operations (replicating entire data stores; copying runs, events, event parts between stores; not just copying but also doing something more complicated—filtering, reconstruction, analysis, …), browsing data down to object detail level, 2D and 3D visualisation, moving code across final analysis, reconstruction and triggers, and so on... Today this involves (too) many tools

May, 2001 Lassi A. Tuura, Northeastern University 4 Short-term IGUANA Planning Strategy v CMS has (non-optimal) means to do analysis at the moment: PAW, Lizard, ROOT, JAS v We need more urgently tools we don't have r "De-mystifying" federation management r Ability to view meta-data and make selections based on it r Ability to browse through data sets r Configuring CARF and ORCA r GRID support àMoving to an environment where all these can be offered …while recasting existing functionality into the new form …and integrating full analysis functionality (e.g. Lizard) into the environment at a suitable moment

May, 2001 Lassi A. Tuura, Northeastern University 5 Data Store (Objectivity) File Federation wizards Cmscan Data Browser Analysis job wizards Other Non- IGUANA Tools IGUANA OSCAR ORCA CARF Tony’s scripts Objytools GRIDTools Analysis Architecture At a Glance

May, 2001 Lassi A. Tuura, Northeastern University 6 Architecture Background v Founded on two very basic requirements from Julius Hrivnac:  No one visualisation system is or ever will be “the right one”; the architecture should not be tied to one but cater for many simultaneously  Visualisation should have minimal impact on application object design v Code now in IGUANA v Currently developing a prototype to illustrate the key features and functioning of the architecture, an internal evaluation will follow v Milestone: October

May, 2001 Lassi A. Tuura, Northeastern University 7Objectives  Decouple entities where they do not need to know about each other (  interfaces): r (Re)design freedom r Language migration freedom r Reusing existing code and packages r Dynamically load only what is needed  Integrate many independently useful ways of examining and interacting with data (= "browsers") into one architecture r Browsers should not need to know about each other to communicate or to form a seamless user interface

May, 2001 Lassi A. Tuura, Northeastern University 8Objectives...  Minimise the effort of (  encourage): r Designing a new browser r Presenting an application object in a browser r Making the above two available in applications  Allow the analysis environment to be built of components r Add new features by adding components r Use the same components in many applications r Allow the components to integrate with the application state

May, 2001 Lassi A. Tuura, Northeastern University 9 Quick Overview v Main parts r Tiny kernel r Bunch of plug-ins – Application personalities (drivers) – Application extensions (components) – Browser Sites – Browsers – Browser Models – Representation converters r “Other” shared libraries (in particular application logic and data) iguana  New generic application called iguana r Loads and executes a given personality (“IGUANA” by default) r … or dumps out plug-in database information

May, 2001 Lassi A. Tuura, Northeastern University 10 Illustration: 3D Visualisation

May, 2001 Lassi A. Tuura, Northeastern University 11 Illustration: 3D Visualisation... QMainWindow Browser Site QMDIShell Browser Site QMDIShell Browser Site 3D Browser Twig Browser

May, 2001 Lassi A. Tuura, Northeastern University 12 Illustration: 3D Visualisation... 3D Browser Twig Browser 3D Model Twig Model Object A Object B Twig Rep A Twig Rep B 3D Rep A 3D Rep B AppRepsBrowsers

May, 2001 Lassi A. Tuura, Northeastern University 13 Application Personalities v The personality driver is the “main program” r Defines what to do, running it amounts to running the program r Can choose how much it uses the rest of the IGUANA architecture r Binds with application extensions v Exports common interfaces to application extensions r “Qt main window driver”  access to the menus, tool bars,... r “CARF main driver”  access to CARF actions and notifications,... v The extensions are available to all application personalities r Common wizards (federation operations, GRID tasks,...) r Once written, an extension is available to any personality with the appropriate interface

May, 2001 Lassi A. Tuura, Northeastern University 14 Browsers and Sites v Browsers are created within sites r A collection of Qt sites that export appropriate Qt widgets r Could also be a sub-process channel, Java widget, … r Dynamic site and browser creation from a description (e.g. XML file) v A browser is a way of looking at or interacting with application objects r Uses one or more models r Can be heavy-duty (OpenInventor viewer), or light-weight (tool tip) r Can be abstract and completely hidden from the user interface: object scripting information, hooks to interact with the application,... v Models are made of reps (application object representations) r Reps are not usually the application objects, but objects specific to the model: a SoNode, the list of the object’s properties, text for the tool tip,...

May, 2001 Lassi A. Tuura, Northeastern University 15 Putting It All Together v Highly decoupled system r A browser only knows its model and reps r Application objects know nothing about browsers or reps r No comprehensive list of all combinations r So who knows how to create rep X from object Y? v Solution: runtime binding r Separate definition for every combination r Bindings come from converter plug-ins and are loaded on demand r The framework chooses the most applicable combination based on an efficient matching of the possible candidates r (Technically: a multi-method)

May, 2001 Lassi A. Tuura, Northeastern University 16 Other Practical Examples v Possible candidates for “yet another browser” r Data query interface – Could present the source and result data sets – Would allow to edit the selection/query expression – Attributes that can be queried could be presented as a rep r Command line – Needs scripting bindings for objects—reps? – Can monitor what other browsers do and translate back to script v Automating many CMS-specific tasks r Not much more than a wizard hooked on to the menus and tool bars r Most will require negligible access to application state r …but can benefit tremendously from a common look and feel!

May, 2001 Lassi A. Tuura, Northeastern University 17 The Plug-In Manager v Maintains a list of directories with plug-in definitions v Plug-in = shared library with well-defined entry points v Automatically detects new, changed or removed plug-ins r For new or changed ones loads the plug-in, queries for its capabilities, and unloads the plug-in r Maintains a cache of plug-in properties r Updates the cache if the directory is writable v When requesting information from the database, it uses the cache instead of loading all the plug-ins all the time v A separate generic package; the object browser architecture defines a specific implementation

May, 2001 Lassi A. Tuura, Northeastern University 18Multi-Methods v A virtual function defines a family of functions that is polymorphic on the first argument (the object applied to) void print (virtual Base *, std::ostream &out); void print (virtual Derived *, std::ostream &out); v A multi-method is a family of functions that is polymorphic in N arguments; the selection is done as per normal overloading rules, but at run-time Point intersect (virtual Trajectory*, virtual Surface*); Point intersect (virtual Line *, virtual Plane *); Point intersect (virtual Helix *, virtual Sphere *); v My implementation was designed with dynamic loading in mind r Family can be extended and shrunk by loading/unloading libraries r Maintains reverse look-up tables, not the full (# classes) N matrix