Empty primary_assembly_loci but filled alt_genomic_loci for "NC_000024.9:g.9197998C>T".

[ifokkema]

Describe the bug
My pipeline complained about NC_000024.9:g.9197998C>T not having any genomic mappings. The APIs didn't fill the primary_assembly_loci key; instead, the data is in the alt_genomic_loci field. But also in a very weird way... it's a list of objects, instead of an object/dict, and the NCs are gone. Do you have any clue why? Is this normal? Should I update my LOVD-VV library to handle this?

To Reproduce
See link above.

Expected behavior
I don't see why the genomic mappings wouldn't be in the primary_assembly_loci field.

[Peter-J-Freeman]

Interesting.

Ill look into this.

Off the top of my head, the Y chromosome is moved to ALT loci in pseudo autosomal regions. This is because we can only handle 1 primary assembly chromosome.

However, it was designed on submission of c. descriptions for genes on both X and Y.

I will add additional context so that if the gene is in the Par but on Y only, make Y the primary assembly.

However, for genes on chr 23 and chr 24, you will likely need to parse the alts for the Y chromosome in addition to the X.

Let me get some examples made up in testing and I'll pass them on.

[Peter-J-Freeman]

Also, if you have preferred behaviour, let me know.

The issue we have is that without severely changing the output json, one of the chromosomes has to go to ALT for genes appearing in both the x and y.

[ifokkema]

Off the top of my head, the Y chromosome is moved to ALT loci in pseudo autosomal regions. This is because we can only handle 1 primary assembly chromosome.

Ah, right, I forgot about that... but I think I handled that already... probably in the code that handles c. to g.. But then I don't remember that the structure of the alt is so different.

Also, if you have preferred behaviour, let me know.

Does it make sense that if the input is chrY, that I only get chrY back in the primary assembly? Otherwise, I should add code that checks if the chr that I get back is a different one than I put in.

[Peter-J-Freeman]

Does it make sense that if the input is chrY, that I only get chrY back in the primary assembly? Otherwise, I should add code that checks if the chr that I get back is a different one than I put in.

Yeah, that was pretty much my thinking. If Y only then send to Primary Assembly, otherwise itll have to go to ALTS

[ifokkema]

Yeah, that was pretty much my thinking. If Y only then send to Primary Assembly, otherwise itll have to go to ALTS

Just to be sure; this should depend on the input, right? If I have chrY input and get chrX and chrY output, then the chrX should go to the alternative.

[Peter-J-Freeman]

OK, this is a VF issue not a VV issue and may not be related to PAR at all

VV

import json
import VariantValidator
vval = VariantValidator.Validator()
variant = 'NC_000024.9:g.9197998C>T'
genome_build = 'GRCh38'
select_transcripts = 'all'
validate = vval.validate(variant, genome_build, select_transcripts, transcript_set="refseq")
validation = validate.format_as_dict(with_meta=True)
print(json.dumps(validation, sort_keys=True, indent=4, separators=(',', ': ')))

        "primary_assembly_loci": {
            "grch37": {
                "hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
                "vcf": {
                    "alt": "T",
                    "chr": "Y",
                    "pos": "9197998",
                    "ref": "C"
                }
            },
            "grch38": {
                "hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
                "vcf": {
                    "alt": "T",
                    "chr": "Y",
                    "pos": "9360389",
                    "ref": "C"
                }
            },
            "hg19": {
                "hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
                "vcf": {
                    "alt": "T",
                    "chr": "chrY",
                    "pos": "9197998",
                    "ref": "C"
                }
            },
            "hg38": {
                "hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
                "vcf": {
                    "alt": "T",
                    "chr": "chrY",
                    "pos": "9360389",
                    "ref": "C"
                }
            }
        },

This is because the code looks for

                # Identify Pseudo Autosomal Regions
                chrX = False
                chrY = False
                par = False
                for g_var in multi_gen_vars:
                    if 'NC_000023' in g_var.ac:
                        chrX = True
                    if 'NC_000024' in g_var.ac:
                        chrY = True
                if chrX is True and chrY is True:
                    par = True

