[Bioperl-l] RemoteBlast [was: (no subject)]

Wed Feb 8 15:32:25 UTC 2006

Roger, 

It might be better to build a wrapper for the blastcl3 and make it a
separate Bio::Tools::Run module, maybe branch it off from RemoteBlast or,
better yet, StandAloneBlast.  All the put/get parameters in the BEGIN{}
block for RemoteBlast look like they are configured for NCBI's HTTP
submission via CGI; I don't think you can use these for blastcl3.  Ergo,
you'll have to create a whole new set of hashes or parameter arrays inside
RemoteBlast just for blastcl3 since everything is passed via command-line
flags, like so (from http://www.ncbi.nlm.nih.gov/blast/docs/netblast.html):

blastcl3 -p blastp -d nr -i MY_QUEYR -o MY_QUERY.out

However, StandAloneBlast looks like it has all the parameters mapped out in
the BEGIN{} block.  And it looks like the command line options support just
about everything you get via the web version.  It probably wouldn't take
much modification from StandAloneBlast to get it to run blastcl3.

As for queueing, I don't think it's supported, though you can send in a
FASTA file with multiple sequences for multiple BLAST queries (I tried this
and it works).  You could also create a queue using a sequence factory,
sending them to the netblast client one at a time, though I'd suggest
putting a delay in between cycles in that case so as not to make the guys at
NCBI cranky.

Christopher Fields
Postdoctoral Researcher - Switzer Lab
Dept. of Biochemistry
University of Illinois Urbana-Champaign  

> -----Original Message-----
> From: bioperl-l-bounces at lists.open-bio.org 
> [mailto:bioperl-l-bounces at lists.open-bio.org] On Behalf Of Roger Hall
> Sent: Tuesday, February 07, 2006 11:17 PM
> To: Paul.Boutros at utoronto.ca; 'BioPerl Mailing List'
> Subject: Re: [Bioperl-l] RemoteBlast [was: (no subject)]
> 
> Paul,
> 
> I think that most core Bioperl folks have long since moved 
> away from RemoteBlast and are using the functionality in 
> StandAloneBlast to run their own local servers. More 
> importantly, they are, in general, researchers who are coming 
> to Bioinformatics from the life sciences side, and are 
> particularly tired of dealing with the technical issues that 
> RemoteBlast consistently generates due to changes in the 
> text-formatted BLAST reports. 
> 
> They aren't code-for-code-sake geeks like me. ;}
> 
> When RemoteBlast was written, XML was barely on the 
> technology radar, and XML-formatted BLAST reports weren't 
> even available. It seems that everyone recognizes that the 
> XML reports now generated by NCBI's blast server is the wave 
> of the future, but I think there is still some concern that 
> not every flavor of BLAST produces XML yet. Even so, the XML 
> parser is considered to be very strong, and only helps hasten 
> the end of text-formatted support, since parsing 
> text-formatted reports is the primary source of pain. 
> 
> In discussing the shift from old to new, I think the idea of 
> relying on NCBI's application (and NCBI's issue system and 
> NCBI's developers) entered the realm of possibility, so as 
> the guy who just showed up to adopt RemoteBlast, I am trying 
> to air all options and beg for all requirements. 
> 
> Personally, I am okay with the idea of maintaining 
> text-formatted report parsing, but like I said, I'm pound 
> foolish about code sometimes. Additional foolishness arises 
> from the fact that the first money I earned in Bioinformatics 
> was on a contract gig where I relied on RemoteBlast (and the 
> related text parsers).
> 
> For my money, I just needed anyone, anywhere, to say they 
> desired a pure perl implementation to meet my personal 
> threshold. So far, you're the second. ;}
> 
> I do, however, see the advantage in shifting to XML-formatted 
> reporting and parsing *only* as soon as every BLAST flavor 
> supports it, if not before.
> (Anyone - is this still an issue. Please educate me.)
> 
> At the moment, I'm leaning towards adding an option to 
> RemoteBlast. The default (no option) would use a "pure perl" 
> implementation, and the enhancement (with explicit option) 
> would merely wrap the NCBI executable.
> However, there are other issues (queuing, batches) that I 
> don't fully understand in context, so I haven't zeroed in on 
> a complete recommendation yet. Additionally, the end of 
> text-formatted reports, while drawing near, is not yet 
> agreed, although it is pretty clear that the only way text 
> support will be continued is if I insist on it and then 
> deliver the support myself.
> :}
> 
> In any case, I am very interested in a pure perl 
> implementation for exactly the two reasons stated thus far: 
> it's one less thing for a newbie to worry about, and it will 
> run on every platform that runs perl. 
> 
> Thanks much for the input!
> 
> Roger Hall
> Technical Director
> MidSouth Bioinformatics Center
> University of Arkansas at Little Rock
> (501) 569-8074
> 
> 
> 
> 
> -----Original Message-----
> From: bioperl-l-bounces at lists.open-bio.org
> [mailto:bioperl-l-bounces at lists.open-bio.org] On Behalf Of 
> Paul Boutros
> Sent: Tuesday, February 07, 2006 7:39 PM
> To: BioPerl Mailing List
> Cc: Roger Hall
> Subject: [Bioperl-l] (no subject)
> 
> Hi Roger,
> 
> I would definitely prefer a fully Perl-based implementation.  
> For starters, I have not been successful in compiling the 
> Toolkit that contains netblast for some platforms (e.g. 
> AIX 5.2 w/gcc 4.0).
> 
> I haven't been following the discussion: is there some 
> compelling reason to prefer a netblast-based system that's 
> come up recently?  I'm guessing that adding a new non-perl 
> dependency would only be done if there was considerable 
> justification for this type of change, but I'm not clear from 
> your message what that justification is.
> 
> Paul
> 
> 
> 
> ------------------------------ 
> 
> Message: 12
> Date: Mon, 6 Feb 2006 20:46:44 -0600
> From: "Roger Hall" <rahall2 at ualr.edu>
> Subject: [Bioperl-l] RemoteBlast users - potentially major changes - 
>         please        reply 
> To: <bioperl-l at lists.open-bio.org>
> Message-ID: <002001c62b90$bb9dbe00$4301a8c0 at LIBERAL> 
> Content-Type: text/plain;        charset="us-ascii" 
> 
> To everyone who uses RemoteBlast.pm: 
> 
> Would anyone object to RemoteBlast being rewritten in a way 
> that requires NCBI's blastcl3 executable? 
> 
> Binary downloads of blastcl3 (column "netblast") are 
> available for numerous platforms at: 
> http://ncbi.nih.gov/BLAST/download.shtml 
> 
> Does anyone require or desire a "pure perl" implementation? 
> If so, please explain the advantage you see with such an 
> implementation. 
> 
> Thanks! 
>  
> 
> Roger Hall 
> 
> Technical Director 
> 
> MidSouth Bioinformatics Center 
> 
> University of Arkansas at Little Rock 
> 
> (501) 569-8074 
> 
>   
> 
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l