Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T14:34:07.540Z
Answers.Text: 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.
Answers.UserDisplayName: OrdiNeu
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T14:46:19.340Z
Answers.Text: @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
Answers.UserDisplayName: llrs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T14:50:53.553Z
Answers.Text: @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.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:10:17.070Z
Answers.Text: 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`)
Answers.UserDisplayName: Chris_Rands
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:11:18.063Z
Answers.Text: @Chris_Rands curiouser and curiouser. But that makes it even more likely that this is a bug.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:12:26.780Z
Answers.Text: @terdon Yes, can you replicate what I described?
Answers.UserDisplayName: Chris_Rands
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:18:45.570Z
Answers.Text: @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.
Answers.UserDisplayName: TW93
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:26:19.960Z
Answers.Text: @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.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T15:27:06.090Z
Answers.Text: @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.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-21T14:18:48.550Z
Answers.LastActivityDate: 2017-09-21T14:18:48.550Z
Answers.UserDisplayName: terdon
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-21T13:32:09.300Z
Comments.Text: 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.
Comments.UserDisplayName: terdon
Tags: <fasta><blast>
Title: Why is this makeblastdb command not working?
ThreadText: # 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**: @username_2 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**: @username_2 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**: @username_4 curiouser and curiouser. But that makes it even more likely that this is a bug.  
  > **username_4**: @username_1 Yes, can you replicate what I described?  
  > **username_0**: @username_1 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**: @username_4 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**: @username_0 you're welcome. I know how you feel. I'd have wondered about my own sanity too had I encountered this in the wild.  
  
  ---
  
  