Building bowtie index with mirBase hairpin.fa file

[Gators]

Has anyone been able to build a bowtie index with the mirBase hairpin.fa file? I'm having some weird issues and I don't really know what the story is. I've been able to build other indexes without issue, but the mirbase hairpin file is acting strange. When I try to do an alignment it is not finding the vast majority of alignments with the index. It only finds a small percentage, and these are overwhelming GC-rich with 1 or 2 mismatches. There are no errors in the index building process, although I was a bit confused with one aspect of the build - during the build process this was part of the output:

fchr[A]: 0
fchr[C]: 416893
fchr[G]: 781895
fchr[T]: 1191858
fchr[$]: 1191858

I'd be lying if I said I knew exactly what it meant, but it does seem a bit odd...

Anyone make this index successfully?

PS-miRBase is now on version 17, but I couldn't get this to work with version 16 either

[gqy]

I'm having the same issue. Has there been any hints yet?
Thanks!

Alex

[GenoMax]

@ggy: Is the problem building the index or with alignments?

[gqy]

Sorry I was not being clear.
I was trying to build bowtie2 index of mm10 from the mm10_all_chr.fa file.
Basically what I did not get any error message to my understanding (but could be wrong). However, I saw sth like in the report after index building:

fchr[A]: 0
fchr[C]: 416893
fchr[G]: 781895
fchr[T]: 1191858
fchr[$]: 1191858

I haven't carried out alignment yet, but I don't feel right about these messages.
What does the 'fchr[$]' mean? Why is there no 'A' detected if I understood it correctly?

Thank you very much!

[Brian Bushnell]

Those look like the starting indices for the different symbols in the bwt. $ is a fake symbol that indicates the end of a string, and it looks like this actually indicates there are 416893 A's, not zero. Generally, just ignore stuff a program prints to the screen that you don't understand unless it crashes or clearly states something went wrong; it probably means something to the programmer.

[gqy]

Thanks for the advice. I proceeded with the alignment with Tophat2 and got thru with no error. However, there seems to be a significant difference between the alignment result btw Tophat2 and novoalign. I have two samples, the result is like this:

sample1 (17665866 reads): Tophat2 returns 10942864 mapped (61.9% of input); novoalign returns 15436347 mapped (87.4%)

sample2 (23823043 reads): Tophat2 returns 16776971 mapped (70.4% of input); novoalign returns 21214876 mapped (89.1%)

Should I be worried that the Tophat2 was not run correctly or the result from it is less reliable?

Thanks!

Alex

[Brian Bushnell]

Yes, you should be worried. No two mappers will give you identical output, and it's always best to use the one that gives the best results. However, sensitivity is not the same as accuracy, so technically you don't know that novoalign is giving you better results, but it probably is.

In this case, I'm guessing that there's a problem with your data and you should probably quality-trim and/or adapter-trim before mapping. I suggest you run FastQC and post the results here.

What kind of data are you mapping, and what are you mapping it to, anyway?