Answers.Body: <p>I've had great results using <a href="https://github.com/lh3/minimap2" rel="nofollow noreferrer">minimap2</a>, particularly when combined with a pre-treatment of Canu for error correction (using <em>minimap2</em> for the read-to-read mapping):</p>
  
  <pre><code># correct reads
  ~/install/canu/canu-1.6/Linux-amd64/bin/canu overlapper=minimap \
     genomeSize=100M minReadLength=100 minOverlapLength=30 -correct \
     -p 4T1_BC06 -d 4T1_BC06 \
     -nanopore-raw workspace/pass/barcode06/fastq_runid_*.fastq
  # align reads
  ~/install/minimap2/minimap2 -p 10 \
     -a ~/db/fasta/mmus/ucsc/mmus_ucsc_all_cdna.idx \
     -x splice &lt;(pv all/4T1_BC06/4T1_BC06.correctedReads.fasta.gz) | \
    samtools sort &gt; 4T1_BC06_all_vs_mmusAll.bam
  </code></pre>
  
  <p>Update: the most recent nanopore basecaller, combined with the most recent minimap2, seems to now do a decent job with mapping, and pre-correction of reads no longer seems necessary. More recently I've been using LAST to map to the transcriptome, and minimap2 to map to the genome. Minimap2 has the ability to use a homopolymer-compressed genome index, which means that the most common consistent error for nanopore reads (i.e. misjudgement of homopolymer length) will not influence the mapping rate.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-17T10:46:39.370Z
Answers.Text: Yep I also ended up using minimap2, thanks. At the time of this question, I was just trying to check if I was doing some nonsense with parameters for STAR, or if its behavior was simply due to its algorithm. For reads correction, aren't you afraid of altering the indel composition of your reads if you use Canu?
Answers.UserDisplayName: aechchiki
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-17T21:16:37.013Z
Answers.Text: No... why would that be a problem? Canu is correcting errors based on the consensus of overlapping reads; I don't see why/how that correction would cause more problems than it solves.
Answers.UserDisplayName: gringer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-01-17T05:00:30.263Z
Answers.LastActivityDate: 2019-02-22T22:54:39.600Z
Answers.LastEditDate: 2019-02-22T22:54:39.600Z
Answers.UserDisplayName: gringer
Body: <p>Are there any suggested parameters to align ONT reads to the reference genome using <a href="https://github.com/alexdobin/STAR/releases/tag/2.5.3a" rel="noreferrer">STAR-long</a>? For now, I used the parameters suggested <a href="https://github.com/PacificBiosciences/cDNA_primer/wiki/Bioinfx-study:-Optimizing-STAR-aligner-for-Iso-Seq-data#param" rel="noreferrer">here</a>, but I noticed a weird behaviour. </p>
  
  <p>I have RNA reads (<em>D. melanogaster</em>) from <code>R7</code> and <code>R9</code> flowcells, separately. I only selected to analyze <code>2D</code> reads in <code>pass</code> category. </p>
  
  <p>I have, respectively, 113249 reads for <code>R7</code> and 40318 reads for <code>R9</code>. I aligned those reads and get (only!) 150 uniquely mapped reads for <code>R7</code> data and 8017 uniquely mapped reads for <code>R9</code> data. I tried to run again the same command on a different server with fresh compilation, but the output file is consistent with these 150 reads. </p>
  
  <p>However, if I align the same with GMAP, I get 78016 uniquely mapped reads for <code>R7</code> and 33523 uniquely mapped reads for <code>R9</code>, so I suspect that something went wrong in the alignment run. </p>
  
  <p>I am aware that the two mappers behave very differently, STAR-long being  more precise and preferring to report mappings of fewer reads but at better loci, and GMAP being overall less precise, trying to map the most of the reads but at not-so-good loci. </p>
  
  <p>I was wondering if some of you had experience with this and could suggest me the best parameters for RNA reads from ONT?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-18T08:51:20.777Z
