Handiling of male X chromosome genotypes

[Fiwx]

Some male X chromosomes have "0/0" or "1/1" genotypes instead of haploid calls. For a VCF file, does pgsc_calc determine sex and adjust the calculation to handle these "homozygous" (actually haploid) formatted X chromosome calls, to avoid double-counting? Is there an expected or required format for male X chromosomes?

[smlmbrt]

Hi @Fiwx, in this case we'd recommend you first convert your VCF to plink files first (see plink documentation and https://pgsc-calc.readthedocs.io/en/latest/how-to/prepare.html) and making sure that the chrX genotypes get imported correctly. This will likely include using the --update-sex flag to input a file with information.

[AWS-crafter]

@smlmbrt All imputation methods that I am familiar with require diploid, instead of hemizygous (they cannot handle hemizygous), X chromosomes. I am not too concerned about this because most scorefiles will not contain the X chromosome in the first place. However, some do. For these, I think it's important to know how pgsc_calc handles this the X chromosome.

Imputation output on the X chromosome is expected to be a bit "wrong" in the sense that it will output hemizygous calls as homozygous. Should we "fix" this before sending the imputation output to pgsc_calc (change what should technically be hemizygous back to hemizygous calls), or should we leave the technically homozygous calls as is?

Male X chromosomes in the non-PAR region have only one copy and are usually formatted as "0" or "1" instead of "0/0" or "1/1" to reflect this.

If pgsc_calc simply sums the dosage of the allele matching the scorefile, it may double count sometimes. Alleles from males in the non-PAR region of the X chromosome will be output from imputation as diploid (so if a scorefile variant matches, the effect size will be added twice). In reality, there is only one copy, so the effect size should (I think) be added only once. Or perhaps, this double counting is intentional.

Or perhaps pgsc_calc has some other approach, such as something like this:

If build is GRCh37:
      Use this information...
      Chromosome X regions GRCh37/hg19
      X:60,001-2,699,520 (chrX.PAR1)
      X:2,699,521-154,931,043 (chrX.nonPAR)
      X:154,931,044-1,55,260,560 (chrX.PAR2)
      ... to determine if there are near-exclusively homozygous calls the non-PAR regions (and heterozygous calls within the PAR regions)
          If there are, tell the calculator to sum only once at these non-PAR positions even when they are homozygous (or convert the file to have hemizygous calls)

If build is GRCh37:
      Use this information...
      Chromosome X regions GRCh38/hg38
      chrX:10,001-2,781,479 (chrX.PAR1)
      chrX:2,781,480-155,701,382 (chrX.nonPAR)
      chrX:155,701,383-15,6030,895 (chrX.PAR2)
      ... to determine if there are near-exclusively homozygous calls the non-PAR regions (and heterozygous calls within the PAR regions)
                    If there are, tell the calculator to sum only once at these non-PAR positions even when they are homozygous (or convert the file to have hemizygous calls)

[smlmbrt]

Going to take another look at this, but from our perspective the vast majority of PGS do not include the X chromosome. I believe the standard is to treat male X chromosome genotypes as 0/2 and female genotypes as0/1/2 and will check how plink behaves with our reference panel and other data. Do you have any specific PGS or citations that might be relevant?

Notes:

• On coding/association models: https://onlinelibrary.wiley.com/doi/full/10.1002/gepi.22422
• Systematic review of XWAS methods: https://academic.oup.com/bib/article/23/5/bbac287/6651325
• Some discussion of PAR variants: https://journals.plos.org/plosgenetics/article?id=10.1371/journal.pgen.1010472

[AWS-crafter]

Makes sense. I wasn't sure which way was standard. I'm glad the imputation output aligns with this, so no modification should be needed!