headers
Bradyjoel | 1 Feb 2012 15:32
Picon

Re: Running into problems


Thank you for your help! I think I'm almost there, but I still get 1 more
error when I run the script:

$ perl blast2.pl
Searching gi|146341649|ref|YP_001206697.1|
Undefined subroutine &main::hsp_filter called at
/usr/share/perl5/Bio/SearchIO/Writer/TextResultWriter.pm line 298, <GEN6>
line 71.

Smithies, Russell wrote:
> 
> I'd probably cheat a bit and optimise my blast parameters so there's less
> output to process.
> Also, are you sure an e-value of 100 is what you're after? I'd be aiming
> much lower - probably 1e-6.
> It also pays to mask repeats if you're blasting against a whole genome to
> cut down on the number of rubbish hits.
> 
> --Russell
> 
>> -----Original Message-----
>> From: bioperl-l-bounces <at> lists.open-bio.org [mailto:bioperl-l-
>> bounces <at> lists.open-bio.org] On Behalf Of Bradyjoel
>> Sent: Tuesday, 31 January 2012 12:21 a.m.
>> To: Bioperl-l <at> lists.open-bio.org
>> Subject: [Bioperl-l] Running into problems
>> 
>> 
>> HI all,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bradyjoel | 1 Feb 2012 15:33
Picon

Re: Running into problems


Thank you for your help! I think I'm almost there, but I still get 1 more
error when I run the script:

$ perl blast2.pl
Searching gi|146341649|ref|YP_001206697.1|
Undefined subroutine &main::hsp_filter called at
/usr/share/perl5/Bio/SearchIO/Writer/TextResultWriter.pm line 298, <GEN6>
line 71.

Smithies, Russell wrote:
> 
> I'd probably cheat a bit and optimise my blast parameters so there's less
> output to process.
> Also, are you sure an e-value of 100 is what you're after? I'd be aiming
> much lower - probably 1e-6.
> It also pays to mask repeats if you're blasting against a whole genome to
> cut down on the number of rubbish hits.
> 
> --Russell
> 
>> -----Original Message-----
>> From: bioperl-l-bounces <at> lists.open-bio.org [mailto:bioperl-l-
>> bounces <at> lists.open-bio.org] On Behalf Of Bradyjoel
>> Sent: Tuesday, 31 January 2012 12:21 a.m.
>> To: Bioperl-l <at> lists.open-bio.org
>> Subject: [Bioperl-l] Running into problems
>> 
>> 
>> HI all,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bradyjoel | 1 Feb 2012 15:33
Picon

Re: Running into problems


Thank you for your help! I think I'm almost there, but I still get 1 more
error when I run the script:

$ perl blast2.pl
Searching gi|146341649|ref|YP_001206697.1|
Undefined subroutine &main::hsp_filter called at
/usr/share/perl5/Bio/SearchIO/Writer/TextResultWriter.pm line 298, <GEN6>
line 71.

Smithies, Russell wrote:
> 
> I'd probably cheat a bit and optimise my blast parameters so there's less
> output to process.
> Also, are you sure an e-value of 100 is what you're after? I'd be aiming
> much lower - probably 1e-6.
> It also pays to mask repeats if you're blasting against a whole genome to
> cut down on the number of rubbish hits.
> 
> --Russell
> 
>> -----Original Message-----
>> From: bioperl-l-bounces <at> lists.open-bio.org [mailto:bioperl-l-
>> bounces <at> lists.open-bio.org] On Behalf Of Bradyjoel
>> Sent: Tuesday, 31 January 2012 12:21 a.m.
>> To: Bioperl-l <at> lists.open-bio.org
>> Subject: [Bioperl-l] Running into problems
>> 
>> 
>> HI all,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Vivek Krishnakumar | 1 Feb 2012 16:14
Picon

`get_feature_by_name` not working after migrating to Bio::DB::SeqFeature::Store from a Bio::DB::GFF backend

Hello,

I would like to state my problem: Previously, i was working with a
Bio::DB:GFF backend database and was able to retrieve features from the
database by feature name using the function 'get_feature_by_name()'. But
recently, when I made the switch to Bio::DB::SeqFeature::Store to store the
exact same data points as before in the new db, invoking the
'get_feature_by_name()' function returns nothing.

Please refer to the following code snippet which is supposed to retrieve a
certain gene "locus" feature from the backend database and use that to get
the 'start' and 'end' coordinate of the feature based on the 'strand' on
which it is present.

my ($locus_obj, $gene_models) = get_annotation_db_features($locus,
$gff_dbh);

sub get_annotation_db_features {
    my ($locus, $gff_dbh) =  <at> _;

    my ($locus_obj) = $gff_dbh->get_feature_by_name('Gene' => '$locus');

    my ($end5, $end3) = $locus_obj->strand == 1
      ? ($locus_obj->start, $locus_obj->end)
      : ($locus_obj->end, $locus_obj->start);

    my $segment = $gff_dbh->segment($locus_obj->refseq, $end5, $end3);
    my  <at> gene_models =
      $segment->features('processed_transcript:working_models', -attributes
=> { 'Gene' => $locus });
(Continue reading)

Permalink | Reply | 9 comments |
headers
Lincoln Stein | 1 Feb 2012 16:20
Picon
Gravatar

Re: `get_feature_by_name` not working after migrating to Bio::DB::SeqFeature::Store from a Bio::DB::GFF backend

Try not putting single quotation marks around $locus, as you are searching
for a gene named (literally) "$locus". If this doesn't work,
use $gff_dbh->get_features_by_name($locus) instead, as I'm not sure whether
the Class=>Identifier syntax is accepted by Bio::DB::SeqFeature::Store.

Lincoln

On Wed, Feb 1, 2012 at 10:14 AM, Vivek Krishnakumar <
vivekkrishnakumar <at> gmail.com> wrote:

> Hello,
>
> I would like to state my problem: Previously, i was working with a
> Bio::DB:GFF backend database and was able to retrieve features from the
> database by feature name using the function 'get_feature_by_name()'. But
> recently, when I made the switch to Bio::DB::SeqFeature::Store to store the
> exact same data points as before in the new db, invoking the
> 'get_feature_by_name()' function returns nothing.
>
> Please refer to the following code snippet which is supposed to retrieve a
> certain gene "locus" feature from the backend database and use that to get
> the 'start' and 'end' coordinate of the feature based on the 'strand' on
> which it is present.
>
> my ($locus_obj, $gene_models) = get_annotation_db_features($locus,
> $gff_dbh);
>
> sub get_annotation_db_features {
>    my ($locus, $gff_dbh) =  <at> _;
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Fields, Christopher J | 1 Feb 2012 16:37
Favicon
Gravatar

Re: Running into problems

That looks like a bug to me, but it's hard to say w/o having more information, such as the actual code you are
using, the version of BioPerl, etc.  See the BioPerl FAQ to get the version number.

chris

On Feb 1, 2012, at 8:33 AM, Bradyjoel wrote:

> 
> Thank you for your help! I think I'm almost there, but I still get 1 more
> error when I run the script:
> 
> $ perl blast2.pl
> Searching gi|146341649|ref|YP_001206697.1|
> Undefined subroutine &main::hsp_filter called at
> /usr/share/perl5/Bio/SearchIO/Writer/TextResultWriter.pm line 298, <GEN6>
> line 71.
> 
> 
> Smithies, Russell wrote:
>> 
>> I'd probably cheat a bit and optimise my blast parameters so there's less
>> output to process.
>> Also, are you sure an e-value of 100 is what you're after? I'd be aiming
>> much lower - probably 1e-6.
>> It also pays to mask repeats if you're blasting against a whole genome to
>> cut down on the number of rubbish hits.
>> 
>> --Russell
>> 
>>> -----Original Message-----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vivek Krishnakumar | 1 Feb 2012 16:50
Picon

Re: `get_feature_by_name` not working after migrating to Bio::DB::SeqFeature::Store from a Bio::DB::GFF backend

Hi Lincoln,

Thanks very much for your suggestions. Not sure how the single quotation 
marks appeared around the $locus variable. But looks like it was only in 
the email. Fortunately did not have quotes around the variable in my 
original code.

Now, when I switch over to 'get_features_by_name()', my script does not run 
to completion.

I want to mention that this snippet of code is part of a larger CGI script 
that interfaces with the SeqFeature backend DB. When I modify the function 
call to $gff_dbh->get_features_by_name($locus), the script just runs 
indefinitely and returns absolutely nothing. I did put in a warn statement 
to see if the correct locus ID is being passed to the function (I am able 
to see the warning message in my apache error log), which seems to be fine. 
But the moment it reaches the function call step, the CGI script freezes up 
and I am unable to do anything. It just ends up as a rogue process owned by 
the 'daemon' user and continues to use up a lot of memory.

I am using the following BioPerl modules in this CGI script:
use Bio::SeqIO;
use Bio::SearchIO;
use Bio::DB::SeqFeature::Store;
use Bio::SeqFeature::Generic;
use Bio::Graphics;
use Bio::Graphics::Feature;

Could any of these be interfering with get_features_by_name()?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Scott Cain | 1 Feb 2012 17:26
Favicon

Re: `get_feature_by_name` not working after migrating to Bio::DB::SeqFeature::Store from a Bio::DB::GFF backend

Hi Vivek,

I responded to your original email and I suspect you may have missed
it.  I'll copy it below.  Another few things: how does $locus get
populated?  Are you sure what you expect to be there is?

Also, to answer your question about the other bioperl modules you're
using: no, I don't think that's interfering.

Scott

------------------------------------------------
Hello Vivek,

In your GFF3, you don't have any features of class "Gene".  In GFF2,
the class was the text string that started the ninth column, like
this:

chr2   .  gene    30427563    30429139    .   -   .  Gene 35804

where the class would be Gene and the name (also called group) would
be 35804.  Class is not a particularly well defined concept in GFF3,
so the easiest way to restore functionality to your script is to
change the call from this:

 my ($locus_obj) = $gff_dbh->get_feature_by_name('Gene' => $locus);

to this:

 my ($locus_obj) = $gff_dbh->get_features_by_name(-name => $locus,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bradyjoel | 1 Feb 2012 17:47
Picon

Re: Running into problems


the bioperl version that I have found with this command is:
$ perl -MBio::Root::Version -e 'print $Bio::Root::Version::VERSION,"\n"'
1.006901
$  perl -MBio::Root::Version -e 'printf "%vd\n",
$Bio::Root::Version::VERSION'
49.46.48.48.54.57.48.49

And I put the perl code that I'm currently using in the attachment. 

Fields, Christopher J wrote:
> 
> That looks like a bug to me, but it's hard to say w/o having more
> information, such as the actual code you are using, the version of
> BioPerl, etc.  See the BioPerl FAQ to get the version number.
> 
> chris
> 
> On Feb 1, 2012, at 8:33 AM, Bradyjoel wrote:
> 
>> 
>> Thank you for your help! I think I'm almost there, but I still get 1 more
>> error when I run the script:
>> 
>> $ perl blast2.pl
>> Searching gi|146341649|ref|YP_001206697.1|
>> Undefined subroutine &main::hsp_filter called at
>> /usr/share/perl5/Bio/SearchIO/Writer/TextResultWriter.pm line 298, <GEN6>
>> line 71.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vivek Krishnakumar | 1 Feb 2012 17:51
Picon

Re: `get_feature_by_name` not working after migrating to Bio::DB::SeqFeature::Store from a Bio::DB::GFF backend

Hi Scott,

Thanks very much for your suggestions. Looks I did miss it somehow
(confusion was caused because I was using both bioperl-l <at> googlegroups and
bioperl-l <at> open-bio)

Anyway, I had modified my function exactly like your suggestion:
my ($locus_obj) = $gff_dbh->get_features_by_name(-name => $locus, -type =>
'gene');

But doing so just returns the following error:

-------------------- EXCEPTION --------------------
MSG: segment() called in a scalar context but multiple features match.
Either call in a list context or narrow your search using the -types
or -class arguments

STACK Bio::DB::SeqFeature::Store::segment
/usr/local/packages/perl-5.10.1/lib/5.10.1/Bio/DB/SeqFeature/Store.pm:1322
STACK main::get_annotation_db_features
/opt/www/medicago/cgi-bin/medicago/eucap/eucap.pl:899
STACK main::structural_annotation
/opt/www/medicago/cgi-bin/medicago/eucap/eucap.pl:660
STACK toplevel /opt/www/medicago/cgi-bin/medicago/eucap/eucap.pl:119
-------------------------------------------

which would suggest to oneself that there are several such features with
the same ID. But in fact, I was able to verify by querying the database
that I have only one such locus.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane