Skip navigation links
(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)

(Introduction) (Tutorial) (Geometry and Flow Physics Modeling) (Numerical Modeling) (Boundary Conditions) (Convergence Monitoring) (Files) (Scripts) (Parallel Processing) (Keyword Reference) (Test Options)

Scripts

wind - Run Wind-US Code

The usual procedure for running Wind-US 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 wind script is actually a simple wrapper, that passes its arguments through to wind.pl, which in turn is a symbolic link to a Perl script named solver.pl. A job file (with the suffix .job.pl) is created on the fly, which is the actual script submitted to the queue specified by the user. This is all normally transparent to users, however.]

The syntax used when invoking wind is:

   wind [-(no)batch] [-begtime time] [-(no)bg] [-binroot directory] [-cfdrootrem directory]
        [-(no)cgesave] [-(no)cl] [-cleanup] [-dat datfile] [-(no)debug] [-debugger debugger]
        [-done] [-endtime time] [-flow cflfile] [-genpost time] [-grid cgdfile]
        [-grpcharge number] [-help] [-list lisfile] [-loads time] [-memory number] [-(no)mp]
        [-mpiver version] [-mpmode mode] [-ncpu number] [-nice_val number] [-norsh] [-not_nice]
        [-nzones number] [-(no)parallel] [-program windname] [-queue_name name] [-remoterun]
        [-runinplace] [-runque queue] [-runroot directory] [-(no)save_core] [-solver solver]
        [-test] [-tmpdir directory] [-user_name name] [-user_passwd passwd] [-(no)usessh]
        [-version] [-waittime time] [-walltime time]

The various command-line options are described below. Note that all are optional. Several use the syntax -(no)option, indicating that they may be specified as either -option or -nooption. In addition to specifying values on the command line, several of the options may also be specified using environment variables. Values specified on the command line will override values set by environment variables.

    -(no)batch   If -batch is specified, run in "batch" mode, with all necessary input specified via command-line options. The user must specify the executable to be run using the -program option; all the input/output file names using the -dat, -list, -grid, and -flow options; and the system run queue using the -runque option. The user must also specify either the -runinplace option, or the directory to run in using the -runroot option. In addition, if a multi-processing control (.mpc) file exists, either the -parallel or -noparallel option must be specified. And, if an .mpc file exists and MPI message passing is being used, the number of zones must be specified using the -nzones option. If any of these items are missing, an error message will be displayed and execution will stop.

The default is -nobatch, allowing the necessary input to be specified in response to prompts.

 
-begtime time The beginning time for a standard Unix at/batch job (i.e., when using -runque AT_QUE).
 
-(no)bg Jobs in the interactive queue normally run in the foreground if the output is being displayed on the screen, and in the background if the output is being sent to the .lis file. If -nobg is specified, interactive jobs will be run in the foreground, even if the output is being sent to the .lis file.
 
-binroot directory Root location of the Wind-US executable on the system on which it will be running.

Environment variables: WIND_BINROOT, CFDROOT_REM. In order of preference, the default root location is set to the value of the environment variable WIND_BINROOT (if defined), then CFDROOT_REM (if defined), then CFDROOT.

 
-cfdrootrem directory The CFDROOT directory on the system on which the Wind-US executable will be running. The default is the same as the CFDROOT directory on the local machine.

Environment variable: CFDROOT_REM.

 
-(no)cgesave By default, when Wind-US is being run in a remote directory (i.e., in master mode, or without -runinplace), the common edge (.cge) file used for unstructured grids is saved in the job submittal directory at the end of the run. Specifying -nocgesave indicates that the .cge file is not to be saved.
 
-(no)cl Specifying -cl indicates that a cluster machine environment (e.g., a Linux cluster) is to be assumed. The default is -nocl.

Environment variable: WIND_CL. Set to YES for a cluster, NO otherwise.

 
-cleanup Perform clean-up functions only, copying files to the run directory if necessary, and removing temporary files, then exit. These clean-up functions are normally done only during normal job termination, or in the event of an error during the run.
 
-dat datfile The input data (.dat) file, entered without the extension (e.g., wing, not wing.dat).
 
-(no)debug If -debug is specified, Wind-US will run in debug mode, using the debugger specified by the -debugger option. The job will automatically be run interactively, and the -runinplace option will be set. The default is -nodebug.

Environment variable: WIND_TEST_MODE. Set to DEBUG for debug mode, NODEBUG otherwise.

 
-debugger debugger Define the debug package to be used when running in debug mode. The default depends on the computer system being used.

