Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle CTX_PP/QQ and CTX_PQ/QP CPX_TYPE values in SVConcordance #8885

Merged
merged 5 commits into from
Jul 1, 2024

Conversation

epiercehoffman
Copy link
Contributor

CTX events have CTX_PP/QQ or CTX_PQ/QP as CPX_TYPE values in GATK-SV VCFs. However, slashes are not allowed as part of enum values, so these are represented in the ComplexVariantSubtype enum as CTX_PP_QQ and CTX_PQ_QP. This caused the CTX subtypes to not be recognized and to be dropped during SVConcordance (broadinstitute/gatk-sv#664).

This representation may merit further discussion, as it's not ideal that the ComplexVariantSubtype values are not a 1:1 match with the VCF values. But as one possible solution without altering the VCF, I've implemented a workaround that replaces the slash with an underscore during getComplexSubtype. I've also updated SVAnnotate to use this method, in the hopes that we can use it across all of the SV tools for more consistent behavior.

I added a unit test for getComplexSubtype with one regular CPX_TYPE, one CTX subtype, and one non-CPX event. The test suites for SVCallRecord, SVCallRecordUtils, SVAnnotate, and SVConcordance all ran successfully on my branch.

Copy link
Contributor

@mwalker174 mwalker174 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing this @epiercehoffman.

I don't see an issue with CPX_SUBTYPE containing /. It's certainly within the spec. I also would rather not force a formatting change if we don't have to (and if we did we would also need to modify gatk-sv to use _ instead of / in the first place so that vcfs are consistent throughout the pipeline). These kinds of changes usually cause a lot of confusion.

First, let's change the parsing behavior to not rely on the use of ComplexVariantSubtype.valueOf() and instead define a HashBiMap<String, ComplexVariantSubtype> over in GATKSVVCFConstants to define the conversion. You'll have to also modify SVCallRecordUtils.getVariantBuilder() to handle the conversion back to a String using the bimap. A unit test for the conversion back would be a good idea as well.

Copy link
Contributor

@mwalker174 mwalker174 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small suggestion

@@ -95,6 +101,26 @@ public enum ComplexVariantSubtype {
CTX_INV
}

// keep in sync with enum above
public static final HashBiMap<String, ComplexVariantSubtype> ComplexVariantSubtypeMap = HashBiMap.create(Map.ofEntries(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public static final HashBiMap<String, ComplexVariantSubtype> ComplexVariantSubtypeMap = HashBiMap.create(Map.ofEntries(
public static final HashBiMap<String, ComplexVariantSubtype> COMPLEX_VARIANT_SUBTYPE_MAP = HashBiMap.create(Map.ofEntries(

@epiercehoffman epiercehoffman merged commit 4af2b49 into master Jul 1, 2024
21 checks passed
@epiercehoffman epiercehoffman deleted the eph_ctx_subtypes branch July 1, 2024 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants