Skip to main content

MCScanBlocksAdapter

Auto-generated config schema for the current JBrowse release — see the config guide for concepts. Provided by the comparative-adapters plugin. View source.

Example usage

uri is the shorthand for the anchor .blocks file:

{
  type: 'SyntenyTrack',
  trackId: 'my_track',
  name: 'My track',
  assemblyNames: ['grape', 'peach', 'cacao'],
  adapter: {
    type: 'MCScanBlocksAdapter',
    uri: 'grape.blocks',
    blockAssemblies: ['grape', 'peach', 'cacao'],
    bedLocations: [
      { uri: 'grape.bed' },
      { uri: 'peach.bed' },
      { uri: 'cacao.bed' },
    ],
  },
}

See the Config slots section below for all available configuration fields.

Gotcha

blockAssemblies and bedLocations are positional against the table's own columns, which is not necessarily the order assemblyNames lists or the order the genomes were given to whatever wrote the table. Get it wrong and every gene is looked up in another genome's BED; the track fails with the column order named, rather than drawing empty. The table carries no coordinates: a gene is placed by matching its id against column 4 of its column's BED, byte for byte. One column whose BED places none of its ids fails the track naming that column, since the rest still resolve and only the bands touching that genome would have been empty. BED column 1 has to match the assembly's reference sequence names, which is the one mismatch that still draws nothing rather than erroring.

Loads a multi-genome MCScan (jcvi) .blocks file: a reference-anchored, tab-delimited table where column 0 is a reference gene and each further column is that gene's ortholog in another genome (. = no ortholog), produced by jcvi.compara.synteny mcscan + jcvi.formats.base join.

A .blocks file describes N genomes at once, so one track backs every band of a multi-way view: the synteny view tells the adapter which pair each band draws, deriving that pair's gene links from the two matching columns. When neither column is the reference the link is transitive (both orthologous to the same reference gene) rather than a direct alignment. Every genome blockAssemblies names is available that way unless assemblyNames narrows it, and listing just two assemblies there pins the track to that pair.

Somewhere that names no pair, such as the track shown in a plain linear genome view or the "Linear synteny view" launcher asking what a locus aligns to, gets every pair the track declares at once, one set of links per other genome. Group the display by mate assembly to read them as a lane apiece.

A gene pair the table names on several rows draws once. Both ordinary table shapes repeat one: a reference-anchored table names a transitive pair again through each reference gene anchoring it, and an orthogroup table expanded a copy at a time names every pair not touching that duplication once per row.

See the ortholog tables tutorial, which covers building the table from jcvi, OrthoFinder, reciprocal best hits or MCScanX, and stacking the genomes in one view.

Config slots

These slots go inside the track's adapter: "adapter": { "type": "MCScanBlocksAdapter", ... }. It also accepts the shorthand keys uri, baseUri in place of writing a location slot out. Slot types (fileLocation, frozen, ...) are explained in the config slot types reference. Slots a base configuration contributes are listed here too, so this table is the whole surface.

SlotDescription
mcscanBlocksLocation
fileLocation = { uri: '/path/to/mcscan.blocks', locationType: 'UriLocation' }		location of the .blocks table: column 0 is a reference gene and each further column is that gene's ortholog in another genome, . where there is none. blockAssemblies names the columns and bedLocations resolves each column's gene names to coordinates.
blockAssemblies
stringArray = []		one assembly name per column of the blocks file, in column order (column 0 is the reference). A genome may hold several columns, which is what jcvi mcscan writes above --iter=1 (a column per chain of synteny blocks, so a duplicated region is a further column of the same genome) and what a self-comparison is; every column of a genome is drawn, so a gene with two copies in its mate draws a link to each
bedLocations
frozen = []		one BED fileLocation per column of the blocks file, parallel to blockAssemblies, resolving that column's gene ids to coordinates
assemblyNames
stringArray = []		the assemblies this track can render, to narrow it below what the table describes: two entries pin it to a single pair. Unset (the default) is every genome blockAssemblies names, so one track backs every band of a multi-way view and the view picks each band's pair. Every entry must appear in blockAssemblies. A genome spanning several columns is named once here, not once per column
attributeColumns
stringArray = []		names for the extra columns that follow the gene columns, in order, so an ortholog table can carry per-link measurements the format itself has no place for: ["identity", "dn", "ds", "goc_score"] reads column N as identity where N is blockAssemblies.length. Each becomes a feature attribute, so it shows in the detail panel, and dn/ds are what the synteny view's Color by value → dN/dS reads. A cell of ., NA, NULL or empty is a missing value rather than a zero. A column of text, an ancestral linkage group or an orthogroup label say, is kept as text and Color by value → <column> paints one color per distinct label; a column named color holding CSS colors is what that mode paints a label with when the file carries one.

These describe the ROW. On a two-genome table a row is one link, which is what makes a per-link measurement meaningful; on an N-genome table a row is an orthogroup spanning several pairs, so only a value that describes the whole group belongs there