Milagros is an SGI Onyx2 that is used primarily for driving the large immersive displays in the ACES Visualization Laboratory.

Milagros is configured with 24 400 MHz R12000 processors, 25 GB memory, and 6 IR2 graphics pipes. A pipe is a generic term, which generally refers to the graphics components on the system. Milagros has 6 highly configurable graphics pipes, numbered from 0 to 5. Pipe-0, 2, and 4 are fat pipes, and Pipe-1, 3, and 5 are narrow pipes. Fat pipes have larger amounts of graphics memory as well as the ability to enable more channels because of the number of physical video ports on the board. Each fat pipe has its own keyboard/mouse ports, enabling the OS to host a single console per fat pipe. Graphics memory on each pipe can be divided into smaller chunks to handle multiple display screens. Each of these chunks is called a channel. Each channel outputs a video signal to a video port, and the maximum number of channels on each pipes is dictated by the physical number of video output ports on each graphics pipes. We have several pre-set modes that users are allowed to switch in between.

Milagros is a local visualization system and has no formal mechanism for displaying remote visualizations. The access point to see the output from the graphics pipes on Milagros is at the console in the ACES Visualization Laboratory. What you see on screen when you log in to the console is known as the desktop. A console can be driven by 1 channel or by multiple channels. One console (desktop) can be made of 3 channels (screens or CRTs). Milagros main console is configured this way since the main workstation mirrors the 3 front projectors in the ACES Visualization Laboratory. The image projected on 3 CRTs or projectors will create 1 console (or desktop). Depending on what display mode you are in, these 3 channels can come from the same pipe or 3 different pipes. The method for switching between display modes is covered in the ACES Visualization Lab user guide.

Milagros has three console monitors attached to it and they are located in the ACES Visualization Laboratory. They allow users to directly log in to the system. The term Console refers to an X-session capability to give you a desktop screen. Normally only 1 console is used by a user at a single time. Depending on how much graphics capability is needed at the main console, all 3 consoles can be used simultaneously by 3 users.

The most common output display device used with Milagros is the ACES Visualization Laboratory. Milagros supports a variety of video modes because application software can vary widely. For example, an application that loads a large data file containing large geometry descriptions would want to use the multi-pipe mode so that more graphics pipelines can be available, thus increasing the amount of graphics memory and effective graphics capability.

When logging into Milagros remotely, users may use the ssh command. To ensure a secure login session, users must connect to all TACC machines using the secure shell, ssh program. Telnet is no longer allowed because of the security vulnerabilities associated with it. The "r" commands rlogin, rsh, and rcp, as well as ftp, are also disabled on this machine for similar reasons. These commands are replaced by the more secure alternatives included in SSH --- ssh, scp, and sftp.

ssh <login-name> @ milagros.tacc.utexas.edu

Note that the <login-name> is only needed if the user name on the machine being logged onto differs from the user name on the workstation.

1. Login Shell

   The most important component of a user's environment is the login shell that interprets text on each interactive command line and statements in shell scripts. Each login has a line entry in the /etc/passwd file, and the last field contains the shell launched at login. To determine your login shell, execute:

   grep <my_login_name> /etc/passwd {to see your login shell}

   You can use the passwd command to change your login shell; instructions are in the man page. Available shells are listed in the /etc/shells file with their full-path. To change your login shell, execute:

   cat /etc/shells	{select a <shell> from list}
   chsh -s <shell> <username>	{use full path of the shell}

2. User Environment

   The next most important component of a user's environment is the set of environment variables. Many of the Unix commands and tools, such as the compilers, debuggers, profilers, editors, and just about all applications that have GUIs (Graphical User Interfaces), look in the environment for variables that specify information they may need to access. To see the variables in your environment execute the command:

   env {to see environment variables}

   The variables are listed as keyword/value pairs separated by an equal (=) sign, as illustrated below by the HOME and PATH variables.

   HOME=/home/utexas/staff/username

   PATH=/bin:/usr/bin:/usr/local/apps

   (PATH has a colon (:) separated list of paths for its value.) It is important to realize that variables set in the environment (with setenv for C shells and export for Bourne shells) are "carried" to the environment of shell scripts and new shell invocations, while normal "shell" variables (created with the set command) are useful only in the present shell. Only environment variables are seen in the env (or printenv) command; execute set to see the (normal) shell variables.

3. Startup Scripts

   All Unix systems set up a default environment and provide administrators and users with the ability to execute additional Unix commands to alter the environment. These commands are "sourced"; that is, they are executed by your login shell, and the variables (both normal and environmental) as well as aliases and functions are included in the present environment. We recommend that you customize the login environment by inserting your "startup" commands in .cshrc_user, .login_user, and .profile_user files in your home directory.

   The commands in the /etc/profile file address operating system behavior and set the initial PATH, ulimit, umask, and environment variables such as the HOSTNAME. /etc/profile sources files ending in .sh. Many site administrators use these scripts to setup the environments for common user tools (vim, less, etc.) and system utilities (ganglia, modules, Globus, LSF, etc.)

   TACC has to coordinate the environments on platforms of several operating systems: AIX, Linux, IRIX, Solaris, and Unicos. In order to efficiently maintain and create a common environment among these systems, TACC uses its own startup files in /usr/local/etc. (A corresponding file in this etc directory is sourced by the .profile and .login files that reside in your home directory. (Please do not remove these files and the sourcing commands in them, even if you are a Unix guru.) Any commands that you put in your .login_user, .cshrc_user, or .profile_user file are sourced (if the file exists) at the end of the corresponding /usr/local/etc command files. If you accidentally remove your .login, .cshrc, and .login, you can copy new ones from /usr/local/etc/start-up.

4. Modules

   TACC is constantly including updates and installing revisions for application packages, compilers, communications libraries, and tools and math libraries. To facilitate the task of updating and to provide a uniform mechanism for accessing different revisions of software, TACC uses the modules utility.

   At login, a basic environment for the default applications, compilers, tools, and libraries is set by several modules commands. Your PATH, MANPATH, LIBPATH, directory locations (WORK, ARCHIVE, HOME, ...), alias (cdw, cda, ...) and license paths, are just a few of the environment variables and aliases created for you. This frees you from having to initially set them and update them whenever modifications and updates are made in system and application software.

   Users who need 3rd party applications, special libraries, and tools for their development can quickly tailor their environment with only the applications and tools they need. (Building your own specific application environment through modules allows you to keep your environment free from the clutter of all the other application environments you don't need.)

   Each of the major TACC applications has a modulefile that sets, unsets, appends to, or prepends to environment variables such as $PATH, $LD_LIBRARY_PATH, $INCLUDE_PATH, $MANPATH for the specific application. Each modulefile also sets functions or aliases for use with the application. A user need only invoke a single command,

   module load <application>

   at each login to configure an application/programming environment properly. If you often need an application environment, place the modules command in your .login_user and/or .profile_user shell startup file.

   Most of the package directories are in /usr/local/apps ($APPS) and are named after the package name (<app>). In each package directory there are subdirectories that contain the specific version of the package. The APPS directory structure is shown in the diagram below:

   
   TACC Applications Directory Structure

   The details of the environmental changes are in the modulefile, /usr/local/opt/modules/modulefiles/fftw. To see a list of available modules and a synopsis of a modulefile's operations, execute:

   module available	{lists modules}
   module help <app>	{lists environment changes performed for <app>}

   During upgrades, new modulefiles are created to reflect the changes made to the environment variables. TACC will always announce upgrades and module changes in advance.

   Another feature of modules is the ease in changing the environment for experimenting with new updates or backing down to older application versions. TACC will often make a link from <app>.new to the updated package modulefile (<app>.<new-version>) that has not become the default version yet. Also, the retired default modulefile is often linked to <app>.old. This makes it easier for users to change to new or old environments with the commands:

   module swap <app> <app>.old

   module swap <app> <app>.new

   (If the app module has not been loaded, then it is only necessary to load the new or old version; e.g. module load <app>.old.)

   For more information on modules and a description of how to build modulefiles, check out the man pages and the following URL:

   http://www.tacc.utexas.edu/resources/userguides/modules/.

   For information on customizing your login, go to the following URL:

   http://www.tacc.utexas.edu/resources/userguides/login/.

The TACC platforms have several different file systems with distinct storage characteristics. There are predefined, user-owned directories in these file systems for users to store their data. Of course, these file systems are shared with other users, so they are managed by either a quota limit, a purge policy (time-residency) limit, or a migration policy.

To determine the size of a file system, cd to the directory of interest and execute the "df" command with the syntax:

df -k .

or simply execute it without the "dot" to see all file systems. In the example below the file system name appears on the left, and the used and available space (-k, in units of 1KBytes) appear in the middle columns followed by the percent used:

To determine the amount of space occupied in a user-owned directory, cd to the directory and execute the du command with the -s option (s=summary):

du -s

To determine quota limits and usage on $HOME, execute the quota command without any options (from any directory):

quota

The four major file systems and directories available on TACC HPC machines are:

The system automatically changes to a user's home directory at login and this is the recommend location to store your source codes and build your executables.

Use $HOME to reference your home directory in scripts.

Use cd to change to $HOME.

Store large files and perform most of your job runs from this file system. This file system is accessible from all the nodes, however, older will be purged.

Use $WORK to reference your work directory in scripts.

Use cdw to change to $WORK.

This is the directory on each node where you can store files and perform local I/O for the duration of a batch job. Often, in batch jobs it is more efficient to use and store files directly on $WORK (to avoid moving files from scratch at the end of a job). Available for the duration of a job. Use $SCRATCH to reference a temporary directory in scripts.

The SAN directory is available on login nodes (front-ends) of Lonestar and Longhorn. Space on the SAN is an allocatable resource; that is, space is not automatically allocated to a project, the Principal Investigator must request space on this file system.

Store permanent files here. This file system has "archive" characteristics (see below). The access speed is low relative to the work directory. Use $ARCHIVE to reference your archive directory in scripts. Use cda to change to $ARCHIVE.

A user's home directory is the place to store files that are routinely used in development and day-to-day work. If the output files from production runs are small, then it is reasonable to store them in $HOME. Home directories are backed up daily; so, if you accidentally remove a critical file, submit a request using the consulting form in the TACC User Portal to recover the last saved version (include the full path name of the file(s) or directory, as well as the machine name).

Since the home file system is of limited size, a 500 megabyte quota limit is imposed on every user (the quota limit is machine specific).

The work file system is configured with fast disks on TACC machines and should, therefore, be used when I/O performance significantly affects program performance. Work can also be used to store large files temporarily. The files in work ARE NOT backed up and are temporary. Files that are corrupted or accidentally removed are not recoverable.

PLEASE NOTE: TACC staff may delete files from work if the work file system becomes full and directories consume an inordinately large amount of disk space. A full work file system inhibits use of the file system for ALL users.

The TACC SAN is a Storage Area Network that is accessible from the Milagros. The /san/vis/<project_name> directories are for projects that have been awarded (allocated) long-term space. The present configuration has ~4TB space for persistent, project-oriented storage. For more details read:

For long term file storage, use the archive file system ($ARCHIVE). This file system physically resides on an SGI Origin 2000 (archive.tacc.utexas.edu), a machine dedicated to supporting the archive file system.

A user's archive directory is available on all TACC HPC computers and is mounted at /archive. It appears as a normal UNIX file system but is managed by DMF, SGI's Data Migration Facility. Files that have not been accessed in a long time are moved offline (migrated) to tape via two StorageTek 9310 robots. DMF automatically and transparently performs the archival and retrieval of files from the tape robot system. When an off-line file is accessed, DMF automatically retrieves the file while the process that is accessing the files waits. Under normal circumstances it takes less than a minute for the robots to start streaming a file's data back to the disk and for the user's process to continue.

On Milagros, there are a couple of programming models for consideration.

First, in the message-passing model one may use either the SPMD or the MPMD programming paradigms. With the former, each processor loads the same program image and executes but on different data sets. This is dependent on the local portion of distributed arrays according to their distribution, array sizes, and number of processors determined at runtime. With the MPMD paradigm, each processor loads up and executes a different program image and on different data sets, with a similar set of parameters as the SPMD paradigm. This message passing programming model strictly uses MPI for its communication.

The other programming model that is always recommended on the Symmetric Multi- Processor based nodes like Milagros, is the SMP (Shared Memory Programming) model using either proprietary directives (or pragmas), vendor implementations of standards like OpenMP, or explicit threaded implementations such as Pthreads. Here, the major point of distinction is that all of the processors in the same node share data, hence strict processor to processor message-passing is unnecessary. Further, additional parallelism can be extracted by use of threads or multi-threaded implementations of the compilers, libraries, or tools.

For further information on OpenMP, MPI and on programming models/paradigms, please see the manuals and packages sections for documentation

The Milagros programming environment uses the Sun C++ and Fortran compilers as the default compilter system. The following section highlights the important aspects of using the Sun compilers. The Sun compiler commands can be used for both compiling and loading (making an executable from a .o object file). The tables below list the syntax for serial and parallel program compilation.

Appropriate program-name suffixes are required for each compiler. By default, the executable name is a.out; and it may be renamed with the -o option. To run a serial (non-parallel) executable, simply type the name of the executable on the command line (and hit return). When compiling and linking code in a single command, include the linker options at the end of the command as illustrated below:

To run the above compiled program interactively, execute:

./prog

The relative path expression "./" tells the shell to look in the present working directory for the executable. It is often used to make sure that an executable of the same name in another directory (as determined by the PATH environment variable) is not executed. Also, if the "." is not in the PATH variable it is necessary to use "./" for the shell to find the executable.

A list of all compiler options, their syntax, and a terse explanation, is given when the compiler command is executed with the -flags option. To see the listing, type:

Additional information can be found in the man pages for each compiler (e.g. man cc).

To compile OpenMP programs, add -xO3 -xopenmp=parallel to the compiler command line as shown below:

The "mpicmds" commands support the compilation and execution of parallel MPI programs on Milagros. The mpcc, mpCC, mpf77, and mpf90 compiler scripts (wrappers) compile MPI code into the executable. The following table lists the compiler wrappers for each language:

NOTE: In order to link in the mpi libraries -lmpi must be added to the command line at link time as illustrated below:

Here "linker options" are linker/loader options such as library paths and names.

The MPI compiler wrappers use the same compilers that are invoked for serial code compilation. So, any of the compiler flags used with the cc command can also be used with mpcc; likewise for f90 and mpif90; and CC and mpiCC. Below are some of the common serial compiler options with descriptions.

Some of the more useful load flags/options are listed below.

• Use the -l loader option to link in a library at load time: e.g.
  f90 prog.f -lname
• This links in the library libname.a provided it is found in ldd's library search path or by the environment variable LD_LIBRARY_PATH.
• To add a library directory to the library search path, use the -L option, e.g.
  f90 prog.f -L/mydirectory/lib -lname
• In the above example, the libname.a library linked in by the user is not in the default search path, so the "-L" option must be specified to point to the libname.a directory.

As described previously, graphics pipes contain a pool of graphics memory, and graphics channels are created to host your display by taking certain amount of graphics memory from the graphcs pipe. You can easily think of 3 combinations from this: 1) multiple channels from a single pipe, 2) single channel from a single pipe and 3) multiple channels from multiple pipes (This is called Monster-mode, and has a very special usage. This is not a commonly used mode, and will not be discussed here. Please contact the visualization staff directly if you need further assistance on this.)