Environment variable: WIND_DEBUGGER.

 
-done Create a file named done at the end of the run containing a brief job status message. The status message will be "Done" for normal termination, "Execution Interrupted" for an interrupt during job execution, or "Error On Exit" for an error during job termination.
 
-endtime time Ending time for a Unix at/batch job, or time to run in seconds for a job running under the basic QSUB, PBS, or LSF queueing system. For the PBS and LSF queueing systems, some additional time will be added for termination processing (i.e., updating the flow (.cfl) file, terminating worker processes, etc.) Also see the -walltime option.
 
-flow cflfile The flow (.cfl) output file, entered without the extension (e.g., wing, not wing.cfl). If the file exists, the solution will restart using the conditions in the file as initial conditions.
 
-genpost time Create/update GENPLOT files containing convergence information every time seconds. If -genpost is specified without a time, the value specified with -waittime (or its default value) is used. Note that this option requires use of the POSTPROC keyword block in the input data (.dat) file. The -genpost option may not be used for jobs in the interactive queue with output sent to the screen.

Also see the -loads option for a quick, but less general, way to create a GENPLOT file containing convergence information.

 
-grid cgdfile The grid (.cgd) input file, entered without the extension (e.g., wing, not wing.cgd).
 
-grpcharge number Group charge number for jobs run under the PBS queueing system.
 
-help Display the list of command-line options, and quit, ignoring any other options.
 
-list lisfile The list output (.lis) file, entered without the extension (e.g., wing, not wing.lis). For interactive jobs, set lisfile to "screen" to display the .lis file at the terminal.
 
-loads time Create/update a GENPLOT file containing total forces and moments, and the L2 norm of the Navier-Stokes residual, every time seconds. The file name will be lisbase.loads.gen, where "lisbase" is the base name of the .lis file. If -loads is specified without a time, the value specified with -waittime (or its default value) is used. The LOADS keyword block must be used to write the desired total loads data (i.e., using TOTALS with the PRINT keyword) into the .lis file. The -loads option may not be used for jobs in the interactive queue with output sent to the screen.

Also see the -genpost option for a more general way to create GENPLOT files containing convergence information.

Due to a script bug, the -loads option will not work with versions of the Wind Scripts older than 2.0.82. This corresponds to Wind-US versions obtained before the afternoon of 14 Mar 2008.

 
-memory number Amount of run-time memory (in megabytes) to request for a job running under the PBS queueing system.
 
-(no)mp Specifying -mp indicates that a multi-processor machine (i.e., a single machine with multiple processors) is being used, with either PVM or MPI message passing. The default is -nomp.

Environment variable: WIND_MP. Set to YES for a multi-processor machine, NO otherwise.

 
-mpiver version MPI distribution being used when running in parallel with MPI message passing. version must be one of OPENMPI, MPICH1, MPICH2, INTEL, SGI. The default is MPICH2.

Environment variable: WIND_MP_VER.

 
-mpmode mode Message passing mode to be used when running in parallel: either PVM or MPI. To use MPI message passing, MPI must be pre-installed on your system(s) (unlike PVM, MPI is not distributed with Wind-US), and you will need to compile a Wind-US executable that links to the MPI library. See Installing the Build Distribution in the Wind-US Installation Guide for instructions on creating the executable. The default message passing mode is PVM.

Environment variable: WIND_MP_MODE.

 
-ncpu number Number of CPUs to request for a job running under the PBS or LSF queueing system.
 
-nice_val number The "nice" value (a number from 1 to 20) to use with the Unix nice command. Larger values cause the job to run at a lower CPU scheduling priority to lessen the impact on other jobs on the system. For interactive jobs (-runque REAL), the value is automatically set to 2.

Environment variable: WIND_NICE_VAL.

 
-norsh No remote shell (i.e., rsh or ssh) capability is available. This option only applies when MPI message passing is being used on distributed systems; all systems must be of the same type, and the Wind-US executable must be in the same location on each system. Parallel runs with PVM message passing on distributed systems and clusters require a remote shell capability.

Environment variable: WIND_USE_SSH. Set to NONE for no remote shell capability.

 
-not_nice Run without using the Unix nice command. This option only applies to serial jobs, and to worker tasks in parallel jobs that are being run on a different system than the master. For parallel jobs, the master task, and worker tasks being run on the same system as the master, automatically run at top priority (i.e., without using nice).

