In-Situ Visualization vs Post-Processing — A Decision Framework

Key Takeaways

• In-situ visualization processes data in-memory during simulation; post-processing saves raw data to disk then reads it back for analysis.
• In-situ can reduce total energy consumption by ~43% by eliminating system idle time — not just I/O overhead.
• In-situ serves as an early-warning system for numerical divergence, instability, and anomalies before wasting core-hours.
• The hybrid strategy (in-situ reduction → selective saving → post-processing on reduced data) is the modern standard for HPC workflows.
• Post-processing still wins for exploratory analysis, small datasets, and archival/re-analysis needs.
• Your choice should go beyond “data size” — consider I/O sufficiency, storage quota, temporal resolution, analysis predictability, resource contention, and archival needs.

Introduction

When you’re running a simulation — whether it’s a computational fluid dynamics (CFD) case, a phase-field model, or a molecular dynamics run — you eventually need to visualize the results. You have two main strategies: in-situ visualization, where you analyze data while the simulation is still running, or post-processing, where you save the full dataset to disk and analyze it afterward.

Choosing between them isn’t just a technical detail — it affects your simulation’s performance, energy consumption, debugging capability, and the flexibility you have for future analysis. Most researchers encounter this decision early in their HPC career and make a choice based on intuition or team convention rather than a structured framework.

For deep technical coverage of in-situ infrastructure, tools, and implementation patterns, see our guide to in-situ visualization. Here, we’re taking a different angle: a practical decision framework that answers “when should I use each approach?” and introduces two dimensions most comparison articles miss — the energy savings argument and the debugging use case.

The Classic Comparison

Before diving into the new dimensions, let’s establish the baseline difference between the two approaches, since this foundational comparison is already well-covered in our in-situ visualization guide.

In-situ visualization runs visualization and analysis code in the same memory space as your simulation. The data never touches disk — it flows from the simulation solver directly into a visualization pipeline. This eliminates file I/O entirely for the visualization path.

Post-processing works the opposite way. Your simulation writes full datasets to disk at regular intervals (or at convergence milestones). After the simulation completes, you load those files into a separate visualization tool — ParaView, VisIt, or similar — and explore the data interactively.

The classic trade-off is simple:

This comparison has been well-documented by Moreland (2016) in “The Tensions of In Situ Visualization,” which lays out the fundamental trade-offs around resource contention, data loss, and coupling complexity. Our guide to in-situ visualization walks through the implementation patterns, tool comparisons, and integration strategies in depth.

The decision isn’t obvious from this table alone, though. Here’s where things get interesting.

The Energy and Greenness Dimension

This is the insight most articles in this space miss. In-situ visualization doesn’t just speed up your workflow — it significantly reduces energy consumption, and the savings are larger than you’d expect.

Where the energy savings come from

Multiple studies from Virginia Tech (notably Adhinarayanan et al. 2015 and the follow-up characterization study in 2017) measured the power and energy of visualization pipelines and found that in-situ approaches consume roughly 43% less total energy than traditional post-processing workflows.

Here’s the critical detail most sources don’t explain clearly: the majority of these savings don’t come from avoiding I/O writes. They come from eliminating system idle time.

When you run post-processing on an HPC system, the compute nodes finish their simulation and sit idle while the storage subsystem processes the dumped data. Those idle nodes still draw power — potentially significant power — while doing nothing productive. In-situ visualization avoids this entirely because analysis happens concurrently with computation, keeping all nodes working.

The Tahir (2024) “Energy-Aware Image-based In Situ” study extends this analysis further, showing that rendering parameter choices within in-situ workflows affect energy consumption. Selecting efficient rendering algorithms — for example, optimized particle-based volume rendering instead of heavy ray casting — yields additional energy savings. The “green” choice matters even inside in-situ pipelines.

Why this matters for your workflow

If you’re running simulations on shared HPC resources, energy consumption directly affects:

• Wall-clock time — faster simulations complete sooner, reducing wasted compute time
• Resource allocation — many HPC centers allocate time based on node-hours consumed
• Environmental impact — large simulations can consume megawatt-hours of energy

For PIs managing grant budgets and HPC administrators evaluating resource utilization, the energy argument is a legitimate reason to consider in-situ even when data sizes are manageable.