Milagros main console is defaulted to use 3 channels. Depending on the modes, these 3 channels can come from the same pipe or from different pipes. The most common case on Milagros is the default set up, in which all 3 channels (screens) come from the same graphics pipeline.

The less common case (Case 2) is useful when you run multi-pipe capable software which allows you to utilize more of graphics hardware resources on the system. This is an advantage of multi-pipe mode since this will allow users to load large geometries. The disadvantage is that users need to write his/her application to span multiple display entities. Recall that multi-pipes mode spans processes over multiple pipelines. Graphics memory spans over multiple locations, so you should also know that you can not drag your application windows to other channels (screens).

As described previously, pipes contain graphics memory. If you are using 6 pipes, then you have 6 physically different graphics memory locations. This means that you have to know on which channel (screen) you want your stuff to be displayed. There are at least 2 basic ways to specify channels to be used by your application software.

1. Issuing a command on the channel you want to use:

   If you move the mouse to the far right edge of the main desktop screen, the mouse pointer will move over to consecutive channels. Each Console (desktop) has a Toolchest menu at left top corner. You can go to:

   	Toolchest
   	Desktop -> open unix shell

   Any application you invoke through Toolchest or a Shell you just opened will run in the same console. There are some applications that know how to display to specific channels. An example would be vGeo that will take up all displays.

