So, we've just begun to run some of our new NextSeq data through our standard pipelines and hit a snag. bcl2fastq still gives us fastq by index, read and lane, so the eight files for every sample are zcat'd together into two and aligned using either STAR or tophat. The problems begin to happen when we use picard Mark Duplicates which seems to fail on certain samples.
I've been trying to diagnose the problem and I think it may be related to samples having clusters with reads at the same XY co-ordinate, albeit on different lanes - although we've not had this problem on HiSeq rapid runs.
If I rename the fastq headers to a rolling number using fastx_renamer -n COUNT and this "fixes" the problem although I now no longer have any info about optical duplicates.
Has anyone else hit this problem?
Code:
Exception in thread "main" htsjdk.samtools.SAMException: Value was put into PairInfoMap more than once. 1: null:NS500195:9:H0MT4AGXX:1:11201:10896:15588 at htsjdk.samtools.CoordinateSortedPairInfoMap.ensureSequenceLoaded(CoordinateSortedPairInfoMap.java:132) at htsjdk.samtools.CoordinateSortedPairInfoMap.remove(CoordinateSortedPairInfoMap.java:86) at picard.sam.DiskReadEndsMap.remove(DiskReadEndsMap.java:63) at picard.sam.MarkDuplicates.buildSortedReadEndLists(MarkDuplicates.java:434) at picard.sam.MarkDuplicates.doWork(MarkDuplicates.java:177) at picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:183) at picard.sam.MarkDuplicates.main(MarkDuplicates.java:161)
If I rename the fastq headers to a rolling number using fastx_renamer -n COUNT and this "fixes" the problem although I now no longer have any info about optical duplicates.
Has anyone else hit this problem?
Comment