-
Notifications
You must be signed in to change notification settings - Fork 22
gnomad svs #1031
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
gnomad svs #1031
Conversation
…b.com:broadinstitute/seqr-loading-pipelines into benb/gnomad_svs
…ing-pipelines into benb/gnomad_svs
…es into benb/gnomad_svs
I don't think it is a good idea for the previously loaded SVs in seqr to be annotated with one version of gnomad and the new samples to be annotated with a different version. Are we planning to go back and update the annotations for everything we currently have? |
I don't think we have the capability to go back and update any of the old variants. I know we, at some point, discussed how the gnomad annotations work and whether or not we should own them as part of our pipeline, and I believe the answer was to leave them as part of the WDL. That leaves us in this situation though. |
This is a blocker for us accepting the data from the Talkowski team, as having a random mix of gnomad versions within a seqr project is an unacceptable end user experience. They either need to deliver us a callset that is annotated with the SAME annotations as past data, specifically using the same version of gnomad, or they need to deliver us an updated version of the previous callset with updated gnomad annotations |
👍 I will follow up. |
Closing in favor of moving gnomad to reference dataset + SVConcordance. |
Updates the gnomad sv field names.