Symbolic variant length not adjusted for indels between genome builds

[davmlaw]

Thanks for the tool!

I know about the warning:

Warning: input VCF includes symbolic alleles that might not properly lift over

but thought it would be useful to explicitly list issues w/Symbolic alts.

To recreate:

• Liftover a symbolic variant that spans an indel between genome builds

# GRCh38 variant - NM_139025.4(ADAMTS13):c.1_2057del
9	133422442	1144	G	<DEL>	.	.	SVLEN=-20044;SVTYPE=DEL;END=133442486

Expected behavior:

• The length of the symbolic variant is altered to reflect the indel in the destination build

Actual behaviour:

• The length always remains the same. END is recalculated as pos + old variant length (and SVLEN is untouched)

Converting this to a c.HGVS gives: NM_139025.4(ADAMTS13):c.-1_2055del

Workaround:

• If you explicitly convert the symbolic alt into explicit bases, things work fine (input grch38 ref size of 20045, output grch37 ref size 20046)

I've attached a zip file that contains a working example with a symbolic and explicit alt, and the output vcfs

bcftools_liftover_symbolic.zip

[freeseek]

You can rewrite the variant as non-symbolic but the BCFtools/liftover model would not work that well and is not appropriate for this. You can use UCSC liftover if you want to liftover larger intervals (but there is no guarantee that they will lift to a single interval). In general I discourage lifting over single variants this large because they will inevitably overlap with other variants differing across the two reference genomes, causing quite a bit of headaches

[davmlaw]

Thanks for feedback. I think 20kb explicit works but if you think it is purely a length problem not symbolic/explicit maybe write a warning out once if detected like symbolic warning?

I understand all liftover comes with issues, we are just unable to get people who send us variants to remap their data to different genomes so we'll take what we can get...

[davmlaw]

FYI I'm going to use 1kb as a maximum cutoff, let me know if that's wildly wrong. I know it's somewhat arbitrary

Is the problem not so much the length but multiple chain blocks? If so, perhaps give that as a warning in the INFO and maybe 1st on command line?

[freeseek]

There is indeed the warning you reported given out once when symbolic alleles are detected:

Warning: input VCF includes symbolic alleles that might not properly lift over

I am not sure what you mean with "going to use 1kb as a maximum cutoff". There is an option --max-indel-inc which is used to choose the sequence length to use when realigning against the reference. The importance of this option is for when you have an indel whose edges/anchors get mapped by the chain file to very distant places on the same chromosome and it instructs the plugin for when to attempt realigning and when to give up, depending on how far the two edges/anchors map. This will not be used for symbolic alleles as these are pretty much treated as SNPs. If you need to understand better how the model works I would advise to read Genovese et al. 2024

[davmlaw]

I am using 1kb as a max cutoff for length attempting lift over, it seems you recommended against long variants, not just symbolic

You can rewrite the variant as non-symbolic but the BCFtools/liftover model would not work that well and is not appropriate for this. You can use UCSC liftover if you want to liftover larger intervals (but there is no guarantee that they will lift to a single interval). In general I discourage lifting over single variants this large

[freeseek]

Yeah, long variants, like large CNVs, are likely to overlap with other variants, and that complicates the lift over

[davmlaw]

Hi, thanks for the feedback. Could you please clarify exactly what you mean?

the BCFtools/liftover model would not work that well and is not appropriate for this

Could you confirm that the liftover issue for long variants is mainly due to accuracy limits beyond a certain length?

overlap with other variants

When you say variants do you mean indels in genome reference?

Or do you mean a complication for some downstream analyses with multiple VCF records?

Because my example file only gave 1 variant, and I am not really concerned if it swaps genomic order with other variants or goes from overlapping to non-overlapping etc

Thanks!

[freeseek]

What I mean is that variants that you would obtain by aligning your data to one reference (e.g. GRCh38) would not be the same as variants that you would obtain by aligning your data to another reference (e.g. GRCh37) and then performing liftover. To understand some of these issues, see the examples in Genovese et al. 2024

[davmlaw]

Sorry I re read the paper and couldn't find the info.

Could you please link to the examples that demonstrate why "model would not work that well and is not appropriate for this" and what specifically this is, and how someone someone is supposed to know?

I read the paper when it came out and I adopted the tool because a feature was listed as "Updates INFO/END field" which I perhaps misinterpreted as implying support for structural variants/ symbolic alts

It sounds you are describing general liftover issues and I have previously stated:

I understand all liftover comes with issues, we are just unable to get people who send us variants to remap their data to different genomes so we'll take what we can get...