Hi all,
I am trying to generate a genome-wide phylogeny of accessions from a plant diversity panel (~360). I have quality-filtered my VCF on both sites and accessions, leaving about 350k SNPs over a ~5 Gbp reference genome. While this is perhaps already a bit sparse, I am trying to understand the general answer to the question "should you linkage-prune SNPs before conversion to PHYLIP and phylogeny construction?".
Specifically, I am planning to use the ML inference methods of IQ-TREE2. It is made very clear in various tutorials that you must linkage prune before running PCA or ADMIXTURE because those analyses assume independent sites. However, I can't find similar information one way or the other for phylogeny inference.
Any advice would be really appreciated!
Thanks, Max
Short answer: no, you generally don't LD-prune for phylogeny. The thing that actually matters for your setup is ascertainment bias correction.
The reason PCA and ADMIXTURE need pruning is that they treat sites as independent observations, so a block of linked SNPs effectively gets counted many times and can dominate the axes or the cluster assignments. Phylogenetic likelihood also assumes site independence, but the practical consequence of violating it is different: linked sites mostly inflate your support values (bootstrap / aLRT look better than they should) rather than systematically dragging the topology somewhere wrong. Discarding sites costs you signal, which matters more when you already only have 350k SNPs.
What does bite people with SNP-only matrices is ascertainment bias. Your PHYLIP contains only variable sites, so branch lengths will be overestimated unless you use an ASC model -- e.g. -m GTR+ASC, or -m MFP+ASC to let ModelFinder choose. Note IQ-TREE will refuse to run +ASC if any invariant sites are still present, so check that your VCF-to-PHYLIP conversion is genuinely dropping them (and that it isn't emitting sites that are invariant after your sample filtering). This has a far bigger effect on the tree than LD does.
Two situations where LD does matter in practice: if a large low-recombination region (pericentromeric, or a segregating inversion) contributes a big share of your SNPs, that single non-recombining block can dominate the tree. Worth plotting SNP density per chromosome, and if one region is overrepresented, compare trees with and without it rather than pruning genome-wide. And more generally, a concatenated SNP tree assumes a single topology for the whole genome, which for a recombining diversity panel is a simplification regardless of whether you prune.
Hi Leo,
Thanks for the detailed answer. Regarding your last paragraph, you say that large low-recombination regions could dominate the tree. Isn't that exactly what linkage pruning would help with?
Cheers, Max
Fair point, I didn't phrase that well.
Pruning does thin the region out, but I don't think it fixes the underlying thing. It reduces how many sites that block contributes, not the fact that all of them are reporting the same single history. A non-recombining 5 Mb region gives you one genealogy whether you keep 10,000 SNPs from it or 100 -- you've downweighted it, you haven't made it independent.
And r2-based pruning gets applied genome-wide, so it also strips sites out of the high-recombination regions, which are exactly the ones where SNPs are carrying independent information. You end up flatter in site count without being flatter in number of independent histories, and it's the second one the tree is actually built from.
If a particular region is the worry, I'd build the tree with and without it and compare. That answers the question directly rather than hoping a global filter handles it.
Thanks Leo, that's a really helpful explanation, I now see the distinction. I'll scan for low-recombination regions and try removing any particularly egregious offenders.
Answer upvoted and accepted.
Cheers, Max
Log in to answer this question.
