Quantum software components unify multiple frameworks and engines
NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines
Software Engineering
Summary
Quantum computing software is complicated because different tools use their own languages and methods to run programs on quantum computers. The authors developed Quanifi, a system that lets many different quantum programming tools work together and run programs across various quantum computers or simulators. By running the same quantum program across multiple tools and devices, Quanifi can spot errors in either the software or the hardware. The authors tested this approach with known algorithms and discovered real problems that they helped get fixed.
What this means in practice
- •For quantum software developers: Run and test quantum programs across multiple software frameworks and hardware platforms to detect errors or inconsistencies early.
- •For quantum hardware engineers: Compare execution results from different quantum engines on the same circuits to identify hardware-specific errors or inaccuracies.
Authors
Neilson Carlos Leite Ramalho, Higor Amario de Souza, Anthony Accioly, Valter Vieira de Camargo, Marcos Lordello Chaim
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$\times$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$\times$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.