-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/slurm #6
Conversation
Great! This is awesome, I'm so glad you guys jumped on this grenade. Sorry to rehash what we already talked about, but I am a slow thinker: I was wondering if you thought it might be possible to be able to be able to still use the num_jobs and cores_per_job fields rather than specifying the number of machines. For example I am thinking of a situation like this: you have a cluster of two nodes with 64 cores each and you want to run an IPython cluster with 4 engines and each engine be dedicated 12 cores because you are calling out to subprocess with a command that runs as a threaded application, and you want to give each call out 12 cores to work with. -N tells it to dedicate it on 2 separate nodes, which isn't exactly what we want since now we need to know about the machines in our cluster. Ideally, in our 2x64 core cluster above, if one node is empty it should run all 4 engines, each with 12 cores dedicated to it, on one node and fill it up. If each node is half full, it should run 2 engines on one node and 2 on the other. If one node is completely full and the other is half full it should stay pending. Is there a way we can have SLURM handle that and figure out how many machines to put the job on? Ideally we shouldn't care about anything other than for each engine, it has 12 cores dedicated on the same node, that is all and not how many different nodes they are on. Does srun -n 4 --cpus-per-task=12 do that? |
…ssing from bcbio-nextgen pipeline
Integration with bcbio-nextgen pipeline parameter passing
…and kill the jobs nicely with scancel
Fixup the example to work with resources (batch system native specs) and...
@vals and @brainstorm -- thanks for all the work on this. Merged in and will be included with the next release of bcbio-nextgen coming soon. We'll also be testing slurm here locally soon so this is really appreciated. |
Here are the SLURM (<=2.5) launchers I worked on at the Codefest 2013.