Repo for testing and developing a common postmortem-derived brain sequencing (PMDBS) and non-human workflow harmonized across ASAP with human and mouse spatial transcriptomics data for both Nanostring GeoMx and 10x Visium platforms. The main goal is to uncover spatially distinct gene expression profiles across tissue samples, enabling insights into tissue architecture, cell type composition, and disease-related molecular patterns.
Common workflows, tasks, utility scripts, and docker images reused across harmonized ASAP workflows are defined in the wf-common repository.
Worfklows are defined in the workflows directory. There is the spatial_geomx workflow directory and the spatial_visium workflow directory.
These workflows are set up to analyze spatial transcriptomics data: Nanostring GeoMx in WDL using command line, R, and Python scripts and 10x Visium in WDL using command line and Python scripts.
Note: Unlike our other workflows (e.g., pmdbs-sc-rnaseq-wf), the spatial workflows do not perform cross-team cohort analysis, as integrating spatial coordinates and mapping dimensions across datasets adds significant complexity.
For the Nanostring GeoMx workflow, we start with raw output files from the instrument and convert them into counts. Then, we clean the data by removing unreliable segments and genes, adjust for technical noise, and combine data from different slides. Finally, we cluster based on segment (which may contain many cells) and visualize their transcriptional profiles in a UMAP space.
Nanostring GeoMx workflow diagram:
Nanostring GeoMx entrypoint: workflows/spatial_geomx/main.wdl
Nanostring GeoMx input template: workflows/spatial_geomx/inputs.json
The Nanostring GeoMx workflow is broken up into three main chunks:
Run once per slide; only rerun when the preprocessing workflow version is updated. Preprocessing outputs are stored in the originating team's raw and staging data buckets.
Run once per slide. Intermediate files from previous runs are not reused and are stored in timestamped directories.
Run once per team (all slide from a single team) if project.run_project_cohort_analysis is set to true. Additional slides requires this entire analysis to be rerun. Intermediate files from previous runs are not reused and are stored in timestamped directories.
For the 10x Visium workflow, we start with raw output files from the instrument and convert them into counts. Then, we clean the data by removing unreliable spots and genes, adjust for technical noise, and combine data from different samples. We cluster based on spots (which may contain many cells) and visualize their transcriptional profiles in a UMAP space. We also identify spatially variable genes to uncover expression patterns that are location-specific within the tissue.
10x Visium entrypoint: workflows/spatial_visium/main.wdl
10x Visium input template: workflows/spatial_visium/inputs.json
The 10x Visium workflow is broken up into two main chunks:
Run once per sample; only rerun when the preprocessing workflow version is updated. Preprocessing outputs are stored in the originating team's raw and staging data buckets.
Run once per team (all samples from a single team) if project.run_project_cohort_analysis is set to true. This can be rerun using different sample subsets; including additional samples requires this entire analysis to be rerun. Intermediate files from previous runs are not reused and are stored in timestamped directories.
An input template file can be found at workflows/spatial_geomx/inputs.json.
| Type | Name | Description |
|---|---|---|
| Array[Project] | projects | The project ID, set of slides and their associated samples, reads and metadata, output bucket locations, and whether or not to run project-level cohort analysis. |
| File | geomxngs_config_pkc | The GeoMx DSP configuration file to associate assay targets with GeoMx HybCode barcodes and Seq Code primers; see https://nanostring.com/products/geomx-digital-spatial-profiler/geomx-dsp-configuration-files/. |
| Int? | min_segment_reads | Minimum number of segment reads. [1000] |
| Int? | min_percent_reads_trimmed | Minimum % of reads trimmed. [80] |
| Int? | min_percent_reads_stitched | Minimum % of reads stitched. [80] |
| Int? | min_percent_reads_aligned | Minimum % of reads aligned. [80] |
| Int? | min_saturation | Minimum sequencing saturation. [50] |
| Int? | min_neg_ctrl_count | Minimum negative control counts. [1] |
| Int? | max_ntc_count | Maximum counts observed in NTC well. [1000] |
| Int? | min_nuclei | Minimum # of nuclei estimated. [100] |
| Int? | min_segment_area | Minimum segment area. [5000] |
| File? | cell_type_markers_list | CSV file containing a list of major cell type markers; used for detecting genes of interest. |
| Float? | min_genes_detected_in_percent_segment | Minimum % of segments that detect the genes. [0.01] |
| Int? | n_comps | Number of principal components to compute. [30] |
| String? | batch_key | Key in AnnData object for batch information. ['batch_id'] |
| Float? | leiden_resolution | Value controlling the coarseness of the Leiden clustering. [0.4] |
| String | container_registry | Container registry where workflow Docker images are hosted. |
| String? | zones | Space-delimited set of GCP zones where compute will take place. ['us-central1-c us-central1-f'] |
An input template file can be found at workflows/spatial_visium/inputs.json.
| Type | Name | Description |
|---|---|---|
| Array[Project] | projects | The project ID, set of samples and their associated reads and metadata, output bucket locations, and whether or not to run project-level cohort analysis. |
| File | spaceranger_reference_data | Space Ranger transcriptome reference data; see https://www.10xgenomics.com/support/software/space-ranger/downloads and 10x Visium notes. |
| File | visium_probe_set_csv | Visium probe-based assays target genes in Space Ranger transcriptome; see https://www.10xgenomics.com/support/software/space-ranger/downloads and 10x Visium notes. |
| Int? | filter_cells_min_counts | Minimum number of counts required for a cell to pass filtering. [5000] |
| Int? | filter_cells_min_genes | Minimum number of genes required for a cell to pass filtering. [3000] |
| Int? | filter_genes_min_cells | Minimum number of cells expressed required for a gene to pass filtering. [10] |
| Float? | filter_mt_max_percent | Maximum percentage of mitochondrial read counts for a cell to pass filtering. [0.2] |
| Float? | normalize_target_sum | The total count to which each cell's gene expression values will be normalized. [10000] |
| Int? | n_top_genes | Number of highly-variable genes to keep. [3000] |
| Int? | n_comps | Number of principal components to compute. [30] |
| String? | batch_key | Key in AnnData object for batch information. ['batch_id'] |
| Float? | leiden_resolution | Value controlling the coarseness of the Leiden clustering. [0.4] |
| String | container_registry | Container registry where workflow Docker images are hosted. |
| String? | zones | Space-delimited set of GCP zones where compute will take place. ['us-central1-c us-central1-f'] |
| Type | Name | Description |
|---|---|---|
| String | team_id | Unique identifier for team; used for naming output files. |
| String | dataset_id | Unique identifier for dataset; used for naming output files. |
| String | dataset_doi_url | Generated Zenodo DOI URL referencing the dataset. |
| Array[Slide] | slides | The set of slides associated with this project. |
| File | project_sample_metadata_csv | CSV containing all sample information including batch, condition, etc. |
| File | geomx_config_ini | The configuration (.ini) file, containing pipeline processing parameters that is used by the GeoMx NGS pipeline to assist in converting the FASTQ files to DCC files. It is from the GeoMx DSP readout package. Sections can include [Sequencing], [Processing_v2], [AOI_List], and [Targets]; see GeoMx configuration (.ini) files notes. |
| Boolean | run_project_cohort_analysis | Whether or not to run cohort analysis within the project. |
| String | raw_data_bucket | Raw data bucket; intermediate output files that are not final workflow outputs are stored here. |
| String | staging_data_bucket | Staging data bucket; final project-level outputs are stored here. |
| Type | Name | Description |
|---|---|---|
| String | slide_id | Unique identifier for the slide within the project; used for naming output files. |
| File | geomx_lab_annotation_xlsx | The annotation (.xlsx) file/lab worksheet, containing phenotypic data from the GeoMx DSP readout package; see GeoMx Lab Worksheet notes. |
| Array[Sample] | samples | The set of samples associated with this project. |
| Type | Name | Description |
|---|---|---|
| String | sample_id | Unique identifier for the sample within the project. |
| String? | batch | The sample's batch. |
| File | fastq_R1 | Path to the sample's read 1 FASTQ file. |
| File | fastq_R2 | Path to the sample's read 2 FASTQ file. |
| File? | fastq_I1 | Optional FASTQ index 1. |
| File? | fastq_I2 | Optional FASTQ index 2. |
| Type | Name | Description |
|---|---|---|
| String | team_id | Unique identifier for team; used for naming output files. |
| String | dataset_id | Unique identifier for dataset; used for naming output files. |
| String | dataset_doi_url | Generated Zenodo DOI URL referencing the dataset. |
| Array[Sample] | samples | The set of samples associated with this project. |
| Boolean | run_project_cohort_analysis | Whether or not to run cohort analysis within the project. |
| String | raw_data_bucket | Raw data bucket; intermediate output files that are not final workflow outputs are stored here. |
| String | staging_data_bucket | Staging data bucket; final project-level outputs are stored here. |
| Type | Name | Description |
|---|---|---|
| String | sample_id | Unique identifier for the sample within the project. |
| String? | batch | The sample's batch. |
| File | fastq_R1 | Path to the sample's read 1 FASTQ file. |
| File | fastq_R2 | Path to the sample's read 2 FASTQ file. |
| File? | fastq_I1 | Optional FASTQ index 1. |
| File? | fastq_I2 | Optional FASTQ index 2. |
| File | visium_brightfield_image | The 10x Visium brightfield image, which is a high-resolution image of a tissue section and used for plotting spatial coordinates. |
| String | visium_slide_serial_number | The 10x Visium slide serial number obtained from the ASAP sample metadata. The unique identifier printed on the label of each Visium slide; see https://www.10xgenomics.com/support/software/space-ranger/3.0/getting-started/space-ranger-glossary. |
| String | visium_capture_area | The 10x Visium slide capture area obtained from the ASAP sample metadata. Active regions for capturing expression data on a Visium slide; see https://www.10xgenomics.com/support/software/space-ranger/3.0/getting-started/space-ranger-glossary. |
The inputs JSON may be generated manually, however when running a large number of samples, this can become unwieldly. The generate_inputs utility script may be used to automatically generate the inputs JSON (inputs.{staging_env}.{source}-{cohort_dataset}.{date}.json) and a sample list TSV ({team_id}.{source}-{cohort_dataset}.sample_list.{date}.tsv); same as the one generated in the write_cohort_sample_list task). The script requires the libraries outlined in the requirements.txt file and the following inputs:
project-tsv: One or more project TSVs with one row per sample and columns team_id, ASAP_dataset_id, ASAP_sample_id, batch, fastq_R1s, fastq_R2s, fastq_I1s, fastq_I2s, embargoed, source, dataset, dataset_DOI_url, and SPATIAL columns if applicable: geomx_config, geomx_dsp_config, geomx_annotation_file, visium_cytassist, visium_probe_set, visium_slide_ref, and visium_capture_area. All samples from all projects may be included in the same project TSV, or multiple project TSVs may be provided.team_id: A unique identifier for the team from which the sample(s) arose.ASAP_dataset_id: A generated unique identifier for the dataset from which the sample(s) arose.ASAP_sample_id: A generated unique identifier for the sample within the project.batch: The sample's batch.fastq_R1s: The gs uri to read 1 of sample FASTQ.- This is appended to the
project-tsvfrom thefastq-locs-txt: FASTQ locations for all samples provided in theproject-tsv. Each sample is expected to have one set of paired fastqs located at${fastq_path}/${sample_id}*. The read 1 file should include 'R1' somewhere in the filename. Generate this file e.g. by runninggcloud storage ls gs://fastq_bucket/some/path/**.fastq.gz >> fastq_locs.txt.
- This is appended to the
fastq_R2s: The gs uri to read 2 of sample FASTQ.- This is appended to the
project-tsvfrom thefastq-locs-txt: FASTQ locations for all samples provided in theproject-tsv. Each sample is expected to have one set of paired fastqs located at${fastq_path}/${sample_id}*. The read 2 file should include 'R2' somewhere in the filename. Generate this file e.g. by runninggcloud storage ls gs://fastq_bucket/some/path/**.fastq.gz >> fastq_locs.txt.
- This is appended to the
fastq_I1s: The gs uri to sample FASTQ index 1.fastq_I2s: The gs uri to sample FASTQ index 2.embargoed: The internal QC/embargo status of dataset.source: The source of dataset (e.g. 'pmdbs').dataset: The assigned dataset name without the source (e.g. 'sn-rnaseq')dataset_DOI_url: Generated Zenodo DOI URL referencing the dataset.geomx_config,geomx_dsp_config,geomx_annotation_file: go to Nanostring GeoMx inputsgeomx_slide: The GeoMx DSP identifier for the slide from which the sample(s) arose.ASAP_geomx_slide_id: A unique identifier for the slide per batch/run from which the sample(s) arose.visium_cytassist,visium_probe_set,visium_slide_ref,visium_capture_area: go to 10x Visium inputs
inputs-template: The inputs template JSON file into which theprojectsinformation derived from theproject-tsvwill be inserted. Must have a key ending in*.projects. Other default values filled out in the inputs template will be written to the output inputs.json file.run-project-cohort-analysis: Optionally run project-level cohort analysis for provided projects. This value will apply to all projects. [false]workflow_name: WDL workflow name.cohort-dataset: Dataset name in cohort bucket name (e.g. 'sc-rnaseq').
Example usage:
./wf-common/util/generate_inputs \
--project-tsv metadata.tsv \
--inputs-template workflows/spatial_geomx/inputs.json \
--run-project-cohort-analysis \
--workflow-name spatial_geomx_analysis \
--cohort-dataset spatial-geomx
./wf-common/util/generate_inputs \
--project-tsv metadata.tsv \
--inputs-template workflows/spatial_visium/inputs.json \
--run-project-cohort-analysis \
--workflow-name spatial_visium_analysis \
--cohort-dataset spatial-visiumcohort_id: either theteam_idfor project-level downstream analysis, or thecohort_idfor the full cohortworkflow_run_timestamp: format:%Y-%m-%dT%H-%M-%SZ- The list of samples used to generate the cohort analysis will be output alongside other cohort analysis outputs in the staging data bucket (
${cohort_id}.sample_list.tsv) - The
MANIFEST.tsvfile in the staging data bucket describes the file name, md5 hash, timestamp, workflow version, workflow name, and workflow release for the run used to generate each file in that directory
The raw data bucket will contain some artifacts generated as part of workflow execution. Following successful workflow execution, the artifacts will also be copied into the staging bucket as final outputs.
In the workflow, task outputs are either specified as String (final outputs, which will be copied in order to live in raw data buckets and staging buckets) or File (intermediate outputs that are periodically cleaned up, which will live in the cromwell-output bucket). This was implemented to reduce storage costs.
asap-raw-{cohort,team-xxyy}-{source}-{dataset}
└── workflow_execution
└── spatial_geomx
├── cohort_analysis
│ └──${cohort_analysis_workflow_version}
│ └── ${workflow_run_timestamp}
│ └── <cohort_analysis outputs>
├── process_to_adata
│ └──${process_to_adata_workflow_version}
│ └── ${workflow_run_timestamp}
│ └── <process_to_adata outputs>
└── preprocess
├── fastq_to_dcc
│ └── ${fastq_to_dcc_task_version}
│ └── <fastq_to_dcc output>
├── dcc_to_rds
│ └── ${dcc_to_rds_task_version}
│ └── <dcc_to_rds output>
└── qc
└── ${qc_task_version}
└── <qc output>
asap-raw-{cohort,team-xxyy}-{source}-{dataset}
└── workflow_execution
└── spatial_visium
├── cohort_analysis
│ └──${cohort_analysis_workflow_version}
│ └── ${workflow_run_timestamp}
│ └── <cohort_analysis outputs>
└── preprocess
├── spaceranger_count
│ └── ${spaceranger_count_task_version}
│ └── <spaceranger_count output>
├── counts_to_adata
│ └── ${counts_to_adata_task_version}
│ └── <counts_to_adata output>
└── qc
└── ${qc_task_version}
└── <qc output>Staging data (intermediate workflow objects and final workflow outputs for the latest run of the workflow)
Following QC by researchers, the objects in the dev or uat bucket are synced into the curated data buckets, maintaining the same file structure. Curated data buckets are named asap-curated-{team-xxyy}-{source}-{dataset}.
Data may be synced using the promote_staging_data script.
asap-dev-{team-xxyy}-{source}-{dataset}
└── spatial_geomx
├── cohort_analysis
│ ├── ${team_id}.sample_list.tsv
│ ├── ${team_id}.merged_metadata.csv
│ ├── ${team_id}.merged_processed.h5ad
│ ├── ${team_id}.all_genes.csv
│ ├── ${team_id}.hvg_genes.csv
│ ├── ${team_id}.hvg_dispersion.png
│ ├── ${team_id}.umap_cluster.png
│ ├── ${team_id}.final.h5ad
│ ├── ${team_id}.final_metadata.csv
│ └── MANIFEST.tsv
├── process_to_adata
│ ├── ${slideN_id}.segment_gene_detection_plot.png
│ ├── ${slideN_id}.gene_detection_rate.csv
│ ├── ${slideN_id}.q3_negprobe_plot.png
│ ├── ${slideN_id}.normalization_plot.png
│ └── MANIFEST.tsv
└── preprocess
├── ${slideA_id}.DCC.zip
├── ${slideA_id}.geomxngs_out_dir.tar.gz
├── ${slideA_id}.NanoStringGeoMxSet.rds
├── ${slideA_id}.qc.rds
├── ${slideA_id}.segment_qc_summary.csv
├── ${slideA_id}.probe_qc_summary.csv
├── ${slideA_id}.gene_count.csv
├── MANIFEST.tsv
├── ...
├── ${slideN_id}.DCC.zip
├── ${slideN_id}.geomxngs_out_dir.tar.gz
├── ${slideN_id}.NanoStringGeoMxSet.rds
├── ${slideN_id}.qc.rds
├── ${slideN_id}.segment_qc_summary.csv
├── ${slideN_id}.probe_qc_summary.csv
├── ${slideN_id}.gene_count.csv
└── MANIFEST.tsv
asap-dev-{team-xxyy}-{source}-{dataset}
└── spatial_visium
├── cohort_analysis
│ ├── ${team_id}.sample_list.tsv
│ ├── ${team_id}.merged_cleaned_unfiltered.h5ad
│ ├── ${team_id}.merged_metadata.csv
│ ├── ${team_id}.all_genes.csv
│ ├── ${team_id}.hvg_genes.csv
│ ├── ${team_id}.qc_violin.png
│ ├── ${team_id}.qc_dist.png
│ ├── ${team_id}.hvg_dispersion.png
│ ├── ${team_id}.umap_cluster.png
│ ├── ${team_id}.spatial_scatter.png
│ ├── ${team_id}.final.h5ad
│ ├── ${team_id}.final_metadata.csv
│ ├── ${team_id}.moran_top_10_variable_genes.csv
│ ├── ${team_id}.moran_top_4_variable_genes_spatial_scatter.png
│ └── MANIFEST.tsv
└── preprocess
├── ${sampleA_id}.raw_feature_bc_matrix.h5
├── ${sampleA_id}.filtered_feature_bc_matrix.h5
├── ${sampleA_id}.molecule_info.h5
├── ${sampleA_id}.metrics_summary.csv
├── ${sampleA_id}.spaceranger_spatial_outputs.tar.gz
├── ${sampleA_id}.aligned_fiducials.jpg
├── ${sampleA_id}.detected_tissue_image.jpg
├── ${sampleA_id}.tissue_hires_image.png
├── ${sampleA_id}.tissue_lowres_image.png
├── ${sampleA_id}.scalefactors_json.json
├── ${sampleA_id}.tissue_positions.csv
├── ${sampleA_id}.spatial_enrichment.csv
├── ${sampleA_id}.cleaned_unfiltered.h5ad
├── ${sampleA_id}.qc.h5ad
├── MANIFEST.tsv
├── ...
├── ${sampleN_id}.raw_feature_bc_matrix.h5
├── ${sampleN_id}.filtered_feature_bc_matrix.h5
├── ${sampleN_id}.molecule_info.h5
├── ${sampleN_id}.metrics_summary.csv
├── ${sampleN_id}.spaceranger_spatial_outputs.tar.gz
├── ${sampleN_id}.aligned_fiducials.jpg
├── ${sampleN_id}.detected_tissue_image.jpg
├── ${sampleN_id}.tissue_hires_image.png
├── ${sampleN_id}.tissue_lowres_image.png
├── ${sampleN_id}.scalefactors_json.json
├── ${sampleN_id}.tissue_positions.csv
├── ${sampleN_id}.spatial_enrichment.csv
├── ${sampleN_id}.cleaned_unfiltered.h5ad
├── ${sampleN_id}.qc.h5ad
└── MANIFEST.tsvThe promote_staging_data script can be used to promote staging data that has been approved to the curated data bucket for a team or set of teams.
This script compiles bucket and file information for both the initial (staging) and target (prod) environment. It also runs data integrity tests to ensure staging data can be promoted and generates a Markdown report. It (1) checks that files are not empty and are not less than or equal to 10 bytes (factoring in white space) and (2) checks that files have associated metadata and is present in MANIFEST.tsv.
If data integrity tests pass, this script will upload a combined MANIFEST.tsv and the data promotion Markdown report under a metadata/{timestamp} directory in the staging bucket. Previous manifest files and reports will be kept. Next, it will rsync all files in the staging bucket to the curated bucket's upstream, downstream, cohort_analysis, and metadata directories. Exercise caution when using this script; files that are not present in the source (staging) bucket will be deleted at the destination (curated) bucket.
If data integrity tests fail, staging data cannot be promoted. The combined MANIFEST.tsv, Markdown report, and promote_staging_data_script.log will be locally available.
The script defaults to a dry run, printing out the files that would be copied or deleted for each selected team.
-h Display this message and exit
-t Space-delimited team(s) to promote data for
-l List available teams
-s Source name in bucket name
-d Space-delimited dataset name(s) in team bucket name, must follow the same order as {team}
-w Workflow name used as a directory in bucket
-p Promote data. If this option is not selected, data that would be copied or deleted is printed out, but files are not actually changed (dry run)
# List available teams
./wf-common/util/promote_staging_data -t cohort -l -s pmdbs -d spatial-geomx -w spatial_geomx
./wf-common/util/promote_staging_data -t cohort -l -s mouse -d spatial-visium -w spatial_visium
# Print out the files that would be copied or deleted from the staging bucket to the curated bucket for teams team-edwards and team-vila
./wf-common/util/promote_staging_data -t team-edwards team-vila -s pmdbs -d spatial-geomx-th spatial-geomx-thlc -w spatial_geomx
# Promote data for team-edwards and team-vila
./wf-common/util/promote_staging_data -t team-edwards team-vila -s pmdbs -d spatial-geomx-th spatial-geomx-thlc -w spatial_geomx -pDocker images are defined in the docker directory. Each image must minimally define a build.env file and a Dockerfile.
Example directory structure:
docker
├── geomxngs
│ ├── build.env
│ └── Dockerfile
└── spatial_py
├── build.env
├── Dockerfile
├── requirements.txt
└── scripts
├── visium_counts_to_adata.py
├── visium_qc.py
├── visium_merge_and_plot_qc.py
├── visium_process.py
├── integrate_harmony.py
├── cluster.py
├── visium_plot_spatial.py
├── visium_spatially_variable_genes.py
└── ...Each target image is defined using the build.env file, which is used to specify the name and version tag for the corresponding Docker image. It must contain at minimum the following variables:
IMAGE_NAMEIMAGE_TAG
All variables defined in the build.env file will be made available as build arguments during Docker image build.
The DOCKERFILE variable may be used to specify the path to a Dockerfile if that file is not found alongside the build.env file, for example when multiple images use the same base Dockerfile definition.
Docker images can be build using the build_docker_images script.
# Build a single image
./build_docker_images -d docker/geomxngs
# Build all images in the `docker` directory
./build_docker_images -d docker
# Build and push all images in the docker directory, using the `dnastack` container registry
./build_docker_images -d docker -c dnastack -p| Image | Major tool versions | Links | Workflow |
|---|---|---|---|
| geomxngs | Dockerfile | spatial_geomx | |
| spaceranger | Dockerfile | spatial_visium | |
| util | Dockerfile | both | |
| spatial_r | R (v4.4.2) packages: | Dockerfile | spatial_geomx |
| spatial_py | Python (v3.12.5) libraries: | Dockerfile | both |
wdl-ci provides tools to validate and test workflows and tasks written in Workflow Description Language (WDL). In addition to the tests packaged in wdl-ci, the spatial-transcriptomics-wdl-ci-custom-test-dir is a directory containing custom WDL-based tests that are used to test workflow tasks. wdl-ci in this repository is set up to run on pull request.
In general, wdl-ci will use inputs provided in the wdl-ci.config.json and compare current outputs and validated outputs based on changed tasks/workflows to ensure outputs are still valid by meeting the critera in the specified tests. For example, if the rds to adata task in our workflow was changed, then this task would be submitted and that output would be considered the "current output". When inspecting the converted adata object, there is a test specified in the wdl-ci.config.json called, "check_hdf5". The test will compare the "current output" and "validated output" (provided in the wdl-ci.config.json) to make sure that the .h5ad file is still a valid HDF5 file.
The GeoMx DSP Instrument User Manual and GeoMx DSP Data Analysis User Manual provide a comprehensive overview of the GeoMx DSP workflow- from sample preparation and slide scanning to sequencing and data analysis. The required input files listed below for our spatial_geomx pipeline are described in detail in these manuals. These files are included as part of the GeoMx Readout Package, which are used during the experimental runs.
The GeoMx Lab Worksheet contains information on the contents of each well of each plate and can be useful when doing library preparation and pooling. Some columns include:
Sample_IDslide namescan namepanelroisegmentaoiarea- ...
An example of the configuration (.ini) file can be found in the GeoMx-NGS-Pipeline-Dataset.
| Section | Description |
|---|---|
[Sequencing] |
Specifies sequencing platform, read pattern, library prep, etc. |
[Processing_v2] |
Core processing parameters including adapters and filters. |
[AOI_List] |
Area of Interest, which refers to the specific regions selected on a GeoMx slide for spatial transcriptomic profiling. |
[Targets] |
Maps readout tag sequence identifiers to their corresponding nucleotide sequences. |
The Nanostring GeoMx configuration (.pkc) files were obtained from https://nanostring.com/products/geomx-digital-spatial-profiler/geomx-dsp-configuration-files/.
- Human_WTA_v1.0 for Human Whole Transcriptome Atlas
- Mouse_WTA_v1.0 or Mouse_WTA_v2.0 for Mouse Whole Transcriptome Atlas
The Space Ranger reference data were obtained from https://www.10xgenomics.com/support/software/space-ranger/downloads.
The Space Ranger probe set data were obtained from https://www.10xgenomics.com/support/software/space-ranger/downloads.