Hi Davide, Galaxy doesn't do anything 'special' here. It provides access to 3 files to UCSC, a BAM file, the BAI index file, and a track definition 'file'. The track definition contains 4 pieces of information, the type of track, the url of the bam file, the dbkey and a name for the track. Check that the track file has valid information (especially the URL) and that the bam, bai and track files are accessible via HTTP. IIRC the UCSC browser does some caching on its end for BAM files by 'filename', so you will likely need to use different history items than the ones that were failing (due to having debug options on) or clear this cache. Can you confirm the odd behavior occurs on history items that did not experience the memory errors? Cloning the history or copying the history items (under edit attributes) should be sufficient. Thanks, Dan On May 28, 2010, at 9:31 AM, Davide Cittaro wrote:
Found something weird
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
/* Davide Cittaro
Cogentech - Consortium for Genomic Technologies via adamello, 16 20139 Milano Italy
tel.: +39(02)574303007 e-mail: davide.cittaro@ifom-ieo-campus.it */
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev