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:
 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.

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:

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:

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
 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: Application-specific default request file
General private default request file
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
|