A heliosphere-only EUHFORIA integration layout

This layout shows where an existing heliosphere calculation meets Enumeray. It provides an integration boundary for review; it does not port EUHFORIA, choose its scientific parameters, provide a native configuration syntax or qualify the model/runtime. Model owners must supply and test the actual native mapping, physical units, bounds and numerical assertions.

Three maintained integration files

euhforia-heliosphere/
  publication.json
  wrapper.py
  model.sbatch

The complete illustrative publication declares one uploaded boundary_conditions file and one heliosphere output collection. Its names and deliberately small demonstration limits illustrate the contract, not an established EUHFORIA workload. Replace those limits and required schemas with reviewed model requirements. Add units, interpretation and named cases as appropriate. The runtime identity must name the actual installed environment rather than the illustrative review-required label.

wrapper.py accepts the ordinary request/result protocol, validates declared scientific inputs and verified staged paths, and generates native configuration inside the current job workspace. It invokes a fixed installed heliosphere executable in the foreground, checks its scientific outputs and writes the declared result/collection reports. Native input files, scratch files and output member manifests are generated per run; they are not additional author configuration sources. The wrapper must preserve result evidence and echo execution identities as in the starter. The native solver needs no Enumeray imports.

model.sbatch owns this calculation’s resource requests and runtime setup:

#!/bin/bash
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --time=00:10:00

set -eu
# Select reviewed site resources and load the installed runtime here.
exec "$1" local-worker --directory "$2"

These scheduler values are placeholders for a reviewed allocation. The worker then launches wrapper.py from execution.entrypoint. A real integration may require installed binaries, runtime libraries, datasets and author tests alongside these three maintained integration files. It need not introduce a new package format or another JSON declaration.

Keep shared compute separate

The connector owner configures the connector, execution account, Slurm/direct or Slurm/SSH context, worker path, approved roots and credentials. The author selects that granted context and the immutable installed release in publication.json. Do not embed SSH hosts, secrets or service provisioning in scientific inputs, the wrapper or the publication. Release and job paths must be visible to the selected compute nodes.

Run local scientific tests first, install the complete immutable release, and follow the same saved release workflow. Readiness establishes installed entrypoint/backend access. Candidate trials and model-owned numerical assertions establish the evidence needed before explicit activation. Choosing this layout does not attest a scientific implementation or its dependencies.