File Changes for lrnassar

v504_preview2 to v504_base (2026-09-14 to 2026-09-21) v504

• src/hg/hgTrackUi/hgTrackUi.c
  • lines changed 8, context: html, text, full: html, text
    ed65d23618ec85f58df1bc341199e904fab55929 Fri Sep 18 00:40:10 2026 -0700
    hgTrackUi: substitute description page variables once, and in the container excerpt too. refs #38283 Removes the hVarSubstTrackDbHtml call in doMiddle. trackUi already calls it at each of the two places that go on to print tdb->html, each after its own quickLift getTrackHtml swap, so the doMiddle call was a second pass over the same text. That second pass ate the escape in $$db, which reached the reader as hg38 in hgTrackUi while hgc correctly showed $db. The plain ajax path returns before any html is printed, so it loses nothing. The Description panel at the top of a subtrack's settings page shows an excerpt of its container's page, and nothing had substituted that one. A hub page using ${db} or ${organism} in its opening paragraph showed the text raw there while the same page rendered correctly further down the screen.
• src/hg/hgTracks/hgTracks.c
  • lines changed 3, context: html, text, full: html, text
    07f0635fd352e098f836664c043aff50449de94e Fri Sep 18 00:17:47 2026 -0700
    hgTracks: reword the density-mode track labels per QA. refs #38279 Say "density graph" to match the checkbox on the track settings page, and name the escape that actually works for each cause: dense mode clears the too-many-items case but does nothing for the maxWindowCoverage one, so the advice was on the wrong message. The window-size label was 90 characters, long enough to push the center label past the edge of the image at ordinary widths and clip the track name along with it.
• src/hg/htdocs/goldenPath/help/trackDb/changes.html
  • lines changed 14, context: html, text, full: html, text
    8d05f42f3315eed8579649f1271899ea8ddd986d Fri Sep 18 00:49:33 2026 -0700
    trackDb hub docs: document the variables a track description page may use. refs #38283 Adds a "Variables in the description page" section to the html setting in trackDbLibrary.shtml, listing ${db}, ${organism}, ${Organism}, ${ORGANISM}, ${date}, ${track}, ${parentTrack} and ${downloadsServer}, with an example of the link a track inside a container can make back to the container's own page. Says plainly that nothing else is substituted, so shell, awk and JavaScript examples on the same page are safe, and that the session id is not available. The section sits after the Example block on purpose. trackDbSettingsGen.py takes the first <pre> in an entry as that setting's example, so a <pre> earlier in the entry overwrites "html docs/myFirstTrack.html" in trackDbSettings.json, which is the file hubCheck -settings reads. Also adds a row to changes.html and regenerates trackDbSettings.yaml. trackDbHub.v3.html needs no change, since this adds no new setting name.
• src/hg/htdocs/goldenPath/help/trackDb/trackDbLibrary.shtml
  • lines changed 34, context: html, text, full: html, text
    8d05f42f3315eed8579649f1271899ea8ddd986d Fri Sep 18 00:49:33 2026 -0700
    trackDb hub docs: document the variables a track description page may use. refs #38283 Adds a "Variables in the description page" section to the html setting in trackDbLibrary.shtml, listing ${db}, ${organism}, ${Organism}, ${ORGANISM}, ${date}, ${track}, ${parentTrack} and ${downloadsServer}, with an example of the link a track inside a container can make back to the container's own page. Says plainly that nothing else is substituted, so shell, awk and JavaScript examples on the same page are safe, and that the session id is not available. The section sits after the Example block on purpose. trackDbSettingsGen.py takes the first <pre> in an entry as that setting's example, so a <pre> earlier in the entry overwrites "html docs/myFirstTrack.html" in trackDbSettings.json, which is the file hubCheck -settings reads. Also adds a row to changes.html and regenerates trackDbSettings.yaml. trackDbHub.v3.html needs no change, since this adds no new setting name.
  • lines changed 15, context: html, text, full: html, text
    64adf565f280a13301d4842582ea9b9c4268f626 Mon Sep 21 03:12:15 2026 -0700
    Document how itemRgb and color interact, and correct the colorFields blurb. refs #36212 The itemRgb entry described what "itemRgb on" does but said nothing about what happens when a stanza also sets "color". That gap is how the two settings came to override each other without anyone noticing. Added the four combinations to the itemRgb blurb: an explicit "itemRgb on" takes the item colors from the file while "color" still colors the track label, "itemRgb off" falls back to "color", "color" alone wins, and a stanza with neither follows the default. The colorFields blurb said item coloring "is suppressed only if the track has an explicit color setting or itemRgb off", which stopped being true with the bedItemRgb() reorder. A color setting no longer suppresses item coloring when the stanza also says "itemRgb on". Reworded to match. trackDbLibrary.shtml supplies the prose for both trackDbDoc.html and the live trackDbHub.html, so this covers both pages. trackDbSettings.yaml is generated from it by "make settings" and is checked in, so it is regenerated here.
• src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml
  • lines changed 31, context: html, text, full: html, text
    8d05f42f3315eed8579649f1271899ea8ddd986d Fri Sep 18 00:49:33 2026 -0700
    trackDb hub docs: document the variables a track description page may use. refs #38283 Adds a "Variables in the description page" section to the html setting in trackDbLibrary.shtml, listing ${db}, ${organism}, ${Organism}, ${ORGANISM}, ${date}, ${track}, ${parentTrack} and ${downloadsServer}, with an example of the link a track inside a container can make back to the container's own page. Says plainly that nothing else is substituted, so shell, awk and JavaScript examples on the same page are safe, and that the session id is not available. The section sits after the Example block on purpose. trackDbSettingsGen.py takes the first <pre> in an entry as that setting's example, so a <pre> earlier in the entry overwrites "html docs/myFirstTrack.html" in trackDbSettings.json, which is the file hubCheck -settings reads. Also adds a row to changes.html and regenerates trackDbSettings.yaml. trackDbHub.v3.html needs no change, since this adds no new setting name.
  • lines changed 15, context: html, text, full: html, text
    64adf565f280a13301d4842582ea9b9c4268f626 Mon Sep 21 03:12:15 2026 -0700
    Document how itemRgb and color interact, and correct the colorFields blurb. refs #36212 The itemRgb entry described what "itemRgb on" does but said nothing about what happens when a stanza also sets "color". That gap is how the two settings came to override each other without anyone noticing. Added the four combinations to the itemRgb blurb: an explicit "itemRgb on" takes the item colors from the file while "color" still colors the track label, "itemRgb off" falls back to "color", "color" alone wins, and a stanza with neither follows the default. The colorFields blurb said item coloring "is suppressed only if the track has an explicit color setting or itemRgb off", which stopped being true with the bedItemRgb() reorder. A color setting no longer suppresses item coloring when the stanza also says "itemRgb on". Reworded to match. trackDbLibrary.shtml supplies the prose for both trackDbDoc.html and the live trackDbHub.html, so this covers both pages. trackDbSettings.yaml is generated from it by "make settings" and is checked in, so it is regenerated here.
• src/hg/htdocs/goldenPath/newsarch.html
  • lines changed 4, context: html, text, full: html, text
    8296c9b7908b7fd73c70b6c7af21c337c55558f4 Mon Sep 21 04:39:42 2026 -0700
    Wording and formatting fixes to the mouseStrainsCactus description page and the AVI news entry, per CR feedback. refs #38351 mouseStrainsCactus.html: use the standard "Display Conventions and Configuration" heading, spell misassemblies without the hyphen, hyphenate large-scale, add the missing commas before "and" in two sentences, finish the Data Access sentence about the API track name, and put the references in alphabetical order by first author. newsarch.html: correct the track group name to "Phenotypes, Variants, and Literature", hyphenate genome-wide, and add the missing "on" in the figure caption.
• src/hg/htdocs/tipOfDay.html
  • lines changed 1, context: html, text, full: html, text
    ba72ed7ec5fd05fb4004419d2cb16b155f13a10f Mon Sep 14 11:20:00 2026 -0700
    Removing the tree copy because this page is regenerated daily, and the tree copy gets copied on the build each weekend and overwrites the fresh regenerated copy. No RM.
• src/hg/makeDb/doc/hg38/fiberSeq.txt
  • lines changed 32, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/doc/hg38/mavemd.txt
  • lines changed 228, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
  • lines changed 1, context: html, text, full: html, text
    fcf788d7357f6f207f2bb0b61acde9dc0507d89f Mon Sep 21 04:04:10 2026 -0700
    Fix two stale figures and guard the accession interpolation in the MaveMD build, per CR. refs #37800 The makeDoc script listing still said the variant converter writes bed12+31. It writes bed12+34, as the autoSql, mavemd.ra, runBuild.sh and the makeDoc's own build-results line all already said. mavemdLib.py's docstring claimed the codon projection is cross-checked against "~154k variants that carry both a genomic and a protein term". 154,895 is the number placed by the genomic route; the cross-check set is the smaller number that also has a resolvable protein term. The docstring now describes the set rather than quoting a figure that drifts with every build. Also adds checkAccession() and calls it before either query that interpolates an accession into SQL. Nothing can currently reach those queries with a quote in it, since the accessions come from PROTEIN_TERM whose character class excludes one, but the regex is a hundred lines from the query and a later edit to it should not be able to open this up silently. Output is byte-identical to the previous build.
• src/hg/makeDb/scripts/fiberSeq/fiberSeqSamples.tsv
  • lines changed 42, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/scripts/fiberSeq/fiberSeqTrackDb.py
  • lines changed 45, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/scripts/mavemd/fetchMaveMd.py
  • lines changed 162, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/scripts/mavemd/makeMaveMdHeatmap.py
  • lines changed 368, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
  • lines changed 28, context: html, text, full: html, text
    97c7de50efd34497c0e3f926f9afeaf9bbe45392 Mon Sep 21 09:10:37 2026 -0700
    Name the assay on every MaveMD map, and add ClinVar and gnomAD as related tracks. refs #37800 Two maps of the same gene routinely disagree, because they measured different things: PTEN abundance against PTEN lipid phosphatase activity, GCK activity against GCK abundance, KCNE1 trafficking with and without KCNQ1. Of the variants measured by more than one score set, 17% get opposite calls, and nothing on the map said why. The assay now travels with the map instead of sitting a click away on the details page. The legend above each matrix names the assay rather than repeating the same colour key on all 84 maps, and every cell mouseover ends with the same line. Method and model system come first because they are short and always present; the score set title is the part that truncates. The separator is a plain hyphen, since the legend is drawn as raster text and an HTML entity would appear literally there. relatedTracks.ra gains one-way links from mavemd to clinvar and gnomadVariants. MaveMD ships a ClinVar and gnomAD snapshot taken from the MaveDB API, and its calibrations were computed against that snapshot, so the imported values stay; the links point readers at our always-current tracks. One-way because MaveMD is too narrow to earn a line on two of the most heavily used tracks we have.
• src/hg/makeDb/scripts/mavemd/makeMaveMdVariants.py
  • lines changed 572, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/scripts/mavemd/mavemdHeatmap.as
  • lines changed 36, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/scripts/mavemd/mavemdLib.py
  • lines changed 332, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
  • lines changed 22, context: html, text, full: html, text
    fcf788d7357f6f207f2bb0b61acde9dc0507d89f Mon Sep 21 04:04:10 2026 -0700
    Fix two stale figures and guard the accession interpolation in the MaveMD build, per CR. refs #37800 The makeDoc script listing still said the variant converter writes bed12+31. It writes bed12+34, as the autoSql, mavemd.ra, runBuild.sh and the makeDoc's own build-results line all already said. mavemdLib.py's docstring claimed the codon projection is cross-checked against "~154k variants that carry both a genomic and a protein term". 154,895 is the number placed by the genomic route; the cross-check set is the smaller number that also has a resolvable protein term. The docstring now describes the set rather than quoting a figure that drifts with every build. Also adds checkAccession() and calls it before either query that interpolates an accession into SQL. Nothing can currently reach those queries with a quote in it, since the accessions come from PROTEIN_TERM whose character class excludes one, but the regex is a hundred lines from the query and a later edit to it should not be able to open this up silently. Output is byte-identical to the previous build.
• src/hg/makeDb/scripts/mavemd/mavemdVariants.as
  • lines changed 50, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/scripts/mavemd/runBuild.sh
  • lines changed 43, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/human/hg38/fiberSeq.html
  • lines changed 10, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/trackDb/human/hg38/fiberSeq.ra
  • lines changed 410, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/trackDb/human/hg38/fiberSeqAcc.html
  • lines changed 9, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
• src/hg/makeDb/trackDb/human/hg38/fiberSeqCompendium.html
  • lines changed 24, context: html, text, full: html, text
    156d289f517d82c4d5a8c59981dfec21a715af8d Mon Sep 21 09:22:45 2026 -0700
    Fiber-seq QA fixes: take sample class from the lab's own table, pin the overlay draw order, and correct the description pages. refs #36210 Sample class had been guessed from the free-text cell type with a two-name exception list, which filed five lymphoblastoid lines as HPRC that are not. It now comes from a fifth column in fiberSeqSamples.tsv carrying the classification the lab supplies, and sampleClass()/NOT_HPRC are gone. Facet counts go from 25/16 to 20/21. The CpG difference track is a solidOverlay whose four files hold the same value at a shared base, so the tier drawn last is the colour the reader sees. Its children inherited a single priority from the parent, trackPriCmp ties on that, and slSort is not stable, so the paint order was arbitrary and p<0.01 was covering p<0.0001. The four levels and the two haplotype children now carry explicit priorities. At chr20:29,300,000-29,305,000 red goes from 2 image columns to 88. CpG haplotype children take their shortLabel prefix from their container, so they read "<sample> CpG Hap1" rather than colliding with the accessibility children's "<sample> Hap1". 82 labels were duplicated. Description pages: fiberSeqAcc.html attached the FIRE score's "fewer than four elements" cutoff to the percent accessible signal, which is a different quantity; two pages overstated how many of the lymphoblastoid lines come from HPRC; both pages told readers to query the API with container track names, which it refuses by design. Also documents GM12878's trio phasing and the FDR ceiling at 100, corrects the difference track's stated range, replaces a non-ASCII author name with numeric entities, and adds db= to hgTrackUi links. makeDoc: corrects a basesCovered figure that was out by a factor of a hundred, refreshes the peak file sizes after the PM00001 reissue, rewrites the sampleClass rationale, and records why multiWig children need their own priority.
  • lines changed 6, context: html, text, full: html, text
    5179d7fac0a1a1bbb6f78ad6b9862b42493eb8d8 Mon Sep 21 09:34:26 2026 -0700
    Fiber-seq: drop two unsupported claims about GM12878's phasing. refs #36210 The page said GM12878 is the only sample here whose haplotypes come from a trio. The pipeline in Vollger et al. attributes phase blocks with parental short-read data and meryl "when available", so trio phasing is the normal route wherever parental sequence exists, not something peculiar to this sample, and the paper already describes GM12878 as parentally binned well before the September reprocessing. It also gave a cause for the empty haplotype files, that most molecules had been left unassigned. Shane raised that possibility on the thread and Andrew contradicted it the next day; the files themselves were 512-byte stubs covering a single base, which is a processing failure rather than a phasing outcome. The page now says only what is certain: the files were placeholders, the lab re-ran the sample with parental sequence added for phasing, and the tracks now carry data.
• src/hg/makeDb/trackDb/human/hg38/mavemd.html
  • lines changed 93, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/human/hg38/mavemd.ra
  • lines changed 53, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/human/hg38/mavemdMap.html
  • lines changed 194, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/human/hg38/mavemdVar.html
  • lines changed 187, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/human/hg38/trackDb.ra
  • lines changed 2, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
• src/hg/makeDb/trackDb/mouse/mm10/mouseStrainsCactus.html
  • lines changed 43, context: html, text, full: html, text
    8296c9b7908b7fd73c70b6c7af21c337c55558f4 Mon Sep 21 04:39:42 2026 -0700
    Wording and formatting fixes to the mouseStrainsCactus description page and the AVI news entry, per CR feedback. refs #38351 mouseStrainsCactus.html: use the standard "Display Conventions and Configuration" heading, spell misassemblies without the hyphen, hyphenate large-scale, add the missing commas before "and" in two sentences, finish the Data Access sentence about the API track name, and put the references in alphabetical order by first author. newsarch.html: correct the track group name to "Phenotypes, Variants, and Literature", hyphenate genome-wide, and add the missing "on" in the figure caption.
• src/hg/makeDb/trackDb/relatedTracks.ra
  • lines changed 4, context: html, text, full: html, text
    29af14b47208040441ab4ff7acf51aac71cad4e2 Thu Sep 17 21:58:18 2026 -0700
    Adding MaveMD track, clinically calibrated multiplexed variant effect measurements on hg38. refs #37800 MaveMD is a curated collection inside MaveDB holding the score sets with clinical relevance, restricted to genes with a moderate or stronger gene-disease association. Data come from the MaveDB API rather than the Zenodo snapshots, at the request of the MaveDB team, who also set the request pacing the fetch script follows. Two views under a new phenDis container. mavemdVar draws one item per measured variant per score set, carrying the assay score, the functional class, the ACMG/AMP functional evidence code and strength where the score set is calibrated, the assay metadata, and matching ClinVar and gnomAD annotations. mavemdMap draws each score set as a variant effect map, one column per amino acid position and one row per substitution, reusing Jonathan's heatmap display from the MaveDB track. MaveDB resolves about a third of the collection to the genome and the rest only to a protein sequence, so variants are placed from the genomic HGVS term where one exists, otherwise by projecting the protein term onto its codon through ncbiRefSeqLink and ncbiRefSeqCurated for RefSeq accessions or the GENCODE tables for Ensembl ones, otherwise by running the submitted transcript term through hgvsToVcf. The projection is cross-checked against the variants carrying both coordinate systems and the build aborts if they disagree beyond a threshold. Codons split across an exon junction are written as BED12 with the two real blocks. Haplotypes cannot be given a single position and are excluded, with every dropped measurement counted by reason in the makeDoc. Also adds reciprocal relatedTracks entries between mavedb and mavemd. Gated alpha pending QA.
  • lines changed 11, context: html, text, full: html, text
    97c7de50efd34497c0e3f926f9afeaf9bbe45392 Mon Sep 21 09:10:37 2026 -0700
    Name the assay on every MaveMD map, and add ClinVar and gnomAD as related tracks. refs #37800 Two maps of the same gene routinely disagree, because they measured different things: PTEN abundance against PTEN lipid phosphatase activity, GCK activity against GCK abundance, KCNE1 trafficking with and without KCNQ1. Of the variants measured by more than one score set, 17% get opposite calls, and nothing on the map said why. The assay now travels with the map instead of sitting a click away on the details page. The legend above each matrix names the assay rather than repeating the same colour key on all 84 maps, and every cell mouseover ends with the same line. Method and model system come first because they are short and always present; the score set title is the part that truncates. The separator is a plain hyphen, since the legend is drawn as raster text and an HTML entity would appear literally there. relatedTracks.ra gains one-way links from mavemd to clinvar and gnomadVariants. MaveMD ships a ClinVar and gnomAD snapshot taken from the MaveDB API, and its calibrations were computed against that snapshot, so the imported values stay; the links point readers at our always-current tracks. One-way because MaveMD is too narrow to earn a line on two of the most heavily used tracks we have.