Using Paired-End, Demultiplexed Data

Hello,

Going through the Moving Pictures tutorial, I see that there’s a step for demultiplexing data prior to using DADA2. In the forums, I saw that there were different types of data that were not compatible with QIIME2 yet (?), so I just wanted to ask if the files I’m working with are.

I’m also a little confused with the transition into QIIME2. So normally, I would check the raw data files quality plots with FastQC. Afterwards, I would trim the data to remove sequences with a phred score lower than 20 and any other sequences (like adapter sequences). Then, I would combine the pairs of read files using FLASH into one fastqc file. After that, I can proceed with other cleaning steps, OTU picking, etc. However, in the tutorial I didn’t see anything mentioning trimming depending on phred scores or handling files that aren’t merged?

Since there are the required trimming parameters, which were accessed using qiime demux summarize \, am I able to use this function with my files or should I estimate the parameters using the QC plots from FastQC?

Thanks for the help!

Here is a snippet of one the read files (there’s an R1 and R2):
@M02288:30:000000000-B9N34:1:1101:10562:3248 1:N:0:450
CTTGGTCATTTAGAGGAAGTAAAAGTCGTAACAAGGTCTCCGTAGGTGAACCTGCGGAGGGATCATTACAAGTACACTACCGGCCTAACCCGCCGGCTATGTATAACCCTTTGTTGTCCGACTCTGTTGCCTCCGGGGCGACCCTGCCTTCGGGCGGGGGCCCCGGGTGGCCACTTCAAACTCTTGCGTAACTTTGCAGTCTGAGTAAATTTAATTCATAAATTAAAACTTTCAACAACGGATCTCTTGG
+
AABBBFFFFFFFG4EFFEAGGGHHGHHGGHGGHGGHHHHHHGHHGGHGHFHEGHHGFFGG?EHGHHHHHHHHHEHHHHBGHGCFGGBFHHGGGGGGGGGHGHFF?FGHHHHHFGGGHHHGDGGGHHFFGHHHHHGG?DGGGGGGGHHEHHHH.AFDGFF-B;DFFAAFFF.9BAFFFFF/BFFFFFFFF?..BFFEFFFFFFF9FFB/9BFFF/;B/;FB/9;BBF/9FFFFBB/;/[email protected]:[email protected]
@M02288:30:000000000-B9N34:1:1101:14129:10229 1:N:0:450
GTTTGATCATGGCTCAGAATGAACGCTGGCGGCGTGCTTAACACATGCAAGTCGAGCGGAGAAGCCGCTCTCGCTCTTTGGATCACGGTCGTACGGGTGAGTAACCCGTCAGCAACGTGCCCCTGACTCTGGGATACTCGCTTGAAACAGAGCCTATTGCAACATATGATCTGACCGCGCATGGCCTACAGTTGGAAAGGTTTTTCGGTCTGGGATGGGGTCACGGGCTATCAGCTTGTTGGTGAGGCTA
+
AAAAAFFF3DDCGFGFG11BBFEGGEF0EE?0EEAFE/DFFGBFHHFFHBFGGG//?EE/>>0010/>///1?>?GC1F1<<1100//?<</</</>>//<11111<<///?11<0-><<.0>…C/0<DD0<<//000;-…;.000///:/;/90900000./00;000;000/-;9-9–;-B//;BB;////;/–9;/9-/–;A-/9-99-------9—9;-B/////9FAFF—/;A-9;
@M02288:30:000000000-B9N34:1:1101:22057:12668 1:N:0:450
GTGCCAGCCGCCGCGGTAATACGGAGGGGGCAAGCGTTATTCGGATTTACTGGGCGTAAAGCGCACGCAGGCGGTCTTTTAAGTCTGATGTGAAATCCCTGGGCTCAACCCGGGAACTGCATTCGAAACTGGCAGACTAGAGTCCTGAAGAGGGGAGTAGAATTCCATGTGTAGCGGTGAAATGCGTAGATATCTGGAGGAACACCAGTGGCGAAGGCGGCTCTCTGGTCTGGGACTGACGCTGAGGTGC
+
AAABAFFB3ADBGGGGEEGGGGHEEGG0AEEEGGHGGG?15FGHDAFHHBGFHHHGGGGHHHGF?EG?EGGGGGCDG2F>FGHHH2?GFHHHHHHFHH111?FHHHHGHH.–ADCCGHH0GH0<GCFDHHH.CD.;F0;BFGBF0F;;FFGG.-.:C/CFF0FFFB/;FFFFFBFFFFFFFFBFBFFFF//F/9B:B?DFB9FFF9FFFFEAAF;DF;DFB./;FBF/B///.;:A?FFFFF.AFE/.9
@M02288:30:000000000-B9N34:1:1101:4266:15289 1:N:0:450
GTGTCAGCAGCCGCGGTAATACGGAGGGTGCGAGCGTTAATCGGAATGACTGGGCGTAAAGGGCATGTAGGCGGATAATTAAGTTAGGTGTGAAAGCCCTGGGCTCAACCTAGGAATTGCCCTTAAAACTGGTTAACTAGAGTATTGTAGAGGAAGGTAGAATTCCACGTGTAGCGGTGAAATTCGTAGAGATGTGGAGGAATACCGGTGGCGAAGGCGGCCTTCTGGACAGATACTGACGCTGAGATGC
+
AAA3>DFFFFFBGGGGGGFGGGD?E2EF2CEE1AEGGG11DGEGDGFFEGEBGHHEGCDHHBEEFFHHHFHHGG/EEHF4FHHHHFFH?DG?GHG2FGHGGFGHHGFHHHCHHHFHFHHH1?FCGHDHGFHB11D<FHHHHHG1DD0DD0<=C./CDC0<GCGF0C0CEGGHHFFC-CDFG0C0CEGGEGFBFF000;[email protected][email protected]/BF///99A/9FFFFBF.AAD.A/9B/
@M02288:30:000000000-B9N34:1:1101:11123:27479 1:N:0:450
GTTTGATCCTGGCTCAGAGTGAACGCTGGCGGCGTGCTTAACACATGCAAGTCGAACGAGAACGGGTTATAGTTTACTATAACTGTCAGCTAAGTGGCGCACGGGTGAGTAATATATAGGTAACGTGCCCTAGAGAGGGGGATAACATTTGGAAACGAATGCTAATACCCCATATGCCTCTAAGTCTTAAGACTGCAAGGGAAATATTTATAGCTCTAGGATCGGCCTGTACGGTATCAGTTTGTTGGTG
+
[email protected]EE/[email protected]?BEFGEEECCG/B?CF212>@2DFGF1>1?<<</?GFCGHHHG…CGCFFF0<0<0;C/:CCEA.C:;C0<;C009…/90F00B099;00CFF;;BF00;/00BEFEC9/BFFFFFFFB//////BFBAD-.AEFB/;9;AEBFB99/B.;FE?.

Paired file after trimming sequences:
@M02288:30:000000000-B9N34:1:1101:10562:3248 1:N:0:450
CTTGGTCATTTAGAGGAAGTAAAAGTCGTAACAAGGTCTCCGTAGGTGAACCTGCGGAGGGATCATTACAAGTACACTACCGGCCTAACCCGCCGGCTATGTATAACCCTTTGTTGTCCGACTCTGTTGCCTCCGGGGCGACCCTGCCTTCGGGCGGGGGCCCCGGGTGGACACTTCAAACTCTTGCGTAACTTTGCAGTCTGAGTAAATTTAATTAATAAATTAAAACTTTCAACAACGGATCTCTTGGTTCTGGCATCGATGAAGAACGCAGC
+
AABBBFFFFFFFG4EFFEAGGGHHGHHGGHGGHGGHHHHHHGHHGGHGHFHEGHHGFFGG?FHGHHHHHHHHHEH<HH6GHGCFGGBFHHGGGGGGGGGHGHFF?FGHHHH0FGGG<HHGDGHGHHFFGHHHHHGGADGGGGGGGHHEHHHHCAFEGFFEB;EFFCEGFF3GBAFFFHHGGFFFFFFHFGF?BFHGHHHGFHHFFGFGABHHHGAB9HHFED;HHGHGFG&[email protected]?3
@M02288:30:000000000-B9N34:1:1101:22057:12668 1:N:0:450
GTGCCAGCCGCCGCGGTAATACGGAGGGGGCAAGCGTTATTCGGATTTACTGGGCGTAAAGCGCACGCAGGCGGTCTTTTAAGTCTGATGTGAAATCCCTGGGCTCAACCGAGGAACTGCATTCGAAACTGGGAGTCTAGAGTCCGGAAGAGGGGAGTGGAATTCCATGTGTAGCGGTGAAATGCGTAGATATCTGGAGGAACACCAGTGGCGAAGGCGGCTCCCTGGTCAGAGACTGACGCTGAGGTGCGAAAGCGTGGGGAGCAAACAGGATTAGATACCCGTGTAGTCC
+
AAABAFFB3ADBGGGGEEGGGGHEEGG0AEEEGGHGGG?15FGHD3FHHBGFHHHGGGGHHHGF?EG2FGGGGGCDG$F>FGHHH$?GFHHHHHHFHH1$1HHHHHHGHH#$HHDCCHHHGGH0HGDGGHHH$FD$BF1HDFG4F#F;FGGGG0<BGD#HFGDHGFB1HGGFGF2HHHHHFFFBFHHHHHBGF3CHHG?HFG9HGF9GGGGHHGGGGGGEFB?#HHHGEF4D’5HGGGGGGHHFHGEE2GHGGGGE?HGGG5FFGBHHHHGGGGGGGF2GBBACFFFBBBBB
@M02288:30:000000000-B9N34:1:1101:4266:15289 1:N:0:450
GTGTCAGCAGCCGCGGTAATACGGAGGGTGCGAGCGTTAATCGGAATGACTGGGCGTAAAGGGCATGTAGGCGGATAATTAAGTTAGGTGTGAAAGCCCTGGGCTCAACCTAGGAATTGCACTTAAAACTGGTTAACTAGAGTATTGTAGAGGAGGGTAGAATTCCACGTGTAGCGGTGAAATTCGTAGAGATGTGGAGGAATACCGGTGGCGAAGGCGGCCTTCTGGACAGATACTGACGCTGAGATGCGAAAGCGTGGGGAGCAAACAGGATTAGATACCCCGGTAGTCC
+
AAA3>DFFFFFBGGGGGGFGGGD?E2EF2CEE1AEGGG11DGEGDGFFEGEBGHHEGFDHHBEEFFHHHFHHGG/EEH79FHHHHFFHFFGBGHGCFGHGGGGHHGFHHHCHHHFHFHHH3?FCHHGHGHHB#<DC1#CFC1HHHGF<C#CEGGHHFFHHGHHGCC#FFGGGGFBFF0F>;AFEFBBEFAGFGEFGFFGFAG?GB01FFFDB99HGHHFGFGGHHHHHE/FECHFACGGGHGFGHHHFHHFFHGGG1BGGGEE>111FFFAAA?>
@M02288:30:000000000-B9N34:1:1102:18795:4122 1:N:0:450
GTGTCAGCCGCCGCGGTAATACGAAGGGGGCTAGCGTTGCTCGGATTTACTGGGCGTAAAGCGCACGTAGGCGGATTTTTAAGTCCGAGGTGAAATCCTGGGGCTCAACCCCAGAAGTGCCTTTGATACTGGGAATCTTGAGTCTGGTAGAGGTTGGTGGAACTCCGAGTGTAGAGGTGAAATTCGTAGATATTCGGAAGAACACCAGTGGCGAAGGCGGCTAACTGGTCCATCACTGACGCTGAGGCGCGAAAGCGTGGGGAGCAAACAGGATTAGATACCCGAGTAGTCC
+
[email protected]@FFCE14%BFFGCGGGGGFGFFGG#>FBFFGFEF-0#?FHGHFHH%?#F>FGGAF%<F%<0GCCGGHHHH#E6HGG00<;CGF>GGGGFGGG?1$)GHFGGF?#HGF#HHG/?9##GFGGFF/FBFGHFFHFGFBGHGFFHGGEGHHHFFFGFFFB%A2HFGFFGF:[email protected]@BBGF1GDD2(HGGGFFGGHHFEA3CAF/[email protected]?AFDBF1A>AA

Hi @ninaxhua! Have you had a chance to review the Getting Started Guide? This has recommendations for reviewing the QIIME 2 documentation in a structured manner, that way you can get up to speed quickly! Many of the common workflows in QIIME 2 are a bit different than in QIIME 1, given the nature of changes in the field (for example, ASVs vs OTUs). I would recommend spending some time working through the tutorials and reading up on some of the methods and tools wrapped in QIIME 2 (e.g. dada2, deblur, vsearch), to wrap your head around things.

With that said, you could import your paired-end demultiplexed data using an appropriate import format, and begin to experiment with QIIME 2!

Please let us know if you have any questions or get stuck. Thanks! :t_rex:

1 Like

Thanks for getting back to me! The guide definitely helped. I see that there is the cutadapt plug in, which is what I need because I ran the raw read pairs in FastQC and my plots showed Nextera Transpose Adapter content in the Adapter content tab. I have ran these read pairs in QIIME1 and used TrimGalore to remove the Nextera content. I wanted to confirm that in order to do the same here, I would run this

qiime cutadapt trim-paired
–i-demultiplexed-sequences CC-demux-paired-end.qza
–p-front-f TCGTCGGCAGCGTCAGATGTGTATAAGAGACAG
–p-front-r GTCTCGTGGGCTCGGAGATGTGTATAAGAGACAG \
–p-error-rate 0
–o-trimmed-sequences CC-trimmed-demux-seqs.qza
–output-dir \
–verbose

What I’ve found on the web for the Nextera Transposase sequence is different from the most recent documentation, but can you confirm that the above would be correct to remove the sequence?

