Pith. sign in

REVIEW 4 major objections 5 minor 60 references

Examining QRMI as a Unified Interface for Quantum-HPC Integration

T0 review · 4 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read QRMI, a thin vendor-neutral middleware layer, allows HPC schedulers to treat quantum processors as first-class resources across Slurm, PBS, LSF, Grid Engine, and Kubernetes.

desk verdict Useful engineering report extending QRMI beyond Slurm, but the abstract overclaims portability: integrations are bespoke, Flux is incomplete, and the authors admit it in the body. read the letter →

arxiv 2607.19591 v1 pith:Z7345ZYU submitted 2026-07-21 cs.ET cs.DC

Thomas Badts (8) , Tim Boyle (6) , Claudio Carvalho (4) , Antonio Córcoles (4) , Andrew Damin (10) , Vadim Elisseev (4) , Jonathan Frassineti (2) , Daniel Gruber (3)
show 31 more authors
Hiroshi Horii (4) Eun-Kyung Lee (4) James Machin (1) Sara Marzella (2) Mateusz Meller (12) Daniel Milroy (5) Matthieu Moreau (8) Munetaka Ohtani (4) Elisabeth Ortega-Carrasco (9) Doug Oucharek (7) Yoonho Park (4) Adarsh Patil (11) Emre M. Sahin (12) Gábor Samu (4) Seetharami Seelam (4) Amir Shehata (7) Vanessa Sochat (5) James Thorne (6) Oscar Wallis (12) Aleksander Wennersteen (8) ((1) Alice & Bob (2) CINECA (3) HPC Gridware (4) IBM (5) Lawrence Livermore National Laboratory (6) National Quantum Computing Centre (7) Oak Ridge National Laboratory (8) Pasqal (9) Qilimanjaro Quantum Tech (10) Rensselaer Polytechnic Institute (11) Siemens (12) STFC Hartree Centre)
This is my paper
classification cs.ETcs.DC
keywords quantum-HPCintegrationQRMIworkloadmanagersschedulingacquire-execute-releasedynamicresourceavailabilityKuberneteshybridquantum-classicalworkflows
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 argues that a single thin middleware layer—the Quantum Resource Management Interface (QRMI)—can bring quantum processors into mainstream HPC scheduling without rewriting the schedulers. It extends an earlier Slurm-only proof of concept to PBS, LSF, Grid Engine, Kubernetes, and partially to Flux, and shows that the same three design patterns hold across all of them: quantum resources are exposed as schedulable resources, lifecycle events map to QRMI's acquire-execute-release operations, and provider-specific complexity is confined to configuration files and middleware. The payoff would be that HPC centers can offer hybrid quantum-classical jobs through familiar commands like sbatch, qsub, and bsub, on-premises or in the cloud, with users and applications insulated from vendor-specific APIs. The paper is candid that portability is not absolute—workload-manager design differences force per-scheduler integration work, and the Flux integration is not yet complete.

What carries the argument

QRMI itself is the central object: a thin, vendor-agnostic middleware layer with standardized APIs for resource discovery, acquisition and release, job management, and observability, plus language bindings in Rust, C, and Python. The load-bearing mechanism is the acquire-execute-release pattern: at job start QRMI acquires the quantum resource and stores an acquisition token; during execution connection information is injected as environment variables; at job completion the token is used to release the resource. The pattern is deliberately mapped onto each scheduler's extension hooks rather than into scheduler core, and qrmi_config.json carries the logical-to-physical mapping that keeps provi

What would settle it

A concrete test: choose a workload manager whose extension interface cannot pass acquisition tokens between the acquire and release phases (or has no hook mechanism at all), and show that QRMI cannot be integrated without modifying the scheduler's core. Alternatively, measure HPC idle time under the PBS runjob-hook design against the Slurm GRES design on the same workload; if the hook-before-allocation approach produces no idle-time reduction, the paper's claim that lifecycle placement avoids wasted classical resources is unsupported.

Watch

Extended reading notes

Core claim

