Hi There,
I inserted all my barcodes myself into the fastq files -- they should have matched 100% -- but they did not. Based upon a previous thread regarding the processAmplicons runtime when you allow for mismatches, I turned mismatching basically off just so I could see a return. I have 2 paired reads that were run on a MiSEQ
-- Number of Barcodes : 24
-- Number of Hairpins : 213141
Processing reads in /trimmed_fastq/dalal/fastq/Challenge18_S13_L001_R1_001.bc.fastq and /trimmed_fastq/dalal/fastq/Challenge18_S13_L001_R2_001.bc.fastq\
.
-- Processing 10 million reads
Number of reads in file /trimmed_fastq/dalal/fastq/Challenge18_S13_L001_R1_001.bc.fastq and /trimmed_fastq/dalal/fastq/Challenge18_S13_L001_R2_001.bc.f\
astq: 272472
The input run parameters are:
-- Barcode: start position 1 end position 8 length 8
-- Barcode in reverse read: start position 1 end position 8 length 8
-- Hairpin: start position 1 end position 27 length 27
-- Hairpin sequences need to match at specified positions.
-- Mismatch in barcode/hairpin sequences not allowed.
Total number of read is 272472
There are 157149 reads (57.6753 percent) with barcode matches
There are 17 reads (0.0062 percent) with hairpin matches
There are 0 reads (0.0000 percent) with both barcode and hairpin matches
I don't understand how I would have only 57% barcode matches and I don't understand why I don't have both hairpin and barcode matches (I know that I do -- I created them).
Thoughts?
> sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 13.04
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] edgeR_3.10.5 limma_3.24.15
You should use more general tags, e.g.,
edgeR
andprocessAmplicons
separately. Otherwise, there's no guarantee that the package developers will see this.