¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: Match on block tree but not listed as Big Y Match


 

Hi John,

?

Indeed, the cohabitation between bigY500 and bigY700 tests does not seem very ideal. Imagine if we had to move to a T2T reference and long reads tests...

?

Coming back to the Private Variants deletions, I¡¯ve done a ??shortcut??.

?

My personal test initially (end of 2021) had 12 PVs, and that of my only match 10. Towards the end of 2022, or perhaps the beginning of 2023, I only had 10 PVs and 8 (it seems to me) for this match. In my case, it's not actually deletion. In reality, these variants went from being PVs, presented only by their position on the Y chromosome, to being NMVs with a defined name. For example, 19 363 847 became FTA36935 (which is also associated with R-BY40294), or 25 614 603 became BY237271 (SNP which does not seems to appear on the Y Tree).

?

I also observed at the same time that the average number of PVs of other terminal haplogroups close to mine had also been revised downwards. No new kit had appeared on these branches, which could potentially explain these changes.

?

In conclusion, the list of PVs associated with a kit can be reviewed without a new test appearing close to its terminal haplogroup, or forming a new haplogroup with it.

?

Another "curiosity", but which seems more logical to me, following the appearance of a bigY700 tester on a branch initially formed from a mix between bigY500 and Y700 tests, SNPs initially associated with a haplogroup were moved upwards to an upstream haplogroup of this branch.

?

However, it effectively very rarely happens that certain ¡°established¡± SNPs, and associated as equivalent to a haplogroup, are ultimately simply deleted from the Haplotree. An example with FT354122 (I seem to remember having found a few other deleted SNPs in the past, but I can't get my hands on it), registered in 2020 by FTDNA with ISOGG, initially associated with the R-FT253286 block (3 testers positive to date). This one was finally deleted by FTDNA at the end of 2022 (without the appearance of any new tester). I suppose that FTDNA had reached the conclusion that this SNP was invalid, without knowing precisely why (linked to the imperfection of the GRCh38 reference?). So I suppose (that's where I made my shortcut) that some PVs could also ultimately prove inconsistent.

?

I'm not really convinced that this could be the correct explanation for the issue Mary is having. As I said, this is only a very uncertain hypothesis... To be plausible, the first condition to be fulfilled would be that the list of NMVs associated with matches (and therefore non-matches) in the big Y Results is not re-evaluated following modifications, for old tests (which I would find rather annoying by the way). I would lean more towards the explanation presented by Ray Wings.

?

It seems to me that to this day there are still gray areas on how FTDNA interprets test results, considers a mutation as valid (or reassess it later), sets certain criteria or limits (sometimes differently from one tool / list to another), constructs its Y-DNA Haplotree, etc. This sometimes seems to lead to misunderstanding among testers.

?

An example, for a long-established haplogroup, such as R-M269 (among others), the Y-DNA Haplotree indicates 97 equivalent SNPs, compared to 112 for Discover¡­ Why these 15 additional SNPs are not part of the Y-DNA Haplotree??

Kind regards,

Ewenn

Join [email protected] to automatically receive all group messages.