This page describes how to install and maintain VisIt in a Unix environment. It is intended for two classes of users:

  • Regular users who wish to simply install VisIt one time
  • Super users who want to customize their site installation as well as install multiple versions and/or binaries for multiple platforms

Regular users need only look at the first section, which gives an overview of the basic installation process. The following section is for super users only. This section gives an overview of advanced tips for maintaining multiple VisIt installations and site-specific customizations.

Basic Installation

To install VisIt, you need to download two files from the VisIt website. The first necessary file contains the libraries and binaries for a specific platform and version of VisIt. An example would be visit1_12_0.linux_rhel3.tar.gz. This would contain VisIt version 1.12.0 for the platform "Linux RedHat Enterprise 3". The extension ".tar.gz" indicates that the files are part of a gzip'd tarball. Do not untar or unzip this file. This will be done by the second necessary file, the script visit-install.

You install VisIt by invoking the visit_install script. The gzip'd tarball should be located in the current working directory when you invoke this script. The basic syntax is:


For example:

visit-install 1.12.0 linux_rhel3 /usr/local/tools/visit

would install the binary for linux_rhel3 for version 1.12.0 to the directory /usr/local/tools/visit. VisIt could then be started by invoking /usr/local/tools/visit/bin/visit.

There are additional options to visit_install script, primarily for setting up file permissions and setting up configuration. These options are described later in this page.

Advanced Installation

The layout of a VisIt installation

The directory system used to install VisIt allows for multiple platforms and versions to be supported simultaneously from the same directory. This allows for a site to be maintained using a single installation, provided that the installation is located on a disk that is mounted on all machines of interest.

Assume that VISITDIR is the base VisIt directory. So, for the example previously given, VISITDIR would be /usr/local/tools/visit. Then, if installing version "VER_A" for platform "PLAT_1", VisIt will create the following directories:

  • VISITDIR/bin
  • VISITDIR/data
  • VISITDIR/current (symbolic link)

As previously stated, this directory structure supports multiple platforms and multiple versions. Installing platform ``PLATFORM_2" for ``VERSION_A" would be cause an additional directory, VISITDIR/VERSION_A/PLATFORM_2, to be created. That installation process would leave VISITDIR/VERSION_A/PLATFORM_1 untouched.

In VISITDIR/bin, there is a script called ``visit". This is the script used to launch VisIt. This script is very lightweight. It simply determines the current version of VisIt and then calls a heavier weight script to actually invoke VisIt. That script, for example, would be located somewhere in VISITDIR/VERSION_A/PLATFORM_1.

The symbolic link ``current" points to the current version of VisIt. So, for example, ``current" could point to the ``VER" directory. When VisIt is installed, it automatically updates ``current" to point to the most recently installed version. If that version is somehow faulty, you can go back to a previous version by resetting ``current". Further, you can override the symbolic link ``current" by adding a ``-v" to the invocation of VisIt. For example ``visit -v 1.12.0" will use version 1.12.0, regardless of the setting of ``current". This is useful if the default version is suitable for the majority of users, but if it is important for a subset to access a different version (which may be a new beta version, or an old version that does not contain a key bug).

Finally, the VISITDIR/data directory contains toy data files you can use to test if VisIt is running properly.

Advanced options for visit_install

-c config

The "-c config'" option is used to specify a configuration file. Configuration files are used to specify default settings and "host profiles", which contain information on how to launch VisIt, especially in parallel.

The currently accepted options for "-c" are: open, closed, nersc, and ornl. These are configuration files corresponding to Lawrence Livermore's open side computing facility (open), Lawrence Livermore's closed side computing facility (closed), Lawrence Berkeley's NERSC facility (nersc), and Oak Ridge's LCF facility (ornl). If you would like a configuration file specific to your site to be distributed with VisIt, send an e-mail to Information for how to construct such a file is located later in this page.

-g group and -gw

The "-g group" flag specifies the UNIX group ownership for the files created when installing VisIt. This is useful when a group of users (as opposed to a single individual) are responsible for installing and maintaing VisIt.

The "-gw" flag sets the permissions of the files to be group-writable, so that all members of the group may remove old versions.


This enables logging, so that usage of VisIt can be monitored. Records of all startups are placed in VISITDIR/VERSION/usagelog. Each startup appends to the username, platform, and data to this file. Note that it is important that the file VISITDIR/VER/usagelog be globally writable to correctly retrieve storage information. Some globally accessible file systems (which are ideal installation points for VisIt) do not allow writes. In this case, no logging information will be obtained.

Setting up default configuration for your site

When VisIt starts up, it looks at two configuration files. The first is the site configuration file, which is associated with the version of the tool. It is located in VISITDIR/VERSION/.visit/config. The second configuration file is the user-specific configuration, which is stored $HOME/.visit/config.

The site configuration file is an ideal place to add customizations for your site. The two primary customizations are host profiles and plugin selection, which will be described in the following subsections. The configuration file can be created by starting up VisIt and performing customizations through the GUI. By saving your settings (located under Options in the GUI), VisIt will create a user-specific configuration in $HOME/.visit/config. If you copy that file to VISITDIR/VER/.visit/config, it will create a default configuration for your entire site.

Host profiles

Host profiles contain all of the key information about how to launch VisIt, which is especially important in parallel. You can establish host profiles using the window located under Options. More information about host profiles can be found in the VisIt User's Manual. You can also look at existing host profiles to learn how to use the different options. One key option to consider is placing "-dir visit-dir" under the additional options. In the example used previously, visit-dir would resolve to /usr/local/visit (not /usr/local/visit/bin). This option is helpful when running client-server. When running the client, this option can tell VisIt where the server is located on the remote machine. This obviates the need to put VisIt in the user's "$PATH" on the remote machine.

Choosing Which Plugins are Available by Default

You can turn plugins on and off using the window under Options. When you turn a plugin off, it means that you cannot use the plugin for that session, not that the plugin can never be available. The purpose for turning off plugins is to reduce the list of operators that the users will consider (they are numerous).

Installing New Plugins

When you develop a new plugin against an existing VisIt installation, the program xml2makefile creates a Makefile that will place the resulting shared libraries in a subdirectory of $HOME/.visit. When VisIt starts up, it looks for plugins in both the installation and in $HOME/.visit. Plugins that are located in $HOME/.visit are available only to that specific user. If you want to install new plugins that will be accessible to all users, then they should be copied into the base VisIt installation at VISIT_DIR/VERSION/PLATFORM/plugins/<plugin_type>.