File Changes for angie

v391_preview2 to v391_base (2019-11-18 to 2019-12-02) v391

• src/hg/hgc/hgc.c
  • lines changed 26, context: html, text, full: html, text
    f0d09119e54af30308746dd1c5d4f0178f07af72 Thu Nov 21 10:45:56 2019 -0800
    When displaying ncbiRefSeq alignments, use ncbiRefSeqCds not gbCdnaInfo which may have a different version. refs #24554
• src/hg/inc/bigDbSnp.h
  • lines changed 2, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
• src/hg/lib/bigDbSnp.c
  • lines changed 5, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
• src/hg/makeDb/doc/bigDbSnp.txt
  • lines changed 64, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
  • lines changed 104, context: html, text, full: html, text
    6974f14d41a28ed1198110de47946370cfc2bb73 Fri Nov 22 10:29:44 2019 -0800
    dbSnp153: When different freq alleles can be expanded by different amounts, pad out the smaller range & alleles for consistency. refs #23283 One variant (rs782394990) was dropped because of that quirk, but now no variants are dropped. :) A few ucscNotes increased by 1 or 2. Some of the counts of various ucscNotes were a little out of date due to recent work on adding freq notes instead of dropping; up to date now. I was all proud of this but it's a dead end. One b153 variant, rs782394990, errored out because its freq alleles couldn't be expanded by the same amount. The insertions of pure A's could be expanded to a larger range than an ins that included a T in addition to A's. So I siezed upon the problem of independently trimmed and expanded SPDIs resulting in inconsistent dels, and set about trimming by list instead of trimming each SPDI separately. I would restrict the expansion to the minimum range by which any allele could be shifted. That would fix the problem of independent del's for rs782394990. However, there was a problem. A variant that includes both an ins and a del that could be expanded to the same range, e.g. rs201454468 with alleles ref=T, alt="", alt=TT, cannot be trimmed as a list because it already has "". T/"" is already minimal. However, T/TT is not already minimal and needs to be minimized before expansion. So no expansion was performed, and we ended up with inconsistent alleles between different sources because one was expanded (it had only the del) and the other wasn't. No good. I think that's why, although I was trimming listwise already, I did another trim just before trying to expand. Is there even a point in trimming listwise? So... back to individual trimming of each SPDI. And individual expansion. But what do we do about the 1 in 680M case of rs782394990? I think we should detect inconsistent dels -- and then pad out all dels and inses to the maximal range. So for the allele that could be shifted 2 bases less than the others because it included a T, just pad its del and ins with genomic bases. OK, now it works. Squash branch into master...
• src/hg/makeDb/trackDb/human/dbSnp153Composite.html
  • lines changed 19, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
  • lines changed 39, context: html, text, full: html, text
    6974f14d41a28ed1198110de47946370cfc2bb73 Fri Nov 22 10:29:44 2019 -0800
    dbSnp153: When different freq alleles can be expanded by different amounts, pad out the smaller range & alleles for consistency. refs #23283 One variant (rs782394990) was dropped because of that quirk, but now no variants are dropped. :) A few ucscNotes increased by 1 or 2. Some of the counts of various ucscNotes were a little out of date due to recent work on adding freq notes instead of dropping; up to date now. I was all proud of this but it's a dead end. One b153 variant, rs782394990, errored out because its freq alleles couldn't be expanded by the same amount. The insertions of pure A's could be expanded to a larger range than an ins that included a T in addition to A's. So I siezed upon the problem of independently trimmed and expanded SPDIs resulting in inconsistent dels, and set about trimming by list instead of trimming each SPDI separately. I would restrict the expansion to the minimum range by which any allele could be shifted. That would fix the problem of independent del's for rs782394990. However, there was a problem. A variant that includes both an ins and a del that could be expanded to the same range, e.g. rs201454468 with alleles ref=T, alt="", alt=TT, cannot be trimmed as a list because it already has "". T/"" is already minimal. However, T/TT is not already minimal and needs to be minimized before expansion. So no expansion was performed, and we ended up with inconsistent alleles between different sources because one was expanded (it had only the del) and the other wasn't. No good. I think that's why, although I was trimming listwise already, I did another trim just before trying to expand. Is there even a point in trimming listwise? So... back to individual trimming of each SPDI. And individual expansion. But what do we do about the 1 in 680M case of rs782394990? I think we should detect inconsistent dels -- and then pad out all dels and inses to the maximal range. So for the allele that could be shifted 2 bases less than the others because it included a T, just pad its del and ins with genomic bases. OK, now it works. Squash branch into master...
