SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows

Aniello Esposito; Utz-Uwe Haus

REVIEW 3 major objections 6 minor 2 cited by

SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Splitting a hybrid job into single-quantum-block sub-jobs lets SLURM interleave workflows, cutting quantum-device idle time and combined wall time.

desk verdict A useful and plausible engineering recipe for splitting hybrid SLURM jobs, but the central saving is asserted, not measured; worth refereeing as a practice paper, not as a demonstrated result. read the letter →

arxiv 2506.03846 v1 pith:MSEGKSL3 submitted 2025-06-04 cs.DC

Aniello Esposito , Utz-Uwe Haus This is my paper

classification cs.DC

keywords hybridclassical-quantumworkflowsSLURMheterogeneousjobsMPIdynamicprocessmanagementquantumdeviceidletimejobschedulingcheckpointandrestartHPCscancel

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

The paper argues that a hybrid classical-quantum job, which typically holds a quantum device for the whole runtime of a classical allocation while using the device only in short blocks, can be split into sub-jobs that each contain one quantum block. Releasing the quantum resource as soon as each block finishes, through MPI dynamic process management and a scancel call, gives the SLURM scheduler room to interleave sub-jobs from different workflows. The authors claim this reduces both the idle time of the quantum device and the combined wall time of co-scheduled jobs relative to running them sequentially. The method uses only tools already present on common supercomputers, so users can adopt it without waiting for new scheduling frameworks. That matters because quantum hardware is scarce, and better utilization can shorten turnaround for hybrid workloads.

What carries the argument

The mechanism combines three standard tools. SLURM heterogeneous jobs (the hetjob directive with separate partitions, e.g. -p cpu and -p qpu) allocate classical and quantum service-node resources inside one job; MPI dynamic process management (Open_port, Publish_name, Accept, Connect, Disconnect) creates a client-server intercommunicator between the classical server and the quantum client, each in its own MPI_COMM_WORLD; and a scancel call from the server terminates the client job once the quantum block is done, releasing the device. Checkpoint and restart, for example with pickle in Python, carries classical state between sub-jobs, and a dependency flag (-d) to sbatch preserves order. The paper supplies pseudo-code and SLURM scripts showing how these pieces fit together, with the possibility of embedding them in an API.

What would settle it

Run two hybrid jobs that each need several quantum blocks on a SLURM cluster with a real or simulated quantum device, once as monolithic jobs scheduled sequentially and once split into single-block sub-jobs using MPI dynamic process management and scancel. Measure the quantum device's idle time and the combined wall time in both configurations; if the split version does not reduce device idle time or combined wall time, the scheduling opportunity described in the paper does not occur in practice.

Watch

Extended reading notes

Core claim

The central claim is that job splitting converts a monolithic hybrid workflow—one that occupies a quantum device for the entire duration of a classical allocation—into a sequence of independent sub-jobs, each with a single quantum block, that SLURM can schedule like ordinary jobs. The authors show how the quantum component can run as a client with its own MPI_COMM_WORLD, connect to a classical server through MPI Open_port/Accept/Connect, and be terminated by scancel as soon as the block finishes, so the device is released as soon as possible. With several split jobs in the queue, SLURM gains an opportunity to interleave their quantum blocks and fill what would otherwise be idle time, reducing the quantum device's overall idle time and the combined wall time of two jobs compared with a sequential schedule. Working code was run on a current-generation supercomputer as a proof of concept, although the paper reports no measurements of the gain.

Load-bearing premise

The load-bearing premise is that the overhead of splitting—checkpoint and restart, MPI connection setup and teardown, SLURM job startup and termination, and scancel propagation—is small relative to the duration of a quantum block, so the quantum time released early is not offset by delays in reacquiring the device.

Editorial extensions

If this is right

