PE reads uneven after cutadapt

Question

[blur]

Hi! I used cutadapt on my PE reads, and then FASTX to collapse duplicate reads in my data. Then I proceeded to do bowtie2 - turns out that there was a different no. of reads in R1 than R2 so bowtie could not run at all! I assume this was not do to FASTX, but rather to cutadapt (I specified to remove reads that became too short after trimming). so my questions are:

• Am I right in my assumption regarding cutadapt?
• Is there any way to make the reads appear even again, without hurting the data? (I was not sure if just adding reads would be OK or not).

Thanks for the help!

[GenoMax]

If you are happy with the end result then you could use repair.sh from BBMap to re-sync your files (C: Calculating number of reads for paired end reads? ).

[i.sudbery]

Errr.... Why would it not be fastx_collapser? If one of a pair is duplicate and the other isn't, you'll lose a read from one file but not the other....

Cutadapt has a paired end mode. As far as I can tell fastx_collapser doesn't.

[i.sudbery]

While fastx-collapser doesn't seem to support paired end processing, the tally tool apparently does the same thing and does accept paired data.

[GenoMax]

If we are talking about other read de-duplicators then dedupe.sh from BBMap would be a great candidate as well.

Answer 1

[dariober]

Recent versions of cutadapt support paired end trimming while keeping the two files in sync. For example:

cutadapt -a AGATCGGAAGAGC -A AGATCGGAAGAGC -o trimmed.R1.fq -p trimmed.R2.fq read.R1.fq read.R2.fq

How did you run cutadapt exactly?

About your second point, maybe it's possible to rescue the corrupted files but I strongly doubt it is worth the effort (maybe as an exercise...). Just start again once you find out what went wrong.