Comments.Text: I guess my reply would be more appropriate as a comment - but I can't. I'm not sure if that setting of SE makes sense, but whatever. This is not necessarily a solution for the behaviour you see, but I would suggest trying https://github.com/lh3/minimap2 for cDNA-seq alignment.
Comments.UserDisplayName: Wouter De Coster
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-17T15:48:32.327Z
Comments.Text: At my hand, STAR-long doesn't work well with noisy reads. It worked for iso-seq mostly because the error rate of iso-seq reads is much lower.
Comments.UserDisplayName: user172818
Tags: <nanopore><rna-alignment><star><gmap>
Title: STAR-long parameters for aligning RNA ONT reads to genome
ThreadText: # STAR-long parameters for aligning RNA ONT reads to genome
  
  (Asked by: username_0 on 2017-08-30)
  
  Are there any suggested parameters to align ONT reads to the reference genome using [STAR-long](https://github.com/alexdobin/STAR/releases/tag/2.5.3a)? For now, I used the parameters suggested [here](https://github.com/PacificBiosciences/cDNA_primer/wiki/Bioinfx-study:-Optimizing-STAR-aligner-for-Iso-Seq-data#param), but I noticed a weird behaviour.
  
  I have RNA reads (*D. melanogaster*) from `R7` and `R9` flowcells, separately. I only selected to analyze `2D` reads in `pass` category.
  
  I have, respectively, 113249 reads for `R7` and 40318 reads for `R9`. I aligned those reads and get (only!) 150 uniquely mapped reads for `R7` data and 8017 uniquely mapped reads for `R9` data. I tried to run again the same command on a different server with fresh compilation, but the output file is consistent with these 150 reads.
  
  However, if I align the same with GMAP, I get 78016 uniquely mapped reads for `R7` and 33523 uniquely mapped reads for `R9`, so I suspect that something went wrong in the alignment run.
  
  I am aware that the two mappers behave very differently, STAR-long being more precise and preferring to report mappings of fewer reads but at better loci, and GMAP being overall less precise, trying to map the most of the reads but at not-so-good loci.
  
  I was wondering if some of you had experience with this and could suggest me the best parameters for RNA reads from ONT?
  
  **Tags:** nanopore, rna-alignment, star, gmap
  
  > **Comments:**
  > **username_1**: I guess my reply would be more appropriate as a comment - but I can't. I'm not sure if that setting of SE makes sense, but whatever. This is not necessarily a solution for the behaviour you see, but I would suggest trying https://github.com/lh3/minimap2 for cDNA-seq alignment.  
  > **username_2**: At my hand, STAR-long doesn't work well with noisy reads. It worked for iso-seq mostly because the error rate of iso-seq reads is much lower.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2018-01-17. Score: 5 | Accepted answer
  
  I've had great results using [minimap2](https://github.com/lh3/minimap2), particularly when combined with a pre-treatment of Canu for error correction (using *minimap2* for the read-to-read mapping):
  
  ```
  # correct reads
  ~/install/canu/canu-1.6/Linux-amd64/bin/canu overlapper=minimap \
     genomeSize=100M minReadLength=100 minOverlapLength=30 -correct \
     -p 4T1_BC06 -d 4T1_BC06 \
     -nanopore-raw workspace/pass/barcode06/fastq_runid_*.fastq
  # align reads
  ~/install/minimap2/minimap2 -p 10 \
     -a ~/db/fasta/mmus/ucsc/mmus_ucsc_all_cdna.idx \
     -x splice <(pv all/4T1_BC06/4T1_BC06.correctedReads.fasta.gz) | \
    samtools sort > 4T1_BC06_all_vs_mmusAll.bam
  
  ```
  
  Update: the most recent nanopore basecaller, combined with the most recent minimap2, seems to now do a decent job with mapping, and pre-correction of reads no longer seems necessary. More recently I've been using LAST to map to the transcriptome, and minimap2 to map to the genome. Minimap2 has the ability to use a homopolymer-compressed genome index, which means that the most common consistent error for nanopore reads (i.e. misjudgement of homopolymer length) will not influence the mapping rate.
  
  > **Comments:**
  > **username_0**: Yep I also ended up using minimap2, thanks. At the time of this question, I was just trying to check if I was doing some nonsense with parameters for STAR, or if its behavior was simply due to its algorithm. For reads correction, aren't you afraid of altering the indel composition of your reads if you use Canu?  
  > **username_3**: No... why would that be a problem? Canu is correcting errors based on the consensus of overlapping reads; I don't see why/how that correction would cause more problems than it solves.  
  
  ---
  
  