-
Notifications
You must be signed in to change notification settings - Fork 1
Meeting 2026 06 15
- Date: Monday, June 15, 2026
- Time: 7 pm - 8 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Location: Virtual Meeting.
- Next: Monday, June 22, 2026 @ 12 pm - 1 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Seminar Series: ORNL - Development update (Amir Shehata)
| Person | Institution |
|---|---|
| Amir Shehata | Oak Ridge National Laboratory (ORNL) |
| Thomas Naughton III | Oak Ridge National Laboratory (ORNL) |
| Ryan Landfield | Oak Ridge National Laboratory (ORNL) |
| Brandon Neth | Hewlett Packard Enterprise (HPE) |
| Michael Ferguson | Hewlett Packard Enterprise (HPE) |
| Oliver Alvarado Rodriguez | Hewlett Packard Enterprise (HPE) |
| Eun Kyung Lee | IBM |
| Hiroshi Horii | IBM Japan |
| Smriti Bajaj | Dell Technologies |
| Yasuko Eckert | AMD |
| Neal Erickson | Quantinuum |
| Josh Moles | IonQ |
| Jiri Schindler | Independent |
| Doug Oucharek | Oak Ridge National Laboratory (ORNL) |
| Jeff Heckey | AWS |
| Kevin K | Alice & Bob |
| Miwako Tsuji | RIKEN |
| Sakshi Chhabra | Indian Institute of Science (IISc) |
| Abdur Rahman Hatim | Indian Institute of Science (IISc) |
| Martin Schulz | Technical University of Munich (TUM) |
The meeting had two primary goals:
-
Review logistics and objectives for the upcoming openQSE Day event.
-
Provide technical updates on:
- openQSE GitHub repositories
- Hardware description schemas
- The Quantum Framework (QFW)
- Resource management interfaces
- Integration with quantum hardware and simulators
- Future architectural directions
Amir provided an overview of the upcoming openQSE Day agenda.
The event will begin with:
- Welcome and organizational remarks
- A keynote from Georgia Tourassi (Associate Lab Director - ORNL ) discussing ORNL's quantum strategy
- A short introduction to openQSE activities and goals
The majority of the day will be dedicated to focused working group activities.
Participants will be able to join up to two working groups across two separate sessions.
9:45 AM – 12:00 PM
Following lunch and a keynote from Laura, participants may join a second working group.
Each working group will summarize:
- Progress
- Findings
- Proposed milestones
- Inter-group dependencies
at the conclusion of the day.
The following working groups were announced:
| Working Group | Lead Organizations |
|---|---|
| Software Architecture | ORNL, AMD |
| System Architecture & Workflows | AWS |
| Compiler Infrastructure | HPE and collaborators |
| Quantum Resource Management | IBM |
Oracle representatives will participate across all working groups.
Amir emphasized two primary objectives:
Each group should identify:
- Deliverables
- Milestones
- Priorities
for the next year.
Since the groups are interdependent, they should also identify:
- Inputs required from other groups
- Outputs they provide to other groups
- Cross-group interfaces and dependencies
to avoid isolated development efforts.
Thomas Naughton presented ongoing work related to vendor-neutral hardware description formats.
Two repositories were highlighted:
Provides:
- Hardware schema definitions
- Validation mechanisms
- Portable hardware descriptions
The goal is to establish a common, vendor-neutral representation of quantum hardware characteristics.
A concrete implementation of the schema for IQM systems.
This repository demonstrates:
- Hardware description generation
- Integration with IQM platforms
- Use of the common schema
Both repositories are distributed as installable Python packages to encourage reuse and integration.
The work aims to:
- Normalize hardware descriptions across vendors.
- Represent topology information consistently.
- Provide graph-based hardware models.
- Support calibration and execution metadata.
Thomas compared the effort conceptually to HWLOC, which provides standardized hardware topology descriptions in HPC systems.
Thomas also demonstrated a second project based on a containerized Slurm environment.
The project provides:
- A local virtual HPC cluster
- Developer-friendly deployment
- CI/CD testing environment
- Quantum resource experimentation
using Docker containers.
The environment includes:
- Slurm controller
- Virtual compute nodes
- Database backend
- QFW integration
- Quantum resource management interfaces
Users can quickly:
- Launch clusters
- Submit jobs
- Develop and test workflows
- Evaluate scheduling and resource management approaches
without needing access to production HPC systems.
Amir provided a detailed overview of the Quantum Framework architecture.
QFW consists of two major layers:
Implemented in C and Python.
Provides:
- Communication infrastructure
- Process coordination
- Service discovery
- Remote procedure calls (RPC)
A Python interpreter is embedded within a C runtime environment.
Provides:
- Hardware abstraction
- Device access
- Simulator access
- Vendor-neutral execution APIs
Applications interact with services rather than directly with vendor-specific APIs.
Amir demonstrated how service APIs are defined.
A service API defines functions such as:
- Synchronous execution
- Asynchronous execution
- Completion queues
- Event notifications
Applications call these APIs without needing to know which hardware vendor is providing execution.
Several backend implementations currently exist, including:
- IQM
- Quantum Brilliance
- NWQSim
- TNQVM
- Other simulators
Each backend implements the same common API.
Amir explained how QFW integrates with Slurm.
Users can allocate:
Traditional HPC nodes.
Physical quantum systems or simulator clusters.
Applications may use either independently or together.
During startup:
- Framework initializes.
- Services are launched.
- Service directory registers available resources.
- Applications discover available services.
- Workloads are submitted through common APIs.
This enables transparent execution regardless of backend implementation.
Amir demonstrated execution against the local IQM system.
The demonstration included:
- Running characterization circuits
- Collecting execution results
- Capturing hardware timing information
- Normalizing vendor-specific output into a common schema
The resulting data includes detailed timelines showing:
- Job creation
- Submission
- Validation
- Execution stages
This normalization framework is intended to support multiple vendors in the future.
Several roadmap items were discussed.
AMD and ORNL are exploring a higher-level runtime layer that would:
- Decouple execution from backend implementations
- Support multiple software frameworks
- Provide more flexible execution workflows
Further discussion is planned during the July 24 workshop.
IBM, ORNL, MQSC, and others are working on:
- QRMI integration
- QDMI integration
- Unified resource interfaces
The goal is to support multiple resource managers and execution environments.
Future plans include:
- Slurm support
- Flux integration
- PBS Pro support
- LSF support
where feasible.
Planned capabilities include:
- Rate-based policies
- Credit-based policies
- Resource quotas
- Usage governance
to prevent oversubscription of quantum devices.
Future scheduling research may include:
- Round-robin scheduling
- Shortest-job-first
- Longest-job-first
- Multi-user fairness policies
for quantum hardware access.
The framework currently supports individual backends.
Future work will focus on:
- Simultaneous multi-device execution
- Hybrid hardware workflows
- Multi-vendor orchestration
within a common framework.
Jiri asked about the rationale behind:
-
Current RPC mechanisms
-
Python service definitions
-
Alternatives such as:
- Protocol Buffers
- gRPC
- Language-neutral interface definitions
Amir explained that the current implementation evolved historically and uses:
- Python service definitions
- JSON serialization
- Internal RPC mechanisms
Jiri noted that gRPC could provide:
- Language neutrality
- Auto-generated client/server stubs
- Stronger type safety
- Better interoperability
Amir agreed that future evolution toward such technologies would be reasonable and welcomed community contributions.
Smriti asked how vendor neutrality is maintained.
Amir explained:
- Applications interact only with common APIs.
- Vendor-specific services implement those APIs.
- Backends translate common calls into vendor-specific operations.
This architecture allows the same application to target different quantum systems without modification.
Several participants discussed authentication.
Currently:
- IQM access relies on API keys.
- Keys are configured manually.
The group discussed:
- Integrating authentication with Slurm identities.
- Mapping user identities to vendor credentials.
- Hiding API keys from applications.
- Creating pluggable authentication mechanisms.
Jiri emphasized that vendor participation will be necessary to develop robust authentication solutions.
Michael asked how cloud-style execution models fit into QFW.
Specifically:
- Cloud providers often queue jobs internally.
- Users submit work asynchronously.
- Resource allocation differs from HPC scheduler models.
Amir explained:
- Current development targets Slurm-based deployments.
- Cloud-style queueing would require additional work.
- The framework architecture should be flexible enough to support such workflows in the future.
The topic remains an area for future exploration.
- openQSE Day structure and working group organization were finalized.
- Community members were encouraged to complete working group surveys.
- Hardware schema and topology repositories continue to mature.
- Containerized Slurm developer environments are available for experimentation.
- QFW now supports execution against local IQM hardware.
- Vendor-neutral service APIs remain a central architectural goal.
- Authentication and cloud scheduling remain active design challenges.
- Community participation through pull requests, testing, and design feedback was strongly encouraged.
| Action Item | Owner |
|---|---|
| Complete working group participation survey | All Members |
| Review and contribute to hardware schema repositories | Community |
| Test the Slurm developer cluster environment | Community |
| Provide feedback on QFW architecture and APIs | Community |
| Continue QRMI/QDMI integration work | IBM, ORNL, MQSC |
| Present runtime architecture updates during July 24 workshop | AMD & ORNL |
| Explore authentication and identity integration approaches | Vendors & Resource Management WG |
| Evaluate alternative RPC technologies and service definitions | Community |
Amir concluded by encouraging community members to:
- Clone the repositories
- Experiment with the tools
- Submit pull requests
- Offer architectural suggestions
The meeting ended with a reminder that all components remain community-driven and open for contribution.