Confusing results comparing QTLs without and with WASP filters

[plbngl]

Dear Bryce/Graham,
I was evaluating the use of WASP mapping bias removal in my dataset for scATAC-seq QTLs discovery (custom modified implementation to take into account single cell barcodes). QTLs were detected with Rasqual (similar concept as your CHT).

The issue I am having is illustrated in the figure below. Basically without WASP I have no apparent reference mapping bias (effect >0.5 is preference for alternate) but with WASP I have a reduction in discoveries (fewer tested peaks and snps and fewer caQTLs, which seemed to be originally not having biases) and introduction of new significant caPeaks with apparently a reference mapping bias.

I expected the exact opposite. Do you think that this is still possible (maybe also alternate allele mapping bias exists) or there must be something wrong in my implementation (a part from obvious swaps that I already checked)?

Thank you for you attention.
Best,
Paola

[gmcvicker]

Hi Paola, I am not sure what the issue is, or if there is in fact an issue. Each QTL on its own is expected to show bias toward either the reference or alternative allele. In aggregate, I believe that caQTLs tend to also show bias toward the reference allele, even after correction for mapping bias, because the reference allele is usually the more common allele, and there tends to be more purifying selection against alleles that reduce chromatin accessibility (i.e. the major allele tends to have higher chromatin accessibility). What would be helpful is to look at the number of reads that you have pre-/post- WASP filtering. If you are losing a huge number of reads then there may be a problem. BTW, we are working on WASP2 and are adding some support for single-cell. You can try it if you like, but it is still under development: https://github.com/mcvickerlab/WASP2 Graham From: Paola Benaglio ***@***.***> Reply-To: bmvdgeijn/WASP ***@***.***> Date: Friday, December 5, 2025 at 8:18 AM To: bmvdgeijn/WASP ***@***.***> Cc: Subscribed ***@***.***> Subject: [bmvdgeijn/WASP] Confusing results comparing QTLs without and with WASP filters (Issue #127) [Image removed by sender.]plbngl created an issue (bmvdgeijn/WASP#127)<#127> Dear Bryce/Graham, I was evaluating the use of WASP mapping bias removal in my dataset for scATAC-seq QTLs discovery (custom modified implementation to take into account single cell barcodes). QTLs were detected with Rasqual (similar concept as your CHT). The issue I am having is illustrated in the figure below. Basically without WASP I have no apparent reference mapping bias (effect >0.5 is preference for alternate) but with WASP I have a reduction in discoveries (fewer tested peaks and snps and fewer caQTLs, which seemed to be originally not having biases) and introduction of new significant caPeaks with apparently a reference mapping bias. I expected the exact opposite. Do you think that this is still possible (maybe also alternate allele mapping bias exists) or there must be something wrong in my implementation (a part from obvious swaps that I already checked)? Thank you for you attention. Best, Paola image.png (view on web)<https://github.com/user-attachments/assets/0b1ab9c2-b82e-411b-a733-71e521fbd30e> — Reply to this email directly, view it on GitHub<#127>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANX4TM5CZLM6VZGXZDP3EL4AGV6LAVCNFSM6AAAAACOFNPB32VHI2DSMVQWIX3LMV43ASLTON2WKOZTGY4TSNJVGI2TAMA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[plbngl]

Thank you Graham for the quick response!
We've double checked that the number of reads removed in the filp-remap-remove step is small (~1.6%)-

I still don't understand why the run without wasp has less QTLs with ref preference (51% caQTLs ref is preferred) while with wasp has more (52.5% caQTLs ref is preferred), given the intended use of remove reference mapping bias.. Does it mean that this increase is due to a true, purifying selection effect and non mapping bias effect? Why this is not more pronounced without wasp?

I have to note that there was a step of remapping the entire bam to be consistent in the remapping step, and a re-implemented duplicate removal step so perhaps these other steps that removed more reads are driving the differences.

Thanks again for your feedback!
Paola

[gmcvicker]

The duplicate removal step could introduce bias. In WASP we intentionally randomize which of the duplicate reads is retained. This is because the default with samtools etc. is to keep the read with the highest score, and this biases toward keeping the reference allele when there are ‘duplicate’ reads mapping to the same position. It’s also possible that the increase in reference mapping reads is real, because I do think there is a real phenomenon where the major allele tends to have higher expression / chromatin accessibility. Hope this helps. From: Paola Benaglio ***@***.***> Reply-To: bmvdgeijn/WASP ***@***.***> Date: Wednesday, December 10, 2025 at 2:45 AM To: bmvdgeijn/WASP ***@***.***> Cc: Graham McVicker ***@***.***>, Comment ***@***.***> Subject: Re: [bmvdgeijn/WASP] Confusing results comparing QTLs without and with WASP filters (Issue #127) [Image removed by sender.]plbngl left a comment (bmvdgeijn/WASP#127)<#127 (comment)> Thank you Graham for the quick response! We've double checked that the number of reads removed in the filp-remap-remove step is small (~1.6%)- I still don't understand why the run without wasp has less QTLs with ref preference (51% caQTLs ref is preferred) while with wasp has more (52.5% caQTLs ref is preferred), given the intended use of remove reference mapping bias.. Does it mean that this increase is due to a true, purifying selection effect and non mapping bias effect? Why this is not more pronounced without wasp? I have to note that there was a step of remapping the entire bam to be consistent in the remapping step, and a re-implemented duplicate removal step so perhaps these other steps that removed more reads are driving the differences. Thanks again for your feedback! Paola — Reply to this email directly, view it on GitHub<#127 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANX4TJTFTU76JTDZEY2UMT4A72UBAVCNFSM6AAAAACOFNPB32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZWGQ3DENRYHA>. You are receiving this because you commented.Message ID: ***@***.***>