[Samtools-help] Fwd: [rice.edu #337918] compile samtools

[deqiang s. <deq...@bc...>]

Dear samtools developer,

We have found that the bam file generated by Tophat v1.3.1 can not be converted to sam file by samtools (multiple versions) on IBM PowerPC system running Red Hat Linux. On this supercomputer, It can convert sam to bam though. 

However, this bam file in question can be converted to sam file by samtools on x86(both AMD and Intel) system running linux.
However, samtools can convert bam files generated by a program called RSEM to sam file on this Power system.

Let me know if you need the file in question. I am not sure whether you can apply for an account on the BLUEBIOU supercomputer from Texas medical center. But if you are willing to do so, there's a great possibility.

Thanks,

D.Sun
Begin forwarded message:
> From: IT Help <hel...@he...>
> Date: November 29, 2011 12:02:21 PM CST
> To: "Sun, Deqiang" <deq...@bc...>
> Subject: [rice.edu #337918] compile samtools 
> Reply-To: IT Help <hel...@he...>
> 
> "Wilkerson, Chandler" replied to your 
> request for help [rice.edu #337918]:
> 
> This is good, now we may be able to go to the developer with something useful.
> 
> As you are the domain expert here (I've never touched tophat, and all my
> knowledge of samtools comes from the online help) I would like to encourage you
> to subscribe to the samtools-help email list and request help with this issue
> from them. (It doesn't look like they have a direct email or ticket support
> system like we have here.)
> 
> The key issues you're seeing is a runaway memory allocation (12TB virtual size,
> 95% actual RAM allocated, with an endless loop of mmap operations trying to
> allocate more) when using a tophat created bam file on a Power system running
> Red Hat Enterprise Linux 6.0.
> 
> My theory is that an endian issue is the underlying culprit, in that recent
> modifications to samtools for tophat support may have come after the effort to
> handle big endian compatibility, and that the code that handles the tophat
> headers may not be big-endian safe, causing some internal array to be bounded
> by an impossibly huge number, which creates the memory issue.
> 
> On Tue Nov 29 11:09:42 2011, ds30 wrote:
>> Thanks very much for your help.
>> I tried another bam file, Rps7_l80.seed80.mis0.rsem.sorted.bam, and
>> it works fine. I then noticed there are two different tags @HD and
>> @PG in the header I tried to remove them and did the bam to sam
>> conversion. But it did not work.
>> 
>> The accepted_hits* are generated by tophat but the Rps7*bam is
>> generated by another program. I use tophat for rna-seq data and
>> probably I just stick to our lab server.
>> 
>> Best regards,
>> 
>> Deqiang Sun
>> Baylor College of Medicine
>> 713-798-6936
>> Deq...@bc...
>> On Nov 29, 2011, at 10:48 AM, IT Help wrote:
>>> "Wilkerson, Chandler" replied to your
>>> request for help [rice.edu #337918]:
>>> 
>>> Also, it is interesting to note, yesterday I tried converting the
>> bam to sam
>>> with headers from my workstation, which worked fine, then I copied
>> the sam over
>>> to biou and used the samtools I compiled to create a bam format file
>> with the
>>> -Sb option. This worked fine and produced an identical .bam file to
>> your
>>> original. It is possible that only the bam to sam conversion is
>> faulty on biou,
>>> in which case you might try circumventing that part of the process.
>>> 
>>> 
>>> 
>>> --
>>> Chandler Wilkerson, RHCA
>>> Research Computing Support Group
>>> http://rcsg.rice.edu/
>>> 
>>> 
>>> You may review this request at
>>> 
>>> https://help.rice.edu:443/SelfService/Display.html?id=337918
>>> 
>> 
> 
> 
> --
> Chandler Wilkerson, RHCA
> Research Computing Support Group
> http://rcsg.rice.edu/
> 
> 
> You may review this request at 
> 
>  https://help.rice.edu:443/SelfService/Display.html?id=337918
>