zzh
/
gatk-3.8
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

As per the comments in the commit itself: when reads get mapped to the junction of two chromosomes (e.g. MT since it is actually circular DNA), their unmapped bit is set, but they are given legitimate coordinates. The Picard code will come in and move the read all the way back to its mate - which can be arbitrarily far away and cause records to be written out of order. Very evil. 

git-svn-id: file:///humgen/gsa-scr1/gsa-engineering/svn_contents/trunk@5484 348d0f76-0448-11de-a6fe-93d51630548a
This commit is contained in:
ebanks 2011-03-21 20:30:24 +00:00
parent f6d4b0aaf5
commit ab6a815184
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
java/src/org/broadinstitute/sting/gatk/walkers/indels/ConstrainedMateFixingManager.java
View File

@ -197,13 +197,19 @@ public class ConstrainedMateFixingManager {
if ( newRead.getReadPairedFlag() ) {
SAMRecord mate = forMateMatching.get(newRead.getReadName());
if ( mate != null ) {
// Frustratingly, Picard's setMateInfo() method unaligns (by setting the reference contig
// 1. Frustratingly, Picard's setMateInfo() method unaligns (by setting the reference contig
// to '*') read pairs when both of their flags have the unmapped bit set. This is problematic
// when trying to emit reads in coordinate order because all of a sudden we have reads in the
// middle of the bam file that now belong at the end - and any mapped reads that get emitted
// after them trigger an exception in the writer. For our purposes, because we shouldn't be
// moving read pairs when they are both unmapped anyways, we'll just not run fix mates on them.
boolean doNotFixMates = newRead.getReadUnmappedFlag() && mate.getReadUnmappedFlag();
// 2. Furthermore, when reads get mapped to the junction of two chromosomes (e.g. MT since it
// is actually circular DNA), their unmapped bit is set, but they are given legitimate coordinates.
// The Picard code will come in and move the read all the way back to its mate (which can be
// arbitrarily far away). However, we do still want to move legitimately unmapped reads whose
// mates are mapped, so the compromise will be that if the mate is still in the queue then we'll
// move the read and otherwise we won't.
boolean doNotFixMates = newRead.getReadUnmappedFlag() && (mate.getReadUnmappedFlag() || !waitingReads.contains(mate));
if ( !doNotFixMates ) {
boolean reQueueMate = mate.getReadUnmappedFlag() && ! newRead.getReadUnmappedFlag();