headers
Chris Fields | 1 Dec 05:37
Picon

Re: Problems installing bioperl (bioperl-live tarball from CVS)

Make sure to keep this on the list.

ncbi_gi() is only in bioperl-live (CVS); my guess is you either  
somehow got 1.5.2 instead or the bioperl-live version is not found in  
your path.  It's very likely the latter, as perl's looking for  
whatever else is present (which appears to be an older version of  
bioperl). That should give you a hint that the problem may be with  
your lib path.  Try changing the 'Use lib '/home/awaller/bioperl-live/ 
Bio'' to:

use lib '/home/awaller/bioperl-live';

chris

On Nov 30, 2007, at 8:09 PM, alison waller wrote:

> Okay so Now I'm really confused.
> I edited > #!usr/bin/perl
>> Use lib '/home/awaller/bioperl-live/Bio.
> I ran the script below with the *special hit->ncbi from Chris.  It  
> worked,
> it was great, I got the gi! No errors, no bugs that I saw in  
> checking the
> output.  Then I went back in, edited the script to retrieve further  
> info
> (specifically the strand).  Saved it, now when I try to run it I get  
> the
> same error message that I was previously getting.
>
> barrett ~ $ perl blast_parse_awcf.pl OldMoBlastxGiTest.txt 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Bridge | 2 Dec 19:29
Picon
Favicon

Bio::Tools::Run::RemoteBlast

Hello,

I was just wondering if, when performing a RemoteBlast, it would be 
possible to specify the entire UniProt database (i.e. Swiss-Prot + 
TrEMBL), or even just TrEMBL.

It seems that currently, you can only specify Swiss-Prot (the annotated 
portion of UniProt, which is much smaller than its automatically 
annotated counterpart, TrEMBL). Any hints on how to expand the search 
space to include TrEMBL would be really appreciated.

Regards, Alan Bridge

            my $prog = 'blastp';
            my $db   = 'swissprot'; # use TrEMBL ?
            my $e_val= '1e-10';

            my @params = ( '-prog' => $prog, '-data' => $db, '-expect' 
=> $e_val, '-readmethod' => 'SearchIO' );

--

-- 
Alan Bridge PhD
Swiss-Prot annotator
Swiss Institute of Bioinformatics (SIB)
1, rue Michel Servet
CH-1211 Geneva 4  
Switzerland   

Tel: (+41 22) 379 58 90
Fax: (+41 22) 379 58 58
(Continue reading)

Permalink | Reply | 1 comment |
headers
Albert Vilella | 3 Dec 12:39
Picon
Gravatar

Re: Query about SLAC.pm module

[CCing to the bioperl ml]

Sorry, there were some bits left in the pod header referring to PAML
objects that aren't quite true.
I've updated now the PODs. The Hyphy executions return hashes:

If you run the SLAC test in t/Hyphy.t you will se that the $results
are something like:

DB<3> x 2 $results
0  HASH(0x8df3110)
   'E[NS Sites]' => ARRAY(0x8e6cff4)
   'E[S Sites]' => ARRAY(0x8e6ceb0)
   'Observed NS Changes' => ARRAY(0x8e7b380)
   'Observed S Changes' => ARRAY(0x8e7b344)
   'Observed S. Prop.' => ARRAY(0x8e6d018)
   'P{S geq. observed}' => ARRAY(0x8e6d360)
   'P{S leq. observed}' => ARRAY(0x8e6d33c)
   'P{S}' => ARRAY(0x8e6d03c)
   'Scaled dN-dS' => ARRAY(0x8e6d384)
   'dN' => ARRAY(0x8e6d084)
   'dN-dS' => ARRAY(0x8e6d0a8)
   'dS' => ARRAY(0x8e6d060)
  DB<4> x $rc

which correspond to the csv file that hyphy produces.

Cheers,

    Albert.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Fields | 3 Dec 15:04
Picon

Re: Bio::Tools::Run::RemoteBlast

You are limited to the databases hosted on the NCBI server, so it's  
really up to them; RemoteBlast is an interface to NCBI's WebBlast  
using URLAPI.

A list of current databases can be found here:

http://www.ncbi.nlm.nih.gov/staff/tao/URLAPI/remote_blastdblist.html

chris

On Dec 2, 2007, at 12:29 PM, Alan Bridge wrote:

> Hello,
>
> I was just wondering if, when performing a RemoteBlast, it would be
> possible to specify the entire UniProt database (i.e. Swiss-Prot +
> TrEMBL), or even just TrEMBL.
>
> It seems that currently, you can only specify Swiss-Prot (the  
> annotated
> portion of UniProt, which is much smaller than its automatically
> annotated counterpart, TrEMBL). Any hints on how to expand the search
> space to include TrEMBL would be really appreciated.
>
> Regards, Alan Bridge
>
>            my $prog = 'blastp';
>            my $db   = 'swissprot'; # use TrEMBL ?
>            my $e_val= '1e-10';
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Boekhoff | 3 Dec 20:14

[StandAloneBLAST] Use more than one CPU + avoid BLAST reload

HI!
I just started working with Perl and BioPerl. I'm quite impressed what 
can be easily done with this module. Today I found that my second CPU 
ist not used, but the first one run's at 100%. I tried to include the 
"-a"-parameter, but I was not successful:

my @params = (
	-database => 'my_db',
	-a => '2',
	-outfile => 'blast1.out'
);

How do I have to use it?

Second question: In my perlscript I start BLAST-searches in a loop. 
Everytime BLAST has finished its search, the memory is cleared and BLAST 
is started again. I think most of the time is used to reload the 
database. Is it somehow possible to keep the database loaded (e.g. by 
starting a second search) or is BLAST reloaded anyway?

Thanks for your help!

Sven

www.boekhoff.info
Permalink | Reply | 10 comments |
headers
Sendu Bala | 4 Dec 01:05
Picon
Favicon

Re: [StandAloneBLAST] Use more than one CPU + avoid BLAST reload

Sven Boekhoff wrote:
> HI!
> I just started working with Perl and BioPerl. I'm quite impressed what 
> can be easily done with this module. Today I found that my second CPU 
> ist not used, but the first one run's at 100%. I tried to include the 
> "-a"-parameter, but I was not successful:
> 
> my @params = (
> 	-database => 'my_db',
> 	-a => '2',
> 	-outfile => 'blast1.out'
> );
> 
> How do I have to use it?

This should work in the CVS version of StandAloneBlast. In other 
versions, perhaps try using $object->a(2);

> Second question: In my perlscript I start BLAST-searches in a loop. 
> Everytime BLAST has finished its search, the memory is cleared and BLAST 
> is started again. I think most of the time is used to reload the 
> database. Is it somehow possible to keep the database loaded (e.g. by 
> starting a second search) or is BLAST reloaded anyway?

I hope someone will correct me for being wrong, but I think you'd have 
to that with a 2-way pipe. StandAloneBlast only uses output to a file 
and input from that file, finishing with the executable inbetween. I've 
thought about improving it with a 2-way pipe, but never got around to 
it, being apprehensive about stability on all platforms.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Smithies, Russell | 4 Dec 01:49
Picon

Bio::Assembly::IO problems reading .ace files

Hi all,

It' trying to read .ace files but keep getting an error that I don't
know the cause of.
Really basic example code:

	#!/usr/local/bin/perl -w

	use lib "/data/home/smithiesr/bioperl-live";
	use Bio::Assembly::IO;
	use Data::Dumper;

	$ace = "CLP0001001240-cE15_20030319.ace";

	$io = new Bio::Assembly::IO(-file=>$ace,-format=>"ace");
	$assembly = $io->next_assembly;

	foreach $contig ($assembly->all_contigs) {
      		print Dumper $contig;
	}

Gives this error;
	[smithiesr <at> impala ace_phrap]$ perl bp_read_ace.pl
	Can't call method "get_consensus_sequence" on an undefined value
at /data/home/smithiesr/bioperl-live/Bio/Assembly/IO/ace.pm line 170,
<GEN0> line 42.

Which relates to this bit in ace.pm:
	# Loading contig qualities... (Base Quality field)
	/^BQ/ && do {
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chris Fields | 4 Dec 03:15
Picon

Re: Bio::Assembly::IO problems reading .ace files

This seems similar to the 'too many open filehandles issue' documented  
here:

http://bugzilla.open-bio.org/show_bug.cgi?id=2320

It unfortunately is due to having an open DB_File for every contig,  
and is a problem with the Bio::Assembly implementation that isn't  
easily fixed.  Changing the open filehandle limit using ulimit is the  
only known fix:

ulimit -n 10000

chris

On Dec 3, 2007, at 6:49 PM, Smithies, Russell wrote:

> Hi all,
>
> It' trying to read .ace files but keep getting an error that I don't
> know the cause of.
> Really basic example code:
>
> 	#!/usr/local/bin/perl -w
>
> 	use lib "/data/home/smithiesr/bioperl-live";
> 	use Bio::Assembly::IO;
> 	use Data::Dumper;
>
> 	$ace = "CLP0001001240-cE15_20030319.ace";
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Florent Angly | 4 Dec 03:25
Picon

Re: Bio::Assembly::IO problems reading .ace files

Would this issue cause an excessive memory usage? Because I was getting 
a high memory usage when parsing some TIGR Assembler files and was 
wondering if the tigr parser was responsible for that or the parent 
assembly IO module.
I'd definitely be interested in a fix of the Bio::Assembly 
implementation if it's the assembly IO module's fault....
Florent

Chris Fields wrote:
> This seems similar to the 'too many open filehandles issue' documented  
> here:
>
> http://bugzilla.open-bio.org/show_bug.cgi?id=2320
>
> It unfortunately is due to having an open DB_File for every contig,  
> and is a problem with the Bio::Assembly implementation that isn't  
> easily fixed.  Changing the open filehandle limit using ulimit is the  
> only known fix:
>
> ulimit -n 10000
>
> chris
>
> On Dec 3, 2007, at 6:49 PM, Smithies, Russell wrote:
>
>   
>> Hi all,
>>
>> It' trying to read .ace files but keep getting an error that I don't
>> know the cause of.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Smithies, Russell | 4 Dec 03:32
Picon

Re: Bio::Assembly::IO problems reading .ace files

Thanx Chris,
I'm only writing a simple .ace viewer to display assembled contigs in a
Bio::Graphics::Panel so I'll parse the coords from the .ace files
"manually".
Unless anyone else has a better idea ?
(and some example code ;-)

Russell

> -----Original Message-----
> From: Chris Fields [mailto:cjfields <at> uiuc.edu]
> Sent: Tuesday, 4 December 2007 3:16 p.m.
> To: Smithies, Russell
> Cc: bioperl-l <at> lists.open-bio.org
> Subject: Re: [Bioperl-l] Bio::Assembly::IO problems reading .ace files
> 
> This seems similar to the 'too many open filehandles issue' documented
> here:
> 
> http://bugzilla.open-bio.org/show_bug.cgi?id=2320
> 
> It unfortunately is due to having an open DB_File for every contig,
> and is a problem with the Bio::Assembly implementation that isn't
> easily fixed.  Changing the open filehandle limit using ulimit is the
> only known fix:
> 
> ulimit -n 10000
> 
> chris
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane