Pith. sign in

REVIEW 1 major objections 2 cited by

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

T0 review · 1 major / 0 minor · reviewed 2026-05-10 · grok-4.3

Challenge this review Download PDF Read on arXiv ↗

Pith's one-line read Standardizing the quantum-HPC boundary with QDMI makes integration reusable across hardware providers.

desk verdict 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 →

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

Lukas Burgholzer , Marcel Walter , Patrick Hopf , Álvaro Caride-Tabarés Sánchez , Teemu Mattsson , Bernd Hoffmann , Noora Färkkilä , Daniel Bulmash
show 2 more authors
Robert Wille Eric Mansfield
This is my paper
classification quant-phcs.ET
keywords quantumcomputingHPCintegrationQDMIIQMSlurmQiskitsuperconductingprocessorssoftwarestandardization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

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.

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.

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.

Watch

Extended reading notes

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.

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.

Editorial extensions

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.

Reading between the lines

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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

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)
  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

  1. 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 · score 0.0 of 10

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.

Assumptions & free parameters 0 free parameters · 0 assumptions · 0 invented entities

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

how reviews work

0 comments
Cite this review

Pith. "Pith review of Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems." pith.science (2026). https://pith.science/paper/2604.19869

@misc{pith2026260419869,
  author       = {Pith},
  title        = {Pith review of: Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2604.19869}},
  note         = {Machine review of arXiv:2604.19869}
}
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.

Figures

Figures reproduced from arXiv: 2604.19869 by the authors.

Figure 2
Figure 2. QDMI as the standardized software-hardware boundary, facilitating [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
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 ↗
Figures from the paper (6 more)
Figure 6
Figure 6. Figure 6: Property query sequence for IQM QDMI device. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
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]
Figure 8
Figure 8. Figure 8: Qiskit-facing adapter skeleton over QDMI. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Illustrative Slurm submission pattern for QDMI-enabled execution. [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 11
Figure 11. Figure 11: Simplified QSCI control flow showing execution-mode toggling. [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 12
Figure 12. Figure 12: Schematic end-to-end workflow for QSCI execution. Numbers [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Examining QRMI as a Unified Interface for Quantum-HPC Integration

    cs.ET 2026-07 conditional novelty 6.0 of 10

    QRMI's acquire-execute-release interface can be adapted to PBS, LSF, Grid Engine, Kubernetes, and partly Flux, with three reusable integration patterns.

  2. SQUIRO: A Framework for Security-Aware Quantum-Classical Scheduling on Kubernetes

    cs.ET 2026-07 conditional novelty 5.0 of 10

    SQUIRO enforces security posture as hard scheduling constraints and ranks quantum backends by coherence margin and queue pressure, reporting up to 51% cost and 63% energy savings on synthetic underloaded Kubernetes clusters.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages · cited by 2 Pith papers

  1. [1]

    IEEE Computational Science and Engineering , issue_date =

    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. [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. [3]

    In: Job Scheduling Strategies for Parallel Processing

    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. [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. [5]

    Integration of Quantum Accelerators with High Performance Computing—A Review of Quantum Programming Tools,

    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. [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. [7]

    doi:10.1109/SCW63240.2024.00019 , abstract =

    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. [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

Show all 25 references
  1. [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

    2022 doi

  2. [10]

    First practical experiences inte- grating 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, 2...

    2025 doi

  3. [11]

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

    2025

  4. [12]

    Seelam et al.,Reference architecture of a quantum- centric supercomputer, 2026

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

    2026

  5. [13]

    Bacher et al.,Quantum resources in resource man- agement systems, 2025

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

    2025

  6. [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

    2026 doi

  7. [15]

    QDMI - quantum device management interface: Hardware-software interface for the munich quantum software stack,

    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

    2024 doi

  8. [16]

    The Munich Quantum Software Stack: Connecting end users, integrating diverse quan- tum 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

    2026 doi

  9. [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,

  10. [18]

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

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

    2024

  11. [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

  12. [20]

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

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

  13. [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

    2025 doi

  14. [22]

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

    2025

  15. [23]

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

    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

    2025

  16. [24]

    Quantum-Selected Configuration Interaction: Classical diagonalization of Hamiltonians in subspaces selected by quantum computers,

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

    2023

  17. [25]

    Chemistry beyond the scale of exact diagonalization on a quantum-centric supercom- puter,

    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

    2025 doi

Pith tools

Reviewed May 10, 2026 · model on record in the stance chip above.