text: user842: I used blastn to search one a genome database for the sequences in a file. 
  blastn -out output.txt -outfmt 6 -query sequence_list -db genome_database -perc_identity 100
  
  These sequences are all from one contig of the genome so the output was all hits in one contig. I then appended more sequences to the sequence file and used blastn again. However the weird thing is the output did not start with the same hits as the last blast. I expected if blastn iterated through sequences in a query file that it would output the original sequences first then go through the appended sequences. Since this was not the case, how does blast order its output?
  I also checked if it was sorted by which contig the hit was in and this is not the case. 
  
  user929: Edit I stand corrected. @Daniel Standage correctly pointed out that the below is only true for a single query, or for the sorting of hits within those found by a given query. Otherwise they're sorted in the order they were given.
  BLAST results are sorted in descending order by the "Bit score" (column 12). Sorting by E. value would not be quite the same.
  i.e. column 11 (E value) will be presented in ascending order (an E. value of 0 is as good as it gets), and as it gets higher, your hit is getting worse. Likewise, bitscores are highest at the top and decrease down the list. A hit with E. value = 0 should have a high score. How high exactly depends on the hit length, so it's common to see many E values with 0.0, but the scores differ. Here's a snippet of one of my blast results:
  PVCcif_ATCC43949  PAU_06042014  100.000  24180  0     0   1      24180  2233012  2257191  0.0  43606
  PVCcif_ATCC43949  PAU_06042014  78.098   5593   1164  16  2765   8323   3219956  3225521  0.0  4547
  PVCcif_ATCC43949  PAU_06042014  77.549   5394   1139  16  2948   8323   2376163  2370824  0.0  4260
  PVCcif_ATCC43949  PAU_06042014  74.140   5669   1342  34  8490   14100  3225688  3231290  0.0  3573
  PVCcif_ATCC43949  PAU_06042014  76.835   3665   825   9   16507  20150  3234191  3237852  0.0  2764
  PVCcif_ATCC43949  PAU_06042014  76.871   2646   571   11  16625  19248  2362597  2359971  0.0  2001
  PVCcif_ATCC43949  PAU_06042014  70.733   4131   1005  51  9047   13063  2368869  2364829  0.0  1954
  PVCcif_ATCC43949  PAU_06042014  75.040   1891   448   7   8500   10383  2370771  2368898  0.0  1272
  PVCcif_ATCC43949  PAU_06042014  78.986   1361   269   7   22766  24119  890051   891401   0.0  1150
  PVCcif_ATCC43949  PAU_06042014  77.819   1082   217   5   536    1610   3217983  3219048  0.0  868
  
  As you can see, they all have E values of 0.0, but they differ quite a lot in score, this is because of the length of the alignment, and the different percentage IDs.
  
  user96: BLASTN should definitely report alignments in the order that the query sequences were provided.
  Based on your description and my personal experience, I think the most likely explanation is some kind of mix up. It happens to all of us, especially when we're in a rush to get an answer, but even sometimes when we're being careful and disciplined.
  If you can go back and recreate the result, I would be very interested to see the two pairs of input and output files. If not, I wouldn't spend too much more time worrying about it. :-)
  UPDATE Alignments are reported in the order that the query sequences are provided, even in tabular mode. The order of each query's hits is sorted by bitscore or e-value, but that is a secondary sorting. I've included an example below that has two queries, seq1 and seq2 with -outfmt 6.
  seq1    scaffold2       100.000 280     0       0       1       280     11131   11410   7.73e-146       518
  seq1    scaffold294     88.693  283     25      4       1       279     12160   12439   6.46e-92        339
  seq1    scaffold1525    85.315  286     29      9       1       277     27142   26861   3.07e-75        283
  seq1    scaffold1874    83.505  291     32      10      1       280     8558    8273    1.86e-67        257
  seq1    scaffold147     82.653  294     34      9       1       279     10797   10506   1.45e-63        244
  seq1    scaffold2478    82.374  278     38      8       11      280     7622    7896    1.13e-59        231
  seq1    scaffold3405    87.940  199     17      5       1       196     14390   14584   1.46e-58        228
  seq1    scaffold395     83.060  183     23      4       106     280     12021   11839   5.40e-38        159
  seq1    scaffold2853    85.965  114     13      3       1       113     20864   20753   9.16e-26        119
  seq2    scaffold9       100.000 140     0       0       1       140     1121    1260    2.34e-68        259
  seq2    scaffold2950    90.909  110     6       3       1       106     110     1       6.84e-34        145
  seq2    scaffold3416    95.385  65      3       0       1       65      11882   11818   1.16e-21        104
  seq2    scaffold3103    95.385  65      3       0       1       65      9736    9672    1.16e-21        104
  seq2    scaffold5297    88.608  79      7       1       64      140     150     228     6.99e-19        95.3
  
  
