We recently discovered a bug related to the
trim-paired command that, in certain situations, can produce incorrect results. In particular, the forward and reverse reads are swapped, causing the underlying
cutadapt command to apply the forward read trimming parameters on the reverse reads (and vice versa).
This issue impacts the following versions of
If you think you may have been impacted please check your provenance at https://view.qiime2.org for the versions listed above.
This problem occurs when the reverse read sorts alphabetically before the forward read. This can happen when the filename’s barcode ID is different between the forward and the reverse read:
# here the barcode IDs are `S01`, `S00`, and `S02` sample_a_S01_L001_R1_001.fastq.gz sample_a_S01_L001_R2_001.fastq.gz sample_b_S00_L001_R2_001.fastq.gz <== here R2 comes *before* R1 sample_b_S02_L001_R1_001.fastq.gz
There are a few ways this could occur:
- You imported using a manifest format and your rows didn’t exactly follow the pattern of forward, reverse, forward, reverse, etc (this is not a requirement of the format).
- You imported via a Casava format and your barcode IDs were nucleotides (or any identifier) in a non-alphabetical order. This might happen with certain barcode schemes or protocols.
We have implemented a fix for this issue which will be available this week as part of the QIIME 2 2018.6 release.
We apologize for any inconvenience this may have caused, and are happy to discuss further.
Special thanks to @jcmcnch for bringing this issue to our attention, and for providing a well documented issue report, complete with supporting data. It made troubleshooting this issue very straightforward. Thanks!