If you happen to see a question you know the answer to, please do chime in and help your fellow community members. We encourage our fourm members to be more involved, jump in and help out your fellow researchers with their questions. GATK forum is a community forum and helping each other with using GATK tools and research is the cornerstone of our success as a genomics research community.We appreciate your help!
Test-drive the GATK tools and Best Practices pipelines on Terra
Check out this blog post to learn how you can get started with GATK and try out the pipelines in preconfigured workspaces (with a user-friendly interface!) without having to install anything.
MarkDuplicates takes too long to be finished within 48 hours
I've been trying to run MarkDuplicates on a MergeBamAlignment-produced bam file, which was derived from a paired-end RNA-seq dataset. However, the program couldn't be finished even after running 48 hours on the Stampede supercomputer system. The size of the bam file is 6.5 gb. Below is the command I used:
$WORK/tools/jre1.8.0_91/bin/java -Xmx128G -jar $WORK/tools/picard-tools-2.4.1/picard.jar MarkDuplicates \
INPUT=$WORK/GATK/XHD1/XHD1-MergeBamAlignment.bam OUTPUT=$WORK/GATK/XHD1/XHD1_markduplicates.bam \
METRICS_FILE=$WORK/GATK/XHD1/XHD1_markduplicates_metrics.txt OPTICAL_DUPLICATE_PIXEL_DISTANCE=250 \
After running the program on individual chromosome's bam files, I found that the reads mapped to chr 17 bogged down the program. The output shows messages like following:
INFO 2016-07-18 17:10:24 OpticalDuplicateFinder compared 37,000 ReadEnds to others. Elapsed time: 00:26:52s. Time for last 1,000: 42s. Last read position: 0:7,276
It appears there are several extremely large sets of duplicates mapped to chr 17.
Are there any solutions to this problem? Any help will be highly appreciated.