I am not 100% sure, it's been a while since the last time I used FastQTL, but I will try to give it a try:
I think that, in theory, it should be OK to have a tagging SNP and its LD proxies for QTL Mapping. Because in FastQTL 2 different multiple-testing methods are used for correcting your nominal associations: permutation test for the best nominal candidate variant per phenotype and FDR estimation for multiple tested phenotypes; and that's for all the variants & phenotypes within (let's say) 1 Mb window of the TSS of a phenotype in the locus.
So if you have only one tagging SNP & LD proxies, most probably they will have a similar nominal association with the phenotypes (like they're forming a haplotype, creating a potential QTL for a locus); and I think their adjusted P-values will be also similar. FastQTL first detects the best variant for a phenotype - then reports the adjusted P-value of that variant by keeping genotypes of the cis variants the same but randomly permuting phenotypic values, therefore it estimates how frequently the new combinations are stronger than the observed association for a given nominal variant-phenotype (and, how likely it's a true association?). Here, the authors are recommending using Beta-approximation method (with 1000 permutations).
So in my opinion LD proxies shouldn't affect your results a lot in terms of the association of that SNP & its proxies with a phenotype. It might be even better to have them. Number of variants tested in that region would affect the process of finding the best nominal association for a phenotype: so, for example, it might be that another SNP that is not genotyped/imputed in the same region is the true QTL SNP for the phenotype (or let's say, having a stronger association with the phenotype). In other words, I think in this case you can only comment & speculate on potential involvement of your SNP & proxies as a QTL for a phenotype in your region of interest within the cis-window.
I hope it was clear enough, and sorry if it's not; let me know if you need any further help. Actually right now I am working on a similar case where I have a few tagging SNPs (genotyped) and its LD proxies (imputed) for a region that I am interested in, so I will give feedback and edit this post if required.
Most likely your parameters for the beta distribution are wrong i.e. negative. This could be due to numerical stability issues in the algorithm.
I don't know how FastQTL works but from the paper:
so another possibility is that the beta distribution is not a good approximation for those cases.
Thank you very much for your reply. Indeed it could be due to the negative parameters, but as far as I know beta parameters are estimated using permutations (in FastQTL case, an adaptive permutation scheme) for generating a set of P-values (and using these values in a log-likelihood equation). So I don't think it would generate negative parameters. Maybe I can try updating the latest version of GSL for a better numerical stability.
Another option might be (somehow) disabling the ''default GSL error handler'' that aborts the computation for the related chunk and deletes all other information, what do you think?
From a quick look at the source code of beta.c, it fails because the function gsl_sf_lnbeta_sgn_e returns -1. This functions appears to check the sign and the amplitude of the parameters so this confirms that it's failing because FastQTL can't find adequate beta distribution parameters. You could suppress the error but would you trust the results ?
Thanks again for your help! Source code of beta.c explains all, you were right. Also I managed to contact the author of FastQTL paper, he also says that it's probably due to the low variability of some of the transcript expression levels between the samples. I've checked the failing ones, and I can confirm this. It's either due to many 0 values, or almost same expression levels for all samples.
Maybe if I can filter out these transcripts, the tool would work properly.
And regarding your last remark: I don't think this error is occurring for a big portion of my phenotype data, so it would be still OK to suppress the error somehow. As I said, even if it occurs for one transcript, it deletes all other mapped eQTLs in the same chunk.
Hi maegsul,
What did you end up using as a workaround? Did you filter out the transcripts? I'm encountering the same issue.
Hi! Yes, I filtered out the transcripts that have low variability (= expression values of 0 for all the individuals) with an awk one-liner. Same goes for the genotypes - if they are always the same genotype for a variant - filter that variant as well. Then the tool works without an error. That wouldn't affect your results or create bias, since you just remove non-variable genotypes/phenotypes.
Let me know if that doesn't solve your problem, I will be happy to help further.
This solution is really helpful. I was running using filtered data, but then I used all the coding genes and got this error, so I think that this has something to do with lowly expressed data.
However, maybe you could try nominal option instead of permutation.
Dear,
FastQTL (permutation pass) is displaying the following error message:
gsl: beta.c:44: ERROR: domain error Default GSL error handler invoked. Aborted
Any help will be appreciated.