caherzee
commented
2 years ago Hi,
It seems possible to me that a larger input bam produces a smaller output vcf compared to a smaller input bam.
Do you suspect there is a bug in elPrep because this outcome makes no sense from a biological perspective in your case? If so, you could remove the haplotypecaller step from the elprep invocation and try to perform that part with GATK and see what the outcome is? If you find there is a bug, please let us know.
If you pass the --sorting-order coordinate option to elPrep, the tool will sort the input by coordinate order. It is not necessary to pre-sort the input before passing it to elPrep.
elPrep accepts both bam and sam as inputs. It should normally not matter for the final outcome.
Thanks!
Kind regards, Charlotte
desmodus1984
Hi, I am using elprep to do variant calling of samples with ~10X coverage and the sample using for genome assembly. The vcf of the ~10X samples were on average 5GB and that genome-assembly sample vcf was 2.9GB. Any ideas of why the samples with ~25 GB reads generated bigger vcf files than the one generated with the 145GB sample?
The code was the same for every sample. I mapped the reads with bwamem-2 followed by vcf calling with elprep.
elprep sfm PA113.sorted.bam PA113.output.bam --nr-of-threads 28 --tmp-path $TMPDIR \ --mark-duplicates --mark-optical-duplicates PA113.metrics \ --sorting-order coordinate \ --bqsr PA113.recal \ --reference /users/PHS0338/jpac1984/data/myse-hapog.elfasta \ --haplotypecaller PA113.vcf.gz
Does it matter whether the input was bam or sam? or coordinate-sorted or not?
Thanks;