Mixed orientation data

[thermokarst]

Hi @c.older, thanks for this info!

What I am having a hard time following is the business about sample labels / orientations being swapped.

@c.older

However, it looks like it’s actually the sequences in the files that I would’ve thought were the reverse reads (file names like “SAMPLE1_2”; what I thought were forward reads were “SAMPLE1_1”) are actually the forward reads… so that’s interesting. But when I look at my demux summary, it looks like qiime2 was able to figure out which ones were forward and reverse, since I would expect the quality on the reverse to fall off earlier

Since you used a manifest format QIIME 2 doesn't need to "figure out" the direction --- it uses the direction you specified in your manifest! At first glance, I think if there are issues with fwd/rev files being swapped, I would triple-check the manifest to make sure there aren't any mistakes there.

@c.older

I’m thinking my issue was at this step, because when I pull a sequence from the q-score output and align it to the raw “forward” and “reverse” reads, it aligns to the “forward” (incorrect) read.

The reason it aligns to the forward read here is because this method only operates on single-end reads. That means that if you pass in paired-end reads, the reverse reads will be discarded.

@c.older

Instead of using the sequences that are actually forward reads but not labelled accordingly in the file names (e.g. “SAMPLE_2”), it used the sequences labelled as forward (e.g. “SAMPLE_1”) but that are actually reverse sequences

In your example are SAMPLE_1 and SAMPLE_2 one sample (fwd and rev) or two samples (one direction)?

@c.older

but that are actually reverse sequences

Can you provide an example of this that illustrates the issue?

---

I am wondering if you are running into another variation of the bug reported here:

Incorrect results produced by q2-cutadapt's trim-paired

Summary We recently discovered a bug related to the q2-cutadapt plugin’s 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). Impact This issue impacts the following versions of q2-cutadapt: 2017.12 2018.2 2018.4 If you think you may have been impacted please check your provenance at h…

but, I need a bit more information to be sure (requested above). In the meantime, can you share some manifest or demux seqs in the DM you opened up with me? Thanks!