Ann, Sorry! My time on G2G has been very sparse and hit-or-miss the past couple of months.
And, yeah; I just kind of danced over "imputation" with no explanation, didn't I? Then again, nobody really wants more word-count from me. <cough>
But what I was thinking of specifically is AncestryDNA. They don't give us a chromosome browser or chromosomal detail, but they do provide us more insight than do most about their process to arrive at DNA matches. You know this better than I do, but for everyone else's entertainment and as a super-quick summary...
Ancestry starts with a form of computational phasing based on genotyping, or how your DNA compares to reference models. To help compensate for population genetic differences, they subdivide each chromosome into tiny "microsegments" of 96 SNPs each. They use a type of "hashing" function, a form of imputation, to more efficiently compare these microsegments across their entire database. Matching starts at that microsegment level, and then they step farther away in both directions along the chromosome, one SNP at a time, to check if they still match. When they bump into a pair of alleles that are a mismatch regardless of the computational phasing, that's the segment demarcation (unlike GEDmatch, whose defaults allow a very lenient number of mismatches).
Then comes the proprietary Timber algorithm which, I think, has a bad rep. It's job is to de-emphasize, or down-weight, the matching information that is less likely to be informative of closer relationships. This takes into account not just documented pile-up regions, but how an individual's results compare (wrongly or not, I refer to these as "haplotypic pile-up regions") to the entire dataset. Ancestry describes it this way:
"The strategy is to analyze matching results accumulated over a large number of genotype samples, then identify, separately for each individual, regions of the genome with unusually high rates of matching. Once we have identified these regions, we reduce the genetic distance of detected IBD segments overlapping these regions. We call these adjusted distances 'Timber scores.'"
By definition, yep, imputation is augmentative. It's all about guessing the value of something that wasn't actually tested. But I think it can be used as a constraint, as well, to better qualify the genealogical/ancestral value of a segment by some fancy extrapolation of how it compares to a large dataset of multiple populations.
Ultimately the point, though, was that GEDmatch does nothing of the kind, as far as I know. Discounting the "slimming" procedure which I've never seen a detailed explanation of (at least not detailed enough to inform us of what, exactly, they're throwing away), everything at GEDmatch is simple arithmetic.
And, I believe unfortunately, since the advent of Genesis going into production and the need to compare across DNA tests that may have as few as 23% of the same SNPs tested, they've loosened their default matching criteria at least twice. For the free one-to-one matching tool, the minimum SNP count used to be 700. Now, it's a dynamically adjusted threshold where two-thirds of the segments deemed as valid will have considered only 185 to 214 of the same SNPs. That's a huge difference. And the "mismatch-bunching limit," GEDmatch's allowance for alleles that are actually non-matching, is whatever that SNP window is, then divided by 2. They also introduced the option to "prevent hard breaks"; it isn't on by default, but checking it allows gaps of over a half-million base pairs to be present and still consider the segment to be continuous and unbroken. For a small chromosome like Chr 21, a gap that size represents over 1% of the overall chromosome.
I'm rambling. Not unusual. ;-) But unless I know what parameters someone has applied to their match reporting at GEDmatch, I've come to basically discount any segment that isn't at least in the high teens in centiMorgan calculation.
P.S. When did you upload that whopping 39-million-SNP file to GEDmatch? I've never been able to get a complete answer about how large their catalog is--in other words, the maximal number of markers they will accept and where we can download a list of those--and since I began trying to use WGS data there in 2019, I've never been able to get anything larger than a file just under 4 million SNPs to upload. That's been all trial and error beyond the collection of SNP "templates" that WGSExtract uses. And interestingly, the 3.9-million-SNP file ended up being "slimmed" to very nearly the same 1.1-1.2 million count as the WGSExtract "combined" kits.
