Diagonalized Upwind Navier Stokes Code

Tutorial Page

In order to compile the DUNS code, you must have a C-compiler at a minimum. A FORTRAN compiler would be nice, too, but is not necessary if you have a FORTRAN-to-C conversion utility such as f2c.

Compiling the DUNS code is divided into two parts. You must first create the source files from the distribution files. This is done simply by preprocessing the code for your particular architecture and flowfield type to generate the appropriate *.f and *.c files for your architecture/flowfield. Then the source files need to be compiled to create the executable.

4.1 Setting up the Compile Environment

Before doing anything, some environment variables need to be set in either your .cshrc or .bashrc (or equivalent) file. The DUNSARCH variable needs to be set, specifying the architecture type. Also, the path to the DUNS directory also needs to be set in shell. For a csh or tcsh, these can be set in .cshrc as

setenv DUNSARCH linux
setenv DUNSPATH27 /home/doug/codes/duns-2.7

in a bsh or bash, you should change the .profile file in your home directory

DUNSPATH27=/home/doug/codes/duns-2.7; export DUNSPATH27

You may also want to set your path to include the $DUNSPATH27/util directory, so you can use the DUNS tools independent of what directory you are in.

Before building the code, you need to enter the lib subdirectory and compile FORTRAN libraries used by the DUNS code. This includes CHEMKIN-II libraries, BLAS libraries, LINPACK libraries, BLOCK solver libraries, and the VODE stiff integrator. All of these programs were developed outside of the DUNS project and are in no way associated with the DUNS code. All of the code is standard FORTRAN77 code, and should compile easily over several platforms.

You need to run "make" and then "make install" inside the lib subdirectory. "make install" installs the libraries in the $DUNSPATH27/$DUNSARCH/lib directory, and two executables in the $DUNSPATH27/$DUNSARCH/bin directory for creating the chemistry and transport linking files required by CHEMKIN-II.

You should now be set up to compile the DUNS and work on some problems.

4.2 Making an Executable

Creating the source files and compiling the code is relatively easy once all the makesystem files are set up. Currently there are working makesystems for IBM AIX 3.2.5, SGI IRIX 6.1, Cray UNICOS 9.0, and Linux. The Linux Makesystems currently use fort77 instead of g77 because of some issues in the g77 compiler (fort77 is a front end to f2c).

Before creating the source files, make sure that your DUNSPATH27 and DUNSARCH environment variables are set up correctly in your .cshrc or .profile. This DUNSARCH variable indicates the architecture you are compiling for so it will read the correct Makesystem file. Currently you should set DUNSARCH to either aix, linux, cray, sgi, hp, or alpha. Please see the previous section on more information about setting up the compile environment.

The source files are simply the distribution files preprocessed by the C-preprocessor for your particular architecture and flow field type. To help create the source files, a shell script is included called dunssource in the util subdirectory. The options allow you to specify if you want to include turbulence, species, and dual-time in the source. For example, if you are not planning to run with turbulence, then you should not compile with turbulence because it will slow down the solution procedure slightly and increase your memory requirement. Note that you can still run laminar solutions even with the code compiled with turbulence. The dunssource command is run as follows:

dunssource options dim compile-options

where options can either be -sp for single precision source code, -dp for double precision source code, or -d $dirname for selecting the directory to put the sources. dim is either 2d or 3d and compile-options are either turb, spec, dual, or cklib. You can include as many or as few compile options as you need, but must specify either 2d or 3d flow. It will put the preprocessed files into a source directory; for instance if your architecture is aix and you compiled it with turb; that is, if you typed the command

dunssource 2d turb

It would put the resulting preprocessed FORTRAN/C files in the directory $DUNSPATH27/aix/duns-2d-turb if another directory is not specified with the -d option. You can then go into this directory and simply type make and it will compile the code and put the resulting executable in duns.e.

If you end up changing the distribution sources and would like to update the source files, just run dunssource again. It will only overwrite files that have been changed more recently within the distribution directory.

The tool dunsdiff can be used to determine the difference between the FORTRAN/C files in your distribution directory and in your source directory. It has the exact same syntax as dunssource, except that it DIFF's each individual file and tells you what differences exist.

A Note About Running On The Cray

