The first step to porting WIND is to obtain and install the WIND application distribution, which contains the scripts used to run the code. Even though there is no executable available to run, you still need the scripts, because the "make" system relies on them to determine what type of machine and CPU it is working on. After you have gone through the process described there, check to make sure that the CFDROOT, SYSTEM, and SYSTEM_CPU environment variables are set to values that make sense for your particular system. Note that it is not strictly necessary that SYSTEM_CPU be set. (For instance, the CRAY and CONVEX systems do not have any particular CPU associated with them at this time.)
The source files for WIND (and the non-system libraries it depends on) are obtained by downloading the WIND build distribution. Put the gzip'ed tar file containing the build distribution into an appropriate directory. The same one used for the application and tools distributions would be a good choice. In that directory, unpack the file by doing:
gunzip -c filename | tar xvf -where filename is the file name, including the .tar.gz extension. Once you have installed the source on your system, change directory to the wind-dev directory and set the WIND_DEV environment variable to point to that directory. For example, if the previous step was done in /usr/local/wind, csh and tcsh users would do
cd wind-dev setenv WIND_DEV /usr/local/wind/wind-dev
Now you are ready to begin the task of actually porting WIND. There are three files you need to either examine or, if they don't already exist, create:
Note: There are other possible extensions than .opt
for this file.
If you wish to compile for use with a debugger, create a
Makefile.include... with a .dbx extension.
See the SGI files for examples.
Other possible extensions are .pure, which defines the
compilation configuration for use with the Purify debugging
software package.
Files ending in .check are for use with the ftnchek
static debugger.
Note 1: If you wish to run WIND in parallel, it is vital that -DRSHCOMMAND point to the correct remote shell command (including path) for your system.
Note 2: As before, there are other extensions besides .opt. See the SGI files for examples.
When all three files exist and everything appears in order, then simply type make opt (if you want to compile for optimization) and the make system should take care of the rest. If you type make by itself (or make help), a list of all the compilation options will be printed.
It is likely that the pvmgetarch and pvmgetcpu scripts need to be modified to detect your particular system. These scripts are found in the $CFDROOT/bin directory. You will have to determine for yourself how the scripts can correctly distinguish your system from other, but the examples already in them should get you started.
Once you have modified the files, you will need to copy them to several different places. Copy $CFDROOT/bin/pvmgetarch to $CFDROOT/pvm/pvmgetarch-cfd and also to $WIND_DEV/pvm/lib/pvmgetarch-cfd. Copy $CFDROOT/bin/pvmgetcpu to $CFDROOT/pvm/pvmgetcpu-cfd.
I know that these files should be links.
I'll get there some day.
If you have a compiler that is capable of compiling for many different machines/CPUs, then you may want to use a single machine to create executables for all of them. To some extent, this is possible, but it will take some extra work on your part.
First, modify $WIND_DEV/Makefile.configure so that
SYSTEM_SUFFIX and SYSTEM_BLD_CPU are set to the machine you wish
to compile for.
The extra work comes because the PVM compilation system is not set up
for cross-compiling.
Therefore, you must set BUILD_PVM to NO and obtain
(by one means or another) PVM libraries and executables for each
machine you wish to compile for.
For SGI workstations with MIPS processors, the default
is to compile PVM for the lowest common denominator CPU, so, for a
given operating system, you should be able to use the same PVM files
for R4400, R5000, R8000, and R10000 machines.
(R12000 too, but we haven't got one to try it with - yet.)
No, you don't.
To turn off the parallel capabilities of WIND, edit
$WIND_DEV/Makefile.configure and set BUILD_PVM to
NO.
Next, edit $WIND_DEV/source/Makefile.user and remove
pssubs from the LINK_MODULES line and add it to
the DUMMY_MODULES line.
This problem pops up on Sun workstations (and maybe others) because
awk is not working as expected.
Check to see if nawk is available on your system.
If it is, edit
$WIND_DEV/makefiles/Makefile.include.$SYSTEM.$SYSTEM_CPU.opt
and set the AWK variable to nawk.
The problem is that the files that are actually used for the
compilation are not the ones under $WIND_DEV/makefiles.
The actual files are: $WIND_DEV/Makefile.include.$SYSTEM.$SYSTEM_CPU
and $WIND_DEV/pvm/conf/$PVMSYS.def, where $PVMSYS is set by
$WIND_DEV/pvm/lib/pvmgetarch.
When you make changes, you must either copy the files to their final
destination or "select" the makefiles for the type of build you're
doing (using, for example make select_opt if you want to
compile with optimization).
When you run one of the "global re-build" compilations (e.g.,
make opt) then the "select" is done automatically.
Ideally, the system should automatically check to see if any of
the configuration files have been modified, but right now they don't.
See the answer to #5.
The short answer is that your changes were overwritten.
You have to modify the files under $WIND_DEV/makefiles
and "select" them in order to be sure that the changes will "stick".
IBMs seem to be particularly bad about this.
The "errors" are usually not errors in the sense that anything
is catastrophically wrong, but rather, in the process of
house-cleaning, the make system may be trying to remove files that
don't exist or is checking to see if a file does exist when it doesn't.
The solution is to modify $WIND_DEV/Makefile.configure and add
a -i switch to the MAKE and PVMMAKE variables.
Sometimes, switching to gmake will solve the problem,
but be aware that the PVM make system has make hardwired.
It may also be necessary to start the make process with the -i
switch (e.g. make -i opt).
The system of makefiles used to build WIND is pretty complex, and some
versions of make just can't handle this complexity.
The weakest link appears to be in the PVM build.
If your make utility is not up to the task, try using another
one (such as gmake).
Since the PVM makefiles are hardwired to use make, you may have
to use an alias rather than changing Makefile.configure.
For example, on the HP/Convex CSPP system, I found it necessary
to alias make to gmake.
The most likely explanation is that your system does not load all the libraries you need by default. Run grep on some of the symbols that it complains about (ignoring post-pended underscores - i.e. psexit, not psexit_) and see if the routines are from within WIND:
cd $WIND_DEV/source grep the_unknown_symbol */*If that fails to find anything, check in libcfd_wind:
cd $WIND_DEV/libcfd_wind grep the_unknown_symbol */*If you still can't find it, try libadf:
cd $WIND_DEV/libadf grep the_unknown_symbol *If that fails as well, then hunt through the $WIND_DEV/pvm subdirectories in a similar fashion. Once you are satisfied that the symbol is not from anything in the WIND distribution, you will have to poke around the system libraries to identify which ones should be added to the EXTRALIBS line in $WIND_DEV/makefiles/Makefile.include.$SYSTEM.$SYSTEM_CPU.opt (or .dbx etc.).
If the symbols are from within WIND, you need to look back through the
compiler listing to see what messages were output when the library
which contains that routine was compiled to see what went wrong.
The ADF core library (libadf) has only been ported to a
finite number of machines.
If your machine is not one of them, you may have to add
some lines to ADF_fbind.h for your system.
As with the ADF library (see #10),
the Common File library has only
been ported to a limited number of machines.
Check in $WIND_DEV/libcfd_wind/include/bind_f_and_c.h
to see if definitions for your system are there.
If not, you will have to add them.
As with libadf (see #10) and
libcfd_wind (see #11),
you may need to add lines appropriate for your system to a header file.
In this case, it's $WIND_DEV/source/include/fbind.h.
If the problem seems to be with the make system itself, then you may be able to successfully compile "manually" by using the following procedure (modify as needed for your particular shell):
cd $WIND_DEV/pvm setenv PVM_ROOT $cwd make clean make
If that works, then copy the PVM libraries (in $WIND_DEV/pvm/lib/$PVMSYS) to the $LIBDIR defined in Makefile.configure. Also remember to copy the PVM executables to $CFDROOT/pvm/$SYSTEM/$SYSTEM_CPU.
An additional possibility is that you have another version of PVM already installed, and certain environment variables may be set for that version which conflict with the version of PVM shipped with WIND. The solution is to make sure that neither of the environment variables PVM_ROOT nor PVM_ARCH are set prior to compiling or running WIND. (The various scripts should set these variables as needed).
If you still can't compile/run PVM, then you may need to talk to the
PVM developers
to see about
porting it to your system.
In the meantime, you can still run WIND in single processor mode
(see #3).
cp: cannot create /usr/local/wind/wind-dev/include/ADF.h: Permission denied.What is the problem?
By default (for security reasons, I believe), IVMS assigns only
"read" permission to the files it sends you.
Thus, when the make system tries to do an operation which results
in a "write" (which happens mostly when it's setting up the
include directory), an error results and the system
screeches to a halt.
The solution is to make sure that you have write permission
for all files and directories under $WIND_DEV.
Program aborting due failure in common I/O library call.
Subroutine called: CFRWFC
ADF 54: A node-id of 0.0 is not valid.
What should I do?
The cause of this problem has been traced to a change in the default floating point exception mode for R12000 systems. R10000 and R4400 SGI systems are not affected.
To run WIND on R12000 systems, you can upgrade to IRIX 6.5.4, and make sure that the kernel parameter "fpcsr_fs_bit" is equal to zero. After upgrading to IRIX 6.5.4, the value of this parameter may be determined by doing
systune fpcsr_fs_bitIf the value is non-zero, it should be changed by doing (as root)
systune fpcsr_fs_bit 0The change in the value of fpcsr_fs_bit occurs dynamically, and does not require rebooting the system.
If you're running on an SGI R12000 system, see the previous question. Otherwise ...
Ironically, the weakest link in the WIND chain (as far as porting goes) has nothing to do with the solver algorithm, parallelization, or memory management (in the fluid solver). The weakest link is, in fact, the file I/O system. The problems all seem to center around the ADF core library. Even if you did not see a specific ADF error code (e.g., "ADF 54: A node-id of 0.0 is not valid"), if you can run the same case (with the same files) on another machine, the problem is almost certainly in libadf.
If this happens, please notify the code developers so that we
can work on finding a fix.
Obviously, if we don't have access to a machine of the type you
are working on, then our ability to solve the problem is limited,
but at least we can note the problem.
If you feel energetic, you could also notify the CGNS folks
over at http://cgns.sourceforge.net/
that you found a problem.
You can, of course, attempt to debug it yourself.
If you do find a solution, please send it to us so that we can
make the fix available to everyone.
If, however, you don't have the time or the inclination
for that, then your best bet is to convert your input
Common Files
(which are version 3.0 by default) to version 2.0.
Version 2.0 of the Common File system does not use the ADF core,
and, so far, it has always worked when version 3.0 wouldn't.
The way to convert the files is to use the
cfcnvt utility.
Choose option 3, "Compress a Common File",
answer the questions, and then enter "2" when asked
"Output CF version number (2 or 3 (default))".
[Note that this assumes you have access to a system for
which the tools executables, including cfcnvt,
are available.]
Edit all Makefile.include.$SYSTEM.$SYSTEM_CPU.* files (found in $WIND_DEV/makefiles). Look for a line that defines "CFDEFS". On this line add "-DNO_TEMPNAM". Next, "select" the appropriate compilation type (e.g., make select_opt) and re-compile.