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

Fixed the bug reported on GS regarding a clipped read that got moved several hundred bases away. The code that got triggered here was written back in the original version of the cleaner and it never actually did the right thing. 

While I was fixing it, I noticed that we weren't allowing the cleaner to un-clean reads with indels when they're wrong even though we should.  Hypothetically, that should rarely happen: only when we can left-align out an indel or when the original mapper really went haywire.  This situation is rare enough that I'm calling logger.info to let the user know it's happening and suggesting that they double-check that everything looks right with their reads.  Better to be extra-cautious now that the cleaner is moving into the 1kg and Broad production pipelines soon
.
Mark, have no fear: this was truly a rare edge case - one that won't affect the cleaning stats.  There is no need to re-clean the data processing paper bams!



git-svn-id: file:///humgen/gsa-scr1/gsa-engineering/svn_contents/trunk@4057 348d0f76-0448-11de-a6fe-93d51630548a
This commit is contained in:
ebanks 2010-08-19 01:42:48 +00:00
parent 3dc4d3c3a9
commit 98f7679619
1 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
java/src/org/broadinstitute/sting/gatk/walkers/indels/IndelRealigner.java
View File

@ -894,8 +894,9 @@ public class IndelRealigner extends ReadWalker<Integer, Integer> {
// for reads ending before the indel
if ( myPosOnAlt + aRead.getReadLength() <= endOfFirstBlock) {
readCigar.add(new CigarElement(aRead.getReadLength(), CigarOperator.M));
aRead.setCigar(readCigar);
//readCigar.add(new CigarElement(aRead.getReadLength(), CigarOperator.M));
//aRead.setCigar(readCigar);
aRead.setCigar(null); // reset to original alignment
return true;
}
readCigar.add(new CigarElement(endOfFirstBlock - myPosOnAlt, CigarOperator.M));
@ -929,9 +930,10 @@ public class IndelRealigner extends ReadWalker<Integer, Integer> {
// for reads that start after the indel
if ( !sawAlignmentStart ) {
aRead.setAlignmentStart(leftmostIndex + myPosOnAlt + indelOffsetOnRef - indelOffsetOnRead);
readCigar.add(new CigarElement(aRead.getReadLength(), CigarOperator.M));
aRead.setCigar(readCigar);
//aRead.setAlignmentStart(leftmostIndex + myPosOnAlt + indelOffsetOnRef - indelOffsetOnRead);
//readCigar.add(new CigarElement(aRead.getReadLength(), CigarOperator.M));
//aRead.setCigar(readCigar);
aRead.setCigar(null); // reset to original alignment
return true;
}
@ -1142,6 +1144,11 @@ public class IndelRealigner extends ReadWalker<Integer, Integer> {
// tentatively sets the new Cigar, but it needs to be confirmed later
public void setCigar(Cigar cigar, boolean fixClippedCigar) {
if ( cigar == null ) {
newCigar = null;
return;
}
if ( fixClippedCigar && getReadBases().length < read.getReadLength() )
cigar = reclipCigar(cigar);
@ -1153,8 +1160,11 @@ public class IndelRealigner extends ReadWalker<Integer, Integer> {
// no indel?
String str = cigar.toString();
if ( !str.contains("D") && !str.contains("I") )
return;
if ( !str.contains("D") && !str.contains("I") ) {
logger.info("Modifying a read with no associated indel; although this is possible, it is highly unlikely. Perhaps this region should be double-checked: " + read.getReadName() + " near " + read.getReferenceName() + ":" + read.getAlignmentStart());
// newCigar = null;
// return;
}
newCigar = cigar;
}