Glossary¶
Terms that are obscure or specific to AtlasXomics.
run_id
: A run identifier of the form Dxxxxx_NGxxxxx (e.g. D00000_NG00000). The
first value, starting with D, is the run ID; each run ID corresponds to a
single tissue slide. The NG value identifies the sequencing library.
Run : In ATX parlance, a tissue-sample analyzed via DBiT-seq. Multiple Runs can be merged into a single Project for analysis.
primary analysis : Alignment and QC of FASTQ files, and processing of image data.
secondary analysis : Post-alignment processing that moves aligned data toward more meaningful context — gene accessibility, peak calling, and motif deviations (epigenomic), clustering, cell typing, and spatial analysis.
DBiT-seq : Deterministic Barcoding in Tissue for spatial omics sequencing — the assay underlying ATX spatial data. See the Bibliography.
tixel : A "tissue pixel" — one spatial barcode location on the DBiT-seq grid.
bulk (mode)
: A preprocessing mode for non-spatial
(bulk) ATAC-seq runs. When enabled, the spatial barcode sequences in reads
are replaced with random barcodes, so the run is processed as a single
bulk sample rather than resolved into tixels. Enabled via the bulk
toggle; AtlasXomics preprocessing supports both spatial and bulk run types.
no-ligation-bulk (mode)
: A bulk preprocessing mode for libraries prepared without the
ligation-linker step. Before alignment, reads have the expected linker
sequences added and random barcodes assigned. Enabled via the
noLigation_bulk toggle.
cross-talk : In DBiT-seq, spatial barcodes are delivered through microfluidic channels (one set of channels for rows, another for columns). Cross-talk is barcode bleed-through — signal leaking between adjacent channels so that certain rows or columns show fragment counts elevated above the local background, contaminating those tixels.
cross-talk correction
: A preprocessing step that removes cross-talk
contamination. Affected positions are detected in
BarcodeQC — a count matrix over the spatial grid is
smoothed (LOWESS) across rows/columns, and positions whose counts exceed the
smoothed background by more than fold_above_background are flagged into an
xtalkTable.csv (columns mer, row, col, xtalk_mask,
fold_above_background). During preprocessing, each flagged barcode's
fragments are then substituted with copies of the nearest unaffected
neighbor's fragments (searched col ± 1, row ± 1, col ± 2, row ± 2, no
diagonals, up to distance 2); positions with no clean neighbor in range are
left untouched. Enabled via the xtalk_correction toggle.
cleaning
: A preprocessing step that remediates
microfluidic intensity artifacts (as opposed to the positional bleed-
through handled by cross-talk correction).
Over-represented barcodes / tixels are randomly downsampled toward
the local background using a cleanTable.csv (columns mer,
finalDownFract — the fraction each barcode is downsampled to), generated in
BarcodeQC. Enabled via the cleaning toggle. The
standalone clean Workflow applies a related
row/column outlier-downsampling directly to a fragments file.
fragments file
: A BED-like, tab-delimited fragments.tsv.gz file where each row is an ATAC-seq
fragment; the primary output of epigenomic preprocessing.
Spatial folder : A directory produced by AtlasXBrowser after image processing, containing the tissue images and metadata that map sequencing data onto the tissue. Contents:
- **`tissue_lowres_image.png`** — low-resolution cropped tissue image.
- **`tissue_highres_image.png`** — high-resolution cropped tissue image.
- **`metadata.json`** — ROI coordinates, pixel-thresholding parameters
(block size, threshold), on-tissue tixel count, image height, and rotation.
- **`tissue_positions_list.csv`** — per-tixel barcode, on/off-tissue flag
(`1`/`0`), row/column indices, and X/Y coordinates.
- **`tissue_positions_list_log_UMI_Genes.csv`** *(optional)* — the positions
list with added log-transformed UMI and gene counts for visualization.
See the [AtlasXBrowser Spatial Folder docs](https://atlasxbrowser-docs.readthedocs.io/en/latest/SpatialFolder.html).
ArchRProject : The ArchR analysis object bundling fragments, QC, dimensionality reduction, and clustering for a set of Runs.
Latch platform concepts¶
The AtlasXomics platform is built on top of LatchBio, a cloud environment for building and running bioinformatics Workflows. These are the Latch pieces you will encounter throughout this documentation.
Workflow : A versioned, containerized pipeline made up of one or more Tasks. Each ATX Workflow corresponds to a GitHub repository under atlasxomics.
Task : A single step within a Workflow (e.g. filtering, alignment). Tasks are the units the Latch UI displays while a Workflow runs.
Latch Data
: The Latch file system where inputs and outputs are stored; remote paths use
the latch:/// scheme.
Plots : Latch's interactive visualization environment, where ATX plotting apps render Workflow outputs.
Registry : A light sample database that is part of Latch, storing samples, runs, and metadata alongside your data.
Pod : An interactive, customizable Latch cloud compute instance (similar to an EC2 instance) preconfigured with Jupyter and RStudio, used for analysis and for running interactive tools such as AtlasXBrowser.
SLIMS : AtlasXomics' internal LIMS platform — separate from Latch and used for ATX operations only. The "Upload to SLIMS" toggle is ATX-internal.
Internal (ATX-only) Tasks¶
Several Workflows include Tasks that are not relevant to customers and exist only for AtlasXomics internal operations. You may see these in the Latch UI while a Workflow runs, but they do not affect your outputs.
lims_task
: Pushes QC results and run metadata to SLIMS, the ATX internal LIMS
platform (separate from Latch).
upload_latch_registry / upload_registry_task
: Writes Workflow outputs and their locations to the Registry — the
light sample database built into Latch.
These steps are typically gated behind an "Upload to SLIMS" or "Registry Table ID" parameter and can be ignored for external/DIY use. Individual Workflow pages therefore omit them from their Steps lists, and do not repeat this note.