A single quantum device can be shared by interleaving small quantum blocks from multiple hybrid jobs, so it no longer has to be reserved for the full wall time of each classical job.
Users on existing supercomputers can improve quantum utilization without installing new software stacks; the required SLURM and MPI features are already standard.
The scheduling benefit should grow with the number of sub-jobs and the number of co-scheduled workflows, because more blocks create more opportunities for SLURM to fill idle gaps.
The split can be hidden inside an API, so application scientists keep a high-level workflow and do not manage the client-server mechanics by hand.
Hybrid workflows that previously had to queue for contiguous quantum access can instead be co-scheduled, shortening the time users wait for their results.

Reading between the lines

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

A direct benchmark extension would measure monolithic versus split execution across a range of quantum-block durations; the paper's claim implies there is a block-size threshold below which checkpoint/restart and MPI connect/disconnect overhead erase the scheduling gain.
The same release-early pattern should transfer to other scarce accelerators (GPUs, FPGAs) and to any scheduler supporting heterogeneous jobs and job dependencies, not just SLURM/MPI.
If the benefit scales with the number of interleavable blocks, the method offers a low-cost interim path for NISQ-era hybrid computing, complementing dedicated quantum software stacks until they mature.
A testable prediction from the paper's argument is that combined wall time shrinks roughly in proportion to the number of released inter-block gaps, and that this reduction disappears when quantum blocks become as short as the sub-job overhead.

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.

Desk Editor's Note

read the letter

Quick take: this is a useful engineering recipe, not a demonstrated result. The split-and-release pattern—carving a monolithic hybrid SLURM job into per-quantum-block sub-jobs and using MPI DPM plus scancel to free the quantum partition—is genuinely new relative to the authors' earlier [12] and to the cited QDMI/MQSS work. The pseudo-code in listings 5–7 is clear enough to re-implement, and the architecture in Fig. 1 is sensible. If the overheads are small, the interleaving in Fig. 3 does reduce quantum idle time. That is a real idea worth having.

The soft spot is exactly where the reader and stress test put it: nothing is measured. Section 2.3 asserts the saving, and Section 4 says data collection is future work. The overhead of checkpoint/restart, MPI Open_port/Accept/Connect/Disconnect, SLURM job startup, and scancel propagation could easily dominate a small quantum block. The submitted paper has no logs, no benchmarks, no comparison against the monolithic baseline. So the central quantitative claim is a hypothesis. The paper is honest about this, which I respect, but the abstract says "bares the potential"—that is the right register. The claims in Section 2.3 ("reduces the overall idle time", "combined wall time ... reduced") are stronger than the evidence.

Other notes: the reliance on [12] is fine; it is prior work, and the new split is independent of it. The writing has minor typos ("ceckpoint", "revc", "bares") but nothing that blocks understanding. Related work is thin but fair for a short recipe paper.

Who is this for? People running hybrid workloads on SLURM-based HPC systems who want a concrete pattern to try. It would be a useful workshop paper or a short practice-and-experience track. As a journal article it needs the measurements it promises.

Should we send it to referees? I would, conditional on the referees understanding that the contribution is the recipe, not the quantified saving. I would ask for either a measured comparison or a clearly scoped claim. It is not a desk reject; the idea is plausible and the implementation details are nontrivial (the HPE-Cray network flags, the DPM shutdown sequence). A referee can add real value.

Recommendation: engage with it. Bring it to a reading group if anyone is working on hybrid scheduling.

Referee Report

3 major / 6 minor

Summary. The paper proposes a scheduling method for hybrid classical-quantum workflows on SLURM-based HPC systems. A monolithic job that repeatedly accesses a quantum device is split into sub-jobs containing exactly one quantum block. The quantum device is released promptly after each block using MPI dynamic process management (intercommunicators) and a scancel call from the server component. The authors argue that this split gives the SLURM scheduler the opportunity to interleave sub-jobs from different users, reducing quantum-device idle time and total wall time. The manuscript provides an architecture description, pseudo-code for the server and client, and a SLURM heterogeneous job script. No quantitative evaluation is included; the conclusion states that collecting data to statistically quantify the advantage is future work.

