ebanks 12990c5e7a Added qual-by-depth annotation ... git-svn-id: file:///humgen/gsa-scr1/gsa-engineering/svn_contents/trunk@2445 348d0f76-0448-11de-a6fe-93d51630548a		2009-12-25 02:30:30 +00:00
..
annotator	Added qual-by-depth annotation	2009-12-25 02:30:30 +00:00
concordance	I want to move over to hpprojects tonight, so I'm checking in various changes all in one go:	2009-12-13 02:52:18 +00:00
fasta	a fix for a bug Andrey discovered: in read-based interval traversals we're dupplicating reads in rare cases. The problem was that to accomidate a bug in SAM JDK indexing, we were forced to add one to the stop of our QueryOverlapping() calls to ensure we always got all of the overlapping reads.	2009-11-05 05:26:33 +00:00
filters	Fixed another test	2009-12-18 05:05:03 +00:00
genotyper	Added qual-by-depth annotation	2009-12-25 02:30:30 +00:00
indels	After further review, it's unclear that my patch in RecalDataManager was the right choice. Reverting.	2009-12-24 00:32:33 +00:00
recalibration	The new recalibrator had been mimicking the behavior of the old one in that if there was no dinuc available (following a no-call base or at either end of a read), it didn't try to recalibrate. Now that Ryan has modularized the system, we no longer need to skip the base completely (we just need to skip the dinuc value)... which is good because the Picard people complained after realizing that cycle #1 never got recalibrated.	2009-12-24 20:41:29 +00:00
DepthOfCoverageIntegrationTest.java	- Moved various header line printing into a single method	2009-12-04 02:15:43 +00:00
PileupWalkerIntegrationTest.java	Fixed curiously epic failure in read-backed pileup: size() mismatched the numReads-numDeletions at that locus in the case where includeReadsWithDeletionsAtLoci == false, causing failures including bad output from pileup walker. Also fixed up ValidatingPileup to run with the new ReadBackedPileup instead of just compiling successfully.	2009-12-18 22:52:44 +00:00
PrintReadsWalkerTest.java	A big fix for MergingSamRecordIterator, where we weren't correctly handling the comparisons of SAMRecords correctly (we weren't applying the new reference index first, so sometimes the MT contig would be ID 23, sometimes 24 in different records).	2009-10-02 19:35:35 +00:00