Open jdblischak opened 8 years ago
Can this problem be solved with the new 2.63 release? I have abandoned the chromosome check which is often problematic. Users are now responsible for making sure their bam files contain the same chromosome names as their references.
ngsplot only accepts BAM files where the chromosomes either all start with "chr" or none start with "chr". This has caused problems in the past, e.g. Issues #25 and #39, and I demonstrate below that the current implementation has trouble with reads mapping to mitochondrial reads.
From my quick inspection of the code, it is my understanding that the purpose of checking for the presence of "chr" at the beginning of the chromosome names is to account for the differences in how databases name them.
For example, the annotation data for hg19 uses the UCSC naming scheme.
On the other hand, the [example BAM file]() provided for testing uses the Ensembl naming scheme.
My understanding of the current solution is that the function chrTag checks for the presence of "chr" at the beginning of the chromosomes. If it detects "chr", it sets
chr.tag
toTRUE
. Here is the function.chr.tag
is then passed to the function doCov. If it isTRUE
, the leading "chr" is removed from the chromosome names in the annotation file. Here is the relevant code:This workaround fixes the naming for the majority of the chromosomes. However, it does not fix the name of the mitochondrial sequence. UCSC uses "chrM", and Ensembl uses "MT".
To confirm this problem, I created a list of the mitochondrial genes.
I then run ngsplot on the example BAM file for only these genes.
Because the chromsome names do not match, there is zero enrichment.
Now creating a new BAM file with the mitochondrial chromosome converted from MT to M (inspired by this Biostars post).
Re-running ngsplot with the updated chromosome name.
Now that the chromosome names match, there is enrichment.
Instead of removing "chr" from the chromosome names in the annotation file, what if instead ngsplot converted the chromsome names in the BAM file from Ensembl to UCSC? Maybe this could be a command-line option? I could help try to implement something to fix this if you could give me some direction on what you would be willing to accept as a PR.