Physical meaning stays implicit
Declare types, units, constraints, and explanatory metadata alongside the values.
WHY SNT HUB
Your code knows
how to compute.
SNT Hub makes its parameters understandable and manageable by other software.
A native input file tells a simulation code what to execute. A DIPL model can also describe, validate, inspect, and manipulate the scientific meaning of its parameters.
Keep the native format.
SNT Hub adds an optional parameter layer around it. A project adapter translates evaluated values into the files the existing solver already understands.
THE PRACTICAL CASE
What changes when
inputs have structure?
Native files remain the final input. The added model gives people and tools a common place to understand and check the values that produce those files.
Bad settings fail at run time
Check declared rules before spending time on a simulation.
Studies need custom file edits
Inspect and override structured values, then generate native inputs through an adapter.
Codes speak different input languages
Build tooling against a common parameter interface while each solver keeps its own format.
Agents must guess what inputs mean
Offer a machine-readable contract that tools and AI agents can inspect instead of inferring everything from prose.
The machine-readable interface is useful for AI agents, but its immediate value is the same for human-built tools: explicit inputs that can be inspected and checked.
A REALISTIC WORKFLOW
Imagine preparing
500 simulations.
A researcher varies density, temperature, and magnetic field across hundreds of runs. Native files alone can support this, but a growing script must edit them, check values, track variations, and preserve provenance.
With a sufficiently complete DIPL integration, the same workflow can use a structured interface:
Python scripts and workflow managers can already do this. The aim is to make the parameter contract reusable across codes, so each team need not rebuild it from scratch.
SNT Hub does not replace the workflow that schedules or runs the sweep. It supplies inspectable, validated inputs and native file generation for each run.- 01Inspect
Find available parameters, types, units, and documented relationships.
- 02Vary
Use a workflow or script to supply structured overrides for each run.
- 03Check
Evaluate declared constraints and adapter checks before launching the solver.
- 04Prepare
Generate the native inputs expected by the existing code.
- 05Record
Keep the evaluated parameter snapshot with each run for inspection and comparison.
WHERE IT PAYS OFF
Three levels
of value.
The extra layer becomes most useful when many runs, people, tools, or scientific codes have to work together.
Easier inputs
Inspect and generate configurations through a structured interface.
Clearer contracts
Use declared rules and recorded values to support validation and reproducibility.
Reusable tooling
Connect different scientific codes to consistent workflows and automation.
When is it worth adopting?
If you edit a few familiar input files by hand, your current workflow may be enough. The case grows stronger for developers, research software engineers, and computational researchers building reliable tooling around hundreds or thousands of simulations.
A SCIENTIFIC BOUNDARY
Meaning must be
declared and tested.
A datatype and unit do not, by themselves, capture a parameter's scientific meaning. Physical constraints, dependencies, and model validity domains must be represented explicitly or checked by the adapter. A Hub listing should show what has actually been modeled and validated.
START WITH A PROJECT
See what the layer
can describe.
Explore participating codes, their parameter references, and the evidence behind each integration.