Sun Grid Engine Information Center
Administering Sun Grid Engine
Index

Managing Parallel Environments

About Parallel Environments

A parallel environment (PE) is a software package that enables concurrent computing on parallel platforms in networked environments.

A variety of systems have evolved over the past years into viable technology for distributed and parallel processing on various hardware platforms. The following are two examples of the most common message-passing environments:

• Parallel Virtual Machine (PVM) from Oak Ridge National Laboratories
• Message Passing Interface (MPI) from the Message Passing Interface Forum

Public domain as well as hardware vendor-provided implementations exist for both tools.

All these systems show different characteristics and have separate requirements. To handle parallel jobs running on top of such systems, the Grid Engine system provides a flexible, powerful interface that satisfies various needs.

The Grid Engine system enables you to run parallel jobs through the following programs:

• Arbitrary message-passing environments such as PVM or MPI. See the PVM User's Guide and the MPI User's Guide for details.
• Shared memory parallel programs on multiple slots, either in single queues or distributed across multiple queues and across machines for distributed memory parallel jobs.

Any number of different parallel environment interfaces can be configured concurrently.

Interfaces between parallel environments and the Grid Engine system can be implemented if suitable startup and stop procedures are provided. The startup procedure and the stop procedure are described in Parallel Environment Startup Procedure and in Termination of the Parallel Environment.

How to Configure Parallel Environments With QMON

1. On the QMON Main Control window, click the Parallel Environment Configuration button.
   The Parallel Environment Configuration dialog box appears.
   
   Currently configured parallel environments are displayed under PE List.
   
   
2. To display the contents of a parallel environment, select it.
   The selected parallel environment configuration is displayed under Configuration.
   
   
3. To add a new parallel environment, click Add.
   The Add/Modify PE dialog box appears. See How to Add or Modify Parallel Environments.
   
   
4. To modify a parallel environment, select it, and then click Modify.
   The Add/Modify PE dialog box appears. See How to Add or Modify Parallel Environments.
   
   
5. To delete a parallel environment, select it, and then click Delete.

How to Add or Modify Parallel Environments

1. From the Parallel Environment Configuration window, click Add or Modify as appropriate.
   The Add/Modify PE dialog box appears. If you are modifying a parallel environment, its name is displayed in the Name field.
   
   
   
2. To add a new parallel environment, type its name in the Name field.
   
   
3. In the Slots box, enter the total number of job slots that can be occupied by all parallel environment jobs running concurrently.
   
   
4. To change user access, click the icons at the right of the User Lists or Xuser Lists.
   User Lists displays the user access lists that are allowed to access the parallel environment. Xuser Lists displays the user access lists that are not allowed to access the parallel environment.
   The Select Access Lists dialog box appears.
   
   
   See Configuring User Access Lists for more information about user access lists.
   
   
5. To define the precise invocation sequence of the parallel environment startup and stop procedures, use the Start Proc Args and Stop Proc Args fields.
   See the sections Parallel Environment Startup Procedure and in Termination of the Parallel Environment.
   If no such procedures are required for a certain parallel environment, you can leave the fields empty.
   The first argument is usually the name of the start or stop procedure itself. The remaining parameters are command-line arguments to the procedures.
   A variety of special identifiers, which begin with a $ prefix, are available to pass internal runtime information to the procedures. The sge_pe(5) man page contains a list of all available parameters.
   
   
6. To define the number of parallel processes to allocate on each machine that is used by a parallel environment, use the Allocation Rule field.
   
   • Use a positive integer to set a specific number of process for each suitable host.
   • Use the special denominator $pe_slots to cause all the processes of a job to be allocated on a single host (SMP).
   • Use the denominators $fill_up and $round_robin to cause unbalanced distributions of processes among hosts.
     For more details about these allocation rules, see the sge_pe(5) man page.
     
7. To specify the method used to assess the number of slots that pending jobs with a slot range get, use the Urgency Slots field.
   The assumed slot allocation is meaningful when determining the resource-request-based priority contribution for numeric resources. You can specify an integer value for the number of slots. Specify min to use the slot range minimum. Specify max to use the slot range maximum. Specify avg to use the average of all numbers occurring within the job's parallel environment range request.
   
   
8. To specify whether the Grid Engine system generates parallel tasks or the corresponding parallel environment creates its own process, use the Control Slaves check box.
   The Grid Engine system uses sge_execd and sge_shepherd to generate parallel tasks. Full control over slave tasks by the Grid Engine system is preferable, because the system provides the correct accounting and resource control. However, this functionality is available only for parallel environment interfaces especially customized for the Grid Engine system.
   See Tight Integration of Parallel Environments and Grid Engine Software for more details.
   
   
9. If Control Slaves is checked, consider also selecting the Job Is First Task box.
   The Job Is First Task check box is meaningful only if Control Slaves is selected. If you select Job Is First Task, the job script or one of its child processes acts as one of the parallel tasks of the parallel application. For PVM, you usually want the job script to be part of the parallel application, for example. If you clear the Job Is First Task check box, the job script initiates the parallel application but does not participate. For MPI, you usually do not want the job script to be part of the parallel application, for example, when you use mpirun.
   
   
10. Click OK to save your changes and close the dialog box.
    Click Cancel to close the dialog box without saving changes.

Example – Displaying Configured Parallel Environment Interfaces With QMON

The following example defines a parallel job to be submitted. The job requests that the parallel environment interface mpi (message passing interface) be used with from 4 to 16 processes, with 16 being preferable.

• To select a parallel environment from a list of available parallel environments, click the button at the right of the Parallel Environment field. A selection dialog box appears.
  
  
  
• You can add a range for the number of parallel tasks initiated by the job after the parallel environment name in the Parallel Environment field.

Configuring Parallel Environments From the Command Line

Type the qconf command with appropriate options:

qconf <options>

The following options are available:

• qconf -ap pe-name
  The -ap option (add parallel environment) displays an editor containing a parallel environment configuration template. The editor is either the default vi editor or the editor defined by the EDITOR environment variable. pe-name specifies the name of the parallel environment. The name is already provided in the corresponding field of the template. To configure the parallel environment, change and save the template. See the sge_pe(5) man page for a detailed description of the template entries to change.
• qconf -Ap filename
  The -Ap option (add parallel environment from file) parses the specified file and adds the new parallel environment configuration. The file must have the format of the parallel environment configuration template.
• qconf -dp pe-name
  The -dp option (delete parallel environment) deletes the specified parallel environment.
• qconf -mp pe-name
  The -mp option (modify parallel environment) displays an editor containing the specified parallel environment as a configuration template. The editor is either the default vi editor or the editor defined by the EDITOR environment variable. To modify the parallel environment, change and save the template. See the sge_pe(5) man page for a detailed description of the template entries to change.
• qconf -Mp filename
  The -Mp option (modify parallel environment from file) parses the specified file and modifies the existing parallel environment configuration. The file must have the format of the parallel environment configuration template.
• qconf -sp pe-name
  The -sp option (show parallel environment) prints the configuration of the specified parallel environment to standard output.
• qconf -spl
  The -spl option (show parallel environment list) lists the names of all currently configured parallel environments.

Note To run parallel jobs, you must also associate a queue with the PE. Use the queue_conf(5) attribute pe_list to identify the suited PEs. Then, to link the PE and queues, use either the QMON utility or the following form of the qconf command: # qconf -mq <queue_name>

Example – Configuring a Parallel Environment From the Command Line

The qsub command that corresponds to the parallel job specification in Example -- Displaying Configured Parallel Environment Interfaces With QMON is as follows:

% qsub -N Flow -p -111 -P devel -a 200012240000.00 -cwd \
 -S /bin/tcsh -o flow.out -j y -pe mpi 4-16 \
 -v SHARED_MEM=TRUE,MODEL_SIZE=LARGE \
 -ac JOB_STEP=preprocessing,PORT=1234 \
 -A FLOW -w w -r y -m s,e -q big_q\
 -M me@myhost.com,me@other.address \
 flow.sh big.data

This example shows how to use the qsub -pe command to formulate an equivalent request. The qsub(1) man page provides more details about the -pe option.

Select a suitable parallel environment interface for a parallel job, keeping the following considerations in mind:

• Parallel environment interfaces can use different message-passing systems or no message systems.
• Parallel environment interfaces can allocate processes on single or multiple hosts.
• Access to the parallel environment can be denied to certain users.
• Only a specific set of queues can be used by a parallel environment interface.
• Only a certain number of queue slots can be occupied by a parallel environment interface at any point of time.

Ask your Grid Engine administrator for the available parallel environment interfaces best suited for your types of parallel jobs.

You can specify resource requirements along with your parallel environment request. The specifying of resource requirements further reduces the set of eligible queues for the parallel environment interface to those queues that fit the requirement. See Managing Resource Quotas.

For example, assume that you run the following command:

% qsub -pe mpi 1,2,4,8 -l nastran,arch=osf nastran.par

The queues that are suitable for this job are queues that are associated with the parallel environment interface mpi by the parallel environment configuration. Suitable queues also satisfy the resource requirement specification specified by the qsub -l command.

Note The parallel environment interface facility is highly configurable. In particular, the administrator can configure the parallel environment startup and stop procedures to support site-specific needs. See the sge_pe(5) man page for details. Use the qsub -v and qsub -V commands to pass information from the user who submits the job to the startup and stop procedures. These two options export environment variables. If you are unsure, ask the administrator whether you are required to export certain environment variables.

Parallel Environment Startup Procedure

The Grid Engine software starts the parallel environment by using the exec system call to invoke a startup procedure. The name of the startup executable and the parameters passed to this executable are configurable from within the Grid Engine software.

