Hi!
I have made my own pipeline for genome assemb...
# genomeassemblero
oliviercoen
10/22/2025, 9:32 AMHi!
I have made my own pipeline for genome assembly at https://github.com/OlivierCoen/EGCE-genomeassembler and I think it can bring interesting features to #C038XMTQWBT.
With this pipeline, and using Nanopore long reads ~10k bp on average / Q20 > 99% + Hi-C data, I was able to build a 1.6Gb genome assembly with a N50 > 55M (we have the full chromosomes basically, except perhaps some internal gaps).
I've implemented quite a lot of things for phasing but I've not tested them since I eventually did not need them (so far).
But everything related to:
ā¢ polishing (I rewrote a bit the medaka pipeline in Nextflow to make it more scalable)
ā¢ Hi-C scaffolding (in particular I wrote the full Arima pipeline in Nextflow)
ā¢ gap closing: several tools are implemented to allow users choose what they want to do
can bring valuable value to #C038XMTQWBT
Do you think I can start by making a PR to integrate medaka in the pipeline (as an alternative option to pilon when there is no short read sequencing data)?
Thanks,
Olivier
n
Niklas Schandry
10/22/2025, 9:35 AMMedaka is already part of the pipeline
Niklas Schandry
10/22/2025, 9:37 AMBut if your implementation is much better to mine (https://github.com/nf-core/genomeassembler/blob/master/modules/local/medaka/medaka_consensus/main.nf) please feel free to open a PR
Niklas Schandry
10/22/2025, 9:37 AMhowever, please use the current dev branch as the base for your pr(s)
š 1
o
oliviercoen
10/22/2025, 9:37 AMI forgot that, sorry. What I actually did is to follow the medaka's developers guidelines to improve parallelism:
https://github.com/nanoporetech/medaka?tab=readme-ov-file#improving-parallelism
oliviercoen
10/22/2025, 9:38 AMYes of course, it would be on dev branch š
n
Niklas Schandry
10/22/2025, 9:39 AMI think my implementation is also based on those guidelines
Niklas Schandry
10/22/2025, 9:39 AMbut it has been a while
Niklas Schandry
10/22/2025, 9:39 AMi also noticed that with sufficient coverage from ONT and / or HiFi, polishing does not seem to super necessary
š 1
Niklas Schandry
10/22/2025, 9:40 AMbut of course it still makes sense to have those tools in the pipeline
o
oliviercoen
10/22/2025, 9:43 AMYes, if data are good enough, polishing is not necessary. In the Flye documentation, it's also said that it's unnecessary to polish the draft assembly because Flye does it internally. But as you said, it's always good to have it since not all input data have sufficient quality / coverage
oliviercoen
10/22/2025, 9:46 AMI just saw that your implementation of parallelised medaka inference is contained in one single module,:
https://github.com/nf-core/genomeassembler/blob/dev/modules/local/medaka/medaka_consensus/main.nf
while my implementation is in a subworflow, which launches medaka inference of each chunk in a separate process (thus making it more scalable):
https://github.com/OlivierCoen/EGCE-genomeassembler/blob/main/subworkflows/local/medaka/main.nf
oliviercoen
10/22/2025, 9:47 AMI don't want to force anything, but if you think it can be worth it, I can make a PR
n
Niklas Schandry
10/22/2025, 12:01 PMYou approach is probably more nextflow-y
Niklas Schandry
10/22/2025, 12:01 PMmaybe this could also be an nf-core subworkflow?
o
oliviercoen
10/22/2025, 3:07 PMactually you are right, I should publish tose things primarily as modules / subworkflows
Then, if you think it might be interesting for the #C038XMTQWBT pipeline, you can integrate them š
oliviercoen
10/22/2025, 3:08 PMOr I can do it if you prefer
n
Niklas Schandry
10/22/2025, 5:19 PMOnce you have them ready as modules or subworkflows i would be happy if you could integrate them. For things that require actual workflow changes, such as integrating hic scaffolding, we should probably take a look together, they would also entail updates to the reporting
š 1