arxiv: 2604.19869 · v1 · submitted 2026-04-21 · 🪐 quant-ph · cs.ET

Recognition: unknown

Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems

\'Alvaro Caride-Tabar\'es S\'anchez, Bernd Hoffmann, Daniel Bulmash, Eric Mansfield, Lukas Burgholzer, Marcel Walter, Noora F\"arkkil\"a, Patrick Hopf, Robert Wille, Teemu Mattsson

Authors on Pith no claims yet

Pith reviewed 2026-05-10 02:39 UTC · model grok-4.3

classification 🪐 quant-ph cs.ET

keywords quantum computingHPC integrationQDMIIQMSlurmQiskitsuperconducting quantum processorssoftware standardization

0 comments

The pith

Standardizing the quantum-HPC boundary with QDMI makes integration reusable across hardware providers.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper demonstrates a practical way to connect quantum computers to high-performance computing centers using a standardized interface called QDMI. By building an implementation for IQM superconducting systems and linking it to Slurm job schedulers and Qiskit user tools, it shows that custom engineering per vendor is avoidable. A sympathetic reader would care because quantum hardware is increasingly deployed in shared HPC facilities, and fragmented software stacks hinder moving from experiments to routine use. If the approach holds, operators and users can leverage the same software layers for different quantum backends.

Core claim

The authors present an IQM-backed QDMI layer that integrates with Slurm-based execution and Qiskit workflows. They argue that once the software-hardware boundary is standardized through QDMI, large parts of the integration stack become reusable across providers and deployment styles, as shown in their real-hardware case study with publicly available code.

What carries the argument

The Quantum Device Management Interface (QDMI), which acts as a standardized boundary layer between quantum hardware backends and higher-level HPC software components such as schedulers and user SDKs.

If this is right

Quantum hardware from different vendors can share the same integration code for HPC environments.
Existing Slurm workflows can schedule quantum jobs without vendor-specific modifications.
Qiskit users can access new hardware backends through the standardized interface.
The development effort for new quantum systems in HPC decreases as reusable components increase.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Adoption of QDMI by more vendors would allow HPC centers to treat quantum resources more like classical accelerators.
This standardization might enable higher-level optimizations like dynamic scheduling or resource sharing across quantum and classical nodes.
Future work could extend QDMI to include metrics for error rates or calibration data to improve job placement.

Load-bearing premise

That the QDMI specification is complete enough to support all necessary operations for real quantum hardware in production HPC settings and that vendors will implement it consistently.

What would settle it

Observing that the implemented QDMI layer cannot correctly translate or execute a standard quantum circuit from Qiskit on the IQM hardware, or that Slurm jobs fail to allocate resources properly due to missing functionality in the interface.

Figures

Figures reproduced from arXiv: 2604.19869 by \'Alvaro Caride-Tabar\'es S\'anchez, Bernd Hoffmann, Daniel Bulmash, Eric Mansfield, Lukas Burgholzer, Marcel Walter, Noora F\"arkkil\"a, Patrick Hopf, Robert Wille, Teemu Mattsson.

**Figure 4.** Figure 4: Architecture of the IQM QDMI device implementation. [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗

**Figure 5.** Figure 5: IQM QDMI device session setup sequence and resulting interaction with IQM Server API. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗

**Figure 6.** Figure 6: Property query sequence for IQM QDMI device. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗

**Figure 7.** Figure 7: IQM QDMI device job setup sequence and resulting interaction with IQM Server API. [PITH_FULL_IMAGE:figures/full_fig_p006_7.png] view at source ↗

**Figure 8.** Figure 8: Qiskit-facing adapter skeleton over QDMI. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png] view at source ↗

