Run the program

On all systems it is possible to run a program from a so-called job card which are the shell scripts programmed with shell commands on Unix platforms. Those commands work similar as in usual programming languages and allow for complex controlling with branching and loops. There the input files for the program can be initiated or changed before being read and the output similarly can be processed before being written on external files. As an example the job card for the calculation of the total energy of a small GaAs bulk system is described:

#!/bin/csh
cd
cd qmc/TMP/bin
rmx gsh.out
date > gsh.out
time gsahga.exe << [EOF]
10.65
gitgs1h.dat
2398798
0.325
PHAGADAT.DAT
0.935
PHAASDAT.DAT
0.945
0.6
4.0
1000
4.0
10000
100
gitgs1h.dta
[EOF]
date >> gsh.out
date

Such a script can be directly started or within batch. The latter is not terminated if the user logs out in contrast to the former. To estimate the run time one usually first starts a short job before turning to production runs. The single lines of the script mean the following:

Different from Lithium the GaAs case does not need a preparation of the one-particle wave functions through a separate call to the special program vorslak.exe. The program start with time yields the output of the run time as a by-product. [EOF] marks the end of input for the program, i.e. the following lines are treated as they were typed on the keyboard up to the second occurrence of [EOF] (this string may be replaced by any other, the same on both occurrencies). The first line contains the lattice constant of the solid which is the length of the cube edge for cubic lattices. The system defining quantities are read from gitgs1h.dat [gitgsquad020208symz.dat, HRINITgitgsquad020208symz.dat] on the directory TMP which has been fixed within the program code. The following number is a 4-Byte integer as start value for the generator of the pseudo-random numbers. Using this same value again the same random numbers will occur and the run is exactly reproduced provided the same file gitgs1h.dat is used, of course. As next the Jastrow parameter is read and subsequently the name of the file on TMP where the basic one-particle wave functions are stored. For Galliumarsenide this takes first the Ga wave function with the subsequent Ga Slater parameter and then the file name associated with As, the parameter for As, and at last a further Slater parameter for combination. The next steps are identical for all applications. The parameters for thermalization that denote the maximum step length (here 4.0 Bohr) and the number of steps per electron are fixed. During this period no observable is sampled. This occurs on the next stage and the parameter for the step length is read. It is optimized here for the case of about 50% acceptance probability of the step to yield the best relation between run time and statistical accuracy. It might have been chosen differently for thermalzation. After taking the number of steps per electron an integer, say n (here 100), is read which should be an integer fraction of the number before. The reason follows from the property of the program to calculate 3 variances. One of those calculations grasps the value after each step, another one after each electron has made a step (after a sweep) and the third one after each electron has finished the n-th step. The last input is the file name where the actual electron configuration shall be stored. Only these positions have changed after a run. The next line specifies output of date and time to the file gsh.out and the last gives this information to standard output.

The standard output is the xterm or screen in the case of a direct start from the terminal. In a batch job the output is collected by the system and sent as an email to the user after job termination [~/qmc/TMP/out]. The only disadvantage of this kind of output is the possibility of its loss at system break down. A piping of the output to a file would be not affected by such an event. However, the advantage is that the many data of the various program runs can be nicely organized in mail folders. Such a mail from the system is characterized by the userīs name as sender (From: ) and by the title (Subject: ) ``Output from at job''. One stores ( in elm with s or C) the message in an own file, a so-called mail folder, and loads it into an editor to insert as sender the computer name, as title the relevant informations on the parameters of the program. The name of the mail folder should also contain the information about the kind of jobs collected there. So, later program runs for the same task can be stored in the same mail folder. They are just appended at the end. By loading the mail folder one gets e.g. via the command c in elm a quick overview over the executed runs.