original_text: 842: <p>I used blastn to search one a genome database for the sequences in a <a href="http://ix.io/xFG" rel="nofollow noreferrer">file</a>. </p>
  
  <pre><code>blastn -out output.txt -outfmt 6 -query sequence_list -db genome_database -perc_identity 100
  </code></pre>
  
  <p>These sequences are all from one contig of the genome so the output was all hits in one contig. I then <strong>appended</strong> more sequences to the sequence file and used blastn again. However the weird thing is the output did not start with the same hits as the last blast. I expected if blastn iterated through sequences in a query file that it would output the original sequences first then go through the appended sequences. Since this was not the case, how does blast order its output?</p>
  
  <p>I also checked if it was sorted by which contig the hit was in and this is not the case. </p>
   929: <p><strong>Edit</strong> I stand corrected. @Daniel Standage correctly pointed out that the below is only true for a single query, or for the sorting of hits within those found by a given query. Otherwise they're sorted in the order they were given.</p>
  <p>BLAST results are sorted in descending order by the &quot;Bit score&quot; (column 12). Sorting by E. value would not be quite the same.</p>
  <p>i.e. column 11 (E value) will be presented in ascending order (an E. value of 0 is as good as it gets), and as it gets higher, your hit is getting worse. Likewise, bitscores are highest at the top and decrease down the list. A hit with E. value = 0 should have a high score. How high exactly depends on the hit length, so it's common to see many E values with 0.0, but the scores differ. Here's a snippet of one of my blast results:</p>
  <pre><code>PVCcif_ATCC43949  PAU_06042014  100.000  24180  0     0   1      24180  2233012  2257191  0.0  43606
  PVCcif_ATCC43949  PAU_06042014  78.098   5593   1164  16  2765   8323   3219956  3225521  0.0  4547
  PVCcif_ATCC43949  PAU_06042014  77.549   5394   1139  16  2948   8323   2376163  2370824  0.0  4260
  PVCcif_ATCC43949  PAU_06042014  74.140   5669   1342  34  8490   14100  3225688  3231290  0.0  3573
  PVCcif_ATCC43949  PAU_06042014  76.835   3665   825   9   16507  20150  3234191  3237852  0.0  2764
  PVCcif_ATCC43949  PAU_06042014  76.871   2646   571   11  16625  19248  2362597  2359971  0.0  2001
  PVCcif_ATCC43949  PAU_06042014  70.733   4131   1005  51  9047   13063  2368869  2364829  0.0  1954
  PVCcif_ATCC43949  PAU_06042014  75.040   1891   448   7   8500   10383  2370771  2368898  0.0  1272
  PVCcif_ATCC43949  PAU_06042014  78.986   1361   269   7   22766  24119  890051   891401   0.0  1150
  PVCcif_ATCC43949  PAU_06042014  77.819   1082   217   5   536    1610   3217983  3219048  0.0  868
  </code></pre>
  <p>As you can see, they all have E values of 0.0, but they differ quite a lot in score, this is because of the length of the alignment, and the different percentage IDs.</p>
   96: <p>BLASTN should definitely report alignments in the order that the query sequences were provided.</p>
  
  <p>Based on your description and my personal experience, I think the most likely explanation is some kind of mix up. It happens to all of us, especially when we're in a rush to get an answer, but even sometimes when we're being careful and disciplined.</p>
  
  <p>If you can go back and recreate the result, I would be very interested to see the two pairs of input and output files. If not, I wouldn't spend too much more time worrying about it. :-)</p>
  
  <p><strong>UPDATE</strong> Alignments are reported in the order that the query sequences are provided, even in tabular mode. The order of each query's hits is sorted by bitscore or e-value, but that is a secondary sorting. I've included an example below that has two queries, <code>seq1</code> and <code>seq2</code> with <code>-outfmt 6</code>.</p>
  
  <pre><code>seq1    scaffold2       100.000 280     0       0       1       280     11131   11410   7.73e-146       518
  seq1    scaffold294     88.693  283     25      4       1       279     12160   12439   6.46e-92        339
  seq1    scaffold1525    85.315  286     29      9       1       277     27142   26861   3.07e-75        283
  seq1    scaffold1874    83.505  291     32      10      1       280     8558    8273    1.86e-67        257
  seq1    scaffold147     82.653  294     34      9       1       279     10797   10506   1.45e-63        244
  seq1    scaffold2478    82.374  278     38      8       11      280     7622    7896    1.13e-59        231
  seq1    scaffold3405    87.940  199     17      5       1       196     14390   14584   1.46e-58        228
  seq1    scaffold395     83.060  183     23      4       106     280     12021   11839   5.40e-38        159
  seq1    scaffold2853    85.965  114     13      3       1       113     20864   20753   9.16e-26        119
  seq2    scaffold9       100.000 140     0       0       1       140     1121    1260    2.34e-68        259
  seq2    scaffold2950    90.909  110     6       3       1       106     110     1       6.84e-34        145
  seq2    scaffold3416    95.385  65      3       0       1       65      11882   11818   1.16e-21        104
  seq2    scaffold3103    95.385  65      3       0       1       65      9736    9672    1.16e-21        104
  seq2    scaffold5297    88.608  79      7       1       64      140     150     228     6.99e-19        95.3
  </code></pre>
  