pith. machine review for the scientific record. sign in

arxiv: 2604.20912 · v1 · submitted 2026-04-22 · 🪐 quant-ph · cs.DC· cs.ET· cs.SE

Recognition: unknown

Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey

Aleksander Wennersteen, Alex Chernoguzov, Amir Shehata, Andrea Delgado, Brian Austin, Christian Ortiz Pauyac, Ermal Rrapaj, Guen Prawiroatmodjo, Jeffery Heckey, Jiri Schindler, Josh Moles, Katherine Klymko, Kevin Kissell, Laura Schulz, Lee James O'Riordan, Lukas Burgholzer, Martin Schulz, Miwako Tsuji, Sebastian Stern, Spencer Churchill, Thomas Naughton, Tom Beck, Travis Humble, Tyler Takeshita, Yasuko Eckert

Authors on Pith no claims yet

Pith reviewed 2026-05-10 01:09 UTC · model grok-4.3

classification 🪐 quant-ph cs.DCcs.ETcs.SE
keywords quantum-HPCsoftware stacksreference architectureinteroperabilityNISQfault-tolerant quantum computingruntime abstractionresource management
0
0 comments X

The pith

A survey of nine quantum-HPC stacks identifies recurring patterns and proposes layer boundaries for interoperability and future-proofing.

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

The paper examines nine production stacks that integrate quantum resources into high-performance computing environments and catalogs their shared approaches to deployment, application interaction, SDK support, and resource handling. It extracts consistent requirements around runtime abstraction, resource management, interconnect semantics, and observability. From these patterns the authors define a set of layer boundaries that different implementations can adopt while keeping their internal designs flexible. The resulting structure is intended to work for both current noisy devices and later error-corrected systems without forcing changes to application code. If the boundaries hold, isolated proprietary stacks could begin to exchange components and workloads at defined interfaces.

Core claim

Analysis of nine production QHPC stacks reveals common design patterns and emerging requirements; these observations lead to the definition of the openQSE reference architecture, which specifies layer boundaries that permit different implementations to interoperate, preserve deployment flexibility, and support both NISQ workloads and future FTQC systems without changes to upper-layer application interfaces.

What carries the argument

The openQSE reference architecture, a set of layer boundaries that separate runtime abstraction, resource management, orchestration, and execution concerns to enable cross-implementation interoperability.

If this is right

  • Different vendor implementations can interoperate at the defined runtime, resource, and orchestration layers.
  • Upper-layer applications remain unchanged when stacks transition from noisy intermediate-scale to fault-tolerant quantum operation.
  • Observability and interconnect requirements can be met through standardized interfaces at the identified boundaries.
  • Deployment flexibility is retained because each layer can be realized by multiple concrete implementations.

Where Pith is reading between the lines

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

  • Clear layer boundaries could encourage development of modular components that plug into multiple environments rather than requiring full-stack reinvention.
  • The architecture might reduce vendor lock-in by letting users mix runtime or resource-management pieces from different sources.
  • Validation against additional stacks beyond the original nine would test whether the identified patterns truly generalize.
  • Standardized layers could ease integration of quantum resources into existing classical HPC schedulers and monitoring tools.

Load-bearing premise

The design patterns and requirements seen in the nine surveyed stacks are common enough and stable enough to define layer boundaries that will actually allow broad interoperability and will need no changes to applications when moving to fault-tolerant systems.

What would settle it

Two independent quantum-HPC stacks that each conform to the proposed layer boundaries and successfully exchange resources or execute a shared workload without modifying their upper-layer application code would support the claim; persistent inability to achieve such exchange after adaptation attempts would challenge it.

Figures

Figures reproduced from arXiv: 2604.20912 by Aleksander Wennersteen, Alex Chernoguzov, Amir Shehata, Andrea Delgado, Brian Austin, Christian Ortiz Pauyac, Ermal Rrapaj, Guen Prawiroatmodjo, Jeffery Heckey, Jiri Schindler, Josh Moles, Katherine Klymko, Kevin Kissell, Laura Schulz, Lee James O'Riordan, Lukas Burgholzer, Martin Schulz, Miwako Tsuji, Sebastian Stern, Spencer Churchill, Thomas Naughton, Tom Beck, Travis Humble, Tyler Takeshita, Yasuko Eckert.

