Ignore PCR Duplicates in CollectTargetedPcrMetrics

fongchun · 02-16-2013, 10:59 AM

Hi all,

I have a set of amplicon target sequencing libraries and I am trying to generate some basic metrics (e.g. number of reads, coverage of amplicons, etc) using the Picard Tools CollectTargetedPcrMetrics.jar. What I've noticed is that the tool ignores reads which have been marked as duplicates in its calculation of the statistics such as coverage of an amplicon. I was wondering if there was a way to get CollectTargetedPcrMetrics to ignore PCR duplicates. I wasn't able to find any parameters about this ...

The libraries have been aligned with bwa and then mark duplicate. I suppose one option could be to not mark duplicates, but that seems like a roundabout way of solving this.

Anyone else encountered this question before? Also, while we are on the topic what is the difference in the amplicon interval list and the target interval list? The reason I ask is that I passed in my intervals list file to the PER_TARGET_COVERAGE parameter and I ended up getting negative mean coverage which doesn't make sense to me (I didn't mark duplicates for this one). Anyone encountered this?

Thanks,

Bukowski · 02-16-2013, 11:29 AM

Why are you marking duplicates in an amplicon based assay? I'm just curious..

fongchun · 02-16-2013, 11:32 AM

Quote:

Originally Posted by Bukowski

Why are you marking duplicates in an amplicon based assay? I'm just curious..

Just part of our standard pipeline that we used to analyse all sequencing libraries. Like I mentioned, we could just build a separate analyses pipeline just for this, but it seems odd there isn't simply a parameter to just ignore PCR duplicates....

Bukowski · 02-16-2013, 02:54 PM

Quote:

Originally Posted by fongchun

Just part of our standard pipeline that we used to analyse all sequencing libraries. Like I mentioned, we could just build a separate analyses pipeline just for this, but it seems odd there isn't simply a parameter to just ignore PCR duplicates....

Marking duplicates when there is PCR involved seems counter-intuitive. Wont that lead to lots of things with the same start and stop position which will appear to be duplicated? If that's part of the design, why remove them?

Edit:

I should clarify this. I do a lot of in-solution capture analysis, and I de-duplicate the data if I'm using (for instance) SureSelect. But if the experiment is HaloPlex I don't - because de-duplicating the data removes data that is there because of the design - it's unavoidable to have data that matches the characteristics of 'duplicates'.

fongchun · 02-16-2013, 03:25 PM

I probably wasn't clear on what I want to actually do. I agree with you that we expect a lot of PCR duplicates and yes it is counter-intuitive to remove them. I am not suggesting that we remove them. I am just saying that as part of an already established pipeline we use, any libraries we align will automatically marks duplicates all sequencing libraries. I was just wondering if there was a parameter in the CollectTargetedPcrMetrics to calculate statistics on a library and ignore the fact there are marked duplicates. This would serve as an alternative solution to developing a branch in the pipeline that won't run mark duplicates. Either solution is fine. We can easily develop a branch. I would just like to know whether there was other options available.

I intend to use all the reads whether they are duplicates or not in our future analyses.

Hope that clarifies the confusion.

Quote:

Originally Posted by Bukowski

Marking duplicates when there is PCR involved seems counter-intuitive. Wont that lead to lots of things with the same start and stop position which will appear to be duplicated? If that's part of the design, why remove them?

Edit:

I should clarify this. I do a lot of in-solution capture analysis, and I de-duplicate the data if I'm using (for instance) SureSelect. But if the experiment is HaloPlex I don't - because de-duplicating the data removes data that is there because of the design - it's unavoidable to have data that matches the characteristics of 'duplicates'.

Bukowski · 02-16-2013, 03:51 PM

I guess it's no surprise that in my pipelines I have a switch that says 'don't de-dup the data' for when I need it. Pipelines are not immobile, immovable things, and they're never suitable for every situation.

It seems to me that the problem isn't with Picard, it's behaving exactly as it should, the fact is the pipeline shouldn't be marking duplicates. I guess that answers your question though!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PCR duplicates	aquleaf	RNA Sequencing	5	10-30-2012 11:40 AM
Distinguish real duplicates from those generated by PCR	aquleaf	Bioinformatics	1	10-30-2012 05:49 AM
How to differentiate between PCR duplicates and real data?	frymor	Bioinformatics	5	09-15-2011 01:05 PM
PCR duplicates questions	slny	Bioinformatics	8	06-07-2011 04:06 AM
how critical is the filtering of potential PCR duplicates?	julien	General	3	03-26-2010 10:24 AM

02-16-2013, 10:59 AM	#1
fongchun Member Location: Vancouver, BC Join Date: May 2011 Posts: 55	Ignore PCR Duplicates in CollectTargetedPcrMetrics Hi all, I have a set of amplicon target sequencing libraries and I am trying to generate some basic metrics (e.g. number of reads, coverage of amplicons, etc) using the Picard Tools CollectTargetedPcrMetrics.jar. What I've noticed is that the tool ignores reads which have been marked as duplicates in its calculation of the statistics such as coverage of an amplicon. I was wondering if there was a way to get CollectTargetedPcrMetrics to ignore PCR duplicates. I wasn't able to find any parameters about this ... The libraries have been aligned with bwa and then mark duplicate. I suppose one option could be to not mark duplicates, but that seems like a roundabout way of solving this. Anyone else encountered this question before? Also, while we are on the topic what is the difference in the amplicon interval list and the target interval list? The reason I ask is that I passed in my intervals list file to the PER_TARGET_COVERAGE parameter and I ended up getting negative mean coverage which doesn't make sense to me (I didn't mark duplicates for this one). Anyone encountered this? Thanks, Last edited by fongchun; 02-16-2013 at 11:31 AM. Reason: Added an additional question.

02-16-2013, 11:29 AM	#2
Bukowski Senior Member Location: UK Join Date: Jan 2010 Posts: 390	Why are you marking duplicates in an amplicon based assay? I'm just curious..

02-16-2013, 03:51 PM	#6
Bukowski Senior Member Location: UK Join Date: Jan 2010 Posts: 390	I guess it's no surprise that in my pipelines I have a switch that says 'don't de-dup the data' for when I need it. Pipelines are not immobile, immovable things, and they're never suitable for every situation. It seems to me that the problem isn't with Picard, it's behaving exactly as it should, the fact is the pipeline shouldn't be marking duplicates. I guess that answers your question though!