blastn: restrict output to same length as query

[Mimoeschen]

Hi,

I would like to filter my blastn output to look at hits in their full length relative to the query, not just including the matching part.

One way, I came up with, is to filter all output to have the same length (or longer) as the query sequence.
Alternatively it would help me very much, if there was a way to calculate the perc_identity relative to to the whole length of the query and not to just to the match.
Is there a way, that I can play with word_size to allow mismatches? Then I could just set the word_size to the query length...
(in my case, just mismatches are important, I would not allow for insertions or deletions anyway)

Does anybody have an idea, how I could solve this, or how I can practically implement the ideas that I had?

Thank you very much!

[Rhizosis]

Well the problem you are facing lies in the core foundation of how the blast algorithms and scoring matrices work. Blast already searches for the most optimal alignment without taking too big of a scoring penalty (mismatches, gaps and extensions thereof).
In other words, you will have to store the length of the query sequence you are inputting and subtract the length of the actual match.
That difference in of query not being matched (pre and post blast) could be counted as 'non-identical'. If you start allowing more mismatches and introduce a lower gap penalty you might be able to match a larger portion of the sequence.

Good luck.

[Mimoeschen]

Thank you very much Rhizosis!

I have changed my strategy now to allow more than one match and filter by length afterwards. Since I have multiple query sequences, the files get huge, but I guess there is no way around it...

[Rhizosis]

No problem.
To minimize the amount of results in your blast output, you maybe can dynamically set the min. alignment length flag for each blast. Foreach accession entry in the input, measure the length of the hit you would like to obtain and set that length as the flag argument in blast.
This would mean that you would have to cut up the large input fasta file into single accession entry fasta files.

This is just a thought however and I dont know if its applicable to your situation.

Good luck