HPRC release 2 graph, indexed for JBrowse 2 =========================================== These files are a redistribution, not original data. They are tabix-indexed BED projections of a graph published by the Human Pangenome Reference Consortium, built so that JBrowse can query a locus without downloading the graph. Source ------ https://s3-us-west-2.amazonaws.com/human-pangenomics/pangenomes/freeze/ release2/minigraph-cactus/hprc-v2.0-mc-grch38.sv.gfa.gz 841,612,966 bytes. The SV-resolution projection of the Minigraph-Cactus graph, 464 haplotypes on a GRCh38 backbone. It comes from the graph's minigraph stage, so every segment carries rGFA tags (SN/SO/SR), which is what makes these coordinate projections possible. HPRC data is released under CC0. See https://github.com/human-pangenomics/hpp_pangenome_resources for the release itself and its terms. Files ----- hprc-v2.0-mc-grch38.segs.bed.gz{,.tbi} one row per segment: stable name, span, id, rank 751,237 segments hprc-v2.0-mc-grch38.links.bed.gz{,.tbi} one row per link per endpoint, each repeating both endpoints hprc-v2.0-mc-grch38.bubbles.bed.gz{,.tbi} gfatools bubble output, 130,510 bubbles hprc-v2.0-mc-grch38.alleles.bed.gz{,.tbi} one row per allele the graph holds, derived from segs+links: 208,545 alleles (112,995 insertions, 90,108 deletions, 5,442 same-length substitutions) Stable names are PanSN (GRCh38#0#chr1), so a JBrowse track on an ordinary hg38 assembly needs assemblyNameToPanSN: { "hg38": "GRCh38" }. How they were built ------------------- wget # segs + links, via scripts/build_rgfa_tabix.sh in GMOD/jbrowse-components gfatools gfa2bed -m <(gzip -dc hprc-v2.0-mc-grch38.sv.gfa.gz) \ | sort -k1,1 -k2,2n | bgzip > hprc-v2.0-mc-grch38.segs.bed.gz tabix -p bed hprc-v2.0-mc-grch38.segs.bed.gz # (links.bed.gz joins each L line against the segment table; see the script) # bubbles gzip -dc hprc-v2.0-mc-grch38.sv.gfa.gz | gfatools bubble - \ | sort -k1,1 -k2,2n | bgzip > hprc-v2.0-mc-grch38.bubbles.bed.gz tabix -p bed hprc-v2.0-mc-grch38.bubbles.bed.gz # alleles, via scripts/build_rgfa_alleles.sh in GMOD/jbrowse-components bash build_rgfa_alleles.sh hprc-v2.0-mc-grch38 gfatools: https://github.com/lh3/gfatools Built 2026-07-23 with gfatools from git HEAD; alleles added 2026-07-26. Alleles rebuilt 2026-07-26 after a fix to build_rgfa_alleles.sh. The walk used to decide an allele had rejoined the reference by looking up a table of departures keyed on (segment, orientation). Every L-line has two equivalent directions and the file states one, so when the other was written the exit was invisible: the walk stepped onto the backbone and ran to the end of the chromosome. 237 alleles were lost that way, including AMY1's 41 kb insertion at chr1:103,676,921. The walk now tests arrival at a rank-0 segment instead, which is direction-independent, and every walk resolves. The allele file is derived from the two above and needs no graph: plain awk, 23 seconds. Each row carries a CIGAR against the reference span it replaces, so an AlignmentsTrack reading the BED draws each insertion at its real size rather than as a 1 bp box. Read `firstSeenIn`/`discoveryRank` as the first haplotype to contribute an allele - minigraph collapses, so it is discovery order, never carriage. 237 of the walks (0.1%) reach no link back to the backbone and are dropped rather than guessed at. Using them ---------- https://jbrowse.org/jb2/docs/tutorials/pangenome_hprc/ RgfaTabixAdapter takes the shared prefix (no suffix): https://jbrowse.org/demos/hprc/hprc-v2.0-mc-grch38 MinigraphBubbleAdapter takes the bubbles file directly: https://jbrowse.org/demos/hprc/hprc-v2.0-mc-grch38.bubbles.bed.gz The alleles file is a plain BedTabixAdapter uri, on an AlignmentsTrack: https://jbrowse.org/demos/hprc/hprc-v2.0-mc-grch38.alleles.bed.gz One gotcha worth recording: gfatools counts paths through a bubble combinatorially and clamps the count at 2147483647 rather than overflowing. 406 of the 130,510 bubbles sit at that value, where it means "more than I can count", not a measurement. repeat_density/ - per-class RepeatMasker density ------------------------------------------------ repeat_density/{hg38,hs1}_repeat_density_{LINE,SINE,LTR,DNA,Satellite,Simple_repeat}.bw Twelve bigWigs: fraction of each 5 kb bin covered by one RepeatMasker class, genome-wide (chr1-22,X,Y), for GRCh38 and T2T-CHM13v2.0. Values are 0-1, so a MultiQuantitativeTrack over them should pin minScore/maxScore to 0 and 1 - the point of the track is comparing rows and assemblies, which autoscale destroys. Sources, both UCSC: hg38 goldenPath/hg38/database/rmsk.txt.gz (class in column 12) hs1 gbdb/hs1/t2tRepeatMasker/chm13v2.0_rmsk.bb (repName#Class/Family) Built by scripts/build_repeat_density.sh in GMOD/jbrowse-components, which also prints the summary table below. Annotations of one class overlap (a fragmented L1 is several records), so each class is merged before coverage - unmerged would double-count shared bp and report over 100%. What it is for: over the last 650 kb of chr17 in each assembly - the subtelomere GRCh38 ends short of - the classes separate rather than move together, which a single density track cannot show. class GRCh38 CHM13 LINE 13.71% 70.05% (L1 alone: 13.35% -> 66.70%) SINE 13.58% 10.53% goes down LTR 6.10% 9.81% DNA 2.29% 8.17% all (merged) 37.22% 76.37% Each assembly is measured over its OWN last 650 kb, not a lifted-over interval: there is no lift-over for sequence one of them does not have.