Architecture of the IViPP Particle Visualization Program

Doug Baldwin

Department of Computer Science
SUNY Geneseo

June 22, 2004

Abstract

IViPP is a program for visualizing the outputs of computational particle physics models. The critical need in this area of visualization is not so much to visualize a particular computational model as to produce a visualization architecture that can be adapted to accommodate new models, new ways of viewing or interacting with data, etc. IViPP is a prototype of such an architecture. IViPP exploits object oriented design, and in particular the Strategy and Model-View-Controller design patterns, for extensibility. System-independent graphics and user interface libraries make IViPP portable to all popular computing platforms. IViPP was first implemented in the summer of 2002. Since then, it has been extended in a number of ways, and has been used in another physics project, demonstrating the extensibility and practicality of the underlying architecture.

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.

1. Design Goals

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.

2. Architecture

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.

2.1 The Database

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.

Main Data 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:

changeColumn
Takes a column name as its parameter, and returns a pointer to the vector of data in that column. Creates a new column if the requested one does not already exist.
erase
A parameterless message that clears the database of all data.
setMinX, setMaxX, setMinY, setMaxY, setMinZ, setMaxZ
Messages that set the minimum or maximum coordinates of the bounding box in each dimension. Each of these messages takes the corresponding coordinate as its only parameter.
getMinX, getMaxX, getMinY, getMaxY, getMinZ, getMaxZ
Parameterless messages that return the minimum or maximum coordinates of the bounding box in each dimension.

Data Items

Objects 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.

2.2 User Interaction: Renderers, Control Panels, and Interaction Tools

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.

Renderers

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…

PtRenderer
Draws particles as points. Typically used to view stationary particles.
TransmitRenderer
Draws moving particles as lines. A particle’s energy is represented by the line’s length, and the particle’s direction by the line’s direction. One end of the line is anchored at whatever position the database records for the particle.
VoxelRenderer
Draws voxel data (i.e., VoxelData 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:

  1. Draw a set of coordinate axes (by sending a drawAxes message)
  2. Enable image clipping for any clipping planes (a kind of interaction tool, described below) that the user has defined (a drawClip message)
  3. Draw particle data (a drawParticles message)
  4. Draw targets (a drawTarget message)
  5. Draw any selectors (another interaction tool, described below) that the user has defined (a drawSelectors message)
  6. Disable clipping (another drawClip message)
  7. Draw any clipping plane tools that the user has asked to see (a 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.

Control Panels

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.

Interaction Tools

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.

2.3 Supporting the User Interface

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.

Events and Event Handlers

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.

User Interface Components

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.

2.4 Input and Output

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.

Particle Data

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).

Interaction Tools

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.

Statistics Control Panels

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.

3. Evaluation

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.

3.1 Implementation

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.

3.2 IViPP in Operation

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.

4. Conclusion

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.

Acknowledgements

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.

References

[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/