Skip navigation links
(Wind-US Documentation Home Page) (Wind-US User's Guide) (GMAN User's Guide) (MADCAP User's Guide) (CFPOST User's Guide) (Wind-US Utilities) (Common File User's Guide) (Wind-US Installation Guide) (Wind-US Developer's Reference) (Guidelines Documents)

(Overview) (Obtaining Wind-US and the Tools) (Installing the Application Distributions) (Installing the Build Distributions) (Porting Wind-US to a New UNIX Platform) (Wind-US at NASA Glenn (GRC only))

Porting Wind-US to a New UNIX Platform

[The material in this section was originally written by Chris Nelson of Sverdrup Technology, Inc. - AEDC Group.]

Porting Guidelines

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:

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.

Frequently (or not) Encountered Problems

  1. The SYSTEM and SYSTEM_CPU variables are not being set in a way that makes sense for my system. What can I do?

    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.

  2. Can I cross-compile Wind-US for a different system using these makefiles?

    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.

  3. I only have a single processor machine. Do I really have to mess with all this parallel stuff?

    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.

  4. The compilation gets all the way to the end, and then fails with complaints about rcutv1, rcutaa, and rcimsc being unresolved symbols. What gives?

    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.

  5. I modified $WIND_DEV/source/makefiles/Makefile.include... (or $WIND_DEV/source/makefiles/pvm_conf/$SYSTEM...def... ), but when I re-compile, none of my changes are picked up. What is wrong?

    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.

  6. I modified $WIND_DEV/Makefile.include.SYSTEM.SYSTEM_CPU (or $WIND_DEV/pvm/conf/$PVMSYS.def), but when I tried to build Wind-US, it didn't seem to find my changes. I checked the files, and my changes were gone. What happened?

    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".

  7. My make utility complains that there are errors and aborts before anything gets compiled. Why?

    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).

  8. When I try to compile, it gets to a certain point and then just hangs. What is the problem?

    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.

  9. I'm getting undefined symbols at the end of my compilation, but it's more than just the three you mentioned in question #4. What are likely causes of the problem?

    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.

  10. I'm having trouble compiling the ADF library. What can I do?

    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.

  11. I'm getting some fairly bizarre compiler errors when compiling the Common File library. What is going on?

    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.

  12. Okay, I got libadf and libcfd to compile, but now Wind-US itself is complaining. Where should I look?

    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.

  13. I'm having trouble getting PVM to compile and run properly. What should I do?

    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

    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 external link to see about porting it to your system. In the meantime, you can still run Wind-US in single processor mode (see #3).

  14. I've gone through the whole process you describe above (in the Porting Guidelines section), but when I type make opt, I get one or more errors dealing with file permissions, like
       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.

  15. When running Wind-US on my brand new SGI R12000 system, I get the following error message
        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_bit
    If the value is non-zero, it should be changed by doing (as root)
       systune fpcsr_fs_bit 0
    The change in the value of fpcsr_fs_bit occurs dynamically, and does not require rebooting the system.
  16. I finally got everything to compile and link, but when I try to run the code, I get a "Program aborting due failure in common I/O library call" message, and then the code exits. What should I do?

    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 external link 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.]

  17. When compiling the Common File library, I'm getting messages about an undefined function called "tempnam". What should I do?

    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