text: user1771: I am trying to understand local realignment but I could not get a clear idea of what is the problem solved by it.
  For example, reading Homer and Nelson (2010):
  
  Because alignment algorithms map each read independently to the reference genome, alignment artifacts could result, such that SNPs, insertions, and deletions are improperly placed relative to their true location. This leads to local alignment errors due to a combination of sequencing error, equivalent positions of the variant being equally likely, and adjacent variants or nearby errors driving misalignment of the local sequence. These local misalignments lead to false positive variant detection, especially at apparent heterozygous positions. For example, insertions and deletions towards the ends of reads are difficult to anchor and resolve without the use of multiple reads. In some cases, strict quality and filtering thresholds are used to overcome the false detection of variants, at the cost of reducing power [13]. Since each read represents an independent observation of only one of two possible haplotypes (assuming a diploid genome), multiple read observations could significantly reduce false-positive detection of variants.
  
  I don't understand how the different artifacts (such as SNPs) can result from the alignment.
  
  Homer, Nils, and Stanley F. Nelson. "Improved variant discovery through local re-alignment of short-read next-generation sequencing data using SRMA." Genome biology 11.10 (2010): R99.
  
  
  user77: SNPs are likely to be created and InDels are likely to be missed. Suppose you have a read, ACTGACTGACTGTAC and you align it to a reference sequence ACTGACTGACTGTTAAGAACGACTACGAC. If you aligned that, you would either get:
  ACTGACTGACTGTac    (lower case denotes soft-clipping)
  ACTGACTGACTGTTAAGAACGACTACGAC
  
  or
  ACTGACTGACTGTAC    (N.B., you've created some possible SNPS)
  ACTGACTGACTGTTAAGAACGACTACGAC
  
  But what happens if you look at a bunch of reads? See below:
  ACTGACTGACTGTAC
    TGACTGACTGTACTA
      ACTGACTGTACTAAG
  ACTGACTGACTGT--TAAGAACGACTACGAC
  
  I've made the 2 base insertion obvious. As you can see, using many alignments, we can "realign" our original read to see that it actually ends in a 2 base insertion, something that's completely impossible to find with a single read. This realignment is part of what the GATK haplotype caller does (it makes a local de Bruijn graph). That's also what my MethIndelRealigner does. I have another real-world example in its documentation.
  Raw alignments in IGV:
  
  Alignments after realignment:
  
  One can find plenty of similar scenarios that result in SNPs rather than simply losing coverage for InDels.
  
original_text: 1771: <p>I am trying to understand local realignment but I could not get a clear idea of what is the problem solved by it.</p>
  
  <p>For example, reading Homer and Nelson (2010):</p>
  
  <blockquote>
    <p>Because alignment algorithms map each read independently to the reference genome, alignment artifacts could result, such that SNPs, insertions, and deletions are improperly placed relative to their true location. This leads to local alignment errors due to a combination of sequencing error, equivalent positions of the variant being equally likely, and adjacent variants or nearby errors driving misalignment of the local sequence. These local misalignments lead to false positive variant detection, especially at apparent heterozygous positions. For example, insertions and deletions towards the ends of reads are difficult to anchor and resolve without the use of multiple reads. In some cases, strict quality and filtering thresholds are used to overcome the false detection of variants, at the cost of reducing power [13]. Since each read represents an independent observation of only one of two possible haplotypes (assuming a diploid genome), multiple read observations could significantly reduce false-positive detection of variants.</p>
  </blockquote>
  
  <p>I don't understand how the different artifacts (such as SNPs) can result from the alignment.</p>
  
  <ul>
  <li>Homer, Nils, and Stanley F. Nelson. "<a href="https://genomebiology.biomedcentral.com/articles/10.1186/gb-2010-11-10-r99" rel="noreferrer">Improved variant discovery through local re-alignment of short-read next-generation sequencing data using SRMA.</a>" Genome biology 11.10 (2010): R99.</li>
  </ul>
   77: <p>SNPs are likely to be created and InDels are likely to be missed. Suppose you have a read, <code>ACTGACTGACTGTAC</code> and you align it to a reference sequence <code>ACTGACTGACTGTTAAGAACGACTACGAC</code>. If you aligned that, you would either get:</p>
  
  <pre><code>ACTGACTGACTGTac    (lower case denotes soft-clipping)
  ACTGACTGACTGTTAAGAACGACTACGAC
  </code></pre>
  
  <p>or</p>
  
  <pre><code>ACTGACTGACTGTAC    (N.B., you've created some possible SNPS)
  ACTGACTGACTGTTAAGAACGACTACGAC
  </code></pre>
  
  <p>But what happens if you look at a bunch of reads? See below:</p>
  
  <pre><code>ACTGACTGACTGTAC
    TGACTGACTGTACTA
      ACTGACTGTACTAAG
  ACTGACTGACTGT--TAAGAACGACTACGAC
  </code></pre>
  
  <p>I've made the 2 base insertion obvious. As you can see, using many alignments, we can "realign" our original read to see that it actually ends in a 2 base insertion, something that's completely impossible to find with a single read. This realignment is part of what the GATK haplotype caller does (it makes a local de Bruijn graph). That's also what my <a href="https://github.com/dpryan79/MethIndelRealigner" rel="noreferrer">MethIndelRealigner</a> does. I have another real-world example in its documentation.</p>
  
  <p>Raw alignments in IGV:</p>
  
  <p><img src="https://raw.githubusercontent.com/dpryan79/MethIndelRealigner/master/images/InDelExample.annotated.png" alt="Before realignment"></p>
  
  <p>Alignments after realignment:</p>
  
  <p><img src="https://raw.githubusercontent.com/dpryan79/MethIndelRealigner/master/images/RealignedExample.png" alt="After realignment"></p>
  
  <p>One can find plenty of similar scenarios that result in SNPs rather than simply losing coverage for InDels.</p>
  