OpenQARP: a modular framework for quantum application research

AI summary

Overview

Research area: Quantum computing software infrastructure — frameworks for developing, simulating, compiling, and costing quantum algorithms.

Technical level: Advanced. The paper assumes familiarity with quantum circuit simulation, Pauli/fermionic operator representations, compilation (routing, rebasing), and benchmark methodology.

Scope (one sentence): The paper introduces OpenQARP, an open-source Python framework with a compiled C++ core that unifies circuit construction, measurement protocols, simulation, device-aware compilation, circuit cutting, and resource estimation under one set of numerical conventions, and benchmarks it against OpenFermion, Qiskit/Aer, PennyLane/Lightning, Qulacs, qsim, and pytket.

What This Paper Is About

Quantum algorithm research usually requires stitching together several separate tools — one SDK for circuits, another for operators, another for simulation, another for compilation — and each brings its own qubit ordering, phase conventions, and performance quirks. The result is that research time is lost to integration and to silent convention bugs that produce plausible but wrong physics rather than crashes. OpenQARP's goal is to make the entire workflow — from ansatz to device-constrained cost estimate — fast and numerically trustworthy in a single framework, organized around three interchangeable interfaces rather than around any particular method.

Key Contributions

1. A three-layer compositional architecture. Circuits are blocks (objects representing meaningful operations, with symbolic parameters and known adjoints), measurements are primitives (what to extract: statevector, sampling, Pauli averaging, classical shadows, Hadamard/SWAP/mirror tests), and execution is engines (CPU statevector, optional GPU, plus compilation). Each layer can be swapped independently without touching the others.

2. A single authoritative conventions document, versioned with the code. It fixes qubit 0 as the least-significant bit everywhere, radians with the e^{-iθP/2} rotation convention, and treats global phase as physical — since a block's global phase becomes a relative phase under control or inside a linear combination of unitaries.

3. A compiled C++ core behind a Python research surface. Operator algebra, fermionic mappings, circuit optimization, routing, and simulation live in C++ bound with nanobind; Python block classes are genuine subclasses of their C++ counterparts, and gate parameters stay symbolic inside the core and are bound at run time. Simulation kernels are vendored from Qulacs and wrapped, with the framework's own contributions being gate fusion, a grouped expectation kernel, a fast path for structured phase-estimation circuits, batched execution, and the compilation pipeline.

4. Correctness-as-evidence testing and a public benchmark suite. Every numerical feature is tested against an independent oracle (analytic values, published results, OpenFermion or SciPy references, a plain-NumPy statevector implementation), and every published timing carries a correctness check. The benchmark suite ships as a public package with six tracks.

Main Findings

• Operator algebra is 10 to 50 times faster than OpenFermion across construction, accumulation, products, commutators, and all three fermionic mappings (Jordan–Wigner, Bravyi–Kitaev, parity). The gap widens with system size on the mappings: 29 times at 20 modes and 50 times at 40 modes. On symbolic coefficients the speedup exceeds two orders of magnitude (the symbolic_algebra row is 30,960 ms for OpenFermion versus 82.1 ms for OpenQARP).

• The margin comes from representation, not language. OpenFermion keys terms by tuples of (qubit, Pauli) pairs; OpenQARP holds a Pauli string in binary-symplectic form, one pair of 64-bit masks per 64 qubits, so a product is an exclusive-or plus four population counts regardless of term weight. Construction and accumulation run 5 to 11 times faster, products 15 to 17 times, commutators 35 times.

• One operator row goes the other way. Qiskit's SparsePauliOp is an order of magnitude quicker on Hermitian conjugation (0.6 ms versus 5.4 ms at 100,000 terms), because it stores dense bit arrays plus a coefficient vector and does the operation in one vectorized pass. At a million terms the cost is allocation rather than algebra, and the margin over OpenFermion narrows to 1.3.

• Statevector simulation leads every table row except one. At 20 qubits the brickwork, QFT, and Trotter circuits run in 40.1, 191.5, and 95.3 ms, against 50.7/238.3/111.7 for qsim and 125.0/222.5/217.2 for Aer. The exception is the 14-qubit molecular energy, where PennyLane's Lightning takes 4.7 ms against OpenQARP's 6.3 ms, because Lightning materializes the Hamiltonian as a sparse matrix (11.6 MiB at that width, but about 7 GB for a 2329-term operator at 20 qubits, a ceiling the streaming kernel does not have).

• Gate fusion is what closes the gap. OpenQARP folds runs of gates into dense blocks of at most three qubits, taking the 20-qubit brickwork, QFT, and Trotter fixtures from 228, 981, and 385 passes over the state to 20, 102, and 48. Three-qubit-block pass cost times those counts predicts 38, 192, and 90 ms against the measured 40.1, 191.5, and 95.3 ms.

