Wind-US Installation Guide - Installing the Application Distributions

(Wind-US Documentation Home Page) (Wind-US User's Guide) (GMAN User's Guide) (MADCAP User's Guide) (CFPOST User's Guide) (Wind-US Utilities) (Common File User's Guide) (Wind-US Installation Guide) (Wind-US Developer's Reference) (Guidelines Documents) (Support)

(Overview) (Obtaining Wind-US and the Tools) (Installing the Application Distributions) (Installing the Build Distributions) (Porting Wind-US to a New UNIX Platform)

Installing on a UNIX System

After downloading the Wind-US and tools application distributions for the platforms to be used, the recommended procedure to unpack and install them is as follows:

Put the gzip'ed tar files containing the Wind-US and tools application distributions into an appropriate directory, such as wind_download. This directory does not have to be the permanent parent directory for the scripts and executables, but it can be.
In that directory, unpack all the files by doing, for each file:
```
   gunzip -c filename | tar xvf -
```
where filename is the file name, including the .tar.gz extension. Note that if application distributions were downloaded for several different machines, all of the gzip'ed tar files should be located in the same directory, and unpacked before proceeding to the actual installation. Similarly, if application distributions for some tools have been downloaded individually, it's recommended that they also be unpacked before continuing. This will allow all the tools to be installed in one step, rather than separately.
Install Wind-US first, by running the Install.appl script in the directory containing the application distributions. When prompted, enter the parent directory where Wind-US is to be installed. A wind subdirectory will be created directly below the directory you specify, and all files will be installed in subdirectories below that. E.g., if you specify /usr/local as the parent installation directory, the result will be a directory structure in /usr/local/wind.
The Install.appl script does not change any of your system or user files. It simply copies the executables and scripts to the appropriate locations below the directory you specify, and modifies the cfd.login and cfd.profile files in the application distribution accordingly.
Next, to finish the installation of Wind-US, csh and tcsh users must add the following line to their .login file in their home directory.
```
   source install_directory/wind/bin/cfd.login
```
where install_directory is the full path name for the parent installation directory you specified in the previous step.
Similarly, sh, bash, and ksh users must add the following line to their .profile file in their home directory.
```
   . install_directory/wind/bin/cfd.profile
```
This will cause the contents of cfd.login (or cfd.profile) to be executed each time you log in, setting/modifying the following environment variables:
- CFDROOT, specifying the root location of the Wind-US executable(s) and scripts (i.e., install_directory/wind)
- SYSTEM and SYSTEM_CPU, defining the type of system and CPU you're using
- PATH, to include the locations of the newly-installed executables and scripts in your search path
Log out and log back in, so that the cfd.login (or cfd.profile) script gets executed. (Or alternatively, issue the command "source .login" (or "source .profile") in your home directory.) This is necessary in order to define the CFDROOT, SYSTEM, and SYSTEM_CPU environment variables, that the tools installation and usage also require.
Next install the tools, by running the Install.tools script in the directory containing the application distributions. This step is exactly analogous to the one above for Wind-US. When prompted, enter the parent directory where the tools are to be installed. While not strictly necessary, it's recommended that the tools be installed under the same parent directory as used for Wind-US. A tools subdirectory will be created directly below the directory you specify, and all files will be installed in subdirectories below that. E.g., if you specify /usr/local as the parent installation directory, the result will be a directory structure in /usr/local/tools.
The Install.tools script does not change any of your system or user files. It simply copies the executables and scripts to the appropriate locations below the directory you specify, and modifies the tools.login and tools.profile files in the application distribution accordingly.
To finish the installation of the tools, csh and tcsh users must add the following line to their .login file in their home directory.
```
   source install_directory/tools/bin/tools.login
```
where install_directory is the full path name for the parent installation directory you specified in the previous step.
Similarly, sh, bash, and ksh users must add the following line to their .profile file in their home directory.
```
   . install_directory/tools/bin/tools.profile
```
This will cause the contents of tools.login (or tools.profile) to be executed each time you log in, setting/modifying the following environment variables:
- TOOLSROOT, specifying the root location of the tools executable(s) and scripts (i.e., install_directory/tools)
- PATH, to include the locations of the newly-installed executables and scripts in your search path
Finally, log out and log back in again, so that the tools.login (or tools.profile) script gets executed (or alternatively, issue the command "source .login" (or "source .profile") in your home directory), and the necessary environment variables get defined.

