Skip to content
Snippets Groups Projects
Commit 02bac6ae authored by Adam Caprez's avatar Adam Caprez
Browse files

Update Submitting Jobs section.

parent 2a8466e1
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 716 additions and 6969 deletions
content/guides/submitting_jobs/_index.md
+ 92
− 119
View file @ 02bac6ae
......@@ -4,62 +4,53 @@ description = "How to submit jobs to HCC resources"
weight = "10"
+++
HCC-DOCS : Submitting Jobs
=========================================================
Crane, Sandhills and Tusker are managed by
the <a href="https://slurm.schedmd.com" class="external-link">SLURM</a> resource
manager. In order to run processing on Crane, Sandhills or Tusker, you
the [SLURM](https://slurm.schedmd.com) resource manager.
In order to run processing on Crane, Sandhills or Tusker, you
must create a SLURM script that will run your processing. After
submitting the job, SLURM will schedule your processing on an available
worker node.
Before writing a submit file, you may need to [compile your
application](Compiling-Source-Code_332258.html).
Before writing a submit file, you may need to
[compile your application]({{< relref "/guides/running_applications/compiling_source_code" >}}).
- [Ensure proper working directory for job
output](#SubmittingJobs-Ensureproperworkingdirectoryforjoboutput)
- [Creating a SLURM Submit
File](#SubmittingJobs-CreatingaSLURMSubmitFile)
- [Submitting the job](#SubmittingJobs-Submittingthejob)
- [Checking Job Status](#SubmittingJobs-CheckingJobStatus)
- [Checking Job Start](#SubmittingJobs-CheckingJobStart)
- [Next Steps](#SubmittingJobs-NextSteps)
- [Ensure proper working directory for job output](#ensure-proper-working-directory-for-job-output)
- [Creating a SLURM Submit File](#creating-a-slurm-submit-file)
- [Submitting the job](#submitting-the-job)
- [Checking Job Status](#checking-job-status)
- [Checking Job Start](#checking-job-start)
- [Next Steps](#next-steps)
Ensure proper working directory for job output
----------------------------------------------
<span
class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span>
### Ensure proper working directory for job output
{{% notice info %}}
All SLURM job output should be directed to your /work path.
{{% /notice %}}
**manual specification of /work path**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Manual specification of /work path" %}}
{{< highlight bash >}}
$ cd /work/[groupname]/[username]
```
The environment variable $WORK can also be used.
{{< /highlight >}}
{{% /panel %}}
**using environment for /work path**
``` syntaxhighlighter-pre
The environment variable `$WORK` can also be used.
{{% panel theme="info" header="Using environment variable for /work path" %}}
{{< highlight bash >}}
$ cd $WORK
$ pwd
/work/[groupname]/[username]
```
Review how /work differs from /home [here.](Handling-Data_332256.html)
{{< /highlight >}}
{{% /panel %}}
Creating a SLURM Submit File
----------------------------
Review how /work differs from /home [here.]({{< relref "/guides/handling_data/_index.md" >}})
<span
class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span>
### Creating a SLURM Submit File
{{% notice info %}}
The below example is for a serial job. For submitting MPI jobs, please
look at the [MPI Submission Guide.](Submitting-an-MPI-Job_332242.html)
look at the [MPI Submission Guide.]({{< relref "submitting_an_mpi_job" >}})
{{% /notice %}}
A SLURM submit file is broken into 2 sections, the job description and
the processing. SLURM job description are prepended with `#SBATCH` in
......@@ -67,7 +58,7 @@ the submit file.
**SLURM Submit File**
``` syntaxhighlighter-pre
{{< highlight batch >}}
#!/bin/sh
#SBATCH --time=03:15:00 # Run time in hh:mm:ss
#SBATCH --mem-per-cpu=1024 # Maximum memory required per CPU (in megabytes)
......@@ -79,47 +70,41 @@ module load example/test
hostname
sleep 60
```
- **time**
Maximum walltime the job can run. After this time has expired, the
job will be stopped.
- **mem-per-cpu**
Memory that is allocated per core for the job. If you exceed this
memory limit, your job will be stopped.
- **mem**
Specify the real memory required per node in MegaBytes. If you
exceed this limit, your job will be stopped. Note that for you
should ask for less memory than each node actually has. For
instance, Tusker has 1TB, 512GB and 256GB of RAM per node. You may
only request 1000GB of RAM for the 1TB node, 500GB of RAM for the
512GB nodes, and 250GB of RAM for the 256GB nodes. For Crane, the
max is 500GB.
- **job-name
**The name of the job. Will be reported in the job listing.
- **partition**
The partition the job should run in. Partitions determine the job's
priority and on what nodes the partition can run on. See [Available
Partitions on
Sandhills](Available-Partitions-on-Sandhills_332211.html), and
[Available Partitions on Crane and
Tusker](https://hcc-docs.unl.edu/display/HCCDOC/Available+Partitions+on+Crane+and+Tusker) for
a list of possible partitions.
- **error**
Location of the stderr will be written for the job. `[groupname]`
and `[username]` should be replaced your group name and username.
Your username can be retrieved with the command `id -un` and your
group with `id -ng`.
- **output**
Location of the stdout will be written for the job.
More advanced submit commands can be found on the
<a href="https://slurm.schedmd.com/sbatch.html" class="external-link">SLURM Docs</a>.
You can also find an example of a MPI submission on [Submitting an MPI
Job](Submitting-an-MPI-Job_332242.html).
Submitting the job
------------------
{{< /highlight >}}
- **time**
Maximum walltime the job can run. After this time has expired, the
job will be stopped.
- **mem-per-cpu**
Memory that is allocated per core for the job. If you exceed this
memory limit, your job will be stopped.
- **mem**
Specify the real memory required per node in MegaBytes. If you
exceed this limit, your job will be stopped. Note that for you
should ask for less memory than each node actually has. For
instance, Tusker has 1TB, 512GB and 256GB of RAM per node. You may
only request 1000GB of RAM for the 1TB node, 500GB of RAM for the
512GB nodes, and 250GB of RAM for the 256GB nodes. For Crane, the
max is 500GB.
- **job-name**
The name of the job. Will be reported in the job listing.
- **partition**
The partition the job should run in. Partitions determine the job's
priority and on what nodes the partition can run on. See
[Available Partitions on Crane and Tusker]({{< relref "available_partitions_on_crane_and_tusker" >}})
for a list of possible partitions.
- **error**
Location of the stderr will be written for the job. `[groupname]`
and `[username]` should be replaced your group name and username.
Your username can be retrieved with the command `id -un` and your
group with `id -ng`.
- **output**
Location of the stdout will be written for the job.
More advanced submit commands can be found on the [SLURM Docs](https://slurm.schedmd.com/sbatch.html).
You can also find an example of a MPI submission on [Submitting an MPI Job]({{< relref "submitting_an_mpi_job" >}}).
### Submitting the job
Submitting the SLURM job is done by command `sbatch`. SLURM will read
the submit file, and schedule the job according to the description in
......@@ -127,64 +112,59 @@ the submit file.
Submitting the job described above is:
**SLURM Submission**
``` syntaxhighlighter-pre
$ sbatch example.slurm
{{% panel theme="info" header="SLURM Submission" %}}
{{< highlight batch >}}
$ sbatch example.slurm
Submitted batch job 24603
```
{{< /highlight >}}
{{% /panel %}}
The job was successfully submitted.
Checking Job Status
-------------------
### Checking Job Status
Job status is found with the command `squeue`. It will provide
information such as:
- The State of the job:
- **R** - Running
- **PD** - Pending - <span style="color: rgb(0,0,0);">Job is
awaiting resource allocation.</span>
- <span style="color: rgb(0,0,0);">Additional codes are available
on the
<a href="http://slurm.schedmd.com/squeue.html" class="external-link">squeue</a>
page.</span><span style="color: rgb(0,0,0);">
</span>
- <span style="color: rgb(0,0,0);">Job Name</span>
- <span style="color: rgb(0,0,0);">Run Time</span>
- <span style="color: rgb(0,0,0);">Nodes running the job</span>
- The State of the job:
- **R** - Running
- **PD** - Pending - Job is awaiting resource allocation.
- Additional codes are available
on the [squeue](http://slurm.schedmd.com/squeue.html)
page.
- Job Name
- Run Time
- Nodes running the job
Checking the status of the job is easiest by filtering by your username,
using the `-u` option to squeue.
``` syntaxhighlighter-pre
{{< highlight batch >}}
$ squeue -u <username>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
24605 batch hello-wo <username> R 0:56 1 b01
```
{{< /highlight >}}
Additionally, if you want to see the status of a specific partition, for
example if you are part of a
[partition](Available-Partitions-on-Sandhills_332211.html), you can use
the `-p` option to `squeue`:
example if you are part of a [partition]({{< relref "available_partitions_on_crane_and_tusker" >}}),
you can use the `-p` option to `squeue`:
``` syntaxhighlighter-pre
{{< highlight batch >}}
$ squeue -p esquared
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
73435 esquared MyRandom tingting R 10:35:20 1 ri19n10
73436 esquared MyRandom tingting R 10:35:20 1 ri19n12
73735 esquared SW2_driv hroehr R 10:14:11 1 ri20n07
73736 esquared SW2_driv hroehr R 10:14:11 1 ri20n07
```
{{< /highlight >}}
### Checking Job Start
#### Checking Job Start
You may view the start time of your job with the
command `squeue --start`. The output of the command will show the
expected start time of the jobs.
``` syntaxhighlighter-pre
{{< highlight batch >}}
$ squeue --start --user lypeng
JOBID PARTITION NAME USER ST START_TIME NODES NODELIST(REASON)
5822 batch Starace lypeng PD 2013-06-08T00:05:09 3 (Priority)
......@@ -198,29 +178,22 @@ $ squeue --start --user lypeng
5830 batch Starace lypeng PD 2013-06-08T00:13:09 3 (Priority)
5831 batch Starace lypeng PD 2013-06-08T00:14:09 3 (Priority)
5832 batch Starace lypeng PD N/A 3 (Priority)
```
{{< /highlight >}}
The output shows the expected start time of the jobs, as well as the
reason that the jobs are currently idle (in this case, low priority of
the user due to running numerous jobs already).
<span
style="color: rgb(0,0,0);font-size: 20.0px;line-height: 1.5;">Removing
the Job</span>
#### Removing the Job
Removing the job is done with the `scancel` command. The only argument
to the `scancel` command is the job id. For the job above, the command
is:
``` syntaxhighlighter-pre
{{< highlight batch >}}
$ scancel 24605
```
Next Steps
----------
{{< /highlight >}}
### Next Steps
{{% children %}}
content/guides/submitting_jobs/available_partitions_on_sandhills.md deleted 100644 → 0
+ 0
− 107
View file @ 2a8466e1
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Available Partitions on Sandhills </span>
===========================================================================
Created by <span class="author"> Confluence Admin</span>, last modified
by <span class="editor"> Josh Samuelson</span> on Oct 19, 2017
Partitions are used in Sandhills to enforce ownership and priority for
owned resources. You can view the partitions with the command `sinfo`.
*last generated Wed Oct 24 14:47:57 2018*
<table style="width:100%;">
<colgroup>
<col style="width: 8%" />
<col style="width: 11%" />
<col style="width: 18%" />
<col style="width: 18%" />
<col style="width: 19%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th>Partition</th>
<th>Owner</th>
<th>Node total (NODExCPU/MEM/FEATURE)</th>
<th>Description</th>
<th>SLURM Specification</th>
<th style="text-align: center;">Max Job Run Time</th>
<th style="text-align: center;">Max CPUs Per User</th>
<th style="text-align: center;">Max Jobs Per User</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>batch</td>
<td>shared</td>
<td>92 total (49x64/192GB/ib,2300Mhz; 41x32/128GB/ib,2000Mhz; 2x48/256GB/none)</td>
<td>(default, no specification)</td>
<td>#SBATCH --partition=batch</td>
<td style="text-align: center;">10-00:00:00</td>
<td style="text-align: center;">2000Mhz:1312 2300Mhz:3136</td>
<td style="text-align: center;">1000</td>
</tr>
<tr class="even">
<td>sabirianov</td>
<td>sabirianov</td>
<td>4 total (4x64/192GB/ib,2300Mhz)</td>
<td>Dedicated resources with ib or 2300Mhz</td>
<td>#SBATCH --partition=sabirianov</td>
<td style="text-align: center;">10-00:00:00</td>
<td style="text-align: center;">2300Mhz:256</td>
<td style="text-align: center;">1000</td>
</tr>
</tbody>
</table>
Specific CPU Frequency Selection
--------------------------------
Sandhills is a hetereogenous cluster in terms of individual node
resources, even when 'owned' by a research group and allocated to a
specific partition with limited access. So that researchers can
constrain their jobs' deployment to nodes with specific CPU frequencies,
HCC has added a 'feature' on each node that can be used to filter as
part of submission requests. Currently there are nodes with processors
operating at 2300Mhz and 2000Mhz. In order to select only nodes of a
specific frequency one must add '–contraint=2000Mhz' to the SLURM
specification (for example). One can see partitions, node names,
features, and allocation status by using a command such as 'sinfo -N -o
"%P %f %t %N".
<span style="color: rgb(0,0,0);">Limitations of Jobs</span>
-----------------------------------------------------------
<span style="color: rgb(0,0,0);">There are no special QoS settings for
Sandhills currently. All jobs are subject to the maximum 10 day run time
and 1000 jobs per user.</span>
Guest Partition
---------------
The `guest` partition can be used by users and groups that do not own
resources on Sandhills but still want to run parallel applications.
Jobs running in the `guest` partition will run on the owned resources
with a high performance interconnect optimized for parallel
applications. The jobs are preempted when the resources are needed by
the resource owners and are restarted on another node.
Owned Partitions
----------------
Partitions marked as owned by a group means only specific groups are
allowed to submit jobs to that partition. Groups are manually added to
the list allowed to submit jobs to the partition. If you are unable to
submit jobs to a partition, and you feel that you should be, please
contact <a href="mailto:hcc-support@unl.edu" class="external-link">hcc-support@unl.edu</a>.
content/guides/submitting_jobs/hcc_acknowledgment_credit.md
+ 59
− 128
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : HCC Acknowledgment Credit </span>
===================================================================
Created by <span class="author"> Josh Samuelson</span>, last modified on
Sep 27, 2017
<span
class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span>
+++
title = "HCC Acknowledgment Credit"
description = "Details on the Acknowledgment Credit system."
+++
{{% notice note %}}
To submit an acknowledgement and receive the credit, please use the form
here:
<a href="https://hcc.unl.edu/acknowledgement-submission" class="external-link">https://hcc.unl.edu/acknowledgement-submission</a>
here: https://hcc.unl.edu/acknowledgement-submission.
{{% /notice %}}
### What is HCC Acknowledgment Credit?
......@@ -29,12 +21,10 @@ machine, it may not start immediately like a Priority Access (owned
partition) job will. This will, however, likely shorten the start time
of the job considerably, depending on job requirements.
Different types of research activities are awarded different amounts of
time.
The following table lists research activities and awarded time:
......@@ -48,22 +38,17 @@ The following table lists research activities and awarded time:
| undergrad thesis | 1 year |
| unfunded grant | 6 months |
Time is awarded evenly for compute and memory resources at a ratio of
1CPU to 4GB of memory. The QoS remains active until either resource is
exhausted.
exhausted.
Why this ratio?
**Why this ratio?**
All nodes in the Crane batch partition can meet this CPU to memory
ratio.
Why have this ratio?
**Why have this ratio?**
In short: fairness. All programs require CPU and memory to complete the
tasks they were written to perform. Dividing the memory amount by the
......@@ -76,191 +61,148 @@ job.  Similarly, a high memory job may use all the memory on a node but
only use a single CPU. Using the ratio will result in fair accounting
of CPU and memory resources awarded.
Column description of the hcc-ac utility
| hcc-ac header | Description |
|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Slurm qos | The qos name that must be provided with the Slurm '--qos=ac\_&lt;name&gt;' argument |
| Slurm qos | The qos name that must be provided with the Slurm `--qos=ac_<name>` argument |
| CPUx1 time | Time remaining for a single CPU |
| MEMx4GB time | Time remaining for 4GB of memory |
| per-CPU AvgMEM | The per-CPU average memory size available for the CPU time remaining in the qos. If CPU time is consumed faster than memory time, this value will increase. If memory time is consumed faster than CPU time, this value will decrease. |
Example of how to use the awarded time for the 'demo' group.
##### Example of how to use the awarded time for the 'demo' group.
The awarded time is reduced down to 10 minutes to show consumption
changes with differing job resource requirements:
All times are in days-hours:minutes:seconds as used in Slurm's '--time='
argument.
**Default output**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Default output" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ hcc-ac
+-----------+--------------+--------------+----------------+
| Slurm qos | CPUx1 time | MEMx4GB time | per-CPU AvgMEM |
+-----------+--------------+--------------+----------------+
| ac_demo | 0-00:10:00 | 0-00:10:00 | 4.0GB |
+-----------+--------------+--------------+----------------+
```
{{< /highlight >}}
{{% /panel %}}
Use the Slurm quality of service argument '--qos' to gain access to the
awarded time with increased priority:
**--qos=ac\_demo**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**--qos=ac_demo**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ srun --qos=ac_demo --ntasks=1 --mem=8g --time=1:00 /bin/sleep 60
```
{{< /highlight >}}
{{% /panel %}}
**\*\*job runs for 60 seconds\*\***
\*\***job runs for 60 seconds**\*\*
**After 60 second job**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**After 60 second job**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ hcc-ac
+-----------+--------------+--------------+----------------+
| Slurm qos | CPUx1 time | MEMx4GB time | per-CPU AvgMEM |
+-----------+--------------+--------------+----------------+
| ac_demo | 0-00:09:00 | 0-00:08:00 | 3.556GB |
+-----------+--------------+--------------+----------------+
```
{{< /highlight >}}
{{% /panel %}}
1 CPU minute and 2 4GB memory minutes were consumed by the prior srun
job.
1 CPU minute ie, (--ntasks=1 --time=1:00)
2 4GB minutes ie, (--ntasks=1 --mem=8G --time=1:00 \~= 1 8GB minute \~=
2 4GB minutes)
The remaining per-CPU average memory can be found with the following
equation:
(memory time remaining) / (cpu time remaining) \* 4
ie, 8 / 9 \* 4 == 3.556
Multiplying the remaining cpu time against the per-CPU average memory
will give the same value as multiplying the remaining memory time
against 4GB:
ie, 9 \* 3.556 \~= 8 \* 4
**--ntasks=4**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**--ntasks=4**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ srun --qos=ac_demo --ntasks=4 --mem-per-cpu=2G --time=1:00 /bin/sleep 60
```
{{< /highlight >}}
{{% /panel %}}
**\*\*job runs for 60 seconds\*\***
\*\***job runs for 60 seconds**\*\*
**After 60 second job**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**After 60 second job**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ hcc-ac
+-----------+--------------+--------------+----------------+
| Slurm qos | CPUx1 time | MEMx4GB time | per-CPU AvgMEM |
+-----------+--------------+--------------+----------------+
| ac_demo | 0-00:05:00 | 0-00:06:00 | 4.8GB |
+-----------+--------------+--------------+----------------+
```
{{< /highlight >}}
{{% /panel %}}
4 CPU minutes and 2 4GB minutes were consumed by the prior srun job.
4 CPU minutes (--ntasks=4 --time=1:00)
2 4GB minutes (--ntasks=4 --mem-per-cpu=2G --time=1:00 \~= 1 8GB minute
\~= 2 4GB minutes)
6 / 5 \* 4 == 4.8
**Insufficient time**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**Insufficient Time**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ srun --qos=ac_demo --ntasks=5 --mem-per-cpu=5000M --time=1:00 /bin/sleep 60
srun: error: Unable to allocate resources: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)
```
{{< /highlight >}}
{{% /panel %}}
An example of a job requesting more resources than what remains
available in the qos.
**corrected memory requirement**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**Corrected Memory Requirement**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ srun --qos=ac_demo --ntasks=5 --mem-per-cpu=4800M --time=1:00 /bin/sleep 60
```
{{< /highlight >}}
{{% /panel %}}
**\*\*job runs for 60 seconds\*\***
\*\***job runs for 60 seconds**\*\*
**exhausted qos**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**Exhausted QoS**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ hcc-ac
+-----------+--------------+--------------+----------------+
| Slurm qos | CPUx1 time | MEMx4GB time | per-CPU AvgMEM |
+-----------+--------------+--------------+----------------+
| ac_demo | exhausted | exhausted | 0.0GB |
+-----------+--------------+--------------+----------------+
```
{{< /highlight >}}
{{% /panel %}}
All remaining time was used. Any further submissions to the qos will be
**denied at submission time**.
All of the above **srun** arguments work the same with **sbatch** within
the submit file header.
**submit file example**
``` syntaxhighlighter-pre
{{% panel theme="info" header="**Submit File Example**" %}}
{{< highlight batch >}}
[demo01@login.hcc_cluster ~]$ cat submit_test.slurm
#!/bin/bash
#!/bin/batch
#SBATCH --ntasks=4
#SBATCH --qos=ac_demo
#SBATCH --ntasks=5
......@@ -269,9 +211,8 @@ the submit file header.
/bin/sleep 60
[demo01@login.hcc_cluster ~]$ sbatch ./submit_test.slurm
```
{{< /highlight >}}
{{% /panel %}}
CPU and memory time in the qos are only consumed when jobs run against
the qos. Therefore it is possible for more jobs to be submitted
......@@ -280,31 +221,22 @@ exhausted all pending jobs attempting to use it will remain in pending
state until more time is added to the qos or the job is modified to not
consider the qos as a job requirement.
HCC will run a script periodically (hourly) to scan for jobs pending in
this state and modify them to utilize the cluster's default qos.
Sizing what can fit in the qos's time limits using Slurm's '--test-only'
Sizing what can fit in the qos's time limits using Slurm's `--test-only`
argument.
You can attempt different combinations of --nodes, --ntasks,
--ntasks-per-node, --mem-per-cpu= and --mem utilizing the '--test-only'
You can attempt different combinations of `--nodes`, `--ntasks`,
`--ntasks-per-node`, `--mem-per-cpu` and `--mem` utilizing the `--test-only`
argument to size the job against what time remains in the qos.
For example, with the same 10 minute limit:
**--test-only job to see if it fits within qos time limits**
{{% panel theme="info" header="**--test-only job to see if it fits within qos time limits**" %}}
{{< highlight batch >}}
``` syntaxhighlighter-pre
[demo01@login.hcc_cluster ~]$ hcc-ac
+-----------+--------------+--------------+----------------+
| Slurm qos | CPUx1 time | MEMx4GB time | per-CPU AvgMEM |
......@@ -334,6 +266,5 @@ allocation failure: Job violates accounting/QOS policy (job submit limit, user's
[demo01@login.hcc_cluster ~]$ srun --test-only --qos=ac_demo --ntasks=1 --time=3:00 --mem-per-cpu=12G
srun: Job <number> to start at YYYY-MM-DDTHH:MM:SS using 1 processors on compute_node
```
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/job_dependencies.md
+ 41
− 72
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Job Dependencies </span>
==========================================================
Created by <span class="author"> Adam Caprez</span>, last modified by
<span class="editor"> Derek Weitzel</span> on Nov 05, 2013
+++
title = "Job Dependencies"
description = "How to use job dependencies with the SLURM scheduler."
+++
The job dependency feature of SLURM is useful when you need to run
multiple jobs in a particular order. A standard example of this is a
......@@ -17,15 +11,14 @@ then manually submit the next, all the jobs in the workflow can be
submitted at once. SLURM will then run them in the proper order based
on the conditions supplied.
Syntax
------
### Syntax
The basic syntax is to include the `-d `option with the `sbatch` command
The basic syntax is to include the `-d` option with the `sbatch` command
for a new submission to indicate it depends on another job. You must
also supply the condition and job id upon which it depends. SLURM
supports several possible conditions; see the `sbatch`
<a href="http://slurm.schedmd.com/sbatch.html" class="external-link">man page</a>
for all the options. The example here uses `after``ok`, which instructs
[man page](http://slurm.schedmd.com/sbatch.html)
for all the options. The example here uses `afterok`, which instructs
SLURM to only run the submitted job after the dependency job has
terminated without error (exit code 0).
......@@ -34,18 +27,12 @@ This example is usually referred to as a "diamond" workflow.  There are
B and C both depend on Job A completing before they can run. Job D then
depends on Jobs B and C completing.
<span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img src="assets/images/4849718/4980738.png" title="Simple Dependencies" alt="Simple Dependencies" class="confluence-embedded-image" width="300" height="300" /></span>
{{< figure src="/images/4980738.png" width="400" >}}
The SLURM submit files for each step are below.
**JobA.submit** <span class="collapse-source expand-control"
style="display:none;"><span
class="expand-control-icon icon"> </span><span
class="expand-control-text">Expand source</span></span> <span
class="collapse-spinner-wrapper"></span>
``` syntaxhighlighter-pre
{{%expand "JobA.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --job-name=JobA
#SBATCH --time=00:05:00
......@@ -55,15 +42,12 @@ class="collapse-spinner-wrapper"></span>
echo "I'm job A"
echo "Sample job A output" > jobA.out
sleep 120
```
{{< /highlight >}}
{{% /expand %}}
**JobB.submit** <span class="collapse-source expand-control"
style="display:none;"><span
class="expand-control-icon icon"> </span><span
class="expand-control-text">Expand source</span></span> <span
class="collapse-spinner-wrapper"></span>
``` syntaxhighlighter-pre
{{%expand "JobB.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --job-name=JobB
#SBATCH --time=00:05:00
......@@ -76,15 +60,11 @@ cat jobA.out >> jobB.out
echo "" >> jobB.out
echo "Sample job B output" >> jobB.out
sleep 120
```
**JobC.submit** <span class="collapse-source expand-control"
style="display:none;"><span
class="expand-control-icon icon"> </span><span
class="expand-control-text">Expand source</span></span> <span
class="collapse-spinner-wrapper"></span>
{{< /highlight >}}
{{% /expand %}}
``` syntaxhighlighter-pre
{{%expand "JobC.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --job-name=JobC
#SBATCH --time=00:05:00
......@@ -97,15 +77,11 @@ cat jobA.out >> jobC.out
echo "" >> jobC.out
echo "Sample job C output" >> jobC.out
sleep 120
```
{{< /highlight >}}
{{% /expand %}}
**JobD.submit** <span class="collapse-source expand-control"
style="display:none;"><span
class="expand-control-icon icon"> </span><span
class="expand-control-text">Expand source</span></span> <span
class="collapse-spinner-wrapper"></span>
``` syntaxhighlighter-pre
{{%expand "JobC.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --job-name=JobD
#SBATCH --time=00:05:00
......@@ -120,60 +96,53 @@ cat jobC.out >> jobD.out
echo "" >> jobD.out
echo "Sample job D output" >> jobD.out
sleep 120
```
{{< /highlight >}}
{{% /expand %}}
To start the workflow, submit Job A first:
**Submit Job A**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Submit Job A" %}}
{{< highlight batch >}}
[demo01@login.tusker demo01]$ sbatch JobA.submit
Submitted batch job 666898
```
{{< /highlight >}}
{{% /panel %}}
Now submit jobs B and C, using the job id from Job A to indicate the
dependency:
**Submit Jobs B and C**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Submit Jobs B and C" %}}
{{< highlight batch >}}
[demo01@login.tusker demo01]$ sbatch -d afterok:666898 JobB.submit
Submitted batch job 666899
[demo01@login.tusker demo01]$ sbatch -d afterok:666898 JobC.submit
Submitted batch job 666900
```
{{< /highlight >}}
{{% /panel %}}
Finally, submit Job D as depending on both jobs B and C:
**Submit Job D**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Submit Job D" %}}
{{< highlight batch >}}
[demo01@login.tusker demo01]$ sbatch -d afterok:666899:666900 JobD.submit
Submitted batch job 666901
```
{{< /highlight >}}
{{% /panel %}}
Running `squeue` will now show all four jobs. The output from `squeue`
will also indicate that Jobs B, C, and D are in a pending state because
of the dependency.
**squeue output**
``` syntaxhighlighter-pre
{{% panel theme="info" header="Squeue Output" %}}
{{< highlight batch >}}
[demo01@login.tusker demo01]$ squeue -u demo01
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
666899 batch JobB demo01 PD 0:00 1 (Dependency)
666900 batch JobC demo01 PD 0:00 1 (Dependency)
666901 batch JobD demo01 PD 0:00 1 (Dependency)
666898 batch JobA demo01 R 0:52 1 c2409
```
{{< /highlight >}}
{{% /panel %}}
As the each job completes successfully, SLURM will run the job(s) in the
workflow as resources become available.
Attachments:
------------
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[SimpleDependencies.png](attachments/4849718/4980738.png) (image/png)
content/guides/submitting_jobs/monitoring_jobs.md
+ 33
− 69
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Monitoring Jobs </span>
=========================================================
Created by <span class="author"> Carrie Brown</span>, last modified by
<span class="editor"> Natasha Pavlovikj</span> on Sep 19, 2018
+++
title = "Monitoring Jobs"
description = "How to find out information about running and completed jobs."
+++
Careful examination of running times, memory usage and output files will
allow you to ensure the job completed correctly and give you a good idea
......@@ -18,17 +12,14 @@ of what memory and time limits to request in the future.
To see the runtime and memory usage of a job that has completed, use the
sacct command:
``` syntaxhighlighter-pre
{{< highlight bash >}}
sacct
```
{{< /highlight >}}
Lists all jobs by the current user and displays information such as
JobID, JobName, State, and ExitCode.
<span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img src="assets/images/21070052/21070053.png" class="confluence-embedded-image" height="150" /></span>
{{< figure src="/images/21070053.png" height="150" >}}
Coupling this command with the --format flag will allow you to see more
than the default information about a job. Fields to display should be
......@@ -36,15 +27,14 @@ listed as a comma separated list after the --format flag (without
spaces). For example, to see the Elapsed time and Maximum used memory by
a job, this command can be used:
``` syntaxhighlighter-pre
{{< highlight bash >}}
sacct --format JobID,JobName,Elapsed,MaxRSS
```
{{< /highlight >}}
<span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img src="assets/images/21070052/21070054.png" class="confluence-embedded-image" height="150" /></span>
{{< figure src="/images/21070054.png" height="150" >}}
Additional arguments and format field information can be found in
<a href="https://slurm.schedmd.com/sacct.html" class="external-link">the SLURM documentation.</a>
[the SLURM documentation](https://slurm.schedmd.com/sacct.html).
### Monitoring Running Jobs:
......@@ -54,46 +44,43 @@ multi-process jobs, whereas the cgroup files provide information on
memory usage. Both of these tools require the use of an interactive job
on the same node as the job to be monitored.
<span
class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span>
{{% notice warning %}}
If the job to be monitored is using all available resources for a node,
the user will not be able to obtain a simultaneous interactive job.
{{% /notice %}}
After the job to be monitored is submitted and has begun to run, request
an interactive job on the same node using the srun command:
``` syntaxhighlighter-pre
{{< highlight bash >}}
srun --jobid=<JOB_ID> --pty bash
```
{{< /highlight >}}
Where &lt;JOB\_ID&gt; is replaced by the job id for the monitored job as
Where `<JOB_ID>` is replaced by the job id for the monitored job as
assigned by SLURM.
Alternately, you can request the interactive job by nodename as follows:
``` syntaxhighlighter-pre
{{< highlight bash >}}
srun --nodelist=<NODE_ID> --pty bash
```
{{< /highlight >}}
Where &lt;NODE\_ID&gt; is replaced by the node name that the monitored
Where `<NODE_ID>` is replaced by the node name that the monitored
job is running. This information can be found out by looking at the
squeue output under the NODELIST column.
squeue output under the `NODELIST` column.
<span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img src="assets/images/21070052/21070055.png" class="confluence-embedded-image" width="700" /></span>
{{< figure src="/images/21070055.png" width="700" >}}
Once the interactive job begins, you can run top to view the processes
on the node you are on:
<span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img src="assets/images/21070052/21070056.png" class="confluence-embedded-image" height="400" /></span>
{{< figure src="/images/21070056.png" height="400" >}}
Output for top displays each running process on the node. From the above
image, we can see the various MATLAB processes being run by user
cathrine98. To filter the list of processes, you can type \`u\` followed
cathrine98. To filter the list of processes, you can type `u` followed
by the username of the user who owns the processes. To exit this screen,
press \`q\`.
press `q`.
During a running job, the cgroup folder is created which contains much
of the information used by sacct. These files can provide a live
......@@ -104,43 +91,20 @@ following commands:
##### To view current memory usage:
``` syntaxhighlighter-pre
{{< highlight bash >}}
less /cgroup/memory/slurm/uid_<UID>/job_<SLURM_JOB_ID>/memory.usage_in_bytes
```
{{< /highlight >}}
Where &lt;UID&gt; is replaced by your UID and &lt;SLURM\_JOB\_ID&gt; is
Where `<UID>` is replaced by your UID and `<SLURM_JOB_ID>` is
replaced by the monitored job's Job ID as assigned by Slurm.
<span
class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span>
To find your uid, use the command \`id -u\`. Your UID never changes but
is cluster specific (ie, your UID on Crane will always be the same but
will differ from your UID on the other clusters).
{{% notice note %}}
To find your uid, use the command `id -u`. Your UID never changes and is
the same on all HCC clusters (*not* on Anvil, however!).
{{% /notice %}}
##### To view maximum memory usage from start of job to current point:
``` syntaxhighlighter-pre
{{< highlight bash >}}
cat /cgroup/memory/slurm/uid_${UID}/job_${SLURM_JOBID}/memory.max_usage_in_bytes
```
Attachments:
------------
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[image2017-7-10\_11-16-5.png](attachments/21070052/21070053.png)
(image/png)
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[image2017-7-10\_11-16-36.png](attachments/21070052/21070054.png)
(image/png)
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[image2017-7-10\_12-14-1.png](attachments/21070052/21070055.png)
(image/png)
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[image2017-7-10\_12-23-27.png](attachments/21070052/21070056.png)
(image/png)
<img src="assets/images/icons/bullet_blue.gif" width="8" height="8" />
[image2017-7-10\_12-27-45.png](attachments/21070052/21070057.png)
(image/png)
{{< /highlight >}}
content/guides/submitting_jobs/submitting_a_job_array.md
+ 12
− 28
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Submitting a Job Array </span>
================================================================
Created by <span class="author"> Derek Weitzel</span>, last modified by
<span class="editor"> Carrie Brown</span> on Jun 29, 2017
+++
title = "Submitting a Job Array"
description = "How to use job arrays with the SLURM scheduler."
+++
A job array is a set of jobs that share the same submit file, but will
run multiple copies with a environment variable incremented. These are
useful when you need to process a series of files, or if you need to run
the same application multiple times.
Creating a Array Submit File
----------------------------
### Creating a Array Submit File
An array submit file is very similar to the example submit files
in [Submitting Jobs](Submitting-Jobs_332222.html).
**example.slurm**
in [Submitting Jobs]({{< relref "/guides/submitting_jobs/_index.md" >}}).
``` syntaxhighlighter-pre
{{% panel theme="info" header="example.slurm" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --array=0-31
#SBATCH --time=03:15:00 # Run time in hh:mm:ss
......@@ -37,18 +27,12 @@ module load example/test
echo "I am task $SLURM_ARRAY_TASK_ID on node `hostname`"
sleep 60
```
{{< /highlight >}}
{{% /panel %}}
The submit file above will output the `$SLURM_ARRAY_TASK_ID`, which will
be different for every one of the 32 (0-31) jobs, to the output files.
Job Arrays in SLURM have more features than this brief description,
please visit
the <a href="https://slurm.schedmd.com/job_array.html" class="external-link">SLURM Documentation</a> for
more detailed information.
please visit the [SLURM Documentation](https://slurm.schedmd.com/job_array.html)
for more detailed information.
content/guides/submitting_jobs/submitting_an_interactive_job.md
+ 23
− 39
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Submitting an Interactive Job </span>
=======================================================================
Created by <span class="author"> Derek Weitzel</span>, last modified by
<span class="editor"> Adam Caprez</span> on Sep 14, 2018
<span
class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span>
+++
title = "Submitting an Interactive Job"
description = "How to run an interactive job on HCC resources."
+++
{{% notice info %}}
The `/home` directories are read-only on the worker nodes. You will need
to compile or run your processing in `/work`.
{{% /notice %}}
Submitting an interactive job is done with the command `srun`.
``` syntaxhighlighter-pre
{{< highlight bash >}}
$ srun --pty $SHELL
```
{{< /highlight >}}
or to allocate 4 cores per node:
``` syntaxhighlighter-pre
{{< highlight bash >}}
$ srun --nodes=1 --ntasks-per-node=4 --mem-per-cpu=1024 --pty $SHELL
```
{{< /highlight >}}
Submitting an interactive job is useful if you require extra resources
to run some processing by hand. It is also very useful to debug your
......@@ -35,34 +28,25 @@ And interactive job is scheduled onto a worker node just like a regular
job. You can provide options to the interactive job just as you would a
regular SLURM job.
Priority for short jobs
-----------------------
### Priority for short jobs
To run short jobs for testing and development work, a job can specify a
different quality of service (QoS). The *short* QoS increases a jobs
priority so it will run as soon as possible.
| <span style="color: rgb(0,51,102);">SLURM Specification</span> |
|----------------------------------------------------------------|
| `--qos=short` |
Limits per user for 'short' QoS
<span
class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span>
| SLURM Specification |
|---------------------|
| `--qos=short` |
- 6 hour job run time
- 2 jobs of 16 CPUs or fewer
- No more than 256 CPUs in use for *short* jobs from all users
**Using the short QoS**
{{% panel theme="warning" header="Limits per user for 'short' QoS" %}}
- 6 hour job run time
- 2 jobs of 16 CPUs or fewer
- No more than 256 CPUs in use for *short* jobs from all users
{{% /panel %}}
``` syntaxhighlighter-pre
{{% panel theme="info" header="Using the short QoS" %}}
{{< highlight bash >}}
srun --qos=short --nodes=1 --ntasks-per-node=1 --mem-per-cpu=1024 --pty $SHELL
```
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/submitting_an_mpi_job.md
+ 31
− 1331
View file @ 02bac6ae
This diff is collapsed.
content/guides/submitting_jobs/submitting_an_openmp_job.md
+ 18
− 25
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
+++
title = "Submitting an OpenMP Job"
description = "How to submit an OpenMP job on HCC resources."
+++
<span id="title-text"> HCC-DOCS : Submitting an OpenMP Job </span>
==================================================================
Submitting an OpenMP job is different from
[Submitting an MPI Job]({{< relref "submitting_an_mpi_job" >}})
since you must request multiple cores from a single node.
Created by <span class="author"> Derek Weitzel</span>, last modified by
<span class="editor"> Adam Caprez</span> on Jun 10, 2013
Submitting an OpenMP job is different from [Submitting an MPI
Job](Submitting-an-MPI-Job_332242.html) since you must request multiple
cores from a single node.
**OpenMP example submission**
``` syntaxhighlighter-pre
{{% panel theme="info" header="OpenMP example submission" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --ntasks-per-node=16 # 16 cores
#SBATCH --nodes=1 # 1 node
......@@ -24,26 +17,26 @@ cores from a single node.
#SBATCH --error=/work/[groupname]/[username]/job.%J.err
#SBATCH --output=/work/[groupname]/[username]/job.%J.out
export OMP_NUM_THREADS=16
export OMP_NUM_THREADS=${SLURM_NTASKS_PER_NODE}
./openmp-app.exe
```
{{< /highlight >}}
{{% /panel %}}
Notice that we used `ntasks-per-node` to specify the number of cores we
want on a single node. Additionally, we specify that we only want
1 `node`.
`OMP_NUM_THREADS` is required to limit the number of cores that OpenMP
will use on the node. It should match the `ntasks-per-node` value.
will use on the node. It is set to ${SLURM_NTASKS_PER_NODE} to
automatically match the `ntasks-per-node` value (in this example 16).
### Compiling
Directions to compile OpenMP can be found on [Compiling an OpenMP
Application](Compiling-an-OpenMP-Application_332316.html).
Directions to compile OpenMP can be found on
[Compiling an OpenMP Application]
({{< relref "/guides/running_applications/compiling_source_code/compiling_an_openmp_application" >}}).
### Further Documentation
Further OpenMP documentation can be found on LLNL's
<a href="https://computing.llnl.gov/tutorials/openMP/" class="external-link">OpenMP</a>
website.
[OpenMP](https://computing.llnl.gov/tutorials/openMP) website.
content/guides/submitting_jobs/submitting_htcondor_jobs.md
+ 16
− 32
View file @ 02bac6ae
1. [HCC-DOCS](index.html)
2. [HCC-DOCS Home](HCC-DOCS-Home_327685.html)
3. [HCC Documentation](HCC-Documentation_332651.html)
4. [Submitting Jobs](Submitting-Jobs_332222.html)
<span id="title-text"> HCC-DOCS : Submitting HTCondor jobs </span>
==================================================================
Created by <span class="author"> Derek Weitzel</span>, last modified on
Sep 13, 2013
<span
class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span>
HTCondor is only available on Sandhills.
+++
title = "Submitting HTCondor Jobs"
description = "How to submit HTCondor Jobs on HCC resources."
+++
If you require features of HTCondor, such as DAGMan or Pegasus,
<a href="http://research.cs.wisc.edu/htcondor/" class="external-link">HTCondor</a> can
submit jobs onto Sandhills using HTCondor's PBS integration. This can
[HTCondor](http://research.cs.wisc.edu/htcondor/) can
submit jobs using HTCondor's PBS integration. This can
be done by adding `grid_resource = pbs` to the submit file. An example
submission script is below:
**submit.condor**
``` syntaxhighlighter-pre
{{% panel theme="info" header="submit.condor" %}}
{{< highlight batch >}}
universe = grid
grid_resource = pbs
executable = test.sh
......@@ -31,25 +19,21 @@ error = stuff.err
log = stuff.log
batch_queue = guest
queue
```
{{< /highlight >}}
{{% /panel %}}
The above script will translate the condor submit file into a SLURM
submit file, and execute the `test.sh` executable on a worker node.
<span
class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span>
The `/home` directories are read only on the Sandhills worker nodes. You
{{% notice warning %}}
The `/home` directories are read only on the worker nodes. You
have to submit your jobs from the `/work` directory just as you would in
SLURM.
{{% /notice %}}
Using Pegasus
-------------
### Using Pegasus
If you are using
<a href="http://pegasus.isi.edu/" class="external-link">Pegasus</a>,
If you are using [Pegasus](http://pegasus.isi.edu),
instructions on using the *glite* interface (as shown above) are
available on the
<a href="http://pegasus.isi.edu/wms/docs/latest/execution_environments.php#glite" class="external-link">User Guide</a>.
[User Guide](http://pegasus.isi.edu/wms/docs/latest/execution_environments.php#glite).
content/guides/submitting_jobs/submitting_jobs.md deleted 100644 → 0
+ 0
− 227
View file @ 2a8466e1
This diff is collapsed.
content/guides/submitting_jobs/submitting_matlab_jobs.md
+ 40
− 1337
View file @ 02bac6ae
This diff is collapsed.
content/guides/submitting_jobs/submitting_r_jobs.md
+ 172
− 1504
View file @ 02bac6ae
This diff is collapsed.
layouts/shortcodes/readfile.html 0 → 100644
+ 8
− 0
View file @ 02bac6ae
{{$file := .Get "file"}}
{{- if eq (.Get "markdown") "true" -}}
{{- $file | readFile | markdownify -}}
{{- else if (.Get "highlight") -}}
{{- highlight ($file | readFile) (.Get "highlight") "" -}}
{{- else -}}
{{ $file | readFile | safeHTML }}
{{- end -}}
static/html/crane.html 0 → 100644
+ 36
− 0
View file @ 02bac6ae
<p><em>last generated Wed Nov 7 15:47:00 2018</em></p>
<table style="font-size: small">
<colgroup>
<col style="width: 8.83281%;"/>
<col style="width: 11.9085%;"/>
<col style="width: 18.4543%;"/>
<col style="width: 18.3754%;"/>
<col style="width: 19.2429%;"/>
<col style="width: 7.57098%;"/>
<col style="width: 7.80757%;"/>
<col style="width: 7.80757%;"/>
</colgroup>
<tbody>
<tr style="font-size: x-small">
<th>Partition</th>
<th>Owner</th>
<th>Node total (NODExCPU/MEM/FEATURE)</th>
<th>Description</th>
<th>SLURM Specification</span> </th>
<th>Max Job Run Time</th>
<th>Max CPUs Per User</th>
<th>Max Jobs Per User</th>
</tr>
<tr>
<td colspan="1">batch</td>
<td colspan="1">shared</td>
<td colspan="1">399 total (377x16/64GB/ib; 6x36/256GB/opa; 16x36/512GB/opa)</td>
<td colspan="1">(default, no specification)</td>
<td colspan="1">#SBATCH --partition=batch</td>
<td colspan="1" style="text-align: center;" >7-00:00:00</td>
<td colspan="1" style="text-align: center;" >ib:2000 opa:576</td>
<td colspan="1" style="text-align: center;" >1000</td>
</tr>
</tbody>
</table>
static/html/tusker.html 0 → 100644
+ 36
− 0
View file @ 02bac6ae
<p><em>last generated Wed Nov 7 15:14:27 2018</em></p>
<table style="font-size: small">
<colgroup>
<col style="width: 8.83281%;"/>
<col style="width: 11.9085%;"/>
<col style="width: 18.4543%;"/>
<col style="width: 18.3754%;"/>
<col style="width: 19.2429%;"/>
<col style="width: 7.57098%;"/>
<col style="width: 7.80757%;"/>
<col style="width: 7.80757%;"/>
</colgroup>
<tbody>
<tr style="font-size: x-small">
<th>Partition</th>
<th>Owner</th>
<th>Node total (NODExCPU/MEM/FEATURE)</th>
<th>Description</th>
<th>SLURM Specification</span> </th>
<th>Max Job Run Time</th>
<th>Max CPUs Per User</th>
<th>Max Jobs Per User</th>
</tr>
<tr>
<td colspan="1" >batch</td>
<td colspan="1" >shared</td>
<td colspan="1" >38 total (38x64/256GB/none)</td>
<td colspan="1" >(default, no specification)</td>
<td colspan="1" >#SBATCH --partition=batch</td>
<td colspan="1" style="text-align: center;" >7-00:00:00</td>
<td colspan="1" style="text-align: center;" >2000</td>
<td colspan="1" style="text-align: center;" >1000</td>
</tr>
</tbody>
</table>
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment