Figure 1.
Typical IViPP Use.
Department of Computer Science
SUNY Geneseo
IViPP (“Interactive Visualizations in Particle Physics”) is a program for visualizing the outputs of computational particle physics models. IViPP inputs data describing points, possibly moving, in three-dimensional space, and produces three-dimensional graphical displays of those points. Users can interact with the display, by changing their viewing point and by isolating subsets of the data. IViPP is highly extensible, i.e., it is easy to change for new input formats, new ways of viewing points, or new ways of interacting with them.
IViPP arose from a need to view the outputs of certain computational particle physics models in three dimensions. The models in question typically simulate the evolution of a system of particles over some time period or during some interaction, and output large text files containing the histories or final states of each particle. These files present the results of a simulation in perfect detail, and can be input to further automatic data analysis, but a graphical presentation better communicates a qualitative summary of the results to humans. Existing programs for displaying this data graphically are limited in various ways — for example, in only producing two dimensional displays, in only handling certain kinds of data, etc.
When we started considering visualization needs in particle physics, it quickly became apparent that many modeling programs lack good visualization tools, and that users want to view or interact with simulation results in a virtually unlimited number of ways. The critical need is therefore not a visualization program for a particular modeling program, but a visualization architecture that can easily be adapted to accommodate new models, new ways of viewing data, new ways of interacting with data, etc. IViPP defines and implements such an architecture.
IViPP’s most general goal is to allow humans to filter data from computational particle physics models. Very broadly, IViPP’s use cases (abstract interactions with users) are therefore…
Figure 1 summarizes this usage model.
Figure 1.
Typical IViPP Use.
The main design goals for IViPP are to handle the above use cases in an extensible way, i.e., in a way that allows programmers to easily add new file formats, viewing styles, interactions, etc. to the program. Furthermore, because IViPP is developed in an academic environment, it needs to be supportable by a small, part-time, team. These needs for extensibility and low support costs dictate that IViPP should be largely machine and operating system independent, so that porting it to new machines or operating systems does not require large rewrites, and to minimize the number of different versions of the program that need to be supported.
IViPP has an object oriented design that makes heavy use of the Strategy design pattern [Gamma] for extensibility. Specifically, IViPP is organized as a set of modules, for example a module that reads data from files, another that displays data for users, etc. At run time, each module is an object; modules communicate with each other solely by exchanging messages. Each module’s message interface is defined by its class. To extend IViPP in some way, one simply writes new subclasses of one or more module classes. Instances of the new subclasses handle the messages appropriate to their module, and so can be “plugged in” to IViPP at any time (even while it is running). However, each subclass can respond to messages in its own way, so different subclasses provide different alternatives for how each module behaves. For example, consider the modules that display data for users (known as a “renderers” in IViPP parlance). At any given time, only one renderer object is active in IViPP, and so data are only displayed in one way (e.g., perhaps as dots at particles’ final positions). However, to change the display (e.g., perhaps to lines showing particles’ paths), a user can simply replace the original renderer object with a different one chosen from a menu.
Figure 2 shows IViPP’s main modules and how data moves between them. The overall data flow reflects the usage model of Figure 1 closely. Input is handled by “reader” objects. Users interact with a visualization via “renderer” and “interaction tool” objects — renderers draw data, interaction tools select subsets of the data for display or saving. The user interface to both renderers and interaction tools is provided by “control panel” objects. Output is handled by “writer” objects. A “database” object provides a central place for the other objects to deposit data to or fetch data from. A number of additional classes support those shown in Figure 2, for example by providing internal representations of data.
Figure 2.
Major IViPP Modules.
The term “database” is used in IViPP in a very general sense, simply denoting a data structure that organizes the data that IViPP has available to display. IViPP does not use (or need) a database management system in the common, information systems, sense of the word. IViPP’s database-related classes include one that represents the main data structure, and a hierarchy of classes that represent things that can be stored in that structure.
IViPP’s database is an instance of the Database class. Database objects
contain a set of vectors (i.e., adjustable-size arrays), one vector for each
kind of data in the database.
For
example,
IViPP’s
database usually contains a vector of particle data, it may contain another
vector of
targets
the particles collide with, etc. These vectors are known as “columns” in
the database. Columns
can be created at will, so exactly what columns are in IViPP’s database
is determined by what sorts of data the current reader knows how
to read and
create columns
for.
Similarly,
columns can be read or not at will, so exactly what data is displayed to users
is determined by which columns the current renderer knows how to process.
Columns
are identified by string names. The database uses a hash table to map
column names to data vectors.
Clients usually interact with the database by fetching a column from it, and then either iterating over that column to process the data it contains, or adding new data to it.
Database objects also record a bounding box for the region of
space that contains the “interesting” items in the database. Reader
objects define the bounding box as they read data files, so the reader for
a file type
determines what items are “interesting” for
that type.
The most
important messages to Database objects are the following:
changeColumnerasesetMinX, setMaxX, setMinY, setMaxY, setMinZ, setMaxZgetMinX, getMaxX, getMinY, getMaxY, getMinZ, getMaxZObjects stored in IViPP’s database must be instances of the
VisData (“Visualizable
Data”) class,
or one of its subclasses. Figure 3 illustrates VisData and
its key subclasses. Of these classes, ParticleData, PtData,
and ParticleWithEnergy represent actual particles (or, more generally,
points) — PtData represents
stationary particles, while ParticleWithEnergy represents moving
ones (i.e., particles
with kinetic
energy). Class TargetData represents targets with which particles
collide. A VoxelData object describes a region of space (a voxel),
recording the total number of particles in that region but not the individual
particles. Voxels
display in different colors, according to the number of particles they contain.
This provides a way to visually summarize particle densities, and to draw large
data sets faster than would be possible plotting each particle individually.
Figure 3.
The Main Data Classes in IViPP.
All VisData objects respond to the draw message
by drawing themselves. Each subclass of VisData provides its own draw method,
so each kind of visualizable data has its own, unique, visual representation.
However, to allow renderers to influence how particles
appear, the draw message takes an integer parameter, which is
interpreted as a vector of flag
bits.
The draw methods
use these flags in class-specific ways to tailor how they draw
objects; authors of renderers need to know how the particles their renderer
draws will interpret the flags.
To record the subset of the
displayed data that a user has selected for saving or other special processing,
every VisData object can be in one of two states: “on” (i.e., selected)
or “off” (not
selected). The on, off, and isOn messages shown in Figure
3 allow clients to
change and query a VisData object’s selection state.
IViPP’s user interface is loosely based on the model-view-controller (MVC) design pattern [Sasine]. The MVC pattern divides an interactive application into core data (the model), one or more displays of that data (the views), and mechanisms through which users can modify the data (the controllers). IViPP’s model, not surprisingly, is the information in its database. Renderers form the view part of the pattern. Controllers are provided by control panels.
Models, views, and controllers in IViPP are not as strictly separated
as they are in the classical MVC pattern, however.
Not all control panels are technically controllers; some serve more as secondary
views, status displays, etc. Even those control panels that are, properly speaking,
controllers place interaction
tools in the database in order to visually
show what the control panel
is
doing,
and to mediate
its
interactions
with the
database. Interaction
tools have characteristics of both models and controllers: they are
model elements in being stored in the database, and they are controller
elements in helping control panels alter the database. Furthermore, all model
objects participate in viewing via the draw message. Finally,
views and controllers are paired in a pure MVC scheme, so that for every view
there is exactly one controller, but IViPP
typically has one view with multiple controllers.
A renderer displays the particles and other objects in IViPP’s database.
A typical renderer iterates over one or more database columns,
drawing the objects it encounters. The basic drawing is done by
sending the object a draw message, but different renderers may
pass different flags to this message to modify the object’s appearance.
Renderers may also differ in which columns they process.
Figure 4 shows the most important renderer classes in IViPP. Class Renderer defines the interface to all renderers, namely a drawData message that causes
a renderer to draw its parts of a database. This message’s parameter
is the
database to draw.
Figure 4.
IViPP’s Major Renderer Classes.
The renderers that IViPP actually creates are instances of classes from the bottom row of Figure 4. These classes render data as follows…
PtRendererTransmitRendererVoxelRendererVoxelData objects, described above) from
the database. When created, a VoxelRenderer adds a column of voxel
data to the database if one does not already exist. The information in this
column is computed from the database’s particle data.All of these renderers share a great deal of behavior. They differ in how
they draw particles, but all draw targets in the same way, all draw any interaction
tools the user may have created, etc. Class StandardParticleRenderer captures
these commonalities. This class uses the Template Method design pattern [Gamma],
providing a drawData method that implements the common rendering
algorithm via a series of messages that a renderer sends to itself. In particular,
the
common rendering algorithm consists of the following steps:
drawAxes message)drawClip message)drawParticles message)drawTarget message)drawSelectors message)drawClip message)drawVisPlane message).Class StandardParticleRenderer defines methods
that
handle each common rendering message in the most common way, but subclasses
can override any of those methods. Currently, most subclasses override the
drawParticles method, but use the inherited methods for all other
steps. If a renderer is ever needed for which the common rendering algorithm
is completely inappropriate, that renderer can be a direct subclass of Renderer and
define an arbitrary drawData method.
Visually, a control panel appears as a window, usually containing such user interface components as buttons, text fields, etc. For example, Figure 5 shows a control panel that allows users to select particles relative to a conical region of space. The control panel lets the user control the size and orientation of this selection region, and to either select or deselect particles inside or outside of the region.
Figure 5.
A Control Panel.
IViPP has many different kinds of control panel, implemented as subclasses
of a ControlPanel class. Figure 6 shows the
heart of the control panel class hierarchy.
Figure 6.
The Control Panel Class Hierarchy.
The MainControlPanel class provides the window within which renderers
display data. The class’s name reflects the fact that this window is
the central thing users see and interact with when using IViPP. This control
panel uses a “virtual trackball” algorithm (adapted from [Angel],
Section 4.10.2) to rotate the view of the database that the user sees, based
on certain mouse motions.
Main
control panels also translate the view in response to other mouse motions.
To implement these viewing transformations, main control panels accumulate
small rotations or translations derived from moment-to-moment mouse movement
in a
viewing transformation matrix, which they then make available to the active
renderer. Main control panels also provide
a pull-down menu with which users issue commands to IViPP, notably including
the commands that create other control panels. IViPP creates one MainControlPanel object
upon start-up, and never replaces or destroys it.
Class InteractionToolControlPanel is a superclass from
which all control panels for interaction tools inherit. Every interaction tool
has
a control panel, and every interaction tool control
panel controls exactly one interaction tool. Thus there
is always a one-to-one pairing between interaction tool control panels open
on the screen, and interaction tool objects in the database. The InteractionToolControlPanel class
provides basic features of all interaction tools, namely the abilities to save
the state
of
the tool
to
a file
and later
restore
that
state, to define and apply default values for the tool’s parameters,
and to remove the tool. Every interaction tool control panel also provides
text fields in which users can view and change the tool’s parameters,
although the exact set of fields depends on the tool.
InteractionToolControlPanel has two immediate subclasses, SelectorControlPanel and ClipControlPanel.
Selector control panels allow users to
select
particles in the database. There are several different kinds of selector in
IViPP (see below), each of which corresponds to a subclass
of SelectorControlPanel.
Figure 5 illustrates one of the selector control panels.
Clipping control panels define planes that “clip,” or
remove, parts of a visualization. This allows users to see the interior of
a dense cluster of points, for example. Note that clipping only affects what
data are displayed by renderers, it does not physically remove data from the
database.
StatisticControlPanel represents a somewhat unusual feature of
IViPP, as StatisticControlPanel objects are the only elements
of IViPP that do data analysis. Specifically, a statistics control panel computes
and displays an energy histogram of
the currently selected particles.
Figure 7 is an example of a statistics control panel.
Figure 7.
A Statistics Control Panel.
The FileNameControlPanel class defines control panels that present
file selection dialogs to users. FileNameControlPanel itself defines
a rudimentary dialog box containing a text field for the file name and “OK” and “Cancel” buttons.
Subclasses of FileNameControlPanel provide
more elaborate dialogs or define how a control panel responds to its buttons: OpenControlPanel provides
general dialogs for selecting a file from which to read something, while SaveControlPanel provides
general dialogs for selecting a file into which to save something. Subclasses
of both OpenControlPanel and SaveControlPanel correspond to specific types
of data that can be read and saved (e.g., particle data, the states of other
control panels, etc.)
MessageControlPanel objects are windows that display text. Message control
panels are very simple control panels, providing no controls other than scroll
arrows for moving through the text. IViPP
creates
one,
global,
MessageControlPanel object upon start-up, which it uses to display error messages
and similar information for its user.
The two kinds of interaction tool in IViPP are selectors and clipping planes.
As mentioned already, selectors allow users to select sets of particles, while
clipping planes allow users to temporarily remove data from the display.
All interaction tools descend from the VisData class, and are
stored in the database. Thus interaction tools are visible in the main control
panel, and
are drawn by renderers like all other VisData objects. Figure
8 shows
IViPP’s interaction
tool classes.
Figure 8.
IViPP’s Interaction Tool Classes.
Selectors allow users to select particles for saving to files or histogramming
in statistics control panels.
IViPP currently provides two kinds of selector, both of which select particles
relative to certain regions
of space. Each kind of selector allows users to independently select or deselect
the particles that lie inside or outside the selection region. With this feature,
users may select particles according to boolean combinations of several selectors
(for example, select all particles that lie inside one selector’s
region and outside another’s). For
SphereSelector selectors, the selection region lies between two concentric
spheres. For ConeSelector selectors, the selection region is a cone. Both kinds
of selector allow users to adjust the size, position, orientation, etc. of
selection regions.
As the term suggests, a clipping plane represents a plane through
space. Renderers that are aware of clipping planes only draw other objects
on one side of
this plane. Class ClipData represents clipping planes.
Users can create and destroy interaction tools at will. The main control panel’s menu provides commands for creating instances of the various interaction tools. Creating an interaction tool causes it to be entered into the database, and also creates a control panel with which the user can control the interaction tool. Selectors are stored in a database column named “Selectors,” and clipping planes in one named “Clipping.” Every interaction tool control panel provides a “Close” button that removes the tool from the database and destroys it and its control panel.
IViPP is built on a platform-independent library that provides windows, menus (but no other user interface components), and a callback mechanism for notifying IViPP of user inputs. IViPP provides the rest of its user interface infrastructure for itself. In particular, IViPP defines its own event-based model for communicating information about user inputs between objects, and defines several additional classes of user interface component.
IViPP’s underlying user interface library uses callbacks to notify client programs of user input. In other words, client programs register client functions with the library; the library later calls these functions when certain input actions happen. Code inside the library actually detects input. The most important callbacks for IViPP correspond to mouse movement, mouse button clicks, and keyboard input. The library invokes callbacks via conventional function calls, not messages to objects. IViPP, on the other hand, needs to notify a control panel object when input happens in the window corresponding to that control panel. IViPP thus registers as callback functions conventional functions that translate callback calls into messages to control panels. These callback functions use a global vector that maps window identifiers to control panels to find the control panel that controls the currently active window. The callback function then sends a message corresponding to the type of callback (mouse motion, keyboard input, etc.) to that control panel, passing along any parameters provided to the callback function.
When a control panel receives a callback message, it may handle the input directly (for example, by adding a character to an input field), but often the control panel has to translate the low-level input action into a higher level event that is meaningful to other parts of IViPP (for example, translating a mouse click into notification that a particular user interface button in a particular control panel has been pressed). The raw translation is done by determining whether a mouse click was within a particular region of a window, whether a keystroke was a command-confirming key (such as the “enter” key), etc. Once translated, however, other parts of IViPP generally need to be notified of the high-level event.
High-level events in IViPP are of two types. The mechanism for notifying objects of events depends on the event type.
Figure 9 illustrates typical delayed event handling. In
response to some user action (e.g., a mouse click), a control panel recognizes
that the user has
issued a command that the control panel itself cannot carry out immediately.
The control panel therefore creates an event object that encodes the command
and any parameters it requires, and enqueues that object on the delayed event
queue (a global object
named eventManager). At some later time, the display method
in the main control panel executes, and tells the event manager to process
all queued events. (The display method runs periodically,
through the callback mechanism, and will always run soon after a delayed
event has been enqueued.) The event manager dequeues the event, and sends it
a process message. In response to this message, the event executes
a method that processes the original
user command. Different user commands correspond to different subclasses of
the main event class, with different process methods. Often, although
not inevitably, processing an event includes destroying the
control
panel
that
created
the event.
Figure 9.
Handling a Delayed Event.
Because the library on which IViPP is built provides little support for creating
graphical user interfaces, IViPP defines the additional
user interface
components shown
in Figure
10. These classes represent check boxes,
two kinds of button, uneditable text labels, and one-line editable text fields.
Among the buttons, arrow buttons are labeled solely with arrows, and
are typically used as “increment” or “decrement” buttons,
or for scrolling. Text buttons are labeled with arbitrary text, and are typically
used for less stylized commands than the arrow buttons. All user interface
components render themselves in a window in response to the draw message,
and test whether a point lies inside the component in response to the inside message.
Figure 10.
IViPP Classes for User Interface Components.
Many different kinds of information can be read into IViPP and saved from it. The most important is particle data, which IViPP must be able to read and save in order to be useful at all. However, IViPP can also save and restore the state of interaction tools, and the results of the data analyses performed by statistics control panels.
As outlined in Figure 2, particle data is read into IViPP
by reader objects, and written by writer objects. A Reader class
defines the interface
for all
readers; different subclasses implement this interface for different
particle file formats. Similarly, a Writer class defines
the interface for writer objects, with subclasses implementing it for different
output file
formats.
A reader’s main job is to extract data from a file
created by an external program, and store that data in IViPP’s database.
Note, however, that readers don’t necessarily read every single piece
of data from a file. For example, some readers are deliberately designed to
filter complex
files
into
simple
visualizations. The crucial message to readers is readFile, which
takes the database, the file, and a set of flags (allowing clients to adjust
exactly
what
a reader
reads)
as parameters. This message causes the reader to read all its data from the
file, and store that data in the database. While reading the file,
the reader also keeps track of the bounding box for the
particles
or other objects described by the file, and adds that bounding box to the
database when reading is finished. Readers currently exist for
three file
formats:
two produced by a program called SRIM [Ziegler],
and one produced by a program known as MCNP™ [MCNP].
A writer’s job is to save selected particles to an external file.
The main message to writers is writeToFile, which takes the database,
the file, and a set of flags as parameters. Two writers currently exist, one
that produces a VRML version of a visualization (which can be displayed by
many Web browsers), and one that produces
tab-delimited
text describing the selected particles (which can be read by many spreadsheets
or other data analysis programs).
Every interaction tool can save its state to a file, and restore its state from a file. This feature allows a selection or view created for one data set to be saved and later reused with other data — for example, a common set of selection criteria could be applied to the results from a whole series of experiments.
Every interaction tool class provides its own save and restore methods. Separate readers and writers, such as exist for particle data, are unnecessary, because file formats are simple and need not be compatible with external programs. In general, interaction tools use a simple text format for their file representations, which keeps the reading and writing algorithms simple, and allows the files to be viewed or altered with a standard text editor for testing or debugging.
Saving a statistics control panel writes a complete description of the control panel’s settings (number of bins, etc.) and histogram, plus complete descriptions (position, direction, and energy) of each selected particle, into a file. Restoring a statistics control panel from a file restores the saved settings, and reads the saved particle data into a new column in IViPP’s database. The histogram contained in the file is ignored — the restored control panel reconstructs its histogram from the new database column. This strategy means that users can later change the restored control panel’s settings in order to histogram the retrieved data differently.
Although saved histograms are not used when restoring a statistics control panel, they can be used by external programs that read the saved control panel data. To facilitate reading by external programs, statistics control panel files have a simple text format.
The success of IViPP’s architecture is measured by the extent to which concrete implementations work as intended, and provide the desired extensibility and platform independence.
IViPP is written in C++, using the OpenGL® [Shreiner] graphics application programming interface. The “platform-independent library” for windowing and basic user input mentioned earlier is the GLUT toolkit [Kilgard]. C++, OpenGL, and GLUT are all available on most computing platforms, making IViPP highly portable. However, using platform-independent tools means that IViPP cannot take advantage of operating-system-specific user interface toolkits (thus the need to write many user interface components for IViPP), and probably imposes some performance penalty relative to system-specific graphics libraries (although this effect is minimized by the effectiveness with which OpenGL implementations use current graphics hardware).
Many features of IViPP were added after the basic architecture was defined.
In particular, the ability to read and render data from MCNP, the statistics
control panel, and clipping planes are all major features that were not envisioned
when the architecture was first defined. Although adding these features has
required some changes to the architecture (a notable example being that clipping
planes were the first non-selector interaction tool, and so required adding
the InteractionTool class as a common superclass for clipping
planes and selectors), the basic architecture has accepted these new features
gracefully.
IViPP presently runs under Microsoft’s Windows XP® operating system, Apple Computer’s Mac OS X® operating system, and several variants of the UNIX® operating system, including the Linux® and Sun OS™ forms.
IViPP has been successfully tested on data sets ranging in size from ten particles to one million. As a rough indication of its speed, IViPP renders just about 200,000 stationary particles (single points) per second on a mid-range computer (an Apple PowerBook® G4 running at 550 MHz, with a 16 MB ATI RAGE™ M6 graphics adaptor).
To date, IViPP has been used in one “production” project (i.e., a project not conceived primarily as a test of IViPP itself). This project created a computational model of a certain series of nuclear reactions; the model required tables giving energy distributions for nuclei with various initial energies after they passed through a thin plastic film. To generate these tables, we used SRIM to model a large number of nuclei entering the film for each initial energy range, and then used IViPP to histogram the energies of the nuclei that exited on the film’s other side. The histograms were produced by statistics control panels, which were saved and then read by the nuclear reaction model to initialize its tables. IViPP’s inputs in this project consisted of up to 99,999 moving particles. IViPP handled these data sets without difficulty.
IViPP’s architecture provides the robust flexibility it was intended to. It reads three different file formats, writes two, and incorporates three distinct renderers. From a single code package, it runs on three different computer systems. It has gracefully accepted significant features added after the basic architecture was defined. Last, but certainly not least, IViPP displays realistically large data sets at acceptable speeds.
IViPP is still being extended and improved — indeed, if the reasons for wanting an extensible architecture are valid, and the design sound, IViPP should never really be finished. In the immediate future, we hope to greatly expand IViPP’s ability to handle data from MCNP and similar programs, in particular to visualize particles’ evolution over time, and to display the geometry of the materials with which particles interact. Material geometry is often described using constructive solid geometry, so research in ways of rapidly rendering constructive solid geometry is a prominent part of current work on IViPP.
IViPP is in large part the product of a great many students at SUNY Geneseo. The program arises from an SRIM-specific visualizer developed in the Spring of 2001 as a class project by Mark Valites and Dan Born. Jake Clements added many features of the current IViPP to this project, and contributed to the extensible design that is the hallmark of IViPP proper. Cindy Wong, Genevieve Herres, and Elena Kornienko coded most of the present IViPP; Brian Aloisio and Ryan Kinal are currently extending it.
Dr. Stephen Padalino of Geneseo’s physics department recognized the potential of IViPP in nuclear physics research, and has been an enthusiastic supporter from the beginning.
Design and development of IViPP is funded by the Lawrence Livermore National Laboratory, the United States Department of Energy, and the Laboratory for Laser Energetics at the University of Rochester.
Trademarks mentioned in this report are as follows: “Linux” is a registered trademark of Linus Torvalds. “MCNP” is a trademark of the Regents of the University of California. “Mac OS X” and “Powerbook” are registered trademarks of Apple Computer, Inc. “OpenGL” is a registered trademark of Silicon Graphics, Inc. “RAGE” is a trademark of ATI Technologies, Inc. “SunOS” is a trademark of Sun Microsystems. “UNIX” is a registered trademark of The Open Group. “Windows XP” is a registered trademark of Microsoft Corp.
[Angel] E. Angel, Interactive Computer Graphics: A Top-Down Approach Using OpenGL. Addison-Wesley, 2003.
[Gamma] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[Kilgard] M. Kilgard. “The OpenGl Utility Toolkit (GLUT) Programming Interface.” 1996.
[MCNP] Anonymous. “MCNP — A General Monte Carlo N-Particle Transport Code — Version 5.” http://laws.lanl.gov/x5/MCNP/index.html
[Sasine] J. M. Sasine and R. J. Toal, “Implementing the Model-View-Controller Paradigm in ADA-95.” Proceedings of TRI-Ada ’95, Nov. 1995. pp 202 - 211.
[Shreiner] D. Shreiner et al. The OpenGL Programming Guide (4th ed.) Addison-Wesley, 2004.
[Ziegler] J. Ziegler. “Particle Interactions with Matter.” http://www.srim.org/