NWQ-Sim Simulation Framework

• NWQ-Sim is a multi-formalism HPC quantum simulation framework supporting state-vector, density-matrix, tensor-network, and stabilizer methods for heterogeneous systems.
• It employs advanced gate fusion, multi-backend processing, and a unified workflow interface to accelerate algorithm validation, noise modeling, and benchmarking on large-scale systems.
• Its tensor-network extension (TN-Sim) enables efficient simulation of circuits with controlled entanglement, promoting scalable studies in quantum benchmarking and digital twin applications.

NWQ-Sim, also written NWQSim, is a high-performance quantum circuit simulation environment for heterogeneous multi-node CPU/GPU systems and the “HPC simulation” component of the broader NWQWorkflow stack. It was originally designed around large-scale state-vector and density-matrix simulation, with an initial focus on “medium” qubit counts and high circuit depth on GPU clusters, and has since been extended into a multi-formalism package comprising exact pure-state simulation, explicit noisy simulation, matrix-product-state tensor networks, and stabilizer methods. In that evolution, the addition of the TN-Sim backend turned NWQ-Sim from a purely state-vector/density-matrix simulator into a full tensor-network simulation environment, while its role inside NWQWorkflow positioned it as the numerical backbone for algorithm validation, noise-aware “digital twin” studies, benchmarking, and software–hardware co-design (Suh et al., 2024, Hoyt et al., 7 Jan 2026, Li, 21 Jan 2026).

1. Historical development and scope

NWQ-Sim was developed as a quantum system simulation environment intended to exploit modern heterogeneous high-performance computing systems, including multi-node clusters with many-core CPUs and GPUs. Its early emphasis was gate-based quantum circuit simulation for NISQ-era workloads, especially deep, parameterized circuits, realistic device noise, and production-scale HPC deployment. In this phase, the package combined a high-performance state-vector simulator, SV-Sim, with a density-matrix simulator, DM-Sim, and exposed them through a unified framework with multiple frontends and hardware backends (Suh et al., 2024).

The later TN-Sim work broadened this scope substantially. Rather than only accelerating exact state-vector and density-matrix simulation, NWQ-Sim was extended toward tensor-network simulation so that circuit classes with bounded or truncated entanglement could be addressed efficiently. This changed the operational profile of the package: the original engines remain appropriate for deep circuits on qubit counts limited by $2^n$ or $4^n$ state growth, whereas TN-Sim targets large qubit counts, including “hundreds or more,” when the entanglement structure is compatible with an MPS representation or controlled bond-dimension truncation (Hoyt et al., 7 Jan 2026).

Within NWQWorkflow, NWQ-Sim is not an isolated simulator but a family of simulators that supports large-scale ideal and noisy numerical execution, multiple simulation formalisms, and integration with end-to-end compilation and execution workflows. The package is explicitly used for algorithm validation, noise modeling, benchmarking, digital twins, and closed-loop software–hardware co-design, including workflows that couple circuit generation, transpilation, simulation, and eventual execution on hardware testbeds (Li, 21 Jan 2026).

2. Software architecture, interfaces, and execution model

NWQ-Sim is organized as a layered simulation framework. At the user-facing level, circuits can be provided through C++, Python, Q#/QIR, Qiskit, QASM, and XACC frontends, while the C++ interface accepts OpenQASM 2.0, QIR, and XACC as inputs and the Python interface integrates with Qiskit. In the NWQWorkflow stack, logical circuits expressed in NWQASM are transpiled by QASMTrans or NWQEC into QASM2/NWQASM-compatible forms, then executed by the NWQ-Sim front end as OpenQASM2-style inputs (Suh et al., 2024, Li, 21 Jan 2026).

A notable internal preprocessing step is gate fusion. NWQ-Sim performs gate fusion using fuse_circuit_sv, rewriting a circuit as a sequence of generic 1- and 2-qubit gates and merging consecutive gates on overlapping qubits in order to reduce the number of contractions. The resulting fused gate list is then delegated to one of several backends. In the tensor-network setting, this same front-end flow feeds TN-Sim, which internally chooses ITensor for local runs or TAMM for distributed runs; users invoke NWQ-Sim with a chosen backend rather than interacting directly with ITensor or TAMM (Hoyt et al., 7 Jan 2026).

