-
Notifications
You must be signed in to change notification settings - Fork 1
Meeting 2026 08 17
amirshehataornl edited this page Aug 20, 2026
·
4 revisions
- Date: Monday, August 17, 2026
- Time: (Slot #1) 12 pm - 1 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Location: Virtual Meeting.
- Meeting Link: openqse.org/captcha
- Next: Monday, August 24, 2026 @ (Slot #2) 7 pm - 8 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Seminar Series: Infleqtion - Ryan Jones
Attendance Report was corrupted. The meeting had 42 attendees.
| Person | Institution |
|---|---|
| Amir Shehata | ORNL |
| Ryan Jones | Infleqtion |
| Johannes Blaschke | EIT Oxford |
| Masoud Mohseni | HPE |
| Namit Anand | HPE |
| Jiri Schindler | IonQ |
| Peter Groszkowski | ORNL |
| Álvaro Caride | IQM |
- Ryan Jones presented Infleqtion's neutral-atom quantum-computing stack and discussed how its hardware capabilities affect quantum-HPC integration.
- The talk emphasized dynamic atom reconfiguration, all-to-all connectivity, and how neutral-atom systems can support different fault-tolerant and measurement-feedback strategies.
- Infleqtion's Superstaq middleware was described as the main user-facing interface for compiling circuits from common quantum programming frameworks to native hardware operations.
- Ryan distinguished batch-time hybrid workflows, where quantum and classical steps may run minutes or longer apart, from real-time workflows where classical compute participates in the loop with the QPU on roughly millisecond timescales.
- The discussion focused on when co-location or co-allocation with HPC resources matters, how real-time decoder and conditional workflows could be exposed to users, and whether MLIR-style heterogeneous kernels could provide a standard interface across vendors.
- Participants raised questions about mid-circuit measurement, conditional operations, QLDPC decoding requirements, repeat-until-success circuits, RoCE/RDMA-style links, NVLink-related integration, and FPGA-based real-time data movement.
- NOTICE: Notes generated using AI; please verify accuracy.
- Amir Shehata opened the meeting and introduced Ryan Jones from Infleqtion for a seminar on QHPC integration.
- Ryan introduced himself as a principal embedded systems engineer at Infleqtion, focused on control software and hardware architectures for quantum computing.
- He invited questions during the talk through raised hands or chat.
- Ryan described Infleqtion as a quantum-technology company centered on neutral-atom systems.
- The same core neutral-atom platform supports:
- Research, academic, and industrial neutral-atom cells.
- Position, navigation, and timing systems.
- Sensing applications such as inertial sensing.
- Quantum-computing systems and quantum software.
- Infleqtion has offices in the United States, United Kingdom, and Australia, and systems deployed with collaborators internationally.
- Examples included quantum computers delivered to the UK's NQCC and Japan's Moonshot project, PNT systems, and space-related atom-lab work.
- Ryan framed neutral atoms as attractive qubits because they are naturally uniform, stable, scalable, and have relatively long coherence times.
- He noted that longer coherence times can relax some latency requirements for online decoders compared with faster-clocked modalities.
- Infleqtion's system uses laser beams, magnetic fields, electric fields, microwave radiation, and atom motion to manipulate qubits.
- A central hardware capability is dynamic reconfiguration:
- Atoms can be physically moved between sites.
- Arrays can be prepared before circuit execution.
- Reconfiguration can also occur during circuit execution.
- This dynamic motion enables effective any-to-any or all-to-all coupling, which affects how users and compilers should express connectivity and motion costs.
- Ryan used a fault-tolerant state-preparation example to show how atoms can be moved after two-qubit operations to continue forwarding quantum information.
- For many quantum computers, error-correction workflows involve measuring qubits, sending the result to a classical decoder, applying corrections, and continuing execution.
- Infleqtion's all-to-all connectivity may enable alternatives such as measurement-free quantum error correction and coherent feedback.
- Ryan emphasized that users should still be able to use standard circuit tools, but should also be able to expose or hint hardware capabilities such as atom motion and all-to-all connectivity to the compiler.
- He noted that, for very large circuits, it may sometimes be better to measure and use a classical decoder despite the latency cost, depending on the full system tradeoff.
- Ryan described Infleqtion's high-level stack as:
- An application layer where people and software work with collaborators to formulate problems.
- Superstaq middleware as the interface between user-level quantum circuits and hardware.
- A native gate and pulse-sequence layer that executes on the control system.
- Superstaq was described as accepting common circuit inputs from frameworks such as Qiskit and Cirq.
- The compiler can target Infleqtion neutral-atom systems and other third-party hardware, including IBM systems, trapped-ion systems, superconducting systems, and spin-qubit systems.
- In response to a chat question, Ryan said Superstaq supports OpenQASM with some limitations, but is not fully feature complete.
- Ryan defined batch-time workflows as cases where one circuit or a collection of circuits is submitted and eventually returns measurement data for later classical processing.
- These loops may take tens of minutes, hours, or longer.
- He used precision oncology work with the University of Chicago and MIT under Wellcome Leap's Q4Bio program as an example.
- The workflow was described as:
- Preprocess patient sample data.
- Frame the problem as a polynomial constrained binary optimization tournament.
- Use the quantum computer to identify important features and relationships.
- Use classical computation to narrow the problem until the remaining instance is classically tractable.
- Ryan argued that physical co-location matters less for these long-loop workflows if the classical and quantum stages already take many minutes.
- Ryan contrasted batch-time workflows with real-time workflows, where classical compute is inside the execution loop of the quantum computer.
- A real-time workflow might:
- Execute part of a circuit.
- Measure the QPU state.
- Send measurement data to a classical system.
- Receive low-level operations back from the classical system.
- Continue execution based on the result.
- He suggested the relevant loop period is likely on the order of milliseconds, including both classical and quantum durations.
- Ryan said these real-time workflows are currently internal to Infleqtion, but are worth discussing because standardization could eventually let users define classical operations inside the QPU loop.
- Ryan described Infleqtion's real-time control hardware as distributed programmable systems-on-chip used to orchestrate peripherals, modulate laser beams, acquire measurements, and manage QPU state.
- These systems are connected through a high-speed topology, with some links in the hundreds-of-gigabits-per-second range.
- He described a RoCE/RDMA-style link for expanding real-time compute capabilities to accelerators such as GPUs.
- The same dispatch model could in principle extend beyond GPUs to FPGA, TPU, MPU, DPU, CPU, or other accelerator clusters.
- Ryan then described a heterogeneous-kernel model:
- Quantum instructions execute on the real-time control system.
- A measurement operation produces data.
- The control system dispatches a classical decode function to an accelerator such as a GPU.
- The accelerator returns a result with low latency and low jitter.
- He suggested MLIR as a promising path for expressing these heterogeneous workflows in a way that different vendors could lower to their own hardware.
- He mentioned open-source efforts such as the Munich Quantum Toolkit and PennyLane as examples of MLIR-related quantum tooling.
- Masoud Mohseni asked whether Infleqtion's pipeline provides access to mid-circuit measurement and conditional operation for heterogeneous compilation.
- Ryan distinguished between:
- Mid-circuit measurement, which can be described in a circuit-style interface.
- The heterogeneous real-time part, which is currently implicit and not publicly exposed to end users.
- Ryan said Infleqtion does not yet have a sustainable public interface for users to describe arbitrary heterogeneous workflows.
- He noted that such workflows could be described in OpenQASM-like or circuit-like forms, but that the full hardware degrees of freedom make a simple circuit-only abstraction less tractable.
- Masoud commented that neutral atoms' slower physical clock can relax decoder latency requirements, but may create throughput challenges for fully parallel transverse operations and conditional operations.
- Ryan agreed that the earlier latency framing was simplified and that neutral-atom systems have challenges as well as advantages.
- He said he was not the best person to describe Infleqtion's detailed approach to that particular throughput issue.
- Namit Anand asked what class of QLDPC codes Infleqtion expects to support and noted that more complex QLDPC codes create decoding requirements that interact with Masoud's point.
- Ryan said Infleqtion has parallel efforts across classes of QLDPC codes but could not describe a specific direction or family in detail.
- He offered to discuss hardware-side approaches for reducing latency, but not the internal code-family roadmap.
- Amir asked about the difference between physical co-location and co-allocation of quantum and HPC resources.
- He noted that even if a batch-time workflow tolerates high network latency, releasing and reacquiring HPC resources around QPU use could be expensive because of queue delays.
- Ryan agreed that co-location may not be compelling from a data-transfer-latency perspective for long-loop workflows, but that co-allocation and orchestration can matter substantially.
- He said a tightly coupled quantum/classical scheduling model is a reason an openQSE-style interface could be preferable to cloud-service workflows for some use cases.
- Amir also asked whether Infleqtion uses workflow management software for batch-time workflows.
- Ryan said Superstaq has internal workflow-management components, but they are not generally exposed to users.
- He said Infleqtion is considering compatibility with QRMI-like interfaces so HPC orchestration systems can interact with Infleqtion systems and users can keep using familiar workflow managers.
- Masoud asked for examples of quantum algorithms that require real-time millisecond-scale workflows.
- Ryan identified quantum error correction and decoding as obvious examples.
- He also suggested repeat-until-success or early-exit conditions, where an algorithm can continue until a success criterion is reached or stop when a failure condition is detected.
- Masoud clarified that he was asking about algorithmic quantum/classical co-processing at the logical layer, beyond error correction or error mitigation.
- Ryan said some tournament-style workflows could benefit from faster feedback hooks, but did not provide a concrete public algorithmic example.
- Amir said it would be useful for Infleqtion to share specific algorithms that require in-the-loop classical HPC beyond decoding.
- Ryan agreed and said Infleqtion expects to use its low-level flexibility in creative application-layer workflows and to make some of those examples publicly available.
- Namit commented that repeat-until-success circuits appear not only in error mitigation but also in partially fault-tolerant computation and Clifford+T synthesis resource estimates.
- He cautioned that reporting average T counts under a repeat-until-success assumption hides variance and implementation details.
- Namit suggested either:
- Expose repeat-until-success as an explicit primitive so users can declare it when submitting jobs.
- Derandomize the construction and report an explicit circuit and approximation error instead of only an average estimate.
- Ryan asked whether Namit meant these should be formal primitives; Namit confirmed that was the suggestion.
- Jiri Schindler asked about the real-time hardware slide with the RoCE/RDMA-style connection, including what abstractions or libraries Infleqtion uses and whether the accelerator connection is actually RoCE or NVLink.
- Ryan said the main point was that vendors could define boundaries for transferring data across classical systems, with an RDMA-like paradigm that could extend to different accelerator types.
- Amir followed up on whether QPU measurements would be forwarded over RoCE to a GPU for decoding and asked whether Infleqtion uses standardized libraries such as libfabric or UCX.
- Ryan described the real-time system as a tightly coupled distributed FPGA/processor network that can behave like a larger composed FPGA system.
- He said the data path is intended to run largely in FPGA fabric to avoid jitter and processor stalls.
- Ryan said some implementation components use vendor IP at lower layers, while Infleqtion has developed higher-layer packetization and formatting for dispatching data to GPUs or other compute systems.
- He mentioned NVIDIA Hololink as a layer that can support RDMA/RoCE-related functionality for the GPU-facing path.
- Amir clarified that the actual data transfer is FPGA-based; Ryan confirmed that the CPU may initiate or configure operations, but the FPGA fabric should remain in the critical data path.
- Neutral-atom dynamic reconfiguration changes the compiler and runtime interface because atom motion and all-to-all connectivity are important execution resources.
- For long-loop batch workflows, network latency is often less important than allocation and orchestration of quantum and classical resources.
- For real-time workflows, the open interface problem is harder: users need a way to define classical work inside the QPU loop without binding themselves to one vendor's control stack.
- MLIR-style heterogeneous kernels may be a useful abstraction for vendor-specific lowering of quantum/classical real-time workflows.
- Repeat-until-success, mid-circuit measurement, conditional branching, and decoder dispatch need explicit resource accounting if they are to be portable and comparable.
- FPGA-resident data movement is a practical way to reduce jitter in real-time QPU-to-accelerator workflows, but standardizing that path remains an open systems question.