2. Specifying the display channel by using environment variable:

   You can specify within a shell which pipe (desktop) your application software is started. You can do so by issuing:

   	> setenv DISPLAY localhost:0.PipeID
   	where PipeID is the integer ID of the desired pipe

   You can then issue a command to invoke your application to the PipeID you specified.

On Milagros, several pre-defined display modes are available for users through a GUI. The components of each display mode are:

1. Pipe- single, multi
2. Channel- single, multi
3. Resolution per Channel- 1280x1024(SXGA) @60Hz, 1024x768(XGA) @96Hz
4. Geometry Mode- flat screen projection mode, curved screen projection mode
5. Stereo Mode- single eye view, stereo view

As a default, single-pipe stereo mode is used on Milagros. It is called single pipe stereo since channels that compose the main console are all from the same pipe and stereo view mode is enabled (if application requires it). In VisLab, main console will display on front projector screen as main desktop. The projector screens in VisLab are arranged as:

Given the screen arrangement above, the detail of single-pipe mode is:

In the above example, each Pipe/Channel ID pair is routed to particular Screen IDs. In the VisLab, you may route any desired video input to any desired output, but the default is a pre-defined single-pipe mode.

As a default, Milagros display mode is set to single-pipe/multi-channels for the front screens. For normal use, you do not have to change Milagros display mode. If you need to switch the display mode, there is a GUI utility for pre-defined display modes that are commonly needed in the VisLab. Depending on what display mode you would use, you may also need to switch display modes on projectors side. If this is the case, you need to use a utility from the Trimension handset, located at main workstation. For further explanation on Trimension, please refer to VisLab users guide.

