Contents

13 Tests and example input and output files

A set of test and example runs is provided in the distribution of sapt2012. These include several very small cases which should finish in seconds or minutes and which can be used to check the correctness of the sapt2012 installation. In each case, both the complete set of input files and the output files (at least from one platform) are provided. With the large number of front-end SCF programs interfaced with sapt2012 and with the large number of hardware platforms on which it can be run, it is not practical to provide examples for all possible cases. The mix of combination of various factors chosen should be sufficient to establish the correctness of installation and help in preparation of user’s production runs.

In some cases, the test files compute all currently available SAPT corrections. This is not needed for calculations of interaction potentials. In such calculations, use one of the SAPTn control variables to select the minimal needed set of corrections. This will reduce the time of calculations.

13.1 The examples directory

The directory ./SAPT2012/examples is divided into subdirectories corresponding to different SCF front-end programs, e.g., gamess or atmol1024. Each of those subdirectories contains the following test job directories (named the same for all SCF programs):

• BER: a very small test calculation for the beryllium dimer in a DCBS consisting of a 2s1p set on each atom. The run will complete in a few seconds using 0.1 Mwords of memory and should be tried first. We note again the naming convention for clarity: for atmol1024 the dimer files are called BER.intinp and BER.scfinp, the monomer A files are called BERA.intinp and BERA.scfinp, the monomer B files are called BERB.intinp and BERB.scfinp, and the perturbation file input is given by BERP.data. The input files needed when using gamess are called BER.inp, BERA.inp, and BERB.inp (integral/SCF input files) and BERP.data (perturbation input file). Monomer A and monomer B input files are created by setting the charge to zero on the proper site. For example, in the case of monomer A the charges on site B should be set to zero. The perturbation program should produce the results given below in Appendix D. These results can be found in the Summary Table at the end of an output.
• HF2_DCBS: the HF basis set [4s2p1d∕2s1p] is taken from Ref. 48, and a 2s1p set of midbond functions is added. Needs about 1 Mword of memory and takes less than a minute to complete. In the gamess input files, the option ISPHER=1 is used, so that the results of this test performed with gamess should agree with those from an atmol1024 run.
• HF2_MCBS: the MC⁺BS version of the above: monomer basis set (files HF2MA.* and HF2MB.*) are obtained by removing the d and p orbitals of F and H, respectively, of the “ghost” molecule. In the gamess version of this test, the “tags” technique is used to enforce MC⁺BS, whereas in the atmol1024 version, the basis functions are arranged in blocks polA, isoA, mid, isoB, polB, as described in Sec. 10.1.2 . As in the DC⁺BS variant, the space spanned by the basis functions is always restricted to spherical Gaussian functions, even in the gamess version.
• ArHF_DCBS: the basis set [8s5p2d1f∕6s3p2d1f∕3s2p1d] has been taken from Ref. 58. No midbond functions are present here. This run will need about 6 Mwords of memory and about 4 minutes to complete (on an Opteron 252 machine).
• ArHF_MCBS: an MC⁺BS version of the above. Monomer basis sets (in files ArHFMA.* and ArHFMB.*) are obtained by deleting the polarization functions (d and f on F and Ar and p and d on H) of the “ghost” molecule. The “tags” technique is used for MC⁺BS for both the gamess and atmol1024 examples.
• CO2D_MCBS: an MC⁺BS run for the CO₂ dimer in the basis of Ref. 51 (DCBS size: 200, MC⁺BS size: 149). This example is larger than the previous ones, it requires about 40 Mwords of memory and takes slightly less than two hours to complete on an Opteron 252 machine. The gaussian and molpro versions of this example are also provided (note that these two require the specification of monomer A/monomer B/dimer sets using the “tags” mechanism presented in Sec. 10.1.2 ).
• C6H6_H2O_ADZM: the benzene-water dimer in a 262-term basis. This is the largest example included and will take about 27 hours (on an Opteron 252) to complete.

Some additional examples are also included, namely

