Mutation rate interpretation in biallelic models [Recipe 14.13]

[vsudbrack]

Hello!

A quick comment about the SLiM manual. The current recipe for biallelic loci, sec. 14.13, implements the following mutation callbacks:

mutation(m2) {
// unique down to the canonical m2 mutation
return MUT2[mut.position];
}
mutation(m3) {
// unique down to the canonical m3 mutation
return MUT3[mut.position];
}

Notice that this mutation process includes events from m2 to m2 and from m3 to m3, which produce no allelic change at all (due to the uniquing down). Therefore, this version of the recipe actually has an effective mutation rate lower than the rate specified in initializeMutationRate(). With equal mutation rates and under neutrality, such that the equilibrium is 50% m2 and 50% m3, the effective mutation rate is approximately half of the value passed to initializeMutationRate().

This is, of course, not a bug per se, since SLiM’s interpretation of mutation rates is completly consistent. However, I would suggest either adding a warning to the recipe, along the lines of:

Notice that, if you are comparing this recipe with biallelic models in which mutation rates are defined as probabilities of switching between the two alleles, the effective switching rate in this recipe is lower than the rate passed to initializeMutationRate() due to...

Alternatively, the mutation callbacks could be updated as follows, which might also be instructive for people learning SLiM:

/// Back and forth mutations m2<-->m3
mutation(m2) {
	pos = mut.position;
	originally_m2 = haplosome.containsMutations(MUT2[pos]);
	return ifelse(originally_m2, MUT3[pos], MUT2[pos]);
}

mutation(m3) {
	pos = mut.position;
	originally_m2 = haplosome.containsMutations(MUT2[pos]);
	return ifelse(originally_m2, MUT3[pos], MUT2[pos]);
}

[bhaller]

Fair enough. All of this biallelic stuff needs further work, and maybe intrinsic support in SLiM; I'm not happy with how complicated and difficult it is right now. Anyhow, thanks for the issue, I'll ponder what I want to do.

[vsudbrack]

Yes, that would be a very useful feature.

One possible implementation would be a new stack policy, say 'b', that behaves as follows: when a mutation occurs at a position that does not currently carry a mutation of the focal type (or focal type's stack group), a new mutation is added; however, if a mutation of that type is already present at that position, all mutations of that type (or stack group) at that position are removed. If we denote the "empty" state by the wildtype allele a (not represented on SLiM), this corresponds to the transitions (a --> A_i) and (A_i --> a), where the index i indicates that multiple distinct mutations of the same type may be segregating at the same position in different haplosomes. A_i are always alone at a given position because, if a new mutation occurs on top of A_i, if would remove A_i due to the policy instead of adding a new, say, A_j.
So mutations at a position would go as a("empty") -> A_i -> a("empty")-> A_j -> a("empty") -> A_k ... .

This model combines identity by state (amongst wildtype a) and identity by descent (amongst derived alleles because retain their genealogical identity). If the mutation() callback is invoked only when a new mutation is created (i.e., for a -> A_i, but not for A_i -> a), then collapsing all (A_i) to a single derived state (A) becomes straightforward (the callback you have in Receipt 14.13 now). Then the mutations would go as a -> A -> a -> A-> a -> A ... at each position, which is the biallelic model.

[bhaller]

That is a possibility, but would only encompass biallelic dynamics, whereas sometimes people want triallelic dynamics (-1 / 0 / +1), and sometimes people want back-mutations to the ancestral (empty) state in nucleotide-based models rather than back-mutations to a new segregating mutation with the same nucleotide as the ancestral state, and so forth. There's a bigger problem here of needing to make it easier for people to implement whatever mutational model they want, without having to jump through so many hoops.

[petrelharp]

For more discussion on this type of thing, see https://tskit.dev/msprime/docs/latest/mutations.html#adjusting-mutation-rates-for-silent-mutations

…

On Sun, Jun 21, 2026 at 4:25 AM Ben Haller ***@***.***> wrote: *bhaller* left a comment (MesserLab/SLiM#636) <#636 (comment)> That is a possibility, but would only encompass biallelic dynamics, whereas sometimes people want triallelic dynamics (-1 / 0 / +1), and sometimes people want back-mutations to the ancestral (empty) state in nucleotide-based models rather than back-mutations to a new segregating mutation with the same nucleotide as the ancestral state, and so forth. There's a bigger problem here of needing to make it easier for people to implement whatever mutational model they want, without having to jump through so many hoops. — Reply to this email directly, view it on GitHub <#636?email_source=notifications&email_token=AAH7N2JB3BA3PVSMODYTD435A7A2NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGE3TQNZXGUZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4761787752>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7N2PXDQCSXPFNEGG2FFL5A7A2NAVCNFSNUABEKJSXA33TNF2G64TZHMZDOOJUGEYTGMB3JFZXG5LFHM2DMNZSGUZDGMJYG2QXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAH7N2JGSPLN6LLTYOWMV5D5A7A2NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGE3TQNZXGUZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AAH7N2JPBDX7IXJUVHAAU3D5A7A2NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGE3TQNZXGUZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>