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
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
files for your architecture/flowfield. Then the source files need
to be compiled to create the executable.
Before doing anything, some environment variables need to be set in
.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
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
DUNSARCH=linux; export DUNSARCH
DUNSPATH27=/home/doug/codes/duns-2.7; export DUNSPATH27
You may also want to set your path to include the
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.
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
Before creating the source files,
make sure that your
variables are set up correctly in your
DUNSARCH variable indicates the architecture you are compiling
for so it will read the correct
Makesystem file. Currently you
DUNSARCH to either
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
options can either be
-sp for single precision source
-dp for double precision source code, or
-d $dirname for
selecting the directory to put the sources.
dim is either
compile-options are either
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
$DUNSPATH27/aix/duns-2d-turb if another directory
is not specified with the
You can then go into this directory and
make and it will compile the code and put the
resulting executable in
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
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.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).
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 (
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
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
$dim is either
3d. It puts the source code in the
same location as the
duns source, in the subdirectory
The program is then compiled by going into the source directory and typing
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 [-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
duns code. The
-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
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
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