Ignore PCR Duplicates in CollectTargetedPcrMetrics

[fongchun]

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]

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

[fongchun]

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]

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]

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.

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]

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!