Significance. If the claimed advantage is real, this is a practically useful contribution: it addresses a genuine inefficiency in hybrid classical-quantum execution using only standard SLURM and MPI features, and the pseudo-code gives implementers a concrete starting point. The architecture is coherent, the use of standard tools is appropriate, and the split-and-release idea is not circular: it does not depend on fitted parameters or on results from the authors' prior work [12]. However, the central quantitative claims are currently unsupported. The paper explicitly defers data collection to future work, and the assertion that working code was run on an HPE-Cray EX system is not accompanied by logs, scripts, or benchmarks. The contribution is therefore best described as a plausible and clearly presented engineering pattern, not a validated scheduling method.

major comments (3)

[Section 2.3, Fig. 3, and Section 4] The central claims that splitting reduces the quantum device's idle time and that 'the combined wall time of two jobs is reduced compared to a sequential scheduling' are not supported by measurements. Section 4 states that data collection is future work, and no logs, benchmarks, or comparison runs appear in the paper. Since the claimed benefit depends on per-sub-job overheads (checkpoint/restart, MPI Open_port/Accept/Connect/Disconnect, SLURM job startup/teardown, and scancel propagation) being small relative to the duration of a quantum block, the authors should provide measurements from the claimed HPE-Cray EX runs or, at minimum, a parameterized overhead model showing under what conditions the split wins. Without that, Fig. 3 is an illustration of a possible schedule rather than evidence of improvement.
[Section 2.3, Listings 5 and 7] The scancel-based release mechanism is not fully specified. Listing 7 submits the server and client as two components of a single SLURM heterogeneous job, and Listing 5 calls scancel from the server to 'terminate the client.' SLURM scancel normally operates on a whole job or job step, so it is unclear whether this command terminates only the client component or the entire heterogeneous job. If it terminates the entire job, the server's remaining classical work after scancel would not execute, breaking the proposed workflow. Please specify the exact job identifiers or steps targeted by scancel and provide log output demonstrating that only the client component is terminated.
[Section 2.3, paragraph on optimized scheduling] The statement that splitting 'gives an opportunity to SLURM' to reduce idle time does not by itself establish that the combined wall time of two jobs is reduced. Interleaving requires that classical CPU resources for a second job are available while the first job is in its quantum block, and that the scheduler actually packs sub-jobs in the order shown in Fig. 3. If CPU nodes are scarce or the scheduler's policy does not backfill in that manner, the split schedule can be worse than the monolithic baseline. The paper should state these assumptions explicitly and either prove the wall-time reduction under them or clearly label it as a conditional expectation.

minor comments (6)

[Abstract] There are two typos: 'in to' should be 'into' and 'bares the potential' should be 'bears the potential.'
[Section 2.2] The phrase 'an quantum program' should be 'a quantum program.'
[Listing 2] The comment 'instead ofirecv' is missing a space and should read 'instead of irecv'; also, 'revc' appears to be a typo for 'recv.'
[Listing 4] The word 'ceckpoint' appears twice and should be 'checkpoint.'
[Listing 7] The caption says 'SLURM Heterogeneous job script for listing 3,' but the script appears to implement the split workflow of Listing 4 rather than the monolithic loop of Listing 3; please clarify or correct the cross-reference.
[Listings 5 and 6] The shutdown protocol is incomplete: Listing 5 calls shut_down_client_listener, but Listing 6's listener loop has no visible exit condition and no message that would terminate the while loop, so the described shutdown is not reproducible from the pseudo-code alone.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; the main benefit is conditionally argued and explicitly deferred for measurement, not reduced from a fit or self-citation.

full rationale

The paper contains no fitted parameters, no equations, and no benchmark that would allow a derived quantity to equal its input by construction. Its central claim is that splitting a monolithic job into one-quantum-block sub-jobs and releasing the quantum partition via MPI dynamic process management and scancel gives SLURM "an opportunity" to interleave sub-jobs, reducing quantum-device idle time and combined wall time (Section 2.3, Fig. 3). This is a conditional engineering argument, not a derivation: it depends on the scheduler actually generating such a schedule and on per-sub-job overheads being small. Section 4 explicitly says "In a future work we want to collect data on a test system to statistically quantify the advantage of the proposed method," confirming that the quantitative benefit is an unverified hypothesis rather than a claimed derivation. The only self-citation is [12], referenced in Section 1 as "In this work we further develop the ideas presented in [12]." Since the novel split-and-release mechanism is fully specified by the paper's own listings and by standard SLURM/MPI features, this citation is not load-bearing for the paper's conclusion. Lack of empirical validation is a real limitation, but it is an evidentiary gap, not circularity.

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