If you will be running the code on a Cray and wish to transfer any unformatted files which are generated by the DUNS code (e.g. duns.restart, duns.restart-unst, duns-out.g, duns-out.q,duns.grid) from the CRAY to another architecture (e.g. Linux, IBM, SGI, etc.) and use them to run on this other architecture, then you will need to include the following lines in your .cshrc file (or simply type them in on the command line of the CRAY window where you will be running the DUNS code)

    assign -F f77 -N ieee u:30
    assign -F f77 -N ieee u:31
    assign -F f77 -N ieee_dp f:duns.restart
    assign -F f77 -N ieee_dp f:duns.restart_unst

These lines will ensure that the unformatted files are written out (and read in) using IEEE specifications, which is common to most of the IBM workstations, the SGI workstations, and Linux boxes (provided you make the appropriate patch to the FORTRAN library).

4.3 Definition of Parameters

Before compiling the code, the parameters file must be edited for the particular flow field you are interested in. The size of the code and the characteristics of the grid you run on are defined in this file. Because of the complexity of the code, there are unforunately several parameters that must be set. These parameters typically indicate the maximum number of something allowable. A description of them is as follows

Parameters related to grid

  • nbig Maximum total number of points for a grid
  • nbig2 Maximum total number of pointers to points for sweep blocks. For 2d cases, this is typically twice as big as nbig; for 3d cases, it is typically three times as big.
  • nblk Maximum total number of blocks for grid
  • mblk Maximum total number of sweeping blocks for grid. Again, for 2d this is typically twice as big as nblk; for 3d cases, it is typically three times as big.
  • nsmall Maximum number of points for one block in the grid. Depends on if your grid has many small blocks (nsmall can be small) or a few big blocks (nsmall will be pretty large).
  • nsmall2 Number of interior ghost cells. This also depends on the number of blocks you have. If you have a lot of blocks, nsmall2 will be relatively large. If you only a few blocks, it should be small.
  • nsmall3 Number of interpolated cells. This will be small if you do not have any zonal boundaries, in which case only corner cells are interpolated.
  • nsmall4 Number of surface points in the grid.
  • nsmall5 Number of interpolated points for parallel cases. If running scalar, than this should be 1.
  • nbcgen Should be 1 if you are not running generalized boundaries, otherwise it depends on the number of surface points that have a general boundary.
  • ibig Maximum number of points in the sweeping direction for a sweep block.
  • ibig2 Maximum number of points for any direction in a block. It is also used as a vectorization length when computing chemical source terms and property evaluations.

Parameters related to chemistry

  • nsm Maximum number of species
  • nrm Maximum number of reactions
  • nelm Maximum number of elements (not currently used)
  • nmodm Maximum number of chemistry models to use with adaptive chemistry. This can be safely set to a high number without an adverse effect on footprint or speed.

Parameters related to boundaries

  • nsrf Maximum number of surfaces

Another program called pregrid.e is also available to help determine appropriate parameters especially for complex problems. Like the DUNS code, the pregrid.e code needs to be preprocessed before it can be compiled. Again, you can use dunssource script to create the source files:

dunssource pregrid $dim

Where $dim is either 2d or 3d. It puts the source code in the same location as the duns source, in the subdirectory pregrid-2d. The program is then compiled by going into the source directory and typing make.

This program is compiled in a similar manner to the duns.e code, and in fact uses quite a bit of the duns.e code. It will give optimal parameters for a specific set of grid and boundary conditions. The command line options are as follows for pregrid.e

pregrid.e [-sp, --single-precision] [-dp, --double-precision]
 [-g, --grid filename] [-c, --conn filename] [-i, --interp] 
 [-ni, --no-interp] [-nb, --no-bounds]

The options for grid filename and connectivity filename are as given for the duns code. The -sp and -dp options are used dependent on whether the grid file is either a single or double precision unformatted plot3d file. Because of zonal boundaries, where interpolation takes place, boundary conditions can effect the values for parameters nsmall5 and nbcgen. If you have not generated a duns.bc file yet or know that it is wrong, run with the -nb option. This will exclude considering boundaries. In this case, you will have to determine good values for nsmall4 and nbcgen by your own means (typically this is fairly simple after you have some experience).

After the parameters file is set in the source directory, you can make the executable by simply typing make in the source directory. Wasn't that easy?

Next Previous Contents