I am trying to make local databases for the ncbi-blast+ package (version 2.60). I am doing so for 4 T-cell receptor genes. 3 of the 4 (TRAV, TRAJ, TRBV) have worked fine, but I am having problems with TRBJ. I say this because they should be the same format and if one works the rest works.

They take the format below:

>K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48 nt|3| | | |15 AA|15+0=15| | |

I used the following command (like I say, it was fine for the rest, oddly enough):

makeblastdb -in TRBJ_AA.fa -parse_seqids -dbtype prot

and I get the following error message:

BLAST options error: TRBJ_AA.fa does not match input format type, default input type is FASTA

One issue I checked was the length of the sequences being too short, but I believe 11 is the minimum length required (for inputs, don't know if that is the same for databases)- but would someone be able to confirm, that strikes me as the most likely candidate?

I'm happy to use some other metric, but I was hoping on keeping BLAST for consistency's sake for the time being.

Thank you.

edit: I know it's to late, but for reference I'm on Ubuntu 16.04.2 LTS x86_64 for all steps.

  • 1
    $\begingroup$ What operating system are you running this on and what operating system was the input file created on? Also, please edit your question and show us the actual file you are using. $\endgroup$
    – terdon
    Commented Sep 21, 2017 at 13:32

1 Answer 1


This looks like a bug in makeblastdb. Removing the final | | | from your sequence's description makes it work:

>K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48 nt|3| | | |15 AA|15+0=15

So does removing everything after the 1st space:

>K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48

There is nothing in the FASTA definition that would explain this and, even more weirdly, the presence of the | | | alone isn't enough to trigger the issue. I played around with this a little and it looks like it doesn't like the combination of + or -along with empty | |, but there's no clear pattern I can see:

These fail:

>| | |15-| | |
>| | |15+| | |
>| | |15-1| | |
>| | |15+1| | |

These work:

>| |15+| |
>| | |151| | |

So yeah, sounds like a bug. I suggest you report it to the NCBI devs. In the meantime, a simple fix would be to just keep the first space-separated field of your fasta header. Pass your fasta file through this:

awk '{print $1}' fasta.fa > new.fa

That will print the 1st field of each line and, assuming you don't have spaces in your sequence, it should effectively sort this out for you.

  • 1
    $\begingroup$ I'm not convinced that this is a bug per se -- FASTA headers can use any combination of these specific identifiers. It's parsing it somehow (assuming it's figuring out which of the possible identifiers to use based the parsing the + and - as strings), but it must be getting confused by the addition of three empty columns. $\endgroup$
    – OrdiNeu
    Commented Sep 21, 2017 at 14:34
  • 1
    $\begingroup$ @OrdiNeu what it is after > is left for the user to decide if NCBI decides to add these identifiers or more is their own decision but it should be able to work with other identifiers $\endgroup$
    – llrs
    Commented Sep 21, 2017 at 14:46
  • 1
    $\begingroup$ @OrdiNeu the FASTA format itself allows anything you care to put there. The identifiers you linked to are just what NCBI tends to use in its FASTA files, but they have nothing to do with the FASTA format. If a program expects a specific format, then the program is buggy. The fact that there's no clear pattern and that the issue occurs both with and without the -parse_seqids flag is further indication of a bug. $\endgroup$
    – terdon
    Commented Sep 21, 2017 at 14:50
  • 1
    $\begingroup$ Oddly I found on my system that whether or not it 'works' also depends on the sequence lines. For example, take header >| | |151| | | and sequence ATGAAGAG it fails, with ATGAAGAG\nATG it works (in both cases running makeblastdb -dbtype nucl -in my_fasta.fa) $\endgroup$ Commented Sep 21, 2017 at 15:10
  • 1
    $\begingroup$ @Chris_Rands curiouser and curiouser. But that makes it even more likely that this is a bug. $\endgroup$
    – terdon
    Commented Sep 21, 2017 at 15:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.