and only if par = True does it push the Y chromosome to ALT. @ifokkema wants this to also happen in VF, which is returning

{
"NC_000024.9:g.9197998C>T": {
"NC_000024.9:g.9197998C>T": {
"g_hgvs": "NC_000024.9:g.9197998C>T",
"genomic_variant_error": null,
"genomic_variant_warnings": null,
"hgvs_t_and_p": {
"NM_001243721.2": {
"alt_genomic_loci": [
{
"grch37": {
"hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
"vcf": {
"alt": "T",
"chr": "Y",
"pos": "9197998",
"ref": "C"
}
}
},
{
"hg19": {
"hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
"vcf": {
"alt": "T",
"chr": "chrY",
"pos": "9197998",
"ref": "C"
}
}
},
{
"grch38": {
"hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
"vcf": {
"alt": "T",
"chr": "Y",
"pos": "9360389",
"ref": "C"
}
}
},
{
"hg38": {
"hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
"vcf": {
"alt": "T",
"chr": "chrY",
"pos": "9360389",
"ref": "C"
}
}
}
],
"gap_statement": null,
"gapped_alignment_warning": null,
"gene_info": {
"hgnc_id": "HGNC:37471",
"symbol": "TSPY8"
},
"p_hgvs_slc": null,
"p_hgvs_tlc": null,
"primary_assembly_loci": {
"grch37": {},
"grch38": {},
"hg19": {},
"hg38": {}
},
"select_status": {
"mane_select": true
},
"t_hgvs": "NM_001243721.2:c.911C>T",
"transcript_variant_error": null,
"transcript_version_warning": null
}
},
"p_vcf": "Y:9197998:C:T",
"selected_build": "GRCh37"
},
"errors": [],
"flag": null
},
"metadata": {
"variantformatter_version": "4.0.0",
"variantvalidator_hgvs_version": "4.0.0",
"variantvalidator_version": "4.0.1.dev7+gbdab9c72f",
"vvdb_version": "vvdb_2025_3",
"vvseqrepo_db": "VV_SR_2025_02/master",
"vvta_version": "vvta_2025_02"
}
}

[Peter-J-Freeman]

ok, can now do

import json
import VariantFormatter
import VariantFormatter.simpleVariantFormatter
batch_results_from_string = VariantFormatter.simpleVariantFormatter.format('NC_000024.9:g.9197998C>T', 'GRCh37', 'refseq', 'mane_select', False, 'False')
print(json.dumps(batch_results_from_string, sort_keys=False, indent=4, separators=(',', ': ')))

{
"NC_000024.9:g.9197998C>T": {
"NC_000024.9:g.9197998C>T": {
"g_hgvs": "NC_000024.9:g.9197998C>T",
"genomic_variant_error": null,
"genomic_variant_warnings": null,
"hgvs_t_and_p": {
"NM_001243721.2": {
"alt_genomic_loci": [
{
"grch37": {
"hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
"vcf": {
"alt": "T",
"chr": "Y",
"pos": "9197998",
"ref": "C"
}
}
},
{
"hg19": {
"hgvs_genomic_description": "NC_000024.9:g.9197998C>T",
"vcf": {
"alt": "T",
"chr": "chrY",
"pos": "9197998",
"ref": "C"
}
}
},
{
"grch38": {
"hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
"vcf": {
"alt": "T",
"chr": "Y",
"pos": "9360389",
"ref": "C"
}
}
},
{
"hg38": {
"hgvs_genomic_description": "NC_000024.10:g.9360389C>T",
"vcf": {
"alt": "T",
"chr": "chrY",
"pos": "9360389",
"ref": "C"
}
}
}
],
"gap_statement": null,
"gapped_alignment_warning": null,
"gene_info": {
"hgnc_id": "HGNC:37471",
"symbol": "TSPY8"
},
"p_hgvs_slc": null,
"p_hgvs_tlc": null,
"primary_assembly_loci": {
"grch37": {},
"grch38": {},
"hg19": {},
"hg38": {}
},
"select_status": {
"mane_select": true
},
"t_hgvs": "NM_001243721.2:c.911C>T",
"transcript_variant_error": null,
"transcript_version_warning": null
}
},
"p_vcf": "Y:9197998:C:T",
"selected_build": "GRCh37"
},
"errors": [],
"flag": null
},
"metadata": {
"variantformatter_version": "4.0.0",
"variantvalidator_hgvs_version": "4.0.0",
"variantvalidator_version": "4.0.1.dev7+gbdab9c72f",
"vvdb_version": "vvdb_2025_3",
"vvseqrepo_db": "VV_SR_2025_02/master",
"vvta_version": "vvta_2025_02"
}
}