To start the mode switching utility, type:

	> ~vega/Vislab/rr

Users will be able to run application software from Milagros either at a console in the ACES Visualization Lab or through Sun Grid Engine via Milagros (see the section Running Remote Visualization Jobs). More details on the software listed here can be found in the UNIX man pages and at the applications website listed below.

1. Amira is a visualization tool that allows visualization and processing of 3D data sets in medicine, biology, physics and engineering. It includes automatic and interactive segmentation tools, reconstruction algorithms to create polygonal models from segmented objects, and many other tools relevant to CT and volumetric data sets. More information about Amira can be found at http://www.amiravis.com.

   To set up your environment properly to run Amira, type module load amira.

2. AVS 5.6 is a visualization tool tailored for scientific researchers from Advanced Visual Systems, Inc.. AVS is built on a visual programming paradigm that makes it easy to visualize scientific data without requiring extensive programming knowledge or expertise in advanced visualization techniques. A large collection of vendor-supplied and public domain modules is available from the International AVS Center at the North Carolina Supercomputing Center. AVS has standard subsystems for handling image, geometry, volume, and chemistry data and a graph manipulation package for plotting.

   To set up your environment properly to run AVS, type module load avs.

   Online references: more information about AVS 5 can be found at TACCs online pages at http://www.tacc.utexas.edu/resources/software/applications.php#AVS%205 and users can find online man pages by typing man avs at the prompt. Help is also available from within the package.

   University of Texas at Austin students, faculty, staff, and other authorized agents of the university can get a free copy of AVS 5.6 by completing the form located at http://www.tacc.utexas.edu/resources/software/avs/