QRMI's central discovery is that the acquire-execute-release lifecycle—acquire a quantum resource at job start, expose connection metadata via environment variables during execution, and release at completion—can be implemented through each workload manager's native extension points: Slurm SPANK plugins, PBS runjob and execjob_end hooks, LSF jobstarter and postexec hooks, Grid Engine prolog and epilog hooks, and a Kubernetes operator built on CustomResourceDefinitions. In every case quantum resources are registered as custom schedulable resources, and a single administrator-managed qrmi_config.json maps logical resource names to physical endpoints and credentials. The paper finds full suppor

Load-bearing premise

The portability claim rests on the assumption that each workload manager's existing extension mechanisms—SPANK plugins, PBS hooks, LSF jobstarter and postexec hooks, Grid Engine prolog and epilog hooks, and Kubernetes CRD/operator—can implement QRMI's acquire-execute-release lifecycle without invasive changes to the scheduler; the paper itself concedes the approach is not fully portable and leaves the Flux integration incomplete.

Editorial extensions

If this is right

  • HPC centers can offer hybrid quantum-classical jobs without changing user-facing submission interfaces: sbatch, qsub, bsub, and kubectl all gain access to quantum resources.
  • A single QRMI deployment can span on-premises and cloud quantum providers, so sites can begin integration before hardware arrives and swap providers without rewriting scheduler code.
  • Workload managers need stronger primitives for dynamic resource availability; QRMI's proposed is_runnable() would let schedulers estimate when a quantum job will actually run.
  • Workflow managers can use QRMI as a consistent interface for orchestrating hybrid quantum-classical workloads.
  • Until workload managers add native quantum support, QRMI-based integrations remain external middleware, which excludes them from data centers that only allow product software.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: if QRMI's portability claim holds in production, the same acquire-execute-release pattern could serve as a template for integrating other bursty, externally queued accelerators (for example, analog or neuromorphic hardware), not just quantum processors.
  • Editorial inference: the paper's qualitative comparison suggests the real bottleneck is scheduler-side dynamic availability, not the middleware; a testable extension is to implement QRMI against a scheduler with no event hooks to find where the portability boundary actually lies.
  • Editorial inference: the two-queue gating approach used in the Kubernetes-based prototype could be adapted by traditional schedulers as a lighter-weight co-scheduling strategy than reserving HPC resources while waiting on a quantum queue.
  • Editorial inference: 'minimal scheduler-specific modifications' should be read as pattern-level repeatability, not zero per-scheduler work; the paper's own comparison table shows differences in language, deployment, token passing, and code-update paths across schedulers.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents QRMI as a vendor-agnostic middleware layer for exposing quantum resources to HPC workload managers. It describes QRMI's design patterns—representing quantum resources as schedulable resources, mapping lifecycle events to acquire-execute-release operations, and encapsulating complexity in configuration/middleware—and then reports integrations for Slurm, PBS, LSF, Grid Engine, Kubernetes, and Flux, with code listings and a comparison table. It also cites production deployments at CINECA, BasQ, RPI, and UK HPC sites, and positions QRMI relative to QDMI and openQSE. The abstract claims that the paper 'demonstrate[s] that QRMI provides a portable and flexible abstraction layer that minimizes scheduler-specific modifications'; Section VI later states that the analysis is qualitative and that many integrations are proof-of-concept.

Significance. If the portability claim were established, the paper would provide a practical foundation and a useful taxonomy for quantum-HPC scheduling standardization. The paper's genuine strengths are the concrete integration descriptions, the candid comparison of scheduler extension mechanisms in Table III, the discussion of dynamic-availability limitations, and the early deployment experience. It also ships references to code repositories and gives reproducible configuration listings. However, the headline claim is not yet established: the evidence shows that the QRMI client API can be adapted to multiple schedulers, not that a single thin integration layer is portable with minimal scheduler-specific modifications.

major comments (4)
  1. [Abstract, Sec. III, Sec. IV, Sec. VI] The central claim that QRMI 'provides a portable and flexible abstraction layer that minimizes scheduler-specific modifications' is contradicted by the paper's own evidence. Sec. III concedes 'this approach is not fully portable between workload managers due to differences in workload manager design'; Sec. VI states 'Many of the integrations presented in this paper remain at the proof-of-concept stage' and 'The analysis presented in this paper is qualitative.' Each integration uses a different bespoke mechanism: Slurm SPANK callbacks share a process, PBS hooks serialize tokens in job.Variable_List, LSF persists tokens to a temporary file, Grid Engine uses complexes plus prolog/epilog, and Kubernetes uses a CRD/operator that 'does not strictly follow' the acquire-execute-release pattern. The paper therefore demonstrates portability of the QRMI client API, not of the scheduler integration
  2. [Sec. IV-F] The Flux Framework section does not describe a completed QRMI integration. It describes a Kubernetes custom scheduler plugin (Fluence) that models quantum resources in a resource graph, and it gives a roadmap for future integration with Flux Core. The text explicitly says that support for the design patterns 'will only be declared when the integration is complete.' Since the abstract includes Flux among the workload managers examined as part of the extended validation, presenting an incomplete integration in the central evidence base is a load-bearing gap. This section should be clearly framed as future work and should not be counted as evidence for the portability claim.
  3. [Sec. V-C, Table II] The portability claim is not supported by deployment evidence. All named production deployments—CINECA, BasQ, and RPI—use Slurm; the Hartree/NQCC work is described as evaluation on development nodes and a preliminary API integration. No cross-scheduler test runs the same QRMI implementation against multiple schedulers, and no metric is provided for 'minimizes scheduler-specific modifications.' Table II itself assigns only partial support to all four traditional schedulers for the first design pattern and 'no' native quantum support to all. At minimum, the paper should either weaken the claim to 'the QRMI API can be adapted to multiple schedulers' or add a controlled comparison (e.g., per-scheduler extension code size, number of required modifications, or a common test workload).
  4. [Sec. IV-E] The Kubernetes integration is an important exception to the paper's proposed unifying pattern. The section states that the description 'does not strictly follow' the three design patterns, and the claim model has its own acquire/release semantics, including the acknowledged problem of QRCs outliving workloads and delaying release. This means the acquire-execute-release pattern is not uniform across the six systems studied. The conclusion should be narrowed to 'several schedulers can support the pattern with custom glue' or should analyze this exception as a limitation of the claimed unification.
minor comments (5)
  1. [Sec. IV (opening), Sec. IV-E] Typos: 'workfload' should be 'workload' in the opening of Sec. IV; 'QuantumResoureClaim' should be 'QuantumResourceClaim' in Sec. IV-E.
  2. [Listings 9-10, Table III] The environment variable is written as QRMI_QPU_RESOURCES in Listings 9 and 10 but shortened to QRMI_QPU_RES in Table III. Please make the notation consistent or explain the abbreviation where it appears.
  3. [Table II] The special symbol '≈∗∗' for the Slurm row is not explained in the text. The table legend explains ✓, ≈, and ×, but not what distinguishes the Slurm entry from the other '≈' entries. Add a note.
  4. [Sec. V-A] The distinction between is_accessible() and the proposed is_runnable() is useful, but the text should be explicit that is_runnable() is not yet part of QRMI and is under community discussion, to avoid readers attributing it to the current interface.
  5. [References] Several references (e.g., [2], [3], [4]) are arXiv preprints dated 2026. Please verify that the cited versions are publicly available and, if appropriate, add DOIs or permanent identifiers.

Circularity Check

0 steps flagged · score 2.0 of 10

No derivation-level circularity: the portability claim is an empirical overreach, not a self-referential derivation.

full rationale

The paper contains no equations, fitted parameters, or uniqueness theorems; its central claim ('QRMI provides a portable and flexible abstraction layer') is an empirical generalization from six workload-manager integrations. That claim is weakened by the paper's own admissions — 'this approach is not fully portable between workload managers due to differences in workload manager design' (Sec. III), 'Many of the integrations presented in this paper remain at the proof-of-concept stage' (Sec. VI), and 'The analysis presented in this paper is qualitative' (Sec. VI) — and the Flux integration is explicitly incomplete (Sec. IV-F). These are evidential limitations, not circular reductions: the integrations are new implementations described with scheduler-specific code, so the conclusion does not rest on an equation that assumes it. The main self-citation concern is that QRMI's definition and Slurm baseline come from the authors' prior work [1] and many cited repos/deployments are from the QRMI community; however, this is a support/independence issue, not a derivation-level circularity. No step in the paper reduces the claimed portability to its own inputs by construction, so no circular step is flagged; the low score reflects only the minor self-citation pattern.

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

