Entering edit mode
7.5 years ago
igor
13k
All read trimmer work on single-end FASTQs. Most support paired-end FASTQs (both input mates must pass filters to be in output). Is there a trimmer that supports more than two mates (yes, it's possible to have more than just R1 and R2)?
If not, what would be the simplest way to perform quality trimming and still keep the same clusters in the same order across multiple FASTQs?
BBDuk's "ordered" flag will keep all output reads in the input order. And if you set "minlen=0" it will not discard any reads; rather they will be trimmed to a minimum length of 1. For example:
That right-trims the reads to Q15, maintains order, and discards nothing.
The only standard additional reads I know about are the barcode reads, which you would generally not want to trim.
Wait how do you get more than 2 read directions? Or did I misunderstood something?
For example, you can have R1, R2, and index read. Each one belongs to the same cluster and each one is a separate read.
Out of curiosity, why do you want a separate file containing the index reads? Usually those just get moved into the read names and no file with them written.
Sometimes tools require that. For example, QIIME.
Why is the order important (out of curiosity) and are you worried about keeping the order in the tag/barcode file?
@Brian suggested an alternative but that would leave some reads with at least 1 base in them. Probably not the solution you want. Since this is a special case you may need to code something yourself to bring the barcode file in sync after R1/R4 (if R2/R3 are you index reads for a 2D run) are trimmed.
I've run into errors with aligners before when reads weren't in the same order, so I'd rather not risk it.
If you use bbduk.sh then order of R1/R2 is maintained after trimming.