Ion Torrent Ampliseq: duplicate removal / coverage / variants?

[[email protected]]

Hi Folks

I would love to get some opinions regarding duplicate removal during variant calling for the AmpliSeq Comprehensive Cancer Panel.

I have noted some previous discussions on the topic on this forum, but I am experiencing some additional issues.

We have been doing tumor vs. normal samples, and do the realignment and base quality score recalibration steps (no duplicate removal) using GATK. We are currently testing a variety of somatic variant callers (Strelka, VarScan, MuTect, JointSNVMix, SomaticSniper).

Ion Torrent states the following:

"Marking duplicate reads is not appropriate for Ion AmpliSeq data, because many independent reads are expected to share the same 5' alignment position and 3' adapter flow as each other. Marking duplicates on an Ion AmpliSeq run risks inappropriately flagging many reads that are in fact independent of one another."

When doing visual inspection of (possibly) variant positions in IGV, a lot of the variants seem to have been called based on read depth that sure look like duplicates upon inspection. There also seems to be a trend for variant positions to be at the edges of these reads .

However, if I do duplicate removal, my average coverage drops from 300x to 9x.

The duplicate reads vs. true coverage depth obviously has quite serious implications for all variant calling statistics...

Any advice / opinions / debate would be much appreciated.

Best regards!

Fourie

[Bukowski]

Well it's exactly like IonTorrent advise - you can't deduplicate amplicon data on any platform, neither can you do it with HaloPlex.

This means it is impossible to remove PCR artefacts from the data. This is why I much prefer hybridisation capture for these kind of studies, as deduplication is required to keep that source of false positives under control.

My best advice is if you're stuck with this system, run samples in duplicate - at least then if you have false positives from the amplification, they shouldn't be present in the other replicate.

[nbahlis]

I have the same problem. Is there a way to rum Mutect without removing duplicates (or presumed duplicates)?

[IonTom]

You can use the VariantTools Biocondctor package, this gives you the
number of unique in read positions for variant and reference. Using a GenomicRanges object generated from a vcf you can make it report specifically for the positions of interest. This can be done using the tally function.

[IonTom]

Here is the code:

library(gmapR)
library(VariantTools)
library(VariantAnnotation)
library(BiocParallel)

biocParam <- MulticoreParam(workers = ncores)

fastaFile <- rtracklayer::FastaFile(referencefile)
gmapGenome <- GmapGenome(fastaFile, create=TRUE,directory = referencefolder)

print(tallied)

vcf = readVcf(vcffile)
called <- as(unlist(vcf),"VRanges")


tally.param <- TallyVariantsParam(gmapGenome, high_base_quality = 0L,minimum_mapq = 10L,
which = unique(as(called,"GRanges")),ignore_duplicates = FALSE,read_pos_breaks = c(1,10,120,330),
variant_strand = 1)


tallied = tallyVariants(bam_file,tally.param,BPPARAM = biocParam)
matched = called %in% tallied
matched_tallied = tallied %in% called

cur_called = called[matched]
tallied = unique(tallied[matched_tallied])

sampleNames(tallied) = sampleNames(cur_called)

elementMetadata(tallied) = c(elementMetadata(cur_called),elementMetadata(tallied))

print(tallied)

[dakl]

I have the same problem. Is there a way to rum Mutect without removing duplicates (or presumed duplicates)?

Yes, just skip the dedup step. It's just an upstream step to skip.

[quantrix]

Hi Fourie,
I was wondering what you ended up doing in terms of variant calling with the Ion CCP panel data? Did you just end up using the torrent variant caller? If so, how did you do the downstream analysis for filtering the variants etc? Did you use Ion Reporter?
I find it quite incredible that the Ion data seems to be quite incompatible with ANY of the variant callers like Mutect, Varscan to do paired tumor normal analysis.
Thanks for the favor of a reply.
Regards