3. AVS/Express is a general purpose data-flow visualization tool. AVS/Express also provides an object oriented environment for developing interactive visualization applications for use with data from science and engineering related sources. Beginning users should refer to the Getting Started and Using AVS/Express Guides.

   To set up the environment properly to run AVS/Express, type module load avs_express.

   Online references: more information about AVS/Express can be found at TACCs online pages at http://www.tacc.utexas.edu/resources/software/applications.php#AVS%205 and users can find online man pages by typing man avs at the prompt. Help is also available from within the package.

   University of Texas at Austin students, faculty, staff, and other authorized agents of the university can get a free copy of AVS 5.6 by completing the form located at http://www.tacc.utexas.edu/resources/software/avs/

4. Chromium is a system for interactive rendering on clusters of graphics workstations. Various parallel rendering techniques such as sort-first and sort-last may be implemented with Chromium. Furthermore, Chromium allows filtering and manipulation of OpenGL command streams for non-invasive rendering algorithms. More information about Chromium can be found at http://chromium.sourceforge.net/.

   To set up your environment properly to run Chromium, type module load chromium.

5. Ferret is an interactive computer visualization and analysis environment designed to meet the needs of oceanographers and meteorologists analyzing large and complex gridded data sets. It can transparently access extensive remote Internet data bases using OPeNDAP (formerly known as DODS); see http://www.unidata.ucar.edu/packages/dods/. Ferret was developed by the Thermal Modeling and Analysis Project (TMAP) at PMEL in Seattle to analyze the outputs of its numerical ocean models and compare them with gridded, observational data. The model data sets are generally multi- gigabyte in size with mixed 3 and 4-dimensional variables defined on staggered grids. Ferret offers a Mathematica-like approach to analysis; new variables may be defined interactively as mathematical expressions involving data set variables. Calculations may be applied over arbitrarily shaped regions. Fully documented graphics are produced with a single command. More information about Ferret can be found at http://ferret.pmel.noaa.gov/Ferret/.

To set up your environment properly to run Ferret, type module load ferret.

6. GIMP is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It is akin to Adobe Photoshop, can be used for photo retouching image composition and image authoring. More information about GIMP can be found at http://www.gimp.org.

   To set up the environment properly to run GIMP, type module load gimp.

7. GLUT (pronounced like the glut in gluttony) is the OpenGL Utility Toolkit, a window system independent toolkit for writing OpenGL programs. It implements a simple windowing application programming interface (API) for OpenGL. GLUT makes it considerably easier to learn about and explore OpenGL programming. GLUT provides a portable API so you can write a single OpenGL program that works across all PC and workstation OS platforms. GLUT is designed for constructing small to medium sized OpenGL programs. While GLUT is well-suited to learning OpenGL and developing simple OpenGL applications, GLUT is not a full-featured toolkit so large applications requiring sophisticated user interfaces are better off using native window system toolkits. GLUT is simple, easy, and small. The GLUT library has C, C++ (same as C), FORTRAN, and Ada programming bindings. The GLUT source code distribution is portable to nearly all OpenGL implementations and platforms. The current version is 3.7. Additional releases of the library are not anticipated. More information about GLUT can be found at http://www.opengl.org/resources/libraries/glut.html.

   To set up the environment properly to use glut, type module load glut.

