[The material in this section was originally written by Chris Nelson of Sverdrup Technology, Inc. - AEDC Group.]
The source files for Wind-US (and the non-system libraries it depends on) are provided in the build distribution. See the instructions on how to obtain a copy. 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-US. There are three files you need to either examine or, if they don't already exist, create:
This file contains generic information such as the name of the make utility, where to find the source for the various components of Wind-US, and whether or not to build PVM. In addition, this file defines the machine and CPU type for which Wind-US will be built. By default, these are set from the SYSTEM and SYSTEM_CPU environment variables. If this file doesn't exist, download the build distribution again - something went very wrong.
This file contains system-specific information, such as compiler names, optimization switches, machine-specific compilations, the name of the awk command, the location of the C pre-processor cpp, and extra libraries which must be linked in. Pay particular attention to the MCHNSRCS lines in the "Common File directory special rules" section. If you are compiling for a completely new machine, you may have to create one or more of these files (which are found in $WIND_DEV/libcfd/machine.lib). You may, however, be able to use files created for other machines.
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. Another possible extension is .pure, which defines the compilation configuration for use with the Purify debugging software package.
This is the PVM configuration file. If your system is not currently supported, check in $WIND_DEV/pvm/conf to see if a configuration file for your system already exists. Note that the definition of SYSTEM may be different for PVM than for Wind-US. If you cannot find a pre-existing configuration file for your system, you will have to create one. Choose a file for a system similar to yours and use that as a starting point.
Note: 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 others, 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.
Ideally these files should be links, and perhaps some day they will be.
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 R10000 (and up) machines.
No, you don't. To turn off the parallel capabilities of Wind-US, 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/source/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/source/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/source/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-US 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, it might be 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-US:
cd $WIND_DEV/source grep the_unknown_symbol */*If that fails to find anything, check in libcfd:
cd $WIND_DEV/libcfd 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-US distribution, you will have to poke around the system libraries to identify which ones should be added to the EXTRALIBS line in $WIND_DEV/source/makefiles/Makefile.include.$SYSTEM.$SYSTEM_CPU.opt (or .dbx etc.).
If the symbols are from within Wind-US, 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/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 (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-US. 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-US. (The various scripts should set these variables as needed).
If you still can't compile or 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-US 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), the source files only have "read" permission enabled. 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-US 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-US 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
https://cgns.github.io/
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.
Last updated 20 July 2006