Environment variable: WIND_NOT_NICE. Set to YES to run without the nice command, NO otherwise.

 
-nzones number Number of zones, used in MPI message passing mode. If not specified, the utility mpigetnzone will be used to get the number of zones from the common grid (.cgd) file. If mpigetnzone is not installed, the user will be prompted for the number of zones.
 
-(no)parallel Specifying -parallel indicates that the job is to be run in parallel mode, while -noparallel indicates serial mode. Parallel mode requires a multi-processing control (.mpc) file. If -parallel is specified, but an .mpc file doesn't exist, the user will be asked if serial mode should be used. If neither -parallel nor -noparallel is specified, and an .mpc file exists, the user will be asked if parallel mode should be used.
 
-program windname The name of the executable to be used, without the .exe extension.
 
-queue_name name In the queueing system being used, as specified using the -runque option, the name of the specific queue in which the job is to run. The form of the name parameter depends on the queueing system.
 
-remoterun Bypass some of the built-in error checking for valid path names preventing error messages when running on a remote system. The CFDROOT directory on the remote machine should be specified using the -cfdrootrem option, and the root directory under which the Wind-US executable is to be run on the remote system should be specified using the -runroot option.
 
-runinplace Run in place, i.e., in the directory in which the wind script was invoked. This option is automatically selected if master mode is being used, or if running in debug mode. Otherwise, the default is to run in the directory specified using -runroot.

Environment variable: WIND_RUNINPLACE. Set to YES to run in place, NO otherwise.

 
-runque queue Queueing system in which the Wind-US executable is to run. The parameter queue may be REAL for a real-time interactive job; AT_QUE to run in a Unix at or batch queue; QSUB_QUE to run in a basic QSUB queue; QSUB_PBS_QUE to run in a QSUB queue using the PBS batch system; or BSUB_QUE to run in a BSUB queue using the LSF batch system. If the specified queueing system doesn't exist on the system being used, the job will stop.

Environment variable: WIND_RUN_QUE.

 
-runroot directory Root directory under which the Wind-US executable is to be run when -runinplace is not specified. The full name will be directory/userid/basename.scr, where userid is your userid and basename is the base name of your .dat file. The default directory, if -runroot is not specified, is /tmp.

Environment variable: WIND_RUNROOT.

 
-(no)save_core Specifying -save_core sets the allowed core file size equal to the maximum possible value. The default is -nosave_core, which makes no change to the allowed size. This option only applies to Linux systems.
 
-solver solver The solver to be run. The default, and only meaningful value for running Wind-US, is the base name of the top level Perl script (i.e., wind, from wind.pl).
 