Figure 1
Figure 1. Figure 1: Common hybrid job submission workflow across all surveyed stacks. A Job Submission [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Proposed openQSE reference architecture for QHPC integration, showing a layered, [PITH_FULL_IMAGE:figures/full_fig_p015_2.png] view at source ↗
read the original abstract

Quantum resources are increasingly integrated into high-performance computing (HPC) and cloud environments, but quantum high-performance computing (QHPC) software stacks remain isolated, often proprietary, full-stack solutions lacking common interfaces across runtime, resource management, orchestration, and execution layers. This paper analyzes nine production QHPC stacks and identifies common design patterns and emerging requirements, covering deployment models, application interaction patterns, SDK support, and readiness for fault-tolerant operation. The survey exposes consistent needs in runtime abstraction, resource management, interconnect semantics, and observability. Based on these findings, we propose the open quantum-HPC software ecosystem ( openQSE) reference architecture as a first step toward unifying the state-of-the-practice. openQSE defines a set of layer boundaries that allow different implementations to interoperate while preserving deployment flexibility, and is structured to support both current noisy intermediate-scale quantum (NISQ) workloads and future fault-tolerant quantum computing (FTQC) systems without changes to upper-layer application interfaces.

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.

Referee Report

2 major / 2 minor

Summary. The paper surveys nine production quantum-HPC (QHPC) software stacks, identifies recurring design patterns and requirements across deployment models, application interaction, SDK support, and fault-tolerance readiness, and proposes the openQSE reference architecture. openQSE defines layer boundaries (runtime abstraction, resource management, interconnect semantics, observability) intended to enable interoperability among implementations while preserving deployment flexibility and supporting both NISQ workloads and future FTQC systems without upper-layer application changes.

Significance. If the extracted patterns prove representative and the layer boundaries stable, the work would offer a practical starting point for unifying currently isolated QHPC stacks and easing the transition to fault-tolerant systems. The survey itself supplies a useful catalog of current practice; the architectural proposal, however, remains a hypothesis whose impact depends on subsequent validation.

major comments (2)
  1. [Proposal of openQSE (likely §4–5)] The central claim that the nine surveyed stacks suffice to define stable, interoperable layer boundaries rests on observed common needs but provides no explicit per-stack mapping to the proposed openQSE layers, no cross-vendor prototype exercising the interfaces, and no concrete analysis of how FTQC mechanisms (error correction, logical-qubit interfaces, syndrome extraction) would be hidden from upper layers. This gap directly undermines the assertion that the boundaries will require no upper-layer changes when moving from NISQ to FTQC.
  2. [Survey methodology and analysis sections] The representativeness assumption—that patterns from the nine stacks generalize to broad vendor interoperability—is load-bearing yet untested; the manuscript does not report selection criteria for the stacks, quantitative coverage metrics, or a falsifiable test (e.g., implementing a minimal cross-stack workflow) that would confirm the boundaries are both necessary and sufficient.
minor comments (2)
  1. Clarify whether the nine stacks are named and tabulated with their key characteristics; a summary table would strengthen the survey presentation.
  2. The abstract states that openQSE supports FTQC 'without changes to upper-layer application interfaces,' but the manuscript should explicitly list which interfaces are claimed to remain invariant and why.

Simulated Author's Rebuttal

2 responses · 2 unresolved

We thank the referee for the constructive feedback, which highlights important areas for strengthening the presentation of our survey and the openQSE proposal. We respond to each major comment below and specify the revisions planned for the next version of the manuscript.

read point-by-point responses

  1. Referee: The central claim that the nine surveyed stacks suffice to define stable, interoperable layer boundaries rests on observed common needs but provides no explicit per-stack mapping to the proposed openQSE layers, no cross-vendor prototype exercising the interfaces, and no concrete analysis of how FTQC mechanisms (error correction, logical-qubit interfaces, syndrome extraction) would be hidden from upper layers. This gap directly undermines the assertion that the boundaries will require no upper-layer changes when moving from NISQ to FTQC.

    Authors: We agree that an explicit per-stack mapping would improve clarity and verifiability. In the revised manuscript we will add a table in Section 4 that maps the components of each of the nine stacks onto the four openQSE layers. We will also expand the FTQC discussion in Section 5 to describe how the runtime-abstraction and interconnect-semantics layers encapsulate error-correction logic, logical-qubit interfaces, and syndrome extraction so that upper-layer applications remain unchanged; concrete examples drawn from the surveyed stacks will be included. A working cross-vendor prototype, however, lies outside the scope of the present survey paper; we will state this limitation explicitly and note it as planned future work. revision: partial

  2. Referee: The representativeness assumption—that patterns from the nine stacks generalize to broad vendor interoperability—is load-bearing yet untested; the manuscript does not report selection criteria for the stacks, quantitative coverage metrics, or a falsifiable test (e.g., implementing a minimal cross-stack workflow) that would confirm the boundaries are both necessary and sufficient.

    Authors: We accept that the selection criteria and coverage analysis should have been stated more explicitly. The revised manuscript will include a dedicated subsection under the survey methodology that lists the criteria used to select the nine stacks (production status, vendor diversity, and public availability at the time of writing) and provides a quantitative summary of how many stacks exhibit each identified pattern. A falsifiable cross-stack workflow test would require implementation effort beyond the scope of this survey; we will acknowledge this limitation and identify such validation as an important direction for subsequent research. revision: yes

standing simulated objections not resolved
  • Absence of a cross-vendor prototype exercising the proposed openQSE interfaces.
  • Empirical falsifiable test confirming that the layer boundaries are both necessary and sufficient.

Circularity Check

0 steps flagged

No circularity: openQSE layers derived from external survey patterns, not self-definition or fitted inputs

full rationale

The paper's chain consists of surveying nine independent production QHPC stacks, extracting recurring requirements (runtime abstraction, resource management, interconnect semantics, observability), and proposing openQSE layer boundaries as a unification step. No equations, fitted parameters, or self-citations are invoked to justify the boundaries; the architecture is presented as an organizational synthesis of observed external patterns rather than a reduction to author-defined quantities or prior self-work. The claim that the layers support NISQ-to-FTQC transition without upper-layer changes is an unproven assumption about future stability, but it does not create circularity because it is not derived by construction from the proposal itself.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The paper is a survey and proposal that rests on empirical observation of existing production systems rather than formal derivations, fitted parameters, or new physical axioms.

axioms (1)
  • domain assumption Quantum resources are increasingly integrated into HPC and cloud environments
    Opening premise of the abstract used to frame the need for unified software stacks.
invented entities (1)
  • openQSE reference architecture no independent evidence
    purpose: To define interoperable layer boundaries for QHPC software stacks supporting both NISQ and FTQC
    Newly proposed construct based on the survey findings; no independent falsifiable evidence or external validation is provided in the abstract.

pith-pipeline@v0.9.0 · 5587 in / 1399 out tokens · 54674 ms · 2026-05-10T01:09:46.008346+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

72 extracted references · 41 canonical work pages · 1 internal anchor

  1. [1]

    Scaling and networking a modular photonic quantum computer,

    J. E. Bourassa, R. S. Chadwick, and et al., “Scaling and networking a modular photonic quantum computer,”Nature, vol. 638, pp. 912–919, Jan 2025. [Online]. Available: https://doi.org/10.1038/s41586-024-08406-9

    work page doi:10.1038/s41586-024-08406-9 2025

  2. [2]

    Catalyst: a Python JIT compiler for auto-differentiable hybrid quantum programs,

    D. Ittah, A. Asadi, E. O. Lopez, S. Mironov, S. Banning, R. Moyard, M. J. Peng, and J. Izaac, “Catalyst: a python jit compiler for auto-differentiable hybrid quantum programs,”Journal of Open Source Software, vol. 9, no. 99, p. 6720, 2024. [Online]. Available: https://doi.org/10.21105/joss.06720

    work page doi:10.21105/joss.06720 2024

  3. [3]

    jeff: bridging quantum compilers,

    D. Ittah, “jeff: bridging quantum compilers,” Talk abstract, Quantum Software 2.1 Workshop. [Online]. Available: https://sites.google.com/view/quantum-software-workshop-2025, 2025, accessed: Mar. 6, 2026

    2025

  4. [4]

    Guppy: pythonic quantum-classical programming.arXiv preprint arXiv:2510.12582, 2025

    M. Koch, A. Lawrence, K. Singhal, S. Sivarajah, and R. Duncan, “Guppy: Pythonic quantum-classical programming,” inInformal Proceedings of the Fourth International Workshop on Programming Languages for Quantum Computing (PLanQC ’24), 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2510.12582

    work page doi:10.48550/arxiv.2510.12582 2024

  5. [5]

    Imperative quantum programming with ownership and borrowing in guppy,

    M. Koch, A. Borgna, C. Roy, A. Lawrence, K. Singhal, S. Sivarajah, and R. Duncan, “Imperative quantum programming with ownership and borrowing in guppy,” inInformal Proceedings of the Fifth International Workshop on Programming Languages for Quantum Computing (PLanQC ’25), 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2510.13082

    work page doi:10.48550/arxiv.2510.13082 2025

  6. [6]

    Nature606(7912), 75–81 (2022) https://doi.org/ 10.1038/s41586-022-04725-x

    L. S. Madsen, F. Laudenbach, M. F. Askarani, F. Rortais, T. Vincent, J. F. F. Bulmer, F. M. Miatto, L. Neuhaus, L. G. Helt, M. J. Collins, A. E. Lita, T. Gerrits, S. W. Nam, V. D. Vaidya, M. Menotti, I. Dhand, Z. Vernon, N. Quesada, and J. Lavoie, “Quantum computational advantage with a programmable photonic processor,”Nature, vol. 606, no. 7912, pp. 75–8...

    work page doi:10.1038/s41586-022-04725-x 2022

  7. [7]

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

    E. Mansfield, S. Seegerer, P. Vesanen, J. Echavarria, M. N. Farooqi, B. Mete, and L. Schulz, “First practical experiences integrating quantum computers with hpc resources: A case study with a 20-qubit superconducting quantum computer,” inProceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage...

    work page doi:10.1145/3731599.3767551 2025

  8. [8]

    [Online]

    QIR Specification, QIR Alliance: https://qir-alliance.org. [Online]. Available: https: //github.com/qir-alliance/qir-spec 18

  9. [9]

    Svore, A

    K. Svore, A. Geller, M. Troyer, J. Azariah, C. Granade, B. Heim, V. Kliuchnikov, M. Mykhailova, A. Paz, and M. Roetteler, “Q#: Enabling Scalable Quantum Computing and Development with a High-level DSL,” inProceedings of the Real World Domain Specific Languages Workshop 2018, ser. RWDSL2018. ACM, Feb. 2018. [Online]. Available: http://dx.doi.org/10.1145/31...

    work page doi:10.1145/3183895.3183901 2018

  10. [10]

    Real-time feedback and active reset with OPX and QOP,

    Quantum Machines Documentation, “Real-time feedback and active reset with OPX and QOP,” [Online]. Available: https://docs.quantum-machines.co/1.2.3/docs/Introduction/use_case/acti ve_reset/, 2026, accessed: Mar. 6, 2026

    2026

  11. [11]

    Amazon EC2,

    Amazon Web Services, “Amazon EC2,” [Online]. Available: https://aws.amazon.com/ec2/, 2026, accessed: Mar. 30, 2026

    2026

  12. [12]

    Quantum circuits with many photons on a programmable nanophotonic chip,

    J. M. Arrazola, V. Bergholm, K. Brádler, T. R. Bromley, M. J. Collins, I. Dhand, A. Fumagalli, T. Gerrits, A. Goussev, L. G. Heltet al., “Quantum circuits with many photons on a programmable nanophotonic chip,”Nature, vol. 591, no. 7848, pp. 54–60, 2021. [Online]. Available: https://doi.org/10.1038/s41586-021-03202-1

    work page doi:10.1038/s41586-021-03202-1 2021

  13. [13]

    AWS Batch,

    Amazon Web Services, “AWS Batch,” [Online]. Available: https://aws.amazon.com/batch/, 2026, accessed: Mar. 30, 2026

    2026

  14. [14]

    AWS ParallelCluster,

    ——, “AWS ParallelCluster,” [Online]. Available: https://aws.amazon.com/hpc/parallelcluster /, 2026, accessed: Mar. 30, 2026

    2026

  15. [15]

    AWS Parallel Computing Service,

    ——, “AWS Parallel Computing Service,” [Online]. Available: https://aws.amazon.com/pcs/, 2026, accessed: Mar. 30, 2026

    2026

  16. [16]

    AWS Step Functions - workflow orchestration,

    ——, “AWS Step Functions - workflow orchestration,” [Online]. Available: https://aws.amazon .com/step-functions/, 2026, accessed: Mar. 30, 2026

    2026

  17. [17]

    Working with Amazon Braket hybrid jobs,

    Amazon Braket Developer Guide, “Working with Amazon Braket hybrid jobs,” [Online]. Available: https://docs.aws.amazon.com/braket/latest/developerguide/braket-build-jobs.html, 2025, accessed: Mar. 3, 2026

    2025

  18. [18]

    Running hybrid jobs during a reservation,

    ——, “Running hybrid jobs during a reservation,” [Online]. Available: https://docs.aws.ama zon.com/braket/latest/developerguide/braket-run-hybrid-jobs-with-reservation.html, 2025, accessed: Mar. 3, 2026

    2025

  19. [19]

    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, vol. 10, no. 108, p. 7478, 2025. [Online]. Available: https://doi.org/10.21105/joss.07478

    work page doi:10.21105/joss.07478 2025

  20. [20]

    Camps, E

    D. Camps, E. Rrapaj, K. Klymko, H. Kim, K. Gott, S. Darbha, J. Balewski, B. Austin, and N. J. Wright, “Quantum computing technology roadmaps and capability assessment for scientific computing–an analysis of use cases from the nersc workload,”arXiv preprint arXiv:2509.09882, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2509.09882

    work page doi:10.48550/arxiv.2509.09882 2025

  21. [21]

    Catalyst quantum compilation dialects,

    Xanadu, “Catalyst quantum compilation dialects,” GitHub repository. [Online]. Available: https://github.com/PennyLaneAI/catalyst/tree/main/mlir/lib, 2026, accessed: Mar. 23, 2026

    2026

  22. [22]

    Cirq: A Python Framework for Creating, Editing, and Invoking Noisy Intermediate Scale Quantum (NISQ) Circuits,

    Google Quantum AI, “Cirq: A Python Framework for Creating, Editing, and Invoking Noisy Intermediate Scale Quantum (NISQ) Circuits,” https://quantumai.google/cirq, 2024, accessed: 2026-04-03. 19

    2024

  23. [23]

    Shirakawa, J

    T. Shirakawa, J. Robledo-Moreno, T. Itoko, V. Tripathi, K. Ueda, Y. Kawashima, L. Broers, W. Kirby, H. Pathak, H. Paik, M. Tsuji, Y. Kodama, M. Sato, C. Evangelinos, S. Seelam, R. Walkup, S. Yunoki, M. Motta, P. Jurcevic, H. Horii, and A. Mezzacapo, “Closed-loop calculations of electronic structure on a quantum processor and a classical supercomputer at f...

    work page doi:10.48550/arxiv.2511.00224 2025

  24. [24]

    Conditional operations (QTM/QCM-RF II),

    Qblox Documentation, “Conditional operations (QTM/QCM-RF II),” [Online]. Available: https://docs.qblox.com/en/main/cluster/q1_sequence_processor.html, 2026, accessed: Mar. 6, 2026

    2026

  25. [25]

    Cross, A

    A. Cross, A. Javadi-Abhari, T. Alexander, N. De Beaudrap, L. S. Bishop, S. Heidel, C. A. Ryan, P. Sivarajah, J. Smolin, J. M. Gambettaet al., “Openqasm 3: A broader and deeper quantum assembly language,”ACM Transactions on Quantum Computing, vol. 3, no. 3, pp. 1–50, 2022. [Online]. Available: https://doi.org/10.1145/3505636

    work page doi:10.1145/3505636 2022

  26. [26]

    CUDA-Q: A platform for hybrid quantum-classical computing,

    NVIDIA Corporation, “CUDA-Q: A platform for hybrid quantum-classical computing,” [Online]. Available: https://developer.nvidia.com/cuda-q, 2026, accessed: Mar. 23, 2026

    2026

  27. [27]

    A survey on integrating quantum computers into high performance computing systems,

    P. Döbler and M. S. Jattana, “A survey on integrating quantum computers into high performance computing systems,” 2025. [Online]. Available: https://arxiv.org/abs/2507.03540

    work page arXiv 2025

  28. [28]

    Hardware considerations and limitations for dynamic circuits,

    IBM Quantum Documentation, “Hardware considerations and limitations for dynamic circuits,” [Online]. Available: https://docs.quantum.ibm.com/guides/dynamic-circuits-considerations, 2025, accessed: Mar. 6, 2026

    2025

  29. [29]

    Elsharkawy, X.-T

    A. Elsharkawy, X.-T. M. To, P. Seitz, Y. Chen, Y. Stade, M. Geiger, Q. Huang, X. Guo, M. A. Ansari, C. B. Mendl, D. Kranzlmüller, and M. Schulz, “Integration of quantum accelerators with high performance computing—a review of quantum programming tools,” ACM Transactions on Quantum Computing, vol. 6, no. 3, Jul. 2025. [Online]. Available: https://doi.org/1...

    work page doi:10.1145/3743149 2025

  30. [30]

    The spack package manager: bringing order to hpc software chaos,

    T. Gamblin, M. LeGendre, M. R. Collette, G. L. Lee, A. Moody, B. R. de Supinski, and S. Futral, “The spack package manager: bringing order to hpc software chaos,” inSC ’15: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2015, pp. 1–12. [Online]. Available: https://doi.org/10.1145/2807591.2807623

    work page doi:10.1145/2807591.2807623 2015

  31. [31]

    grpc: A high performance, open source universal rpc framework,

    gRPC Authors, “grpc: A high performance, open source universal rpc framework,” https: //grpc.io/, 2024, accessed: 2024-05-28

    2024

  32. [32]

    Quantum computing with neutral atoms,

    L. Henriet, L. Beguin, A. Signoles, T. Lahaye, A. Browaeys, G.-O. Reymond, and C. Jurczak, “Quantum computing with neutral atoms,”Quantum, vol. 4, p. 327, Sep. 2020. [Online]. Available: https://doi.org/10.22331/q-2020-09-21-327

    work page doi:10.22331/q-2020-09-21-327 2020

  33. [33]

    What is HIP?

    AMD ROCm Documentation, “What is HIP?” HIP 7.2 documentation. [Online]. Available: https://rocm.docs.amd.com/projects/HIP/en/develop/what_is_hip.html, 2025, accessed: Mar. 3, 2026

    2025

  34. [34]

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

    S. Seelam, J. M. Chow, A. D. Corcoles, S. Sheldon, T. Mittal, A. Kandala, S. Dague, I. Hincks, H. Horii, B. Johnson, M. Le, H. Jamjoom, and J. M. Gambetta, “Reference architecture of a quantum-centric supercomputer,” 2026, arXiv:2603.10970. [Online]. Available: https://doi.org/10.48550/arXiv.2603.10970 20

    work page doi:10.48550/arxiv.2603.10970 2026

  35. [35]

    Observability architecture for quantum-centric supercomputing workflows,

    N. Kanazawa, Y. Morohoshi, H. Takahashi, Y. Kawashima, H. Horii, and K. Naka- jima, “Observability architecture for quantum-centric supercomputing workflows,” 2025, arXiv:2512.05484. [Online]. Available: https://doi.org/10.48550/arXiv.2512.05484

    work page doi:10.48550/arxiv.2512.05484 2025

  36. [36]

    doi:10.22331/q-2024-11-07-1516 , url =

    J.-S. Chenet al., “Benchmarking a trapped-ion quantum computer with 30 qubits,”Quantum, vol. 8, p. 1516, 2024. [Online]. Available: https://doi.org/10.22331/q-2024-11-07-1516

    work page doi:10.22331/q-2024-11-07-1516 2024

  37. [37]

    IonQ quantum cloud,

    IonQ, Inc., “IonQ quantum cloud,” [Online]. Available: https://www.ionq.com/quantum-cloud, 2026, accessed: Mar. 23, 2026

    2026

  38. [38]

    Euro-q-exa: Integrating quantum computers into hpc systems,

    T. Häner, D. S. Steiger, J. Heinsooet al., “Euro-q-exa: Integrating quantum computers into hpc systems,”arXiv preprint arXiv:2509.12949, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2509.12949

    work page doi:10.48550/arxiv.2509.12949 2025

  39. [39]

    JAX: composable transformations of Python+NumPy programs,

    J. Bradbury, R. Frostig, P. Hawkins, M. J. Johnson, C. Leary, D. Maclaurin, G. Necula, A. Paszke, J. VanderPlas, S. Wanderman-Milne, and Q. Zhang, “JAX: composable transformations of Python+NumPy programs,” 2018. [Online]. Available: http://github.com/jax-ml/jax

    2018

  40. [40]

    Annual report 2025 (JEFF section, collaboration with Xanadu and Quantinuum),

    Unitary Foundation, “Annual report 2025 (JEFF section, collaboration with Xanadu and Quantinuum),” [Online]. Available: https://willzeng.com/shared/UF_Annual_Report_2025. pdf, Jan. 2026, accessed: Mar. 6, 2026

    2025

  41. [41]

    LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation

    C. Lattner and V. Adve, “Llvm: A compilation framework for lifelong program analysis & transformation,” inProceedings of the International Symposium on Code Generation and Optimization (CGO). IEEE, 2004, pp. 75–86. [Online]. Available: https://doi.org/10.1109/CGO.2004.1281665

    work page doi:10.1109/cgo.2004.1281665 2004

  42. [42]

    MLIR: A compiler in- frastructure for the end of Moore’s Law,

    C. Lattneret al., “MLIR: A compiler infrastructure for the end of Moore’s Law,” arXiv:2002.11054, 2020. [Online]. Available: https://doi.org/10.48550/arXiv.2002.11054

    work page doi:10.48550/arxiv.2002.11054 2002

  43. [43]

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

    L. Burgholzer, J. Echavarria, P. Hopf, Y. Stade, D. Rovara, L. Schmid, E. Kaya, B. Mete, M. N. Farooqi, M. Chung, M. De Pascale, L. Schulz, M. Schulz, and R. Wille, “The Munich Quantum Software Stack: Connecting End Users, Integrating Diverse Quantum Technologies, Accelerating HPC,” inSC/HPC Asia 2026. ACM, 2026, pp. 55–67. [Online]. Available: https://do...

    work page doi:10.1145/3773656.3773669 2026

  44. [44]

    The MQT handbook: A summary of design automation tools and software for quantum computing,

    R. Wille, L. Berent, T. Forster, J. Kunasaikaran, K. Mato, T. Peham, N. Quetschlich, D. Rovara, A. Sander, L. Schmid, D. Schoenberger, Y. Stade, and L. Burgholzer, “The MQT handbook: A summary of design automation tools and software for quantum computing,” inInt’l Conf. on Quantum Software, 2024. [Online]. Available: https://doi.org/10.1109/QSW62656.2024.00013

    work page doi:10.1109/qsw62656.2024.00013 2024

  45. [45]

    NVIDIA CUDA Parallel Computing Platform,

    NVIDIA Corporation, “NVIDIA CUDA Parallel Computing Platform,” https://developer.nvid ia.com/cuda-zone, 2024, accessed: 2026-04-03

    2024

  46. [46]

    Platform architecture for tight coupling of high-performance computing with quantum processors,

    S. A. Caldwellet al., “Platform architecture for tight coupling of high-performance computing with quantum processors,” arXiv:2510.25213, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2510.25213

    work page doi:10.48550/arxiv.2510.25213 2025

  47. [47]

    Quantum task offloading with the openmp api,

    J. K. Lee, O. T. Brown, M. Bull, M. Ruefenacht, J. Doerfert, M. Klemm, and M. Schulz, “Quantum task offloading with the openmp api,” inPosters at SC23, 2023. [Online]. Available: https://sc23.supercomputing.org/proceedings/tech_poster/poster_files/rpost177s3-file3.pdf 21

    2023

  48. [48]

    openQSE workshops (architecture presentations and stack evaluations),

    openQSE Initiative, “openQSE workshops (architecture presentations and stack evaluations),” GitHub repository. [Online]. Available: https://github.com/openQSE/Workshops, 2026, accessed: Mar. 3, 2026

    2026

  49. [49]

    openqse working group: Quantum computing software ecosystem workshop notes,

    openQSE Working Group, “openqse working group: Quantum computing software ecosystem workshop notes,” https://github.com/openQSE/Workshops/blob/main/OpenQSE-WG/open QSE-IonQ-20260309.pdf, 2026, accessed: 2026-04-04

    2026

  50. [50]

    openqse working group: Quantum computing software ecosystem workshop notes,

    ——, “openqse working group: Quantum computing software ecosystem workshop notes,” https://github.com/openQSE/Workshops/blob/main/OpenQSE-WG/openQSE-RIKAN-202 60113.pdf, 2026, accessed: 2026-04-04

    2026

  51. [51]

    openqse working group: Quantum computing software ecosystem workshop notes,

    ——, “openqse working group: Quantum computing software ecosystem workshop notes,” https://github.com/openQSE/Workshops/blob/main/OpenQSE-WG/openQSE-MQSC-202 60105.pdf, 2026, accessed: 2026-04-04

    2026

  52. [52]

    openqse working group: Quantum computing software ecosystem workshop notes,

    ——, “openqse working group: Quantum computing software ecosystem workshop notes,” https://github.com/openQSE/Workshops/blob/main/OpenQSE-WG/openQSE-Pasqal-202 60119.pdf, 2026, accessed: 2026-04-04

    2026

  53. [53]

    openqse working group: Quantum computing software ecosystem workshop notes,

    ——, “openqse working group: Quantum computing software ecosystem workshop notes,” https: //github.com/openQSE/Workshops/blob/main/OpenQSE-WG/openqSE-QB-20260219.pdf, 2026, accessed: 2026-04-04

    2026

  54. [54]

    openqse working group: Quantum computing software ecosystem workshop notes,

    ——, “openqse working group: Quantum computing software ecosystem workshop notes,” https://github.com/openQSE/Workshops/blob/main/OpenQSE-WG/openQSE-Xanadu-202 60303.pdf, 2026, accessed: 2026-04-04

    2026

  55. [55]

    Tejedor, B

    A. Wennersteen, M. Moreau, A. Nober, and M. Beji, “Towards a user-centric HPC-QC environment,” inProc. SC ’25 Workshops, 2025. [Online]. Available: https://doi.org/10.1145/3731599.3767549

    work page doi:10.1145/3731599.3767549 2025

  56. [56]

    Hybrid quantum classical algorithms: A cloud on-demand viewpoint,

    A. Wennersteen, K. Bidzhiev, M. D’Arcangelo, M. Moreau, A. Quelle, A. Dauphin, and M. Beji, “Hybrid quantum classical algorithms: A cloud on-demand viewpoint,” in Quantum Engineering Sciences and Technologies for Industry and Services, F. Barbaresco and F. Gerin, Eds. Cham: Springer Nature Switzerland, 2026, pp. 117–125. [Online]. Available: https://doi.o...

    work page doi:10.1007/978-3-032-13855-2_11 2026

  57. [57]

    PennyLane: Automatic differentiation of hybrid quantum-classical computations

    V. Bergholmet al., “Pennylane: Automatic differentiation of hybrid quantum-classical computations,” 2022. [Online]. Available: https://doi.org/10.48550/arXiv.1811.04968

    work page internal anchor Pith review doi:10.48550/arxiv.1811.04968 2022

  58. [58]

    Pulser: An open-source package for the design of pulse sequences in programmable neutral-atom arrays,

    H. Silvério, S. Grijalva, C. Dalyac, L. Leclerc, P. J. Karalekas, N. Shammah, M. Beji, L.-P. Henry, and L. Henriet, “Pulser: An open-source package for the design of pulse sequences in programmable neutral-atom arrays,”Quantum, vol. 6, p. 629, Jan. 2022. [Online]. Available: https://doi.org/10.22331/q-2022-01-24-629

    work page doi:10.22331/q-2022-01-24-629 2022

  59. [59]

    https://doi.org/10.5281/zenodo.2573505

    Qiskit contributors, “Qiskit: An open-source framework for quantum computing,” [Online]. Available: https://github.com/Qiskit/qiskit, 2024. [Online]. Available: https://doi.org/10.5281/zenodo.2573505

    work page doi:10.5281/zenodo.2573505 2024

  60. [60]

    Seitz, M

    E. Kaya, B. Mete, L. Schulz, M. N. Farooqi, J. Echavarria, and M. Schulz, “Qpi: A programming interface for quantum computers,” in2024 IEEE International Conference on 22 Quantum Computing and Engineering (QCE), vol. 02, 2024, pp. 286–291. [Online]. Available: https://doi.org/10.1109/QCE60285.2024.10293

    work page doi:10.1109/qce60285.2024.10293 2024

  61. [61]

    Quantum resources in resource management systems,

    U. Bacheret al., “Quantum resources in resource management systems,” arXiv:2506.10052,

    work page arXiv

  62. [62]

    Quantum resources in resource management systems,

    [Online]. Available: https://doi.org/10.48550/arXiv.2506.10052

    work page doi:10.48550/arxiv.2506.10052

  63. [63]

    Quantinuum nexus,

    Quantinuum, “Quantinuum nexus,” 2024. [Online]. Available: https://nexus.quantinuum.com/

    2024

  64. [64]

    Mqt bench: Benchmarking software and design automation tools for quantum computing,

    N. Quetschlich, L. Burgholzer, and R. Wille, “MQT Bench: Benchmarking Software and Design Automation Tools for Quantum Computing,”Quantum, vol. 7, p. 1062, 2023, MQT Bench is available at https://mqt-bench.app/. [Online]. Available: https://doi.org/10.22331/q-2023-07-20-1062

    work page doi:10.22331/q-2023-07-20-1062 2023

  65. [65]

    MQT Predictor: Automatic Device Selection with Device-Specific Circuit Compilation for Quantum Computing,

    ——, “MQT Predictor: Automatic Device Selection with Device-Specific Circuit Compilation for Quantum Computing,”ACM Transactions on Quantum Computing (TQC), 2025. [Online]. Available: https://doi.org/10.1145/3673241

    work page doi:10.1145/3673241 2025

  66. [66]

    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, D. Feitelson, L. Rudolph, and U. Schwiegelshohn, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2003, pp. 44–60. [Online]. Available: https://doi.org/10.1007/10968987_3

    work page doi:10.1007/10968987_3 2003

  67. [67]

    scontrol (reservation and TRES semantics),

    Slurm Workload Manager Documentation, “scontrol (reservation and TRES semantics),” [On- line]. Available: https://slurm.schedmd.com/scontrol.html, 2025, accessed: Mar. 3, 2026

    2025

  68. [68]

    Wide quantum circuit optimization with topology aware synthesis

    S. Sivarajah, L. Heidemann, A. Lawrence, and R. Duncan, “Tierkreis: a dataflow framework for hybrid quantum-classical computing,” in2022 IEEE/ACM Third International Workshop on Quantum Computing Software (QCS), 2022, pp. 12–21. [Online]. Available: https://doi.org/10.1109/QCS56647.2022.00007

    work page doi:10.1109/qcs56647.2022.00007 2022

  69. [69]

    MQT QMAP: Efficient quantum circuit mapping,

    R. Wille and L. Burgholzer, “MQT QMAP: Efficient quantum circuit mapping,” inInternational Symp. on Physical Design, 2023. [Online]. Available: https://doi.org/10.1145/3569052.3578928

    work page doi:10.1145/3569052.3578928 2023

  70. [70]

    Seitz, M

    R. Wille, L. Schmid, Y. Stade, J. Echavarria, M. Schulz, L. Schulz, and L. Burgholzer, “QDMI – quantum device management interface: Hardware-software interface for the Munich Quantum Software Stack,” inProc. IEEE Int’l Conf. on Quantum Computing and Engineering (QCE), 2024, pp. 573–574. [Online]. Available: https://doi.org/10.1109/QCE60285.2024.10411

    work page doi:10.1109/qce60285.2024.10411 2024

  71. [71]

    Quantum-hpc hybrid computation of biomolecular excited-state energies,

    K. Yamamoto, R. Masui, T. Nakajima, M. Tsuji, M. Sato, P. Schow, L. Heidemann, M. Burke, P. Seitz, O. J. Backhouse, J. W. Pedersen, J. Children, C. Holliman, N. Lysne, D. Okuno, S. Sivarajah, D. M. Ramo, A. Chernoguzov, and R. Duncan, “Quantum-hpc hybrid computation of biomolecular excited-state energies,” 2026. [Online]. Available: https://doi.org/10.485...

    work page doi:10.48550/arxiv.2601.15677 2026

  72. [72]

    Quantum-classical auxiliary field quantum monte carlo with matchgate shadows on trapped ion quantum computers,

    L. Zhaoet al., “Quantum-classical auxiliary field quantum monte carlo with matchgate shadows on trapped ion quantum computers,” arXiv:2506.22408, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2506.22408 23

    work page doi:10.48550/arxiv.2506.22408 2025