On May 28, 2010, at 3:05 PM, Davide Cittaro wrote:
On May 28, 2010, at 2:58 PM, Nate Coraor wrote:
Davide Cittaro wrote:
use_printdebug = False
Ah, that was going to be my first question. I suggest just use_debug = False.
solves the memory issue (at least doesn't call paste.PrintDebugMiddleware which calls paste.intercept_output....)
BTW, still not able to see BAM files... well, actually I can see the reads at the beginning of chromosome 10, which are the reads at the beginning of my BAM file :-(
I've asked to open the galaxy test server to the UCSC in California... Still get truncated BAM files, at the beginning of chr10... What is nice is that files are truncated in a different manner on our mirror, like it can read some more information before end of communication... Unfortunately there's no log about this "truncation" error... :-(
It looks like I'm only able to load the portion of BAM file that is in the UCSC range previously selected. Suppose I have a clean session in UCSC, spanning chr10:1-50,000,000. As I link from history to UCSC a BAM file I can see reads for the same span, nothing more (and, obviously no reads on other chroms).
What is strange is that the same doesn't apply on other chromosomes, it seems that galaxy tells the UCSC the content of BAM file from the beginning (chr10 in my sorted case) to the max span available (which is the end of chr10 at max)... It acts as if there is a kind of galaxy cache that is never emptied... Does this make sense to you? Besides, have you ever tried visualizatoin of BAM files when using remoteuser?
d
/*