8. Mesa is a 3-D graphics library with an API which is very similar to that of OpenGL. More information about Mesa can be found at http://www.mesa3d.org/.

   To set up the environment properly to use mesa, type module load mesa.

9. MPlayer is a movie player that plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska files, supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora, and MPEG-4 (DivX) movies too. MPlayer supports displaying through some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+. More information about MPlayer can be found at http://www.mplayerhq.hu/DOCS/HTML/en/index.html.

   To set up the environment properly to use mplayer, type module load mplayer.

10. OpenDX is a full-featured software package for the visualization of scientific, engineering and analytical data. Its open system design is built on a standard interface environments, and its sophisticated data model provides users with great flexibility in creating visualizations. More information about OpenDX can be found at http://www.opendx.org.

    To set up the environment properly to run OpenDX, type module load dx.

11. ParaView was created by Kitware in conjunction with Jim Ahrens of the Advanced Computing Laboratory at Los Alamos National Laboratory (LANL). Contributers and developers of ParaView currently include: Kitware, LANL, Sandia National Laboratories, and Army Reseach Laboratory. ParaView is funded by the US Department of Energy ASCI Views program as part of a three-year contract awarded to Kitware, Inc. by a consortium of three National Labs - Los Alamos, Sandia, and Livermore. The goal of the project is to develop scalable parallel processing tools with an emphasis on distributed memory implementations. The project includes parallel algorithms, infrastructure, I/O, support, and display devices. One significant feature of the contract is that all software developed is to be delivered open source. Hence ParaView is available as an open-source system. ParaView runs on distributed and shared memory parallel as well as single processor systems and has been succesfully tested on Windows, Linux and various Unix workstations and clusters. Under the hood, ParaView uses the Visualization Toolkit as the data processing and rendering engine and has a user interface written using a unique blend of Tcl/Tk and C++. More information about ParaView can be found at http://www.paraview.org.

    To set up the environment properly to run Paraview version 1.6.3 , type module load paraview-1.6.3.

    To set up the environment properly to run Paraview version 1.8.5 , type module load paraview-1.8.5.

12. Vis5D is a system for interactive visualization of large 5-D gridded data sets such as those produced by numerical weather models. One can make isosurfaces, contour line slices, colored slices, volume renderings, etc of data in a 3-D grid, then rotate and animate the images in real time. There's also a feature for wind trajectory tracing, a way to make text anotations for publications, support for interactive data analysis, etc. More information about Vis5D can be found at http://www.ssec.wisc.edu/~billh/vis5d.html.

    To set up the environment properly to run Vis5D, type module load vis5d.

13. VMD is a molecular visualization program for displaying, animating, and analyzing large biomolecular systems using 3-D graphics and built-in scripting. More information about VMD can be found at http://www.ks.uiuc.edu/Research/vmd/.

To set up the environment properly to run vmd, type module load vmd.

14. The Visualization ToolKit (VTK) is an open source, freely available software system for 3D computer graphics, image processing, and visualization used by thousands of researchers and developers around the world. VTK consists of a C++ class library, and several interpreted interface layers including Tcl/Tk, Java, and Python. Professional support and products for VTK are provided by Kitware, Inc. VTK supports a wide variety of visualization algorithms including scalar, vector, tensor, texture, and volumetric methods; and advanced modeling techniques such as implicit modelling, polygon reduction, mesh smoothing, cutting, contouring, and Delaunay triangulation. In addition, dozens of imaging algorithms have been directly integrated to allow the user to mix 2D imaging / 3D graphics algorithms and data. The design and implementation of the library has been strongly influenced by object-oriented principles. More information about VTK can be found at http://public.kitware.com/VTK/.

    To set up the environment properly to use vtk, type module load vtk.