#981 lrz_cm4 config and doc Pull request opened by nschan --- ## name: lrz_cm4 about: A configuration for LRZ CM4 clusters Please follow these steps before submitting your PR: • If your PR is a work in progress, include

[WIP]

in its title • Your PR targets the

master

branch Steps for adding a new config profile: • Add your custom config file to the

conf/

directory • Add your documentation file to the

docs/

directory • Add your custom profile to the

nfcore_custom.config

file in the top-level directory • Add your profile name to the

profile:

scope in

.github/workflows/main.yml

• OPTIONAL: Add your custom profile path and GitHub user name to

.github/CODEOWNERS

(

**/<custom-profile>** @<github-username>

) Opening this for discussion / testing. @Jin Khoo @amitfenn In short, this provides a single profile, for running "nextflow inside slurm" on CM4. nf-core/configs

I made this config, and it uses

SLURM

env variables to set limits, so the test fails. Should I worry about that?

Of course I don't know if your site have special users that don't run the same pipelines as others, but to me it seems odd just having what I feel is niche runners that require special handling. So my knee-jerk recommendation would be to include a normal profile and set that for the testing, having the flux one as an extra similar to the

local

you have.

Not sure if I understand, but these clusters are kind of used by >3 universities, mostly scientists, so they are all special with niche requirements 😉

What does "nextflow with slurm executor is not allowed" mean?

That they do not want nextflow with executor = "slurm" running on a head node, compute node are not submit hosts, and even if they were, the issue seems to be the slurm backend

And for clarity; this is a general communication? From what you wrote previously, you seem to run a fair amount of things with short jobs. I know there are pipelines with a lot of that, but I believe most tend to have OK job size (running for hours or days). I have certainly told people not to do stupid things they were doing without it meaning "the thing" would be banned generally, but rather that they shouldn't misuse stuff. If it's actually "banned", I don't see there's being any good way of dealing with it.

This is a very clear, repeated, general communication from the datacenter for these particular (public) clusters with a large number of users, yes. Personally, I am using a different cluster where I am allowed to use executor = "slurm", housed in the same data center. Since the nextflow local userbase is small and the datacenter guys have little experience with it, they involved me and we trying to work out a way to use nextflow on the public clusters, without burdening the slurm backend. The solution is nextflow inside a slurm job, executing "local" (or flux for multi-node slurm "container" job), so the scheduling of the pipeline is not done via slurm

Then there's probably no way I'd say is good 😞 (for those seeing the profile only, it might be good documenting that the slurm executor is not usable on the cluster.)

Yes, of course, I did that https://github.com/nf-core/configs/pull/981/files/84f0644cb333e66e22181d4644cdabbd37b6e573

You mean "> NB: Please note that using nextflow with the SLURM executor on the serial partition is not permitted." ? It didn't make the above very clear to me 🙂

Hm, I see, which part is unclear?

I'd say it's not very noticable, and even then seen, it only implies it's a specific partition (

serial

) where you can't use the slurm executor (i.e. hosts in that partitions are not allowed to submit jobs).

Hm, I see, I would kind of hope that users have looked at this https://doku.lrz.de/job-processing-on-the-linux-cluster-10745970.html and have an idea of the partitions, but I will rephrase to make it clearer that it is simply "no nextflow on login node"

That mentions some things on login nodes, but I don't see anything about the "no submission from jobs", but yes.

Thanks, I added another note on that

#981 lrz_cm4 config and doc Pull request merged by nschan nf-core/configs