WebSubmit Help Desk
Table of Contents
Overview
Setup and Configuration
WebSubmit Home Page
Page Layout
Link Bar
Comments and Reports
Usage
Overview
Comments about Form Elements
Session Management
System-Wide Application Interfaces
General System
Commands
File Transfer
SImple File Editor
Load Leveler Application Interfaces
General Job Submission
MPI Job Submission
Gaussian 94 Job
Submission
SP2 Queuing System
Control
SGI Origin 2000 Application Interfaces
General NQS Job
Submission
Queuing System
Control
Overview
WebSubmit is intended to serve as a universal
user interface to networked high-performance computing resources.
Its primary function is to allow users to submit job requests, execute
simple commands, and control job execution. A WebSubmit server
is used as an intermediary between the client's browser and one of a group
of valid remote computer systems. The main WebSubmit page
contains links to a group of application modules, each of which
performs a specific function aimed at a specific remote computer system.
For example, a link on the WebSubmit home page might point to a module
to interface to the IBM SP2 queuing system. Each application module
is currently implemented as a simple HTML form, although future versions
of WebSubmit might provide more flexibility.
At the present time, the WebSubmit cluster
at NIST encompasses the IBM SP2 (danube.nist.gov)
and the SGI Origin 2000 (arno.nist.gov);
interfaces are planned for the Pentium cluster (rapid.nist.gov)
and the CRAY (granta.nist.gov).
Access to systems outside of the WebSubmit cluster using WebSubmit is not
provided for.
Setup and Configuration
Registration
WebSubmit uses an authentication system to
restrict system access to valid users. Authentication between the
user and the WebSubmit server is accomplished using a special digitally-signed
certificate, issued by a valid WebSubmit certificate authority.
In order to use the system, users must register themselves with this authority
and receive a certificate to gain access. The procedure for obtaining
a certificate is as follows:
-
Register the WebSubmit certificate authority with
your browser software
-
Submit a certificate request
-
Once a certificate has been generated, load it into
your browser software
Each of these tasks can be accomplished through a
central Certificate
Manager maintained on the WebSubmit server. If you plan to use
WebSubmit from a variety of different machines that access different certificate
databases, then you must either export your certificate to those machines
or obtain additional certificates. At present, WebSubmit only supports
the use of Netscape Communicator v3.0+. If you have further questions
about certificates and registering with the system, please contact the
WebSubmit administrator.
Remote System Configuration
WebSubmit can be used to access a select group of
machines within the WebSubmit cluster. In order to access
these machines properly, a configuration file must exist for each user
on each machine they wish to utilize. This configuration file allows
the WebSubmit server to execute processes on that system in the user's
name. Execution is performed using secure protocols (Secure
SHell and Secure CoPy) to minimize the risk
of invalid users gaining access to your account. SSH and SCP can
be utilized by the WebSubmit server provided the single file .shosts
exists in the user's home directory on the desired system. This file
should contain the following line:
websubmit.nist.gov
nobody
Its access permissions should be set so that this
file is readable and writable only by the user. On UNIX systems,
this corresponds to permissions of 600 (-rw-------). If this file
is not present on the target computer system, WebSubmit will raise an error
indicating that there was a permission problem.
WebSubmit Home Page
Users access all modules on the WebSubmit system through a main home page.
The home page is laid out into three regions (HTML frames). Along
the left border of the screen, there is a collection of HTML links that
act as a menu bar (the Link Bar). Each element of the menu
either connects to related information or to configuration features of
WebSubmit. Along the foot of the page there is a link that allows
user to contact the WebSubmit adminstrator regarding problems with the
system. The central frame (Master Page) contains links to
the WebSubmit application modules.
Link Bar
The link bar (located along the left edge of the
WebSubmit screen) contains links to various useful WebSubmit help, information,
and configuration functions.
-
WebSubmit Master Page
This link will return you to the WebSubmit master
page, the entry point for all modules.
-
Help
Link to this help page
-
Messages
Read the current group of messages related to WebSubmit. These
messages will typically contain information about events on the system
related to WebSubmit, or matters that the server administrator considers
relevant.
-
Additional Information
This web page contains a set of links that point to resources connected
with the applications modules contained within WebSubmit.
-
Configure
The configuration page is used to change the visual appearance of the
WebSubmit master page. It allows users to delete or reinstall individual
application modules for their environment.
-
Administrator Reference
This link points to an extended set of documentation that discusses
the details of the operation of WebSubmit and its implementation as a package
of Tcl code.
-
Modules
All of these links point to the different WebSubmit application modules.
There should be a 1:1 correspondence between this collection of links and
those visible on the Master page.
Master Page
The central frame contains links to the WebSubmit application modules.
These are organized into classes, each of which contains modules relevant
to a single target compute engine). Within each class, the individual
application modules are further organized into functionally-related elements.
For example, if a series of modules is used to interact with a queing system
on a specific machine, then each will appear under a heading related to
the queing system.
Comments and Reports
At the foot of the master page (and all WebSubmit pages), there is a link
that allows users to send mail to the WebSubmit administrator. Mail
should be sent to the WebSubmit administrator to report problems with the
software, to request changing the user's status (active or inactive), or
to present general inquiries.
Usage
Overview
WebSubmit was designed to be easy to use. Users should be familiar
with the type of forms interfaces to application modules. A simple
interaction with an application interface would proceed as follows:
-
Go to the WebSubmit master (home) page
-
Click the link to the desired application module
-
Fill out the form for the application module with all necessary information
-
Submit the form by clicking on the relevant action buttons.
Directions for specific application modules are contained below.
The behavior of the form elements within each module should be transferrable
across modules, so usage of one module should aid in utilizing another.
Comments about Form Elements
Relative vs. Absolute Pathnames
Some form elements request file or directory names. In most cases,
these names can be entered using either relative or absolute pathnames.
Absolute pathnames begin with a /
(e.g., /some/directory/name),
whereas relative paths do not (e.g., some/relative/path).
If not explicitly stated, relative pathnames will be interpreted as
relative to the user's home directory on the relevant system.
For example, if a user specifies a directory name as foo/bar,
and their home directory on the relevant system is /home/user1,
then the directory name will be interpreted by WebSubmit as /home/user1/foo/bar
unless otherwise stated.
Session Management
Some of the WebSubmit modules (e.g., General Job Submission) provide the
user with the possibility of saving their form input so that ti can be
recalled at a later date. Each group of form data is considered as
a session that can be saved in the Session Library for that particular
module. A more detailed discussion of Session Management and its
use in WebSubmit can be found in the Session Management
section of the Reference Guide.
System-Wide Application
Interfaces
Individual application interfaces perform specific
functions on remote systems. They are either general (i.e., are useful
for all systems), or they are specific to a given system. For example,
the General Command Interface can be used on any system, but the
Load Leveler interface is only useful for the IBM SP2 (or other
machines using Load Leveler as a queuing system). To enter the interface
for a specific application, simply click on the link in the master page
that points to this application. The following sections
cover all system-wide application interfaces.
General System Commands
The general command interface allows users to execute
(UNIX) commands on remote systems and view the output from these commands.
Commands are executed on a specified Remote Host (selected from
a pull-down menu) within a specified working directory.
Output from and command(s) executed is returned in a different browser
window. Three slightly different modes of interaction are available:
-
Single user-specified commands
-
Single preselected commands
-
Groups of commands
Relative pathnames for working directories are interpreted as relative
to the user's home directory on the selected remote system. Absolute
pathnames can also be entered, although the user may not have permission
to execute arbitrary commands in directories not within their directory
hierarchy.
Single User-Specified Commands
Under the section Simple System Commands, there is a command line where
users can enter and execute arbitrary commands. Simple type the command
to execute and then click the Submit button to run. The command will
execute as if it had been typed from the shell in the specified working
directory on the selected remote host.
Single Preselected Commands
Under the section Simple System Commands, there is a series of preselected
commands that are commonly used on UNIX systems. For each of these
commands, there is a brief description, a pull-down menu of a few options,
and a text field where users enter arguments to the command. As with
single user-specified commands, each of these commands is executed in the
specified working directory on the selected remote host. In order
to use one of these commands, select the desired options and arguments
for the command, then press the button in the column labeled Command.
Pressing the Help button in a given command row will bring up the
UNIX man page for that command on the selected remote system.
Groups of Commands
Under the section General Command Facility, there is a text
window where several individual commands can be entered. This is
similar in spirit to a simple command shell.
File Transfer Interface
File transfers occur between the browser (client)
system and the specified remote system. The basic process
for transferring file(s) is as follows:
-
Select the remote system from the pull-down menu
-
Specify the file(s) to be transferred
-
Select the appropriate options for the transfer
-
Select the proper archive options if necessary
-
Click the arrow corresponding to the direction of
file transfer
The current interface allows you to perform several
types of file transfers between the client system (your local computer)
and a target remote system:
-
Single files between client and remote system
-
Directories or groups of files from the remote system
to the client
-
Directory or file archives from the client to the
server
The type of transfer that is desired determines how
the files are selected and the configuration of any file transfer or configuration
options.
Modes of File Transfer
Single File Transfer
If you wish to transfer
a single file between the client and remote systems, you simply need to
select the name of the file you wish to transfer. On the client system,
you can browse your filesystem by clicking the Browse... button, or just
select an individual file. At present, there is no mechanism for
browsing a remote file system, so the file must be manually selected.
If you are transferring a file from the Remote to Client, then no
client filename needs to be specified; you will be prompted for the name
of the local file to which the remote file will be copied. If you
are transferring a file from the Client to Remote, then the remote
filename can be specified in two ways: (1) as a remote directory,
to which the file will be copied or (2) as the new filename on the remote
system.
Download a Group of Files or a Directory
Hierarchy from Remote to Client
Groups of files or entire
directory hierarchies can be transferred from the remote host to the client
system, but they must be transferred as an archive. Four archive
formats are currently supported: zip, gzipped tar, compressed tar and binhex.
In order to transfer a group of remote files or a directory structure,
check the box for Remote-to-Client and select the format for the
transferred data. The file for the remote system must either be a
wildcard expression for a group of files (i.e.,the expression contains
* or ?) or a directory name.
Upload an Archive from Client to Remote
Client archives can
be transferred and unpacked on the remote system, provided they already
exist as archives on the client system. Simply specify the name of
the client archive file, check the box Unpack Client-to-Remote,
and choose the format of the file. The remote file should specify
the name of the directory in which the archive will be unpacked (default
= remote home directory). If the specified remote file does not exist,
a directory is created with this name and the archive is unpacked in this
location.
Options
-
Overwrite:
Specifies whether remote files are to be overwritten
by local files copied to the system.
-
Compress:
Causes file compression to be used during the
transfer process. In most cases, this will probably just slow down
the transfer due to the overhead incurred by compression.
Archive Options
-
Remote-to-Client:
Indicates that the specified remote file is a directory or group of
files that are to be archived and transferred to the client host.
This flag is meaningless if you are transferring files from client to remote.
-
Unpack Client-to-Remote:
Indicates that the client file is an archive to be unpacked after being
transferred to the remote host. This flag is meaningless for archive
transfers from remote to client.
-
Format:
The format of the archive to be transferred between the client and
remote systems. Currently four formats are allowed, although some
remote systems may not possess the required utilities to unpack archives
of any format. For example, many UNIX systems do not have binhex
utilities. The four formats currently supported are zip (common
on Windows systems), gzip'ed tar (a gzip'ed UNIX tar archive), compressed
tar (a compressed UNIX tar archive), and binhex (a Macintosh
archiving utility).
Simple File Editor
The file editor interface is a simple tool that users
can use to edit ASCII files on remote systems. It is not a full-featured
text editor like vi or emacs, and it is not intended to replace
eitehr of these utilities. It does, however, provide a means for
making quick changes to straight ASCII files. Binary files or documents
created with word-processing utilities like Wordperfect cannot be edited.
Using the editor is very simple:
-
Select the remote host where the file is located
-
Select the name of the file to edit
-
Load the file for editing
-
Save the file once changes are complete (if desired)
The output of any commands (i.e., Load or Save) will
be presented to the user at the top of the editor interface, just below
the WebSubmit user ID and user name. This indicates whether the action
was successful or not.
Remote Host
Choose the remote host where the file is located
using this pull-down menu. Only machines within the WebSubmit hierarchy
are available as remote hosts.
Remote File
Choose the name of the remote file to be edited
by entering its name in this text field. Pathnames, if not absolute,
are interpreted as relative to the user's home directory on the specified
remote host. No browsing facility exists, so users must be careful
to select existing files.
Action
-
Load File
Loads the specified remote file from the chosen
host into the text area in your browser.
-
Save
Saves the contents of the text area to the file
named in Remote File.
-
Reset
Reloads the original text into the text area.
This effectively undoes any changes made to the file.
Overwrite when saving
Determines whether the file in the text area
will overwrite an existing file on the remote system. For example,
assume a Remote File testfile is loaded, edited, then
saved. If the No box is checked next to overwrite, then changes
to this file will not be saved to testfile on the remote system
(since it already exists).
Load Leveler Application Interfaces
A group of interfaces is used to interact with the
Load Leveler queuing system on the IBM SP2. These provide facilities
for job submission and for the control of jobs once they have been submitted.
General Job Submission
This module is used to submit general parallel jobs
to Load Leveler. It is ideal if the user has a compiled code that
they wish to run in parallel on the SP2. It allows for the specification
of the working directory, executable name and arguments, data file names,
and a subset of Load Leveler keywords. The only required element
on the form is the name of the executable code; all other elements
have default values if they are left blank, although these defaults may
not coincide with the desired values for the given job. The general
method for using this module is to fill out the form with information related
to the desired job, and then to click the Submit Job button.
Session management functions can be performed using the Session Manager
at the bottom of the form. Specific fields within the form are discussed
below.
-
Working Directory (Load
Leveler Keyword = initialdir)
This is the directory in which Load Leveler executes
the specified code. The directory path is interpreted as relative
to the user's home directory.
-
Executable File Name (Load
Leveler Keywords = executable,
arguments)
This is the name of the executable code that you wish to run.
The pathname for the executable code is interpreted relative to the working
directory (not the user's home directory). Arguments to this code
are specified in the arguments section.
-
Data File Names (Load
Leveler Keywords = input,
output,
and error)
Load Leveler allows for redirection of standard input, standard output,
and standard error. If your executable code uses any of these devices,
then names should be given for these files. If not filenames are
given, Load Leveler assumes /dev/null.
-
Job Type (Load Leveler Keyword:
job_type)
Used to specify whether the job is to be run in serial, parallel, or
using the parallel virtual machine (pvm).
-
Job Class (Load
Leveler Keyword = class)
This is the Load Leveler job class in which your job will run.
The class controls the maximum number of processors, the scheduling priority,
and the maximum amount of time the job can run. You should select
the smallest class that exceeds the requirements for your job. Simply
click the radio button corresponding to the desired class to select it.
-
Number of Processors (Load
Leveler Keywords = min_processors,
max_processors)
The minimum and maximum number of processors specify these values
for your job. For any given job, the minimum number of processors
is 1 and the maximum is the number of nodes on the system. However,
if the numbers of processors is specified that is not consistent with the
class you have selected, then these values will be adjusted accordingly
to match the current class.
-
Job Name (Load
Leveler Keyword = job_name)
This is the name used by Load Leveler for your
job. The job name is also used by WebSubmit to construct a filename
for the Load Leveler job control file for your job.
-
Executable Script
(Load Leveler Keywords: shell)
A shell script can be given to Load Leveler to
execute in lieu of an executable code. This script is executed using
the specified shell. If you specify an executable script in WebSubmit,
this will override any executable file name given.
-
Job Requirements (Load
Leveler Keyword: requirements)
List of requirements that the remote machine
must meet in order to execute your batch job. Feature is used
to specify the type of node on which your job will execute. Memory
determines the minimum memory requirements. Adapter is the
type of adapter to be used by the SP system for your job.
-
Job Preferences (Load
Leveler Keyword: preferences)
List of characteristics that you prefer to be
available on the remote machine executing your job. Each entry is
equivalent to that for Job Requirements.
-
Job Environment (Load
Leveler Keyword: environment)
This section is used to specify shell environment
variables that you would like added or removed from the environment when
your job executes. If you wish all environment variables from your
shell to be present, select Copy all environment variables.
Alternatively, you can specify individual variables to include or exclude
from the environment. Finally, you can explicitly specify variables
and their values.
-
Parallel Path
(Load Leveler Keyword: parallel_path)
This specifies the path that should be used when
starting a PVM3.3 slave process; it is only used for PVM3.3 jobs,
and will be ignored if another job_type
is selected. The parallel path has two components separated by a
colon. The first component points to the location of the user's programs.
The second component points to the location of the pvmgs
routine (used for PVM3.3 group support).
-
Submission Timing
(Load Leveler Keywords: startdate,
hold)
The start date determines the date and time at
which you wish your job to start. If you wish your job to be held
in the queue when you submit it (i.e., queued but not submitted for execution),
you can specify that a hold be placed on your request.
MPI Job Submission
This module is used to submit parallel jobs that utilize the Message
Passing Interface (MPI) for communication. These jobs are executed
within the Parallel Operating Environment (POE). This module
is similar to the Generic Job Submission module, with two important distinctions.
First, the executable code you specify will be passed as an argument to
poe (along with any arguments to
your code itself); general executable scripts are not allowed. Second,
the job_type is assumed to be parallel.
A description of specific elements follows.
BASIC mode elements:
-
Working Directory (Load
Leveler Keyword = initialdir)
This is the directory in which Load Leveler executes
the specified code. The directory path is interpreted as relative
to the user's home directory.
-
Executable File Name (Load
Leveler Keywords = executable,
arguments)
This is the name of the executable code that you wish to run as a parallel
job. The pathname for the executable code is interpreted relative
to the working directory (not the user's home directory). Arguments
to this code are specified in the arguments section. The name
of the code specified in this section will be passed as an argument to
poe.
-
Data File Names (Load
Leveler Keywords = input,
output,
and error)
Load Leveler allows for redirection of standard input, standard output,
and standard error. If your executable code uses any of these devices,
then names should be given for these files. If not filenames are
given, Load Leveler assumes /dev/null.
-
Job Class (Load
Leveler Keyword = class)
This is the Load Leveler job class in which your job will run.
The class controls the maximum number of processors, the scheduling priority,
and the maximum amount of time the job can run. You should select
the smallest class that exceeds the requirements for your job. Simply
click the radio button corresponding to the desired class to select it.
-
Number of Processors (Load
Leveler Keywords = min_processors,
max_processors)
The minimum and maximum number of processors specify these values
for your job. For any given job, the minimum number of processors
is 1 and the maximum is the number of nodes on the system. However,
if the numbers of processors is specified that is not consistent with the
class you have selected, then these values will be adjusted accordingly
to match the current class.
-
Job Name (Load
Leveler Keyword = job_name)
This is the name used by Load Leveler for your
job. The job name is also used by WebSubmit to construct a filename
for the Load Leveler job control file for your job.
ADVANCED mode elements:
-
Job Requirements (Load
Leveler Keyword: requirements)
List of requirements that the remote machine
must meet in order to execute your batch job. Feature is used
to specify the type of node on which your job will execute. Memory
determines the minimum memory requirements. Adapter is the
type of adapter to be used by the SP system for your job.
-
Job Preferences (Load
Leveler Keyword: preferences)
List of characteristics that you prefer to be
available on the remote machine executing your job. Each entry is
equivalent to that for Job Requirements.
-
Job Environment (Load
Leveler Keyword: environment)
This section is used to specify shell environment
variables that you would like added or removed from the environment when
your job executes. If you wish all environment variables from your
shell to be present, select Copy all environment variables.
Alternatively, you can specify individual variables to include or exclude
from the environment. Finally, you can explicitly specify variables
and their values.
-
Transfer Files to Local Nodes:
In order to accelerate execution of your parallel
job, it is possible to copy your executable code and input files to the
local nodes (processors) on which your job will be executed. Optionally,
output can then be copied back to the SP2 control workstation (danube.nist.gov).
WebSubmit will write a Load Leveler script to perform these actions based
on the information you provide. Input and output filenames can be
specified using wildcard characters (*,?) if necessary.
Gaussian 94
This module is used to submit parallel jobs for the Gaussian 94 quantum-chemistry
package. There are basic and advanced modes for the form that
allow the user to control details of the job submission to different degrees.
As with the general job submission module, a job is submitted by filling
out the form and clicking the Submit Job button.
Required Information (BASIC and ADVANCED modes)
The only information required by WebSubmit for the successful submission
of a job is a working directory and a Gaussian input file. The directives
file must exist either on the remote computing system (where the job is
run), or on the user's browser system. The user must specify one
input file (either local or remote); if two files are specified, an error
is returned.
-
Working Directory (Load
Leveler Keyword = initialdir)
This is the directory in which Load Leveler executes
the Gaussian 94 job. The directory path is interpreted as relative
to the user's home directory.
-
Gaussian Input File
This is the name of the Gaussian 94 input file on the remote system.
If this file is specified, it will be used as input to the Gaussian job.
The file pathname is interpreted as relative to the working directory,
and the file must exist.
-
Local Gaussian Input File
This is the name of a Gaussian input file on the user's browser system.
If this file is specified, it will be uploaded to the compute system and
used as input for the Gaussian job.
Optional Information (ADVANCED mode only)
The following information can be specified if the advanced mode of
the form is being used. If no values are specified, the default values
will be used by WebSubmit.
-
Notification E-Mail Address
(Load Leveler Keyword = notify_user)
The e-mail address used to receive information about job completion
or status
-
Output File Name
The naming convention used for the file that holds Gaussian output.
This output file name can either be based on the name of the directives
file, based on the Load Leveler job number, or specified by the user.
If User-Defined is selected, then the user must enter the output file name
in the text entry blank to the right of the selection bar.
-
Load Leveler Command File Name
The naming convention used for the Load Leveler job command file (the
file submitted to Load Leveler). This name can either be based on
the name of the directives file, or specified by the user (as with the
output file name).
-
Job Class (Load
Leveler Keyword = class)
See General Job Submission
-
Number of Processors (Load Leveler
Keyword = max_processors)
The number of processors for a Gaussian job can either be specified
in the Gaussian directives file or manually. If specified manually,
indicate the number of processors desired in the text entry blank to the
right of the slection bar. In either case, the specified number of
processors will be made consistent with the job class chosen.
SP2 Queuing System Control
This module is used to examine the current queue status on your SP2 system,
and to control your jobs that are currently within the queue. When
you have jobs queued in the system, a table will be shown with details
about each job. If you click the checkbox to the right of the job
and then execute one of the Load Leveler Actions given below, this
action will be taken on the selected jobs.
Jobs Currently Queued
The jobs that are currently in the queue for the current WebSubmit
user. This table presents information about each job and allows you
to select the job (by clicking the checkbox) for further action.
Any selected job can be killed, held, have its scheduling priority changed,
and have a detailed listing about the job displayed. If you select
multiple job and then choose an action to be performed, it will be performed
on each job selected.
-
Node Listing
A listing of jobs that are currently running and which nodes on the
system they are using. The output in this section is equivalent to
the jmsum command. Information
can be updated by pressing the Update Queue Information button.
-
Complete Listing
A complete listing of the jobs currently running on your SP2 system.
This listing indicates for each job its owner, submission time, status,
priority, class, and machine. The output displayed in this section
is equivalent to that obtained using the llq
command. Information can be updated by pressing the Update Queue
Information button.
-
Load Leveler Actions
This section allows execution of various Load Leveler commands.
Some of these commands provide general information about the system, whereas
others act on specific jobs within the queue. If the user has no
jobs currently queued, only the generic actions will be displayed.
When jobs are in the queue that can be selected, then the remaining job
actions will also be displayed. Whenever an action is taken, the
output from this action will be displayed at the top of the form, before
the queue listings.
SGI Origin 2000 Application Interfaces
General NQS Job Submission
This module is used for submitting general batch jobs to the Network Queuing
System (NQS) operating on the SGI Origin 2000. The only element that
is required in this form is the Executable Script. As with
other WebSubmit modules, simply fill out the form and click the Submit
Job button to execute your job.
-
Working Directory
This is the directory in which your job will
execute. The directory path is interpreted as relative to the user's
home directory.
-
Executable Script
This script contains the commands that you wish to be executed as your
batch job. The script is interpreted using your login shell, unless
otherwise specified. The content of this script may only be a single
command consisting of the binary code you want to execute, or it may be
a series of commands.
-
Data File Names
The names for Standard Output and Standard Error files
are selected in this section. These files can either be updated during
execution or created when your request (job) is completed; select the appropriate
radio buttons to determine how your job output behaves. In addition,
Standard Error can be combined with Standard Output if desired by
selecting the small checkbox below the Standard Error form element.
The Job Control File Name is the name that your batch request script
will be given when it is written by WebSubmit; this is the script that
is used to submit your request.
-
Request Name
This is a simple identifier used by NQS to specify your job.
If no request name is specified, the request name will be based on the
name of the job control file.
-
Resource Limits
This section is used to specify the time and memory allocations required
for your job. They should both exceed the requirements for your request.
CPU Time indicates the amount of time your entire request will consume;
if you specify CPU Time, use the format indicated. Memory
is used to select the maximum amount of memory your request will consume;
choose an integer for this value and select the appropriate units if you
need to specify memory requirements. If you exceed the time or
memory available in the existing batch queues, NQS will simply delete your
request.
-
Email Notification
You can have the NQS system notify you at different times during the
execution of your batch request. Select the time at which you wish
to be notified, and mail will be sent to you on the SGI Origin 2000 machine.
If you do not wish to be notified by mail about your job status, select
Do Not Notify.
-
Multiprocessor Specification
If you wish to use more than one CPU for your job, please select the
number of processors desired in this entry. Please note that if
you exceed the number of processors available on the machine, NQS will
simply delete your request.
-
Submission Time
Use this entry to specify the time at which you wish your job to execute.
A variety of formats for time specification can be used. For more
information about valid time formats for this directive, please refer to
the NQS
documentation or the manual page for qsub.
Queuing System Control
This module provides users with the ability to examine
and control their jobs in the NQS queue. Details about the meaning
of display elements can be found in the NQS
Documentation or in the qstat
manual pages.
Jobs Currently Queued
The jobs that are currently in the queue for the current WebSubmit
user. This table presents information about each job and allows you
to select the job (by clicking the checkbox) for further action.
Any selected job can be killed or have a detailed listing about it displayed.
If you select multiple job and then choose an action to be performed, it
will be performed on each job selected.
-
Queue Summary
A summary listing of the jobs currently running on the system.
This listing indicates only the summary statistics for each batch and pipe
queue. Current policy on the system prevents users from seeing explicit
information about other user's jobs, although this may change in the future.
Information can be updated by pressing the Update Queue Information
button.
-
NQS Actions
This section allows execution of various NQS commands that act on specific
jobs within the queue. If the user has no jobs currently queued,
no actions will be displayed. When jobs are in the queue that can
be selected, then the job actions will also be displayed. Whenever
an action is taken, the output from this action will be displayed at the
top of the form, before the queue listings.