¿ªÔÆÌåÓý

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

Re: Family Finder tests entering the Y-DNA haplotree

 

I know that one of the tests was my uncles. He was moved to R-S15510.

On Thursday, December 7, 2023 at 07:54:34 AM CST, Iain via groups.io <gubbins@...> wrote:


Hi folks,


A quick note to say that overnight the first batch of Y-DNA haplogroups from Family Finder tests has entered the haplotree. Nearly 12,000 tests have been added to the haplotree in the last four weeks, the vast majority of which have appeared since yesterday and are therefore presumably these new tests.


These are early stages, and we don't yet have the answers to a lot of questions. For example, we don't yet have a good idea of which haplogroups are included in this analysis. That will become clearer as we go through the results, as they are released. Charles is in the process of regrouping the tests with new results, and has told me it includes Z30 and Z326. Hopefully we will find out more soon.


Cheers,


Iain.


Re: Family Finder tests entering the Y-DNA haplotree

 

Thank you- Iain.? The Little Project has two of these initial returns, they happen to be brothers and they have landed on R-S18823, which is indeed under Z306 and U106.? My question will be whether I should encourage them to join this Project, but I plan to wait for the dust to settle. The thing with no STRs displayed is very weird and will take some getting used to.

The son of one of these kits has a Y-111 and, based on his father's results, I have asked him to join the U106 project. He was designated R-M269, so it's a good example, perhaps, of the resolution of the FF results regarding Y-haplogroups.

- Tom Little, admin
The Little Surname DNA Project


Family Finder tests entering the Y-DNA haplotree

 

¿ªÔÆÌåÓý

Hi folks,


A quick note to say that overnight the first batch of Y-DNA haplogroups from Family Finder tests has entered the haplotree. Nearly 12,000 tests have been added to the haplotree in the last four weeks, the vast majority of which have appeared since yesterday and are therefore presumably these new tests.


These are early stages, and we don't yet have the answers to a lot of questions. For example, we don't yet have a good idea of which haplogroups are included in this analysis. That will become clearer as we go through the results, as they are released. Charles is in the process of regrouping the tests with new results, and has told me it includes Z30 and Z326. Hopefully we will find out more soon.


Cheers,


Iain.


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

 
Edited

Thank you Mike for this interesting feedback. R-M269 is not the only haplogroup affected by these differences.
?
The cohabitation between bigY500 and 700 sometimes gives some curious results. In my autosomal matches, I have a match with a bigY500 tester whose haplogroup Y does not exist in the haplotree (starting with R-FTT; just like R-Z14 is not there either). This SNP only appears in a terminal haplogroup, composed of 2 SNPs. My guess is that this kit does not have an usable reading (or a no call) at the 2nd SNP position.
?
Cheers,
?
Ewenn


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

 

I asked FTDNA about your question and have a little more info on one issue.

1- "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??"

They told me that Discover tree data is technically correct. The Haplotree is a bit behind on this. The R-M269 block will be updated on the Haplotree but the R-M269 block is not the highest priority they have for updating the Haplotree database, which sits in a production environment and affects haplogroup assignments in projects, etc.

2- "the cohabitation between bigY500 and bigY700 tests does not seem very ideal."

Certainly, straight apples to apples comparisons are important and Big Y700 has additional coverage. Right now, the Big Y700 is just under 85% of the database of Big Y individuals, so so this problem decreases every year but is still important.


Re: FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

 

¿ªÔÆÌåÓý

Thanks Tom. We¡¯ll have to wait and see how these haplogroup reports turn out. In theory, FTDNA could add lots of custom Y-SNPs to the microarray they use for the Family Finder test to give a more detailed haplogroup assignment but I¡¯m not sure if they¡¯ve done this.

?

I was a virtual attendee at the FTDNA Group Administrators¡¯ Conference and heard the news about the MyHeritage trees. I believe we did discuss this on the list at the time. The issue with the MyHeritage trees is that you are restricted to 250 people with a free account but any tree is better than nothing. I¡¯m still not sure how FTDNA are going to handle the process of linking autosomal DNA matches to trees when the trees are hosted on a different website altogether.

?

Debbie

?

From: [email protected] <[email protected]> On Behalf Of T J Little via groups.io
Sent: Friday, December 1, 2023 12:45 PM
To: [email protected]
Subject: Re: [R1b-U106] FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

?

Thanks Debbie.? I think it's worth remarking here that the FTDNA lab processes the MyHeritage autosomal tests. We asked at the conference, and they confirmed this, but explained MyHeritage then has their own proprietary analysis. As you read that the autosomal transfers from MyHeritage will be included in some reports and other companies' transfers will not, this could be at least part of that explanation.?