What we recommend: If your simulation exceeds a few gigabytes of output per run, the energy savings alone make a case for in-situ. For large-scale HPC jobs, the ~43% savings is substantial enough to factor into your workflow design — not just a nice-to-have.

In-Situ as a Debugging and Early-Warning Tool

This is where our article introduces genuinely new territory that existing guides don’t cover well. In-situ visualization isn’t just about seeing results faster — it’s a debugging strategy for numerical simulations.

Catching divergence before it costs you

When a simulation diverges — whether from numerical instability, physical parameter mismatches, or mesh quality issues — the cost compounds with every timestep. If you’re saving data for post-processing and discover divergence after 50 core-days have been consumed, that’s a devastating outcome.

In-situ visualization gives you immediate visual feedback. You can spot divergence, instability, or anomalies the moment they develop and stop the simulation before it wastes millions of core-hours. The Bennett (2019) DAG Report on In Situ Visualization describes this as the “simulation dashboard” concept — using real-time visualization for visual debugging, co-scheduling, and steering.

Multiple studies reinforce this pattern:

• Kitware’s practical CFD examples (2024) describe “early error detection through immediate visual feedback” as a core benefit
• Sandia’s ML-driven defect monitoring work (Shaaban 2026, Shead 2023) uses in-situ pipelines for anomaly detection
• The EXCELLERAT best-practices guide (2022) frames real-time visualization as an error-prevention tool for exascale workflows

Practical debugging use cases

Here are scenarios where in-situ visualization pays off as a debugging tool:

• Coupled physics simulations — spotting energy or mass conservation violations before they compound
• Adaptive mesh refinement (AMR) — verifying mesh quality and refinement logic as it develops
• Turbulence and CFD — detecting non-physical oscillations, shock artifacts, or numerical diffusion
• Reaction-diffusion and phase-field — identifying unstable interfaces or parameter drift

The key insight: you’re not waiting until the simulation finishes to know whether it’s behaving correctly. You know while it’s running.

What we recommend: If your simulation is computationally expensive (more than a few hours on multiple nodes) or physically coupled, run it in-situ with at least one diagnostic visualization — a slice through a key variable, a time-history plot, or an isosurface. Even a single in-situ plot can save you days of wasted compute time.

Decision Framework: 6 Criteria to Guide Your Choice

The classic framing of “data size” as the deciding factor is incomplete. The EXCELLERAT best-practices guide (2022) and multiple HPC workflow studies suggest a richer set of criteria. Here are six factors to weigh when choosing between in-situ and post-processing.

1. I/O Bandwidth Sufficiency

Question: Does your system have enough I/O bandwidth to write your full datasets at the frequency you need?

Why: If I/O is already saturated by your simulation, adding full visualization datasets can cause I/O contention that slows the simulation itself. In-situ bypasses the I/O path entirely for visualization.

2. Storage Quota Constraints

Question: Are you constrained by storage quota or archival policies?

Why: Large simulations can generate terabytes of output. If your storage quota is fixed, in-situ reduces the amount you need to save while preserving the insights you need.

3. Temporal Resolution Needs

Question: Do you need to observe fine-grained temporal phenomena (e.g., autoignition in combustion, wave propagation, turbulence cascades)?

Why: Kitware’s CONVERGE/combustion example (2024) demonstrates how in-situ can save isosurfaces of temperature and pressure gradient at high frequency — capturing phenomena that would be lost if the full dataset were written at a lower frequency. The full dataset from that case was ~100 GB, but in-situ reduced the saved data to ~100 MB while preserving the critical features.

4. Analysis Predictability

Question: Do you know what you want to visualize beforehand, or will you explore freely?

Why: In-situ pipelines are defined before or during the simulation run. You can’t change them interactively. If you’re discovering new phenomena or iterating on visualization parameters, post-processing gives you the flexibility.

5. Resource Contention Tolerance

Question: Can you tolerate the compute resources consumed by visualization running alongside simulation?

Why: In-situ visualization shares compute resources with the simulation. If your simulation is already resource-constrained, adding visualization code can slow it down. The Moreland (2016) tension analysis covers this trade-off in detail.

6. Archival and Re-Analysis Needs

Question: Will you need to re-analyze this dataset later with new filters or different visualization parameters?

Why: This is the most commonly overlooked trade-off. When in-situ discards raw data after producing reduced representations (Cinema databases, isosurfaces, statistics), you lose the ability to re-analyze with new filters. Users who switch to in-situ without planning for archival often express regret about not preserving raw data.

