In the latest tsinfer version, we raise "LibraryError: Sites with multiple mutations are not supported in matcher_indexes", and define TSI_ERR_MULTIPLE_MUTATIONS_AT_SITE, which is raised in
|
ret = TSI_ERR_MULTIPLE_MUTATIONS_AT_SITE; |
.
However, we quite often will have bialleleic inference sites with multiple mutations between the alleles, for instance when we match against a tree sequence that has allowed for mismatch (although I know we don't nowadays recommend setting a mismatch in match_ancestors). We surely used to allow matching at sites with multiple mutations, and we will definitely want this if we are matching samples into (for instance) the unified genealogy, where there are currently lots of inference sites with multiple mutations. The HMM approach also works fine in things like sc2ts where there are multiple mutations.
So I'm not entirely sure why this restriction now exists - I guess it could just be to restrict the code at the moment to the most common case, and the intention is to change this later. But perhaps I've misunderstood something @jeromekelleher ?
In the latest tsinfer version, we raise "LibraryError: Sites with multiple mutations are not supported in matcher_indexes", and define
TSI_ERR_MULTIPLE_MUTATIONS_AT_SITE, which is raised intsinfer/lib/ancestor_matcher.c
Line 198 in 7bfa63e
However, we quite often will have bialleleic inference sites with multiple mutations between the alleles, for instance when we match against a tree sequence that has allowed for mismatch (although I know we don't nowadays recommend setting a mismatch in
match_ancestors). We surely used to allow matching at sites with multiple mutations, and we will definitely want this if we are matching samples into (for instance) the unified genealogy, where there are currently lots of inference sites with multiple mutations. The HMM approach also works fine in things like sc2ts where there are multiple mutations.So I'm not entirely sure why this restriction now exists - I guess it could just be to restrict the code at the moment to the most common case, and the intention is to change this later. But perhaps I've misunderstood something @jeromekelleher ?