Standalone installation and maintenance

Build and validate a source bundle, install a Linux binary, or try the supplied dataset.

Quick start · Model guide · Results and diagnostics

Collaborators can use their project’s existing shared installation directly; see the quick start. The instructions below are for maintainers and users installing a supplied binary.

The standalone frontend prepares inputs and labels results. Native libraries perform the numerical work through gsuite_model_driver. R is not required; existing R interfaces remain separate. Build scripts and launchers select the private MKL/SuiteSparse libraries and handle OpenMP affinity automatically.

Build, validate and distribute

The source bundle includes the build scripts, YAML frontend, model examples and binary installer. Each source or binary release needs its own target-system validation; acceptance of another release does not qualify it.

Obtain the source archive and matching checksum from the maintainer, verify and extract it once, then enter the extracted bundle directory. Inside a compute allocation with at least eight CPUs and $TMPDIR, activate the build environment:

conda activate gsuite

Run each task separately, proceeding after success:

bash build.sh

Builds and installs this source version, reusing compatible native builds from the project-root .gsuite-native-cache/.

bash hpc_tasks/validate.sh

Runs exact references, truth-evaluation checks and all 20 fixture models, including CHOLMOD/PARDISO comparisons. Scratch handling, timings, memory reports and result collection are automatic. Logs and results go under results/BUNDLE-validation-TAG/ in the project root, where BUNDLE is the extracted bundle directory name and TAG identifies the run. Require exit code zero and accepted: true in task.json and the four receipts: exact/validation.json, evaluation-check/validation.json, fixture/validation.json and backends/validation.json.

bash hpc_tasks/build_binary_distribution.sh

Produces a binary archive under project-root distributions/ and saves reports under results/. It uses the existing native installation, qualifies the producer installation, then independently installs and validates the delivered archive using $TMPDIR. It requires patchelf and Conda/Mamba, and performs no native compilation. Scratch handling and result collection are automatic.

Producing an archive leaves existing shared installations in place. New shared versions use separate prefixes after their own installation checks.

Install a supplied Linux binary

These commands install a maintainer-supplied binary archive on a compatible Linux x86-64 host. Replace BUILD and VERSION below with the delivered archive stem and intended versioned installation name. Use the binary archive and its matching checksum, rather than the YAML source bundle.

Shared and independent installations have recorded successful GenomeDK validation. Every new archive must pass its own fresh-runtime installer checks. Binary archives remain private validation artifacts, with no public binary download on this website. Use the archive and matching checksum supplied by the maintainer.

The recipient needs Conda or Mamba, Python 3.10 or newer, network access to the runtime packages, and the ordinary Linux bash, ldd and readelf tools. No compiler, R, CMake, development headers or patchelf is required. On HPC, use an allocated compute-node shell with $TMPDIR available; allocate at least eight CPUs for the eight-thread model example.

An existing Python 3.10+ Conda environment, including a suitable base environment, can start the installer. If one is needed, create this small bootstrap environment once:

conda create -n gsuite-installer -c conda-forge python=3.12 -y
conda activate gsuite-installer

Set ARCHIVE to the absolute path of the delivered archive, with its .tar.gz.sha256 file beside it. Choose a new prefix at its permanent location:

(
set -euo pipefail
ARCHIVE=/path/to/gsuite-genomedk-BUILD.tar.gz
PREFIX="$HOME/software/gsuite-VERSION"
: "${TMPDIR:?Run inside a Slurm compute-node allocation}"

cd "$(dirname "$ARCHIVE")"
sha256sum -c "$(basename "$ARCHIVE").sha256"
WORK=$(mktemp -d "$TMPDIR/gsuite-install.XXXXXX")
tar -xzf "$ARCHIVE" -C "$WORK"

bash "$WORK/$(basename "$ARCHIVE" .tar.gz)/install.sh" \
  --prefix "$PREFIX" --scratch-directory "$WORK"
)

The installer creates <prefix>/runtime and <prefix>/app, installs pinned runtime packages, checks host/library compatibility and runs small exact references, the installed launcher and CHOLMOD/PARDISO agreement checks. Continue after exit code zero and accepted: true in <prefix>/installation.json. Reports and copied numerical results stay under <prefix>/validation/, including exact/validation.json and backends/agreement.json. The input archive and checksum can be retained separately from the installation.

An existing prefix is preserved rather than overwritten. Do not move an installed Conda prefix; install again at the desired final location. The scratch extraction directory is not needed for later fits. These checks use tiny models and do not establish industrial performance or PEV precision.

Run the included dataset

Copy the installed small dataset into a new writable directory. This preserves the installed examples and keeps relative input paths together:

export PATH="$HOME/software/gsuite-VERSION/bin:$PATH"

mkdir -p "$HOME/gsuite-work"
cp -a "$HOME/software/gsuite-VERSION/app/example" "$HOME/gsuite-work/example"
cd "$HOME/gsuite-work/example"

gsuite validate model.yml
gsuite describe model.yml
gsuite run model.yml

Use a new work directory if gsuite-work/example already exists. The example includes CSV pedigree/phenotypes, SNP-major PLINK BED/BIM/FAM and simulated true genetic values. Truth is not used by the fit. Its eight phenotype rows and two traits are a workflow check, not prediction-accuracy evidence. The complete model describes these same files, covariances, effects, threads and outputs. Results are written to $HOME/gsuite-work/results/example by this model’s relative output path.

The installed app/models/ directory contains 42 self-contained YAML examples and their tiny inputs. The external-data 1M production recipe is separate under app/recipes/model-1m-ancestral-t16.yml. Copy a model together with its required data, then edit paths and settings for your dataset. No large dataset is included or required by installation checks. YAML files and data travel together; paths resolve beside the YAML, not beside the executable.