January 2008 - Mg-rast - mailman3.cels.anl.gov

mg-rast Bug with micro-jobs
by Robert Olson 28 Jan '08

28 Jan '08

There's a current flood of tiny jobs (one had 3 reads) in the mgrast server. Some are failing during sims postprocess in this code: sub handle_block { my($block, $n) = @_; my @b = sort { $a->[4] <=> $b->[4] } @$block; for (my $i = 0; $i < $n; $i++) { my($id1, $id2, $genome) = @{$b[$i]}; My guess is that this is because the blocks are singletons: Looking through 1 hits Can't use an undefined value as an ARRAY reference at /vol/ metagenome-48-hour/FIGdisk.backend.prod/FIG/bin/ summarize_taxonomy_by_blast line 226. --bob

1 0

mg-rast On the production MG-RAST
by Robert Olson 23 Jan '08

23 Jan '08

it occurred to me after setting Daniel up with a space to play on bio- macpro-2 that we have enough other stuff moved off that machine that we could move the production MG-RAST frontend over there. I dup'd the frontend code onto the local disk, and have set up this url: http://bio-macpro-2.mcs.anl.gov/rast/FIG/rast.cgi it's identical to the current production code, except set up for the new multi-architecture FIGdisk scheme. Code in /disks/space2/vol/ metagenome-48-hour-xx/ on bio-macpro-2. let me know if you guys want to swing everything over there. --bob

1 0

mg-rast genomemeta
by Robert Olson 21 Jan '08

21 Jan '08

I smacked into the corruption problem on the new rast today, so finally started poking more deeply at it. it looks like I may have been doing something braindamaged in the locking code there, so have ripped it out and am trying out a fix. not committed y et, but if you want to try it in your test server it's in ~olson/FIGdisk/dist/ releases/current/FigKernelPackages/GenomeMeta.pm. --bob

1 0

Re: mg-rast possible analysis corruption mgrast
by Robert Olson 21 Jan '08

21 Jan '08

I forced a reschedule(restart) of them with 'qmod -rj jobnum' --bob On Jan 21, 2008, at 2:02 PM, Rob Edwards wrote: > Can you either restart these three jobs or kill them and their > dependents: > > 89270 > 89257 > 89242 > > Then I'll restart the analysis > > Rob > > On Jan 21, 2008, at 11:58 AM, Robert Olson wrote: > >> alas, yes, at least the part that does subsystem stuff. >> >> --bob >> >> On Jan 21, 2008, at 1:54 PM, Rob Edwards wrote: >> >>> Does this mean that the last stages of the metagenomes that are >>> chunking through at the moment should be rerun? >>> >>> There are three that seem to have been running for a long time on >>> the cluster. >>> >>> >>> Rob >>> >>> >>> On Jan 21, 2008, at 9:33 AM, Robert Olson wrote: >>> >>>> I moved the sim server on Friday, and just today saw I did not >>>> update the mgrast configs to point at its new location (bio- >>>> data-1); I believe the subsystem bindings detection code may be >>>> making use of FIG sims. >>>> >>>> there is now a redirect on the old server bio-ppc-head-2 that is >>>> sending the requests over to the new server. bioseed is also >>>> doing the same thing (and provides the external interface to the >>>> sims server). I typically configure the inside-the-firewall >>>> systems to go direct, to avoid the redirect. >>>> >>>> my apologies for any extra work this might entail. >>>> >>>> --bob >>>> >>> >> >

1 0

Re: mg-rast possible analysis corruption mgrast
by Rob Edwards 21 Jan '08

21 Jan '08

Can you either restart these three jobs or kill them and their dependents: 89270 89257 89242 Then I'll restart the analysis Rob On Jan 21, 2008, at 11:58 AM, Robert Olson wrote: > alas, yes, at least the part that does subsystem stuff. > > --bob > > On Jan 21, 2008, at 1:54 PM, Rob Edwards wrote: > >> Does this mean that the last stages of the metagenomes that are >> chunking through at the moment should be rerun? >> >> There are three that seem to have been running for a long time on >> the cluster. >> >> >> Rob >> >> >> On Jan 21, 2008, at 9:33 AM, Robert Olson wrote: >> >>> I moved the sim server on Friday, and just today saw I did not >>> update the mgrast configs to point at its new location (bio- >>> data-1); I believe the subsystem bindings detection code may be >>> making use of FIG sims. >>> >>> there is now a redirect on the old server bio-ppc-head-2 that is >>> sending the requests over to the new server. bioseed is also >>> doing the same thing (and provides the external interface to the >>> sims server). I typically configure the inside-the-firewall >>> systems to go direct, to avoid the redirect. >>> >>> my apologies for any extra work this might entail. >>> >>> --bob >>> >> >

1 0

Re: mg-rast possible analysis corruption mgrast
by Robert Olson 21 Jan '08

21 Jan '08

alas, yes, at least the part that does subsystem stuff. --bob On Jan 21, 2008, at 1:54 PM, Rob Edwards wrote: > Does this mean that the last stages of the metagenomes that are > chunking through at the moment should be rerun? > > There are three that seem to have been running for a long time on > the cluster. > > > Rob > > > On Jan 21, 2008, at 9:33 AM, Robert Olson wrote: > >> I moved the sim server on Friday, and just today saw I did not >> update the mgrast configs to point at its new location (bio- >> data-1); I believe the subsystem bindings detection code may be >> making use of FIG sims. >> >> there is now a redirect on the old server bio-ppc-head-2 that is >> sending the requests over to the new server. bioseed is also doing >> the same thing (and provides the external interface to the sims >> server). I typically configure the inside-the-firewall systems to >> go direct, to avoid the redirect. >> >> my apologies for any extra work this might entail. >> >> --bob >> >

1 0

Re: mg-rast possible analysis corruption mgrast
by Rob Edwards 21 Jan '08

21 Jan '08

Does this mean that the last stages of the metagenomes that are chunking through at the moment should be rerun? There are three that seem to have been running for a long time on the cluster. Rob On Jan 21, 2008, at 9:33 AM, Robert Olson wrote: > I moved the sim server on Friday, and just today saw I did not > update the mgrast configs to point at its new location (bio- > data-1); I believe the subsystem bindings detection code may be > making use of FIG sims. > > there is now a redirect on the old server bio-ppc-head-2 that is > sending the requests over to the new server. bioseed is also doing > the same thing (and provides the external interface to the sims > server). I typically configure the inside-the-firewall systems to > go direct, to avoid the redirect. > > my apologies for any extra work this might entail. > > --bob >

1 0

mg-rast possible analysis corruption mgrast
by Robert Olson 21 Jan '08

21 Jan '08

I moved the sim server on Friday, and just today saw I did not update the mgrast configs to point at its new location (bio-data-1); I believe the subsystem bindings detection code may be making use of FIG sims. there is now a redirect on the old server bio-ppc-head-2 that is sending the requests over to the new server. bioseed is also doing the same thing (and provides the external interface to the sims server). I typically configure the inside-the-firewall systems to go direct, to avoid the redirect. my apologies for any extra work this might entail. --bob

1 0

mg-rast additional confusion info
by Rob Edwards 18 Jan '08

18 Jan '08

The bug is easily reproduced: Basically it happens that after you have chosen view taxnomic classification once, if you do it again without loading the genome page from scratch (just reload doesn't seem to help) it displays the previous taxonomic classification, regardless of the genome you came from. You can confirm this by closing all windows/tabs related to metagenomes, and then opening two genomes in separate tabs or windows. Choose taxonomic classification in one, and then in the other. The second will always be the classification of the first, regardless of genome in the second window, and the genome identifier shown in the URL. This is very confusing to people. Rob

1 0

mg-rast confusion
by Rob Edwards 18 Jan '08

18 Jan '08

One of the things that I have seen confuse users with the current mg- rast, and is something that confuses me too, is opening multiple genomes in different tabs in a browser. For some reason the service gets confused and you end up with data from a different genome. Can you please add text somewhere that tells you which genome you are looking at. For example on the current taxonomic classification page there is no description of which genome you are looking at, or think you are looking at. Thanks Rob

1 0