Adding Admixture functionalities to the API

[jonbrenas]

The ancestry of a population can significantly bias many association studies. It is also critical for analyses of population demographics, genetic drift, ...

ADMIXTURE (https://dalexander.github.io/admixture/publications.html, https://pmc.ncbi.nlm.nih.gov/articles/PMC2752134/) is a commonly used tool to estimate individual ancestry.

Adding Admixture functionalities to the API would be of great benefit. This can be done either by extracting the data from the API into a format that is compatible with ADMIXTURE (i.e., LD-pruned PLINK), or the algorithm can be reimplemented, ...

[31puneet]

Hi @jonbrenas, this ties in nicely with #730. Since biallelic_snps_to_plink already handles the conversion pipeline, the LD-pruned PLINK export path could be a natural extension — adding an LD pruning step (e.g., via scikit-allel's locate_unlinked) before the PLINK write.

Would you lean towards keeping LD pruning as part of the export, or as a separate utility that can be combined with other analyses too?

[rehanxt5]

Hi @jonbrenas ,

I'm planning to add ld_prune_and_export() to export LD-pruned SNP sets to PLINK format. I'll use allel.locate_unlinked() from scikit-allel for the pruning logic.

A couple of design questions:

1. Pre-filtering with n_snps: Should this method accept an n_snps parameter (like biallelic_snps_to_plink does) to reduce memory before LD computation? My concern is that uniform positional thinning might break LD blocks and bias the result. Would it be better to forbid n_snps here and let users control memory via max_cohort_size or min_minor_ac instead?

• For full chromosome 2L (~7M SNPs × 3k samples), the genotype matrix would be ~21 GB.
  So pre-filtering matters for practical use, but I want to make sure the tradeoff doesn't hurt the statistical validity.

2. API design: Should the LD pruning be exposed as two separate methods : one that computes and returns the pruned dataset (e.g., biallelic_snp_calls_ld_pruned()) for inspection, then separately write to PLINK? This would follow the pattern of pca() building on biallelic_diplotypes(). Or would you prefer a single end-to-end method?

Thoughts?

[jonbrenas]

Hi @31puneet, @rehanxt5,

I think the LD pruning should be its own function. It is, by itself, an interesting analysis step.

As for pre-filtering, it is, indeed, an important step. I think there are multiple correct answers (either downsampling on individuals or SNPs) and all the (realistic) options should be on the table.

[31puneet]

Thanks for the feedback @jonbrenas would follow your approach and work on this

[rehanxt5]

@jonbrenas Thanks! I'll start implementing this

[adilraza99]

Hi @jonbrenas,

I spent some time looking through the architecture, especially the existing PLINK export pipeline (PlinkConverter in to_plink.py), to understand how ADMIXTURE support could fit into the current API.

From what I can see, the repository consistently follows a pattern where data access (snp_calls, biallelic_snp_calls) is separated from transformations and exports. Because of that, LD pruning seems to fit most naturally as a transformation step rather than something tied directly to a specific export workflow.

One thing that stood out while reviewing the pipeline is that LD pruning methods such as allel.locate_unlinked() require a fully materialized genotype matrix. For large regions this could easily involve millions of variants across many samples, which may become quite large in memory. It might therefore be important that pruning happens after pre-thinning (e.g. via n_snps or smaller regions) to keep memory usage manageable.

A possible direction could be introducing a method like biallelic_snp_calls_ld_pruned() returning a pruned dataset, and then reusing the existing PLINK export functionality afterwards.

Curious to hear if this aligns with the intended direction.

[jonbrenas]

I appreciate the enthusiasm but this is not how collaborative programming or contributing to an open-source project works: we don't need 3 PRs doing similar work. Either you are all doing the exact same thing, and then what's the benefit, or you all have different ideas and make different choices, in which case you need to discuss them and come to a decision that you can then defend as the best option. The code itself doesn't really matter: any decently set up AI agent should be able to produce code that is close enough to a solution to a well-described problem that one barely has to adjust it. What is important is why this is the way you want to tackle the problem.

[31puneet]

@jonbrenas Understood, happy to discuss and align with the others here on one approach. Let me know how you'd like us to proceed.