The package is therefore best understood as a multi-backend simulation layer rather than a single simulator kernel.

Backend	Internal representation	Primary role
SV-Sim	Full state vector of dimension $2^n$	Ideal functional simulation of general circuits
DM-Sim	Full density matrix of dimension $2^n \times 2^n$	Noisy and non-unitary simulation
TN-Sim	Matrix Product State tensor network	Low-bond-dimension or structured-circuit simulation
STAB-Sim	Stabilizer representation	Clifford-dominated and QEC-style circuits

This architecture is embedded in larger orchestration systems. NWQStudio exposes NWQ-Sim as a backend in its “Simulation” tab, where a transpiled circuit and a target HPC system such as NERSC Perlmutter can be selected; the GUI then launches jobs on the cluster and displays simulation time, memory usage, fidelity, and shot histograms. External orchestration layers have also incorporated NWQ-Sim. In the Quantum Framework, for example, NWQ-Sim appears as a backend selected through a property dictionary such as {"backend":"nwqsim", "subbackend":"MPI"}, with QFw translating higher-level circuits to NWQ-Sim execution through a backend-agnostic interface (Li, 21 Jan 2026, Chundury et al., 17 Sep 2025).

3. Core simulation engines and computational formalisms

SV-Sim is the full-state engine for ideal pure-state evolution. It stores the $2^n$-dimensional state vector across distributed resources, partitioning amplitudes across MPI ranks or analogous distributed-memory abstractions. The backend supports CPUs, NVIDIA GPUs, and AMD GPUs, and relies on MPI and OpenSHMEM for CPU multi-node execution, NVSHMEM for NVIDIA GPU-side direct communication, and MPI+RDMA or ROC_SHMEM for AMD GPUs. The implementation also uses aggressive gate fusion to reduce memory traffic and kernel-launch overhead, and it is characterized in the NWQWorkflow whitepaper as a “state-vector-based, full-scale functional simulator” (Li, 21 Jan 2026).

DM-Sim extends this exact approach to mixed states and noisy dynamics by evolving a density matrix of size $2^n \times 2^n$, with the corresponding $4^n$ memory growth. The backend supports non-unitary, noisy quantum circuit simulation and integrates depolarization, thermal relaxation, and readout noise. Device parameters are supplied through configuration files containing $T_1$, $T_2$, gate times, and readout fidelity, and the density-matrix evolution follows the standard completely positive trace-preserving channel form

$$\rho \mapsto \mathcal{E}(\rho) = \sum_k K_k \rho K_k^\dagger.$$

In practical use, this makes DM-Sim the noise-aware engine for device-level studies, open-system dynamics, and digital-twin workflows (Suh et al., 2024, Li, 21 Jan 2026).

STAB-Sim is the stabilizer backend for Clifford circuits and QEC-oriented workloads. It is described as a GPU-accelerated stabilizer simulator focused on QEC verification and designed to be faster than Google Stim and Qiskit’s stabilizer simulator. Its implementation relies on trivialization of Clifford operations such as $4^n$0, $4^n$1, and CNOT into structured updates of stabilizer generators rather than generic matrix operations, and it uses GPU warp- or wavefront-level primitives to accelerate measurement, which the whitepaper identifies as a typical bottleneck. The same source also states that STAB-Sim introduces a new error model that captures non-unitary $4^n$2 noise with improved performance while still being “exact” for most physical systems (Li, 21 Jan 2026).

Taken together, these three engines establish NWQ-Sim as a formalism-adaptive simulator family. Exact pure-state simulation, explicit density-operator simulation, and stabilizer simulation are all available under the same umbrella, with backend selection governed by workload characteristics rather than by a change of software stack.

4. Tensor-network extension: TN-Sim under NWQ-Sim

