<p>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.</p>

<p>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.  </p>

<p>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.</p>

CC BY-SA 3.0
2018-03-01T06:10:34.227Z
2018-03-01T06:10:34.227Z
Edward Kirton
<p>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. </p>

<p>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.</p>

CC BY-SA 3.0
2018-02-15T23:44:05.020Z
2018-02-15T23:44:05.020Z
conchoecia
<p>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.</p>

CC BY-SA 3.0
2018-02-15T23:39:58.220Z
2018-02-15T23:49:21.790Z
2018-02-15T23:49:21.790Z
Devon Ryan
<p>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?</p>

CC BY-SA 3.0
2018-02-15T19:12:37.807Z
Are you doing any sort of digital normalization or correction of the input reads, or just feeding increasing numbers of raw reads in?
Devon Ryan
CC BY-SA 3.0
2018-02-15T21:27:22.347Z
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.
twmccart
CC BY-SA 3.0
2018-02-15T23:11:32.617Z
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.
user172818
<assembly>
Why can using more reads lead to a lower quality assembly?
# Why can using more reads lead to a lower quality assembly?

(Asked by: username_0 on 2018-02-15)

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?

**Tags:** assembly
> **Comments:**
> **username_1**: Are you doing any sort of digital normalization or correction of the input reads, or just feeding increasing numbers of raw reads in?  
> **username_0**: 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.  
> **username_2**: 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.  

---

## 3 answers

### Answer by username_1 on 2018-02-15. Score: 4 | Accepted answer

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.


---

### Answer by username_3 on 2018-03-01. Score: 0

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.


---

### Answer by username_4 on 2018-02-15. Score: 0

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.


---