An example for such a startup procedure for the PVM environment is contained in the distribution tree of the Grid Engine software. The startup procedure is made up of a shell script and a C program that is invoked by the shell script. The shell script uses the C program to start up PVM cleanly. All other required operations are handled by the shell script.

The shell script is located under $SGE_ROOT/pvm/startpvm.sh. The C program file is located under $SGE_ROOT/pvm/src/start_pvm.c.

Note The startup procedure could have been a single C program. The use of a shell script enables easier customization of the sample startup procedure.

The example script startpvm.sh requires the following three arguments:

• The path of a host file generated by Grid Engine software, containing the names of the hosts from which PVM is to be started
• The host on which the startpvm.sh procedure is invoked
• The path of the PVM root directory, usually contained in the PVM_ROOT environment variable

These parameters can be passed to the startup script as described in Configuring Parallel Environments With QMON. The parameters are among the parameters provided to parallel environment startup and stop scripts by the Grid Engine software during runtime. The required host file, as an example, is generated by the Grid Engine software. The name of the file can be passed to the startup procedure in the parallel environment configuration by the special parameter name $pe_hostfile. A description of all available parameters is provided in the sge_pe(5) man page.

The host file has the following format:

• Each line of the file refers to a queue on which parallel processes are to run.
• The first entry of each line specifies the host name of the queue.
• The second entry specifies the number of parallel processes to run in this queue.
• The third entry denotes the queue.
• The fourth entry denotes a processor range to use in case of a multiprocessor machine.

This file format is generated by the Grid Engine software. The file format is fixed. Parallel environments that need a different file format must translate it within the startup procedure. See the startpvm.sh file. PVM is an example of a parallel environment that needs a different file format.

When the Grid Engine software starts the parallel environment startup procedure, the startup procedure launches the parallel environment. The startup procedure should exit with a zero exit status. If the exit status of the startup procedure is not zero, Grid Engine software reports an error and does not start the parallel job.

Note You should test any startup procedures first from the command line, without using the Grid Engine system. Doing so avoids all errors that can be hard to trace if the procedure is integrated into the Grid Engine software framework.

Termination of the Parallel Environment

When a parallel job finishes or is aborted, for example, by qdel, a procedure to halt the parallel environment is called. The definition and semantics of this procedure are similar to the procedures described for the startup program. The stop procedure can also be defined in a parallel environment configuration. See, for example, Configuring Parallel Environments With QMON.

The purpose of the stop procedure is to shut down the parallel environment and to reap all associated processes.

Note If the stop procedure fails to clean up parallel environment processes, the Grid Engine system might have no information about processes that are running under parallel environment control. Therefore the stop procedure cannot clean up these processes. The Grid Engine software, of course, cleans up the processes directly associated with the job script that the system has launched.

The distribution tree of the Grid Engine software also contains an example of a stop procedure for the PVM parallel environment. This example resides under $SGE_ROOT/pvm/stoppvm.sh. It takes the following two arguments:

• The path to the host file generated by the Grid Engine system
• The name of the host on which the stop procedure is started

Similar to the startup procedure, the stop procedure is expected to return a zero exit status on success and a nonzero exit status on failure.

Note You should test any stop procedures first from the command line, without using the Grid Engine software. Doing so avoids all errors that can be hard to trace if the procedure is integrated into the Grid Engine framework.

Tight Integration of Parallel Environments and Grid Engine Software

How to Configure Parallel Environments With QMON mentions that using sge_execd and sge_shepherd to create parallel tasks offers benefits over parallel environments that create their own parallel tasks. The UNIX operating system allows reliable resource control only for the creator of a process hierarchy. Features such as correct accounting, resource limits, and process control for parallel applications, can be enforced only by the creator of all parallel tasks.

Most parallel environments do not implement these features. Therefore parallel environments do not provide a sufficient interface for the integration with a resource management system like the Grid Engine system. To overcome this problem, the Grid Engine system provides an advanced parallel environment interface for tight integration with parallel environments. This parallel environment interface transfers the responsibility for creating tasks from the parallel environment to the Grid Engine software.

The distribution of the Grid Engine system contains two examples of such a tight integration, one for the PVM public domain version, and one for the MPICH MPI implementation from Argonne National Laboratories. The examples are contained in the directories $SGE_ROOT/pvm and $SGE_ROOT/mpi, respectively. The directories also contain README files that describe the usage and any current restrictions. Refer to those README files for more details.

For the purpose of comparison, the $SGE_ROOT/mpi/sunhpc/loose-integration directory contains a loose integration sample with Sun HPC ClusterTools software, and the $SGE_ROOT/mpi directory contains a loosely integrated variant of the interfaces for comparison.

Note The performance of a tight integration with a parallel environment is an advanced task that can require expert knowledge of the parallel environment and the Grid Engine software parallel environment interface. You might want to contact your Sun support representative for assistance.