Differences

This shows you the differences between two versions of the page.

--- 1slurm [2020/05/07 08:35] – admin
+++ 1slurm [2020/05/09 15:12] – admin
@@ Line 75: / Line 75: @@
 </code>
-=== Scripts (used with **sbatch**) ===
+=== Scripts (used with sbatch) ===
-It is convenient to write the job script in a file not only because in this way the script can be reused, but also because it is also possible to set ''sbatch'' options directly inside the script as in the following example:
+It is convenient to write the job script in a file not only because in this way the script can be reused, but also because it is also possible to set ''sbatch'' options directly inside the script as in the following example (that shows the content of the file sheepit.slurm):
 <code>
 $ cat sheepit.slurm
@@ Line 102: / Line 102: @@
 srun sleep 60
 echo "$(hostname) $(date)"
 </code>
+<note>
+At the beginning of the file you can read the line ''#!/bin/bash'' that is not strictly necessary. It turns out that it's common practice to identify the slurm script as bash scripts so they can be executed also outside of the cluster. in this case the '#SBATCH' lines are interpreted as comments.
+</note>
 Inside a script, all the line that starts with the '#' char are comment, but the lines that start with the '#SBATCH' string, are directives for the queuing system.
 The example above instruct the queuing system to:
@@ Line 136: / Line 141: @@
 <note important>
-It is **mandatory** to specify at least the estimated run time of the job and the memory needed by so that the scheduler can optimize the machines usage and the overall cluster throughput. If your job will pass the limits you fixed, it will be automatically killed by the cluster manager.
+It is **mandatory** to specify at least the estimated run time of the job and the memory needed, so the scheduler can optimize the machines/cores/memory usage and the overall cluster throughput. If your job will pass the limits you fixed, it will be automatically killed by the cluster manager.
 Please keep in mind that longer jobs are less likely to enter the queue when the cluster load is high. Therefore, don't be lazy and do not always ask for //infinite// run time because your job will remain stuck in the queue.