Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

Submitting Extended Jobs From the Command Line

To submit the extended job request that is shown in Figure 3-5 from the command line, type the following command:

% qsub -N Flow -p -111 -P devel -a 200404221630.44 -cwd \
	-S /bin/tcsh -o flow.out -j y flow.sh big.data

Submitting Advanced Jobs With QMON

The Advanced tab of the Submit Job dialog box enables you to define the following additional parameters:

  • Parallel Environment - A parallel environment interface to use

  • Environment - A set of environment variables to set for the job before the job runs. Click the icon at the right of the Environment field to open a dialog box for the definition of the environment variables to export:

    Dialog box titled Environment Variable List. Shows list of environment
variables and their values. Shows Clear, Get Environment, Ok, Cancel, and Help buttons.

    Environment variables can be taken from QMON`s runtime environment. Or you can define your own environment variables.

  • Context - A list of name/value pairs that can be used to store and communicate job-related information. This information is accessible anywhere from within a cluster. You can modify context variables from the command line with the -ac, -dc, and -sc options to qsub, qrsh, qsh, qlogin, and qalter. You can retrieve context variables with the qstat -j command.

    Dialog box titled Context Variable List. Shows list of context
variables and their values. Shows Clear, Ok, Cancel, and Help buttons.
  • Checkpoint Object - The checkpointing environment to use if checkpointing the job is desirable and suitable. See Using Job Checkpointing for details.

  • Account - An account string to associate with the job. The account string is added to the accounting record that is kept for the job. The accounting record can be used for later accounting analysis.

  • Verify Mode - The Verify flag determines the consistency checking mode for your job. To check for consistency of the job request, the grid engine system assumes an empty and unloaded cluster. The system tries to find at least one queue in which the job could run. Possible checking modes are as follows:

    • Skip - No consistency checking at all.

    • Warning - Inconsistencies are reported, but the job is still accepted. Warning mode might be desirable if the cluster configuration should change after the job is submitted.

    • Error - Inconsistencies are reported. The job is rejected if any inconsistencies are encountered.

    • Just verify - The job is not submitted. An extensive report is generated about the suitability of the job for each host and queue in the cluster.

  • Mail - The events about which the user is notified by email. The events' start, end, abort, and suspend are currently defined for jobs.

  • Mail To - A list of email addresses to which these notifications are sent. Click the icon at the right of the Mail To field to open a dialog box for defining the mailing list:

    Dialog box titled Send mail to mail address. Shows list of mail
addresses and a data entry field. Shows Ok, Cancel, Delete, Reset, and Help buttons.
  • Hard Queue List, Soft Queue List - A list of queue names that are requested to be the mandatory selection for the execution of the job. The Hard Queue List and the Soft Queue List are treated identically to a corresponding resource requirement.

  • Master Queue List - A list of queue names that are eligible as master queue for a parallel job. A parallel job is started in the master queue. All other queues to which the job spawns parallel tasks are called slave queues.

  • Job Dependencies - A list of IDs of jobs that must finish before the submitted job can be started. The newly created job depends on completion of those jobs.

  • Deadline - The deadline initiation time for deadline jobs. Deadline initiation defines the point in time at which a deadline job must reach maximum priority to finish before a given deadline. To determine the deadline initiation time, subtract an estimate of the running time, at maximum priority, of a deadline job from its desired deadline time. Click the icon at the right of the Deadline field to open the dialog box that is shown here:

    Dialog box titled Enter a String. Shows a field where you can
enter a deadline time. Shows OK, Cancel, and Help buttons.


    Note - Not all users are allowed to submit deadline jobs. Ask your system administrator if you are permitted to submit deadline jobs. Contact the cluster administrator for information about the maximum priority that is given to deadline jobs.


Advanced Job Example

Figure 3-6 shows an example of an advanced job submission.

Figure 3-6 Advanced Job Submission Example

Dialog box titled Submit Job. Shows the Advanced tab. Previous
sections describe the parameters and buttons that are shown.

The job defined in Extended Job Example has the following additional characteristics as compared to the job definition in Submitting Extended Jobs With QMON.

  • The job requires the use of the parallel environment mpi. The job needs at least 4 parallel processes to be created. The job can use up to 16 processes if the processes are available.

  • Two environment variables are set and exported for the job.

  • Two context variables are set.

  • The account string FLOW is to be added to the job accounting record.

  • Mail must be sent to me@myhost.org as soon as the job starts and finishes.

  • The job should preferably be executed in the queue big_q.

Submitting Advanced Jobs From the Command Line

To submit the advanced job request that is shown in Figure 3-6 from the command line, type the following command:

% 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 -m s,e -q big_q\
 -M me@myhost.com,me@other.address \
 flow.sh big.data

Default Request Files

The preceding example shows that advanced job requests can be rather complex and unwieldy, in particular if similar requests need to be submitted frequently. To avoid the cumbersome and error-prone task of entering such commands, users can embed qsub options in the script files. Or users can use default request files. For more information, see Active Comments.


Note - The -binary yes|no option when specified with the y argument, allows you to use qrsh to submit executable jobs without the script wrapper. See the qsub man page.


The cluster administration can set up a default request file for all grid engine system users. Users, on the other hand, can create private default request files located in their home directories. Users can also create application-specific default request files that are located in their working directories.

Default request files contain the qsub options to apply by default to the jobs in one or more lines. The location of the global cluster default request file is sge-root/cell/common/sge_request. The private general default request file is located under $HOME/.sge_request. The application-specific default request files are located under $cwd/.sge_request.

If more than one of these files are available, the files are merged into one default request, with the following order of precedence:

  1. Application-specific default request file

  2. General private default request file

  3. Global default request file

Script embedding and the qsub command line have higher precedence than the default request files. Thus script embedding overrides default request file settings. The qsub command line options can override these settings again.

To discard any previous settings, use the qsub -clear command in a default request file, in embedded script commands, or in the qsub command line.

Here is an example of a private default request file:

-A myproject -cwd -M me@myhost.com -m b,e
-r y -j y -S /bin/ksh

Unless overridden, for all of this user's jobs the following is true:

  • The account string is myproject

  • The jobs execute in the current working directory

  • Mail notification is sent to me@myhost.com at the beginning and at the end of the jobs

  • The standard output and standard error output are merged

  • The ksh is used as command interpreter

Previous Previous     Contents     Index     Next Next