After completing the above steps, the directory structure will be similar to the example shown below, where wind_install is the directory specified in steps 3 and 6. (This example assumes that 32-bit executables were installed for a Linux system with glibc 2.3 and an Intel Xeon processor, and SGI systems with R12000 and R14000 processors. The actual "system" and "CPU" directory names for your installation will correspond to the choices you made for "Machine OS" and "CPU" when you downloaded the application distribution(s).)

   wind_install/
      wind/
         LINUX32-GLIBC2.3/
            XEON/
               bin/
                  Wind-US executable
         SGI32-IRIX6.5/
            R12000/
               bin/
                  Wind-US executable
            R14000/
               bin/
                  Wind-US executable
         bin/
            Wind-US and PVM scripts
            chemistry/
               Chemistry data (.chm) files
         pvm/
            LINUX32-GLIBC2.3/
               XEON/
                  PVM executables
            SGI32-IRIX6.5/
               R12000/
                  PVM executables
               R14000/
                  PVM executables
      tools/
         LINUX32-GLIBC2.3/
            XEON/
               bin/
                  Tools executable(s)
         SGI32-IRIX6.5/
            R12000/
               bin/
                  Tools executable(s)
            R14000/
               bin/
                  Tools executable(s)
         bin/
            Tools scripts

Using Symbolic Links for Similar Systems

As noted in the section on downloading the application distribution, if an executable is not available for the exact type of system and CPU you need to run on, a symbolic link can often be set up to specify that a different (but compatible) executable should be used.

For example, most (all?) modern Linux distributions include glibc Version 2.3. Suppose your SYSTEM environment variable is equal to LINUX32-RH9, but only executables for LINUX32-GLIBC2.3 are available. You can run the LINUX32-GLIBC2.3 executables by making LINUX32-RH9 a symbolic link to the directory LINUX32-GLIBC2.3. I.e., in the wind, wind/pvm, and tools directories, do

   ln -s LINUX32-GLIBC2.3 LINUX32-RH9

The resulting directory structure will be (starting from the example shown in the previous section, here in abbreviated form):

   wind_install/
      wind/
         LINUX32-GLIBC2.3/
            ...
         LINUX32-RH9 -> LINUX32-GLIBC2.3/
         SGI32-IRIX6.5/
            ...
         bin/
            ...
         pvm/
            LINUX32-GLIBC2.3/
               ...
            LINUX32-RH9 -> LINUX32-GLIBC2.3/
            SGI32-IRIX6.5/
               ...
      tools/
         LINUX32-GLIBC2.3/
            XEON/
               ...
         LINUX32-RH9 -> LINUX32-GLIBC2.3/
         SGI32-IRIX6.5/
            ...
         bin/
            ...

where the notation "LINUX32-RH9 -> LINUX32-GLIBC2.3/" is used to indicate that LINUX32-RH9 is a symbolic link pointing to LINUX32-GLIBC2.3/.

Similarly, on SGI systems an executable built on an R14000 CPU will also run on an R16000 CPU, for example. In this case, to run the R14000 executables on R16000 systems, in the SGI32-IRIX6.5 directories below wind, wind/pvm, and tools you would make R16000 a symbolic link to the directory R14000.

   ln -s R14000 R16000

The resulting directory structure will be (again starting from the example shown in the previous section, and here in even more abbreviated form):

   wind_install/
      wind/
         LINUX32-GLIBC2.3/
         SGI32-IRIX6.5/
            R12000/
            R14000/
            R16000 -> R14000/
         bin/
         pvm/
            SGI32-IRIX6.5/
               R12000/
               R14000/
               R16000 -> R14000/
      tools/
         LINUX32-GLIBC2.3/
         SGI32-IRIX6.5/
            R12000/
            R14000/
            R16000 -> R14000/
         bin/

Installation for NFS Access

If multiple users in an organization will be running Wind-US, it's convenient to install the Wind-US and tools executables below a parent directory that can be accessed by all the users via NFS. This way, the location and method of accessing the executables will be the same on all user machines, and they can be updated without impacting the user significantly. It is suggested that one individual from an organization download the needed application distributions and serve as a single point of contact for Wind-US.

When the scripts and executables are to be accessed via NFS, if the path name used by the user to access the NFS-mounted file system is different from the actual directory name on the "host" system, a slight variation of the above installation procedure is necessary. That's because the user's environment variables CFDROOT and TOOLSROOT must define the NFS-mounted location of the wind and tools subdirectories. Similarly, the lines users add to their .login or .profile files should specify path names used to access the NFS-mounted file system.

NFS file systems are typically accessed using automount. As an example, assume that Wind-US and the tools have been installed on a host workstation named wind_machine, and that the parent installation directory is /usr/local/wind_nfs. On wind_machine, that directory is exported read-only to the "home" system, normally an individual's workstation, of each Wind-US user. The user can then access that directory via automount by adding "/net/wind_machine" to the beginning of the path name. E.g.,

   cd /net/wind_machine/usr/local/wind_nfs

The cfd.login, etc., files on wind_machine were copied to new files named cfd.nfs.login, etc. [This was done so that users logging directly onto wind_machine could still access Wind-US as described in the previous section.] The definitions of CFDROOT and TOOLSROOT in cfd.nfs.login, etc., were modified to point to the automount'ed location of the wind and tools subdirectories. I.e., in cfd.nfs.login CFDROOT is defined as

   setenv CFDROOT /net/wind_machine/usr/local/wind_nfs/wind

and in tools.nfs.login TOOLSROOT is defined as

   setenv TOOLSROOT /net/wind_machine/usr/local/wind_nfs/tools

Finally, using the above example, csh and tcsh users accessing Wind-US via automount would modify their .login file to add the lines

   source /net/wind_machine/usr/local/wind_nfs/wind/bin/cfd.nfs.login
   source /net/wind_machine/usr/local/wind_nfs/tools/bin/tools.nfs.login

and sh and ksh users would modify their .profile file to add the lines

   . /net/wind_machine/usr/local/wind_nfs/wind/bin/cfd.nfs.profile
   . /net/wind_machine/usr/local/wind_nfs/tools/bin/tools.nfs.profile

Installation for Parallel Execution on Distributed Systems

It should be noted that Wind-US does not need to be installed on each individual machine in order to run in parallel mode using a network of distributed systems. The executables for all the different types of systems and CPUs being used are installed only on the master system. The Wind-US run scripts automatically take care of copying the appropriate Wind-US and PVM executables and files to the systems being used, starting and stopping the message passing software, and cleaning up at the end of the run. See the Parallel Processing section of the Wind-US User's Guide for details.

Installing on a Windows System

Unfortunately, due to resource limitations, the NPARC Alliance cannot officially support a Windows version of Wind-US. Nevertheless, application distributions for Windows may be available for Wind-US and some of the tools. These executables will generally not be as current as those in the supported Unix versions. The recommended installation procedure for Windows application distributions is described below.

After downloading the gzip'ed tar files containing the Wind-US and tools application distributions to some temporary directory:

Uncompress the gzip'ed tar file using some appropriate decompression software, such as WinZIP, extracting all the files into the temporary directory. With WinZIP this is done by clicking on the "Extract" button.
An "Install" link will appear in the temporary directory. Double click this to install the code(s). A DOS window will open.
Specify where you want to install the code(s) and a default name for the location for running applications. The applications directory is just the default and can be changed interactively later.
Follow the instructions regarding modification of the autoexec.bat file, then reboot.

An icon should appear on your desktop. Double-clicking on it will start execution of Wind-US.

Last updated 18 Jan 2008