Jülich, RIKEN and Hartree Show Different Stages of Quantum-Supercomputer Integration

In early September 2026, three national supercomputing operators each announced work on the link between a classical machine and a quantum processor. The announcements are not the same kind of milestone. On September 3, Forschungszentrum Jülich inaugurated JION, a trapped-ion quantum computer built by the Siegen start-up eleQtron, as part of its JUNIQ user infrastructure. The same day, RIKEN's Center for Computational Science (R-CCS) put QunaSys's QURI SDK Enterprise into operation as the application layer through which users of the supercomputer Fugaku and the GPU system ROQUO reach its two quantum computers. On September 9, the UK's STFC Hartree Center announced a memorandum of understanding with the start-up Qoro Quantum to build a demonstrator that routes quantum circuits through Hartree's Slurm scheduler using the Quantum Resource Management Interface, QRMI, with a simulator as the first backend.

One is a hardware inauguration, one is a software layer in service, and one is a development project whose physical quantum hardware is conditional on results. What the three share is a direction: each operator is working to make a quantum device callable from its classical system rather than reachable only through a separate portal. The software doing that work differs at every site. Jülich's documented hybrid stack, built for a different machine, is Eviden's Qaptiva, ParTec's ParaStation Modulo, and Slurm. RIKEN runs an interface it built itself under the JHPC-quantum project. Hartree is the one site of the three that names QRMI, the IBM-originated middleware now maintained in the qiskit-community organization.

What each operator's own documents say

Jülich: a trapped-ion machine inside JUNIQ, no batch path identified. Jülich's release describes JION as a digital, gate-based trapped-ion quantum computer whose qubits are ionized ytterbium atoms held in a vacuum by electromagnetic fields. eleQtron's control method, magnetic gradient induced coupling (MAGIC), addresses the qubits with microwaves and deliberately generated variations in the magnetic field, and the system "does not need to be operated at temperatures close to absolute zero." The ceremony marked the first public computing operation on JION. JSC's JUNIQ systems page lists a five-system portfolio including JION, spanning annealing, neutral-atom, superconducting and semiconductor spin-qubit machines, and describes JUNIQ as vendor-neutral with peer-reviewed, cloud-based access.

On integration, the release says JUNIQ "connects [the quantum systems] to JSC's high-performance computing (HPC) infrastructure" and that "certain computing operations can be offloaded to quantum systems when using classical JSC supercomputers." The release says JION will be integrated into JUNIQ and made available to researchers and companies; it does not establish a current batch-job access path. It names no software. Jülich documents a Slurm-based stack for JADE, which it inaugurated in November 2025 under the EuroHPC HPCQS project, with named components: Eviden Qaptiva, ParTec's ParaStation Modulo, Slurm, and the Pasqal SDK, so hybrid jobs run "with familiar commands." JADE's stack cannot be assumed to be JION's. JSC's quantum integration group says "all quantum devices available via JUNIQ will be integrated, if possible." The release gives no qubit count for JION.

The release itemizes three funding lines and keeps them apart. EPIQ, the partnership under which JION was procured and is operated, receives around €21 million over four and a half years from the NRW Ministry of Culture and Science. SQALING is eleQtron's own next-stage development project, funded by the state with up to around €25 million from EU ERDF/JTF funds. Q-STAR.NRW is a separate procurement, funded with up to around €25 million from structural money for the Rhenish mining region, for a semiconductor system targeting up to 200 qubits. Only the first of those pays for JION.

RIKEN: an operator-built interface with a vendor-neutral SDK on top. R-CCS's 3 September notice says QURI SDK Enterprise "enables seamless access to quantum computers from the compute and pre/post-processing nodes of the supercomputer Fugaku and the JHPC-quantum GPU supercomputer ROQUO." The hardware access predates September. QunaSys's release names the targets: ibm_kobe, the IBM Quantum System Two installed at R-CCS in Kobe, and Reimei, a Quantinuum System Model H2 at RIKEN's Wako campus. Simulation is MPI-distributed, with mpiQulacs on Fugaku and a cuQuantum backend on ROQUO, and the SDK ships QunaSys's QSCI and ADAPT-QSCI algorithms for chemistry and materials work. Mitsuhisa Sato, who leads JHPC-quantum, attributed the adoption to "strong demand" from the Test User Program, which selected 21 proposals in fiscal 2025.

Underneath the SDK is RIKEN's own layer. Its November 2025 configuration notice defines the SQC Interface as "an API developed under the JHPC Quantum project to directly connect quantum computers and HPC systems, enabling data exchange and job control." The June 2026 notice that put ROQUO into operation adds that the interface "draws on platforms like NVIDIA CUDA-Q," and that ibm_kobe "is directly connected to 'Fugaku' and 'ROQUO.'" ROQUO is a 135-node NVIDIA GB200 NVL4 system at a measured 19.80 petaflops on HPL. The RIKEN notices examined here name the SQC Interface, not QRMI. SCN previously covered work on Quantinuum's H2 platform, when a 56-qubit H2 ran a quantum-magnetism simulation past three classical tensor-network methods; RIKEN's September step puts an application layer in front of that class of hardware.