But we need some PAR genes to test that both tools are doing what they should. Will also see if I can add good warnings to help users too

[Peter-J-Freeman]

Both VF and VV will now provide a warning and VF will no longer push chrY to the alts unless chrX and chrY are in the output.

[Peter-J-Freeman]

@ifokkema It will take a little time to migrate this to the servers as we are doing a few fixes

[ifokkema]

Cool, thanks! Does this also address the structural differences between primary_assembly_loci and alt_genomic_loci, or are they meant to differ so much?

[Peter-J-Freeman]

Sorry, you mean the structural differences in #810?

If so, we are working on it and it will go into the next patch

[ifokkema]

Sorry, you mean the structural differences in #810?

If so, we are working on it and it will go into the next patch

No, I meant the different ways to represent genomic mappings in the JSON structure. But in that issue, comparing the outputs, I realize there are even three different ways that VV/VF does this:

VV:

"primary_assembly_loci": {
    "grch37": {
        "hgvs_genomic_description": "NC_000009.11:g.95237063_95237068dup",
        "vcf": {
            "alt": "CTCATCA",
            "chr": "9",
            "pos": "95237024",
            "ref": "C"
        }
    }
}

VF:

"primary_assembly_loci": {
    "grch37": {
        "NC_000009.11": {
            "hgvs_genomic_description": "NC_000009.11:g.95237063_95237068dup",
            "vcf": {
                "chr": "9",
                "pos": "95237024",
                "ref": "C",
                "alt": "CTCATCA"
            }
        }
    }
}

VV and VF:

"alt_genomic_loci": [
    {
        "grch38": {
            "hgvs_genomic_description": "NW_025791788.1:g.309510_309515dup",
            "vcf": {
                "chr": "HG1012_PATCH",
                "pos": "309509",
                "ref": "T",
                "alt": "TCATCTG"
            }
        }
    }
}

So that's:

• object -> build -> hgvs_genomic_description
• object -> build -> NC -> hgvs_genomic_description
• array of objects -> 0 -> build -> hgvs_genomic_description

But I realize now that you need that array because you don't store the NCs there, and you don't store the NCs either in the VV output. So VF, for alt_genomic_loci, is using the VV-style structure as used in primary_assembly_loci, instead of the VF-like structure...

[Peter-J-Freeman]

you know what, I never realised the VF/VV primary assembly differences until you pointed this out. I am now very much wishing that VV had the VF structure, as this would solve the PAR issue.

They should have been identical.

So, for VF, I can keep the Y chr in the primary assembly potentially, but not in VV, and yes, this is why we ended up with the array structure.

This must have happened when I developed the tool

"primary_assembly_loci": {
    "grch37": {
        "NC_000009.11": {
            "hgvs_genomic_description": "NC_000009.11:g.95237063_95237068dup",
            "vcf": {
                "chr": "9",
                "pos": "95237024",
                "ref": "C",
                "alt": "CTCATCA"
            }
        }
    }
}

It works well for PAR only, but for 99.9% of genes etc, it is a really annoying over-formatting!!! I would ideally like to migrate it to the VV format, but wont.