bproc Boot Module¶

The bproc boot module uses native bproc functionality (e.g., the bproc_execmove library call) to launch jobs on slaves nodes from the head node. Checks are made before launching to ensure that the nodes are available and are "owned" by the user and/or the user's group. Appropriate error messages will be displayed if the user is unable to execute on the target nodes.

Hostnames should be specified using bproc notation: -1 indicates the head node, and integer numbers starting with 0 represent slave nodes. The string "localhost" will automatically be converted to "-1".

The default behavior is to mark the bproc head node as "non-scheduledable", meaning that the expansion of "N" and "C" when used with mpirun and lamexec will exclude the bproc head node. For example, "mpirun C my_mpi_program" will run copies of my_mpi_program on all lambooted slave nodes, but not the bproc head node.

Note that the bproc boot module is only usable from the bproc head node.

The bproc boot module only has one tunable parameter:

boot_bproc_priority

Using the priority argument can override LAM's automatic run-time boot module selection algorithms. This parameter only has effect when the tm module is eligible to be run (i.e., when running on a bproc cluster).

See the bproc notes in the user documentation for more details.

globus Boot Module¶

The globus boot module uses the globus-job-run command to launch executables on remote nodes. It is currently limited to only allowing jobs that can use the fork job manager on the Globus gatekeeper. Other job managers are not yet supported.

LAM will effectively never select the globus boot module by default because it has an extremely low default priority; it must be manually selected with the boot SSI parameter or have its priority raised. Additionally, LAM must be able to find the globus-job-run command in your PATH.

The boot schema requires hosts to be listed as the Globus contact string. For example:

"host1:port1:/O=xxx/OU=yyy/CN=aaa bbb ccc"

Note the use of quotes because the CN includes spaces -- the entire contact name must be enclosed in quotes. Additionally, since globus-job-run does not invoke the user's "dot" files on the remote nodes, no PATH or environment is setup. Hence, the attribute lam_install_path must be specified for each contact string in the hostfile so that LAM knows where to find its executables on the remote nodes. For example:

"host1:port1:/O=xxx/OU=yyy/CN=aaa bbb ccc" lam_install_path=/home/lam

The globus boot module only has one tunable parameter:

boot_globus_priority

Using the priority argument can override LAM's automatic run-time boot module selection algorithms.

rsh Boot Module¶

The rsh boot module uses rsh or ssh (or any other command line agent that acts like rsh/ssh) to launch executables on remote nodes. It requires that executables can be started on remote nodes without being prompted for a password, and without outputting anything to stderr.

The rsh boot module is always available, and unless overridden, always assigns itself a priority of 0.

The rsh module accepts a few run-time parameters:

boot_rsh_agent

Used to override the compiled-in default remote agent program that was selected when LAM is compiled. For example, this parameter can be set to use "ssh" if LAM was compiled to use "rsh" by default. Previous versions of LAM/MPI used the LAMRSH environment variable for this purpose. While the LAMRSH environment variable still works, its use is deprecated in favor of the boot_rsh_agent SSI module argument.

boot_rsh_priority

Using the priority argument can override LAM's automatic run-time boot module selection algorithms.

boot_rsh_username

If the user has a different username on the remote machine, this parameter can be used to pass the -l argument to the underlying remote agent. Note that this is a coarse-grained control -- this one username will be used for all remote nodes. If more fine-grained control is required, the username should be specified in the boot schema file on a per-host basis.

slurm Boot Module¶

The slurm boot module uses the srun command to launch the LAM daemons in a SLURM execution environment (i.e., it detects that it is running under SLURM and automatically sets its priority to 50). It can be used in two different modes: batch (where a script is submitted to SLURM and it is run on the first node in the node allocation) and allocate (where the -A option is used to srun to obtain an interactive allocation). The slurm boot module does not support running in a script that is launched by SLURM on all nodes in an allocation.

No boot schema file is required when using the slurm boot module; LAM will automatically determine the host and CPU count from SLURM itself.

The slurm boot module only has one tunable parameter:

boot_slurm_priority

Using the priority argument can override LAM's automatic run-time boot module selection algorithms. This parameter only has effect when the slurm module is eligible to be run (i.e., when running in a SLURM allocation).

tm Boot Module¶

The tm boot module uses the Task Management (TM) interface to launch executables on remote nodes. Currently, only OpenPBS and PBSPro are the only two systems that implement the TM interface. Hence, when LAM detects that it is running in a PBS job, it will automatically set the tm priority to 50. When not running in a PBS job, the tm module will not be available.

The tm boot module only has one tunable parameter:

boot_tm_priority

Using the priority argument can override LAM's automatic run-time boot module selection algorithms. This parameter only has effect when the tm module is eligible to be run (i.e., when running in a PBS job).