Closed jdwheaton closed 4 years ago
Hi,
indeed that is the case. Our HPC recommends the use of --ntasks which may be why I mapped to that parameter to begin with, but what you're saying makes sense. I hadn't given it that much thought actually. @mwort any thoughts on this?
Thanks for pointing this out @jdwheaton, I think that is correct and should be changed (threads also implies only one node). I have been using -N 1
which works but cpus-per-tasks
is certainly more accurate here. @percyfal are you gonna do a direct push for this? Please also see my other PR.
@mwort Yes I can do a push; you PR is under review and there is a comment.
I was talking about #34;)
While I agree that "-c" is the right mapping for "threads", my memory specifications are being treated as men-per-cpu when I use it. If I map "threads" to "ntasks", the memory requirements are used as "mem" and not multiplied by the threads parameter. Is this behavior by design?
Hi, sorry for the late response. I think I see what you mean, but could you provide an example of what you expect? I'm not sure where, or if, a modification is possible. Are you using the advanced argument conversion?
Hi,
I was considering adopting this slurm profile and was reading through the job submission script when I noticed that you are mapping the snakemake
threads
parameter to SLURM's--ntasks / -n
when submitting to sbatch. I believe that this should instead be--cpus-per-task / -c
, since most applications (at least in my experience) are not run using MPI and thus cannot be split across multiple nodes, which-c
explicitly prevents. It is not clear to me if the behavior of specifying a single node (using-N 1-1
) in concert with-n X
will achieve the same result; however, I believe the explicit approach that fits the most common use case should be the default. Perhaps other options could be included for MPI-capable jobs?