• GAMESS/HF_NH3_MCBS: an example illustrating the use of the MC⁺BS technique in gamess with the “tags” and “basis” options, as described in Sec. 10.1.2 . About 7 minutes on a 2.80 GHz processor.
• ATMOL1024/ArH2O_MCBS: an example of using the RunlotATMOL script, as described in Sec. 10.6 . Consists of two jobs, each taking about 6 minutes on an Opteron 252.
• ATMOL1024/Ar2_FROZENCORE_3ORDER: an example of calculating the third-order SAPT corrections in Eq. (9 ), and of performing a frozen core calculation. The files Ar2P.data.allelectron and Ar2P.data.frozencore present in this example’s subdirectory correspond to an ordinary all-electron calculation and a frozen core calculation, respectively. Rename either one to Ar2P.data and invoke the SAPT script. The basis set employed is aug-cc-pVQZ+(3s3p2d2f1g) midbond, and the MC⁺BS approach is used. The calculation requires about 1.5 hours (all-electron) or half an hour (frozen core) on an Opteron 252.
• ATMOL1024/HE2_E2DISPCCD: an example of the CCD+ST(CCD) dispersion energy calculation (Sec. 10.4 ) for the helium dimer in the d-aug-cc-pVQZ basis set. This calculation will take about 15 minutes on an Opteron 252. A gaussian version of this example is also provided.
• MOLPRO/ArHF_AVDZ: a simple example for a molpro–sapt2012 calculation. Note that for molpro a single input file ArHF.molpro takes care of all integral and SCF calculations and only the usual ArHFP.data post-SCF input file is needed as well. This example takes less than two minutes on an Opteron 252. A relativistic version of this example, showing how to use SAPT with the molpro front end and the second-order Douglas-Kroll-Hess relativistic Hamiltonian, can be found in the same directory (files ArHFrel*). An atmol1024 equivalent of this example (the nonrelativistic version) is also provided.
• MOLPRO/KR2_ECP: an example of using sapt2012 with an effective core potential. An ECP basis set aug-cc-pVTZ-PP [59] supplemented by a (3s3p2d2f1g) midbond set is employed for the van der Waals minimum of the krypton dimer. This example takes slightly more than two hours on an Opteron 250.
• DALTON/He2: helium dimer example with basis set larger than 255 basis functions. The dalton input files have .dal and .mol extensions.
• saptdft: a few examples utilizing SAPT(DFT) with dalton interface and DF-SAPT(DFT) with orca interface. ArHF is a quick example of basic SAPT(DFT) usage. Directories Ne2-aTZ-GGAKER and Ne2-aTZ-LDAKER contain neon dimer with GGA kernel or LDA kernel (default), respectively (see Sec. 16.2 ). H2O2_MCBS contains water dimer example with calculation of δE_int,resp^HF. Finally, C6H6 contains a large calculation for benzene dimer. All examples except ArHF utilize RunlotDALTON, described in Sec. 10.6 .
• dfsaptdft: examples utilizing DF-SAPT(DFT) with dalton interface.
• ORCA: water dimer examples utilizing DF-SAPT(DFT) with orca interface, compared with analogous jobs with dalton interface.

13.2 Running test jobs

The simplest way to run an example is to copy all files from the corresponding directory (e.g., ./SAPT2012/examples/ATMOL1024/BER) to a scratch directory, then cd to this scratch directory and submit the job using the submit line described in Sec. 10, for example, in ksh

Recall that the string BER is the same as the initial part of the name of all input files. If the ./SAPT2012/bin directory is not in your PATH, you may need to supply the full path to the SAPT script.

To simplify the process of running multiple tests, two simple ksh scripts, runtstGAMESS and runtstATMOL are provided in the directories ./examples/GAMESS and ./examples/ATMOL1024, respectively. The scripts execute loops over the subdirectories selected in the for statement, running the SAPT script inside these directories, and cleaning up after each such run. To select the jobs to be executed, adjust the for statement in runtstGAMESS and runtstATMOL. The names of output files from the tests are given an ending (see the variable MACHINE) which can be used, e.g., to distinguish between the runs performed on different platforms.

Under Unix, the output file can be viewed while the program is run. This allows to check how far the program has advanced. Note, however, that Unix first writes the data to fairly large buffers, and only when the buffers are filled, to the output file. It is important to remember about it when debugging the program (some info may not appear in the output after a crash, although it may come from a successful part of the run). SAPT uses instructions flushing buffers in several places but more such statements may have to be added for debugging. Also, for larger runs, one should monitor the disk use (by just doing ls -lt or du -k in the working directory). The memory actually used by the program can be checked by using the top command (called prstat or monitor on some systems). When the program crashes, our practice shows that in most cases it is due to errors in the integral/SCF parts of the code. Thus, make first sure that these stages have finished successfully. When there is an error there, consecutive stages of the code do start (and immediately fail), creating an impression that the code crashed in a later stage than it was the case.

Once the test runs are completed, the results, especially the Summary Table at the end of each output file, should be compared to the reference ones, provided in each test directory for at least one platform. One can notice slight differences between the results obtained with different front-ends and/or on different platforms. In any case, reproducibility of at least 5 significant digits should be expected. The main differences come in the corrections using the converged CCSD amplitudes. The CC convergence threshold has sometimes to be adjusted to obtain several digit agreement. Notice also that in different versions of sapt the threshold was changing between relative and absolute, which of course makes a significant difference.