You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As found in discussion of #49 blast results against databases created with makeblastdb and the -parse_seqids option have the fasta ids in the <Hit_id> field instead of the <Hit_def> field. Currently TBro uses the <Hit_def> field to look for the id. As a <Hit_id> is always present (even when parse_seqids was not used, then it is randomly generated) it is not possible to check whether this option has been set.
Therefore for now it is necessary to execute makeblastdb without the parse_seqids option or to duplicate all ids in the fasta file like this:
original.fa:
>id123 some description
new.fa:
>id123 id123 some description
For TBro 1.2.0 the behavior should be changed to use the <Hit_id> and therefore require makeblastdb to be executed with parse_seqids option. This behavior is more intuitive.
The text was updated successfully, but these errors were encountered:
As found in discussion of #49 blast results against databases created with
makeblastdb
and the-parse_seqids
option have the fasta ids in the<Hit_id>
field instead of the<Hit_def>
field. Currently TBro uses the<Hit_def>
field to look for the id. As a<Hit_id>
is always present (even whenparse_seqids
was not used, then it is randomly generated) it is not possible to check whether this option has been set.Therefore for now it is necessary to execute
makeblastdb
without theparse_seqids
option or to duplicate all ids in the fasta file like this:original.fa
:new.fa
:For TBro 1.2.0 the behavior should be changed to use the
<Hit_id>
and therefore requiremakeblastdb
to be executed withparse_seqids
option. This behavior is more intuitive.The text was updated successfully, but these errors were encountered: