Answers.Body: <p>GATK best practices are explicably meant to consume BWA MEM generated BAM.  Whilst SNAP may be faster, the Broad will not have tested it for compatibility with GATK as such you can't guaranty using it won't have unexpected consequences.  </p>
  
  <p>As such you'd be better off using BWA MEM because I assume accurately called variation is always better than fast and incorrectly called variation.  The main issue you'll have is ensuring shorter split hits and mapping quality are reported in the same way as <code>bwa MEM -M</code> which GATK/Picard is expecting.  Ultimately however you'd be better off posting this question on the <a href="http://gatkforums.broadinstitute.org/gatk" rel="nofollow noreferrer">GATK forum</a>. </p>
  
  <p>It's also worth noting that the soon to be released GATK 4 will utilise bwaspark which can distribute it's alignment processes across Apache Spark for increase performance.  Consequently I can't see SNAP being adopted anytime soon.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-03T13:07:50.953Z
Answers.LastActivityDate: 2017-06-04T00:35:38.640Z
Answers.LastEditDate: 2017-06-04T00:35:38.640Z
Answers.UserDisplayName: Matt Bashton
Body: <p>I am calling SNPs from WGS samples produced at my lab. I am currently using bwa-mem for mapping Illumina reads as it is recommended by GATK best practice. However, bwa is a bit slow. I heard from my colleague that <a href="https://github.com/amplab/snap" rel="noreferrer">SNAP</a> is much faster than bwa. I tried it on a small set of reads and it is indeed faster. However, I am not sure how it works with downstream SNP callers, so here are my questions: have you used SNAP for short-read mapping? What is your experience? Does SNAP work well with SNP callers like GATK and freebayes? Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-03T13:52:24.023Z
Comments.Text: If you have the option of using a paid solution, I would strongly urge you to try [Sentieon's](http://www.sentieon.com/) implementation of the bwa algorithm. I've been using it for a few months and it is several *times* faster than vanilla bwa.
Comments.UserDisplayName: terdon
Tags: <bwa>
Title: Do you use SNAP for short-read mapping?
ThreadText: # Do you use SNAP for short-read mapping?
  
  (Asked by: username_0 on 2017-06-03)
  
  I am calling SNPs from WGS samples produced at my lab. I am currently using bwa-mem for mapping Illumina reads as it is recommended by GATK best practice. However, bwa is a bit slow. I heard from my colleague that [SNAP](https://github.com/amplab/snap) is much faster than bwa. I tried it on a small set of reads and it is indeed faster. However, I am not sure how it works with downstream SNP callers, so here are my questions: have you used SNAP for short-read mapping? What is your experience? Does SNAP work well with SNP callers like GATK and freebayes? Thanks!
  
  **Tags:** bwa
  
  > **Comments:**
  > **username_1**: If you have the option of using a paid solution, I would strongly urge you to try [Sentieon's](http://www.sentieon.com/) implementation of the bwa algorithm. I've been using it for a few months and it is several *times* faster than vanilla bwa.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-06-03. Score: 5 | Accepted answer
  
  GATK best practices are explicably meant to consume BWA MEM generated BAM. Whilst SNAP may be faster, the Broad will not have tested it for compatibility with GATK as such you can't guaranty using it won't have unexpected consequences.
  
  As such you'd be better off using BWA MEM because I assume accurately called variation is always better than fast and incorrectly called variation. The main issue you'll have is ensuring shorter split hits and mapping quality are reported in the same way as `bwa MEM -M` which GATK/Picard is expecting. Ultimately however you'd be better off posting this question on the [GATK forum](http://gatkforums.broadinstitute.org/gatk).
  
  It's also worth noting that the soon to be released GATK 4 will utilise bwaspark which can distribute it's alignment processes across Apache Spark for increase performance. Consequently I can't see SNAP being adopted anytime soon.
  
  
  ---
  
  