Minia assembly is non-deterministic in parallel

[tetedange13]

Description of feature

Hi all,


I noticed that when running assembly with Minia twice with exact same parameters, produced assembled genomes are slightly different
=> This is something known: GATB/minia#25 (comment)

To avoid that, Minia should be run with -nb-cores 1 -nb-glue-partitions 200 (not the case in current Minia nf-core module)
=> See "11 - Reproducibility" section of Minia manual

It first thought it would be OK to set deterministic behaviour as default, because Minia is fast and nextflow should be able to parallellize Minia processes over multiple samples
=> But my tests show a rather important impact on performances
(I only changed main.nf of Minia module, maybe there was something else to tweak to maintain performances ?)

So rather it could useful to add an optional parameter to enable deterministic Minia assembly (could be something like --deterministic-minia) ?
=> In case one wants to compare assembled genomes ?
=> Warning user that it will have a huge impact on performances


Hope this helps !
Have a nice day,
Felix.

[tetedange13]

Edit : Impact on performances (runtime) when using "deterministic Minia" is relative
=> Looking at execution_report file, with deterministic Minia :

• Takes about as long as Kraken2 step
• Still takes way less time than alignment with Bowtie2 step, which is the bottleneck (but only applies to people running both branches of viralrecon)