I modified the code to match the documentation, which is to keep
parsing until it reaches a command. I checked all the way back to
Slurm v2.0 and this has been the behaviour of sbatch for many years.
This will be in v14.11.6, which we hope to release this week. There's
a patch available h
Hi Magnus and Andy,
from my side +1 for the
#SBATCH END-OF-OPTIONS
solution
On 21/04/15 14:44, Magnus Jonsson wrote:
A better approach would be to add to SLURM a "#SBATCH END-OF-OPTIONS" or
something similar to mark the end of sbatch options and that sbatch can
stop parsing from that point.
/M
A better approach would be to add to SLURM a "#SBATCH END-OF-OPTIONS" or
something similar to mark the end of sbatch options and that sbatch can
stop parsing from that point.
/Magnus
On 2015-04-21 14:40, Andy Riebs wrote:
Never mind; which I changed "#sbatch" to the correct "#SBATCH", I got 4
Never mind; which I changed "#sbatch" to the correct "#SBATCH", I
got 4 tasks. According to the man page, this is a bug. For now, I
like Magnus's suggestion :-)
On 04/21/2015 08:21 AM, Andy Riebs
wrote:
Hendryk, what sbatch command line options are you using? How are
you determinin
Hendryk, what sbatch command line options are you using? How are you
determining that job 1 got 2 tasks? I just tried the following
script, and it correctly ran just 1 task:
$ cat test.sh
#!/bin/bash
#SBATCH --ntasks=1
srun hostname
#sbatch --ntasks=4
## end of script
$ sbatch
Hi!
A simple solution would be do:
SBATCH="#SBATCH"
cat << EOF
...
$SBATCH --nodes=1
EOF
/Magnus
On 2015-04-21 13:50, Hendryk Bockelmann wrote:
Hello,
is there a way to prevent slurm from parsing the whole jobscript for
#SBATCH statements?
Assume I have the following jobscript "job1.sh":