Hi @ninaxhua - I can’t confirm the discrepancies you have seen regarding Nextera adapters, but, the command you posted above does look like a sane q2-cutadapt command for stripping adapter from the 5’ end of both the forward and reverse reads, with no allowed errors in the adapter matching processing — this looks good to me. Give it a shot and let us know how it goes, and if you have any additional questions, feel free to open new topics! :t_rex:

Hello Matthew,

The command ran without error. I've attached the output message below. It doesn'tDADA2_Stdout.txt (3.4 KB)
look worrisome to me?

Hi @ninaxhua, everything looks okay with respect to your attached log (to me, that is), but that is just one small piece of the analysis puzzle. Is there something in particular that is worrying you?

There are a lot of reads being removed as chimeric. Are all non-biological sequences already removed (primers, barcodes, etc)? If there are any around, they will cause the read to look chimeric.

1 Like

I’ve used Cutadapt to remove the nextera transposase adapter sequence. Should I use FastQC to visualize the QC plots?

Hi @ninaxhua,

It’s probably a good idea to view quality plots one way or another before proceeding (e.g., to choose trimming parameters with dada2 or whatever denoising/clustering method you prefer).

If you have used q2-cutadapt and your data are thus in a SampleData[PairedEndSequencesWithQuality] artifact, you can use demux summarize to view quality plots before proceeding.

Naturally, if you prefer the output provided by FastQC, you can export your data to view with FastQC.

I hope that helps!

I did view the summary and used 240 as my truncating measure for --p-trunc-len-f and --p-trunc-len-r (following this tutorial: DADA2 Pipeline Tutorial (1.16)). It looks like most of the reads are fine, but following the tutorial, I truncated the last 10 nucleotides.

Command:
qiime dada2 denoise-paired
--i-demultiplexed-seqs $Q2P/CC-demux-paired-end.qza
--p-trunc-len-f 240
--p-trunc-len-r 240
--o-table $Q2P/CC-table-dada2.qza
--o-representative-sequences $Q2P/CC-rep-seqs-dada2.qza
--verbose | tee $Q2P/DADA2_Stdout.txt

I’ve attached the visualization artifact.

V_CC-trimmed-demux-seqs.qzv (283.4 KB)

As for primers, I’m not so sure if they were removed. Looking through the plots again, the quality does dip at the beginning. This was project used the Bacterial 16S v4 primers:

Hyb515F_rRNA: 5’-TCGTCGGCAGCGTCAGATGTGTATAAGAGACAGGTGYCAGCMGCCGCGGTA -3’
Hyb806R_rRNA: 3’-TAATCTWTGGGVHCATCAGGGACAGAGAATATGTGTAGAGGCTCGGGTGCTCTG-5’

Following this post, I should set trim-left-f to 50 and trim-left-r to 54?

Hi @ninaxhua,
The quality in those plots looks great. You should be safe with the trimming settings you’ve used. The reverse read is just a little bit worse (this often happens) but quality is still quite good — though you could trim to 200 on the reverse if this concerns you.

The full “primer” sequences you’ve shared most likely also contain linker and Illumina adapter sequences, which would not be sequenced. The actual DNA-binding section (PCR and most likely also sequencing primer) sequences are:

515F 5’-GTGCCAGCMGCCGCGGTAA
806R 5’-GGACTACHVHHHTWTCTAAT

So those are the sequences that you should use for any primer trimming. The adapters would not appear in the sequence unless if you have very long read lengths and the sequencer reads all the way through the reverse primer. That scenario happens for fungal ITS, but not for V4 16S rRNA sequences on current Illumina read lengths.

No. The adapter section of the primer should not be in the read. Depending on the sequencing protocol that you use, the primer may or may not be present (e.g., for EMP protocol the primer is used as sequencing primer and is not included in the reads). If you use cutadapt to trim primers, the trimming left should not be necessary — but certainly not 50 nt. Left trimming is a convenient way to trim primers if you know for a fact that primers are still contained at the 5’ ends of your reads, in which case there is no need to use q2-cutadapt (that’s much more useful if, e.g., reverse primers are contained somewhere in the reads and length is variable so you don’t know exactly where they are in the reads).

I hope that helps!

1 Like

Hi @Nicholas_Bokulich,

In an earlier post, Evan commented that a lot of reads were removed as chimeric (as seen in the DADA2_Stdout.txt), which could have been caused by primers and barcodes. The sequencing center only performs demultiplexing, but does not remove adapter content. If I used cutadapt to remove the Nextera Transposase sequence, then would I have also removed the barcodes and primers? Or would I need to trim the primer sequences that you defined earlier?

Yes, trim at the primer sequences.

Let us know if that fixes things!

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.