Simulation data management
Simulation data management that keeps up with your campaigns
The number on the review slide came from a run. Which model version, which solver build, which parameter set? In most teams that question takes a day to answer. It should take a click. This page is about that gap, what closes it, and what closing it costs.
The situation
Where simulation data goes today
Results land on a shared drive in a folder named after the engineer, or in cluster scratch space with a retention policy nobody remembers. The summary goes into a slide deck. The deck survives. The run does not. Six months later a supplier disputes a load case, and the team rebuilds the run from memory and hopes the numbers agree.
The classical answer is a simulation process and data management system, SPDM for short. Ansys Minerva, Siemens Teamcenter Simulation and ESTECO VOLTA are good ones. Systems of this class are built for corporate structure and culture: rollout projects, dedicated roles, a method office. A group of eight analysts inside a company of two hundred runs on folders or SharePoint. Rescale, citing NAFEMS, puts adoption of such systems among simulation engineers in the low single digits of percent. We believe that figure.
The rule
What makes a run useful a year later
A run is worth keeping only if it carries its own context: the exact inputs, the code and the environment it ran in, and what it produced. When that holds, two runs can be compared and either can be repeated. When it does not, the results are numbers with a date on them.
NASA writes the same rule into its standard for models and simulations, NASA-STD-7009B, as requirement M&S 24: a record of the inputs, including their pedigree, shall be maintained. Every serious SPDM system agrees. They differ in how much filing they ask of the engineer afterwards. Our position is that filing is the step that fails. It has to happen as part of running the job, or it will not happen on a Thursday afternoon before a deadline. A competent analyst may disagree and point at a disciplined team that files everything. We have not met that team at forty people.
In Ref
Running a campaign
You keep your solvers and your scripts. Ref runs your tools in containers, interactively while you explore and on Azure Batch for campaigns of hundreds of runs. Every run records what it read and what it wrote as part of running. There is nothing left to file afterwards.
A campaign stays one thing: its parameter sets, its runs, its results and a comparison against the criteria you set. When one run is wrong you see which inputs it had, rerun it, and the comparison updates. When a model version changes, you see which past runs used the old one.
Formats: FMI and SSP for co-simulation, and whatever your tool writes. Ref stores files and keeps them straight; it does not have to understand them. The post-processing you already have in Python keeps working, in a container, against the results where they are.
The deliverable
Reproducibility
Any result can be rerun on demand, months later, by a person who was not there. That is what an assessor asks for under ISO 26262 or IEC 61508 when a safety argument rests on simulation. It is what a warranty case needs when the question is what was known at release. It is also what a new engineer needs in the first week.
Limits
What it costs
Your tools should run unattended in a container: a solver with a command line and a silent installer. A tool that only works through its desktop window can be driven by an agent that reads the screen. That works, and it is slower and costs more per run than a command line, so we set it up on request rather than by default. A run that stays outside Ref altogether can still have its results stored with their inputs, with the record only as good as what you attach. Licences stay yours and are not included. Ref is a cloud service on Microsoft Azure in the EU region you choose; your own premises is possible as a project on request. Grunetal holds no ISO 27001 certificate as of September 2026. The scope page lists everything else Ref leaves to other tools.
A pilot costs nothing in money. It costs one project of yours, its data, and an engineer who answers our questions in the first week.
Who
Who this page is for
Simulation groups of three to thirty people inside a company that will never fund a PLM-scale SPDM rollout: automotive suppliers, machinery, energy, mobility start-ups after the first prototype. If you have a simulation department with its own administrator, Teamcenter Simulation or Ansys Minerva will fit you better, and we would rather say so here than in week three of a pilot.
Questions
Asked before every pilot
Do we have to change our solvers?
No. Any tool that runs unattended from a command line runs in Ref. A tool that needs its window can be driven by an agent through the screen, at a higher cost per run. Your input decks, scripts and post-processing stay as they are.
Where is the data?
Normally on Microsoft Azure in the EU region you choose, under your own tenant on request. On your own premises is possible, scoped as a project.
What does the first campaign look like?
One of your own studies, with your solver, run as a campaign and compared against your criteria. That is the goal of the pilot, and it either happens or the pilot has failed.
How large can a campaign be?
Hundreds of runs per campaign is the range we test against as of September 2026. Larger is a conversation about node types and time.
Related
If your simulation data lives in folders and slide decks, a pilot on one of your studies costs nothing. Tell us about your project.