The method depends on unmeasured features of SLURM, MPI, and the user's checkpointing discipline rather than on fitted constants or new physical entities. The key unverified quantities are scheduling overheads and connection and teardown costs.

assumptions (4)

domain assumption SLURM heterogeneous jobs and the -d dependency flag behave as shown in Listings 1 and 7, allowing the two heterogeneous components to start at different times and be scheduled independently.
The entire method relies on SLURM treating the two het-job components as separable units; this is a feature of SLURM but is not demonstrated in the paper's own data.
domain assumption MPI dynamic process management with Open_port, Publish_name, Accept, Connect, Disconnect, and scancel can start and tear down the quantum client per sub-job with negligible overhead.
Listings 5 and 6 assume this; no timing measurements or logs are given.
domain assumption Checkpointing the classical state, for example with pickle, between sub-jobs preserves all required state and costs less than the quantum-device idle time saved.
The split design in Listing 4 depends on this; the paper calls it straightforwardly achieved but provides no overhead estimate.
domain assumption A dedicated service node can be represented as a schedulable SLURM partition named 'qpu' with immediate access to the quantum device whenever allocated.
Figure 1 and Listing 1 allocate a service node with -p qpu; the paper assumes this resource is always available when the job starts.

how reviews work

0 comments

Cite this review

Pith. "Pith review of SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows." pith.science (2026). https://pith.science/paper/MSEGKSL3

@misc{pith2026250603846,
  author       = {Pith},
  title        = {Pith review of: SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MSEGKSL3}},
  note         = {Machine review of arXiv:2506.03846}
}

read the original abstract

A method for efficient scheduling of hybrid classical-quantum workflows is presented, based on standard tools available on common supercomputer systems. Moderate interventions by the user are required, such as splitting a monolithic workflow in to basic building blocks and ensuring the data flow. This bares the potential to significantly reduce idle time of the quantum resource as well as overall wall time of co-scheduled workflows. Relevant pseudo-code samples and scripts are provided to demonstrate the simplicity and working principles of the method.

Figures

Figures reproduced from arXiv: 2506.03846 by the authors.

**Figure 2.** (a) HCQW using a dedicated quantum device over the entire duration of the job. Red arrows indicate the [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Optimized scheduling of two hybrid jobs which have been split in sub-jobs according to Fig. 2. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Examining QRMI as a Unified Interface for Quantum-HPC Integration
cs.ET 2026-07 conditional novelty 6.0 of 10

QRMI's acquire-execute-release interface can be adapted to PBS, LSF, Grid Engine, Kubernetes, and partly Flux, with three reusable integration patterns.
Introducing CQ: A C-like API for Quantum Accelerated HPC
cs.DC 2025-08 conditional novelty 6.0 of 10

CQ is an open-source C-like API and simulator backend for offloading quantum kernels from HPC codes, with sync/async executors and an experimental analogue-annealing extension.

Reference graph

Works this paper leans on

20 extracted references · 16 canonical work pages · cited by 2 Pith papers

[12]

A hybrid classical-quantum hpc workload

Aniello Esposito, Jessica R Jones, Sebastien Cabaniols, and David Brayford. A hybrid classical-quantum hpc workload. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE) , volume 2, pages 117–121. IEEE, 2023

work page 2023
[1]

Quantum algorithms: an overview

Ashley Montanaro. Quantum algorithms: an overview. npj Quantum Information, 2(1):1–8, 2016

work page 2016
[2]

Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Yuri Alexeev, Kirk M

