-
Notifications
You must be signed in to change notification settings - Fork 110
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
Update SPAdes module to official nf-core and version bump #666
Conversation
|
Need to check other downstreeam files to make sure if there is an issue, however it seems that the original SPADES(HYBIRD) modules exported the the main scaffolds as uncompressed for downstream.( even though it also exported a version as compressed). I think I will need to add an additional GUNZIP module after the assembly for safety... |
Added the GUNZIP module actually does somthing similar to pre-assemblies, but then local MEGAHIT module also exports uncompressed files... so I guess time to update this too But I need to udpate the MEGAHIT module to support co-assemblies (basically And also test the fix cpus thing |
@nf-core-bot fix linting |
Final thing: reimplement the CPU fixing |
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.
Great to see :D
conf/base.config
Outdated
cpus = { check_megahit_cpus (8, task.attempt ) } | ||
memory = { check_max (40.GB * task.attempt, 'memory' ) } | ||
time = { check_max (16.h * task.attempt, 'time' ) } | ||
cpus = { params.megahit_fix_cpu_1 ? 1 : check_max(8 * task.attempt, 'cpus') } |
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.
Does that work? I remember vaguely that it didn't work to access params
here, that's why I think I shifted the corresponding functionality to nextflow.config
... but maybe that changed?
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 yes, then this is course much cleaner :)
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.
It should do if it's in a closure { }
. That's why e.g. task.attempt
works.
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.
Did you test?
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.
Yes, but I will double test again 😬
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.
Hrm wait, this can't work as is as check_max
should be gone, do further testing!
|
For future reference, it does work! In the
When fixing the CPUs, as above, you see in the screenshots above that memory retries but CPUs stay at the values fixed by the parameters (the CPUs in the test.config is 12). Without specifying the fixed CPUs, retrying indeed increases the CPUs nextflow run ../main.nf -profile test,docker --outdir ./results |
TODO:
PR checklist
nf-core lint
).nextflow run . -profile test,docker --outdir <OUTDIR>
).nextflow run . -profile debug,test,docker --outdir <OUTDIR>
).docs/usage.md
is updated.docs/output.md
is updated.CHANGELOG.md
is updated.README.md
is updated (including new tool citations and authors/contributors).