Scripts

• wind - Run WIND Code
• windpost - Perform Post-Processing
• windver - Get WIND Version Number
• windrun - Quick WIND Run
• windmp - Run on Multi-Processor
• runtest, runtestsuite - Run WIND Test Case(s)

WIND is run using a Unix script which attaches appropriate files and either starts WIND interactively or submits the job to a queueing system. In addition, this script checks for special files and may be used to re-invoke WIND after performing intermediate operations.

wind - Run WIND Code

The usual procedure for running the WIND code is via a command-line script called wind. With this approach, the specific executable to be run (e.g., production version, alpha version, etc.), the names of the required input and output files, etc., may be defaulted, specified on the command line, or entered as responses to prompts. The various options to the script are described below in the form of a Unix-style man page for wind.

If the Tcl/Tk interpreter is available, the WIND code may be launched via an interactive GUI by using -g as the first option to the wind script, i.e., by typing wind -g. In this case, the executable to be run, the file names, etc., are specified via the GUI. Any options to the wind script following the -g are ignored. If the -g option is specified, but the Tcl/Tk interpreter is not available, the usual command-line interface will be used.

The wind Man Page

wind_post - Perform Post-Processing

At the end of a non-debug job that completes successfully, if a script named wind_post exists in the current directory, and if the job is not being run interactively, the wind_post script is invoked, as follows.

   wind_post datname lisname cgdname cflname iter run_command

The wind_post script itself must be supplied by the user. Users with some experience in writing shell scripts may use this feature to automatically post-process results at the end of a job, or to save and/or process interim results from a lengthy calculation and submit a new job. [Note that a similar capability exists by using the SPAWN keyword in WIND's input data file.]

An example wind_post Bourne shell script called wind_post.sh is supplied with the WIND application distribution in the directory wind/bin. (There's also an example C shell version called wind_post.csh.) The example script resubmits the job with a different input file for each job iteration. It looks for an input data file named datname.dat.nextiter, where datname is the base name of the .dat file and nextiter is the next job iteration number (i.e., one more that the value of the input argument iter). The new input data file, if it exists, is copied over the original input data file and the job file is resubmitted.

A typical method for using this capability would be to create files named, for example, test.dat.1, test.dat.2, test.dat.3, etc. Then, copy test.dat.1 to test.dat and submit the job as usual. By keeping the initial input file in test.dat.1 and copying it to test.dat, the original initial input file is preserved.

After the initial job completes, wind_post will be called with iter = 1. The next job iteration number is thus 2. The file test.dat.2 will be copied into test.dat, and the job will be resubmitted, restarting WIND where it left off. If the file test.dat.nextiter doesn't exist, all the input data files have been used. The job file is then removed, and the run ends.

Note the distinction between a run and a job, and the value of the job iteration number. By run, we mean here a single invocation by the user of the wind script. Within that run, multiple jobs may be submitted using the wind_post feature, each with a different, automatically-incremented job iteration number. As noted above, the job iteration number is not saved between runs. The next time the wind script is invoked, starting a new run, the job iteration number will be re-initialized to zero. If it's necessary to save the value between runs, the user-supplied wind_post script should save it to a file, to be read during the next run.

The example wind_post script does not do any post-processing, but that can easily be added. For example, CFPOST could be run, with input redirected from a command file, to create plot files or reports. Or, an interim flow (.cfl) file could be saved by copying it into a file with the iter variable as part of the file name.

windver - Get WIND Version

The alpha version of WIND, and to a lesser extent the beta version, change quite frequently. Even the released production version is sometimes modified, as a result of bug fixes. Changes are summarized in the "Source History" file, accessed through the Internet Version Management System (IVMS).

The windver script may be used to get the complete version number of a WIND executable, and (for WIND 3.0 and higher) its supporting libraries. For example,

   % windver
   Versions in ./SGIMP6.5/R12000/bin

                    Select the desired version

     0: Exit wind
     1: alpha version
     2: Version 2.0
     3: Version 3.0
     4: Version 4.0
     5: Version 5.0

   Enter number or name of executable.......[5]: 5
    WIND   - Version 5.193 (Last changed 2002/11/05 17:53:28)
    LIBCFD - Version 2.142 (Last changed 2002/10/14 17:27:00)
    LIBADF - Version 2.0.14.1 (Last changed 2002/07/08 17:21:40)
    PVM    - Version 3.4.3

By default, windver looks for the WIND executables in the directory specified by the environment variable WIND_BINROOT. If there is no environment variable of that name, windver will look in CFDROOT. The user may also specify the root location of the WIND executable using the option -binroot. I.e., invoking windver as

   windver -binroot /usr/local/wind/wind

windrun - Quick WIND run

The windrun script may be used to quickly set up and start a WIND run. The run will be in interactive mode, with the output sent to a .lis file. The various options to the script are described below in the form of a Unix-style man page.

NAME

windrun - A quick way to start a WIND run

SYNOPSIS

windrun casename [-dev | -cfd] [windname] [-serial | -parallel] [-new | -restart] [-help]

DESCRIPTION

windrun is a Bourne shell script used to quickly set up and run WIND. Internally windrun invokes the wind script with the options -runinplace, -nobg, and -runque REAL, and other options determined by the windrun input options.

OPTIONS

	casename		The prefix for the WIND input/output files. All files must have the same prefix (e.g., case1.cgd, case1.cfl, etc.)
	[-dev]		Look under the directory defined by the WIND_DEV environment variable for the WIND executable. This is the default.
	[-cfd]		Look under the directory defined by the CFDROOT environment variable for the WIND executable.
	[windname]		The name (without the .exe extension) of the WIND executable to be used (e.g., windalpha, not windalpha.exe).
	[-serial]		Run in serial mode. This is the default.
	[-parallel]		Run in parallel mode, if an .mpc file is present.
	[-new]		Run a new case from scratch. This is the default. Any existing .cfl, .tda, .cth, .lis, and/or .job files with the current casename in the current directory will be erased before starting the WIND run.
	[-restart]		Start from the the existing solution, if one exists.
	[-help]		Display a summary on using windrun.

windmp - Run on Multi-Processor

The windmp script may be used as a shortcut when running WIND on a multi-processor machine (i.e., a single machine with multiple processors, like the CRAY or SGI Origin-2000). It simply invokes the wind script with the options -mp, -runinplace, and -not_nice.

runtest, runtestsuite - Run WIND Test Case(s)

runtest is a utility for running WIND test cases. runtestsuite is a wrapper for runtest that may be used to automate the running of a series of test cases. The various options to both scripts are described below in the form of Unix-style man pages.

The runtest Man Page

The runtestsuite Man Page