PDA

View Full Version : DF27* from Kyiv (Kiev) has Big Y results



lgmayka
06-29-2015, 08:13 PM
Kit 153495 from Kyiv (Kiev, Ukraine) has received his Big Y results. As far as I can see, he remains true DF27*. His BAM file has been requested. Right now, his account says "No VCF File Found". I hope that will be fixed without the need for a formal complaint.

Chad Rohlfsen
06-29-2015, 09:15 PM
Awesome! I'll get my full panel in the next couple months.

Gray Fox
06-29-2015, 09:21 PM
Awesome! I'll get my full panel in the next couple months.

Good deal! Very interested to see where you will fall.

razyn
06-30-2015, 08:18 PM
Kit 153495 from Kyiv (Kiev, Ukraine) has received his Big Y results. As far as I can see, he remains true DF27*. His BAM file has been requested. Right now, his account says "No VCF File Found". I hope that will be fixed without the need for a formal complaint.
He's sort of a pen pal, and I had looked at his results yesterday -- the Shared Novel Variants are weird. (That function has been working right for a week or so, for other new kits.) All of his matches are with just three guys, two of whom are U152. The one match who is DF27+ is in the Z2571 group -- not specifically Rox2 or DF84, but that group. I suppose it's conceivable that he's in some DF27 subclade so nearly basal it's real, but at first glance it looks more like a matching program glitch, to me.

But then the A00 Perry sample looked like a glitch, until they figured him out.

Edit: Just looked again, now he has 8 matches, instead of just 3... but the one at the top of the list is that same guy (whose shared novel variants are working much better, seems to me yesterday he had 276 of them). We are only interested in the ones near the bottom of a normal list -- this guy from Kyiv has such a short list, they are all near the bottom, but it's very, very suspect. Maybe the data wheels are just grinding slowly?