• src/hg/makeDb/trackDb/human/trackDb.ra
  • lines changed 2, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
  • lines changed 1, context: html, text, full: html, text
    c0401cde5d3035571adf6898d572a60f756d0af2 Mon Nov 18 15:36:10 2019 -0800
    dbSnp153: Use new FilterLabel setting to replace the long definition of numeric maxFuncImpact column with a label that is more congruent with dropdown choices. refs #23283
  • lines changed 1, context: html, text, full: html, text
    4e0719d608c56995a991d31ce5c03ac9db7010ca Wed Nov 27 10:06:58 2019 -0800
    Make dbSnp153BadCoords gray. refs #23283
• src/hg/makeDb/trackDb/tagTypes.tab
  • lines changed 1, context: html, text, full: html, text
    c0401cde5d3035571adf6898d572a60f756d0af2 Mon Nov 18 15:36:10 2019 -0800
    dbSnp153: Use new FilterLabel setting to replace the long definition of numeric maxFuncImpact column with a label that is more congruent with dropdown choices. refs #23283
• src/hg/snp/dbSnpJsonToTab/dbSnpJsonToTab.c
  • lines changed 61, context: html, text, full: html, text
    726a4c9c82592c662ae6b8c715e67b783c95beb3 Mon Nov 18 13:45:42 2019 -0800
    Instead of dropping rs IDs that have incomplete frequency data, add two new ucscNotes: freqIncomplete and freqNotMapped. refs #23283
  • lines changed 240, context: html, text, full: html, text
    6974f14d41a28ed1198110de47946370cfc2bb73 Fri Nov 22 10:29:44 2019 -0800
    dbSnp153: When different freq alleles can be expanded by different amounts, pad out the smaller range & alleles for consistency. refs #23283 One variant (rs782394990) was dropped because of that quirk, but now no variants are dropped. :) A few ucscNotes increased by 1 or 2. Some of the counts of various ucscNotes were a little out of date due to recent work on adding freq notes instead of dropping; up to date now. I was all proud of this but it's a dead end. One b153 variant, rs782394990, errored out because its freq alleles couldn't be expanded by the same amount. The insertions of pure A's could be expanded to a larger range than an ins that included a T in addition to A's. So I siezed upon the problem of independently trimmed and expanded SPDIs resulting in inconsistent dels, and set about trimming by list instead of trimming each SPDI separately. I would restrict the expansion to the minimum range by which any allele could be shifted. That would fix the problem of independent del's for rs782394990. However, there was a problem. A variant that includes both an ins and a del that could be expanded to the same range, e.g. rs201454468 with alleles ref=T, alt="", alt=TT, cannot be trimmed as a list because it already has "". T/"" is already minimal. However, T/TT is not already minimal and needs to be minimized before expansion. So no expansion was performed, and we ended up with inconsistent alleles between different sources because one was expanded (it had only the del) and the other wasn't. No good. I think that's why, although I was trimming listwise already, I did another trim just before trying to expand. Is there even a point in trimming listwise? So... back to individual trimming of each SPDI. And individual expansion. But what do we do about the 1 in 680M case of rs782394990? I think we should detect inconsistent dels -- and then pad out all dels and inses to the maximal range. So for the allele that could be shifted 2 bases less than the others because it included a T, just pad its del and ins with genomic bases. OK, now it works. Squash branch into master...