**Figure 9.** Figure 9: Illustrative Slurm submission pattern for QDMI-enabled execution. [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗

**Figure 11.** Figure 11: Simplified QSCI control flow showing execution-mode toggling. [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗

**Figure 12.** Figure 12: Schematic end-to-end workflow for QSCI execution. Numbers [PITH_FULL_IMAGE:figures/full_fig_p010_12.png] view at source ↗

read the original abstract

Quantum computers are moving into HPC centers, and the main challenge is now integration rather than pure hardware access. Many current software paths still depend on vendor-specific adapter chains between user SDKs, schedulers, and backend APIs. This pattern makes operations more complex than necessary and slows the transition from pilots to production workflows. We present a practical integration path centered on the Quantum Device Management Interface (QDMI). Using IQM superconducting systems as a hardware case study, we implement an IQM-backed QDMI layer and connect it to two software layers that HPC centers working with quantum computers already care about: Slurm-based job execution and Qiskit-facing user workflows. The implementation is publicly available at https://github.com/iqm-finland/QDMI-on-IQM. The key message is simple: integrating quantum hardware into HPC does not have to be a bespoke engineering effort for each backend. Once the software-hardware boundary is standardized, large parts of the stack become reusable across providers and deployment styles. Our results do not claim that standardization eliminates all HPCQC challenges. They show that this specific boundary can already be standardized today in a way that is practical for users, operators, and vendors.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

A concrete QDMI implementation for IQM that works with Slurm and Qiskit, but the cross-provider reusability is asserted rather than demonstrated.

read the letter

This paper reports a working QDMI layer for IQM superconducting systems, wired into Slurm job scheduling and Qiskit user workflows, with the code released on GitHub. They took an existing interface and made the vendor-specific part concrete so that two common HPC layers can talk to the hardware without custom adapters at every step. The abstract is clear that this does not remove every integration headache, only that the boundary itself can be standardized in a way that is already usable today. Releasing the actual code is the part that gives the work value beyond a description. People who need to connect similar hardware can inspect the adapters and see what was required to make the connections hold on real systems. The choice to target Slurm and Qiskit is sensible because those are the pieces centers already run. The main limitation is that everything is shown for one provider only. The central claim is that standardizing the boundary makes large parts of the stack reusable across vendors and deployment styles. Yet no second backend appears, no compatibility matrix is given, and there is no test showing that the upper layers would remain unchanged if another company supplied its own QDMI implementation. The reusability therefore stays as a stated benefit rather than a result backed by evidence in the manuscript. This work is aimed at HPC operators and quantum software teams who are moving systems into production environments. Readers who already use the mentioned tools will find the integration details useful as a template. I would send it for peer review. The implementation is grounded and the code is public, so referees can check whether the technical choices hold up and whether the approach offers a workable model for others.

Referee Report

1 major / 0 minor

Summary. The paper presents a practical case study of integrating IQM superconducting quantum hardware into HPC environments through the Quantum Device Management Interface (QDMI). It describes the development of an IQM-backed QDMI layer connected to Slurm-based job execution and Qiskit user workflows, with the full implementation released as open-source code at https://github.com/iqm-finland/QDMI-on-IQM. The central message is that standardizing the software-hardware boundary via QDMI makes large parts of the integration stack reusable across providers and deployment styles, without claiming to solve all HPCQC challenges.

Significance. If the demonstrated QDMI integration holds and the interface sees broader adoption, the work could meaningfully reduce the engineering overhead for incorporating quantum accelerators into production HPC systems. The public code repository is a clear strength, supporting reproducibility and community extension of the Slurm and Qiskit bindings.

major comments (1)

[Abstract] Abstract: The key claim that 'large parts of the stack become reusable across providers and deployment styles' is load-bearing yet rests on a single-vendor (IQM) implementation. No second backend is shown, no interface conformance tests across providers are reported, and no discussion is given of whether the upper-layer Slurm or Qiskit code would remain unchanged under a different vendor's QDMI realization.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and the recommendation for major revision. The comment correctly identifies a point where the abstract's phrasing could be clarified to better reflect the scope of a single-vendor case study. We address this below and have made targeted revisions to qualify our claims without altering the core contribution.

read point-by-point responses

Referee: [Abstract] Abstract: The key claim that 'large parts of the stack become reusable across providers and deployment styles' is load-bearing yet rests on a single-vendor (IQM) implementation. No second backend is shown, no interface conformance tests across providers are reported, and no discussion is given of whether the upper-layer Slurm or Qiskit code would remain unchanged under a different vendor's QDMI realization.

Authors: We agree that the empirical demonstration is confined to a single vendor, consistent with the paper's framing as a practical case study of IQM hardware integration rather than a multi-vendor benchmark. The reusability argument rests on the architectural separation: both the Slurm job plugin and the Qiskit provider are implemented exclusively against the QDMI API, with no IQM-specific code in those layers. Consequently, any future vendor-supplied QDMI backend that adheres to the interface specification would allow the upper-layer components to operate without modification. We have revised the abstract to state this more precisely, replacing the original phrasing with language that ties the reusability claim directly to the standardized boundary and the case-study illustration. We have also added a new paragraph in the Discussion section that explicitly addresses portability, including the conditions under which the Slurm and Qiskit integrations would transfer unchanged to another compliant QDMI realization. Cross-provider conformance testing and a second backend implementation lie outside the scope of this work, as only one production QDMI backend currently exists; the released open-source code is intended to enable such extensions by the community. These changes preserve the paper's central message while addressing the concern about overstatement. revision: partial

Circularity Check

0 steps flagged

Implementation report with no derivations, predictions or fitted quantities

full rationale

The manuscript reports a concrete QDMI implementation for one hardware backend (IQM) and its bindings to Slurm and Qiskit. It contains no equations, no parameter fitting, no predictions of new quantities, and no derivation chain. The reusability statement is presented as an engineering observation from the demonstrated case rather than a result derived from prior inputs or self-citations. No load-bearing self-citation, ansatz smuggling, or renaming of known results occurs. The paper is therefore self-contained as an implementation study.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No mathematical derivations, free parameters, axioms, or invented physical entities; the contribution is software engineering and interface implementation.

pith-pipeline@v0.9.0 · 5555 in / 973 out tokens · 25010 ms · 2026-05-10T02:39:39.724868+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

25 extracted references · 21 canonical work pages

[1]

OpenMP: An industry standard API for shared-memory programming,

L. Dagum and R. Menon, “OpenMP: An industry standard API for shared-memory programming,”IEEE Computational Science and Engineering, 1998.DOI: 10.1109/99.660313

work page doi:10.1109/99.660313 1998
[2]

RAJA: Portable performance for large-scale scientific applications,

D. Beckingsale et al., “RAJA: Portable performance for large-scale scientific applications,” inInternational Workshop on Performance, Portability and Productivity in HPC (P3HPC), 2019.DOI: 10.1109/P3HPC49587. 2019.00012

work page doi:10.1109/p3hpc49587 2019
[3]

doi: 10.1007/10968987_3

A. B. Yoo, M. A. Jette, and M. Grondona, “SLURM: Simple linux utility for resource management,” inJob Scheduling Strategies for Parallel Processing, Springer, 2003.DOI: 10.1007/10968987_3

work page doi:10.1007/10968987_3 2003
[4]

Integrating quantum computing resources into scientific HPC ecosystems,

T. Beck et al., “Integrating quantum computing resources into scientific HPC ecosystems,”Future Generation Computer Systems, 2024.DOI: 10.1016/j.future.2024.06. 058

work page doi:10.1016/j.future.2024.06 2024
[5]

Elsharkawy, X.-T

A. Elsharkawy et al., “Integration of quantum acceler- ators with high-performance computing—a review of quantum programming tools,”ACM Transactions on Quantum Computing, 2025.DOI: 10.1145/3743149

work page doi:10.1145/3743149 2025
[6]

Integrating quantum computing into workflow modeling and execution,

B. Weder, U. Breitenbucher, F. Leymann, and K. Wild, “Integrating quantum computing into workflow modeling and execution,” inInternational Conference on Utility and Cloud Computing (UCC), 2020.DOI: 10 . 1109 / UCC48980.2020.00046

work page arXiv 2020
[7]

Heterogeneous computing in a strongly-connected CPU-GPU environment: fast multiple time-evolution equation-based modeling accelerated using data-driven approach

E. Kaya et al., “A software platform to support dis- aggregated quantum accelerators,” inWorkshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2024. DOI: 10.1109/SCW63240.2024.00205

work page doi:10.1109/scw63240.2024.00205 2024
[8]

XACC: A system-level soft- ware infrastructure for heterogeneous quantum-classical computing,

A. J. McCaskey, D. I. Lyakh, E. F. Dumitrescu, S. S. Powers, and T. S. Humble, “XACC: A system-level soft- ware infrastructure for heterogeneous quantum-classical computing,”Quantum Science and Technology, 2020. DOI: 10.1088/2058-9565/ab6bf6

work page doi:10.1088/2058-9565/ab6bf6 2020
[9]

Accelerating HPC With Quantum Computing: It Is a Software Challenge Too

M. Schulz, M. Ruefenacht, D. Kranzlmueller, and L. B. Schulz, “Accelerating HPC with quantum computing: It is a software challenge too,”Computing in Science & Engineering, 2022.DOI: 10.1109/MCSE.2022.3221845

work page doi:10.1109/mcse.2022.3221845 2022
[10]

First practi- cal experiences integrating quantum computers with HPC resources: A case study with a 20-qubit superconducting quantum computer,

E. Mansfield et al., “First practical experiences inte- grating quantum computers with HPC resources: A case study with a 20-qubit superconducting quantum computer,” inWorkshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2025.DOI: 10.1145/3731599.3767551

work page doi:10.1145/3731599.3767551 2025
[11]

S. A. Caldwell et al.,Platform architecture for tight coupling of high-performance computing with quantum processors, 2025. arXiv: 2510.25213

work page arXiv 2025
[12]

Referencearchitectureofaquantum-centric supercomputer.arXiv preprint arXiv:2603.10970(2026)

S. Seelam et al.,Reference architecture of a quantum- centric supercomputer, 2026. arXiv: 2603.10970

work page arXiv 2026
[13]

Quantum resources in resource management systems,

U. Bacher et al.,Quantum resources in resource man- agement systems, 2025. arXiv: 2506.10052

work page arXiv 2025
[14]

Bridging paradigms: Designing for HPC-quantum convergence,

A. Shehata et al., “Bridging paradigms: Designing for HPC-quantum convergence,”Future Generation Computer Systems, 2026.DOI: 10.1016/j.future.2025. 107980

work page doi:10.1016/j.future.2025 2026
[15]

Seitz, M

R. Wille et al., “QDMI - quantum device management interface: Hardware-software interface for the munich quantum software stack,” inIEEE International Confer- ence on Quantum Computing and Engineering, 2024. DOI: 10.1109/QCE60285.2024.10411

work page doi:10.1109/qce60285.2024.10411 2024
[16]

The munich quantum software stack: Connecting end users, integrating diverse quantum technologies, accelerating hpc,

L. Burgholzer et al., “The Munich Quantum Software Stack: Connecting end users, integrating diverse quan- tum technologies, accelerating HPC,” inInternational Conference on High Performance Computing in Asia Pacific Region, 2026.DOI: 10.1145/3773656.3773669

work page doi:10.1145/3773656.3773669 2026
[17]

P. Hopf, S. Stern, R. Wille, and L. Burgholzer,Stan- dardizing access to heterogeneous quantum backends: A case study on cloud service integration with QDMI,
[18]

Technology and performance benchmarks of IQM’s 20-qubit quantum computer

L. Abdurakhimov et al.,Technology and performance benchmarks of IQM’s 20-qubit quantum computer, 2024. arXiv: 2408.12433

work page arXiv 2024
[19]

On-premises superconducting quantum computer for education and research,

J. Rönkkö et al., “On-premises superconducting quantum computer for education and research,”EPJ Quantum Technology, 2024.DOI: 10 . 1140 / epjqt / s40507 - 024 - 00243-z

2024
[20]

Javadi-Abhari et al.,Quantum computing with Qiskit,

A. Javadi-Abhari et al.,Quantum computing with Qiskit,
[21]

MQT Core: The backbone of the Munich Quantum Toolkit (MQT),

L. Burgholzer, Y . Stade, T. Peham, and R. Wille, “MQT Core: The backbone of the Munich Quantum Toolkit (MQT),”Journal of Open Source Software, 2025.DOI: 10.21105/joss.07478

work page doi:10.21105/joss.07478 2025
[22]

P. V . Sriluckshmy, F. Jamet, and F. Š. IV,Quantum assisted ghost Gutzwiller ansatz, 2025. arXiv: 2506 . 21431

2025
[23]

Shirakawa, J

T. Shirakawa et al.,Closed-loop calculations of elec- tronic structure on a quantum processor and a classical supercomputer at full scale, 2025. arXiv: 2511.00224

work page arXiv 2025
[24]

Kanno, M

K. Kanno et al., “Quantum-Selected Configuration Interaction: Classical diagonalization of Hamiltonians in subspaces selected by quantum computers,” 2023. arXiv: 2302.11320

work page arXiv 2023
[25]

AI Feynman: A physics-inspired method for symbolic regression.Science Advances, 6(16):eaay2631, 2020

J. Robledo-Moreno et al., “Chemistry beyond the scale of exact diagonalization on a quantum-centric supercom- puter,”Science Advances, 2025.DOI: 10.1126/sciadv. adu9991

work page doi:10.1126/sciadv 2025