Users familiar with the Linux command line may use standard job submission utilities to manage and run jobs on the Anvil compute nodes.
Accessing the Compute Nodes
Anvil uses the Slurm Workload Manager for job scheduling and management. With Slurm, a user requests resources and submits a job to a queue. The system takes jobs from queues, allocates the necessary compute nodes, and executes them. While users will typically SSH to an Anvil login node to access the Slurm job scheduler, they should note that Slurm should always be used to submit their work as a job rather than run computationally intensive jobs directly on a login node. All users share the login nodes, and running anything but the smallest test job will negatively impact everyone's ability to use Anvil.
Anvil is designed to serve the moderate-scale computation and data needs of the majority of XSEDE users. Users with allocations can submit to a variety of queues with varying job size and walltime limits. Separate sets of queues are utilized for the CPU, GPU, and large memory nodes. Typically, queues with shorter walltime and smaller job size limits will feature faster turnarounds. Some additional points to be aware of regarding the Anvil queues are:
- Anvil provides a debug queue for testing and debugging codes.
- Anvil supports shared-node jobs (more than one job on a single node). Many applications are serial or can only scale to a few cores. Allowing shared nodes improves job throughput, provides higher overall system utilization, and allows more users to run on Anvil.
- Anvil supports long-running jobs - run times can be extended to four days for jobs using up to 16 full nodes.
- The maximum allowable job size on Anvil is 7,168 cores. To run larger jobs, submit a consulting ticket to discuss with Anvil support.
- Shared-node queues will be utilized for managing jobs on the GPU and large memory nodes.
The charge unit for Anvil is the Service Unit (SU). This corresponds to the equivalent use of one compute core utilizing less than or equal to approximately 2G of data in memory for one hour, or 1 GPU for 1 hour. Keep in mind that your charges are based on the resources that are tied up by your job and do not necessarily reflect how the resources are used. Charges on jobs submitted to the shared queues are based on the number of cores and the fraction of the memory requested, whichever is larger. Jobs submitted as node-exclusive will be charged for all 128 cores, whether the resources are used or not. Jobs submitted to the large memory nodes will be charged 4 SU per compute core (4x standard node charge). The minimum charge for any job is 1 SU. Filesystem storage is not charged.
Link to section 'Job Submission Script' of 'Batch Jobs' Job Submission Script
To submit work to a Slurm queue, you must first create a job submission file. This job submission file is essentially a simple shell script. It will set any required environment variables, load any necessary modules, create or modify files and directories, and run any applications that you need:
#!/bin/sh -l # FILENAME: myjobsubmissionfile # Loads Matlab and sets the application up module load matlab # Change to the directory from which you originally submitted this job. cd $SLURM_SUBMIT_DIR # Runs a Matlab script named 'myscript' matlab -nodisplay -singleCompThread -r myscript
Once your script is prepared, you are ready to submit your job.
|SLURM_SUBMIT_DIR||Absolute path of the current working directory when you submitted this job|
|SLURM_JOBID||Job ID number assigned to this job by the batch system|
|SLURM_JOB_NAME||Job name supplied by the user|
|SLURM_JOB_NODELIST||Names of nodes assigned to this job|
|SLURM_SUBMIT_HOST||Hostname of the system where you submitted this job|
|SLURM_JOB_PARTITION||Name of the original queue to which you submitted this job|
Link to section 'Submitting a Job' of 'Batch Jobs' Submitting a Job
Once you have a job submission file, you may submit this script to SLURM using the sbatch command. Slurm will find, or wait for, available resources matching your request and run your job there.
To submit your job to one compute node with one task:
$ sbatch --nodes=1 --ntasks=1 myjobsubmissionfile
By default, each job receives 30 minutes of wall time, or clock time. If you know that your job will not need more than a certain amount of time to run, request less than the maximum wall time, as this may allow your job to run sooner. To request the 1 hour and 30 minutes of wall time:
$ sbatch -t 1:30:00 --nodes=1 --ntasks=1 myjobsubmissionfile
Each compute node in Anvil has 128 processor cores. In some cases, you may want to request multiple nodes. To utilize multiple nodes, you will need to have a program or code that is specifically programmed to use multiple nodes such as with MPI. Simply requesting more nodes will not make your work go faster. Your code must utilize all the cores to support this ability. To request 2 compute nodes with 256 tasks:
$ sbatch --nodes=2 --ntasks=256 myjobsubmissionfile
If more convenient, you may also specify any command line options to sbatch from within your job submission file, using a special form of comment:
#!/bin/sh -l # FILENAME: myjobsubmissionfile #SBATCH -A myallocation #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --time=1:30:00 #SBATCH --job-name myjobname # Print the hostname of the compute node on which this job is running. /bin/hostname
If an option is present in both your job submission file and on the command line, the option on the command line will take precedence.
After you submit your job with
sbatch, it may wait in the queue for minutes, hours, or even days. How long it takes for a job to start depends on the specific queue, the available resources ,and time requested, and other jobs that are already waiting in that queue. It is impossible to say for sure when any given job will start. For best results, request no more resources than your job requires.
Once your job is submitted, you can monitor the job status, wait for the job to complete, and check the job output.
Link to section 'Checking Job Status' of 'Batch Jobs' Checking Job Status
Once a job is submitted there are several commands you can use to monitor the progress of the job. To see your jobs, use the
squeue -u command and specify your username.
To retrieve useful information about your queued or running job, use the scontrol show job command with your job's ID number.
Link to section 'Checking Job Output' of 'Batch Jobs' Checking Job Output
Once a job is submitted, and has started, it will write its standard output and standard error to files that you can read.
SLURM catches output written to standard output and standard error - what would be printed to your screen if you ran your program interactively. Unless you specified otherwise, SLURM will put the output in the directory where you submitted the job in a file named slurm- followed by the job id, with the extension out. For example
slurm-3509.out. Note that both stdout and stderr will be written into the same file, unless you specify otherwise.
If your program writes its own output files, those files will be created as defined by the program. This may be in the directory where the program was run, or may be defined in a configuration or input file. You will need to check the documentation for your program for more details.
Link to section 'Redirecting Job Output' of 'Batch Jobs' Redirecting Job Output
It is possible to redirect job output to somewhere other than the default location with the --error and
#! /bin/sh -l #SBATCH --output=/path/myjob.out #SBATCH --error=/path/myjob.out # This job prints "Hello World" to output and exits echo "Hello World"
In addition to the ThinLinc and OnDemand interfaces, users can also choose to run interactive jobs on compute nodes,to obtain a shell that they can interact with. This gives users the ability to type commands or use a graphical interface as if they were on a login node.
To submit an interactive job, use
sinteractive to run a login shell on allocated resources.
sinteractive accepts most of the same resource requests as sbatch, so to request a login shell in the compute queue while allocating 2 nodes and 256 total cores, you might do:
$ sinteractive -N2 -n256 -A oneofyourallocations