Manta crashes on input files realigned with ABRA
MagdalenaFeldhahn opened this issue · 7 comments
We observed that MantaSV crashes on some input files that were previously realigned using ABRA2 (https://github.com/mozack/abra2).
For details see error message pasted below. We are using manta version 1.4.0.
The problem seems to be single reads where ABRA produces "unexpected alignment patterns".
Problematic alignment patters and with an insertion.
When we manually exclude the problematic reads, manta completes successfully and the expected translocation is called.
It would be nice to be able to apply manta in a pipeline on files realigned with ABRA.
Would it be possible to allow such alignment patterns, or issuing a warning and ignore those reads?
If you have concerns using a warning (that might be ignored ba users), could you provide a command line option so the user can deliberately ignore such reads?
Kind regards and thank you for your help.
Magdalena
Error Message:
Workflow terminated due to the following task errors:
Failed to complete command task: 'makeLocusGraph_chromId_003_chr4_0004' launched from master workflow, error code: 1, command: 'manta-1.4.0.centos6_x86_64/libexec/EstimateSVLoci --output-file ABRA/manta1.4/workspace/svLocusGraph.bin.tmpdir/svLocusGraph.chromId_003_chr4_0004.bin --align-stats ABRA/manta1.4/workspace/alignmentStats.xml --region chr4:47788573-59735714 --min-candidate-sv-size 8 --min-edge-observations 3 --ref human_hg19.fa --tumor-align-file DS000013_018R0_S000013_development_merged.bam'
[makeLocusGraph_chromId_003_chr4_0004] Error Message:
[makeLocusGraph_chromId_003_chr4_0004] Last 11 stderr lines from task (of 11 total lines):
ERROR: Exception caught while processing single read record:
A00182:125:HFMLNDMXX:1:2154:30038:31250/2 tid:pos:strand 3:55602753:+ cigar: 99M32D2I templSize: 135 mate_tid:pos:strand 3:55602787:-
FATAL_ERROR: 2018-Jun-18 10:14:23 /builder/src/c++/lib/manta/SVLocusScanner.cpp(454): Throw in function void getSVCandidatesFromReadIndels(const ReadScannerOptions&, const ReadScannerDerivOptions&, const SimpleAlignment&, const bam_header_info&, SourceOfSVEvidenceInDNAFragment::index_t, std::vector&)
Dynamic exception type: boost::exception_detail::clone_implillumina::common::GeneralException
std::exception::what: Can't process unexpected alignment pattern: alignment: 3:55602753+ 99M32D2I
cmdline: manta-1.4.0.centos6_x86_64/libexec/EstimateSVLoci --output-file ABRA/manta1.4/workspace/svLocusGraph.bin.tmpdir/svLocusGraph.chromId_003_chr4_0004.bin --align-stats ABRA/manta1.4/workspace/alignmentStats.xml --region chr4:47788573-59735714 --min-candidate-sv-size 8 --min-edge-observations 3 --ref human_hg19.fa --tumor-align-file DS000013_018R0_S000013_merged.bam
version: 1.4.0
buildTime: 2018-04-26T23:54:06.820784Z
compiler: g++-6.3.1
Thanks for the detailed error report!
The exception thrown was due to the read end aligned with combined insertion/deletion, instead of being softclipped (or mismatched).
Can't process unexpected alignment pattern: alignment: 3:55602753+ 99M32D2I
Did the aligner allow softclips at the mismatched end? Was the aligner set up to prefer big gaps rather than mismatches?
Thank you for your reply.
We used ABRA2 to realign the bam files.
“ABRA is a realigner for next generation sequencing data. It uses localized assembly and global realignment to align reads more accurately, thus improving downstream analysis (detection of indels and complex variants in particular).”
The alignment pattern of the problematic read was changed by ABRA from softclips to the D-I-pattern. This is in agreement with the contig assembled locally by ABRA.
We would like to run such realigned bam-files through MANTA as they are without crashing, instead of “fixing” the unusual alignment pattern
Do you see a possibility to allow for such alignment patterns, or – to prevent MANTA from crashing – at least ignore such reads?
Kind regards and thank you for your support,
Magdalena
It's part of the alignment QC Manta relies on, given Manta doesn't try to re-align reads.
Although it might be possible to add a command-line argument to skip such reads, it is also a concern to have the number of arguments under control. I will leave this ticket open until we have a good solution for it.
For the time being, it might be a good idea to config the aligner to avoid such pattern, or to filter such reads out as you have done if aligner configuration is not an option.
Thank you for your quick reply.
Can you provide a list or description of allowed/valid alignment patterns, so that we can filter out reads that do not match these patterns? (A description or list of invalid patterns would work as well of course.)
Thank you and kind regards,
Magdalena
Currently the alignment pattern check is just for combined insertion/deletion at read ends.
If you identify any other error thrown by Manta after filter such reads from ABRA2 alignment, please let me know.
Hi, Just to follow up on this, these reads are valid, adhere to the SAM spec and can represent real variation. The specific use case is where there is a complex indel (sequence both inserted and deleted at the same locus) and the read partially overlaps the variant.
Can you clarify why Manta cannot proceed in the presence of these reads?
Thanks.
Hi @x-chen
I was re-visiting this issue recently. It looks like it was closed last year, but it's not clear what the correct solution is.
Currently the alignment pattern check is just for combined insertion/deletion at read ends.
If you identify any other error thrown by Manta after filter such reads from ABRA2 alignment, please let me know.
If the BAMs have undergone re-aligned with ABRA2, do you recommend that we filter out these reads? How would that affect the Manta outputs?
Do you explicitly recommend that we run Manta without doing re-alignment on the BAMs?
Thank you for the help, Evan