This is a non-mathematical engineering paper, so there are no free parameters or invented physical entities. The load-bearing assumptions are about the stability and capability of the workload-manager extension mechanisms and QRMI's API as defined in prior work; these are domain assumptions, not ad-hoc-to-paper constructs.

assumptions (3)
  • domain assumption The extension mechanisms of the workload managers (SPANK, PBS hooks, LSF jobstarter/postexec, Grid Engine prolog/epilog, Kubernetes CRDs) work as documented and provide sufficient lifecycle interception.
    The paper's integrations rely on these documented hooks; if a hook's semantics differ across versions/sites, the portability claim weakens.
  • domain assumption QRMI's API, as defined in [1], is a stable, vendor-agnostic interface that can be used uniformly across these schedulers.
    The paper takes QRMI's design as given from prior work [1] and does not re-derive it.
  • domain assumption Quantum resources can be abstracted with an acquire-execute-release lifecycle model compatible with batch schedulers.
    This is the core design pattern QRMI applies to all schedulers; if quantum resource semantics do not fit this model, the integrations break.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Examining QRMI as a Unified Interface for Quantum-HPC Integration." pith.science (2026). https://pith.science/paper/Z7345ZYU

@misc{pith2026260719591,
  author       = {Pith},
  title        = {Pith review of: Examining QRMI as a Unified Interface for Quantum-HPC Integration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Z7345ZYU}},
  note         = {Machine review of arXiv:2607.19591}
}
read the original abstract

The efficient and scalable integration of quantum resources into high-performance computing (HPC) environments requires standardized mechanisms for resource management, scheduling, and workflow orchestration across diverse and heterogeneous infrastructures. The Quantum Resource Management Interface (QRMI) addresses this challenge through a thin, vendor-agnostic middleware layer that provides standardized APIs for scheduling, executing, and monitoring quantum workloads while exposing quantum resources as first-class schedulable resources alongside CPUs and GPUs. Although previous work demonstrated QRMI integration with the Slurm workload manager, its applicability across other workload managers remained unexamined. This paper extends the validation of QRMI to a broad range of workload managers, including PBS, LSF, Grid Engine, Kubernetes, and the Flux Framework, encompassing traditional batch schedulers, a cloud-native orchestration platform, and a graph-based scheduler. We examine the integration patterns, implementation requirements, and scheduler-specific considerations associated with each environment and compare QRMI with alternative approaches to quantum resource integration. We demonstrate that QRMI provides a portable and flexible abstraction layer that minimizes scheduler-specific modifications while enabling consistent access to heterogeneous quantum resources across both on-premises and cloud environments.

Figures

Figures reproduced from arXiv: 2607.19591 by the authors.

Figure 1
Figure 1. QRMI architecture, showing core language bind [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. A depth-first quantum resource match using the Fluxion resource graph. [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Workflow manager integration with QRMI and a [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

60 extracted references · 4 canonical work pages

  1. [1]

    Quantum Resources in Resource Management Systems,

    U. Bacher, M. Birmingham, C. D. Carothers, A. Damin, C. D. Gonzalez Calaza, A. K. Karnad, S. Mensa, M. Moreau, A. Nober, M. Ohtani, M. Rossmannek, P. Rubin, M. E. Sahin, O. Wallis, A. Shehata, I. Sitdikov, and A. Wennersteen, “Quantum Resources in Resource Management Systems,”arXiv:2506.10052, 2025. Available: https://ar xiv.org/abs/2506.10052

    arXiv 2025

  2. [2]

    Hybrid Quantum and Classical Workload Management with Graph-based Scheduling,

    V . Sochat and D. Milroy, “Hybrid Quantum and Classical Workload Management with Graph-based Scheduling,”arXiv:2607.09151, 2026. Available: https://arxiv.org/abs/2607.09151

    arXiv 2026

  3. [3]

    Reference Architecture of a Quantum-Centric Supercomputer,

    S. Seelam, J. M. Chow, A. C ´orcoles, 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,”arXiv:2603.10970, 2026. Available: https://arxiv.or g/abs/2603.10970

    arXiv 2026

  4. [4]

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

    A. Shehata, B. Austin, T. Beck, L. Burgholzer, A. Chernoguzov, S. Churchill, A. Delgado, Y . Eckert, J. Heckey, K. Kissell, K. Klymko, J. Moles, T. Naughton, L. J. O’Riordan, C. Ortiz Pauyac, G. Prawiroat- modjo, E. Rrapaj, J. Schindler, L. Schulz, S. Stern, T. Takeshita, M. Tsuji, A. Wennersteen, T. Humble, and M. Schulz, “Quantum-HPC Software Stacks and...

    arXiv 2026

  5. [5]

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

    L. Burgholzer, M. Walter, P. Hopf, ´A. Caride-Tabar´es S´anchez, T. Matts- son, B. Hoffmann, N. F ¨arkkil¨a, D. Bulmash, R. Wille, and E. Mans- field, “Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems,”arXiv:2604.19869, 2026. Available: https://arxiv.org/abs/2604.19869

    arXiv 2026

  6. [6]

    QDMI – Quantum Device Management Interface: Hardware-Software Interface for the Munich Quantum Software Stack,

    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,” IEEE International Conference on Quantum Computing and Engineer- ing (QCE), 2024. Available: https://doi.org/10.1109/QCE60285.2024.10 411

    arXiv 2024

  7. [7]

    SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows,

    A. Esposito and U.-U. Haus, “SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows,”arXiv:2506.03846, 2025. Available: ht tps://arxiv.org/abs/2506.03846

    arXiv 2025

  8. [8]

    Towards a user-centric HPC-QC environment,

    A. Wennersteen, M. Moreau, A. Nober, M. Beji, “Towards a user-centric HPC-QC environment,”Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 1879-1887, 2025. Available: https://dl.acm.o rg/doi/full/10.1145/3731599.3767549

    arXiv 2025

Show all 60 references
  1. [9]

    Assessing the Elephant in the Room in Scheduling for Current Hybrid HPC-QC Clusters,

    P. Viviani, R. Rocco, M. Barbieri, G. Bettonte, E. Boella, and M. Cipollini, “Assessing the Elephant in the Room in Scheduling for Current Hybrid HPC-QC Clusters,”55th Annual IEEE/IFIP Interna- tional Conference on Dependable Systems and Networks Workshops (DSN-W), 2025. Avail...

    2025 doi

  2. [10]

    QMIO: A Tightly Integrated Hybrid HPCQC System,

    J. Cacheiro, ´A. C. S ´anchez, R. Rundle, G. B. Long, G. Dold, J. Friel, and A. G ´omez, “QMIO: A Tightly Integrated Hybrid HPCQC System,” arXiv:2505.19267, 2025. Available: https://arxiv.org/abs/2505.19267

    2025 arXiv

  3. [11]

    Pilot- Quantum: A Middleware for Quantum-HPC Resource, Workload and Task Management,

    P. Mantha, F. J. Kiwit, N. Saurabh, S. Jha, and A. Luckow, “Pilot- Quantum: A Middleware for Quantum-HPC Resource, Workload and Task Management,”2025 IEEE 25th International Symposium on Clus- ter, Cloud and Internet Computing (CCGrid), pp. 1–10, 2025. Available: https://doi.o...

    2025

  4. [12]

    Quber- netes: Towards a Unified Cloud-Native Execution Platform for Hybrid Classic-Quantum Computing,

    V . Stirbu, O. Kinanen, M. Haghparast, and T. Mikkonen, “Quber- netes: Towards a Unified Cloud-Native Execution Platform for Hybrid Classic-Quantum Computing,”Information and Software Technology, vol. 175:107529, 2024. Available: https://doi.org/10.1016/j.infsof.2 024.107529

    2024 doi

  5. [13]

    Kubernetes-Orchestrated Hybrid Quantum–Classical Work- flows,

    M. Tejedor, M. Grossi, C. T ¨uys¨uz, R. Rocha, and S. Val- lecorsa, “Kubernetes-Orchestrated Hybrid Quantum–Classical Work- flows,”arXiv:2603.24206, 2026. Available: https://arxiv.org/abs/2603.2 4206

    2026

  6. [14]

    It’s a Scheduling Affair: GROMACS in the Cloud with the KubeFlux Scheduler,

    C. Misale, M. Drocco, D. Milroy, C. Gutierrez, S. Herbein, D. Ahn, and Y . Park, “It’s a Scheduling Affair: GROMACS in the Cloud with the KubeFlux Scheduler,”3rd International Workshop on Containers and New Orchestration Paradigms for Isolated Environments in HPC (CANOPIE-HPC)...

    2021

  7. [15]

    Towards Standard Kubernetes Scheduling Interfaces for Converged Computing,

    C. Misale, D. Milroy, C. Gutierrez, M. Drocco, S. Herbein, D. Ahn, Z. Kaiser, and Y . Park, “Towards Standard Kubernetes Scheduling Interfaces for Converged Computing,”Driving Scientific and Engi- neering Discoveries Through the Integration of Experiment, Big Data, and Modelin...

    2022 doi

  8. [16]

    One Step Closer to Converged Computing: Achieving Scalability with Cloud- Native HPC,

    D. Milroy, C. Misale, G. Georgakoudis, T. Elengikal, A. Sarkar, M. Drocco, T. Patki, J. Yeom, C. Gutierrez, D. Ahn, and Y . Park, “One Step Closer to Converged Computing: Achieving Scalability with Cloud- Native HPC,”IEEE/ACM 4th International Workshop on Containers and New Or...

    2022

  9. [17]

    Architecture of the Slurm Workload Man- ager,

    M. A. Jette and T. Wickberg, “Architecture of the Slurm Workload Man- ager,”Job Scheduling Strategies for Parallel Processing (JSSPP), pp. 3– 23, 2023. Available: https://doi.org/10.1007/978-3-031-43943-8 1

    2023 doi

  10. [18]

    PBS Pro: Grid computing and scheduling attributes,

    B. Nitzberg, J. M. Schopf, and J. P. Jones, “PBS Pro: Grid computing and scheduling attributes,”Grid Resource Management: State of the Art and Future Trends. Kluwer Academic Publishers, pp. 183–190, 2004. Available: https://dl.acm.org/doi/10.5555/976113.976127

    2004

  11. [19]

    LSF: Load Sharing in Large-Scale Heterogeneous Distributed Systems,

    S. Zhou, “LSF: Load Sharing in Large-Scale Heterogeneous Distributed Systems,”Proceedings of the Workshop on Cluster Computing, 1992. Available: ftp://ftp.csri.toronto.edu/white-technical-reports/257/lsf.ps.Z

    1992

  12. [20]

    Sun Grid Engine: towards creating a compute power grid,

    W. Gentzsch, “Sun Grid Engine: towards creating a compute power grid,”Proceedings of the IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid), 2001. Available: https: //doi.org/10.1109/CCGRID.2001.923173

    2001

  13. [21]

    Borg, Omega, and Kubernetes,

    B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, Omega, and Kubernetes,”Communications of the ACM, vol. 59, no. 5, pp. 70–93, 2016. Available: https://doi.org/10.1145/2890784

    2016 doi

  14. [22]

    Flux: A Next-Generation Resource Management Frame- work for Large HPC Centers,

    D. H. Ahn, J. Garlick, M. Grondona, D. Lipari, B. Springmeyer, and M. Schulz, “Flux: A Next-Generation Resource Management Frame- work for Large HPC Centers,”43rd International Conference on Parallel Processing Workshops, 2014. Available: https://doi.org/10.1109/ICPPW. 2014.15

    2014 doi

  15. [23]

    QFw: A Quantum Framework for Large-scale HPC Ecosystems,

    S. Chundury, A. Shehata, T. Naughton III, S. Kim, and I. Suh, “QFw: A Quantum Framework for Large-scale HPC Ecosystems,” arXiv:2509.14470, 2025. Available: https://arxiv.org/abs/2509.14470

    2025

  16. [24]

    Qiskit Community,Slurm SPANK Plugins for QRMI, GitHub repository,

  17. [25]

    Ohtani (IBM),PBS Hooks for QRMI, GitHub repository, 2026

    M. Ohtani (IBM),PBS Hooks for QRMI, GitHub repository, 2026. Available: https://github.com/qrmi-community/pbs-integration

    2026

  18. [26]

    Park (IBM),LSF QRMI Integration, GitHub repository, 2026

    Y . Park (IBM),LSF QRMI Integration, GitHub repository, 2026. Avail- able: https://github.com/qrmi-community/lsf-integration

    2026

  19. [27]

    Park (IBM),Flux Shell QRMI Integration, GitHub repository, 2026

    Y . Park (IBM),Flux Shell QRMI Integration, GitHub repository, 2026. Available: https://github.com/qrmi-community/flux-shell-integration

    2026

  20. [28]

    Sochat (LLNL),Kubectl Fluence, GitHub repository, 2026

    V . Sochat (LLNL),Kubectl Fluence, GitHub repository, 2026. Available: https://github.com/converged-computing/kubectl-fluence

    2026

  21. [29]

    Available: https://github.com/converged-computing/f luence

    Converged Computing,Fluence Kubernetes Scheduler Plugin, GitHub repository, 2026. Available: https://github.com/converged-computing/f luence

    2026

  22. [30]

    Avail- able: https://github.com/converged-computing/qrmi-sampler

    Converged Computing,QRMI Sampler, GitHub repository, 2026. Avail- able: https://github.com/converged-computing/qrmi-sampler

    2026

  23. [31]

    Available: ht tps://github.com/converged-computing/qrmi-go

    Converged Computing,qrmi-go, GitHub repository, 2026. Available: ht tps://github.com/converged-computing/qrmi-go

    2026

  24. [32]

    Available: https: //github.com/flux-framework/flux-core

    Flux Framework,Flux Core, GitHub repository, 2012. Available: https: //github.com/flux-framework/flux-core

    2012

  25. [33]

    Available: https://github.com/M unich-Quantum-Software-Stack/QDMI

    Munich Quantum Software Stack,Quantum Device Management Inter- face (QDMI), GitHub repository, 2023. Available: https://github.com/M unich-Quantum-Software-Stack/QDMI

    2023

  26. [34]

    Available: https: //github.com/iqm-finland/QDMI-on-IQM

    IQM Finland,QDMI on IQM, GitHub repository, 2026. Available: https: //github.com/iqm-finland/QDMI-on-IQM

    2026

  27. [35]

    Ohtani and S

    M. Ohtani and S. Salaria (IBM),SCA/HPCAsia 2026 Tutorial: QRMI with Prefect, GitHub repository, 2026. Available: https://github.com/q rmi-community/SCA-HPCAsia-2026

    2026

  28. [36]

    Available: https://github.com/IBM/lsf-quantum

    Vadim Elisseev (IBM),Quantum Workloads with IBM LSF, GitHub repository. Available: https://github.com/IBM/lsf-quantum

  29. [37]

    Gruber and A

    D. Gruber and A. Wennersteen,Grid Engine family QRMI Integration, GitHub repository, 2026. Available: https://github.com/hpc-gridware/qp u-resource/

    2026

  30. [38]

    Available: https://github.com /pasqal-io/warden

    Pasqal,Warden, GitHub repository, 2025. Available: https://github.com /pasqal-io/warden

    2025

  31. [39]

    Machin (Alice & Bob),Kubernetes Operator QRMI Integration, GitHub repository, 2026

    J. Machin (Alice & Bob),Kubernetes Operator QRMI Integration, GitHub repository, 2026. Available: https://github.com/qiskit-communi ty/qrmi/tree/proto/k8s-operator

    2026

  32. [40]

    Available: https://github.com/hpc-gridware/clusterscheduler

    HPC Gridware,Open Cluster Scheduler, GitHub repository, 2024. Available: https://github.com/hpc-gridware/clusterscheduler

    2024

  33. [41]

    Available: https: //github.com/apache/airflow

    Airflow Community,Airflow, GitHub repository, 2014. Available: https: //github.com/apache/airflow

    2014

  34. [42]

    Available: https: //github.com/PrefectHQ/prefect

    Prefect Community,Prefect, GitHub repository, 2018. Available: https: //github.com/PrefectHQ/prefect

    2018

  35. [43]

    Available: ht tps://github.com/nextflow-io/nextflow

    Nextflow Community,Nextflow, GitHub repository, 2013. Available: ht tps://github.com/nextflow-io/nextflow

    2013

  36. [44]

    Avail- able: https://github.com/snakemake/snakemake

    Snakemake Community,Snakemake, GitHub repository, 2011. Avail- able: https://github.com/snakemake/snakemake

    2011

  37. [45]

    Available: https: //slurm.schedmd.com/licenses.html#dynamic licenses

    SchedMD,Dynamic Licenses, Software documentation. Available: https: //slurm.schedmd.com/licenses.html#dynamic licenses. Accessed: 19 Jul 2026

    2026

  38. [46]

    Available: https://slurm.schedmd.com/hres.html

    SchedMD,Hierarchical Resource Scheduling (HRES), Software docu- mentation. Available: https://slurm.schedmd.com/hres.html. Accessed: 19 Jul 2026

    2026

  39. [47]

    Available: https://converged- computing.org/introduction

    Converged Computing,Introduction, Converged Computing Community Space. Available: https://converged- computing.org/introduction. Accessed: 19 Jul 2026

    2026

  40. [48]

    Pasqal Inaugurates Italy’s First Neutral-Atom Quantum Com- puter, Third Pasqal System in Europe,

    Pasqal, “Pasqal Inaugurates Italy’s First Neutral-Atom Quantum Com- puter, Third Pasqal System in Europe,” Press Release, 11 Jun 2026. Available: https://www.pasqal.com/newsroom/pasqal-inaugurates-italy s-first-neutral-atom-quantum-computer-third-pasqal-system-in-europ e/. Acc...

    2026

  41. [49]

    The Basque Government Opens the IBM Quantum System Two to Industry and Public Entities to Boost New Innovation and Technology Transfer Projects,

    Basque Quantum, “The Basque Government Opens the IBM Quantum System Two to Industry and Public Entities to Boost New Innovation and Technology Transfer Projects,” Press Release, 6 Jul 2026. Available: https://www.basquequantum.eus/en/news/basque-government-opens-i bm-quantum-s...

    2026

  42. [50]

    Building Software for Quantum-Centric Supercomputing,

    IBM, “Building Software for Quantum-Centric Supercomputing,” IBM Quantum Blog, 15 Sep 2025. Available: https://www.ibm.com/quantu m/blog/qcsc-software. Accessed: 19 Jul 2026

    2025

  43. [51]

    Available: https://2021.help

    Siemens (Altair),Altair PBS Professional 2021.1.2 Plugins (Hooks) Guide, Software documentation, 2021. Available: https://2021.help. altair.com/2021.1.2/PBS%20Professional/PBSHooks2021.1.2.pdf. Accessed: 19 Jul 2026

    2021

  44. [52]

    Available: https://slurm.schedmd.com

    SchedMD,Slurm Workload Manager, Software documentation, version 26.05. Available: https://slurm.schedmd.com. Accessed: 19 Jul 2026

    2026

  45. [53]

    Available: https: //openpbs.org

    OpenPBS Project,OpenPBS, Software documentation. Available: https: //openpbs.org. Accessed: 19 Jul 2026

    2026

  46. [54]

    Available: https://www.ibm.com/docs/en/spectrum-lsf

    IBM,IBM Spectrum LSF Documentation, Software documentation, version 10.1.0. Available: https://www.ibm.com/docs/en/spectrum-lsf. Accessed: 19 Jul 2026

    2026

  47. [55]

    Available: https://kubernetes.io/docs/

    Kubernetes Authors,Kubernetes Documentation, Software documenta- tion. Available: https://kubernetes.io/docs/. Accessed: 19 Jul 2026

    2026

  48. [56]

    Flux Authors,Flux Documentation, Software documentation, 4 Jun

  49. [57]

    STFC launches powerful new AI su- percomputer for industry,

    UK Research and Innovation, “STFC launches powerful new AI su- percomputer for industry,” Press Release, 20 Oct 2025. Available: https://www.ukri.org/news/stfc-launches-powerful-new-ai-superco mputer-for-industry/. Accessed: 19 Jul 2026

    2025

  50. [58]

    Quantum computing testbeds,

    National Quantum Computing Centre, “Quantum computing testbeds,” Press Release, 5 Feb 2024. Available: https://www.nqcc.ac.uk/quantum -computing-testbeds-in-the-uk/. Accessed: 19 Jul 2026

    2024

  51. [2025]

    Available: https://github.com/qiskit-community/spank-plugins/

  52. [2026]

    Accessed: 19 Jul 2026

    Available: https://flux- framework.readthedocs.io/en/latest/. Accessed: 19 Jul 2026

    2026

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.