-test Sets the root location of the Wind-US executable to the value of the environment variable WIND_DEV, allowing a "test" version to be used without having to change your CFDROOT environment variable. (More specifically, it's set to SOLVER_DEV, where SOLVER is the solver being run, specified using -solver, converted to upper case.) This option overrides a value specified using -binroot.
 
-tmpdir directory Directory for storing temporary files during a run. The default is defined by the script pvmgettmp.pl, which sets it to the value of the environment variable PVM_TEMP (if defined); otherwise it's set to the first of the following directories that exists: /lscratch, /scratch*, /data/local, /tmp.

Environment variable: TEMPDIR.

 
-user_name name The username to be used for Windows Scheduler. The default is the current user. (Note, though, that Wind-US is not officially supported under Windows.)
 
-user_passwd passwd The user password to be used for Windows Scheduler. There is no default value. (Note, though, that Wind-US is not officially supported under Windows.)
 
-(no)usessh When -usessh is specified, ssh/scp remote shell/copy commands will be used when copying files between the master and workers when running in parallel mode on distributed systems or clusters. The default is to use ssh/scp. For more details see the discussion of remote shell commands for parallel processing.

Environment variable: WIND_USE_SSH. Set to YES to use ssh/scp, NO to use rsh/rcp.

 
-version Display the specific version numbers for the Wind-US executable, and the CFD, ADF, and PVM libraries it's linked with, and immediately exit.
 
-waittime time Wait time seconds between run status checks. The default value, if -waittime is not specified, is 10 seconds. If -waittime is specified, but with a value less than 1, the value is reset to 30.
 
-walltime time Total wall clock time in seconds for a job running under the PBS or LSF queueing system. This includes the length of time for termination processing (i.e., updating the flow (.cfl) file, terminating worker processes, etc.) Also see the -endtime option.

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 six arguments are defined as:

    datname   The base name (i.e., without the three-letter extension) of the input data (.dat) and job files
lisname The base name of the list output (.lis) file
cgdname The base name of the grid (.cgd) file. (If CGNS files are being used, note that this is the base name of the file itself, not the name of the CGNSBase_t node in the file.)
cflname The base name of the flow (.cfl) file
iter The "job iteration" number. This is a count of the number of jobs, not time step iterations. It is initialized to zero, and incremented by one before each invocation of wind_post. Note that the value of iter is not saved between runs. The next invocation of the top-level wind script will re-initialize the value to zero.
run_command The command used to submit the job

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-US's input data file.]

An example wind_post Bourne shell script called wind_post.sh is supplied with Wind-US. (There is 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-US 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-US Version

The alpha version of Wind-US, 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.

The windver script may be used to get the complete version number of a Wind-US executable, and its supporting libraries. For example,

   % windver
   
            ***** Print Version numbers for Wind *****
   
   --Solver bin directory set to /usr/local/wind
   
                    Select the desired version
   
     0: Exit wind
     1: Wind-US 1.0
     2: Wind-US 2.0
     3: Wind-US 3.0
     4: Wind-US 4.0
   
   Enter number or name of executable.......[4]: 4
   
    Version numbers for /usr/local/wind/LINUX32-GLIBC2.3/XEON/bin/Wind-US3.exe
   
    WINDUS - Version 4.111 (Last changed 2015/06/11 20:31:45)
    LIBCFD - Version 2.180 (Last changed 2014/11/13 21:06:51)
    LIBADF - Version 2.0.20.1 (Last changed 2012/08/15 21:45:43)
    PVM    - Version 3.4.6
windver lists the various executables available, and prompts the user to select one of them. It then prints the complete version number, plus the date it was created, for Wind-US, the CFD library (common file processing routines, system-dependent routines, and utility routines), the ADF library (ADF routines from the CGNS project external link), and the PVM library (PVM routines external link used for parallel processing). In the above example, Wind-US 4.0 is actually Version 4.111, created on June 11, 2015.

By default, the windver script looks for 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. To look in some other location, instead of using windver, use the regular wind script with the -binroot and -version options. E.g., if the executables are located in the appropriate directories (i.e., in subdirectories corresponding to the SYSTEM and SYSTEM_CPU environment variables) below /home/wind_test/, you would do:

   wind -binroot /home/wind_test -version

windrun - Quick Wind-US run

The windrun script may be used to quickly set up and start a Wind-US run. The run will be in interactive mode, with the output sent to a .lis file. Internally windrun invokes the wind script with the options -nobg and -runque REAL, and with other wind script options determined by the windrun options.

The syntax used when invoking windrun is:

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

The command-line arguments and options are described below. Note that except for casename, all are optional.

    casename   The prefix for the Wind-US input/output files. All files must have the same prefix (e.g., case1.cgd, case1.cfl, etc.)
-dev | -cfd Specifies where to look for the Wind-US executable. If -dev is specified, look under the directory defined by the WIND_DEV environment variable. If -cfd is specified, look under the directory defined by the CFDROOT environment variable. The default is to look under the directory defined by the WIND_DEV environment variable if the WIND_DEV environment variable exists, and under the directory defined by the CFDROOT environment variable if the WIND_DEV environment variable does not exist.
windname The name (without the .exe extension) of the Wind-US executable to be used (e.g., windalpha, not windalpha.exe).
-serial | -parallel If -serial is specified, run in serial mode. If -parallel is specified, run in parallel mode on a multiprocessor system (i.e., using the -mp option to the wind script), if an .mpc file is present. The default is to run in serial mode.
-new | -restart If -new is specified, run a new case from scratch. Any existing .cfl, .tda, .cth, .lis, .job, .cge, and .cft files with the prefix casename, and any memdebug.lis file, in the current directory will be erased before starting the Wind-US run. If -restart is specified, start from the the existing solution, if one exists. The default is to run a new case from scratch.
-runlocal | -runtmp If -runlocal is specified, use the -runinplace option to the wind script to run in the current directory. If -runtmp is specified, use the options -remoterun -runroot $TMPDIR to run in a temporary directory below the location specified by the TMPDIR environment variable. The default is to run in the current directory.
-help Display a summary on using windrun.

windmp - Run on Multi-Processor

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

runtest, runtestsuite - Run Wind-US Test Case(s)

runtest - Run Wind-US test cases

runtest is a utility for running Wind-US test cases. The syntax used when invoking runtest is:

   runtest basedir casename [-dev | -cfd] [windname] [-serial | -parallel]
           [-runlocal | -runtmp] [-baseline] [-help]

The base name of the case to be run is given by the specified casename. runtest will look for casename.dat and casename.cgd input files in the current directory. In addition, runtest will recursively descend into any sub-directories and look for input files named subdir.dat and subdir.cgd, where subdir is the sub-directory name.

For example, you could set up a test case named case1, with input files case1.dat and case1.cgd. In the directory containing these files, you could have sub-directories named (say) run1, run2, etc., containing variations (e.g., different input options) on the original case. runtest will cd into the sub-directory run1, and look for input files named run1.dat and run1.cgd. Similarly for the sub-directory run2, etc. All such cases that are found will be run, in the directory containing the input files.

If a file named casename.ic.cfl (or subdir.ic.cfl if in a sub-directory, as described above) exists in the run directory, it will be copied as the file casename.cfl (or subdir.cfl) and used as initial conditions. Otherwise, a new case will be run from scratch. In either situation, any existing output files will be overwritten.

If multiple .dat files are found named casename.1.dat, casename.2.dat, etc. (or subdir.1.dat, etc.), multiple runs will be made using the successive .dat files to restart the solution.

If the specified case has been run previously, any convergence measures stored in the .lis file (i.e., residuals, integrated flow properties, etc.) will be compared with the values from the existing baseline results using diff, and the output will be written to the file basedir/test.log. In addition, if a file named delta.com exists in the directory with the Wind-US input files, it's assumed to contain CFPOST commands. CFPOST is run, with its standard input redirected from delta.com, and its standard output appended to the file basedir/test.log.

The -baseline option may be used to replace an existing baseline solution with the current one, bypassing the comparison of results.

The command-line arguments and options are described below. Note that except for basedir and casename, all are optional.

    basedir   The directory where the log file of the tests is to reside.
casename The prefix for the Wind-US input/output files. All files must have the same prefix (e.g., case1.cgd, case1.cfl, etc.)
-dev | -cfd Specifies where to look for the Wind-US executable. If -dev is specified, look under the directory defined by the WIND_DEV environment variable. If -cfd is specified, look under the directory defined by the CFDROOT environment variable. The default is to look under the directory defined by the WIND_DEV environment variable if the WIND_DEV environment variable exists, and under the directory defined by the CFDROOT environment variable if the WIND_DEV environment variable does not exist.
windname The name (without the .exe extension) of the Wind-US executable to be used (e.g., windalpha, not windalpha.exe). If no name is specified, the default Wind-US version will be used.
-serial | -parallel If -serial is specified, run in serial mode. If -parallel is specified, run in parallel mode on a multiprocessor system (i.e., using the -mp option to the wind script), if an .mpc file is present. The default is to run in serial mode.
-runlocal | -runtmp If -runlocal is specified, use the -runinplace option to the wind script to run in the directory where the input files are found. If -runtmp is specified, use the options -remoterun -runroot $TMPDIR to run in a temporary directory below the location specified by the TMPDIR environment variable. The default is to run in the current directory.
-baseline Replace the saved baseline solution, used for comparison with results from future runs, with the current solution.
-help Display a summary on using runtest.

runtestsuite - Run a series of Wind-US test cases

runtestsuite is a wrapper for runtest that may be used to automate the running of a series of test cases. It assumes that the cases to be run are stored in subdirectories of the current directory, with the subdirectory names the same as the case names (i.e., the subdirectory names are used for the casename argument when invoking the runtest script).

The syntax used when invoking runtestsuite is:

   runtestsuite [-dev | -cfd] [windname] [-serial | -parallel] [-baseline] [-help]

The command-line arguments and options are described below. Note that all are optional.

    -dev | -cfd   Specifies where to look for the Wind-US executable. If -dev is specified, look under the directory defined by the WIND_DEV environment variable. If -cfd is specified, look under the directory defined by the CFDROOT environment variable. The default is to look under the directory defined by the WIND_DEV environment variable if the WIND_DEV environment variable exists, and under the directory defined by the CFDROOT environment variable if the WIND_DEV environment variable does not exist.
windname The name (without the .exe extension) of the Wind-US executable to be used (e.g., windalpha, not windalpha.exe). If no name is specified, the default Wind-US version will be used.
-serial | -parallel If -serial is specified, run in serial mode. If -parallel is specified, run in parallel mode on a multiprocessor system (i.e., using the -mp option to the wind script), if an .mpc file is present. The default is to run in serial mode.
-baseline Replace the saved baseline solutions for each case, used for comparison with results from future runs, with the current solutions.
-help Display a summary on using runtestsuite.


Last updated 30 Sep 2016