List of features

[gaow]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[gaow]

Components to include:

• Padding & stitching algorithm to align fine-mapping of GWAS and QTL regions from different studies (without having to re-finemap).
  • @gaow needs to implement it. Haochen's version has issues.
• SNP ID matching between QTL and GWAS; summary stats and LD SNP ID matching
  • Perhaps we can leverage bigsnpr::snp_match?
• Summary stats QC and imputation
  • Summary stats QC using a simple test for a "fudge factor" on the LD matrix to match z scores. This idea was outlined on SuSiE RSS as a (not so successful) attempt to correct for LD mismatch, and was later developed by CARMA authors into a test for outlier check buried inside of the CARMA program. It was shown to work better than SLALOM but there is practically very difficult, if at all, that the community can use it for QC purpose outside CARMA unless we reimplement. @gaow should be able to implement it here.
  • Imputation using ImpG for now although we might also be able to use RAISS ...
• Enrichment using torus/fastenloc model
  • Implemented with a few difference from original implementation documented in the compute_qtl_enrichment documentation
  • Should work better
• Colocalization using SuSiE-coloc with fastenloc prior
  • This should be very easy to implement
  • Might work better than fastenloc?
• PTWAS/GAMBIT for TWAS
  • we have draft R code but let's drop the SNP LD matching code
• PTWAS_est for MR
  • we have draft R code but let's drop the SNP LD matching code
• INTACT
  • just use the INTACT package on bioconductor
• Visualization
• Vignettee

Down the road we will try to work out a new method for QC and imputation, and implement it also in this package.

[gaow]

@danielnachun are there additional things we should include & easy to add?

[gaow]

For visualization this might be useful https://www.biorxiv.org/content/10.1101/2023.04.28.538654v1.full.pdf i was involved mostly to suggest and edit but didn't do any coding. This is currently in press at Briefings of Bioinformatics.

[danielnachun]

Possible inclusions:

