Read fragments receive maximum MAPQ in bowtie2
Hi everyone,
I am performing WES analysis using bowtie2. Actually I am trying to find out whether specific sequences are present in patients genome. I work with paired-end sequencing, the length of read is 100. I see that sometimes there are cases when read fragment (e.g. length of 19, CIGAR 19M) get maximum MAPQ (42) in my alignment. What happened to the remaining part of read? I did not set --local mode, I only specify input and output files. How is this possible? Is there a possibility to avoid such cases using bowtie2 parameters? I am afraid that these reads do not really reflect the presence of my sequences in the genome.
Thank you in advance!
0 answers
No answers yet.
Log in to answer this question.
More posts like this
-
question regarding sequencing alignment
written by Lin •
-
bowtie2 MAPQ scores more than 42
written by rakusmaximus •
-
no unique mapped paired-end reads in BAM file
written by Ric
-
Flagstat vs stats Samtools
written by v.shapovalova1 •
-
ambiguous characters are not reported in Bowtie2 alignments
written by Famf •
-
Find reads that completely cover short sequences
written by valerie
-
Bowtie2 - How can MAPQ be used to obtain uniquely mapped reads?
written by ej
-
bwa mem has more MAPQ values as 0 and 60
written by John
-
Identification of short insertions in genome
written by valerie
-
Bowtie indexing of a fasta file that consists of a large amount of sequences
written by valerie
What settings did you use? What you're describing shouldn't happen with the default settings.
Here is my script: bowtie2 -x junctions.index -p 8 -1 filename_end1.fastq -2 filename_end2.fastq -S output.sam
Most of the lines in my output.sam look fine, but some of them look like this:
Some of my sequences I am looking for are rather short and I am not expecting the second read in a pair to map the same sequence. Can this issue occur because I am treating paired-end sequencing like this?
the alignment that you list above is not a fragment, it is a full read match note
19Mnothing was clipped off.You have a mismatch in that
19Mbut that's about it.Does this mean that the original read is the length of 19? Is this possible? I was also wrong in the beggining, I am working with WES, not WGS, maybe this is essential
Your data must have been trimmed.