lgmayka
06-30-2015, 09:18 PM
Just looked again, now he has 8 matches, instead of just 3... but the one at the top of the list is that same guy (whose shared novel variants are working much better, seems to me yesterday he had 276 of them). We are only interested in the ones near the bottom of a normal list -- this guy from Kyiv has such a short list, they are all near the bottom, but it's very, very suspect. Maybe the data wheels are just grinding slowly?
His situation is roughly comparable to kit 148821 of R-CTS2617 (< U152) (http://yfull.com/tree/R-CTS2617/), except that:
- My Kyivan friend-of-a-friend is even more basal, a true singleton
- Big Y has far fewer DF27 participants than U152 participants.

That said, kit 148821 has:
- 1 at distance 0 (a genuine CTS2617+ match)
- 5 at distance 2
- 7 at distance 3
- 21 at distance 4

But you are correct that FTDNA has probably not completed the Kyivan's distance-4 match list.

razyn
06-30-2015, 11:54 PM
I never look at those "zero distance" results; even if the match happens to be real, they only refer to known SNPs, and I'm much more interested in unknown ones. Those are only seen in the Shared Novel Variants; only when that function works correctly (as I believe it has yet to do, for our Kyivan); and only at the bottom of that list -- not the top. I don't care if he matches 276 tested samples -- most not in his haplogroup, and one or two not even in his species. (They have tested gorilla and chimp samples -- those "known" SNPs begin with P, for Primate.) A lot of the widely shared SNPs are recurrent, otherwise unstable, or so far up the tree they don't inform or affect my DF27 haplogroup project.

I suppose that's off-topic.

Btw I think we have BigY results in hand for about 255 DF27 guys. And FGC results for a few more, though of course those aren't visible in FTDNA project lists of tested SNPs, etc.

lgmayka
07-01-2015, 12:09 AM
Those are only seen in the Shared Novel Variants; only when that function works correctly (as I believe it has yet to do, for our Kyivan); and only at the bottom of that list -- not the top.
I see no malfunction at all. The Shared Novel Variants dropdown shows:
1 unstable location has (3)
1 unstable location has (4)
4 locations have (7)
52 locations have all (8)

This is about what I would expect of a DF27* singleton.

Kit 64890 is a singleton for Z149* (< L2 < U152). He has 298 so-called matches, but even his most "exclusive" Shared Novel Variant has 101 sharers.

razyn
07-01-2015, 02:17 AM
This is about what I would expect of a DF27* singleton.

Well, I wouldn't. I mean actually I wouldn't expect to find anyone really DF27* after a BigY; but if I did, I think his Shared Novel Variants would look more like those of N34129 Boaz, about the most un-matched guy in the project... he has 498 matches at the top of his list (those useless ones) and only one variant shared with two guys, at the bottom. Unfortunately that variant is in the 125 bp repeat region, and therefore highly suspect (or, hard to test credibly, whatever).

Anyway, I still think 153495 doesn't have a good list, yet -- program glitch -- but his Novel Variants themselves are displaying correctly, or as correctly as anybody else's. So I started down my little checklist (handwritten, I don't do much with spreadsheets). And it took about three minutes to see that he is positive for BY653, which is at 16258837, A-G. We have a group for that, group Q; and he is now in it. He has several off-modals in common with Roseberry, of that group -- and not with the Chamberlain guys (who are related).

lgmayka
07-01-2015, 03:21 AM
He now has 484 "matches." In the Shared Novel Variants dropdown, his lowest counts are:
16258837 (3) - BY653, shared with Roseberry and Chamberl(a)in
19947053 (9) - unreliable, includes U152 guys

So the question now is whether Roseberry and/or Chamberl(a)in have submitted their BAM files to YFull, so that we can better estimate the age of East/West divergence within this subclade.

razyn
07-01-2015, 05:06 AM
I believe Chamberlin is YF02839. Not on the tree, which usually means he has no match in their db yet. Also I don't see Roseberry on the list; but not everybody submits his own kit, some are under another name (a family member, or an admin, etc.).

lgmayka
07-01-2015, 01:24 PM
I believe Chamberlin is YF02839. Not on the tree, which usually means he has no match in their db yet.
YF02839 is on the haplotree, but at the unresolved-P312 (R-P312 but not R-P312*) level (http://yfull.com/tree/R-P312/). This means that from his BAM file alone, YFull could not determine whether he belonged to any subclade of P312. I am afraid that YFull will come to the same conclusion with #153495.

The question then is whether YFull will depict the BY653 subclade at all, and if so where. I will ask Vladimir Tagankin what YFull's policy is in such cases. I will emphasize to him that both kits have tested DF27+ via Sanger sequencing.

I have already submitted the Kyivan's BAM file to YFull for analysis.

ArmandoR1b
07-01-2015, 01:44 PM
YF02839 is on the haplotree, but at the unresolved-P312 (R-P312 but not R-P312*) level (http://yfull.com/tree/R-P312/). This means that from his BAM file alone, YFull could not determine whether he belonged to any subclade of P312. I am afraid that YFull will come to the same conclusion with #153495.

The question then is whether YFull will depict the BY653 subclade at all, and if so where. I will ask Vladimir Tagankin what YFull's policy is in such cases. I will emphasize to him that both kits have tested DF27+ via Sanger sequencing.

I have already submitted the Kyivan's BAM file to YFull for analysis.

So now you are seeing first hand an example of DF27 not being found in a BigY file by YFull. It makes one wonder about some of the other kits under P312 that don't have a subclade.

lgmayka
07-01-2015, 02:15 PM
It makes one wonder about some of the other kits under P312 that don't have a subclade.
This is why YFull carefully distinguishes between proven R-P312* vs. unresolved R-P312. But the question is whether YFull customers can submit "out-of-band" information (e.g., Sanger sequencing results) in order to resolve placement. I shall see what Vladimir says.

ArmandoR1b
07-01-2015, 02:43 PM
This is why YFull carefully distinguishes between proven R-P312* vs. unresolved R-P312. But the question is whether YFull customers can submit "out-of-band" information (e.g., Sanger sequencing results) in order to resolve placement. I shall see what Vladimir says.

What are you calling proven R-P312* ?

lgmayka
07-01-2015, 03:14 PM
What are you calling proven R-P312* ?
Proven R-P312* (with an asterisk) would be someone whose BAM file shows a negative (ancestral) result for every subclade of P312. YFull's haplotree (http://yfull.com/tree/R-P312/) lists no such examples.

Unresolved R-P312 (without an asterisk) is the category for someone whose BAM file shows no positive (derived) results, but at least one no-call or ambiguous result, for the subclades of P312. YFull's tree shows 13 customers, and 1 research sample, in this category.

The question is whether YFull is willing to accept Sanger results to resolve these cases.

ArmandoR1b
07-01-2015, 03:38 PM
Proven R-P312* (with an asterisk) would be someone whose BAM file shows a negative (ancestral) result for every subclade of P312. YFull's haplotree (http://yfull.com/tree/R-P312/) lists no such examples.

Unresolved R-P312 (without an asterisk) is the category for someone whose BAM file shows no positive (derived) results, but at least one no-call or ambiguous result, for the subclades of P312. YFull's tree shows 13 customers, and 1 research sample, in this category.

The question is whether YFull is willing to accept Sanger results to resolve these cases.

Are the YFull customers that are unresolved R-P312 notified that they might be positive for DF27 but in order to determine that they need an individual SNP test?

Are the proven R-DF27* customers informed that it is only temporary since at some point there should be more downstream SNPs identified in the future that they are positive (derived) for?

razyn
07-01-2015, 03:51 PM
I believe Chamberlin is YF02839. Not on the tree

I was actually just looking at the DF27/S250 part of the tree. It didn't occur to me to look higher, since I already know BY653 is DF27+.

YF02839 is a member of the DF27 group, at YFull. I also had looked there (for him and Roseberry).

lgmayka
07-01-2015, 04:56 PM
The question is whether YFull is willing to accept Sanger results to resolve these cases.
Vladimir has assured me that the information and hyperlinks I have provided are sufficient to place BY653 properly under DF27, when the BAM file of #153495 (i.e., a second example of BY653+) has been analyzed.

lgmayka
07-01-2015, 05:07 PM
Are the YFull customers that are unresolved R-P312 notified that they might be positive for DF27 but in order to determine that they need an individual SNP test?
The YFull analysis contains a telltale sign of such ambiguity (even besides the cryptic R-P312 instead of R-P312*), but the customer has to be able to recognize it. Here is an example of what it looks like, from the YFull account of my cousin who has a no-call at Z49 (< L2 < U152):
---
Y-Haplogroup: R-L2
Hg variants: R-L2*, R-Z49*
---

This means that the customer is officially listed as R-L2 (not R-L2*). He could belong to either R-L2* or R-Z49*. My cousin's Sanger sequencing actually found him to be Z49+ .


Are the proven R-DF27* customers informed that it is only temporary since at some point there should be more downstream SNPs identified in the future that they are positive (derived) for?
This is inherent to the operation of a haplotree, and is perhaps the greatest single selling point of YFull's service: Once you are placed on their haplotree, you will automatically be reclassified to a more precise level whenever a closer match comes along.

ArmandoR1b
07-01-2015, 05:31 PM
The YFull analysis contains a telltale sign of such ambiguity (even besides the cryptic R-P312 instead of R-P312*), but the customer has to be able to recognize it.
That was my concern. There are possibly some customers without enough knowledge to recognize the meaning and if they are R-P312 instead of R-P312* but actually positive for DF27 and BigY misses DF27 more than 90% of the time then some of those R-P312 customers could be in the dark about the possibility that they are DF27.


This is inherent to the operation of a haplotree, and is perhaps the greatest single selling point of YFull's service: Once you are placed on their haplotree, you will automatically be reclassified to a more precise level whenever a closer match comes along.

Is that relayed to them directly with their results or is that just on the page that they are expected to read and realize they most likely will be reclassified fairly soon? I already knew that they automatically reclassify I just don't know what the consumer with a limited understanding of the process experiences.