|
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.
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
DUNSARCH=linux; export DUNSARCH
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.
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).
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
|