-
Notifications
You must be signed in to change notification settings - Fork 22
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
Slurm jobs submissions #134
Comments
It seems I was closer than I thought!
|
Super, I will put this in. Out of curiosity can you post the output of $SUBMIT_COMMAND on your system? |
Is the echo necessary or can we do: |
Great timing! I was about to ask about something relevant. First, here is the output from the $SUBMIT_COMMAND (also stored in the submit.txt file on TURBINE_OUTPUT directory).
Good point about the Now, my question. I'm not sure how the resources are allocated for different invocations of my program. Below are some examples where these number are different between these 2 files with different settings:
Now, when I also set
And finally, here is another test, this time adding to the setting
|
Hello again, As a follow up, I'm wondering if there is a way to map directly between Swift-t options, and standard slurm options. I'm trying to run a pipeline with the settings below:
Yet, the scheduler records: Thank you, |
Moving this to a new issue #138 . |
Hello,
I would like to report a problem when submitting jobs to a slurm-scheduled system. On my attempts working with the most recent V1.3 Swift/T, I always get the
sbatch failed!
message whenever I provoke a hypotheticaltst.swift
program (or its compiled version).Here is an example to demonstrate:
Now, the code stored in
${TURBINE_OUTPUT}/submit.txt
does actually work on its own (i.e. when it is manually run, it does the right thing: reserving the right memory, time, ..etc and also implements the right swift/t code).Looking somewhat closely at the code in scripts/submit/slurm/turbine-slurm-run.zsh, this meant jobs were not getting IDs, because they were never submitted to the scheduler to begin with, which can be seen in line 75. Here is a quick attempt to rectify:
This solution is half working: it does submit the swift/t job, and reserves the right resources, but doesn't properly extract the JOB_ID. It is kind of tolerable however, as I can
squeue
anyway.I know there must be a neater way to do this, so I'm eager to know it, but I hope this is nonetheless helpful.
Thank you,
Azza
The text was updated successfully, but these errors were encountered: