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):

Some additional examples are also included, namely

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

SAPT BER scfcp > BER.out 2>&1 &

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.