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

<pre><code>&gt;K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48 nt|3| | | |15 AA|15+0=15
</code></pre>

<p>So does removing everything after the 1st space:</p>

<pre><code>&gt;K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48
</code></pre>

<p>There is nothing in the FASTA definition that would explain this and, even more weirdly, the presence of the <code>| | |</code> 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 <code>+</code> or <code>-</code>along with empty <code>| |</code>, but there's no clear pattern I can see:</p>

<p>These fail:</p>

<pre><code>&gt;| | |15-| | |
&gt;| | |15+| | |
&gt;| | |15-1| | |
&gt;| | |15+1| | |
</code></pre>

<p>These work:</p>

<pre><code>&gt;| |15+| |
&gt;| | |151| | |
</code></pre>

<p>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:</p>

<pre><code>awk '{print $1}' fasta.fa &gt; new.fa
</code></pre>

<p>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. </p>

CC BY-SA 3.0
2017-09-21T14:34:07.540Z
I'm not convinced that this is a bug per se -- FASTA headers can use any combination of [these specific identifiers](https://www.ncbi.nlm.nih.gov/books/NBK21097/table/A632/?report=objectonly). 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.
OrdiNeu
CC BY-SA 3.0
2017-09-21T14:46:19.340Z
@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
llrs
CC BY-SA 3.0
2017-09-21T14:50:53.553Z
@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.
terdon
CC BY-SA 3.0
2017-09-21T15:10:17.070Z
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`)
Chris_Rands
CC BY-SA 3.0
2017-09-21T15:11:18.063Z
@Chris_Rands curiouser and curiouser. But that makes it even more likely that this is a bug.
terdon
CC BY-SA 3.0
2017-09-21T15:12:26.780Z
@terdon Yes, can you replicate what I described?
Chris_Rands
CC BY-SA 3.0
2017-09-21T15:18:45.570Z
@terdon That's ahem... interesting! The 3 empty columns can be found in the other IMGT sequence headers, which were parsed successfuly- whereas the numerics with +/- are only found in the problem file which does place the blame firmly at their door. It also still doesn't work when leaving out the -parseseq_id flag. Will report it. Thanks for maintaining my sanity.
TW93
CC BY-SA 3.0
2017-09-21T15:26:19.960Z
@Chris_Rands yes and no. The one you say works, kinda works on my system but complains about `BLAST Database creation error: Defline lacks a proper ID around line 1`. Changing the defline to `>a| | |151| | |`, however, reproduces what you describe perfectly: sequence `ATGAAGAG` fails but sequence `ATGAAGAG\nATG` works. Weird.
terdon
CC BY-SA 3.0
2017-09-21T15:27:06.090Z
@TW93 you're welcome. I know how you feel. I'd have wondered about my own sanity too had I encountered this in the wild.
terdon
CC BY-SA 3.0
2017-09-21T14:18:48.550Z
2017-09-21T14:18:48.550Z
terdon
<p>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.</p>

<p>They take the format below:</p>

<pre><code>&gt;K02545|TRBJ1-1*01|Homo sapiens|F|J-REGION|749..796|48 nt|3| | | |15 AA|15+0=15| | |
NTEAFFGQGTRLTVV
</code></pre>

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

<pre><code>makeblastdb -in TRBJ_AA.fa -parse_seqids -dbtype prot
</code></pre>

<p>and I get the following error message:</p>

<pre><code>BLAST options error: TRBJ_AA.fa does not match input format type, default input type is FASTA
</code></pre>

<p>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?</p>

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

<p>Thank you.</p>

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

CC BY-SA 3.0
2017-09-21T13:32:09.300Z
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.
terdon
<fasta><blast>
Why is this makeblastdb command not working?
# Why is this makeblastdb command not working?

(Asked by: username_0 on 2017-09-21)

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| | |
NTEAFFGQGTRLTVV

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.

**Tags:** fasta, blast
> **Comments:**
> **username_1**: 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.  

---

## 1 answers

### Answer by username_1 on 2017-09-21. Score: 8 | Accepted answer

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.

> **Comments:**
> **username_2**: I'm not convinced that this is a bug per se -- FASTA headers can use any combination of [these specific identifiers](https://www.ncbi.nlm.nih.gov/books/NBK21097/table/A632/?report=objectonly). 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.  
> **username_3**: @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  
> **username_1**: @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.  
> **username_4**: 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`)  
> **username_1**: @Chris_Rands curiouser and curiouser. But that makes it even more likely that this is a bug.  
> **username_4**: @terdon Yes, can you replicate what I described?  
> **username_0**: @terdon That's ahem... interesting! The 3 empty columns can be found in the other IMGT sequence headers, which were parsed successfuly- whereas the numerics with +/- are only found in the problem file which does place the blame firmly at their door. It also still doesn't work when leaving out the -parseseq_id flag. Will report it. Thanks for maintaining my sanity.  
> **username_1**: @Chris_Rands yes and no. The one you say works, kinda works on my system but complains about `BLAST Database creation error: Defline lacks a proper ID around line 1`. Changing the defline to `>a| | |151| | |`, however, reproduces what you describe perfectly: sequence `ATGAAGAG` fails but sequence `ATGAAGAG\nATG` works. Weird.  
> **username_1**: @TW93 you're welcome. I know how you feel. I'd have wondered about my own sanity too had I encountered this in the wild.  

---

