Whenever BatchMin is run, a UNIX environment variable called BATCH_ROOT must be defined. This should ordinarily be set to $MMOD_ROOT/run/mmdat, where MMOD_ROOT is the parent directory of the MacroModel distribution. When BatchMin is started up from MacroModel, MacroModel itself sets MMOD_ROOT and BATCH_ROOT. If you run BatchMin as a standalone program, you might like to define this variable in one of your startup files, such as .cshrc, .login or .profile; otherwise, you will have to do it manually before you start up BatchMin.
When BatchMin is run from the MacroModel interface, selection of a non-default version of the program may be done by means of the
HOST selection in the energy panel. If no host selection is made, the script bmin.auto will be run. The list of HOST selections comes from the file $MMOD_ROOT/run/mmdat/hostfiles.dat. Using the version of this file that we supply, the HOST selector panel lists a number of shell-scripts which will run different versions of BatchMin on the local host. By editing hostfiles.dat and taking several additional steps, you can also enable selection of BatchMin processes on remote hosts. This procedure is described in Appendix 3 of the MacroModel User Manual.
$MMOD_ROOT/run/mmdat.
bmin.auto: automatically selects the most optimized version of BatchMin that will run the selected job on the current processor. This is the default.
bmin.auto no longer has a facility to select program size.
bmin.auto can be "told" to use a differently optimized version than the one it would normally select.
bmin.auto[-v][-n][-o opt][-r]jobnameFor example, the command
bmin.auto mmodtmp
mmodtmp.com.For another example, the command
bmin.auto -v -n -o -com mmodtmpwill run
bmin-com with low priority (-n), using mmodtmp.com as the BatchMin command file. The (-v) option gives verbose output from the script, which is useful mostly for debugging problems with the script; that is, this option is unlikely to be directly useful to users. The priority used if -n is specified is very low indeed. It is set up in this way so that the BatchMin process started will recede completely into the background on a workstation being used interactively; the job will be pre-empted by virtually any other process except another version of BatchMin started the same way. This is useful for network-distributed BatchMin on a group of workstations that normally are used interactively during the day but are free at night. Even with low priority, the BatchMin process can get close to 100% of the use of the CPU when the workstation is otherwise free.The
-r option affects the redirection of BatchMin's standard input and output, and is normally used only when a bmin.auto script is invoked by a remote rbm process (see below, and Appendix 4, Distributed BatchMin).
Environment VariablesBATCH_ROOT, which identifies the directory in which the default files used by BatchMin are to be found. These files include the force-field files, the solvent files and the atom.typ file. BATCH_ROOT should be set to $MMOD_ROOT/run/mmdat; the C-shell (csh) invocation is: setenv BATCH_ROOT $MMOD_ROOT/run/mmdat
sh) or shells derived from it, such as the Korn shell (ksh), say: BATCH_ROOT=$MMOD_ROOT/run/mmdat
export BATCH_ROOTWhen starting up energetic procedures from within MacroModel, the MacroModel program provides the definition of
BATCH_ROOT. Whether BatchMin is started from the Unix shell or from MacroModel, local versions of the force-field, solvent and atom-type files override versions in the BATCH_ROOT location.
When running on an IBM RISC platform, it is also necessary to set the environment variable cnverr to yes. This can be done as follows, using csh:
setenv cnverr yes
sh) or Korn shell (ksh): cnverr=yes
export cnverrSeveral methods are available for invoking BatchMin; they all, however, involve the use of a BatchMin command file, which we therefore discuss first.
.com file is so called because it generally has the name filename.com, where filename is a valid UNIX filename prefix. The .com file contains the names of the input and output structure files, together with a list of commands telling BatchMin which operations are to be performed in what order. The input structure file contains the molecular structure(s) of the molecules to be processed, and the output file contains the structures after processing. The input file is usually called filename.dat and the output file is usually called filename.out.
The general format of a command file for BatchMin is:
filename.dat
filename.out
OPCD IIIIII IIIIII IIIIII IIIIII FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF
OPCD IIIIII IIIIII IIIIII IIIIII FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF
OPCD IIIIII IIIIII IIIIII IIIIII FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF FFFFF.FFFF
filename.dat and filename.out are the filenames of the input and output files; .dat and .out suffixes are nearly universally used, though there is nothing in the program which requires them. The program allows full-path filenames up to 100 characters in length. The filename prefixes need not be identical for the input, output and .com files, but they are the same in jobs set up in MacroModel and it is usually most convenient to follow this convention. BatchMin may create various temporary files in the course of its work. These have filename prefixes taken from the input or output file names.OPCD is a four-letter operation code ("opcode") for a command; each line containing an opcode begins with a space. IIIIII represents an integer argument in Fortran I6 format (arg1-arg4), and FFFFF.FFFF represents a floating point argument in F10.4 format (arg5-arg8). Each opcode defines a general command for BatchMin and the integer and real-number arguments specify more specific operations or options. Any line containing with an opcode can be turned into a nonexecutable comment line by placing a character other than a blank in the first column. This is useful for "commenting out" existing commands as well as for adding explicit comments. Tabs are not allowed in
.com files.
The form of the .com file must correspond exactly to that shown above. All integer and real arguments must be aligned as shown. Many of the arguments have default values which make it unnecessary to explicitly include them in the .com file if the defaults are the desired values; a zero in place of some argument generally in interpreted as a request for the default value. The actual values for the default parameters are indicated in the descriptions of the opcodes. Though there are exceptions, opcodes are generally processed in the order in which they are given in the
.com file; thus, the order of the command lines is important. Notes about command order are given as part of the opcode descriptions. Examples of valid .com files for numerous common modeling tasks are given in the MacroModel Primer. Though few users learn how even the most simple opcodes work at first, it becomes more necessary to do so as the complexity of the modeling task increases.
bmin.auto, additional optional arguments as described above. They create a log file that contains the BatchMin output, which appears on the UNIX standard-output device, as well as the output of the UNIX standard-error device. Thus, any system errors are recorded to the log file. These scripts also place UNIX C-shell timings into the log file. We recommend the use of these scripts, especially $BATCH_ROOT/bmin.auto, described above. This allows automatic selection of the appropriate BatchMin executable at run time and also has command-line options to override the default operation. If you expect to run BatchMin manually often, you can define an alias in your .cshrc file (if you use csh) or .profile (if you use the Bourne Shell or the Korn Shell) to make it easier to run the bmin.auto script. For example, you could insert a line into this file which says: alias bma path/bmin.auto
where path is the value of $BATCH_ROOT (which still, however, has to be set in the environment). Then a command like: bma filename
will run the bmin.auto script, using filename.com as the input file for BatchMin. Similarly, bma -n filename
.com File.com file that must be run over and over again. Our BatchMin test scripts fall into this category. A technique that is useful for this is to make the .com file itself executable - or, more precisely, to embed the contents of a .com file in an executable shell script. Here we show how this is done. We rarely employ this technique, except for our test suite; we usually use shell scripts, as described in the previous section.#! /bin/csh -f
$MMOD_ROOT/run/exec/bmin << EOC >& mm2-ELST.log
mm2-ELST.dat
mm2-ELST.out
FFLD
READ
ELST 2
EOC
<< EOC" is standard shell syntax for feeding all the lines between the current line and the one which contains the arbitrary string "EOC" to BatchMin as its standard input. The ">&" redirection ensures that both the standard output and standard error will be routed to the log file. Thus, if the above contents were contained in an executable file called mm2-ELST, BatchMin could be invoked to run the included commands by simply naming the file on the command line; for example, one would say the following to run the job in background:
% mm2-ELST &
DEGB 930 is specified.One may interact with a running BatchMin job by creating a file in the directory from which the job was launched. One simple way to do this from the UNIX command line is to use the UNIX
touch command:
% touch filename.sfx
filename is the filename prefix of the input file (usually the job name) and .sfx is a suffix that depends on the action desired, as follows.
Stopping BatchMinkill -9 pid", where pid stands for the process identification number, which can be obtained through use of the UNIX ps command. If this is done, then BatchMin exits without doing its normal cleanup. This means, among other things, that output buffers will not be flushed, and that scratch files, such as filename.tmp, will not be converted to final form, such as the ASCII file filename.out, and removed. This state of affairs also occurs when the system kills the BatchMin job or when the system crashes. Recovery from this state is possible by means of the TRED command, described in Chapter 4.There is, however, a gentler way to kill BatchMin - one which causes the process to carry out its normal clean-up operations. To do this, the user creates a file called
filename.stp in the directory in which the BatchMin job was initiated. The .stp suffix is a mnemonic for "stop." BatchMin periodically checks for the existence of such as file, and, if it finds it, branches immediately to its normal cleanup and exit procedure. BatchMin removes the .stp file prior to exiting; thus the same job may be rerun if desired without first removing this file manually.
filename.slp; the .slp suffix is a mnemonic for "sleep", and filename is the prefix of the input file. BatchMin periodically looks for the .slp file, and, if it finds it, suspends execution, except for periodically attempting to verify the file's continued existence. When it it fails to find the .slp file, it resumes execution. Thus, to resume execution of the BatchMin job, remove the .slp file using the UNIX rm command.The UNIX
kill command can also be used to stop a BatchMin process; to stop the process, say "kill -STOP pid"; to restart it later, say "kill -CONT pid", where pid is the process identification number of the job.When a job is put to sleep the CPU suspends execution and the job may in time be swapped out of active memory (RAM); however, it continues to occupy swap space on disk. If, in a particular situation, the availability of swap space is limiting the number of jobs that can be simultaneously run, putting one or more of them to sleep will not help. This option is, however, useful for obtaining more responsive performance when CPU availability, rather than swap space, is limiting. There are less drastic means of lowering the priority of a job as well - namely,
renice and npri - but these require special privileges if it is desired to restore the original priority.
filename.upt, it will, at the next convenient point, print to the log file a summary of its progress so far, then remove the .upt file. In the current version of BatchMin, this facility is implemented only for conformational search. If the MacroModel front end is running, the update information will also appear in the monitoring window. Selecting a process to be monitored by means of the Montr button of ENRGY mode causes an update to be triggered by this mechanism, but when BatchMin is run as a standalone process, the user can trigger it manually by simply creating the .upt file .