Hi all! We recently ran a small experiment compari...
# rnavar
c
Hi all! We recently ran a small experiment comparing variant calls across different nf-core pipelines and mappers using the same sample. Specifically: • nf-core/sarek (germline workflow, BWAMEM2 mapper) • nf-core/rnavar (STAR mapper) Both were run with HaplotypeCaller followed by SnpEff annotation. Surprisingly, we observed substantial differences in the number of variants identified between the two approaches. nf-sarek identified 871553 variants, whereas nf-rnavar identified 22407 variants. Has anyone seen similar behavior before, or do you have ideas on why such discrepancies might arise? We’d really appreciate insights on potential sources of divergence. Thanks a lot in advance!
n
Was this a WGS sample? In that case this makes a lot of sense since RNA calling only happens on a subset of the genome
c
Apologies, the question was missing this critical context; it was indeed a DNA-seq WGS sample
n
yes I'd say this makes sense in this case 😛
party this 1
Could you compare it with a WES sample? That might give you a better overview?
c
Thank you! We'll try next with a WES sample, we should expect similar magnitudes in terms ammount of variants between the two runs right?
n
I'd say so, it might be a little different depending on your used WES regions but it should be fairly similar I think
s
Or you could potentially give a WES bed file to sarek?
party this 1
m
Interesting idea
I like the results
and definitively @Nicolas Vannieuwkerke is on point
🎉 1
c
Thanks for the suggestion! I'll get my hands on a WES sample and re-run both pipelines, creating the WES BED file for sarek
m
Also, I don’t think you can compare bwa and star, AFAIK both were written with entirely different uses and algorithms behind it
@Nicolas Vannieuwkerke , we did al thorough comparison of aligners a while back. Perhaps you can share those results if you still have them?
n
image.png
data gotten from running 3 WGS samples for each mapper
We didn't test STAR though
m
Do you have stats about the variant calling afterwards?
c
Totally! We know STAR and BWA were designed for very different purposes, but we still wanted to run them side by side to see what discordances show up when using otherwise similar germline workflows on the same sample.
👍 2
n
Nope I didn't test that
c
Hello again! I tested what was suggested here (supplying the same intervals BED file to both sarek and rnavar pipelines) and now the results from both pipelines are much more similar. I'm attaching an "overlap barplot" to illustrate the similarity of the results. There are still variants called only by one of the two pipelines and not by the other, but before supplying the same intervals file, the overlap was minimal. To me, these new results look reassuring, but wanted to consult them here with you as well because there might be some obvious thing I'm missing that makes the overlap not total or higher. What do you think? Thanks in advance!
🎉 2
m
What reference did you align the data to?
c
For both pipelines I used the GATK.GRCh38. For sarek I supplied it with the
genome
param but for rnavar I could not since it does not support this reference (I also wanted to ask why?) so I supplied the individual reference files (fasta, GTF, etc) that I took from sarek
m
Does this reference include alt, HLA, decoys etc?
c
It does, it actually includes tons of decoys
m
I’m mostly worried about alt contigs. Depending on your aligner and settings, reads can (primarily) align to a different contig, resulting in a different coverage profile and different variant calls downstream
c
Got it, it also has alt contigs and HLA loci, to account for natural variation, so this makes a lot of sense 🤔
m
since you’re benchmarking for concordance, and not accuracy, I would suggest you use a no-alt reference
c
Thanks for the idea, I'll do that and hopefully results match even more!
m
Nice
That's super interesting
I'll come back to you with some ideas speaking about references
@Kübra Narcı could we use any VCF for #C06K0KEAMTN?
k
I might not be following quite well but one can compare two VCFs in variantbenchmarking. one VCF can be considered as truth the other can be query. Matching/mismatched variants will be output then too (I have upset plots and indel distribution plots)
just out of curiosity I benchmarked NA12878 results https://nf-core-awsmegatests.s3-eu-west-1.amazonaws.com/rnavar/results-2cbf0469363ca72cc98218e7ae0886bc1bd1fd8f/variant_calling/ and it works. I can sent config if you want
g
Hello all! I'm writing in this thread because the question relates to this topic! I noticed that nf-core/sarek and nf-core/rnavar use two different approaches for variant filtering. 1. nf-core/rnavar --> VariantFiltration (Hard-filtering variants based) 2. nf-core/sarek --> CNNScoreVariants (Annotating variants with a score derived from a Convolutional Neural Network (CNN) model) + FilterVariantTranches (Applying filtering based on a variant's quality score (the one from CNNScoreVariants)) Is there a reason behind the use of this two different workflows? Thanks a lot in advance!
m
That's a very good question, and I feel like I should know the answer, and I am ashamed to say that I do not, so I'll ping @Nicolas Vannieuwkerke first
shared a GIF
🤣 1
n
I don't know either, it was like that when I made my first contribution to the pipeline 😅