Masoud Mohseni, Artur Scherer, K. Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Yuri Alexeev, Kirk M. Bresniker, Kerem Y . Camsari, Barbara Chapman, Soumitra Chatterjee, Gebremedhin A. Dagnew, Aniello Esposito, Farah Fahim, Marco Fiorentino, Archit Gajjar, Abdullah Khalid, Xiangzhou Kong, Bohdan Kulchytskyy, Elica Kyoseva, Ruoyu Li, P. A...

work page 2025
[3]

Davenport, Jessica R

James H. Davenport, Jessica R. Jones, and Matthew Thomason. A practical overview of quantum computing: Is exascale possible?, 2023

work page 2023
[4]

Contextual subspace auxiliary-field quantum monte carlo: Improved bias with reduced quantum resources, 2024

Matthew Kiser, Matthias Beuerle, and Fedor Simkovic IV . Contextual subspace auxiliary-field quantum monte carlo: Improved bias with reduced quantum resources, 2024

work page 2024
[5]

Quantum monte carlo on quantum computers. https://github.com/amazon-braket/ amazon-braket-examples/blob/feature/quantum-monte-carlo/examples/hybrid_quantum_ algorithms/Quantum_Monte_Carlo_Chemistry/Quantum_Monte_Carlo_Chemistry.ipynb

work page
[6]

Hybrid classical-quantum simulation of maxcut using qaoa-in-qaoa

Aniello Esposito and Tamuz Danzig. Hybrid classical-quantum simulation of maxcut using qaoa-in-qaoa. In 2024 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW) , pages 1088–1094. IEEE, 2024

work page 2024
[7]

Towards the munich quantum software stack: Enabling efficient access and tool support for quantum computers

Martin Schulz, Laura Schulz, Martin Ruefenacht, and Robert Wille. Towards the munich quantum software stack: Enabling efficient access and tool support for quantum computers. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE) , volume 2, pages 399–400. IEEE, 2023

work page 2023

Show all 20 references

[8]

Qdmi-quantum device management interface: Hardware-software interface for the munich quantum 7 SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows software stack

Robert Wille, Ludwig Schmid, Yannick Stade, Jorge Echavarria, Martin Schulz, Laura Schulz, and Lukas Burgholzer. Qdmi-quantum device management interface: Hardware-software interface for the munich quantum 7 SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows softw...

2024
[9]

https://slurm.schedmd.com/

Slurm workload manager. https://slurm.schedmd.com/
[10]

Slurm: Simple linux utility for resource management

Andy B Yoo, Morris A Jette, and Mark Grondona. Slurm: Simple linux utility for resource management. In Workshop on job scheduling strategies for parallel processing , pages 44–60. Springer, 2003

2003
[11]

MPI: A Message-Passing Interface Standard V ersion 4.0, Jun 2021

Message Passing Interface Forum. MPI: A Message-Passing Interface Standard V ersion 4.0, Jun 2021

2021
[13]

Ibm’s qiskit tool chain: Working with and developing for real quantum computers

Robert Wille, Rod Van Meter, and Yehuda Naveh. Ibm’s qiskit tool chain: Working with and developing for real quantum computers. In 2019 Design, Automation & Test in Europe Conference & Exhibition (DATE) , pages 1234–1240. IEEE, 2019

2019
[14]

Quantum computing with qiskit

Ali Javadi-Abhari, Matthew Treinish, Kevin Krsulich, Christopher J Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D Nation, Lev S Bishop, Andrew W Cross, et al. Quantum computing with qiskit. arXiv preprint arXiv:2405.08810, 2024

2024 arXiv
[15]

https://qiskit.github.io/qiskit-addon-cutting/

Qiskit addon: circuit cutting. https://qiskit.github.io/qiskit-addon-cutting/
[16]

https://developer.nvidia.com/cuda-q#section-resources

Nvidia cuda-q. https://developer.nvidia.com/cuda-q#section-resources
[17]

Qrisp: A framework for compilable high-level programming of gate-based quantum computers

Raphael Seidel, Sebastian Bock, René Zander, Matic Petriˇc, Niklas Steinmann, Nikolay Tcholtchev, and Manfred Hauswirth. Qrisp: A framework for compilable high-level programming of gate-based quantum computers. arXiv preprint arXiv:2406.14792, 2024

2024 arXiv
[18]

Simulations of quantum circuits with approximate noise using qsim and cirq

Sergei V Isakov, Dvir Kafri, Orion Martin, Catherine V ollgraff Heidweiller, Wojciech Mruczkiewicz, Matthew P Harrigan, Nicholas C Rubin, Ross Thomson, Michael Broughton, Kevin Kissell, et al. Simulations of quantum circuits with approximate noise using qsim and cirq. arXiv pr...

2021 arXiv
[19]

Cirq: A python framework for creating, editing, and invoking quantum circuits

Andrew Hancock, Austin Garcia, Jacob Shedenhelm, Jordan Cowen, and Calista Carey. Cirq: A python framework for creating, editing, and invoking quantum circuits
[20]

Pennylane: Automatic differentiation of hybrid quantum-classical computations

Ville Bergholm, Josh Izaac, Maria Schuld, Christian Gogolin, Shahnawaz Ahmed, Vishnu Ajith, M Sohaib Alam, Guillermo Alonso-Linaje, B AkashNarayanan, Ali Asadi, et al. Pennylane: Automatic differentiation of hybrid quantum-classical computations. arXiv preprint arXiv:1811.0496...

2018 arXiv

Pith tools

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

[1] [12]

A hybrid classical-quantum hpc workload

Aniello Esposito, Jessica R Jones, Sebastien Cabaniols, and David Brayford. A hybrid classical-quantum hpc workload. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE) , volume 2, pages 117–121. IEEE, 2023

work page 2023

[2] [1]

Quantum algorithms: an overview

Ashley Montanaro. Quantum algorithms: an overview. npj Quantum Information, 2(1):1–8, 2016

work page 2016

[3] [2]

Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Yuri Alexeev, Kirk M

Masoud Mohseni, Artur Scherer, K. Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Yuri Alexeev, Kirk M. Bresniker, Kerem Y . Camsari, Barbara Chapman, Soumitra Chatterjee, Gebremedhin A. Dagnew, Aniello Esposito, Farah Fahim, Marco Fiorentino, Archit Gajjar, Abdullah Khalid, Xiangzhou Kong, Bohdan Kulchytskyy, Elica Kyoseva, Ruoyu Li, P. A...

work page 2025

[4] [3]

Davenport, Jessica R

James H. Davenport, Jessica R. Jones, and Matthew Thomason. A practical overview of quantum computing: Is exascale possible?, 2023

work page 2023

[5] [4]

Contextual subspace auxiliary-field quantum monte carlo: Improved bias with reduced quantum resources, 2024

Matthew Kiser, Matthias Beuerle, and Fedor Simkovic IV . Contextual subspace auxiliary-field quantum monte carlo: Improved bias with reduced quantum resources, 2024

work page 2024

[6] [5]

Quantum monte carlo on quantum computers. https://github.com/amazon-braket/ amazon-braket-examples/blob/feature/quantum-monte-carlo/examples/hybrid_quantum_ algorithms/Quantum_Monte_Carlo_Chemistry/Quantum_Monte_Carlo_Chemistry.ipynb

work page

[7] [6]

Hybrid classical-quantum simulation of maxcut using qaoa-in-qaoa

Aniello Esposito and Tamuz Danzig. Hybrid classical-quantum simulation of maxcut using qaoa-in-qaoa. In 2024 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW) , pages 1088–1094. IEEE, 2024

work page 2024

[8] [7]

Towards the munich quantum software stack: Enabling efficient access and tool support for quantum computers

Martin Schulz, Laura Schulz, Martin Ruefenacht, and Robert Wille. Towards the munich quantum software stack: Enabling efficient access and tool support for quantum computers. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE) , volume 2, pages 399–400. IEEE, 2023

work page 2023