From Simulation to Decision: Rethinking Analysis in Modern HPC Workflows
Large simulation programs are producing more data than ever before. At the same time, the workflows built around those simulations are becoming more complex. While much of the conversation around HPC focuses on increasing computational performance, another challenge is increasingly shaping how organizations extract value from their investments: turning simulation output into decisions.
Across modern HPC systems, compute performance is increasing faster than data can be transferred, stored, or analyzed. As a result, simulation teams can often generate data faster than they can move it through the rest of the workflow. As more simulations move to GPUs and as ensemble and digital twin workflows become more common, this imbalance becomes increasingly difficult to ignore.
The traditional approach of running a simulation, writing results to disk, and analyzing them later was developed for a different era of computing. Today, moving and managing simulation data is becoming a larger part of the overall workflow. Even as simulations become faster and more capable, the time and resources required to transfer, store, and analyze their output continue to grow. Compute is getting cheaper. Moving the data compute produces is not.
The Workflow Has Already Changed
The challenge is often discussed in the context of a single simulation, but that is no longer how most production simulation programs operate.
Today’s workflows increasingly rely on design of experiments, parameter sweeps, optimization loops, surrogate model training, and digital twins running against live data. Rather than producing a single answer, these workflows generate ensembles of related simulations. Their results must then be aggregated, compared, and incorporated into the next stage of analysis.
A digital twin requires running multiple simulation variations and comparing the resulting outputs to support operational decisions. An optimization study depends on data extracted from one set of runs feeding the next round of simulations. Surrogate model training requires each simulation run to produce consistent data that can be combined into a larger training dataset. In each case, the value comes not from an individual simulation, but from the ensemble as a whole.
As workflows expand:
- The data-movement problem changes shape.
- The bottleneck affecting a single simulation multiplies across the ensemble.
- Storage requirements scale with the number of runs.
- Cross-run analysis depends on each simulation producing the right reduced data in the right format.
At the same time, the pressure to deliver results increases. A digital twin informing operational decisions often cannot wait for lengthy post-processing workflows to catch up.
Analysis Where the Data Already Lives
One response to this challenge is analyzing data while it is still in memory, before it has to cross the bottlenecks associated with data movement.
This is the operational shift behind in situ analysis. Rather than waiting until a simulation completes, teams can monitor the metrics that matter while runs are still in progress. A diverging simulation can be identified and stopped early, rather than consuming additional allocation time. The specific metrics, summaries, and data extracts engineers need can be generated during execution so useful results are available when the simulation ends rather than days, weeks, or months later.
The impact becomes even more significant at ensemble scale. Instead of producing large volumes of raw output that must be processed repeatedly, each simulation can generate directly comparable extracts that are immediately available for cross-run analysis. Storage and I/O demands decrease because data that will never be used no longer needs to be written. Engineers can begin evaluating results while simulations are still relevant to the project at hand instead of waiting until long after execution has completed.
Programs that have adopted this approach have reported one to three orders of magnitude less data written, along with meaningful end-to-end runtime improvements depending on the workload.
From Simulation to Decision
The challenge extends beyond deciding where analysis occurs. The pipeline that turns simulation runs into decisions involves more than a single analysis step. What information is extracted from the simulation, where the analysis happens, and what the next step requires all shape the outcome.
For some workflows, the central question is when and where analysis should occur. In situ analysis performs analysis while data remains in memory. In transit approaches, move data to dedicated analysis resources. Post hoc workflows analyze results after the simulation completes. ML-in-the-loop and co-simulation introduce additional requirements. Most serious programs rely on a combination of these approaches, making the choice of where each one fits an important design decision.
For other workflows, the more important question is what information is being extracted from the simulation. A design-of-experiments campaign requires coherent outputs that can be consumed directly by an optimizer or surrogate model. A digital twin requires specific reduced quantities delivered at a cadence that supports operational decision-making. In both cases, determining what gets extracted, in what format, and with what coordination across an ensemble is often more important than selecting a particular analysis mode.
These decisions are challenging because they depend on the simulations themselves, the available hardware, the needs of the ensemble workflow, and the downstream optimization, training, or digital twin pipelines that rely on the results. The objective is not simply to create an analysis workflow. It is to create a pipeline that produces decisions rather than archives.
Where ParaView Catalyst Fits
ParaView Catalyst is designed to bridge the gap between simulation data and real decisions. A simulation instruments against the thin Catalyst API once, and ParaView Catalyst serves as the backend that does the heavy lifting. From that single instrumentation point, a simulation code can run analysis in situ while data is still in memory, in transit on dedicated resources, or post hoc on saved extracts. The same instrumentation supports two-way computational steering where results feed back into the running simulation, and live interactive inspection through Catalyst Live. Because the mode is a runtime and configuration choice, a program can decide which approach to use where per workflow and revise it as needs change, whether on a CPU or GPU, a workstation or a leadership-class cluster.
Just as important is what runs inside the pipeline. ParaView Catalyst runs the full ParaView and VTK analysis library, so the reduced extracts, quantities of interest, and consistent per-run data that ensemble, optimization, and digital twin workflows depend on are produced using mature, well-tested tools that continue to improve. The instrumentation remains open and portable, which keeps adoption costs low.
The harder part is the design decision – what to extract, in what format, at what cadence, and how to coordinate it across an ensemble and into the optimization, training, or twin pipeline downstream. Those decisions depend on the simulation, the hardware, and the workflow, and they are where experience matters most. Kitware builds Catalyst and the surrounding stack and works directly with simulation programs to design the pipeline that turns runs into decisions. The workflow examples in Use Cases below show the approach applied to concrete problems, and the ParaView Catalyst Assessment is the place to start.
AI/ML in the Loop: Training and inference without the disk round-trip
Simulation teams increasingly want reduced-order models, neural operators, and other machine learning systems trained on high-fidelity runs. Instead of writing simulation data to disk and training offline, stream runtime data directly into AI training and inference workflows. Zero-copy, GPU-resident execution allows models to learn from every timestep the solver computes while avoiding the performance penalties of moving data between systems.
In our own pipelines, moving from a synchronous extract path to asynchronous execution reduced a representative workload from 9.14s to 0.65s while sustaining 80K+ steps per second on GPU. That is the difference between training that keeps pace with the solver and training that throttles it.
Aerospace and CFD: Quantitative analysis at solver speed
External aerodynamics workflows depend on quantitative engineering analysis, not just visualization. Compute lift and drag integration, vortex extraction, streamlines, boundary-layer metrics, and frontal area measurements directly during simulation instead of relying on sparse output snapshots. By performing analysis in situ, teams can track force distributions and flow structures across every timestep, generating reproducible engineering results that support validation, reporting, and design decisions.
Exascale Physics: When the data is too big to ever land
High-energy physics and other exascale simulations generate data at a volume where writing full timesteps to disk is no longer practical. In many cases, the simulation outruns the file system by orders of magnitude. Perform analysis and visualization where the data is created, on the same CPUs and GPUs the solver uses, or stage workloads in-transit onto dedicated resources when appropriate. Instead of deciding which few timesteps can be saved, teams can analyze the complete simulation as it runs and preserve only the results that matter.
Coupled Multiphysics: Conduit as the in-core bridge
Many multiphysics applications require two or more solvers to exchange field data at every timestep. Instead of routing data through disk or maintaining bespoke coupling code, simulations can share a common in-memory representation of meshes and fields that keeps data synchronized across applications. Success depends on consistent schema, partition handling, and complete metadata across the coupled workflow. When those foundations are in place, teams can build scalable co-simulation environments that exchange data accurately and efficiently throughout the entire run.
Digital Twins: A closed loop between model and asset
A digital twin must do more than visualize a physical asset. It must continuously compare live telemetry against a running model and adapt as conditions change. Operators can inspect the simulation while it runs, assimilate new sensor data, and steer the model in place to keep the twin aligned with the real-world system. By incorporating reduced-order and surrogate models into the workflow, teams can maintain faster-than-real-time performance, enabling monitoring, prediction, and operational decisions based on current conditions rather than historical snapshots.
Design of Experiments: Explore the space, not one run at a time
Large optimization and uncertainty quantification campaigns can generate hundreds of simulation runs, making it impractical to store full-field results for every ensemble member. Extract quantities of interest directly during runtime and generate compact summaries at full temporal fidelity. Those summaries can train surrogate models and feed optimization drivers, enabling adaptive sampling workflows that automatically determine where to explore the design space next.
Looking Ahead
Data volumes will continue to grow. Ensemble workflows will continue to expand. Digital twins will become increasingly operationally important. As these trends continue, the question facing simulation programs is not simply how to generate more data, but how to move from simulation to decision as efficiently as possible. The effectiveness of the analysis pipeline will increasingly determine how quickly simulation results can be transformed into actionable insights.
For a deeper look at how these challenges apply to production simulation programs, explore the ParaView Catalyst Assessment Report or contact Kitware’s HPC experts.