I have this error when i try to run the command Qiime dada2 denoise-paired \ “mismatched forwward and reverse sequence files”
I have the demux.qza file but my sequences were imported by Casava 1.8 paired-end demultiplexed fastq format. I made the same analysis in R using dada2 and i had the same error, but in that situation i just added
matchIDs=TRUE argument to the
filterAndTrim function. I dont know how can i repair this error in qiime2, or if its possible, how to add the parameter “matchIDs=TRUE” in the command line of R that use qiime2.
mismatched forwward and reverse sequence files (sequences imported by Casava 1.8 paired-end demultiplexed fastq format)
Welcome to the Qiime 2 forums!
I think you have identified the issue: Qiime generally expects paired reads to be in the same order.
We have two options here
- Have the devs expose the
matchIDsoption as a new flag in the dada2 plugin
- Reorder your reads using another program, then import them into qiime 2.
I think 1 is a good long-term solution, but until we make this fix, you could fix your reads using something like the bbtools repair.sh script
Let me know what you find!
Hi Colin, thanks for answering
I just accessed to this path “home/bradd/miniconda3/envs/qiime2-2019.4/bin/” and modified the document “run_dada_paired.R”. I added the parameter “matchIDs=TRUE” to the command line and saved the document. Now qiime2 has succeed with the analysis. Do you think that is a good solution? thank you for your help.
I’m glad that worked! That’s a clever way to update the script so it works for your data.
I’m worried that it’s too clever!
(Your version of qiime now has a superpower that most versions of qiime lack. This means what works for you will not work for everyone else. )
The even better solution would be to have an option to use
matchIDs in the dada2 plugin that way everyone can have your superpower.
So I opened an issue: https://github.com/qiime2/q2-dada2/issues/118
I agree with @colinbrislawn that this has the theoretical potential to cause issues in the future if you were to look at provenance. Fortunately! Our development repos are actually relatively clever (as is provenance), so a reasonable thing to do, if you absolutely must make this change, would be to clone the repo:
git clone https://github.com/qiime2/q2-dada2.git cd q2-dada2
Then checkout the release as a branch:
git checkout -b dada2-matchIDs 2019.4.0
Then make your edit to
run_dada_paired.R and commit it (git may complain about not having a user set, go ahead and follow its instructions, there will be 2 commands in that case):
git commit -am "Changed matchIDs"
Finally, activate your environment (and really a second environment named accordingly might be wise) and then run the following in the root of your
This will have the effect of overwriting the current build of q2-dada2 with the repository. When that happens, versioneer will identify the last git tag and commit, and generate a new version for this code-base (the version should look something like
2019.4.0+1.g<your commit sha> which will show up in provenance from there on, allowing you to identify that this q2-dada2 is unlike the normal release (being one commit ahead) and you have some chance of identifying what changed precisely if you still have the repo as the commit sha is also in the version for reference.
For anyone else watching, I’m really not advocating for this approach, but this is the least bad and most trackable way to make these kinds of changes.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.