SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



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

Reply
 
Thread Tools
Old 02-16-2013, 10:59 AM   #1
fongchun
Member
 
Location: Vancouver, BC

Join Date: May 2011
Posts: 55
Default 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.
fongchun is offline   Reply With Quote
Old 02-16-2013, 11:29 AM   #2
Bukowski
Senior Member
 
Location: UK

Join Date: Jan 2010
Posts: 390
Default

Why are you marking duplicates in an amplicon based assay? I'm just curious..
Bukowski is offline   Reply With Quote
Old 02-16-2013, 11:32 AM   #3
fongchun
Member
 
Location: Vancouver, BC

Join Date: May 2011
Posts: 55
Default

Quote:
Originally Posted by Bukowski View Post
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....
fongchun is offline   Reply With Quote
Old 02-16-2013, 02:54 PM   #4
Bukowski
Senior Member
 
Location: UK

Join Date: Jan 2010
Posts: 390
Default

Quote:
Originally Posted by fongchun View Post
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'.

Last edited by Bukowski; 02-16-2013 at 02:58 PM.
Bukowski is offline   Reply With Quote
Old 02-16-2013, 03:25 PM   #5
fongchun
Member
 
Location: Vancouver, BC

Join Date: May 2011
Posts: 55
Default

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 View Post
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 is offline   Reply With Quote
Old 02-16-2013, 03:51 PM   #6
Bukowski
Senior Member
 
Location: UK

Join Date: Jan 2010
Posts: 390
Default

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!
Bukowski is offline   Reply With Quote
Reply

Tags
amplicon sequencing, collecttargetedpcrmetrics, picard

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 08:35 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO