I am completely mystified by this very basic asymmetry in blastn results. I have two FASTA files, which share a 15-mer. However, that common 15-mer only results in a hit if I have one file as subject and the other as query; if I reverse the files, no hit:
$ blastn -task blastn-short -outfmt 6 -ungapped -strand plus -perc_identity 100 -word_size 15 \
-query Phvul.007G125800.5.0kb.upstream.fasta \
-subject Phvul.009G200800.5.0kb.upstream.fasta
Phvul.007G125800 Phvul.009G200800 100.00 15 0 0 3698 3712 1965 1979 0.020 30.2
$ blastn -task blastn-short -outfmt 6 -ungapped -strand plus -perc_identity 100 -word_size 15 \
-query Phvul.009G200800.5.0kb.upstream.fasta \
-subject Phvul.007G125800.5.0kb.upstream.fasta
$
This is highly reproducible and has some consistency. I've got five 5000-nt sequences, all of which share this same 15-mer. When I use two of them as query sequences, I get the 15-mer hit in all cases. When I use the other three as query sequences, I never get the 15-mer hit. If I blast just the 15-mer by itself against the sequences, I get the hit on all sequences.
Any ideas what's going on? This behavior is independent of word_size, by the way, all the way down to 8. I find this very disconcerting, since I thought that blastn would be symmetric w.r.t. query and subject, at least when they're the same size.
2 answers
This thread explains it quite nicely
It turns out that query size really matters in BLAST. I've done some testing with my 5000nt sequences, and in some cases I've had to narrow the query_loc range down to 56nt to capture a hit against a common 16-mer! Furthermore, in one case, there is only a range of five starting positions in query_loc range that will result in the hit. This is very restrictive!
To put my example in numbers so it's clear: I have a 5000nt query sequence with a 16-mer motif at 1965-1980 which is shared by another 5000nt subject sequence. The only range of query_loc that results in a successful hit of this 16-mer against the subject using the experimentally-determined maximum length of 56 is: 1962-2017, 1963-2018, 1964-2019, 1965-2020 and 1966-2021. Outside those query_loc ranges, blast does not find the match.
I haven't been able to find any BLAST parameters that improve this situation, but if you know of something to try, please let me know! This narrow restriction on the size of the query is a show-stopper for doing the analysis with BLAST.
Log in to answer this question.
-
Blast command use
written by harry •
-
Error when using blastn in biopython
written by Hood •
-
Blastn .XML to FASTA
written by baurumon •
-
Cannot reproduce BLAST results returned by the WEB API on the shell-based BLAST+ 2.7.1
written by xerygi •
-
Pass query and subject as string instead of files to blastn
written by juan.crescente •
-
Short Blast with Gaps
written by corvusvordan •
-
Blastn for Short Sequences
written by shahbazmunir11 •
-
Showing the original subject when running BLAST
written by kdsilva •
-
Number of Blast hits for multiple sequence fasta
written by mosquitoes •
-
Blast - Formatting Output
written by timjoncooper
And since you were about to ask, this behavior is reproduced in versions 2.2.31+ (commonly found in distros) and the latest from NCBI, 2.5.0+.
Quite interesting. I have not tested and am guessing but the only thing that is different is the database-size and thereby the e-value. The default cutoff is 10 which is high to being with so this could not be the reason. But can you please check with evalue cutoff of more than 10 specified. I still use the legacy blast and not the new one and am only guessing.