A good place to look for the description of input to atmol1024 is Paul Wormer’s web page, http://www.theochem.ru.nl/~pwormer (strictly speaking, this is a description of the older version of atmol, but the input options are the same as for atmol1024). Below we discuss several options relevant for a sapt2012 run.
It is convenient to reduce printouts from the integral (integw) module of atmol1024 by adding the directive NOPRINT GROU GTOS to the “intinp” files. This will suppress printing of the groups or ordered Gaussian Type Orbitals (GTOs). Adding the word BASI to the list will also suppress the basis set printout. To avoid computation of the multipole integrals, not needed in a SAPT calculation, include the directive BYPASS PROPERTY (this may be important especially on SGI machines, where the absence of such directive may cause a run-time error). Inclusion of a line FPRINT NVCT NEIG NFTE NITE NPOP in the *.scfinp input files will ask the scf program to skip the printout of the vectors, eigenvalues, Fock trial matrix, iterations, and populations for that run.
When the supermolecular SCF interaction energy is calculated during a SAPT run, i.e., when the scfcp option is in effect (most runs are like this), the files nameA.intinp and nameB.intinp should contain the directive BYPASS TWO to avoid recalculation of two-electron integrals. This directive should not be present in the file name.intinp or, in the case of a MC+BS calculation – in nameMA.intinp and nameMB.intinp (name denotes here the name of the job). If the supermolecular SCF calculations are not performed, i.e., if the scfcp option is not in effect, then the directive BYPASS TWO must be also removed from the file nameA.intinp. See Sec. 10 for further explanation.
On old Linux platforms with the g77 compiler, there is a 2 GB restriction on the size of any file. In such a case, if the two-electron integral file generated by atmol1024 is likely to exceed this size, it has to be split into several pieces each 2 GB or less. For example, if the integrals are anticipated to take 5 GB of disk space, one should have them distributed over at least three files. This can be done by specifying
MAINFILE MT3 MT4
MT5
MAXBLOCK 499999
in the *.intinp files, somewhere below the basis set specification but before the ENTER directive. The first of the lines above means that the files called MT3, MT4, MT5 will be used to store the integrals, and that the size of each will not exceed MAXBLOCK*511*8 bytes, which in this case amounts to somewhat less than 2 GB (the number 511 comes from some internal data structures of atmol1024). Now we have to tell the transformation module of sapt2012 how many files atmol1024 produced by including NMFILES=3 in the TRN namelist in the *P.data input file (see Secs. 10 and 10.2 for description of this file). Of course, the number “3” would have to be changed if some other number of MT* files were used. atmol1024 and sapt2012 support up to 18 such files, MT3 through MT20. This option is left for compatibility but is not necessary on modern Linux distributions.
The cadpac interface to sapt2012 is not maintained anymore, however, it is likely to work. Notice that cadpac can use only Cartesian basis functions, and only angular functions up to f are allowed. The input file used for cadpac runs must include the SAPT keyword. This keyword makes cadpac write out to a file the SCF vectors and other information in the format required by the sapt2012 transformation code tran. Thus, there is no interface program required for cadpac.
cadpac was the first front-end for SAPT(DFT) and the use of this package may be still be of some interest despite the slowness of this interface due to the large number of DFT eXchange Correlation (XC) functionals implemented in cadpac. Notice, however, that the complete SAPT(DFT) [14], with coupled Kohn-Sham dispersion and induction energies, does not work anymore with cadpac (it works with dalton 2.0 and Orca only).
To run sapt2012 with cadpac as the front-end, a special script /SAPT2012/bin/SAPT_CADPAC should be used instead of SAPT used for all other SCF programs.
When using gaussian with sapt2012, a symbolic link in the compilation script Compall is made to point to the util.a file in the gaussian directory structure. The transformation module tran of sapt2012 links to this library to be able to read the rwf and two-electron integral files. In the input to the post-Hartree-Fock stage of the calculation (the file nameP.data), in the TRN namelist, the user must specify either ISITG94=T for gaussian94 or ISITG03=T for gaussian98, gaussian03, or gaussian09. In the latter case, the variable GAUEXE, set up during the compilation of SAPT, is passed to the script so that it knows whether to execute g98, g03, or g09.
In gaussian94 and in newer versions of this code, the default method of SCF calculations is direct (two-electron integrals calculated in-core and not written to disk). Since sapt2012 always needs the two-electron integrals, the command SCF=(CONV), which stands for “do conventional SCF”, must be used to force the two-electron integrals to be written to disk. Note that in the conventional (non-direct) mode gaussian is limited to s,p,d,f basis functions and one must use a different integral and SCF front-end when g (or higher) functions are present in the basis set. We recommend the SCF=(TIGHT,CONV) keyword to be used to tighten the SCF iterations convergence criteria. Moreover, the keywords SYMM=NOINT and NORAFF must be present in all inputs to gaussian since SAPT does not use the point group symmetry of integrals and accepts integrals in the regular (non-Raffenetti) format only. For unknown reasons, these settings do not always work in gaussian03 if the default method of selecting the initial guess for the SCF iterations is used. In case of such problems, the user should specify GUESS=INDO so that the initial guess is obtained using the method which was the default in gaussian98 and previous releases (note that the GUESS=INDO keyword is not understood by gaussian98 and older versions). Finally, we remind the user that the MASSAGE keyword should be used in gaussian when setting the charges to zero (e.g., to perform an SCF run for a monomer in a dimer-centered basis set).
In order to ensure that the SCF energies from gamess are printed with a sufficient number of decimals, we recommend one FORMAT change in the rhfuhf.src module, prior to compilation of gamess. In the subroutine RHFCL, the statement
should be replaced by:
Please note that standard (non-direct) SCF calculations must be performed and some options in the gamess input must have specific values:
Whereas most other integral/SCF packages are invoked in the SAPT script by just executing a given program, gamess needs its own script, ./SAPT2012/bin/runGAMESS, called from the SAPT script. runGAMESS is a slightly modified version of the standard script rungms distributed with gamess. As already pointed out in Sec. 8 , the user must edit this script and supply the appropriate value of the TARGET variable. The targets sockets and sgi-mpi have been extensively tested, while other targets may require some additional customization to make gamess run. These additional changes are independent of the sapt2012-related portions of runGAMESS and, if needed, can be introduced with the help of the standard gamess documentation.
If you rather prefer your own gamess script instead of runGAMESS, you can easily adapt it for use with sapt2012 by following these steps:
where
All the parameters in the invocation of runGAMESS are set automatically in the SAPT script upon compilation of sapt2012 or at run time. Your custom-made replacement of runGAMESS should recognize these command-line parameters instead of having them hard-coded, as it is usually the case with the standard rungms.
where SCR denotes gamess scratch directory and JOB is a script variable which will be set by the SAPT script on each call to gamess.
The sources of gamess—sapt2012 interface are located in the ./SAPT2012/misc/gamint subdirectory. The interface consists of the Fortran program gamsintf.f which extracts one-electron integrals and SCF vectors from the “dictionary” file of gamess, and two simple awk scripts, gms_awk1 and gms_awk2, which scan the gamess standard output for the number of basis functions, occupied orbitals, and system geometry.
The dalton 2.0 interface was tested on machines with 32-bit integers only (but most of the ‘64-bit’ architectures, including AMD64 and IBM64, have 32-bit integers). dalton must be compiled without -DVAR_SPLITFILES option and the operating system must support files larger than 2 GB. The input file .dal must include .INTERFACE directive in **WAVE FUNCTIONS and .NOSUPSYM in *ORBITAL. If the job has more than 255 basis functions, .NOSUPMAT in *AUXILLIARY INPUT is required, see examples/DALTON/He2. The symmetry must be switched off. For larger basis sets, prone to linear dependencies, .AO DELETE and .CMOMAX in *ORBITAL INPUT should be set to a small and a large value (e.g., 1.D-8 and 1.D+5), respectively, to suppress removing of quasi-linear dependencies from the basis set combinations since sapt2012 would not work if such a removal is performed. It is recommended to compile dalton with the same compiler as SAPT.
When using molpro as an integral and SCF front end, only one molpro input file that takes care of the dimer and both monomers is required irregardless of whether the DCBS/DC+BS (Sec. 10.1.1 ) or MCBS/MC+BS (Sec. 10.1.2 ) approach is used. The SAPT script assumes that this file is named name.molpro where name is the name of the job. Example name.molpro files can be found in the examples/MOLPRO subdirectory of sapt2012. Several important things should be kept in mind when writing the name.molpro file:
for monomer A and
for monomer B. Note that the order of some of these keywords is important as molpro2006 appears to forget the SCF energy after the data,copy command. The interface also needs the variable nucrep containing the nuclear repulsion term between monomers:
Later in the script, all three SCF energies should be listed with sufficient precision
as the SAPT programs extract these values from the output of the molpro part of calculation. If the supermolecular SCF interaction energy is not requested, the dimer SCF energy edim is not needed, however, the nuclear repulsion energy for the dimer nucdimer is still required. The simplest way to get nucdimer is to request a zero-iteration SCF calculation for the dimer in some minimal basis set like STO-3G:
Starting from the sapt2008.1 release, the molpro interface supports the use of a monomer-centered basis set as well as of a dimer-centered one. An example of an MC+BS sapt2012 run employing the molpro interface can be found in the directory ./SAPT2012/examples/MOLPRO/CO2D_MCBS. Several changes in the molpro input file name.molpro are needed to perform an MC+BS run:
The post-SCF input file nameP.data must in this case contain the BLKMB=F directive so that the assignment of the basis functions to monomer A/monomer B/dimer sets is specified using the ‘tags’ mechanism, cf. Sec. 10.1.2 .
One should note that the geometry section of the final SAPT summary table looks a little different than usual when molpro is used as the integral and SCF front-end. The charges on the nuclei are not given, and all atoms (those of monomer A, those of monomer B, and dummy atoms) are listed together. Nevertheless, all energies calculated by SAPT should be correct.