Reduced sequences after joining paired ends

[rlhughes (Riley)]

Hello,
I have an issue after merging paired reads. I used cutadapt to trim barcodes and primers, imported to qiime 2, then used vsearch join-pairs to merge forward and reverse reads. However, compared to non-joined reads, this resulted in a BIG loss of sequences. Per this previous forum post, I checked the quality of reads and they have good quality so I'm not sure what's causing this big decrease. If it helps diagnose the problem, I also demultiplexed using cutadapt without trimming barcodes/primers, imported, and joined, and did not observe this big decrease in sequence number so I don't know if that means anything...attached are the paired-end-demux.qzv (non-joined) and demux-joined.qzv (joined) files. Any help is appreciated! Thank you
demux-joined.qzv (295.0 KB)
paired-end-demux.qzv (293.2 KB)

[Nicholas_Bokulich]

@rlhughes

I have an issue after merging paired reads. I used cutadapt to trim barcodes and primers, imported to qiime 2, then used vsearch join-pairs to merge forward and reverse reads. However, compared to non-joined reads, this resulted in a BIG loss of sequences.

Are you sure your reads are long enough to overlap effectively? We see this problem a lot (on the forum and in our own data) — check the lengths of your reads, the expected length distribution of your amplicons, and figure out if R1 + R2 - minimum overlap >= max expected length.

@rlhughes

I also demultiplexed using cutadapt without trimming barcodes/primers, imported, and joined, and did not observe this big decrease in sequence number so I don’t know if that means anything…

Now that is weird... I wonder if the trimming is resulting in reads being truncated to the point that they no longer have enough length to overlap? That does not really make sense under normal circumstances (since even if an adapter is being trimming from the 3' end, presumably the paired read should still overlap), but maybe cutadapt is trimming your sequences in the wrong spot? You should spot-check a few of the sequences that are not joining, both before and after cutadapt. Are these being trimmed in unexpected ways???

[Nicholas_Bokulich]

@rlhughes

I also demultiplexed using cutadapt without trimming barcodes/primers, imported, and joined, and did not observe this big decrease in sequence number

@rlhughes you are using vsearch to join paired-end reads, not dada2, but this post might explain the phenomenon you are seeing:

DADA2 paired-end (EMP): All sequences of same length

Ah I see what happened here. The way you trimmed your reads initially resulted in the reverse read always completely overlapping the forward read. That is, the full amplicon length varies (tightly) between about 251-255 nts. But since you cut off the first 5 nts of the reverse read, it always started at a position within the forward read, and because it was truncated at 203 nts, it never extended past the other end of the forward read. So every merged read is just the length of the forward read…