I am experimenting with adding additional reads to the input files I'm giving SOAPdenovo2, and there comes a point where a good contig I've been watching actually stops showing up. Does anyone have a quick answer to why that might happen?

  • $\begingroup$ Are you doing any sort of digital normalization or correction of the input reads, or just feeding increasing numbers of raw reads in? $\endgroup$
    – Devon Ryan
    Feb 15, 2018 at 19:12
  • $\begingroup$ They are reads that have been trimmed for quality, and have been selected from a larger read pool based on mapping the pre-assembled contigs. $\endgroup$
    – twmccart
    Feb 15, 2018 at 21:27
  • 1
    $\begingroup$ Excessively high depth may introduce errors that can't be fixed. Some assemblers subsample reads to a lower depth. In general, de novo assembly is a mess. Even assembler developers often can't explain why things happen. Let alone outsiders. $\endgroup$
    – user172818
    Feb 15, 2018 at 23:11

3 Answers 3


The more reads you add the more errors you add into the assembly. This is because additional duplicate reads don't add nodes/edges to the de Bruijn graph, but those with errors do. By preselecting those reads aligning to your desired contigs, you may be further exacerbating this effect and further hindering SOAPdenovo2's ability to do k-mer correction (after all, the observed k-mer frequency of errors would be higher). This then results in additional incorrect paths through the graph that the assembler has to traverse.


I think the reason that no one has submitted an actual answer yet is because this question is really dependent on the size of the genome you are sequencing, its repetitive content, the level of heterozygosity, the amount of contamination, the type of data (illumina, long illumina, long reads), the library type, library peculariaties, PCR error, the heterozygosity of the contig in question, the complexity of the contig in question (high information content? repeats? AT/GC%?), and probably some other things that I haven't thought of.

Like @user172818 said, all of those things ON TOP OF all of the quirks of different assemblers make this a hard question to answer for you without a full diagnosis of your data and the genome of the thing you are sequencing/assembling.


Yes, this is commonly observed and both the previous answers (Devon Ryan and conchoecia) are spot on so I won't reiterate their explanations on why.

Try bfc (bloom-filter correction) to "fix" likely erroneous base-calls (i.e. uncharacteristically rare kmers) in the reads prior to assembly. This will not only help your assembly, but it shall require less RAM and time.

I also recommend trying running your assembler with multiple kmer parameters, as some values will work better than others for a particular dataset. You can simply choose the best assembly or go through a more complicated effort to merge them, depending on your circumstances.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.