• I have not carefully read the details of https://www.biorxiv.org/content/10.1101/2022.10.21.513123v1, but it would be interesting to consider the implications of infinitesimal fine mapping in the context of colocalization, TWAS and MR. If the ideas are theoretically consistent with our framework and we can reimplement their Python code in R it could be an interesting optional component.
• There is also CTWAS (https://www.biorxiv.org/content/10.1101/2022.09.27.509700v2), which is already part of the SuSiE ecosystem and is developed by our colleagues. If there were a way to connect this package with the CTWAS package (again perhaps as an optional component) that would be great. It may also be worth trying to understand what overlap this has with the INTACT approach given that the goal for both of them is to account for LD hitchhiking.
• Making sure this places nicely with mvsusieR and mvf.susie would be great for allowing joint integration where we can use mashR to share information about effect sizes between omes/tissues/cell types.
• There is also the work in https://genomebiology.biomedcentral.com/articles/10.1186/s13059-020-02125-w on PRIMO for "multivariate colocalization". The model they have built there is quite a general framework where the user can provide a set of molecular QTLs from different contexts and a GWAS, or even multiple GWAS, and try to find which combination of all of them is colocalized. Of all these possible integrations, this is the one I am the least certain about how to connect to our framework. It's not clear whether this framework could extend to TWAS/MR, how one could integrate fine mapping for multiple credible sets into the model either, and what theoretical connections this may have to what we are doing in mvsusieR and mvf.susie.

In all of the above cases, if nothing else it would good for our work to acknowledge these tools and suggest directing future efforts towards connecting them together. One of the biggest challenges end users wanting to do GWAS integration encounter is uncertainty in the relationship between tools that try to solve similar problems. This an ongoing challenge but it would be great to address it as best we can in the current state of the field and maybe do a V2 in a few years if there have been a lot of developments. I think twoSampleMR did a great job of this for the MR field and it would be great to do the same for GWAS integration.

[danielnachun]

I think it's also important to draw some boundaries about things we don't want to incorporate here at the moment. This is what comes to mind so far:

• Q-type and M-type burden tests as defined in the GAMBIT manuscript. It is technically possible to implement a weighted Q-type burden test but Q-type tests cannot make causal claims because by squaring all the weights, you no longer know if you have concordance of signs between the QTL and GWAS. In that sense a Q-type tests (as well as M-type tests) are really more heritability enrichment tests rather than instrumental variable tests like the L-type test we are implementing. There is potentially some opportunity to use an INTACT or CTWAS style approach to reduce confounding caused by LD hitchhiking in Q-type tests, but I think the place of Q-type tests is more for integrating things like functional annotations (CHIP-seq, ATAC-seq, MPRA effects etc.) where the sign of the effect is not expected to be concordant with a GWAS anyway. It's also possible to use functional data as a prior for SuSiE which is something that is already done by tools like polyfun anyway.
• Integration of trans-QTLs is very challenging due to the complex correlated horizontal pleiotropy (CHP) present in that data because the same variant can effect dozens to thousands of different genes. I do not feel the field has really reached a consensus yet about how best to deal with this, and most of the effort has focused on dealing with CHP between GWAS and not between trans-QTL and GWAS. This will be a great area to expand into as this field matures!
• Similarly, I do not think multi-layer/network MR is developed enough yet to try to tackle here yet. This is a really hot topic right now and I am hoping in a few years we'll more consensus about how to model this properly as well but there is a lot fundamental theoretical work to be done before we can integrate it with more mature techniques.

[gaow]

• Regarding SuSiE-inf model: I have difficulties follow the detail of that paper although conceptually it makes sense and i can think of alternative implementations to it. Using it for TWAS is straightforward but it is not immediately clear to me how you do colocalization with it.
• CTWAS is like a next step to our package, not integrated to it. Same for INTACT. I think we should make vignettes for how to use output from our package
• Good point RE other SuSiE methods -- I can try to unify the output objects from them so they connect naturally into our framework. We just need lots of vignettes :D
• mvSuSiE should replace PRIMO but currently mvSuSiE has many limitations. We are also developing a simpler method than mvSuSiE for multi-trait colocaliztaion that already beats what's on the market -- we did not compare with PRIMO because the conditional regression is what turns me down. This new approach is not based on SuSiE framework (it is a frequentest method!) although we made it very much comparable with SuSiE in terms of PIP and CS. Multi-trait approach can be another iteration if you think about not just multivariate colocalization but also TWAS (a few out there perhaps mr.mash is taking a lead) and MR (nothing much out there!).
• I completely agree with your "not-included" list. In fact as I put together the codes I"m already dropping components from each of their original publications that i dont think too relevant at this point. Various types of tests in GAMBIT will be removed --- even if some of those seem like good quantities to report, they are perhaps of less practical use than they appear on the manuscript.
• For the MR part, using composite IV seems a great idea to leverage fine-mapping but the methods used is just standard Q statistics and I^2 heterogeneity tests. I imagine throw into it other MR approaches but it might not worth making a big deal for cis-QTL as IV (at least not in this framework --- we are trying to develop alternative approaches to this problem but haven't made it to far due to lack of energy)

[gaow]

Input format:

• SuSiE objects in RDS for fine-mapping results?
• parquet format for LD?
• No specific input format required for summary stats although we recommend and show QC using munglesumstats?

Output format: just R objects but we provide good summary() functions on each component?

[danielnachun]

Some thoughts here:

• A unified interface for doing this integration from individual level or summary level is really important. One of the biggest challenges to quickly doing GWAS integration is that TWAS methods like FUSION, PrediXcan, TIGAR and PTWAS require individual level QTL data that is sometimes difficult to obtain in a reasonable amount of time. At the same time SMR is the only "off the shelf" method for doing MR from summary stats that really was designed for IV analysis of cis-QTLs, and it can only model one instrument per gene. And almost all of the other summary-based MR methods around are designed for multi-instrument GWAS-to-GWAS IV analysis that is not suitable for cis-QTLs. Having a single interface that accepts SuSiE output (which I think at a certain step will be same whether it is from individual level or summary data) will make this much more user friendly than the existing approaches.
• I think a good summary object should include three layers of information: gene level, credible set/cluster level, and variant level. At each level we would want to give the colocalization probability, TWAS Z-score and MR IVW estimate, since all of these can be computed at each level. Most users will care about the gene level analysis but in some cases they will want the more fine grained details.
• Specifically for the variant level data, we should emphasize one of SuSiE's most attractive properties - exchangeability. As noted in the original SuSiE manuscript, one difficulty with high dimensional regression models (LASSO, ridge, elastic net, BSLMM, Dirichlet process regression) is that the variants they choose will change depending on the order in which parameters are updated in coordinate descent or Gibbs sampling. There are EM/variational inference versions of high dimensional regression but these are known to be inaccurate, and I think even doing variational inference with normalizing flow to update the proposal distribution cannot resolve this because the posterior distributions for high dimensional regression models have no posterior mode. By contrast, because the SuSiE model does not try to estimate exact point estimates for each variant but instead focuses on identifying credible sets, these credible sets are stable. For downstream validation of variant effects this is very helpful because it means users can just use the credible sets we return them rather than having to take individual variants chosen by high dimensional regression and then try to guess what a good LD window is to take around each variant.