Skip to content
This repository has been archived by the owner on Oct 12, 2018. It is now read-only.

error parsing BAM long-ranger aligned files #8

Open
mcieslik-mctp opened this issue Jan 5, 2018 · 6 comments
Open

error parsing BAM long-ranger aligned files #8

mcieslik-mctp opened this issue Jan 5, 2018 · 6 comments

Comments

@mcieslik-mctp
Copy link

When running extract-sv-reads on a long-ranger aligned BAM file, the program quits immediately with the following message:

ERROR: Error parsing position from SA tag hs38d1,-1,-,42S108M,0,15

It appears that this matches the SAM SA tag spec's, although the -1 pos looks suspicious.

(rname ,pos ,strand ,CIGAR ,mapQ ,NM ;)+

The same file aligned with BWA-MEM causes no problems, so it may be considered actually a bug in long-ranger....

Thanks!

@ernfrid
Copy link
Contributor

ernfrid commented Jan 5, 2018

I've seen this once before internally, but hadn't followed up. I'm not sure how to interpret that SA tag.

I just opened an issue with the 10x folks on their aligner repository and hopefully will get an answer on this point.

@mcieslik-mctp
Copy link
Author

this simple patch seems to work-around the problem it, not sure if it is a proper solutin:

diff --git a/src/lib/extract_sv_reads/Alignment.hpp b/src/lib/extract_sv_reads/Alignment.hpp
index 9dc582c..ac0fa4e 100644
--- a/src/lib/extract_sv_reads/Alignment.hpp
+++ b/src/lib/extract_sv_reads/Alignment.hpp
@@ -13,8 +13,8 @@ using boost::format;
 
 struct Alignment {
     AlignmentOffsets offsets;
-    uint32_t pos; //1-based start position of the alignment
-    uint32_t rapos;
+    int32_t pos; //1-based start position of the alignment
+    int32_t rapos;
     int SQO;
     int EQO;
     char strand;
@@ -31,7 +31,7 @@ struct Alignment {
     {}
 
     Alignment(bam1_t const* aln, bam_hdr_t const* hdr) {
-        rapos = aln->core.pos + 1;
+       rapos = aln->core.pos < 0 ? 1 : aln->core.pos + 1;
         chrom = std::string(hdr->target_name[aln->core.tid]);
         offsets = AlignmentOffsets(bam_get_cigar(aln), aln->core.n_cigar);
         if (bam_is_rev(aln)) {

@ernfrid
Copy link
Contributor

ernfrid commented Jan 5, 2018

Yes, that will allow you to proceed and I would probably do something similar if that's how they're supposed to be interpreted. A position of 0 in 1-based coordinates indicates an unmapped alignment though and I don't think that will be properly handled currently. It also begs the question whether all Lariat SA tags are reporting 0-based coordinates instead of 1-based coordinates...

@ernfrid
Copy link
Contributor

ernfrid commented Jan 13, 2018

Just an update on this, I did receive acknowledgement from 10x that they'd seen my report and look into it, but no additional information thus far.

@ernfrid
Copy link
Contributor

ernfrid commented Jan 24, 2018

I've heard back from 10X.

We have identified a bug, and it will be fixed in the next version of longranger, which should be out in a month or so.

The bug was that we should not have been outputting those secondary alignments (SA tag), since longranger determined they are not valid alignments.

I've pushed a potential fix to the skip_bad_sa branch. I still need to do testing to ensure that it works however.

@ernfrid
Copy link
Contributor

ernfrid commented Jan 26, 2018

@mcieslik-mctp - I've done some unit-testing and speed testing on the patch and it seems ok. I'm waiting to hear back from @kmsteinberg for some internal testing before releasing. If you want to give it a try as well, I'd be grateful for any feedback in advance of a release.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants