Read fragments receive maximum MAPQ in bowtie2

Question

[valerie]

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!

[Devon Ryan]

What settings did you use? What you're describing shouldn't happen with the default settings.

[valerie]

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:

D0N36ACXX120228:6:2308:12735:200681 137 sequenceXXX 79  42  19M =   79  0   TGCTGGAGTTGGTGGGATT ,5*4?<+;5:?>=?B#### AS:i:-2 XN:i:0  XM:i:1  XO:i:0  XG:i:0  NM:i:1  MD:Z:2G16   YT:Z:UP

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?

[Istvan Albert]

the alignment that you list above is not a fragment, it is a full read match note 19M nothing was clipped off.

You have a mismatch in that 19M but that's about it.

[valerie]

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

[Devon Ryan]

Your data must have been trimmed.