search

bbuchfink / diamond

Accelerated BLAST compatible local sequence aligner.
GNU General Public License v3.0
1.07k stars 182 forks source link

v2.1.9 does not output `send` correctly when using long-read mode #791

Open xinehc opened 8 months ago

xinehc commented 8 months ago

v2.1.8:

diamond blastx -q GCF_000708165.1_E_coli_EC2.contigs_genomic.fna -d a.fasta --range-culling -F15 --outfmt 6 qseqid sseqid sstart send scovhsp
NZ_JFJL01000045.1   WP_000046661.1  1   109 100

v2.1.9:

diamond blastx -q GCF_000708165.1_E_coli_EC2.contigs_genomic.fna -d a.fasta --range-culling -F15 --outfmt 6 qseqid sseqid sstart send scovhsp
NZ_JFJL01000045.1   WP_000046661.1  1   0   100

The send column in v2.1.9 is always 0 (bug?). scovhsp seems correct.

thackl commented 7 months ago

I have the same problem. send is reported as 0 in v2.1.9.

@xinehc I think you accidentally put qend in the title of the issue.

Pooryamb commented 7 months ago

The same issue happened to me! send is 0

HillJamie commented 1 month ago

The problem is only present for BLAST output, not for PAF or SAM. It is likely related to the change from subject_range to subject_source_range for writing the send field. Perhaps subject_source_range is not even intialized when --long-reads is used?

Relevant lines: In 2.1.9 https://github.com/bbuchfink/diamond/blob/ba088282666c06db0665dafc4851df45eae701f6/src/output/blast_tab_format.cpp#L277

In 2.1.8 https://github.com/bbuchfink/diamond/blob/03e7f4a77b36e7500f6856cd15a05771c1c731fb/src/output/blast_tab_format.cpp#L264

bbuchfink commented 1 month ago

It will be fixed in the next release.