Answers.Body: <p>As per the SAM/BAM format specifications:</p>
  
  <blockquote>
    <p>"RNAME: Reference sequence NAME of the alignment. If @SQheader lines are present, RNAME(if not ‘*’) must be present in one of the SQ-SN tag. <strong>An unmapped segment without coordinate has a ‘*’ at this field.</strong>  However, an unmapped segment may also have an ordinary coordinate such that it can be placed at a desired position after sorting.  If RNAME is ‘*’, no assumptions can be made about POS and CIGAR." -- <a href="http://samtools.github.io/hts-specs/SAMv1.pdf" rel="nofollow noreferrer">http://samtools.github.io/hts-specs/SAMv1.pdf</a>, emphasis mine</p>
  </blockquote>
  
  <p>So, yes, these are the unmapped reads. </p>
  
  <p>I haven't used this <code>splitChromosome</code> utility before myself, but as it splits the BAM file into one BAM file per chromosome, I suspect it simply also creates a BAM file for the unknown (<code>*</code>) chromosome. Why the numbers don't match I can't tell.</p>
  
  <p>How to deal with that file in your pipeline will depend on what the pipeline is meant to do. But if you aren't interested in these reads, I suppose you could simply remove it before continuing to the next step.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-30T14:17:17.090Z
Answers.Text: Nice ! I'll maybe ask directly on bamUtil's github for my second question.
Answers.UserDisplayName: Paul Endymion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-30T14:07:22.740Z
Answers.LastActivityDate: 2020-01-30T14:58:36.630Z
Answers.LastEditDate: 2020-01-30T14:58:36.630Z
Answers.UserDisplayName: DavyCats
Body: <p>I have been working with several tools on bam files recently and I am not sure how I should interpret some of the outputs.</p>
  
  <pre><code>samtools idxstats mapped.sorted.bam
  </code></pre>
  
  <pre><code>Chr1    15096   0   0
  Chr2    33397   0   0
  Chr3    43888   41  0
  Chr4    20819   1   0
  *   0   0   34
  </code></pre>
  
  <p>Documentation says third and fourth column give "mapped reads" and "unmapped reads". So I interpreted the last line (<code>*</code>) as the number of unmapped reads as this is the only line with a non 0 value at this field.</p>
  
  <p>Then I used </p>
  
  <pre><code>bam splitChromosome --in mapped.sorted.bam --out test/aln.
  </code></pre>
  
  <pre><code>Reference Name: chr6 has 6 records
  Reference Name: Chr7 has 1 records
  Reference Name: Chr3 has 41 records
  Reference Name: Chr4 has 1 records
  Reference Name: * has 34 records
  </code></pre>
  
  <p>And looking at the bams outputted (one per reference sequence) in <code>test/</code> I find an <code>aln.UnknownChrom.bam</code> that I am not sure where it comes from. I actually found 97 unique reads ID in it, where I was waiting for 34 or less. </p>
  
  <p>So my <strong>first question</strong> is : Does "*" actually means "all reads that didn't mapp" and this information is stored in way I didn't know about in BAM files ?</p>
  
  <p>And my <strong>second question</strong> would be : Anybody knows where this <code>aln.UnknownChrom.bam</code> comes from when using <code>splitChromosome</code> ? It is a source of error in a pipeline I am building and I'd like to get rid of it, if these are not actual mapping informations.</p>
  
Tags: <sam><samtools>
Title: samtools / bamUtil | Meaning of <wildcard> as Reference Name
ThreadText: # samtools / bamUtil | Meaning of <wildcard> as Reference Name
  
  (Asked by: username_0 on 2020-01-30)
  
  I have been working with several tools on bam files recently and I am not sure how I should interpret some of the outputs.
  
  ```
  samtools idxstats mapped.sorted.bam
  
  ```
  
  ```
  Chr1    15096   0   0
  Chr2    33397   0   0
  Chr3    43888   41  0
  Chr4    20819   1   0
  *   0   0   34
  
  ```
  
  Documentation says third and fourth column give "mapped reads" and "unmapped reads". So I interpreted the last line (`*`) as the number of unmapped reads as this is the only line with a non 0 value at this field.
  
  Then I used
  
  ```
  bam splitChromosome --in mapped.sorted.bam --out test/aln.
  
  ```
  
  ```
  Reference Name: chr6 has 6 records
  Reference Name: Chr7 has 1 records
  Reference Name: Chr3 has 41 records
  Reference Name: Chr4 has 1 records
  Reference Name: * has 34 records
  
  ```
  
  And looking at the bams outputted (one per reference sequence) in `test/` I find an `aln.UnknownChrom.bam` that I am not sure where it comes from. I actually found 97 unique reads ID in it, where I was waiting for 34 or less.
  
  So my **first question** is : Does "\*" actually means "all reads that didn't mapp" and this information is stored in way I didn't know about in BAM files ?
  
  And my **second question** would be : Anybody knows where this `aln.UnknownChrom.bam` comes from when using `splitChromosome` ? It is a source of error in a pipeline I am building and I'd like to get rid of it, if these are not actual mapping informations.
  
  **Tags:** sam, samtools
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-01-30. Score: 2 | Accepted answer
  
  As per the SAM/BAM format specifications:
  
  > "RNAME: Reference sequence NAME of the alignment. If @SQheader lines are present, RNAME(if not ‘\*’) must be present in one of the SQ-SN tag. **An unmapped segment without coordinate has a ‘\*’ at this field.** However, an unmapped segment may also have an ordinary coordinate such that it can be placed at a desired position after sorting. If RNAME is ‘\*’, no assumptions can be made about POS and CIGAR." -- <http://samtools.github.io/hts-specs/SAMv1.pdf>, emphasis mine
  
  So, yes, these are the unmapped reads.
  
  I haven't used this `splitChromosome` utility before myself, but as it splits the BAM file into one BAM file per chromosome, I suspect it simply also creates a BAM file for the unknown (`*`) chromosome. Why the numbers don't match I can't tell.
  
  How to deal with that file in your pipeline will depend on what the pipeline is meant to do. But if you aren't interested in these reads, I suppose you could simply remove it before continuing to the next step.
  
  > **Comments:**
  > **username_0**: Nice ! I'll maybe ask directly on bamUtil's github for my second question.  
  
  ---
  
  