## GSLIB Help Page: Program Compiling

Getting Started:

- GSLIB does not provide executable programs and tutorials. All of the programs must be compiled prior to running them. This appendix provides some information and hints about loading and compiling the GSLIB programs.
- The programs in this version of GSLIB have been developed and are used primarily in the UNIX environment; however, there are no restrictions on the type of operating system. These programs have also been tested in the DOS environment and are distributed on 3.5 inch DOS diskettes. The following information is necessarily general because of the many different possible operating systems.
- As mentioned in the book, the GSLIB programs are distributed without any support or warranty.

Installation:

- Choose a target computer with a Fortran compiler. The first step is to choose a specific computer to load GSLIB. In many cases this is evident; nevertheless, keep the intended applications in mind. Workstations or larger machines would be appropriate if large 3-D simulations and kriging runs are anticipated. A compiler for ANSI standard Fortran 77 (or any later release) must be available on the target computer.
- Load the distribution software. The second step is to copy all of the files from the distribution diskettes to the target computer. Ensure that the directory structure is unchanged; there are files with the same name in different directories. The files may be copied directly if the target computer reads IBM-type high density diskettes; otherwise, they will have to be transferred through an IBM-type PC to the target computer via some file transfer protocol.

  The type of transfer protocol will be accessible from the local system expert or administrator. Some possibilities include a modem connection to the target computer, an ethernet card, or some other network connection.

- File naming conventions. Different Fortran compilers require different file naming conventions, e.g., most UNIX implementations require Fortran source code files to be names with a `.f` extension, most DOS implementations require a `.for` extension, and some compilers require a `.ftn` extension. All of the Fortran code (named with a `.for` extension on the distribution diskettes) should be systematically renamed if appropriate. A UNIX shell script `mvsuff` is provided to change file suffixes, e.g., entering `mvsuff for f` will cause all files with a `.for` extension in the current working directory to be renamed with a `.f` extension.
- Choose compiler options. The next step is to choose the compiler options and to document the changes that are required for the programs to be compiled. Compiler options vary considerably; the following should be kept in mind:
  - The code can be optimized unless the use of a symbolic debugger is being considered. A high level of optimization on certain computers can introduce problems. For example, the `vargplt` program has failed to work properly when compiled with a high level of optimization on certain compilers.
  - The source code is in mixed upper and lower case. In some cases a compiler option must be set or the source code may have to be systematically changed to upper case (the ANSI standard).
  - Some compilers force each `do` loop to be executed at least once (i.e., the test for completion is at the end of the loop). This will cause problems and must be avoided by additional coding (adding an {\tt if statement before entering a loop) or setting the appropriate option when compiling the programs.
  Modifications required in one program will surely be required in other programs. It is good practice to modify systematically all programs at one time rather than when needed.

  On UNIX machines a `makefile` can be used to facilitate source code management. If extensive modifications and upgrades are anticipated some type of source code control system could be considered.

- Compile the GSLIB subroutine library. The 37 programs in GSLIB version 2 require a compiled GSLIB subroutine library. The subroutines are in the GSLIB subdirectory on the diskettes.
- Compile the programs. Each program is in its own subdirectory and can be compiled separately once the GSLIB library has been compiled.
- Testing. A necessary but not sufficient check that the programs are working correctly is to reproduce the example run of each program.

Troubleshooting:

- This section describes some known installation pitfalls. When attempting to isolate a problem it would be a good idea to scan all of the following points:
- MAC users note that the quotes around the file name in the ``include'' statement must be removed.
- VAX/VMS users note that the file opening convention will have to be modified in some cases. The VMS compiler does not accept the \newline `status='UNKNOWN'` option when opening files.
- Lahey Fortran users note that a variable that is in a common block can not be initialized by a ``data'' statement; a ``block data'' statement must be used.
- File not found errors are often due to users forgetting that all file names are read as 40 characters. For example, accidentally removing some of the blank spaces before the start of a comment (e.g., `data file`) will cause the program to fail.
- Nonexistent file names are often used to inform the program that a particular operation is not needed, e.g., if the file specifying conditioning data, in the simulation programs, is missing then an unconditional simulation is constructed. It is good practice to explicitly specify a name that is never used, e.g., `nodata`
- Difficulty reproducing simulation results may be due to differences of numerical precision (machine representation of numbers) and a different sequence of pseudo-random numbers.
- A DOS ``end of line'' is marked by two characters. Some file transfer protocols automatically remove the extra character or a special command is available on most computers (`dos2unix` on SUN computers, `to\_unix` on SGI machines,\ldots).
- End-of-record code: The programs in GSLIB read in the data in free format, so each line should contain the correct number of data values separated by white space. Some of the programs and editors, such as EMACS, that are used to create data files for GSLIB may terminate the very last line with an end-of-file (EOF) code without an explicit end-of-record code; if this is the case, GSLIB may not be able to read the very last record in the file. If users notice that the number of data being read is one less than the number that they intended, a blank line at the end of their data file may solve the problem.