Add more information on standard format and mapping to LD ref

[rkarlssonlinner]

Hi,

I have successfully run this software. Love it so far, great work!

Could you please add some more details on the following:

• Could you provide a full specification of the "standard format expected by magenpy/VIPRS" mentioned in the -h information?

• What is the minimum set of columns required from the input summary statistics?

• Is "A1" the effect-coded allele in the VIPRS standard format?

• How does the software map the summary statistics to the LD reference panel; by rsid or chr:pos?

• Does the software transform logistic regression beta's to the liability scale, or should the user do this as preprocessing?

• For logistic regression GWAS, does the software assume total N or effective N as the input?

• Are SNP positions in ".fit.gz" output reported as hg19/build37?

• Which model in the paper(s) does the option "-m VIPRSmix" refer to?

Thanks!

[shz9]

Hi Richard,

Thanks and glad you had good experience with the software so far.

Here are my answers to your questions:

• The standard sumstats format expected by viprs is quite similar to sumstats format of plink2 in most ways, the main differences in the names of the columns being:
  • #CHROM -> CHR
  • ID -> SNP
  • REF -> A2
  • ALT -> A1 (The tested allele)
  • OBS_CT -> N
  • T_STAT/Z_STAT -> Z
  • P -> PVAL
• For the method to run, it requires the following columns in the summary statistics file:
  • Variant ID: Either rsID or two columns corresponding to chromosome and BP position.
  • Sample size (column N) or you can specify GWAS sample sizes with the flag --gwas-sample-size.
  • Reference (A2) and alternative (A1) allele.
  • A measure of the standardized effect size. Should be one of the following z-score, p-value, or BETA and SE.
• Yes, the software uses A1 for the effect allele.
• We support matching variants using both rsID as well as chr:pos. Here's the function that performs matching between variant tables: merge_snp_tables. First, it checks if it can perform the matching based on rsID. If not present, it attempts to perform matching based on CHR/POS.
• To answer both of your questions about the case-control GWAS, to be honest I didn't spend as much time carefully incorporating best practices for dealing with this form of data. I primarily use the z-score from the all GWASs and the total sample size reported by the GWAS software. It may be worth updating this behavior in upcoming releases.
• For now, variant positions are all based on hg19/build 37.
• VIPRSMix refers to the sparse mixture prior (similar to SBayesR), where the number of mixture components can be set with --n-components. We did some experiments with this prior in the original VIPRS paper (Zabad et al. 2023) and you can see some of the results in the Supplementary Material.

Hope this helps and happy to answer any other questions that you may have.

I will try and incorporate parts of this answer into the documentation of the software. Until then, I'll leave this issue open as a reminder.