NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines
Abstract
Quantum computing has in recent years evolved from a purely theoretical field to an active area in both academia and industry. As a result, Quantum Software Engineering has emerged as an area that aims to organize the process of building, testing, and running quantum software. However, writing quantum software still requires programming with quantum gates and qubits, as well as knowledge specific to quantum software frameworks such as Qiskit, Cirq, Qrisp, pyQuil and PennyLane, each of which reaches quantum hardware through its own toolchain. We present Quanifi, which packages the high-level routines of these frameworks as components on the Apache NiFi dataflow canvas. The components exchange circuits as OpenQASM 2.0, so a circuit built by one framework can be executed by another. This allows for two types of redundancy: several frameworks implement the same algorithm, and several engines (simulators or real hardware) execute the same circuit. We describe N×M program execution, which crosses the two: a single NiFi flow runs each of the N implementations on each of the M engines, and because every result is labelled with its implementation and its engine, a disagreement can be linked to an implementation, to an engine, or to a single implementation-engine pair. We ran Grover's algorithm built by three frameworks on three quantum computers from IBM, IQM and Quantum Inspire, and a matrix of three adder builders on one IQM device reached through two routes. N×M execution helped us discover three real defects: an incorrect gate-set declaration in the Quantum Inspire adapter, execution consistent with negated Rx angles on Tuna-17, and circuit modification through Open Quantum. The latter two returned wrong answers without reporting an error. We reported all three defects and Open Quantum's provider confirmed and fixed its QASM parsing defect.
Related
- EOS version 1.1: A Software for Flavor Physics Phenomenology
- QSoftCore: A Conceptual Foundation for Quantum Software Engineering
- CDFCI: High-Performance Parallel Software for Quantum Many-Body Eigenvalue Problems
- Know Your Qubits, Know Your Users: Personas for Quantum Software
- A Bohmian version of a 2-state quantum system
BibTeX
@misc{ramalho2026nxmversion,
title = {{NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines}},
author = {Neilson Carlos Leite Ramalho and Higor Amario de Souza and Anthony Accioly and Valter Vieira de Camargo and Marcos Lordello Chaim},
howpublished = {arXiv},
year = {2026},
month = sep,
doi = {10.48550/arxiv.2609.33255},
eprint = {2609.33255},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2609.33255},
note = {CC BY 4.0},
}
RIS
TY - UNPB
TI - NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines
AU - Neilson Carlos Leite Ramalho
AU - Higor Amario de Souza
AU - Anthony Accioly
AU - Valter Vieira de Camargo
AU - Marcos Lordello Chaim
PY - 2026
DA - 2026/09/27
PB - arXiv
DO - 10.48550/arxiv.2609.33255
UR - https://arxiv.org/abs/2609.33255
AB - Quantum computing has in recent years evolved from a purely theoretical field to an active area in both academia and industry. As a result, Quantum Software Engineering has emerged as an area that aims to organize the process of building, testing, and running quantum software. However, writing quantum software still requires programming with quantum gates and qubits, as well as knowledge specific to quantum software frameworks such as Qiskit, Cirq, Qrisp, pyQuil and PennyLane, each of which reaches quantum hardware through its own toolchain. We present Quanifi, which packages the high-level routines of these frameworks as components on the Apache NiFi dataflow canvas. The components exchange circuits as OpenQASM 2.0, so a circuit built by one framework can be executed by another. This allows for two types of redundancy: several frameworks implement the same algorithm, and several engines (simulators or real hardware) execute the same circuit. We describe N×M program execution, which crosses the two: a single NiFi flow runs each of the N implementations on each of the M engines, and because every result is labelled with its implementation and its engine, a disagreement can be linked to an implementation, to an engine, or to a single implementation-engine pair. We ran Grover's algorithm built by three frameworks on three quantum computers from IBM, IQM and Quantum Inspire, and a matrix of three adder builders on one IQM device reached through two routes. N×M execution helped us discover three real defects: an incorrect gate-set declaration in the Quantum Inspire adapter, execution consistent with negated R_x angles on Tuna-17, and circuit modification through Open Quantum. The latter two returned wrong answers without reporting an error. We reported all three defects and Open Quantum's provider confirmed and fixed its QASM parsing defect.
ER -