• Grouped expectation contraction is a second, independent effect. Every Pauli string sharing a flip mask reads the same pair of amplitudes, so the kernel groups by mask and contracts once per group. LiH carries 631 terms in 84 groups and H2O 1086 terms in 162 groups, so a per-term engine makes three to seven times more passes.

• Against a plain-NumPy reference at 20 qubits, OpenQARP is 34 to 123 times faster. Against the fastest competitor the margin is 1.2 to 1.3 times at 20 qubits and wider below 16 qubits, where per-call dispatch rather than the kernel sets the time. qsim's float32 wheels give it a structural advantage no double-precision engine can claim, and its times are checked at a looser tolerance and are not like-for-like.

• Sampling is led by Qulacs and OpenQARP, 2 to 20 times ahead of the other three stacks, with Qulacs faster on the brickwork and shot-count rows and OpenQARP faster on the Trotter and QPE circuits. From 1k to 65k shots OpenQARP grows about tenfold and Qulacs about fourfold, while Aer and qsim grow by more than an order of magnitude and Lightning stays almost flat.

• Thread scaling and memory. OpenQARP, Aer, and qsim scale with core count by 4.5, 4.3, and 3.5 times from one thread to eight, while Qulacs and Lightning stay flat because the macOS wheels of both link no OpenMP runtime. OpenQARP's loaded baseline is about 126 MiB, against 31 MiB for Qulacs, 76 MiB for Aer, 357 MiB for Lightning, and 192 MiB for qsim.

• Compilation quality matches mature compilers on two-qubit gate count, with every compiler handed the identical coupling map and target basis and every compiled circuit checked against the coupling map and against its source circuit.

• The test suite is substantial: about 3000 Python test functions in 249 files and 47 C++ test files, a total-coverage floor of 94% that cannot be reduced, 80% patch coverage on every pull request, and around sixty example notebooks executed nightly.

• A real convention bug was caught by exact comparison. A Pauli-block constructor split a complex coefficient into global phase and magnitude and applied the phase only when the imaginary part was nonzero, so a block asked for -Z built +Z. A comparison up to phase passed it; the exact comparison caught it, before the dropped sign could become a relative phase under control.

Methodology in Plain English

The authors first fixed a problem of trust. In quantum software, a convention mistake rarely crashes a program — it returns a number that looks reasonable. So they wrote a single conventions document and gave it an executable form: a hand-built reference implementation sharing no code with the simulator, against which the C++ circuit transformations are pinned. Every gate matrix, argument ordering, and identity the document states is checked against a NumPy and SciPy oracle built from first principles. Property-based tests search invariants over generated inputs, and every counterexample found is pinned as a permanent regression case. Compiler passes are verified to preserve semantics exactly, with negative controls confirming a deliberately unrouted circuit is rejected.

For performance, they separated what a circuit does from how it runs, which lets the engine see the complete gate list and the complete sum of Pauli terms before executing anything. That visibility is what enables fusing neighboring gates into dense multi-qubit blocks and contracting every term sharing a flip mask in one pass.

For benchmarking, they made the comparison hard to bias. Each workload reduces to a canonical physical summary checked against an independent reference; a row whose check fails is not published. Competitors run their fast configurations — Aer for Qiskit, Lightning for PennyLane, qsim for Cirq — and each engine runs the gate fusion its public API exposes at the setting a per-host tuning sweep measured fastest. Every measurement runs in a fresh subprocess with medians of at least three repeats, pinned threads, and per-stack warmup. Results were generated on an arm64 macOS laptop in September 2026 with OpenQARP 0.1.0, qiskit 2.5.2 with qiskit-aer 0.17.2, pennylane 0.45.1 with lightning 0.45.0, qulacs 0.6.14, qsimcirq 0.22.1, openfermion 1.7.1, and pytket 2.18.1, all on Python 3.13.7; the code-volume track adds qiskit-nature 0.8.0 with qiskit-algorithms 0.4.0. A third party regenerates any table with python -m benchmarks.run <track>.

The end-to-end validation is a two-pass study of twisted ethylene, whose C=C torsion drives the molecule through a conical intersection where single-determinant methods fail. In a CAS(2,2) active space (four qubits), DOS-QPE phase-estimates e^{+iHτ} against a Dicke probe |D_4,2⟩ with 8 ancillas, a uniform mixture over the two-electron sector, so the sampled distribution peaks at the eigenphases of the triplet and the two lowest singlets at once; at a flap of 68° the two singlet peaks merge, which is the intersection seen directly in the sampled density of states. The second pass covers the full 0° to 90° torsion in CAS(2,3) (six qubits), where a short unitary coupled-cluster VQE supplies a walker basis and QC-QMC refines the ground-state energy; at 90° the ground state is a triplet with the lowest singlet a few mHa above it. Neither pass required code outside the framework.