TN-Sim is the tensor-network backend that transformed NWQ-Sim into a full tensor-network simulation environment. It uses the Matrix Product State formalism for pure-state circuit simulation and couples two libraries: ITensor for local single-node jobs and TAMM, the Tensor Algebra for Many-body Methods framework, for distributed HPC-scale jobs. Conceptually, NWQ-Sim remains the front-end responsible for parsing, gate fusion, and circuit flow, while TN-Sim is the integrated tensor-network engine and ITensor or TAMM provide the tensor primitives, contractions, SVDs, and scheduling mechanisms (Hoyt et al., 7 Jan 2026).

The MPS representation replaces the exponentially large state tensor by a chain of local tensors,

$4^n$3

with physical dimension $4^n$4 per qubit and bond dimension $4^n$5. For fixed $4^n$6, the memory scaling becomes

$4^n$7

rather than $4^n$8. The implementation initializes $4^n$9 site tensors of shape $2^n$0 corresponding to $2^n$1, so that all initial bond dimensions are 1 and the starting state is unentangled. This supports the intended use case of large-$2^n$2 simulation when area-law entanglement or controlled SVD truncation is acceptable (Hoyt et al., 7 Jan 2026).

Gate application is divided into three cases. Single-qubit gates are purely local updates of one site tensor,

$2^n$3

Nearest-neighbor two-qubit gates use a contract–decompose procedure: two adjacent site tensors are merged into a rank-4 tensor, contracted with the gate tensor, and then split again by SVD, with optional bond-dimension truncation. Non-local two-qubit gates are handled differently in the two backends. The ITensor backend uses a bond propagation method, described as an MPO-like approach without explicit SWAP insertion, while the TAMM backend uses a SWAP-based strategy in which qubits are brought adjacent, the local gate is applied, and SWAPs are reversed afterward (Hoyt et al., 7 Jan 2026).

Sampling is based on the perfect sampling algorithm of Ferris and Vidal. The MPS is brought into left/right canonical form, marginal probabilities are computed from local reduced density matrices, one outcome is sampled and projected into the MPS, and this procedure is repeated sequentially over all qubits. For multiple shots, TN-Sim memoizes intermediate MPS substrings so that reduced density matrices for identical prefixes are not recomputed. This yields a measurement model that the paper describes as scalable and consistent with bitstring sampling on real hardware (Hoyt et al., 7 Jan 2026).

The distributed TAMM backend adds a systems layer beyond the MPS algorithms themselves. TAMM supplies global arrays for distributed data storage, a scheduler for tensor operations written in Einstein notation, and GPU offload. Because orthogonality and canonicalization routines were not native to TAMM, TN-Sim implemented them on top of TAMM. For SVD, the authors report a CPU-based path through Eigen but use NVIDIA cuSOLVER (cusolverDnZgesvdj) for GPU-accelerated performance on Perlmutter. To scale across multiple nodes, TN-Sim uses task-based parallelization for wide circuits with many gates per layer: the fused gate stream is converted into layers of disjoint gates, each layer is treated as a DAG level, and independent gates are claimed dynamically by ranks using AtomicCounterGA in a Blumofe–Leiserson style work-stealing model. Layer-level synchronization then commits updated MPS tensors and bond dimensions to the global arrays so that the next layer sees a consistent global state (Hoyt et al., 7 Jan 2026).

This tensor-network backend also repositions NWQ-Sim strategically. The exact engines remain essential for generic high-entanglement circuits, but TN-Sim provides the substrate for circuit cutting, approximate compilation, and complexity-oriented contraction studies, even though the paper states that such higher-level algorithms are not yet implemented in TN-Sim itself (Hoyt et al., 7 Jan 2026).

5. HPC scaling and benchmarked performance

NWQ-Sim’s principal distinguishing feature is its orientation toward leadership-class HPC systems. The NWQWorkflow whitepaper reports state-vector simulation up to 42 qubits on 4,096 NVIDIA A100 GPUs across 1,024 Perlmutter nodes and 40 qubits on 16,384 NVIDIA V100 GPUs across 4,096 Summit nodes. For density-matrix simulation, it reports 21-qubit density-matrix simulation on 4,096 A100 GPUs. These figures illustrate the intended scale of the exact backends and also expose their fundamental resource ceilings, since SV-Sim scales with $2^n$4 memory and DM-Sim with $2^n$5 memory (Li, 21 Jan 2026).

