## Notes on downsampling in HC/M2
http://gatkforums.broadinstitute.org/gatk/discussion/8028/notes-on-downsampling-in-hc-m2
This document aims to record some developer notes for posterity. Contents were generated July 24, 2015 and are not guaranteed to be up to date. No support guarantee either.
Arguments and Parameters
- "@Downsample" annotation in the class definition for HC/M2 controls the height of the pileup used for active region determination -- HC has default coverage 500, M2 downsampling takes on ActiveRegionWalker default, which is 1000
- "@ActiveRegionTraversalParameters" argument controls the maximum number of reads that can possibly be processed; has default maxReadsToHoldInMemoryPerSample() = 30,000 and across all samples maxReadsToHoldTotal() = 10,000,000 -- these are not currently overridden in HC or M2
- maxReadsInRegionPerSample and minReadsPerAlignmentStart (arguments in HC, hard-coded in M2 right now) loosely control the number of reads that go into the assembly step; default is 10K and 10 for HC, hard-coded 1000 and 5 for M2
Relevant Code
- TraverseActiveRegions.java does a lot of the data management (including some downsampling) and does the iteration over ActiveRegions in traverse()
- TraverseActiveRegions takes in the ActiveRegionTraversalParameters annotations and creates a TAROrderedReadCache (this is where all the reads that get passed to the Walker are stored)
- TAROrderedReadCache contains a ReservoirDownsampler
- ReservoirDownsampler is unbiased with regard to read start position; gets initialized with maxCapacity = min(maxReadsToHoldTotal, maxReadsToHoldInMemoryPerSample*nSamples)
- Reads that go into the Walker's map() function get downsampled by the ReservoirDownsampler to exactly maxCapacity if they exceed the maxCapacity -- at this point this is the most reads you can ever use for calculations
- Reads that go into the assembly step (already filtered for MQ) get downsampled by the LevelingDownsampler to approximately maxReadsInRegionPerSample if the number of reads exceeds maxReadsInRegionPerSample
- (my maxReadsInRegionPerSample is one step-through was 1037, but my downsampleReads was 3003 over 100bp, so it seems pretty approximate)
- The LevelingDownsampler is intentionally biased because it maintains a minimum coverage at each base as specified by minReadsPerAlignmentStart
- ActiveRegionTrimmer.Result trimmingResult in the Walker's map() function recovers reads (up to theTAROrderedReadCache maxCapacity) by pulling them from the originalActiveRegion, but trims them to variation events found in the (potentially downsampled) assembly
- Genotyping is performed based largely on the set of reads going into the map() function (M2 filters for quality with filterNonPassingReads before genotyping)
Worst Case M2 Behavior
- Highest coverage M2 call on CRSP NA12878 SM-612V4.bam vs SM-612V3.bam normal-normal pair occurs at 7:100645781 with 4000-5000X coverage, also coverage can exceed 7000X in other BAMs
- A lot of exons have coverage exceeding the 1000X cutoff for ActiveRegion determination with isActive(), but even with downsampling to 1000X we should still trigger ActiveRegions down to around allele fraction of ~0.8% for 4000X
- Even the highest coverage exon in the CRSP NA12878 normal-normal calling doesn't exceed the default limit for the ReservoirDownsampler (i.e. all reads will have the potential to get genotyped)
- In this super high coverage exon, reads are getting downsampled to ~3000 before they go into the assembly (again, controlled by maxReadsInRegionPerSample and minReadsPerAlignmentStart)
- Here that's a retention of about 12.5% of reads, which seems pretty aggressive
- The maxReadsInRegionPerSample value is 10% of what it is for HC
- Increasing maxReadsInRegionPerSample for M2 may increase sensitivity (although honestly not based on my LUAD comparison vs. M1) but will drastically increase assembly time
- All reads that pass quality filters are genotyped according to the variants found using the downsampled assembly set