Menu
▾
▴
gmod-ajax
|
From: Davis, A. C. <da...@mu...> - 2007-12-04 16:59:50
|
I have been having problems getting the tile generator to generate tiles fo= r EST reads. I have them set up with EST DNA fasta files so that when zoom= ed in it displays the DNA with insertions/deletions and mismatches. It all= displays perfectly fine in gbrowse, but when I try to generate tiles, it h= angs and never even starts the entire landmark view. I tried disabling the= DNA display when zoomed in, but it still wouldnt generate. I'm wondering = if it has to do with having the GFF file set up to utilize the DNA fasta fi= le for the EST reads. For all of this, I loaded everything into database f= irst, then generated tiles after checking that it displayed properly in gbr= owse. Here are some example lines from my EST gff file scaffold_45 est match 753297 756343 . + . Tar= get EST:CACW5781.b1 1 905 scaffold_30 est match 563618 564742 . - . Tar= get EST:CACW6759.g1 1 742 scaffold_2 est match 1281895 1282741 . - . Tar= get EST:CACW11451.g1 1 863 scaffold_68 est match 160772 161720 . + . Tar= get EST:CACW4784.g2 1 725 scaffold_45 est HSP 753297 753324 . + . Tar= get EST:CACW5781.b1 1 28 scaffold_45 est HSP 753463 753501 . + . Tar= get EST:CACW5781.b1 29 67 scaffold_45 est HSP 753854 753979 . + . Tar= get EST:CACW5781.b1 68 193 scaffold_45 est HSP 754933 755079 . + . Tar= get EST:CACW5781.b1 194 340 scaffold_45 est HSP 755505 755688 . + . Tar= get EST:CACW5781.b1 341 524 scaffold_45 est HSP 755963 756343 . + . Tar= get EST:CACW5781.b1 525 905 scaffold_30 est HSP 563618 564293 . + . Tar= get EST:CACW6759.g1 1 675 scaffold_30 est HSP 564676 564742 . + . Tar= get EST:CACW6759.g1 676 742 scaffold_2 est HSP 1281895 1282741 . - . Tar= get EST:CACW11451.g1 1 863 scaffold_68 est HSP 161163 161720 . - . Tar= get EST:CACW4784.g2 1 560 scaffold_68 est HSP 160772 160936 . - . Tar= get EST:CACW4784.g2 561 725 And here is the track in my conf file: [EST] feature =3D match:est glyph =3D segments label_position =3D left draw_target =3D 1 show_mismatch =3D 1 fontcolor =3D blue mismatch_color =3D red true_target =3D 1 realign =3D 1 bgcolor =3D white fgcolor =3D black key =3D ESTs [EST:1000] label_position =3D top I have tried commenting out most of the track settings trying to make it ju= st a generic track, and it still doesnt work, which is why I think it has t= o do with the GFF file formatting. If anyone can possibly provide any insight as to why I can't get the tiles = to generate (or if it just isn't supported), I would greatly appreciate it. -Adam Davis |
|
From: Mitch S. <mit...@be...> - 2007-12-05 08:55:32
|
It's tough to say; I don't know of a reason why this wouldn't work, and I'm sure there are lots of possibilities for what's going on. So I'd like to go through a bit of troubleshooting, if you don't mind answering some questions. 1. What output (if any) do you get when you try to generate tiles? 2. Can you generate tiles for other kinds of features? 3. What database are you using (Bio::DB:GFF, Bio::DB::SeqFeature::Store, Chado, ?) 4. What versions of Bioperl and GBrowse are you using? Thanks, Mitch Davis, Adam Christiaan wrote: > I have been having problems getting the tile generator to generate tiles for EST reads. I have them set up with EST DNA fasta files so that when zoomed in it displays the DNA with insertions/deletions and mismatches. It all displays perfectly fine in gbrowse, but when I try to generate tiles, it hangs and never even starts the entire landmark view. I tried disabling the DNA display when zoomed in, but it still wouldnt generate. I'm wondering if it has to do with having the GFF file set up to utilize the DNA fasta file for the EST reads. For all of this, I loaded everything into database first, then generated tiles after checking that it displayed properly in gbrowse. Here are some example lines from my EST gff file > > scaffold_45 est match 753297 756343 . + . Target EST:CACW5781.b1 1 905 > scaffold_30 est match 563618 564742 . - . Target EST:CACW6759.g1 1 742 > scaffold_2 est match 1281895 1282741 . - . Target EST:CACW11451.g1 1 863 > scaffold_68 est match 160772 161720 . + . Target EST:CACW4784.g2 1 725 > scaffold_45 est HSP 753297 753324 . + . Target EST:CACW5781.b1 1 28 > scaffold_45 est HSP 753463 753501 . + . Target EST:CACW5781.b1 29 67 > scaffold_45 est HSP 753854 753979 . + . Target EST:CACW5781.b1 68 193 > scaffold_45 est HSP 754933 755079 . + . Target EST:CACW5781.b1 194 340 > scaffold_45 est HSP 755505 755688 . + . Target EST:CACW5781.b1 341 524 > scaffold_45 est HSP 755963 756343 . + . Target EST:CACW5781.b1 525 905 > scaffold_30 est HSP 563618 564293 . + . Target EST:CACW6759.g1 1 675 > scaffold_30 est HSP 564676 564742 . + . Target EST:CACW6759.g1 676 742 > scaffold_2 est HSP 1281895 1282741 . - . Target EST:CACW11451.g1 1 863 > scaffold_68 est HSP 161163 161720 . - . Target EST:CACW4784.g2 1 560 > scaffold_68 est HSP 160772 160936 . - . Target EST:CACW4784.g2 561 725 > > And here is the track in my conf file: > [EST] > feature = match:est > glyph = segments > label_position = left > draw_target = 1 > show_mismatch = 1 > fontcolor = blue > mismatch_color = red > true_target = 1 > realign = 1 > bgcolor = white > fgcolor = black > key = ESTs > > [EST:1000] > label_position = top > > I have tried commenting out most of the track settings trying to make it just a generic track, and it still doesnt work, which is why I think it has to do with the GFF file formatting. > > If anyone can possibly provide any insight as to why I can't get the tiles to generate (or if it just isn't supported), I would greatly appreciate it. > > -Adam Davis > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > |
|
From: Mitch S. <mit...@be...> - 2007-12-06 21:43:35
|
Adam Davis wrote: > The "wo oo" part was me inserting prints into generate-tiles.pl to > find the point at which it hangs. Here is the code from that file, > starting at line 255: > The print statement I inserted actually gets cut off halfway through, > which is odd. It always cuts off in the same place too. > > print > " There are $num_tracks tracks, $num_zooms zoom levels total\n", > > "-------------------------------------------------------------------------\n"; > > print " wo\noo\noo"; > <---------------------------------------------------------------------------------------Here > is the print I inserted Thanks for the detailed reply. Hmmm, I probably need to spend some time reading the code and thinking, but off the top of my head I have some information that might help. The wo\noo\noo gets cut off before the last oo because the output is line buffered; your last oo does get output to some buffer, but the program gets stuck before the oo makes it any further than that. So it might seem like the program is getting stuck in the middle of your print statement, but it's actually further down than that. You could try moving the print further down, and/or you could also try running generate-tiles with strace: strace ./generate-tiles.pl <all your generate-tiles.pl arguments> I'm assuming you're using linux. Strace will probably generate a lot of output, and we'd be interested in the last few screenfuls of it. Whenever something hangs on linux and it's not using any CPU (it isn't, right?) it's usually waiting on some kind of IO; best guess is the database. We've tried to use Bio::DB similarly to the way regular GBrowse does, so that we'll be compatible with existing GBrowse setups, but I think we have to do some things differently, and this is probably due to one of those. One of the things we do differently from regular GBrowse is that we deal with an entire landmark (chromosome/scaffold/contig/whatever) of data at a time (to do layout). So the hang may just be the database churning, trying to gather all the data that we're asking for. How many reads are on scaffold_1? I expected some difficulty scaling with some plant genomes, which I've heard are huge, but I thought the individual chromosomes weren't much bigger than (say) human, so I was hoping we'd be okay. But if my guess is right then we need to do some more scaling work. Mitch |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X