Hartree: QRMI through Slurm, simulator first. The announcement, published by both Hartree and Qoro, says Divi, Qoro's open-source Python library, "generates and routes Slurm jobs and circuits into the Hartree Center scheduler through QRMI," and that Maestro, Qoro's simulation engine, "is available as an execution backend through the QRMI interface." Hartree's page carries a publication timestamp of 9 September; Qoro dates its own announcement 8 September. The target domain is electronic structure theory and quantum chemistry, and physical hardware is conditional: "Depending on results, they may extend the work to physical quantum processing units (QPUs) and run industry pilots in sectors such as energy, finance, and pharmaceuticals." Neither text gives a timeline, a cluster name, a Slurm version, or a funding figure, so what the partners have announced is a simulator-backed integration project, with physical QPUs to follow only if the results justify them.

Hartree's involvement goes back further. In June 2025, the center wrote that it was working with IBM and partners "to design a series of plugins that will enable quantum computing vendors to interface their quantum computers to any high performance computing infrastructure," and it is one of twelve institutional affiliations on the QRMI paper discussed below, which says QRMI "has been deployed on development test nodes of the Mary Coombs supercomputer" at Hartree for evaluation with cloud-accessible quantum resources. The paper does not state whether the Qoro demonstrator will use those nodes. Maestro is not in the backend list of the qrmi README at version 0.24.4, which names IBM, IQM, Pasqal and Alice & Bob; that absence does not disprove the announcement, and SCN has not verified the Divi or Maestro integration in released code.

What QRMI does on a Slurm cluster

The qrmi README defines it as "a vendor-agnostic library for high-performance compute (HPC) systems to access, control, and monitor the behavior of quantum computational resources," a "thin middleware layer" in Rust with Python and C bindings, licensed under Apache-2.0. The Slurm side lives in a companion repository, spank-plugins. SPANK is Slurm's plugin architecture for hooking into job launch. Slurm can already be configured with arbitrary generic resources (GRES), and the QRMI paper's Slurm discussion treats the quantum device as one; what the plugin adds is a job option and an acquire-and-release step around it. Deploying it means building the plugin library, adding it to /etc/slurm/plugstack.conf, and writing a qrmi_config.json that names each quantum resource and its credentials, per the plugin README. A user then writes:

#SBATCH --qpu=ibm_quebec,ibm_sherbrooke

The --qpu option belongs to this plugin, not to Slurm. When the job starts, the plugin acquires access to the named resources, sets environment variables the job can read, and releases access when the job ends. Acquiring access is not the same as reserving the device. A provider-side queue can still sit between the job and the hardware.

Two of the project's own documents record the layer's limits. The README's dependency note says "ibm and iqm extras cannot be installed together, as they depend on incompatible versions of Qiskit," and that "alice-bob cannot be installed alongside ibm or iqm, as it depends on Qiskit versions earlier than 2.0." This documents a conflict among Python extras; it does not establish a limitation across every deployment arrangement or API. The second document is the July 2026 paper "Examining QRMI as a Unified Interface for Quantum-HPC Integration" (28 authors, twelve affiliations, revised August 8). Quantum resources, it says, "may have latency constraints, session semantics, or limited availability windows that can be incompatible with queue-based batch scheduling," and under co-scheduling, "if the quantum resource is not available, then the HPC resources will remain idle until the quantum resource becomes available." The paper's mitigation is Slurm's Dynamic License mechanism (Slurm 23.02 and later): an external license manager marks the quantum resource available or consumed, and the job stays pending until it can acquire the license. The authors call that integration a proof of concept and note a race condition, since the polling daemon's count can lag the resource's real state. The paper names production deployments only for Slurm (CINECA's Leonardo, BasQ, RPI); PBS, LSF, Grid Engine and Kubernetes are proofs of concept, and Flux is incomplete.

Software and coupling layers in the documented stacks

QRMI is one component among several in the documented stacks. The rows below are not interchangeable choices: an application SDK, a scheduler-facing resource interface, a device-management API, a programming model, and a hardware link occupy different layers, and some run together in one deployment.

The QRMI paper describes "standardized mechanisms" and a "vendor-agnostic middleware layer," and reports that Oak Ridge integrated both QRMI and QDMI into its QFw framework "behind the same adapter layer, allowing identical workflows ... to be driven through each interface side by side," calling the two complementary. Pasqal's blog calls QRMI "a vendor-neutral way for resource managers and applications to interact with quantum resources" and places CUDA-Q at the code level and NVQLink at the hardware level of the same stack. Neither the paper, the README, nor Pasqal's blog calls QRMI a standard, and SCN does not either. The most direct statement on the field comes from the openQSE survey published in April 2026 by 25 authors from ORNL, LRZ, NERSC, Pasqal, RIKEN, and others: quantum-HPC software stacks "remain isolated, often proprietary, full-stack solutions lacking common interfaces across runtime, resource management, orchestration, and execution layers." The survey proposes a reference architecture with defined layer boundaries; it is a proposal, and says so. NVIDIA's own positioning of CUDA-Q and NVQLink as the classical control plane for every vendor's hardware, which SCN examined in April, sits at a layer the scheduler-facing interfaces do not cover.

