What’s New in In Situ Analysis and Visualization with ParaView Catalyst

As HPC systems scale, the bottleneck is increasingly shifting from compute to data movement. While compute performance continues to improve, storage and interconnect bandwidth have not kept pace. As a result, moving data between devices and storage can become one of the largest performance constraints in modern simulation workflows.

That gap is why in situ analysis has moved from optional to expected on leadership-class systems. The recent webinar, What’s New in In Situ Analysis and Visualization, walks through three new capabilities in ParaView Catalyst 2.1 that address it and demonstrates each on a running GPU simulation.

Data Gravity and the New Bottleneck

Traditional workflows write full-resolution simulation state to disk and analyze it afterward. That model worked while I/O could keep up with compute. On today’s systems, it can’t. Writing every timestep for a large 3D run is often infeasible; writing every hundredth is common but loses transient phenomena that matter.

Rather than moving large simulation datasets for analysis, in situ approaches bring analysis to the data. Keeping analysis on the same device as the simulation reduces unnecessary data movement and makes better use of available bandwidth.

Catalyst has supported this pattern for years by running the analysis pipeline in the solver process, without a disk write. What’s new in 2.1 is that the pipeline no longer has to run synchronously with the solver and no longer has to run on the CPU. Both were architectural constraints of the original design that made sense when analysis workloads were light. Neither assumption holds anymore.

Inside the Catalyst 2.1 Demonstrations

To illustrate these concepts, the webinar demonstrates three new capabilities introduced in ParaView Catalyst 2.1 using a 2D fluid simulation running on a single CUDA GPU. Reference implementations are available in catalyst-examples for developers who want to explore the examples themselves.

Asynchronous execution. Historically, catalyst_execute ran the analysis pipeline on the solver’s thread, and the solver blocked until every filter finished. Catalyst 2.1 introduces an optional worker-thread mode: catalyst_execute snapshots the per-step Conduit tree onto a bounded queue and returns immediately, while a worker thread runs the pipeline in parallel with the next solver step. In the demonstration, synchronous execution kept the solver blocked 33% of wall-clock time; asynchronous execution reduced that to 6%, allowing the solver to complete 27% more iterations in the same window. The trade is bounded memory for the queue in exchange for freeing the solver from waiting.

GPU-resident workflows. With set_external, Catalyst 2.1 accepts CUDA device pointers directly in the Conduit tree that the adaptor hands it. No host staging copy is required from the adaptor side. Filters that dispatch through Viskores execute on the same device buffer the solver just wrote. In the demonstration, four field arrays live in GPU memory throughout the run and are analyzed there, with no per-step transfer to host.

Closed-loop steering with catalyst_results. The catalyst_results API opens a return channel from the pipeline back to the solver. In the demonstration, an on-device Viskores reduction computes a scalar signal from the flow field. That single value is returned to the driver, which uses it as the input to a controller adjusting the solver’s boundary condition on the next step. The round-trip stays on device except for eight bytes of scalar crossing to the driver: field data never leaves the GPU. This is the substrate for the more elaborate patterns on the roadmap, such as catalyst-ml for in situ ML training and catalyst-cosim for multi-physics coupling.

Integration Considerations for HPC Environments

Catalyst is vendor-portable by design. The Conduit data model is API-agnostic, and Viskores filters run through Kokkos, which compiles to CUDA, HIP, SYCL, or OpenMP. The same integration pattern demonstrated here on NVIDIA hardware works on AMD (MI300X) and Intel (Max GPU) without adaptor changes. On unified-memory systems like Grace Hopper and MI300A, the programming model is easier, but the recommendation is the same: keep analysis on the device that owns the data.

Whether async or sync is the right choice depends on the ratio of pipeline cost to solver step cost and on what resources are idle on the node. GPU solvers typically leave CPU cores unused, which is exactly the configuration async is designed for. Codes where the pipeline is very lightweight (with only a few reductions per step) often gain little from async and remain synchronous. Codes where the pipeline is much heavier than the solver step and needs dedicated hardware are better served by in-transit deployment via ADIOS2 SST and Fides, supported today, with ongoing improvements to the Fides OutputBuilder making that integration cleaner. Further out, catalyst-ml packages ML-specific service patterns on top of the same in-transit substrate.

Learn More About ParaView Catalyst Integration

If you’re evaluating how in situ analysis fits an existing simulation workflow, Kitware’s ParaView Catalyst Assessment offers a focused review of your codebase and integration path. To discuss a specific integration or ask about capabilities not covered in the webinar, contact us. We’d like to hear about the workflow you’re trying to accelerate.