The earlier HPC overview paper emphasizes workload-level performance rather than absolute scale. There, NWQ-Sim is described as showing performance “comparable to or better than IBM Qiskit simulators” for deep quantum circuit simulations under specific environments, and “about 50% faster” for VQE workloads on GPU-based supercomputers. The same study uses TFIM time evolution and VQE as worked examples and reports agreement with Qiskit Aer noisy simulations while retaining the ability to scale on HPC systems (Suh et al., 2024).

TN-Sim introduces a different scaling regime. In GHZ-state benchmarks, the paper compares the ITensor MPS backend with NWQ-Sim’s own state-vector engine. Because the GHZ state requires bond dimension $2^n$6, memory scales as $2^n$7, and the reported runtime of TN-Sim grows near-linearly with qubit count whereas SV-Sim grows exponentially as $2^n$8. In brickwork-circuit benchmarks on Perlmutter, TN-Sim is evaluated for up to at least 64 qubits, depth 80, and fixed maximum bond dimension $2^n$9, with each node comprising 4 NVIDIA A100 GPUs and each node treated as one MPI rank. Under these conditions, the paper reports linear scaling in qubit count for fixed $2^n \times 2^n$0, good strong scaling of the compute portion from 1 to 4 nodes, and communication overhead that becomes dominant as node count increases because of synchronization and data movement (Hoyt et al., 7 Jan 2026).

An external benchmark of NWQ-Sim in the Quantum Framework further refines the performance picture. In that study, NWQ-Sim serves as the primary distributed state-vector backend and the authors conclude that Qiskit Aer’s matrix product state “excels for large Ising models,” while NWQ-Sim “leads on large-scale entanglement and Hamiltonian” and benefits from concurrent subproblem execution in distributed DQAOA. The reported trends are workload-specific: GHZ and Hamiltonian benchmarks favor the state-vector backend at larger sizes, TFIM favors Aer’s MPS backend because of the one-dimensional low-entanglement structure, and DQAOA exposes a separate advantage, namely that many subproblems can be dispatched concurrently across distributed resources with lower and more uniform iteration times than a cloud-based simulator (Chundury et al., 17 Sep 2025).

These results collectively show that NWQ-Sim’s performance profile is not monolithic. Exact state-vector simulation dominates when circuits are highly entangled and sufficient distributed memory is available; MPS-based TN-Sim dominates when bond dimension remains controlled; density-matrix simulation is reserved for explicitly noisy studies; and stabilizer methods are used when Clifford structure is present. The package’s significance lies as much in this backend plurality as in any single benchmark.

6. Workflow integration and application domains

Within NWQWorkflow, NWQ-Sim operates as the numerical execution layer that connects algorithm generation, compilation, error modeling, and control. NWQStudio uses it as a simulation backend; NWQASM and QASMTrans provide circuit IR and device-aware transpilation; NWQEC targets FTQC-oriented transformations; NWQLib provides application circuits; NWQData supplies device libraries, gate definitions, and noise parameters; and NWQControl/NWQSC connect simulation to superconducting hardware. In this ecosystem, NWQ-Sim provides both reference execution and noise-aware digital twins, allowing simulation and hardware results to be compared in a closed loop (Li, 21 Jan 2026).

The package has been used in several concrete application classes. The 2024 overview centers on the transverse field Ising model and variational quantum eigensolver workloads. For TFIM, NWQ-Sim simulates time evolution for a 4-spin chain initialized in $2^n \times 2^n$1 and computes the transverse magnetization

$2^n \times 2^n$2

For VQE, it uses the COBYLA optimizer to minimize the expected energy of a parameterized ansatz, with both ideal and noisy modes supported through SV-Sim and DM-Sim. These studies are presented as examples of NWQ-Sim’s suitability for variational workloads with dynamically generated circuits and repeated expectation-value evaluation (Suh et al., 2024).

The NWQWorkflow whitepaper broadens the application portfolio. It identifies algorithm validation and profiling for chemistry workloads such as VQE, ADAPT-VQE, GCM, QAOA, and linear solvers; noise-aware evaluation of compiled NISQ circuits; benchmarking through QASMBench; and QEC and fault-tolerance research through stabilizer simulation. A chemistry workflow is described in which ExaChem, SymGen, TAMM, and downfolding produce Hamiltonians, NWQLib generates circuits, QASMTrans or NWQEC compiles them, and NWQ-Sim executes them on HPC systems or provides the reference against which hardware results are compared. The same paper specifically mentions benzene and free-base porphyrin as end-to-end chemistry benchmarks in which NWQ-Sim serves as the numerical backend (Li, 21 Jan 2026).

TN-Sim opens additional domains even where the higher-level algorithms are not yet implemented. The tensor-network paper explicitly frames large-scale tensor-network simulation as useful for developing robust complexity-theoretic bounds on classical quantum simulation, enabling circuit cutting approaches, and optimizing circuit compilation. It also states that the TN-Sim backend is the necessary substrate for workflows such as circuit cutting and approximate compilation via tensor-network-based techniques such as AQC-Tensor, even though those workflows are not yet part of the implemented backend (Hoyt et al., 7 Jan 2026).

7. Constraints, common misunderstandings, and future directions

A frequent misunderstanding is to treat NWQ-Sim as synonymous with a single state-vector engine. The recent literature instead presents it as an umbrella package with at least four distinct backends—SV-Sim, DM-Sim, TN-Sim, and STAB-Sim—each optimized for a different computational formalism and workload class. The broader package is therefore heterogeneous by design, not only in hardware support but also in mathematical representation (Li, 21 Jan 2026).

A second misunderstanding is that HPC deployment removes the intrinsic complexity barriers of exact quantum simulation. The literature is explicit on this point. SV-Sim retains $2^n \times 2^n$3 memory growth and DM-Sim retains $2^n \times 2^n$4 memory growth, so their scalability remains fundamentally limited by exponential state size. TN-Sim alleviates this only for restricted entanglement structure or under controlled truncation, and the current TN-Sim implementation is limited to a 1D MPS topology and pure-state simulation (Hoyt et al., 7 Jan 2026, Li, 21 Jan 2026).

Noise modeling is likewise substantial but not exhaustive. DM-Sim supports depolarization, thermal relaxation, and readout noise using device parameters such as $2^n \times 2^n$5, $2^n \times 2^n$6, gate times, and readout fidelity, and STAB-Sim introduces a $2^n \times 2^n$7-based error model. At the same time, the 2024 overview notes that more exotic noise processes, such as correlated multi-qubit noise, are not explicitly discussed, and the whitepaper indicates that more complex noise, including correlated errors, crosstalk, and non-Markovian effects, is part of the longer-term roadmap rather than current documented functionality (Suh et al., 2024, Li, 21 Jan 2026).

The published roadmaps identify several concrete directions. For TN-Sim, these include additional tensor-network topologies such as PEPS and tree tensor networks, hyperoptimized contraction ordering, improved multi-GPU parallelization and distributed SVD, and Matrix Product Operators for density-operator simulation and explicit noise. For the broader package, the roadmap includes scaling to larger systems on exascale platforms, closer integration with QEC and control, more advanced FTQC workflows, and maturation of GPU+MPI support on platforms such as Frontier. External orchestration work also points toward automated workload-driven backend selection, reflecting the empirical observation that no single simulator is optimal across GHZ, TFIM, HHL, QAOA, and DQAOA workloads (Hoyt et al., 7 Jan 2026, Chundury et al., 17 Sep 2025).

In sum, NWQ-Sim is best characterized as a multi-formalism HPC simulation framework whose importance lies in the coexistence of exact, noisy, tensor-network, and stabilizer backends within a common software and workflow environment. Its technical trajectory has been from high-performance exact simulation toward a broader numerical platform for heterogeneous quantum-computing workloads, with tensor-network simulation and workflow-level integration marking the most consequential recent expansions.