The application-side evidence: a Gordon Bell finalist on ROQUO

On September 9, Cleveland Clinic, RIKEN and IBM were named finalists for the 2026 ACM Gordon Bell Prize for a quantum-classical workflow that ran on ROQUO, Fugaku and the University of Tokyo/Tsukuba system Miyabi-G. The finalist paper decomposes a molecule into fragments via quantum embedding and simulates the fragments with a heterogeneous quantum-classical method; the quantum processors sampled fragments, not the whole protein. The release puts the system at 12,635 atoms, up to 94 qubits, and nearly 6,000 quantum operations on IBM Heron processors at Cleveland Clinic and RIKEN, using quantum sampling followed by classical subspace diagonalization, and says validating the workflow on ROQUO "eliminated the need for complex manual operations and data transfers." The winner is announced at SC26 in Chicago, November 15-20.

The paper also names the orchestration. Section IV-D describes a "Prefect-based end-to-end orchestration framework for automated execution across QPUs and GPU/CPU-based HPC systems," in which "a persistent workflow controller service on a login node coordinates jobs submitted through the native HPC scheduler with quantum circuits (jobs) submitted through IBM Quantum Runtime to multiple backends." That is a workflow tool above the scheduler and the quantum runtime, neither a scheduler plugin nor the SQC Interface: one documented answer to the question the three operators are working on. SCN reported in July on an IBM-ORNL-Cleveland Clinic fusion-materials workflow where the classical embedding step, and not the quantum solver, carried the error; that was an algorithmic finding about fragmentation accuracy, a separate problem from the manual-transfer overhead the Gordon Bell team removed.

What a QPU tender has to specify

In August, SCN compared five on-premises quantum deals and found different instruments with different success metrics; that comparison focused on procurement instruments and readiness. The documents in this story point to a second set of questions that, in SCN's view, a buyer or host of a QPU should ask at acceptance. What does the device present to: a Slurm plugin such as QRMI's, an operator-built API like RIKEN's, a vendor-supplied stack like Qaptiva, a workflow tool like Prefect, a vendor portal, or several of those in combination? Who maintains the plugin or adapter, and in whose Python environment do the jobs run? What is the access policy when the QPU is busy with someone else's job while the GPU nodes wait? Can the site swap the device for a competitor's without rewriting user workflows? None of these options excludes the others; RIKEN runs an SDK on top of its own API, and the Gordon Bell team ran a workflow controller above RIKEN's scheduler. A tender can cite the documents that bear on each: the QRMI paper for the idle-node cost and its mitigation, the README for the packaging constraint, and the openQSE survey for the absence of a shared interface across the layers.

The public money, by source

The sovereignty content of this story is in the funding lines and one ownership fact. JION is a German-built machine procured and operated under EPIQ, funded by the state of North Rhine-Westphalia, in a user infrastructure Jülich describes as European and vendor-neutral. That is a different instrument from the EuroHPC-funded HPCQS project that brought JADE to the same facility; as SCN's August look at how Europe sorts quantum hardware by funding instrument found, regional money and EuroHPC framework money can put two machines side by side under different rules. JHPC-quantum is funded by NEDO under METI's Post-5G program (JPNP20017), and RIKEN chose a Japanese SDK vendor as the application layer over US (IBM) and US-UK (Quantinuum) quantum hardware and a US (NVIDIA) GPU system. Hartree's own release calls the Qoro work "a step towards a sovereign UK quantum-HPC software value chain," and the UK's National Quantum Computing Center is among the QRMI paper's affiliations. For a US comparison, the four CHIPS quantum awards whose closures were announced on September 8 were scoped, in their public descriptions, to the manufacturing layer rather than to software of this kind.

The ownership fact concerns the scheduler that Jülich's JADE stack and every QRMI deployment in this story attach to. NVIDIA acquired SchedMD, Slurm's developer, on December 15, 2025, saying it would continue to develop and distribute Slurm as open-source, vendor-neutral software and that Slurm was then in use on more than half of the top 10 and top 100 TOP500 systems. NVIDIA also develops CUDA-Q and NVQLink, which Pasqal describes respectively as code-layer integration and hardware-coupling support, and RIKEN's June notice says its SQC Interface draws on CUDA-Q. Whether one company owning the scheduler, the programming model, and the hardware link changes anything for an operator is a question these documents do not answer.