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.
As found in discussion of #49 blast results against databases created with
makeblastdband the-parse_seqidsoption 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_seqidswas 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 executemakeblastdbwithout theparse_seqidsoption 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 requiremakeblastdbto be executed withparse_seqidsoption. This behavior is more intuitive.