Why This Matters

The paper's central argument is that a framework does not have to cost performance relative to a script written straight onto a simulator kernel — because the separation that makes it extensible is also what makes it fast. It also argues that numerical trustworthiness should be evidence rather than assertion: a convergence criterion, a variational bound, and a unit test written against the implementation's own output will all pass a wrong answer, so an independent oracle is the only rule that works. As the authors put it, this does not establish that the physics is right; it reduces the number of ways it can be wrong without failing a test.

Real-world applications the paper demonstrates or targets:

• Photochemistry and electronic structure. The ethylene notebook traces a conical intersection and a diradical torsion from pyscf integrals to a simulated spectrum, with exact diagonalization as the reference throughout.
• Combinatorial optimization. QAOA, PCE and its variants sit in the algorithm library, sharing the same variational parameter handling and classical optimizers (SciPy wrappers, Rotosolve, SPSA, and gradient descent including Adam).
• Spectroscopy. A pre-release version of the framework produced the numerical results in a study of nuclear magnetic resonance spectra with MMQCELS.
• Quantum Monte Carlo for fermions. A quantum-computing quantum Monte Carlo framework built on structured state preparation, and a seniority-zero state-preparation method whose UpCCD ansatz ships in the block library.

Industry relevance: OpenQARP is developed at Fujitsu Research of Europe and released open source. Its device model (qubit count, coupling map, gate set, noise), SABRE-based routing with portfolio search, Clifford+T synthesis via the Ross–Selinger method at a declared accuracy, and circuit cutting for problems wider than the register make it a tool for estimating what a computation would cost on real hardware, not only for idealized simulation. Circuit cutting implements quasi-probability decomposition of two-qubit gates with automated cut-location search by differential evolution, and guards the 6^k distinct experiments that k cuts require — with experiment counts explicitly distinguished from shot counts.

Future Directions

• Replacing the simulation kernel. The Qulacs-derived per-gate kernels are treated as an exchangeable implementation detail behind the engine interface, which the authors expect to revisit as simulation technology advances.
• Larger registers and broader hardware paths. The 22- to 26-qubit sizes are a separate opt-in pass of the suite and are not part of the reported run, and the GPU engine is an optional extra rather than part of the measured results.
• Growth by interfaces rather than methods. Since blocks, primitives, and engines are open axes, new routers, backends, and algorithms should be addable without touching the others — the authors state that methods from recent literature can typically be added quickly because an algorithm is a thin layer over primitives.
• Development practice. Since the Python-to-C++ rewrite, the framework has been developed with the help of coding agents under the conventions and test gates described in the paper, an approach whose longer-term consequences the paper does not evaluate.

Target Audience

Quantum algorithm researchers are the primary audience — especially those who build Hamiltonians, derive commutator pools for adaptive ansätze, or sweep parameterized circuits across optimizer iterations and are currently paying the integration tax across several SDKs. The paper is also relevant to quantum software engineers and compiler/simulator developers who care about pass-count accounting, fusion strategies, and how benchmarking should be made re-verifiable. Quantum chemists and materials researchers who need device-aware resource estimates will find the operator layer, fermionic mappings, and cutting tools directly applicable, and research groups evaluating frameworks for reproducibility will find the testing and benchmark methodology the most transferable part. Beginners will find the architecture descriptions readable but the benchmarks and conventions discussion demanding.

Authors’ abstract

We introduce OpenQARP, the Open Quantum Application Research Package: an open-source Python framework for quantum application research, built on a compiled C++ core. In OpenQARP, an application is assembled from an algorithm library that orchestrates three interchangeable layers: blocks describe circuits, primitives describe what to extract from them, and engines describe how they run. The release spans near-term through fault-tolerant methods, targeting problems from electronic structure to combinatorial optimization, with device-aware compilation, circuit cutting, and resource estimation over a single set of numerical conventions that the code must follow. Every numerical feature is checked against an independent oracle, and every published timing carries a correctness check. Against OpenFermion, Qiskit/Aer, PennyLane/Lightning, Qulacs, qsim, and pytket, OpenQARP is one to two orders of magnitude faster on operator algebra and among the fastest on simulation. It matches mature compilers on two-qubit gate count, and expresses a complete algorithm in the lines a framework needs rather than the plumbing a primitive stack demands.