appschema(5) [debian man page]
APPSCHEMA(5) LAM FILE FORMATS APPSCHEMA(5) NAME
appschema - LAM application schema format SYNTAX
# # comments # [<where>] [-np #] [-s <where>] [-wd <dir>] [-x <env>] <program> [<args>] [<where>] [-np #] [-s <where>] [-wd <dir>] [-x <env>] <program> [<args>] ... DESCRIPTION
The application schema is an ASCII file containing a description of the programs which constitute an application. It is used by mpirun(1), MPI_Comm_spawn, and MPI_Comm_spawn_multiple to start an MPI application (the MPI_Info key "file" can be used to specify an app schema to MPI_Comm_spawn and MPI_Comm_spawn_multiple). All tokens after the program name will be passed as command line arguments to the new pro- cesses. Ordering of the other elements on the command line is not important. The meaning of the options is the same as in mpirun(1). See the mpirun(1) man page for a lengthy discussion of the nomenclature used for <where>. Note, however, that if -wd is used in the application schema file, it will override any -wd value specified on the command line. For each program line, processes will be created on LAM nodes according to the presence of <where> and the process count option (-np). only <where> One process is created on each node. only -np The specified number of processes are scheduled across all LAM nodes/CPUs. both The specified number of processes are scheduled across the specified nodes/CPUs. neither One process is created on the local node. Program Transfer By default, LAM searches for executable programs on the target node where a particular instantiation will run. If the file system is not shared, the target nodes are homogeneous, and the program is frequently recompiled, it can be convenient to have LAM transfer the program from a source node (usually the local node) to each target node. The -s option specifies this behaviour and identifies the single source node. EXAMPLE
# # Example application schema # Note that it may be necessary to specify the entire pathname for # "master" and "slave" if you get "File not found" errors from # mpirun(1). # # This schema starts a "master" process on CPU 0 with the argument # "42.0", and then 10 "slave" processes (that are all sent from the # local node) scheduled across all available CPUs. # c0 master 42.0 C -np 10 -s h slave SEE ALSO
mpirun(1), MPI_Comm_spawn(2), MPI_Comm_Spawn_multiple(2), MPIL_Spawn(2), introu(1) LAM 7.1.4 July, 2007 APPSCHEMA(5)
Check Out this Related Man Page
BHOST(5) LAM FILE FORMATS BHOST(5) NAME
bhost - LAM boot schema (host file) format SYNTAX
# # comments # <machine> [cpu=<cpucount>] [user=<userid>] <machine> [cpu=<cpucount>] [user=<userid>] ... DESCRIPTION
A boot schema describes the machines that will combine to form a multicomputer running LAM. It is used by recon(1) to verify initial con- ditions for running LAM, by lamboot(1) to start LAM, and by lamhalt(1) to terminate LAM (note that lamwipe(1) has been deprecated by the lamhalt(1) command). The particular syntax of a LAM boot schema is sometimes called the "host file" syntax. It is line oriented. One line indicates the name of a machine, typically the full Internet domain name, an optional number of CPUs available on that machine, and optionally the userid with which to access it. Common boot schema for a particular site may be created by the system administrator and placed in the installation directory under etc/. They typically start with the prefix bhost. Individual users usually create their own boot schema, especially if the configurations are simple. NAME RESOLUTION
Note that lamboot resolves all names listed in bhost on the node in which lamboot was invoked on. The lamboot(1) man page contains infor- mation about address resolution, examples on how to handle multiple network interface cards (NICs) in a node, etc. EXAMPLE
Here is an example three node boot schema: # # example LAM host file # server.cluster.example.com schedule=no beowulf1.cluster.example.com cpu=2 beowulf2.cluster.example.com beowulf2.cluster.example.com somewhere.else.example.com user=guest Note that the "guest" ID is significant, since the user has an alternate login ID on somewhere.else.example.com. Additionally note that beowulf1 has a CPU count of 2 listed (a CPU count of 1 is assumed if it is not given). This value is used by mpirun(1), MPI_Comm_spawn(2), and MPI_Comm_spawn_multiple(2) for the "C" (or CPU) notation that specifies how many ranks to start. This is particularly useful for run- ning on SMP machines. Note the schedule=no clause. This means that LAM will boot a daemon on that node, but by default, will not launch any MPI processes on that node. This is handy for when you want to control your MPI applications from one node (e.g., a server), but don't want to run any MPI applications on it. In some environments this is the default (e.g., BProc). See the LAM User's Guide for more details. beowulf2 is listed twice, but has no specific CPU count listed. In this case, LAM will keep a running tally of the total number of CPUs for that host. Hence, LAM will calculate that beowulf2 has two CPUs available for use. Calculating the number of CPUs by counting occu- rances of a hostname is useful in a batch environment where a hostfile may list the same hostname multiple times, indicating that the batch scheduler has allocated multiple CPUs for a single job (e.g., PBS operates this way). For the above-mentioned schema, the command "mpirun C foo" would start five instances of the foo program; two on beowulf1, two on beowulf2, and one on somewhere.else. FILES
$LAMHOME/etc/bhost.def default boot schema file SEE ALSO
LAM User's Guide, lamboot(1), lamhalt(1), mpirun(1), MPI_Comm_spawn(1), MPI_Comm_spawn_multiple(1), recon(1), lamwipe(1) LAM 7.1.4 July, 2007 BHOST(5)