If you didn't hear, FTDNA also announced at the conference that they plan to dump the current family tree utility and incorporate the MyHeritage family tree as the integral tree utility. This is interesting news--mostly good. And, if a member happens to already be a MyHeritage user, seems like all this is good news for them.?
- Tom Little
Little Project Admin?

_._,_._,_


Re: FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

 

Thanks Debbie.? I think it's worth remarking here that the FTDNA lab processes the MyHeritage autosomal tests. We asked at the conference, and they confirmed this, but explained MyHeritage then has their own proprietary analysis. As you read that the autosomal transfers from MyHeritage will be included in some reports and other companies' transfers will not, this could be at least part of that explanation.?

If you didn't hear, FTDNA also announced at the conference that they plan to dump the current family tree utility and incorporate the MyHeritage family tree as the integral tree utility. This is interesting news--mostly good. And, if a member happens to already be a MyHeritage user, seems like all this is good news for them.?
- Tom Little
Little Project Admin?


Two-factor authentication and match list/chromosome browser downloads

 

¿ªÔÆÌåÓý

FTDNA have also advised group administrators of the following.

?

On the website, we have temporarily blocked users from having the ability to download files that include matches and/or Chromosome Browser data and added the note, "The option to download your matches list and segment data is currently unavailable as we work on enhancements. We appreciate your patience and apologize for any inconvenience.¡±

?

The pages and downloads include the following:

  • Family Finder Matches - Export CSV
  • Chromosome Browser - Download All Segments
  • Chromosome Browser - Download Segments (Chromosome View and Detailed Segments)
  • mtDNA Matches - Download: CSV
  • Y-DNA Matches - Export CSV
  • Big Y Results - Export Matches CSV
  • Advanced Matches - Download: CSV


These downloads will remain blocked until two-factor authentication is rolled out early next year.

?

Debbie Kennett

?


Re: FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

 

¿ªÔÆÌåÓý

Here is the relevant text from the e-mail sent to FTDNA Group Administrators:

?

Y-DNA Haplogroups for Family Finder Customers

?

We are excited to begin releasing the long-awaited feature to provide haplogroups for autosomal test takers. We are starting this week with small batches of about 2,000 kits per day to monitor the progress and make sure everything is working as intended, and we will see how long it takes for them to process.

?

Once we have an idea of the timeframe and have verified that everything looks good, then we will start processing existing kits in larger batches and turn on the pipeline for new purchases to get Y-DNA haplogroups when their results are posted.

  • Customers on the current chip, which was introduced in March 2019, will receive results first.
    • Customers who purchased and received results between August 1 (when we announced the update) and November 30 will be in the first batches.
  • Once we have completed the current chip, we will start processing the older chips. Once those are complete, unlocked transfers will be processed.

?

Important Notes:

?

Customers who transferred from Ancestry or 23andMe and have unlocked their transfer will be able to view their Y-DNA haplogroup, but it will not be used in the Y-DNA haplotree or Discover? statistics, nor will their matches or group projects be able to view it.

?

Customers who tested with MyHeritage and Vitagene and have unlocked their transfers will be visible to matches.

?

Customers who took a Family Finder test directly with FamilyTreeDNA will be able to see:

  • Y-DNA haplogroup badge (confirmed haplogroup)
  • Y-STR Results section with Y-DNA haplotree & Y-SNPs and Discover reports
  • Y-SNP download file under Family Finder Results¨CDownload Raw Data

?

Like a customer who has done a Y-STR or Big Y test:

  • Their Y-DNA haplogroup will be counted in the Haplotree and Discover statistics
  • Their matches will be able to view their Y-DNA haplogroup,
  • The Y-DNA haplogroup will be visible in Group Projects (if they have a test that shows up in project reports).

?

Y-STR Tests and Autosomal Tests in Group Projects

  • For project members who have Y-STR tests and an Ancestry or 23andMe transfer, their STR-predicted Y-DNA haplogroup will show in the project.
  • For project members have a Y-STR test and a MyHeritage or Vitagene transfer, their Family Finder Y-DNA haplogroup will show in the project.
  • For project members who do not have a Y-STR test but are in Group Projects, their Y-DNA haplogroup will show under the SNP Report if it is from a Family Finder test or an unlocked MyHeritage/Vitagene transfer.
  • For project members with Ancestry and 23andMe unlocked transfers, their Y-DNA haplogroup from Family Finder will not have display on the Y-SNP report.

?

?

Debbie Kennett

?


Re: FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

 

Hi,

This is indeed excellent news. We should in theory see the number of testers positive for certain R-U106 subclades increase quite significantly. I guess the available SNPs depend on the chip version (V1 to V3) used for autosomal testing. I don't know if it will be possible for us to know the list of SNPs supported by these different chip versions.

Cheers,

Ewenn


