Fix single source gen-anc frequencies on the Variant page

[rileyhgrant]

Resolves #1545

[rileyhgrant]

Tagging you in for review, @ch-kr, in addition to Phil, because I wanted to check on one thing display decision wise.

The v4 exomes and genomes have identical genetic ancestry groups with the exception of ami, which is included presumably because the data was already there from v3 genomes. When both boxes are selected, or just the genomes box is selected, the table will include ami with the respective values there.

When the genomes checkbox is unselected, and only the v4 exome data is shown, should the ami row in the table disappear? The alternative would be to include a row for ami and populate it with AC: 0, AN: 0, AF: -

I'm not sure there's any value to showing it if it's always AC and AN of 0, but also including it keeps it more consistent.

Either is equally doable, I wanted to check on your opinion of what is more clear/preferable.

[ch-kr]

Thanks for the ping!

When the genomes checkbox is unselected, and only the v4 exome data is shown, should the ami row in the table disappear? The alternative would be to include a row for ami and populate it with AC: 0, AN: 0, AF: -

Quick question before I answer: based on this variant, it looks like the ami row currently exists for variants only present in the exomes. Does this question apply to these variants in addition to when a user explicitly selects or unselects the data type checkboxes?

[rileyhgrant]

Thanks for the ping!

When the genomes checkbox is unselected, and only the v4 exome data is shown, should the ami row in the table disappear? The alternative would be to include a row for ami and populate it with AC: 0, AN: 0, AF: -

Quick question before I answer: based on this variant, it looks like the ami row currently exists for variants only present in the exomes. Does this question apply to these variants in addition to when a user explicitly selects or unselects the data type checkboxes?

Gah ok yeah I hadn't thought of that, good catch.

The question specifically was for behavior when the variant is present in both exomes and genomes.

Now I suppose there's another question of what to do for the variants that are not present in one data type, and thus don't allow de-selecting the type its not in. My initial thought there is leave it untouched, e.g. the example variant still includes the genome AN data? But also then if there's joint data maybe it makes sense to allow users to remove the ANs from the other data type that contribute to the overall AN per ancestry group.

[ch-kr]

thanks for clarifying! I think the most consistent behavior is to continue displaying the ami row both for variants only present in the exomes and for variants present in both data types (and where users can choose to unselect the genomes data). This reinforces that the v4 dataset is comprised of both exomes and genomes and also matches the behavior seen when toggling between the full dataset and a subset. For example, here's an example v3 variant -- the ami AC is 1 when all of v3 is selected and becomes 0 when the v3 non-TOPMed subset is selected.

On a slightly related note, this question sort of ties into this slack thread -- we should likely display the genetic ancestry group sample count/counts of each sex karyotype per group for v3/v4 on our stats page (across all groups, without any merged groups, which is what the table on the stats page currently contains)

[rileyhgrant]

thanks for clarifying! I think the most consistent behavior is to continue displaying the ami row both for variants only present in the exomes and for variants present in both data types (and where users can choose to unselect the genomes data). This reinforces that the v4 dataset is comprised of both exomes and genomes and also matches the behavior seen when toggling between the full dataset and a subset. For example, here's an example v3 variant -- the ami AC is 1 when all of v3 is selected and becomes 0 when the v3 non-TOPMed subset is selected.

On a slightly related note, this question sort of ties into this slack thread -- we should likely display the genetic ancestry group sample count/counts of each sex karyotype per group for v3/v4 on our stats page (across all groups, without any merged groups, which is what the table on the stats page currently contains)

Perfect, we'll go with that behavior, thanks so much for the reply and opinion/decision.

[rileyhgrant]

Hiya @phildarnowsky-broad

Tagging you in for review at your convenience. This fix is fairly impactful, and at least one user has written in about this unintended regression, commit by commit should (hopefully) be very bite sized.

[phildarnowsky-broad]

small changes requested but at root this looks good

[rileyhgrant]

Alrighty, added some fixup commits to address comments from code review. Thanks, as always, for your review!

Re-requested you @phildarnowsky-broad