Fixing a silly bug of mine: when a realignment target begins at position 1 of a contig, it was possible to have some reads get emitted out of order (triggering an exception in the SAMFileWriter). This is fixed by moving around some parentheses. Tim, if you are reading this: feel free to take this fix in whenever it's convenient. I.e. it's not critical as the only user who has been hit by it has a reference with over 130K short contigs. Committing in SVN so that it gets incorporated immediately (and I can respond on GS now).

git-svn-id: file:///humgen/gsa-scr1/gsa-engineering/svn_contents/trunk@6024 348d0f76-0448-11de-a6fe-93d51630548a
This commit is contained in:
ebanks 2011-06-21 21:42:38 +00:00
parent 6dd41c8489
commit 8e149cc52f
1 changed files with 1 additions and 1 deletions

View File

@ -192,7 +192,7 @@ public class ConstrainedMateFixingManager {
// if the new read is on a different contig or we have too many reads, then we need to flush the queue and clear the map
boolean tooManyReads = getNReadsInQueue() >= MAX_RECORDS_IN_MEMORY;
if ( canFlush && (tooManyReads || (getNReadsInQueue() > 0 && !waitingReads.first().getReferenceIndex().equals(newRead.getReferenceIndex()))) ) {
if ( (canFlush && tooManyReads) || (getNReadsInQueue() > 0 && !waitingReads.first().getReferenceIndex().equals(newRead.getReferenceIndex())) ) {
if ( DEBUG ) logger.warn("Flushing queue on " + (tooManyReads ? "too many reads" : ("move to new contig: " + newRead.getReferenceName() + " from " + waitingReads.first().getReferenceName())) + " at " + newRead.getAlignmentStart());
while ( getNReadsInQueue() > 1 ) {