Installation

In this chapter, we provide a step by step procedure for the compilation of the STATPACK library. The only requirement is a working Fortran 95/2003 compiler and the availability of the make UNIX tool.

This chapter, and more generally this manual, contains many examples/commands which can be typed at the keyboard. A command entered at the terminal is shown like this:

$ command

The first character on the line is the terminal prompt, and should not be typed. The dollar sign $ is used as the standard prompt in this manual, although some systems may use a different character. The examples/commands assume the use of an UNIX-like operating system.

Basic installation

The basic steps for the installation of STATPACK are described below.

Note that prior to these steps, none other packages are required or must be installed. In other words, STATPACK is a stand-alone software. However, optionally and for efficiency reasons, STATPACK can also benefit of an optimized and multi-threaded BLAS library, if available on your machine, and depending on your choice of the precision used in the library (see below).

It is also possible, optionally, to interface the LAPACK library with STATPACK, again depending on your choice for the precision of the library.

Please follow the following steps for LINUX/Unix systems:

1. Download the latest STATPACK version at STATPACK.

   For example, let us call this package statpack2.3.tar.gz.

2. Put the file in your preferred directory such as $HOME directory or, for example, /opt/ directory if you have ROOT privilege.

3. Execute the UNIX command:

   $ tar -xzvf statpack2.3.tar.gz
   

   to decompress the archive. Let us denote <STATPACK directory> the package’s top directory after decompression. For example, it could be $HOME/statpack2.3 or /opt/statpack2.3.

   This directory, <STATPACK directory>, contains the following subdirectories and associated files:

   Main STATPACK directory

   File/subdirectory	Content
   makefile	Generic Makefile
   make.inc	User specification options for Makefile
   LICENSE	STATPACK License file
   README	README file
   Changelog.txt	Change log file
   doc	STATPACK documentation
   makeincs	Template make.inc files for various compilers/platforms
   sources	STATPACK Fortran 90 modules and source code
   interfaces	Optional include directory for the .mod files generated by the compiler
   tests	Testing programs for the STATPACK source code
   examples	Example programs for the routines available in STATPACK
   myprograms	A directory where, optionally, you can store your own programs using STATPACK

   It is not mandatory, but recommended, to set the STATPACKDIR Shell environment variable to the path of the STATPACK top directory:

   Defining the Shell environment variable STATPACKDIR

   Shell	Command line
   csh/tcsh	setenv STATPACKDIR <STATPACK directory>
   sh/bash	export STATPACKDIR=<STATPACK directory>

   One of this command can be placed in the appropriate shell startup file in $HOME (i.e. .bashrc or .cshrc files).

4. In order to proceed to compilation, go to the $STATPACKDIR directory:

   $ cd $STATPACKDIR
   

   and edit the make.inc file inside this directory and follow the directions to change/specify appropriately:

   • the absolute path of the library directory (DIRLIB);
   • the name of the library (LIB);
   • the absolute path of the include directory, which will contain the .mod files generated by the compiler (INTERFACES);
   • the name/path of the Fortran 95/2003 compiler (FORTRAN);
   • the compiler options (OPTS, NOOPTFLAGS, OPTFLAGS and DRVFLAGS);
   • the archiver and its options to use when building an archive (e.g., a static library; ARCH and ARCHFLAGS);
   • the loader options for your BLAS and LAPACK libraries if you want to use these libraries (LBLAS and LLAPACK);
   • the linker and the flag(s) to use when building a shared library (LIBTOOL and LIBTOOLFLAGS);
   • the loader options for executing the examples and testing programs (LOADFLAGS).

   Alternatively, you can look at the template make.inc examples in the $STATPACKDIR/makeincs subdirectory and if one of them matches your compiler/platform, use this file as a template make.inc to build your own make.inc.

   This can be done:

   • manually, by overwriting the make.inc file in $STATPACKDIR by your choice in $STATPACKDIR/makeincs;

   • by executing the make command:

     $ make
     

     in the $STATPACKDIR directory, selecting the name for your architecture/compiler in the list printed on the screen and, then, executing the make command:

     $ make <arch>
     

     in the $STATPACKDIR directory, where <arch> is the selected name for your architecture/compiler. These steps will also overwrite the make.inc file in $STATPACKDIR by your choice in $STATPACKDIR/makeincs.

   After these steps, you still need to customize this new make.inc file, at least to provide:

   • the absolute path of the library directory (DIRLIB);
   • the name of the library (LIB);
   • the absolute path of the include directory, where the .mod files generated by the compiler will be written (INTERFACES);

   The table below shows what compiler option to use for writing/reading .mod files in the directory specified in the Shell variable INTERFACES (which is defined in your make.inc file) for several well-known Fortran compilers:

   Compiler option for writing/reading .mod files in the $INTERFACES directory

   compiler	Compiler command	compiler option
   GNU	gfortran	-J$(INTERFACES)
   AMD AOCC	flang	-J$(INTERFACES)
   Intel	ifort	-module $(INTERFACES)
   Intel	ifx	-module $(INTERFACES)
   PGI	pgfortran, pgf90, pgf95, pgf2003	-module $(INTERFACES)
   NVIDIA	nvfortran	-module $(INTERFACES)
   NAG	nagfor	-I$(INTERFACES) -mdir $(INTERFACES)
   IBM XL	xlf90_r, xlf95_r, xlf2003_r	-I$(INTERFACES) -qmoddir=$(INTERFACES)

   This command line option must be specified in the Shell variable OPTS defined in your make.inc file.

   Two loader options are typically used for linking the object code of the STATPACK and, eventually, BLAS and LAPACK libraries, when creating an executable:

   • -lname causes the compiler to look for a library file named libname.a and to link the executable to this library. To find this library file, the compiler searches sequentially through any directories named with the -L option explained below;
   • -Ldir option lets you specify a (specific) directory for libraries specified with the -l option, before searching in the standard library directories /lib and /usr/lib.

   Your compiler may have other options for specifying libraries, particularly if your UNIX system supports shared libraries and you want to use shared versions of the STATPACK, BLAS and LAPACK libraries.

   Typically, all these loader options must be specified in the Shell variables LBLAS, LLAPACK and LOADFLAGS in your make.inc file. Look at the template make.inc files in the $STATPACKDIR/makeincs subdirectory for practical examples with different compilers.

   Remember also when specifying these loader options in the Shell variable LOADFLAGS that UNIX linkers search for libraries in the order in which they occur on the command line and only resolve the references that are outstanding at the time when the library is searched. Therefore, the order of libraries and source/object files specified in LOADFLAGS can be critical and it is almost always a good idea to list first the STATPACK library and, secondly, only the LAPACK and BLAS libraries (or other libraries) in the Shell variable LOADFLAGS when compiling and linking STATPACK in order to avoid “Undefined” symbol messages during the loading or execution of an executable using the STATPACK routines.

   Moreover, if STATPACK is built with OpenMP support, executables using the STATPACK library will be multi-threaded and the BLAS library eventually linked to STATPACK must be compiled thread-safe, as much as possible, in order to avoid unexpected errors at execution of your application. A simple way to achieve this, is to compile your BLAS library with OpenMP support. This will also ensure that OpenMP manages all the threads associated with your program, a feature, which is highly recommended to avoid performance problems at execution if your BLAS library is also multi-threaded. See the sections OpenMP compilation and Parallel execution for more details.

5. After you have built your make.inc file, the next step is to choose the real/complex kind types (stnd and extd), integer kind types (i1b, i2b, i4b and i8b) and logical kind type (lgl), which will be used in your version of the STATPACK library. These different kind types are merely named integer constants used by Fortran 95/2003 for defining parameterized real/complex, integer and logical types [Fortran]. All real/complex/integer/logical variables and constants used in STATPACK are defined in this way. See the Fortran program ex1_svd_cmp.F90 for an illustration.

   A point that causes considerable nuisance in current Fortran libraries written in “old” Fortran like in BLAS and LAPACK is the need to maintain both single- and double-precision versions of exactly the same code. On the other hand, in Fortran 95/2003, there is no need to have separate versions of codes for single- and double-precision [Buckley:1994a] [Buckley:1994b] and STATPACK uses this possibility.

   Most of the real/complex computations in STATPACK are done at the parameterized stnd real/complex precision. However, a few computations are preferably done at the higher (parameterized) precision extd. So, the kind type extd should be such that the underlying hardware will select a higher precision for kind extd than for kind stnd, if this is feasible. If a higher precision is not readily available, the same value may be used as for stnd.

   Most current machines offer at least two precisions at the hardware level, very often three, and sometimes four. The decision about the correspondence between the parameterized stnd and extd kind types used in STATPACK and these different precisions at the hardware level is implemented by changing a single statement in the Fortran 90 Select_Parameters module, which is included in STATPACK.

   Thus, for altering the precision of the computations performed in STATPACK, you need to edit the file $STATPACKDIR/sources/Module_Select_Parameters.F90, which contains the Select_Parameters module, and follow the instructions in the comments of this module.

   Suffice to say here, that the user may select exactly the precision he wants for STATPACK by commenting/uncommenting lines in the Select_Parameters module, as in the following example:

   !
   ! use The_Kinds, only : stnd=>sp,  extd=>dp
   !
   use The_Kinds, only : stnd=>dp,  extd=>qp
   !
   ! use The_Kinds, only : stnd=>sp,  extd=>sp2
   !
   !use The_Kinds, only : stnd=>dp,  extd=>dp2
   !
   ! use The_Kinds, only : stnd=>qp,  extd=>qp2
   !
   !
   ! use The_Kinds, only : stnd=>low,   extd=>normal
   !
   ! use The_Kinds, only : stnd=>normal,  extd=>extended
   !
   ! use The_Kinds, only : stnd=>low,   extd=>low2
   !
   ! use The_Kinds, only : stnd=>normal,  extd=>normal2
   

   By simply ensuring that a leading ‘!’ appears on all but exactly one of the preceding use statements in the Select_Parameters module, and then recompiling STATPACK, the precision of all the routines included in STATPACK can be altered. As an illustration, using the statement (e.g., uncommenting):

   use The_Kinds, only : stnd=>sp,  extd=>dp
   

   implies that the kind types stnd and extd used in STATPACK will now refer to single- and double-precision, respectively, after the recompilation of the code.

   The symbolic names sp, qp, qp, … used in the above example are defined in the The_Kinds module. The symbolic names sp2, qp2, qp2, … are equivalent to sp, qp, qp, …, respectively, but are used in Select_Parameters to avoid problems with some compilers, which do not allow that two different symbolic names in use statements may refer to the same entity in a Fortran 90 module.

   The different choices for the kind type stnd (and also extd) are as follows. Selecting:

   • sp kind for real/complex stnd data types in STATPACK requests to use the standard single precision available on all systems as the standard real or complex data type in STATPACK.
   • dp kind for real/complex stnd data types in STATPACK requests to use the standard double precision available on all systems as the standard real or complex data type in STATPACK.
   • qp kind for real/complex stnd data types in STATPACK requests to use the quadruple precision available on some systems as the standard data type in STATPACK (e.g., qp = selected_real_kind( precision( 1.0d0 ) + 1 ) It is expected that this precision may not be available on all machines.
   • low kind for real/complex stnd data types in STATPACK requests to use a real implementation “low” which provides at least 6 decimal digits of precision and an exponent range of at least 10^+-35 as the standard real or complex data type in STATPACK. This would be suitable for low accuracy computations. It is expected that this precision will be available on all machines.
   • normal kind for real/complex stnd data types in STATPACK requests to use a real implementation “normal” which provides at least 12 decimal digits of precision and an exponent range of at least 10^+-50 as the standard real or complex data type in STATPACK. It is expected that this precision will be available on all machines.
   • extended kind for real/complex stnd data types in STATPACK requests to use a real implementation “extended” which provides at least 20 decimal digits of precision and an exponent range of at least 10^+-80 as the standard real or complex data type in STATPACK. It is expected that this precision may not be available on all machines.

   Refer to the The_Kinds module for the exact definitions of all these different Fortran kind types.

   By default (e.g., if you don’t change anything in the Select_Parameters module, the parameterized stnd and extd real/complex kind types will both correspond to double-precision.

   Both the integer (i1b, i2b, i4b and i8b) and logical (e.g., lgl) kind types available in STATPACK are parameterized in the same way. By default, the i1b, i2b, i4b and i8b integer types refer to 1-, 2-, 4- and 8-bytes integers and the lgl logical type refers to the standard logical type, defined as:

   !
   i1b   = selected_int_kind( 2  )
   i2b   = selected_int_kind( 4  )
   i4b   = selected_int_kind( 9  )
   i8b   = selected_int_kind( 10 )
   !
   logic = kind( .true. )
   

   See the definitions in the The_Kinds module for more informations. Again, these definitions can be altered by commenting/uncommenting statements in the Select_Parameters module.

   Finally, note that you can use the Fortran program test_kind.F90 (located in $STATPACKDIR/sources) to determine the available integer, real and logical kind types available on your computer at the hardware level and their properties. To compile and execute this program, simply execute the following make command:

   $ make test_kind
   

   in the main STATPACK directory (e.g., in $STATPACKDIR) and examine the standard output of the program on the screen. Note that if a real, integer or logical kind type defined in the The_Kinds module is not available on your computer, the named integer constant associated with it will be negative. Obviously, in that case, the associated kind type cannot be used in STATPACK.

   Finally, as you can see in the Select_Parameters module, you can also modify manually other global parameters related to OpenMP compilations and cross-over between serial to vector algorithms (used only in the Utilities module) before proceeding to the compilation of the STATPACK library. This is useful if you need to tune STATPACK for improved efficiency on your platform. All the global control parameters of STATPACK are set in the Select_Parameters module.

6. For compiling and creating the STATPACK library, once you have built your own make.inc and customized appropriately the file $STATPACKDIR/sources/Module_Select_Parameters.F90 with your choice for the real/complex kind types (stnd and extd), integer kind types (i1b, i2b, i4b and i8b) and logical kind type (lgl) used in STATPACK, execute the make command:

   $ make lib
   

   in the $STATPACKDIR or $STATPACKDIR/sources directory. If no errors are generated during this step, a static version of STATPACK library is now installed successfully on your computer (e.g., in the directory that you have specified in the Shell variable DIRLIB defined in your make.inc file). The library is called lib$(LIB).a, where the Shell variable LIB is specified in your make.inc file.

   All the public entities available in STATPACK are organized and grouped in Fortran 90 modules. The previous make command just compiles all the STATPACK modules taking into account the dependency between them. The compilation of each STATPACK module creates a .mod file and a .o file (note that some compilers do not create .mod files, however). The .mod file is used by the compiler at compile time to provide information about module contents. The .o file (if generated) contains the code of the STATPACK module procedures and must be specified when creating an executable file using the STATPACK procedures from this module.

   All the .o files are subsequently joined together in the STATPACK library, which is located in the directory you specified in your make.inc file, after the successful completion of the make lib command.

   Similarly, all the .mod files (if they exist) are located in the directory you specify in the Shell variable INTERFACES (again defined in your make.inc) or in the $STATPACKDIR/sources directory if this Shell variable INTERFACES is empty in your make.inc or if you didn’t specify the appropriate compiler option to tell to the compiler where to write these .mod files.

   On the other hand, if compilation errors occur at this step, please look at the section Preprocessor cpp macros and check if some cpp macros listed there can be useful for solving your compilation problem and must be added to the compilation options specified in your make.inc (e.g., in the Shell variable OPTS).

7. For creating a shared version of the STATPACK library (this is optional), execute the make command:

   $ make dynlib
   

   in the $STATPACKDIR directory. This shared library is installed at the same place (e.g., see the value of DIRLIB in your $STATPACKDIR/make.inc) than the static version of the STATPACK library. The shared library is called lib$(LIB).so, where LIB is specified in your $STATPACKDIR/make.inc file.

8. Next, if you want to make sure if STATPACK routines work or not, you may now run some testing programs, which are provided in the subdirectory $STATPACKDIR/tests of the STATPACK distribution. To run these installation tests, once you have built the library, you can enter the commands:

   $ export OMP_NUM_THREADS=2     # If STATPACK has been built with OpenMP support
   $ make test_install
   

   The results of the tests are listed on the screen and are written in the file test_install.output, which is located in the subdirectory $STATPACKDIR/tests.

   Examine the outputs for any obvious errors or problems. Notice, however, that these testing programs are not fully complete in this version of the software. In particular, the fact that some results of the tests are incorrect may only means that you have a (slight) loss of precision in some of the routines available in STATPACK. Additional checking is available with the make command:

   $ make test_more
   

   The results of these new tests are also listed on the screen and written in the file test_more.output, which is also located in the subdirectory $STATPACKDIR/tests. Examine again the output for any obvious errors or problems. Similarly, the fact that some results of these new tests are incorrect may only means that you have a (slight) loss of precision in some of the routines available in STATPACK and do not preclude the use of other STATPACK procedures.

9. Finally, to clean all the directories after building the library and running the test programs, enter the make command:

   $ make clean
   

More details on the available commands for compiling and managing the STATPACK code can be found in the headers of the makefiles $STATPACKDIR/makefile and $STATPACKDIR/sources/makefile. As an illustration, you can use the following Makefile commands for managing the STATPACK source code and library (assuming that your current directory is $STATPACKDIR):

• If for some reasons you want to destroy the present version of the STATPACK library and the associated .mod files, enter the make command:

  $ make clean_lib
  

• On many systems, you can also force the recompilation of all the source files (e.g., modules) in STATPACK by using the make command:

  $ make lib FRC=FRC
  

• Finally, if you have set correctly the Shell variable CHECKFLAGS in your make.inc file, you can check the Fortran syntax in all the STATPACK modules, by entering the make command:

  $ make check_all
  

The following sections provide more details on how to activate OpenMP support when compiling STATPACK, and on the UNIX preprocessor cpp macros, which can be used to compile/optimize STATPACK or solve some compilation problems with STATPACK.

OpenMP compilation

STATPACK is a parallel, multi-threaded library based on the OpenMP standard [openmp]. Support for at least OpenMP 3.0 API is requested for activation of OpenMP parallelism in this version of STATPACK.

In order to activate OpenMP parallelism in the STATPACK library, all compilers require you to use an appropriate compiler flag to turn on OpenMP compilation.

The table below shows what compiler option to use for several well-known Fortran compilers:

OpenMP compilation flags

Compiler	Compiler commands	OpenMP flag
GNU	gfortran	-fopenmp
Intel	ifort	-openmp or -qopenmp
Intel	ifx	-openmp or -qopenmp
AMD AOCC	flang	-mp
PGI	pgfortran, pgf95, pgf90	-mp
NVIDIA	nvfortran	-mp
NAG	nagfor	-openmp
IBM XL	xlf90_r, xlf95_r, xlf2003_r	-qsmp=omp

Additional information on OpenMP compilation options provided by a large range of current Fortran compilers can be found at OpenMP compilers. You will also find several examples of how to activate OpenMP compilation for various compilers/platforms in the template make.inc files under the subdirectory $STATPACKDIR/makeincs.

How to activate parallelism when executing a program using STATPACK routines compiled with OpenMP support is described below in the section Parallel execution.

Preprocessor cpp macros

The STATPACK library uses the standard UNIX preprocessor, cpp, in order to allow some flexibility in the compilation of the STATPACK library and enhanced performance at execution. The cpp preprocessor is only used for conditional compilation of some parts of the STATPACK source code at the user option. This is typically done by defining some UNIX preprocessor cpp macros (e.g., variables governing conditional compilation in the STATPACK source files) at the compilation step of STATPACK, usually by specifying -Dname as a compilation option, where name is a preprocessor cpp macro. Note that there is no space between -D and name. Each occurrence of -D defines a single macro and the -D option can appear many times on a command line.

Please note that your compiler may have other options for specifying UNIX preprocessor cpp macros (this is for example the case of the IBM XL Fortran compiler on IBM UNIX-like systems).

The following preprocessor cpp macros are currently used in the STATPACK source code and can be defined at compilation of STATPACK software in the Shell variable OPTS defined in your make.inc file:

• _F2003 for activating the use of Fortran 2003 constructs and modules inside the STATPACK library. Please note that this includes the use of the intrinsic IEEE_EXCEPTIONS, IEEE_ARITHMETIC and IEEE_FEATURES modules available only in Fortran 2003 (see [Fortran] for further details). More specifically, the detection of NaNs in the STATPACK library will be done with the help of the ieee_is_nan() provided by the IEEE_ARITHMETIC module if the preprocessor cpp macro _F2003 is activated.
• _ISNAN for activating the detection of NaNs in the STATPACK library by the intrinsic isnan() function, if your compiler supports this intrinsic function and the IEEE_ARITHMETIC module is not available with your compiler. The preprocessor cpp macro _ISNAN has no effect if the preprocessor cpp macro _F2003 is also activated.
• _SCALE lets you select how numerical constants defined as integer powers of two are computed in the STATPACK library. If _SCALE is activated at compilation these numerical constants are computed with the scale() intrinsic function instead of direct exponentiation. This macro improves the portability of STATPACK for compilers which do not implement correctly exponentiation with integers or, alternatively, the scale() intrinsic function.
• _NOT_DENORMALIZED lets you inform STATPACK if denormalized floating point numbers are supported or not by your compiler. _NOT_DENORMALIZED can be activated at compilation for improving the accuracy of some scaling constants for computing Euclidean or Frobenius norms if you are sure that denormalized floating point numbers do not exist in the floating point arithmetic of your computer.
• _BLAS lets you activate the use of an optimized/multi-threaded BLAS library [blas] inside STATPACK as described in the section Parallelism and BLAS. Note that the name and path of this BLAS library must also be specified with the help of compiler/loader options in your make.inc file as described in the section Basic installation. Using the _BLAS cpp macro usually results in enhanced performance for most computing subroutines and functions available in STATPACK, especially if the _DOT_PRODUCT and _MATMUL cpp macros are also activated at the compilation of the STATPACK library. However, this will be true only if you links the STATPACK library with an optimized (and eventually multi-threaded) BLAS library such as GotoBLAS [gotoblas], OpenBLAS [openblas] or other vendor BLAS like Intel MKL [mkl]. Obviously, the _BLAS cpp macro can only be used if the parameterized stnd real/complex kind type you have selected corresponds to single- or double-precision on your platform.
• _DOT_PRODUCT tells to the Fortran compiler to replace each instance of the Fortran 90 intrinsic function, dot_product(), in the STATPACK source code by the corresponding STATPACK function, dot_product2(). Use the cpp macro _DOT_PRODUCT, if you suspect that the intrinsic Fortran 90 routines of your Fortran compiler are not optimized or efficient. If the cpp macro _BLAS is also defined, the BLAS subroutine dot() will be used. On many systems, the dot_product2() function is (much) faster than the intrinsic dot_product() function if the _BLAS cpp macro is also activated at the compilation of the STATPACK library.
• _MATMUL tells to the Fortran compiler to replace each instance of the Fortran 90 intrinsic function, matmul(), in the source code by the corresponding STATPACK function, matmul2(), which uses a blocked algorithm and is also multi-threaded when OpenMP is used. Use the cpp macro _MATMUL, if you suspect that the intrinsic Fortran 90 functions of your Fortran compiler are not optimized or efficient. If the cpp macro _BLAS is also defined, the BLAS subroutines gemm() and gemv() will be used instead of an OpenMP multi-threaded version of matmul(). On many systems, the matmul2() function is (much) faster than the intrinsic matmul() function, especially if the _BLAS cpp macro is also activated or if OpenMP is used at the compilation of the STATPACK library.
• _TRANSPOSE tells to the Fortran compiler to replace each instance of the Fortran 90 intrinsic function, transpose(), in the source code by the corresponding STATPACK function, transpose2(), which is multi-threaded when OpenMP is used. Use the cpp macro _TRANSPOSE, if you suspect that the intrinsic Fortran 90 functions of your Fortran compiler are not optimized or efficient. On many systems, the transpose2() function is (much) faster than the intrinsic transpose() function, especially if OpenMP is used at the compilation of the STATPACK library.
• _USE_GNU signals that the GNU gfortran compiler is used for compiling the STATPACK library. This includes only the activation of the _RANDOM_GFORTRAN cpp macro (described below) in this version of the STATPACK library.
• _USE_INTEL signals that the INTEL ifort compiler is used for compiling the STATPACK library. This includes only the activation of the _WHERE cpp macro (described below) in this version of the STATPACK library.
• _USE_NAGWARE signals that the NAG nagfor compiler is used for compiling the STATPACK library. This includes the activation of the _RANDOM_NAGWARE, _INTERNAL_PROC and _ORDERED cpp macros (described below) and the deactivation of some OpenMP directives/constructs in this version of the STATPACK library.
• _USE_PGI signals that the PGI pgfortran (or pgf90, pgf95, …) or NVIDIA nvfortran compilers are used for compiling the STATPACK library. This includes only the deactivation of some OpenMP directives/constructs in this version of the STATPACK library.
• _ALLOC for allocating some local variables instead of of placing them on the stack in some subroutines and functions available in STATPACK.
• _WHERE for replacing Fortran 90 where constructs by do loops inside some OpenMP directives/constructs. This is useful for some compilers, like the INTEL ifort compiler, which does not allow where constructs inside some OpenMP directives in their OpenMP implementation.
• _ORDERED for deactivating OpenMP DO directives, which contain an OpenMP ORDERED clause. Useful for some compilers, which do not support (or do not implement correctly) the OpenMP ORDERED clause in their OpenMP implementation.
• _INTERNAL_PROC for deactivating OpenMP parallelization for sections of codes, which contain calls to internal procedures. This is useful for some fortran compilers like the MIPSpro f90 and the NAG nagfor compilers, which do not allow such possibility in their OpenMP implementation.
• _NOOPENMP2 for deactivating OpenMP parallelization in the tridiagonal eigensolvers and bidiagonal SVD solvers based on the implicit QR method available in the STATPACK library. Use only this cpp macro in case of OpenMP compilation problems with the EIG_Procedures and SVD_Procedures modules, included in the STATPACK library. Use of this cpp macro will result in a large performance degradation of the tridiagonal eigensolvers and bidiagonal SVD solvers based on the implicit QR method available in STATPACK.
• _NOOPENMP3 for deactivating OpenMP parallelization in the low-level subroutines and functions exported by the Utilities module available in STATPACK. By default, if OpenMP is used, these low-level routines are parallelized with OpenMP.
• _STAT for printing statistics on the number of deflated singular values in subroutines implementing the QR algorithm for bidiagonal matrices. Currently, this cpp macro is only used in the SVD_Procedures module available in STATPACK.
• _RANDOM_NOUNIX for signaling that the operating system is not UNIX. This cpp macro is only used in the Random module available in STATPACK.
• _RANDOM_WITH0 for generating real floating point numbers in the [0,1[ interval instead of the ]0,1[ interval with the random generators available in the Random module included in STATPACK. This cpp macro is only used in the Random module available in STATPACK.
• _RANDOM_NOINT32 for signaling that 32 bit integers are not available with the compiler. This imposes some restrictions on the random generators available in STATPACK. This cpp macro is only used in the Random module available in STATPACK.
• _RANDOM_GFORTRAN for signaling that the UNIX integer getpid() function is considered as an intrinsic rather than an external procedure, as for the GNU gfortran compiler.
• _RANDOM_NAGWARE for signaling that the UNIX functions/subroutines, like the UNIX integer getpid() function, are part of the f90_unix_env Fortran 90 module when the NAG nagfor compiler is used. The cpp macro _RANDOM_NAGWARE takes care of this difference. This cpp macro is only used in the Random module available in STATPACK. Don’t use the cpp macro _RANDOM_NAGWARE with other Fortran compilers since this will generate compilation errors for the Random module.

Examples of use of these preprocessor cpp macros for the compilation of STATPACK can be found in the template make.inc files under the subdirectory $STATPACKDIR/makeincs.