I'm running per-sample metagenomic assembly with MEGAHIT v1.2 on host-filtered paired-end reads, using a two-pass strategy:
Pass 1: assemble paired-end reads (R1 + R2)
Pass 2: reassemble using Pass 1 contigs + singleton reads as single-end input (-r)
I ran this full workflow twice, changing only min-contig-len (500 vs. 1), and evaluated the merged, per-sample assemblies with QUAST:
The increase in total contigs at --min-contig-len 1 is expected. What's unexpected is that the number of long contigs (=>1000 bp and up) roughly halved rather than staying constant.
Question: I assumed --min-contig-len only filters output length and shouldn't affect which long contigs get assembled. Why would lowering it cause a loss of long contigs rather than just an increase in short ones? Is this related to Pass 1's unfiltered output (millions of short contigs) being reused as -r input in Pass 2? Any explanation or prior experience with this in a two-pass/reassembly setup would be appreciated.
I think you may need to ask the MEGAHIT authors directly, or look into the code for the answer. My guess is that allowing smaller contigs relaxes the pressure to assemble larger contigs, thus resulting in their reduced number.
Why do you not assemble paired + single reads together in pass 1? Not sure what would be the advantage of your approach over the simultaneous assembly with all the reads.
Separately, what you are doing makes little sense for metagenomic assembly. It is questionable whether one can reliably bin even contigs that are 1000 bp in length. Anything smaller than that, and certainly smaller than 500 bp, is impossible to bin. Contigs smaller than 500 bp are unlikely to have anything close to a whole gene, even if your interest is only to get a catalog of genes without necessarily knowing where they belong. Finally, those small contigs are literally junk because they would assemble into larger contigs if there was decent support.
Thank you very much; this means a lot to me. What I believe is that Pass 1 creates a high-quality backbone assembly using paired-end reads, while Pass 2 uses singleton reads to improve and extend the assembly.
Do you have an alternative option to improve contig quality?
I think you will get the best assembly by using all the available reads at once. I do not think it will be vastly superior to your two-pass approach with --min-contig-len 500, but it should be better. What you are doing is like making a layer cake and using 2/3 of the filling ingredients separately to make the cake filling, then using the other 1/3 of the ingredients to top the cake. You will at best get the same result as making the whole filling at once, but it is more likely that something will be off.
Log in to answer this question.
