-
Notifications
You must be signed in to change notification settings - Fork 720
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
{bio}[foss/2019b,fosscuda/2019b] RELION v3.1.0 #10965
{bio}[foss/2019b,fosscuda/2019b] RELION v3.1.0 #10965
Conversation
Test report by @lexming |
Test report by @lexming |
One drawback with separate cpu and gpu submit files is that the user will have to explicitly change the path to the submit file template in the gui when switching from one to the other. And if one is installed with foss and the other with fosscuda, they have to know how to do this with the full path. This is one of the major reasons for the patch that added the extra code for this. Also, the removal of "which" around all the commands was done since they caused problems with the generated submit files. Don't quite remember what at the moment. |
…asyconfigs into 20200712020923_new_pr_RELION310
a5534af
to
f626345
Compare
@akesandgren I did not bother with the Regarding the job templates, switching between the non-gpu and gpu jobs is transparent for our users. Once they load the module, the gui of relion automatically takes the corresponding job template and users can directly access it from the command line through the env var |
a859a51
to
f79e662
Compare
The template problem comes when using the GUI. The path to the template file is saved in the session files for the relion setup. |
@akesandgren you are right, However, the templates I submitted with this PR are just examples to be adapted on installation. So I do not mind using the gpu template on both easyconfigs and just set the gpu option to zero in By the way, can anybody (eg @boegel ) clarify why the test do not like my perfectly working |
Remember that the preconfigopts gets shipped to /bin/sh, you need to escape them correctly. |
The |
#SBATCH -c XXXthreadsXXX | ||
#SBATCH -e XXXerrfileXXX | ||
#SBATCH -o XXXoutfileXXX | ||
#SBATCH -A XXXextra2XXX |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If XXXextra2XXX is empty this will generate a strange error to the user, and so will the #SBATCH -t XXXextra1XXX:00:00 if extra1 is unset.
And by strange I meant really strange ones. Slurm isn't the best at producing good error messages at all times.
That's why I made those two explicitly include -A/-t in the variable, i.e. XXXaccountXXX and XXXtimelimitXXX
Then the user will at least get a good and understandable error.
Also, for us at least, the --gres part either has to be complete or not there at all. So I made it XXXgpuspecXXX. That way we can use a single cpu/gpu common template file.
It's something that may or may not be a complicated thing to specify and is highly site dependent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated those non-positional extra parameters so that they are not empty by default. This will avoid triggering unintended errors. However, I expect sysadmins installing this software to adapt the settings of easyconfig to their needs.
I agree that your patch does a much better job at providing custom parameters for Slurm, but I really think that it is not feasible to achieve an easyconfig of RELION that works out of the box for all sites. For instance, your patch won't work with Torque and I think that it is not guaranteed that it will work on all systems using Slurm. I also had to adapt the template for Torque to make it work in our systems, but in my opinion that should be expected, as simple things as queue names or accounting do vary. That's why my goal is to have something that provides a good starting point for EB users and that can be easily adapted.
So, we will stick to using the add_hpc2n_submit_file_args.patch. |
Also note that the sed cmd you're using doesn't quite match what the patch is doing. |
@akesandgren thanks for pointing out the missing changes in |
Oh wait, it's not merged yet... 🤦♂️ |
@boegel What do you mean? easybuilders/easybuild-framework#3386 is indeed merged |
…asyconfigs into 20200712020923_new_pr_RELION310
@boegel All tests finally passed on this one. It is ready for review. |
Test report by @lexming |
Test report by @lexming |
Test report by @boegel |
Test report by @boegel |
Test report by @boegel |
@lexming Since this requires customizations specific to the site, I think it makes sense to add a Longer term (but not necessarily a blocker for this PR), it probably makes sense to create a custom easyblock for |
@lexming Ping on adding some more documentation in a README? |
@boegel I explored the option with a README file but it turned out to be too long and still not very straightforward. Main issue is how the extra job parameters have to be declared as environment variables and also added in the job script template, but with different names. So, I went ahead and made an easyblock to simplify this installation. Please check again with easybuilders/easybuild-easyblocks#2274 |
@lexming: Tests failed in GitHub Actions, see https://github.com/easybuilders/easybuild-easyconfigs/actions/runs/410373490
bleep, bloop, I'm just a bot (boegelbot v20200716.01) |
So... where are we on this one? We got a new toy[1] and I'm trying to get it loaded up for the users. |
@JackPerdue flexing with your new toys is not nice, now I'm jealous! Regarding this PR, if you want to test it, you just need to use the easyblock for RELION in easybuilders/easybuild-easyblocks#2274. I just opened easybuilders/easybuild-easyblocks#2302 to fix the failing tests, but that is not really needed to use the easyblock. |
Test report by @lexming |
@lexming Thanks for the info. It installed without problem on the "old" cluster and the new. I'll leave for the user to test and provide us some feedback. Any desire whatsoever to add support for IBM's LSF? Our "older" cluster which is due to head out the door in the next semester or two used it (it came with the IBM cluster... wasn't our choice). Looks like it would be pretty easy to add to your easyblock if there was any interest. |
@lexming any interest in pushing this one along? |
@verdurin yes, I do. I'll go through the comments and see if I can get the easyblock merged 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
closing since RELION 4.0 is out and there are open PRs for that (e.g. #16527) |
(created using
eb --new-pr
)Depends on
#10963,#10964andeasybuilders/easybuild-framework#3386I used #9096 as reference and made some changes to it
configopts
for CUDA capabilities inRELION-3.1.0-fosscuda-2019b.eb
I cannot test the integration with Slurm, somebody with it (@akesandgren ) please test.
Update: made an easyblock to ease the configuration of RELION. This PR depends on easybuilders/easybuild-easyblocks#2274