<p>You can try <a href="https://contignant.com" rel="nofollow noreferrer">s-aligner</a> (free for 15 days) which usually gets quite larger contigs and quite larger NG50 for metagenomic data containing viruses (also phages). Indeed metaSPAdes also gets larger contigs, despite shorter than s-aligner.
<a href="https://i.sstatic.net/qQKaY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qQKaY.png" alt="enter image description here" /></a></p>
<p>Ref. <a href="https://www.biorxiv.org/content/10.1101/2021.02.02.429443v1" rel="nofollow noreferrer">s-aligner: a greedy algorithm for non-greedy de novo genome assembly</a></p>

CC BY-SA 4.0
2021-08-09T15:26:44.447Z
Do I understand right that you are the developer of this commercial product? Please, disclose your conflict of interest.
Kamil S Jaron
CC BY-SA 4.0
2021-03-11T18:08:07.297Z
2021-03-11T18:08:07.297Z
juanjo75es
<p>I've been using MEGAHIT to assemble metagenomes, with particular focus on specific genomic areas.</p>
<p>Sometimes all I get is gene fragments or pathway fragments (eg. if I know that genes A, B, C, D and E should be together, I only get A, B, C in one contig, and maybe D and E in another). That is understandable when the sequencing depth is low, and I'm assume that it's the best I can get.</p>
<p>However. In two of my metagenomes, the genes of interest seem to be abundant (depth of 100-300+ listed for MEGAHIT contigs). And I still have the same problem. I assume that these 'breaks' between contigs are due to natural sequence variation which breaks the assembly process. (while sequencing errors are also possible, I've used bbduk to clean my data prior to assembly)</p>
<p>I'd like to have larger contigs because I'm curious about the gene order. Things I've tried (did not work): visualizing assembly graphs with Bandage around Blast hits, starting with a smaller k-min (21 as opposed to 27).</p>
<p>So I guess I'm wondering if using even smaller k-mers might make a difference. Or if someone has another suggestion, I'm happy to listen! Thank you.</p>
<p>Megahit setting used:</p>
<pre><code>megahit -r input_files.fastq --num-cpu-threads 32 --min-contig-len 300 --presets meta-large -o output
megahit -r input_files.fastq --num-cpu-threads 32 --min-contig-len 1500 --presets meta-sensitive -o output
</code></pre>
<p>Meta-large starts from minimum kmer size 27; meta-sensitive from 21.</p>

CC BY-SA 4.0
2020-03-18T13:53:12.900Z
Typically the tradeoff is smaller kmers getting you a more connected assembly graph, while longer kmers can span repeats more and perhaps connect more contigs. So I think the logical thing might be to try and _increase_ kmer size.
NatWH
CC BY-SA 4.0
2020-03-18T15:50:23.680Z
@NatWH Thank you, I can see how that would work. Considering that a MEGAHIT run goes all up to k-mer size 127 (maximum), and the results that I get are as such, shall I assume that nothing can be done just by changing k-mer size? (or even in general)
Laura
CC BY-SA 4.0
2020-03-19T14:21:59.293Z
Does MEGAHIT build the results of the graph from larger kmer sizes on top of those from smaller in some way, akin to SPAdes? If so, then the method should already have accounted for this. If not, then perhaps you can try and manually increase kmer size.
NatWH
<gene><assembly><pathway><k-mer>
Will using smaller kmers help get larger contigs? If not, then what?
# Will using smaller kmers help get larger contigs? If not, then what?

(Asked by: username_0 on 2020-03-17)

I've been using MEGAHIT to assemble metagenomes, with particular focus on specific genomic areas.
Sometimes all I get is gene fragments or pathway fragments (eg. if I know that genes A, B, C, D and E should be together, I only get A, B, C in one contig, and maybe D and E in another). That is understandable when the sequencing depth is low, and I'm assume that it's the best I can get.
However. In two of my metagenomes, the genes of interest seem to be abundant (depth of 100-300+ listed for MEGAHIT contigs). And I still have the same problem. I assume that these 'breaks' between contigs are due to natural sequence variation which breaks the assembly process. (while sequencing errors are also possible, I've used bbduk to clean my data prior to assembly)
I'd like to have larger contigs because I'm curious about the gene order. Things I've tried (did not work): visualizing assembly graphs with Bandage around Blast hits, starting with a smaller k-min (21 as opposed to 27).
So I guess I'm wondering if using even smaller k-mers might make a difference. Or if someone has another suggestion, I'm happy to listen! Thank you.
Megahit setting used:
megahit -r input_files.fastq --num-cpu-threads 32 --min-contig-len 300 --presets meta-large -o output
megahit -r input_files.fastq --num-cpu-threads 32 --min-contig-len 1500 --presets meta-sensitive -o output

Meta-large starts from minimum kmer size 27; meta-sensitive from 21.

**Tags:** gene, assembly, pathway, k-mer
> **Comments:**
> **username_1**: Typically the tradeoff is smaller kmers getting you a more connected assembly graph, while longer kmers can span repeats more and perhaps connect more contigs. So I think the logical thing might be to try and _increase_ kmer size.  
> **username_0**: @NatWH Thank you, I can see how that would work. Considering that a MEGAHIT run goes all up to k-mer size 127 (maximum), and the results that I get are as such, shall I assume that nothing can be done just by changing k-mer size? (or even in general)  
> **username_1**: Does MEGAHIT build the results of the graph from larger kmer sizes on top of those from smaller in some way, akin to SPAdes? If so, then the method should already have accounted for this. If not, then perhaps you can try and manually increase kmer size.  

---

## 1 answers

### Answer by username_2 on 2021-03-11. Score: 0

You can try [s-aligner](https://contignant.com) (free for 15 days) which usually gets quite larger contigs and quite larger NG50 for metagenomic data containing viruses (also phages). Indeed metaSPAdes also gets larger contigs, despite shorter than s-aligner.
[![enter image description here](https://i.sstatic.net/qQKaY.png)](https://i.sstatic.net/qQKaY.png)

Ref. [s-aligner: a greedy algorithm for non-greedy de novo genome assembly](https://www.biorxiv.org/content/10.1101/2021.02.02.429443v1)

> **Comments:**
> **username_3**: Do I understand right that you are the developer of this commercial product? Please, disclose your conflict of interest.  

---

