Increasing number of nonchimeric reads compared to the number of input reads

[Abdelrahim-maker]

Hi everyone

I was using dada2 in R on my arbuscular mycorrhizal fungi reads and I noticed that after truncating them, I got an increased number of nonchimeric reads compared to the input I had. for example my input for one of the samples was 666 reads and the nonchim is 47,000. another sample has an input of 8 and nonchim which is 49 reads. How is that possible?

Thanks

[benjjneb]

It's not possible. How are you arriving at this result?

[Abdelrahim-maker]

@benjjneb apologies for the late reply. That is how I was doing it Parameters used:
filterAndTrim(fnFs, filtFs, fnRs, filtRs, truncLen=c(280,275),
maxN=0, maxEE=c(2,2), trimLeft = 10, truncQ=2, rm.phix=FALSE,
compress=FALSE, multithread=n_cores, verbose = TRUE)
overall Median loss (difference between input and nonchimeric) = 15311, percentage= 46.99108
Overall minimum percentage loss = 32.5477
Overall maximum percentage loss = 100

[benjjneb]

Can you provide the output of read tracking through the workflow, as demonstrated in the read tracking section of the dada2 tutorial? https://benjjneb.github.io/dada2/tutorial.html#track-reads-through-the-pipeline

[Abdelrahim-maker]

16s_reads_summary (1) (1) (2).csv
densoised_reads_amf (5) (2).csv

These are the output for AMF and 16S rRNA which I have noticed issues after using these parameters

[benjjneb]

Can you clarify what your issue is? I do not see the examples that you referenced in your first post, nor any sample where the number of nonchimeric reads is more than the input.

[IK237]

Hello, I think I have a similar issue as above. I'm sequencing the ITS2 region for Fungal Reads and I've noticed a few samples where I have a low input of initial reads and a significantly higher number of reads after going through the other parts of the pipeline.

Here is the code I am running to get these results
ITS Sequencing Code.txt

Here is a list of the reads tracked through the pipeline.
ITS Read Track.csv

JKA010219ITS, JKA010293ITS, and JKA010580ITS are a few of my samples that do this.

I've looked but can't seem to find any other reports of this happening. I generally have kept the default pipeline for ITS reads in Dada2. My primers are ITS4 and fITS7. Thank you for your help!

[Abdelrahim-maker]

@IK237 I found this code to adjust my table #710 and it helped me. Now my reads are fine. Hopefully this would solve your issue too

[IK237]

I ended up fixing this but going to an adjacent post on this issue found here #715 so thanks for that info Abdelrahim-maker.

I fixed this by doing

nrow(out)
[1] 177
length(dadaFs)
[1] 171
length(dadaRs)
[1] 171
length(mergers)
[1] 171
nrow(seqtab)
[1] 171
nrow(seqtab.nochim)
[1] 171

The numbers generated here should all be equal. nrow(out) was not for me. To fix this I ran this code to assign an "exists" variable.

exists <- file.exists(filtFs)
table(exists)
exists
FALSE TRUE
6 171

The comma in out = out[exists,] below denotes that dada2 should look at the rows and is necessary as far as I can tell.

out = out[exists,]

running this again shows that all sample numbers are equal and should be good to run the cbind command.

nrow(out)
[1] 171
length(dadaFs)
[1] 171
length(dadaRs)
[1] 171
length(mergers)
[1] 171
nrow(seqtab)
[1] 171
nrow(seqtab.nochim)
[1] 171