[next] [prev] [prev-tail] [tail] [up]

8 Installing SAPT2012

Installation of sapt2012 is controlled by a universal script Compall, a small portion of which has to be customized by the user. The Compall script sets the compilation options appropriate for a given hardware platform and for the integral/SCF interfaces chosen. It then compiles and links all the pieces of the code, which sometimes requires access to the I/O libraries of the integral/SCF packages. If atmol1024 has been downloaded and the ./SAPT2012/atmol1024 directory is present, this package is also built. Finally, Compall updates the scripts used to run sapt2012 (SAPT, Runlot*) by inserting updated paths to executables. (The asymp_sapt package is installed by a separate script).

8.1 Compall installation script

The following adjustments must be made by the user to the Compall script:

  1. Execution shell: Change the first line of the script to one of the following:
    • #!/bin/bash : The Bash shell on a Linux box, or
    • #!/bin/ksh : The Korn shell on all other platforms.
  2. Integral/SCF program: Declare the SCF packages you wish sapt2012 to be interfaced with. An integral/SCF package is activated by simply setting the corresponding variable in the script to the complete path to the directory where the libraries (or executables, depending on the SCF package) of a given package are located (for example, GAMESS=/home/local/gamess). Otherwise set the variable to ‘NO’ (note the capitals). In addition, for gamess, the so-called “version number” environmental variable, VERNO=XX, needs to be specified (sapt2012 assumes that the name of the gamess executable is gamess.$VERNO.x). The list of SCF codes in Compall does not include atmol1024. This latter option is activated automatically if atmol1024 has been downloaded and is present in the ./SAPT2012/atmol1024 directory. Thus, you may set all the integral/SCF variables to ‘NO’, provided that atmol1024 has been downloaded. Otherwise at least one integral/SCF variable must be set by specifying the path. If atmol1024 is present and in addition one or more integral/SCF packages are selected, both atmol1024 and the explicitly selected interfaces should work with the created sapt2012 executables. In most cases, the sapt2012 codes use I/O libraries of the integral/SCF packages in order to read the data created by these packages. Therefore, a given SCF package has to be installed before sapt2012 and its libraries must be accessible. Three exceptions are cadpac, gamess, and dalton, which generate data read by sapt2012 using its own subroutines. The SCF programs that can be used to generate atomic integrals and SCF vectors for sapt2012 are
    • atmol1024: This is the current and maintained by us version of atmol [23], extended to handle up to 1023 basis functions. atmol1024 is the default integral/SCF package. The Compall script checks if the atmol1024 source is present in ./SAPT2012/atmol1024 subdirectory and compiles it automatically. (If for some reasons atmol1024 has to be kept in another location, and compiled separately, it can still be used by sapt2012 if the line ATMOL1024=NO in Compall is changed to reflect the current location of the atmol1024 main directory.) atmol1024 code has been tested with sapt2012 more extensively than any other package and is the recommended choice.
    • gaussian: gaussian94 (G94) and gaussian98, gaussian03, or gaussian09 [42] (G03). A full gaussian installation including the source code must be present at the location specified by the G94/G03 variable. A binary-only gaussian installation will not suffice. Set at least one of the variables G94, G03 to NO as these packages are mutually exclusive. The path specified here should contain the gaussian’s library util.a (usually it is the main directory of the gaussian distribution). Additionally, the variable GAUEXE holds the name of the gaussian executable (no path is necessary) so that the SAPT scripts know which executable to call. The default value GAUEXE=g09 must be changed if a different version is used. Finally, the Compall script declares a variable EXTRADEFS which is an empty string by default. If gaussian was compiled with the option -DI64 (64-bit integers, default on several architectures) and/or -DPACK64 (64-bit packing of integral indices, also default on a few platforms), the same set of options (-DI64 and/or -DPACK64) must be given to the variable EXTRADEFS so that the gaussian interface and the transformation program are compiled to work with this particular configuration of gaussian. These options do not affect running SAPT with any other integral and SCF front-ends.

      One should note that, as the SAPT codes are linked to the gaussian’s util.a library, the user must make sure that this library (and the whole gaussian code) has been compiled for exactly the same architecture as SAPT. For example, the Sun SPARC architecture (TARGET=sunf90) supports generation of codes for several different flavors of SPARC via the compilation option -xarch=PLATFORM. If gaussian was compiled for an architecture other than the default -xarch=generic, the user needs to edit all occurrences of -xarch=generic in both Compall and atmol1024/Makefile.sunf90, replacing generic by the architecture for which gaussian was compiled. It is not a problem if Fortran 77 (rather than Fortran 90 as in the case of SAPT) was used to compile gaussian for TARGET=sunf90, as the compatibility library -lf77compat is automatically linked in where necessary.

      SAPT does work with the latest releases of gaussian03 that support the AMD64 architecture. Note, however, that the TARGET=pgf90 architecture has to be chosen in this case despite the fact that for this platform, gaussian itself is compiled with pgf77. The TARGET=pgf77 setting is restricted to the 32-bit i386 architecture and will not produce a valid code on an AMD64 machine.

    • gamess [22]: sapt2008.1 works with the most recent release of gamess (dated 11 Apr 2008). If you want to use an older version of gamess, you may need to edit the file misc/gamint/gamsintf.F, subroutine OPENDA, changing the value of the variable IRECLN from 4090 to whatever is returned by the gamess function NRASIZ(10); see gamess source code, file iolib.src.

      If the gamess interface is used, set the variable GAMESS to the path where the gamess executable is located. Also set the variable VERNO which is the middle part of the name of this executable (e.g., for gamess.01.x, VERNO=01). The sole purpose of the variable GAMESS in Compall is to pass the path and name of the gamess executable to the SAPT execution script. No access is needed to any gamess files at the compilation time. Thus, compilation will proceed even if gamess is not installed beforehand.

      64-bit gamess: if you intend to use gamess compiled with a 64-bit integer (this happens by default on the ALPHA platform, but may also happen on SGI when “sgi64” is specified during compilation of gamess), replace the line GAMSI8=NO with GAMSI8=YES.

    • cadpac [52]: This package does not need any interface programs since the files created by it can be read directly by sapt2012 codes. Also, sapt2012 does not need access to any cadpac libraries, so that the compilation will proceed even if cadpac is not installed on your system.
    • dalton [37]: If used, set the path to wherever the dalton executable script is located. The sole purpose of the variable DALTON in Compall is to pass the path and name of dalton executable to the SAPT execution script. No access is needed to any dalton files at the compilation time. Thus, compilation will proceed even if dalton is not installed on your system beforehand.
    • orca [53]: If used, set the path with the orca executable files. Similarly as for dalton, the only use of the variable ORCA during the compilation is to pass the path to orca executable files to the SAPT execution script.
    • molpro [41]: If the molpro interface is used, set the variable MOLPRO to the full name of the molpro executable (including the path). All versions of molpro starting from molpro2002.1 up to and including molpro2010.1 are supported. During the compilation of sapt2012, no access to any molpro libraries is needed so the compilation will proceed even if molpro is not installed on your system beforehand. However, the molpro program itself must be modified and recompiled before using it with sapt2012 as the SAPT interface to this front-end has the form of a molpro patch. This interface is located in the misc/patch.molpro2sapt subdirectory and consists of four files: src/common/sapt1, src/common/sapt2, src/util/user.f, and src/util/user_sapt.f. The first two of these files must be placed in the src/common subdirectory, and the last two—in the src/util subdirectory of your parent molpro directory before recompiling molpro. Note that the standard distributions of molpro already contain a dummy version of the file src/util/user.f. It may safely be replaced by the file from sapt2012 if, as it is the case for a default molpro installation, no other user-supplied subroutines have been placed there. As a Fortran 90 compiler is required to build molpro, this interface has been tested only for such compilers (Portland pgf90 and Intel ifort on a 64-bit AMD architecture running Linux) so far.
    • aces: This interface has not been tested recently but might work.

    It is also possible to build the sapt2012 package for use with the older version of atmol (such a version, limited to 255 basis functions, is included in the asymp_sapt distribution). This can be accomplished by setting the variable ATMOL in Compall equal to the path of the main atmol directory (change the line ATMOL=NO) and removing or renaming the directory ./SAPT2012/atmol1024 (if present). The atmol package has to be compiled prior to the compilation of sapt2012. sapt2012 cannot be interfaced with atmol1024 and atmol simultaneously.

  3. PLATFORM: Two variables need to be set:
    • TARGET is the system on which sapt2012 will be compiled. This can be one of (all lowercase): sgi, ibm32, ibm64, alpha, g77, pgf77, pgf90, ifort, g77_32, g77_64, sunf90, or hpux. sgi stands for the Silicon Graphics ORIGIN or POWER CHALLENGE series computers with the MIPSPRO 7.3 or higher compiler, ibm32 – for the IBM RS6000 or SP machines (on 64-bit IBM platforms, ibm64 is also possible), alpha – for the (formerly DEC) ALPHA platform. g77 and pgf77 are used for a 32-bit LINUX box with the compiler g77 or pgf77 (Portland Group Fortran), respectively. If one needs to run SAPT on an old Linux machine which does not support files larger than 2 GB, splitting of all potentially large temporary files into 2 GB chunks can be turned on at compile time by adding the -DTWOGIGAMAX declaration to the variable EXTRADEFS at the beginning of the Compall file. On a 64-bit AMD platform running Linux, one may compile SAPT using the Portland Group Fortran 90 (Portland Group Fortran 77 will not suffice in this case) or the Intel Fortran Compiler (versions 8.1 and above) by setting TARGET=pgf90 and TARGET=ifort, respectively. For the compilation on 64-bit AMD using g77, the user needs to specify the g77_32 or g77_64 target flag for a 32-bit or a 64-bit binary, respectively. TARGET=pgf90 and TARGET=ifort work in the 64-bit mode by default; note, however, that atmol1024 does not work with TARGET=ifort in 64-bit mode. GNU Fortran95, gfortran is supported starting with SAPT2008.2, except for atmol, where some combinations of compiler versions/systems do not work. Since gfortran changed the file binary format between versions 4.1 and 4.2, it is strongly recommended that all programs (including SCF/DFT interface programs) are compiled with the same version of the compiler. TARGET=sunf90 is for the Sun SPARC machines equipped with the FORTRAN90 compiler. Finally, TARGET=hpux corresponds to the 64-bit Itanium architecture running HPUX and equipped with the HP Fortran90 compiler. Note that for this platform several necessary system calls (used, e.g., in the timing routines) are contained in the libU77.a library whose location may vary on different machines (/lib/hpux64 or other). To compile SAPT for TARGET=hpux, the user must make sure that the correct, 64-bit version of the libU77.a library is present in one of the directories in which the linker searches for libraries.
    • BLAS points to the Basic Linear Algebra Subprograms (BLAS) and the Linear Algebra PACKage (LAPACK) libraries. On SGIset BLAS=’ -llapack -lblas ’. On an ALPHA, set BLAS=’ -ldxml ’, on IBM AIX (RS6000 or SP4): BLAS=’ -lessl ’, and on SPARC: BLAS=’ -xlic_lib=sunperf ’. On Linux machines, one may set BLAS=’ -llapack -lblas ’, however, other options usually lead to substantially better performance. For example, if you have compiled yourself a self-optimizing BLAS library like ATLAS (http://math-atlas.sourceforge.net), set BLAS=’ -L<Full Path to Library> -llapack -lcblas -lf77blas -latlas ’. However, a simpler option which usually leads to only slightly lower performance may be to download the prebuilt ATLAS library for your architecture from, e.g., www.netlib.org. The efficiency of the BLAS library is important for the performance of SAPT and users are encouraged to use the fastest BLAS library on their machines. The performance of LAPACK, however, is of minor importance and if optimized LAPACK is unavailable, one can set BUILDLAPACK=YES in the Compall script and the subset of LAPACK required for SAPT will be compiled.
  4. Several additional preprocessor definitions may be specified during the compilation by listing them in the variable EXTRADEFS in the Compall script. This variable, equal to an empty string by default, may contain the options -DI64 and/or -DPACK64 defining the format of files imported from gaussian, the option -DTWOGIGAMAX which requests splitting of all large temporary files into chunks smaller than 2 GB, and/or, the definition -DTPDRVN used to switch on the old algorithm of calculating the four-virtual contribution to the monomer CC amplitudes using unsorted integrals. The default algorithm uses sorted integrals and is faster, especially when a well-optimized BLAS library is available, but it requires more disk space during the CC stage of the calculation.

Once all the variables mentioned above are set, simply type:

and the compilation should begin. Check compall.log to see if all is well. The Compall script will create a file ‘./SAPT2012/stamp.intf’ containing a summary of the settings you have used in the compilation. A subsequent invocation of Compall will detect any changes made to these settings since stamp.intf was last created and only those parts of the code which were affected by these changes will be rebuilt. Running the script ./SAPT2012/Cleandirs will restore the ./SAPT2012 directory to its “distribution” state, i.e., all object files and executables (except shell scripts) will be deleted and a subsequent invocation of Compall will start the compilation from scratch.

One more customization step may be required before sapt2012 is run with gamess as the SCF front-end: the ./SAPT2012/bin/runGAMESS script must be modified by setting the TARGET variable, which depends on the platform and on the way gamess has been compiled. In most cases, the default TARGET=sockets will be appropriate, although on SGI machines TARGET=sgi-mpi is also popular. Consult your local gamess installation. Further customization of runGAMESS will be needed for other targets (if you need to do such a customization, see examples given in both runGAMESS and the standard rungms script for the gamess distribution).

8.2 Compall_asymp installation script

If you have downloaded the asymp_sapt package, it will expand into ./asymp_SAPT directory. Change to this directory and use Compall_asymp script to build all programs in this package. The subdirectory doc contains the user’s manual for these programs. The asymptotics calculations are presently limited to 255 orbitals per monmer and the relevant codes are interfaced only with the older version of atmol (included in the asymp_sapt package). Furthermore, the POLCOR program computing the dynamic polarizabilities works only under SGI’s IRIX and IBM AIX operating systems.

8.3 Testing sapt2012 installation

Once the compilation has been completed successfully (if unsure, just grep the compall.log file for the word error), we strongly recommend that you perform as many tests as possible before starting to use sapt2012 for production runs. A suite of test jobs of varying size and for various SCF front-ends has been provided for this purpose in the subdirectory examples/. Sample outputs from different platforms can also be found there. For more information on running the test jobs, see Sec. 13.

[next] [prev] [prev-tail] [front] [up]