Dear QIIME2 team,
troubleshooting a big library we encountered a behaviour we think could be a bug in qiime cutadapt demux paired.
We are using QIIME2 version 2024.10 and this is the command that’s being run via snakemake
qiime cutadapt demux-paired \
--i-seqs {input.q2_import} \
--p-error-rate 0.17 \
--m-forward-barcodes-file {input.mapping_file} \
--m-reverse-barcodes-file {input.mapping_file} \
--m-forward-barcodes-column Forward_Barcode \
--m-reverse-barcodes-column Reverse_Barcode \
--o-per-sample-sequences {output.q2_demux_file} \
--p-mixed-orientation TRUE \
--p-forward-cut 2 \
--p-reverse-cut 2 \
--p-anchor-forward-barcode TRUE \
--p-anchor-reverse-barcode TRUE \
--p-batch-size 24 \
--p-cores {threads} \
--verbose \
--o-untrimmed-sequences {output.q2_demux_untrimmed}
The problematic part is the combination of ‘--p-forward-cut/--p-reverse-cut’ with ‘--p-batch-size’.
Our amplicons are designed with an AC spacer at the beginning of the reads, therefore we chose to use the ‘cut’ parameters. By examining the demux log file I noticed that when qiime invokes cutadapt it will work ok for the first round. The problem is that the first batch of cutadapt will trim the bases and pass the trimmed version of the reads to the second round of cutadapt where it will trim once again. In our case from the 3rd round of cutadapt it started reporting mostly 0 adaptor trimmings for all the samples.
I think the correct behaviour could be:
1st round: trim, pass trimmed version to 2nd round
2nd round: don’t trim, pass input to 3rd round
3rd round: don’t trim, pass input to next round
and so on
For us removing ‘--p-forward-cut’ and ‘--p-revese-cut’ fixes the issue.
Attached the log file.
Thanks!
Novogene_11Gb_v8_q2_demux.txt (100.8 KB)