FamilyTreeDNA provides Y-DNA haplogroups from Family Finder autosomal tests

 
Edited

Sorry folks. Didn't know where else to post this but its good news.
?
"Big News!?FamilyTreeDNA?is delivering holiday gifts early!

Y DNA?haplogroups are beginning to be delivered as a free benefit to men who took the?Family Finder?test at?FamilyTreeDNA. This is the first wave of a staggered rollout. Haplogroup results will be delivered to several thousand people at a time, in batches, beginning today.

This is no trivial gift and includes LOTS of information that can be used in various ways for your genealogy. Please feel free to share this article. The new?Family Finder?haplogroups are another reason to take a?Family Finder?test and to encourage other family members to do so as well."

?


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

 

In addition, the deletion of FT354122 was not linked to the upgrade from a bigY500 test to a bigY700. This was, it seems to me, more linked to its detection on a certain number of aDNAs which did not however belong to this branch.


Le jeu. 30 nov. 2023 ¨¤ 20:39, Ewenn via <gwenng008=[email protected]> a ¨¦crit?:
Hi Iain,?

Thank you for your reply.

Yes, that¡¯s what I observe in my match. Ultimately, when the number of bigY tests will have increased considerably, the number of resilient PVs should drop considerably, and undoubtedly lose their interest.

Aren't some recurring SNPs also likely to one day be deleted from NMV lists? I suppose, given the imperfection of the GRCh38 reference, that some of these may be somehow "puppets", and not actually imply a valid mutation between 2 tests. If we were to one day move to a new comprehensive reference, taking into account the entire Y chromosome (and the rest of the human genome), as well as all its variations (also including all the existing, sometimes very long, indels), I presume that certain current results would ultimately be invalidated (bad alignments for example - this should in particular be even more true as we move away, in the Y tree, from the person who served as the basis for the development of the GRCh38 reference).

Cheers,

Ewenn



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

 

Hi Iain,?

Thank you for your reply.

Yes, that¡¯s what I observe in my match. Ultimately, when the number of bigY tests will have increased considerably, the number of resilient PVs should drop considerably, and undoubtedly lose their interest.

Aren't some recurring SNPs also likely to one day be deleted from NMV lists? I suppose, given the imperfection of the GRCh38 reference, that some of these may be somehow "puppets", and not actually imply a valid mutation between 2 tests. If we were to one day move to a new comprehensive reference, taking into account the entire Y chromosome (and the rest of the human genome), as well as all its variations (also including all the existing, sometimes very long, indels), I presume that certain current results would ultimately be invalidated (bad alignments for example - this should in particular be even more true as we move away, in the Y tree, from the person who served as the basis for the development of the GRCh38 reference).

Cheers,

Ewenn



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

 

¿ªÔÆÌåÓý

Hi Ewenn,


The private variants list is essentially stripped straight out of the VCF file, from what I can tell. Private variants will gradually get replaced with named SNPs, which will lead to changes over time. Is this what you are seeing? Alternatively, SNPs can appear and disappear if a tester upgrades from BigY-500 to BigY-700.


For realignment, remember that we have already had a realignment from hg19/GRCh37 to h38/GRCh38. A realignment to T2T has certainly been tried for a few tests (hence the FTT series of SNPs), but I don't know if they are planning a wider roll-out.


Cheers,


Iain.


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


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

 

Hello Ewen

<mutations can sometimes be deleted from the list of PVs associated with a kit, without this being reflected on the associated bigY match(es)

If I am reading your post correctly, this is something I have never seen/noticed. That presumes that your PVs are what ISOGG refers to as singletons, and not the other PV (Public Variants). Unless you are suggesting that Kit A has singleton 9 deleted, while it remains on the Kit B singleton Private Variant list; which would be much stranger again.

What I do notice is that men with only Big Y-500 results typically have more/many NMVs than men with Big Y-700 results. If I remember correctly Iain has previously advised us to ignore them (in the main), as they are typically inconsistent.

Working with a mixture of Y500 and Y700 results, obviously presents many problems. So much so, that FTDNA have offered (in the current sale) the chance to get a new Big Y-700 for a true bargain basement price. We should encourage everyone with Big Y-500 to get (on average) 50% more singletons (and other SNPs too) by jumping into Big Y-700 while it is so cheap (about 1/4 usual price).

FTDNA's recent blog might be of interest to some too.


Kind regards
John




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

 

Hi, all!

Thank you, John and Iain, for the information you've shared with me!??

John - if I understand correctly, the X in the non matching variants column means the two kits have greater than 30 non matching variants.??

My follow up question is - what is the cutoff for being shown as a match on the block tree?? The match that has X in the NMV column shows up as a match in the block tree.? It's confusing to me that the match is considered a match one place - in the block tree, but not in another - the match list. So the two reports must have different cutoff thresholds?

Iain - I so appreciate your offer, but I don't want to trouble you unnecessarily?with looking at the kit - I have a query in to FTDNA, and hopefully they can clear up the analysis of this kit compared to the Big Y match.

With much appreciation,?

Mary

?

On Tuesday, November 28, 2023 at 10:40:40 PM EST, John T via groups.io <z343snp@...> wrote:


Hello Mary

It is not often (in fact a first) that I can elucidate in respect of an Iain McDonald answer.

An x in the NMV column always means more than 30 NMVs, and is only ever shown where you have Y37/67/111 matches with someone with Big Y results.

Hello Iain

It is not the first time we have seen shading below Big Y blocks. I am hoping that as on other occasions it will revert back to what we usually see. Probably hoping a bit too much that it might herald some enhancement. Maybe the display of academic and other 'hidden' results.

Kind regards
John

On Wednesday, 29 November 2023 at 08:43:39 am ACDT, Iain via groups.io <gubbins@...> wrote:


Hi all - apparently FTDNA have taken away the average number of private variants from each haplogroup on the Block Tree. The teal-coloured blocks that used to denote these have been replaced throughout by hashed-out boxes.


Mary - happy to look into your kits, but I'll need the kit numbers - feel free to send me them privately. The "x" either means there are no mis-matching variants (say, if you have a match within your immediate family) or that data is absent due to some error. If you've already written to FTDNA, they'll be able to give you a more authoritative answer than I can.



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

 

Hi Mary,

Several answers have already been provided to you by other members, more competent than I am, and FTDNA should shed more light on the issue you are having with these kits. Therefore, what follows will probably provide you with little useful information.

It indeed seems to me (almost) impossible to know the list of NMVs between two kits if it exceeds the number of 30. The PV average indicated in the block tree corresponds to the average of Private Variants of the set of kits attached to a particular haplogroup (excepted some of them if they fall into specific parts of the Y chromosome, it seems to me). These have not yet been given a name (in fact, most of them have, if you search on YBrowse based on their position on the Y chromosome - FTDNA has pre-registered these with ISOGG). However, in the list of NMVs between 2 kits, a number of mutations have already been observed elsewhere in the Y tree, and are therefore named. In the example you give to us (with the X), the NMVs with the kit above indicate a single PV and 16 NMVs already named (most starting with BY18...).
My personal experience has shown me that mutations can sometimes be deleted from the list of PVs associated with a kit, without this being reflected on the associated bigY match(es) (I don't know if this list of NMVs between 2 kits is likely to be updated). Perhaps similar circumstances could give the following situation: initial list of NMVs > 30 => deletion of certain irrelevant variants bringing this number below this threshold => refresh in the Block Tree without refresh in the list of bigY matches. .. This is just a very uncertain hypothesis.

Since the two kits you are interested in are quite old, I assume that TMRCA have been estimated for the corresponding haplogroup(s). In this case, a TMRCA rather distant from the present (~1950) should be associated with a fairly high number of NMVs between those kits. Conversely, if the number of NMVs is relatively small, the corresponding TMRCA should be more recent (however the calculation of TMRCA, with other parameters which are not all known at the moment, also takes into account STR distances, and does not in principle take into account certain NMVs).

Cheers,?

Ewenn

Le mer. 29 nov. 2023 ¨¤ 11:19, Iain via <gubbins=[email protected]> a ¨¦crit?:

Thanks John - that's what comes of not reading the original post carefully enough! :)


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

 

¿ªÔÆÌåÓý

Thanks John - that's what comes of not reading the original post carefully enough! :)


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

 

Hello Mary

It is not often (in fact a first) that I can elucidate in respect of an Iain McDonald answer.

An x in the NMV column always means more than 30 NMVs, and is only ever shown where you have Y37/67/111 matches with someone with Big Y results.

Hello Iain

It is not the first time we have seen shading below Big Y blocks. I am hoping that as on other occasions it will revert back to what we usually see. Probably hoping a bit too much that it might herald some enhancement. Maybe the display of academic and other 'hidden' results.

Kind regards
John

On Wednesday, 29 November 2023 at 08:43:39 am ACDT, Iain via groups.io <gubbins@...> wrote:


Hi all - apparently FTDNA have taken away the average number of private variants from each haplogroup on the Block Tree. The teal-coloured blocks that used to denote these have been replaced throughout by hashed-out boxes.


Mary - happy to look into your kits, but I'll need the kit numbers - feel free to send me them privately. The "x" either means there are no mis-matching variants (say, if you have a match within your immediate family) or that data is absent due to some error. If you've already written to FTDNA, they'll be able to give you a more authoritative answer than I can.


Cheers,


Iain.