What we recommend: Run this decision framework against your specific simulation. If 4+ criteria lean toward in-situ, it’s likely the right choice. If 4+ lean toward post-processing, stick with the traditional workflow. If the criteria are split evenly, the hybrid strategy (next section) may be your best path.

The Hybrid Strategy: Modern Standard

The emerging standard for mature HPC workflows isn’t “in-situ vs post-processing” — it’s both.

The pattern is straightforward: perform data reduction and feature extraction in situ, then generate visualization in-transit on the reduced data. The canonical example is the Catalyst-ADIOS2 workflow: Catalyst performs in-situ data reduction (extracting isosurfaces, computing statistics, generating Cinema databases), and ADIOS2 transports the reduced datasets to visualization nodes for post-hoc exploration.

This approach captures the benefits of both worlds:

• In-situ reduction eliminates I/O bottlenecks and idle time (energy savings)
• In-transit exploration preserves flexibility for iterative analysis
• Selective saving means you only write the data you actually need

Kitware’s 2025 broader HPC overview frames this as the default pattern for “exascale-ready” workflows. The ArXiv 2024 paper “In Situ In Transit Hybrid Analysis with Catalyst-ADIOS2” describes the typical modern pattern in detail.

Practical hybrid workflow

1. Define visualization and analysis pipelines before the simulation starts (Catalyst scripts, Ascent recipes)
2. Run the simulation with in-situ data reduction — extract the features you need while it’s running
3. Monitor via real-time plots or snapshots for debugging and steering
4. Save only the reduced datasets (not the full simulation state)
5. Post-process on the reduced data using ParaView, VisIt, or your preferred tool

This is what the EXCELLERAT best-practices guide (2022) recommends as the “best practice” pattern for exascale visualization at scale.

What we recommend: If you’re running large-scale simulations (100+ GB per run, multi-node, or HPC-cluster runs), adopt the hybrid strategy as your default. It gives you the performance and energy benefits of in-situ without sacrificing the analytical flexibility of post-processing. Only pure post-processing makes sense when your datasets are small enough that I/O overhead is negligible.

When Post-Processing Still Wins

In-situ gets a lot of attention, but post-processing remains the right choice in several important scenarios. Don’t abandon it entirely — use it strategically.

Exploratory analysis

If you’re developing new visualization techniques, testing analysis pipelines, or simply exploring a dataset without knowing what you’ll need, post-processing is unmatched. You can load the data, apply arbitrary filters, and iterate. In-situ pipelines can’t offer this flexibility — they require predefined logic.

Small datasets

If your simulation produces less than a few gigabytes per run and runs on a single node or a small cluster, the I/O overhead of post-processing is likely negligible. The flexibility of post-processing outweighs the minor performance cost.

Algorithm development

When you’re developing new numerical methods, testing convergence rates, or iterating on solver parameters, you need full data fidelity. Post-processing preserves every timestep and every field. In-situ reduction discards information you may later regret losing.

Archival and reproducibility

If your simulation is part of a published study or a reproducible workflow, post-processing gives you a clear audit trail: the raw data files, the post-processing scripts, the resulting visualizations. The “data loss” trade-off of in-situ (discarding raw simulation state after extraction) makes reproducibility harder when you need to re-analyze with new methods.

When to choose post-processing over in-situ

Use post-processing when:

• Your dataset is small enough that I/O overhead is acceptable
• You need iterative, exploratory analysis
• You’re developing or testing new visualization techniques
• Reproducibility and archival require full data preservation
• You don’t have access to in-situ-compatible tools or the integration expertise

Tool Landscape Brief

You don’t need to build in-situ infrastructure from scratch. Several mature tools make integration straightforward.

ParaView Catalyst

The most widely adopted in-situ library. ParaView Catalyst provides a small, stable API for simulation codes to expose data structures in memory to ParaView’s processing engine. Once instrumented with Catalyst, a simulation code can harness ParaView’s full analysis and visualization capabilities.

• Best for: Large-scale CFD, combustion, and multiphysics simulations
• Example: CONVERGE CFD uses Catalyst for in-situ combustion analysis (Kitware 2024)
• Integration complexity: Moderate — requires initial instrumenting, then runs Catalyst scripts as predefined pipelines

Ascent

A lightweight in-situ framework from Kitware designed for easy integration. Ascent provides a simple YAML-based recipe language for defining in-situ pipelines without deep C++ knowledge.

• Best for: Teams wanting quick in-situ integration without deep code changes
• Integration complexity: Low — YAML recipes, minimal C++ integration required
• Limitation: Smaller ecosystem than Catalyst; less mature for exascale deployments

VisIt LibSim

The in-situ library for VisIt. Similar to Catalyst but integrated with the VisIt ecosystem.

• Best for: Teams already invested in the VisIt ecosystem
• Integration complexity: Moderate — requires LibSim instrumenting

Damaris

A newer, standards-based in-situ framework designed for portability across visualization tools. Damaris uses a standardized API that decouples simulation from specific visualization backends.

• Best for: Multi-ecosystem deployments (wanting to use multiple visualization tools)
• Integration complexity: Higher — newer, less established toolchain
• Notable: Gaining traction in European HPC communities

Tool selection guidance

The EXCELLERAT best-practices guide (2022) provides detailed comparison tables for in-situ interfaces and tool recommendations at exascale. Their analysis suggests Catalyst as the most mature option for production HPC workflows, with Ascent as a strong lightweight alternative.

Summary + Next Steps

Choosing between in-situ visualization and post-processing isn’t a binary “which is better” question. It’s a workflow design decision that should account for data size, energy, debugging needs, flexibility, and archival considerations.

Here’s our recommendation distilled to three principles:

1. For large-scale HPC simulations (100+ GB, multi-node), adopt the hybrid strategy: in-situ reduction with selective saving, followed by post-processing on the reduced data. This gives you the energy savings (~43% total energy reduction per VT studies), the debugging benefits, and the analytical flexibility you need.
2. For small-to-medium simulations (<10 GB, single-node or small cluster), post-processing is usually simpler and more flexible. Don’t add in-situ complexity unless you specifically need the debugging or energy benefits.
3. Always consider debugging. Even if you choose post-processing for the main workflow, running at least one in-situ diagnostic plot (a time-history, a key slice, or a convergence monitor) can save you hours of wasted compute time when divergence occurs.

Practical next steps

• If your current workflow is purely post-processing and you’re running large simulations: evaluate Catalyst or Ascent for in-situ data reduction. Even a simple pre-defined slice or statistics pipeline will cut I/O and idle time.
• If you’re already using in-situ but haven’t explored debugging: add at least one early-warning visualization (time-history plot, isosurface of a key field, or anomaly detection). The Bennett (2019) DAG Report’s “simulation dashboard” concept is a good starting point.
• If you’re planning archival workflows: decide what raw data to preserve before switching to in-situ. Don’t discard simulation state you might need for future analysis.

The visualization decision is one of the few simulation workflow choices that directly impacts both performance and insight quality. Get it right, and your simulations run faster, save energy, and catch errors early. Get it wrong, and you waste compute time, storage, and potentially miss phenomena you can’t re-analyze. Use this framework to make an informed choice.

Related Guides

For deeper coverage on related topics, here are some additional resources from our site:

• In-Situ Visualization: Integrating Visualization During Computation — Our comprehensive guide to in-situ infrastructure, tools, and implementation patterns.
• VisIt vs ParaView: Choosing the Right Tool for Your Simulation Data — A comparison of the two most widely used visualization frameworks for scientific data.
• Illuminator Distributed Visualization Library — Overview of a specialized tool for parallel rendering and storage.
• Managing Large-Scale PDE Problems: Strategies, Solvers, and HPC Case Studies — Strategies for solving massive computational problems efficiently.
• Advection-Dominated Problems: Upwind Schemes and SUPG Stabilization — Practical guidance for stabilization techniques in CFD simulations.

References and sources cited in this article:

• Kitware (2024). In Situ Data Analysis Brings Faster Results and Accelerated Insights
• Adhinarayanan et al. (2015). On the Greenness of In-Situ and Post-Processing Visualization Pipelines
• Adhinarayanan et al. (2017). Characterizing Modeling Power & Energy for In-Situ Visualization
• Bennett, J. (2019). DAG Report: In Situ Visualization
• Moreland, K. (2016). The Tensions of In Situ Visualization
• EXCELLERAT (2022). Best Practices and Tools for Visualization, Data Management and Analytics at Exascale
• Tahir, M. (2024). Analysis Towards Energy-Aware Image-based In Situ