Pith. sign in

REVIEW 4 major objections 5 minor 50 references

Q-AIM: A Unified Portable Workflow for Seamless Integration of Quantum Resources

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

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

Pith's one-line read The paper claims that one containerized microservice stack, Q-AIM, can serve as a portable, vendor-independent gateway to a quantum computer, running on a laptop, an on-premise server, or a cloud instance.

desk verdict A competent Dockerized prototype for exposing a Qiskit simulator as a protected quantum resource; portability is shown, but pulse-level and real-hardware integration are deferred, so the headline abstraction-level claim is unsupported. read the letter →

arxiv 2506.13436 v1 pith:S3OFDYRX submitted 2025-06-16 quant-ph

Zhaobin Zhu , Cedric Gaberle , Sarah M. Neuwirth , Thomas Lippert , Manpreet S. Jattana This is my paper · ORCID
classification quant-ph
keywords quantumcomputinghardwareintegrationcontainerizationmicroservicesAPIgatewayaccessmanagementasaservicevendorindependence
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 proposes Q-AIM, an open-source integration workflow that lets a research group connect its own quantum hardware to users through a single, portable access point. The claim is that one containerized microservice stack can expose a quantum resource at several abstraction levels, with role-based access control, while remaining light and vendor-independent enough to run on a personal computer, an on-premise server, or a small cloud instance. The paper supports this with a prototype deployed on all three hosting paradigms and measured to use under 3 GB of memory in its tested configuration. The motivation is that small academic groups buying quantum devices currently spend their own time building integration software, and a common open-source platform would remove that redundant work. The end-to-end demonstrations run against a circuit simulator rather than physical hardware, so the portability claims are validated for the software layer only.

What carries the argument

The load-bearing mechanism is the encapsulated, containerized microservice architecture centered on an API gateway. The gateway is a superset of a reverse proxy: it assigns ports, forwards requests, and enforces authentication, authorization, and access control before any request reaches a microservice. Behind it sit a database, an identity and access management service, an API application, a web frontend, a reverse proxy, and an optional monitoring service, each an independently replaceable container. The classical quantum-computing workflow is itself treated as a self-contained black-box component inside this stack, so users at different abstraction levels—from high-level circuit code down to hardware-near representations—interact only with the gateway. This structure is what lets the same image run unchanged on different hosting paradigms and lets administrators grant fine-grained access by role and group.

What would settle it

Attach a real quantum device (or a hardware emulator that accepts pulse-level commands) to the unmodified Q-AIM container and run the same workflows; if any part of the image, the API, or the authentication flow must be altered to reach the device, the portability and vendor-independence claims fail. A simpler check: attempt to submit a pulse-level program through the gateway today—the claimed abstraction range predicts such an endpoint should exist, and its absence would show the low-level access claim is not yet implemented.

Watch

Extended reading notes

Core claim

Q-AIM is a software framework intended to be the missing integration layer for small quantum computers: a single, open-source, containerized microservice stack that wraps the entire classical quantum-computing workflow (circuit definition, transpilation, job submission, result retrieval) as a black box and exposes it through one API gateway. The gateway is the only entry point; it terminates HTTPS, runs authentication and role-based authorization, and forwards requests to internal services that talk to the quantum resource. The paper claims this design is vendor-independent, portable across a personal laptop, an on-premise server, and a cloud instance, and light enough to run in under 3 GB of memory in the tested configuration. Access is granted at different abstraction levels through supported input formats (OpenQASM and a Pauli representation), with internal and external user groups receiving different roles and permissions. Because no real hardware was available, all end-to-end demonstrations run against a circuit simulator that stands in for the quantum endpoint.

Load-bearing premise

The whole portability and abstraction-level argument depends on the circuit simulator used for every end-to-end test behaving like a real quantum device in the ways that matter—interface, timing, and control demands—so the same container will work unchanged when physical hardware is attached.

Editorial extensions

If this is right

  • A group that deploys the Q-AIM image once can move from a laptop to a server or cloud instance by copying the image, with no per-environment changes.
  • Administrators can give internal and external users different roles, so a device can be opened to students or collaborators without exposing the supporting infrastructure.
  • Users can submit jobs as OpenQASM or as a Pauli representation and receive results and metadata through the same web interface, suggesting the abstraction-level promise is exercised at the circuit-representation level.
  • Because all services ship in one reproducible image, different institutions can share and redeploy the same tailored configuration, lowering the barrier to cross-institution collaboration.
  • The measured memory footprint below 3 GB indicates the framework itself is not the cost driver on small cloud instances, leaving room for larger simulator workloads.

Reading between the lines

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

  • The clearest next test is to connect the unmodified container to a physical quantum device; if that requires only a backend swap, the vendor-independence claim is confirmed, and if it requires driver-level changes, the claim needs revision. This test is not reported in the paper.
  • The prototype's supported inputs stop at circuit-level representations (OpenQASM and Pauli), so the advertised pulse-level interaction is presently a design goal rather than a demonstrated capability; building and testing a pulse-level endpoint would be the direct way to close that gap.
  • The role model of internal and external groups could be extended to federated access across institutions, so multiple universities could share one device using their own identity providers—an application the paper mentions only in passing.
  • Since the simulator backend hides hardware-specific latencies and failure modes, a realistic hardware test may also reveal that error handling and timeout behavior in the gateway need to be tuned; that is an empirical question the current evaluation cannot answer.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 Q-AIM, a Dockerized microservice framework intended to give research groups a portable, open-source way to expose and manage quantum computing hardware. The proposed architecture uses an API gateway, Keycloak-based authentication and role management, a FastAPI backend, an Angular frontend, and containerized services. A prototype implementing OpenQASM and Pauli-representation endpoints on top of Qiskit's QasmSimulator was deployed on a local machine, an on-premise cluster node, and a Google Cloud instance, and the paper reports a memory footprint below 3 GB. Based on these deployments, the authors claim that Q-AIM is lightweight, portable, customizable, and capable of integrating quantum resources at multiple abstraction levels, from algorithmic down to pulse-level access.

Significance. If the central claims were fully supported, Q-AIM would be a useful contribution for small academic groups that want to own and operate small quantum devices: the paper ships a concrete open-source artifact, demonstrates deployment on three distinct hosting paradigms, integrates standard identity management, and provides a reproducible Docker Compose setup. The deployment evidence and the cAdvisor-based resource measurement are genuine strengths. However, the current evaluation is narrowly scoped: all quantum endpoints are backed by a local simulator, no pulse-level or machine-instruction endpoint is implemented, and no performance, concurrency, or scaling measurements are reported. As it stands, the paper is best read as a prototype description with promising architecture, rather than a validated integration workflow for real quantum hardware.

major comments (4)
  1. [§5.4 (API), cf. §2.3 and §4.4] The central differentiator claimed in the introduction and Section 2.3 is low-level, pulse-level access to quantum hardware, described as 'the exact opposite' of higher-abstraction QCaaS offerings. However, the prototype in Section 5.4 exposes only four quantum endpoints, /api/qc/qasm/{upload, code} and /api/qc/pauli/{upload, code}, all served by Qiskit's QasmSimulator. No pulse-level, waveform, or machine-instruction endpoint is implemented or tested. The claim of providing access 'on different levels of abstraction' (abstract, Section 1 contributions) is therefore not supported by the presented prototype. The authors should either implement and test a low-level endpoint or explicitly rescope the claim to circuit/gate-level abstraction and describe pulse-level access as future work.
  2. [§5.4, §7 (Conclusion)] All end-to-end tests are performed against a Qiskit simulator, as stated in Section 5.4: 'Since real quantum hardware is not available for testing, the API utilizes simulators to query as endpoints instead.' Real backends introduce authentication mechanisms, calibration data, job queues, device-specific result formats, and hardware-specific IR constraints that the simulator path sidesteps. The conclusion explicitly defers 'the first real quantum computing device' to future work. Consequently, the headline claim of seamless integration of quantum resources is not yet demonstrated. A concrete improvement would be to validate the same endpoints against a remotely hosted Qiskit backend (e.g., IBM Quantum or a cloud-accessible simulator with device-like constraints) and to report what adaptations were required.
  3. [§6.1, §6.2 (Evaluation)] The evaluation demonstrates successful deployment on three hosts, but it does not quantify the portability or scalability claims. There are no end-to-end execution benchmarks, no comparison of results across the three environments, no concurrency or throughput measurements, and no stress tests. The statement in Section 6.2 that the setup 'can be scaled to more powerful instances, enabling it to handle more demanding workloads' is asserted rather than measured. The authors should add quantitative evaluation, for example request latency, throughput under concurrent users, and resource utilization across environments, or clearly label these claims as architectural expectations rather than validated results.
  4. [§6.2, Fig. 6] The lightweight claim rests on the observation that the container 'utilized less than 3 GB of memory in our configuration.' This is not sufficiently precise: it is unclear whether this is peak RSS, average memory, host-level memory including cAdvisor and all service containers, or only the Q-AIM application containers, and no time window or measurement method is given. Since memory footprint is a central contribution, the metric should be defined and reported in a reproducible way, ideally with a breakdown per microservice and a comparison against a baseline configuration.
minor comments (5)
  1. [Abstract and Introduction] The terms 'vendor-independent' and 'open-source' are used repeatedly, but the prototype depends on Qiskit for execution and on a specific Pauli-to-OpenQASM parser. Please clarify the intended scope: vendor-neutral API design versus vendor-neutral implementation.
  2. [§5.1, Listing 1] The paper alternates between describing 'the Q-AIM Docker image' and the multi-container Docker Compose deployment. Since portability is claimed for the image, please state explicitly which component is the portable unit (the compose project, the API image, or the entire stack) and how users are expected to redistribute it.
  3. [§5.3, Fig. 5] The screenshots in Figure 5 are too small to read in the PDF; the endpoint names, code editor contents, and result plots are not legible. Consider enlarging the figure or splitting it into subfigures for the different UI panels.
  4. [§6.2] The statement that 'the consistent behavior observed across different systems and settings underscores the portability' would be stronger if the paper reported what was actually compared, for example identical result objects or identical execution outputs, rather than only the fact that the stack started successfully.
  5. [References] Reference [41] is an unpublished thesis and is used to introduce the Pauli representation format. Since this format is a user-facing feature, please provide a citable, accessible description or repository link in the reference.

Circularity Check

0 steps flagged · score 0.0 of 10

No consequential circularity: the integration claims are validated by direct deployment tests and an external simulator backend, not derived from the paper's own outputs.

full rationale

Q-AIM is a software-engineering artifact rather than a formal derivation, so the circularity patterns for fitted predictions or imported uniqueness theorems do not apply. The central claims are that the Dockerized workflow is portable, lightweight, and customizable; these are supported by direct empirical deployment tests on three distinct hosting environments (local machine, on-premise server, and cloud instance) and by measured resource usage. No parameter is fitted to a subset of data and then renamed a prediction, and no equation or formal result is derived from the paper's own conclusions. The self-citations in the paper, references [41] and [42], define the Pauli representation and the parser library; these are internal input-format components that the authors supply, not external evidence invoked to justify the portability or integration claims, so they are not load-bearing in a circular way. The prototype endpoints use Qiskit's QasmSimulator because real quantum hardware is unavailable, and the paper explicitly defers real-device integration to future work; this is a limitation of validation scope, but it is not circularity because the simulator is an independent, external execution backend and the paper does not claim to have validated hardware integration. The conclusion that real hardware integration remains future work is consistent with the evidence presented. Therefore, the derivation chain, such as it is, is self-contained and no circular step is exhibited.

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

The central claim rests on two domain assumptions: Docker containers give identical behavior across hosts, and the simulator faithfully stands in for real device interaction. Neither is a free parameter; both are standard engineering assumptions that the paper does not independently justify beyond the three test deployments.

assumptions (2)
  • domain assumption Container virtualization provides consistent execution across heterogeneous hosts without modification.
    The portability claim in Section 6 assumes Docker's abstraction behaves identically on the three tested systems.
  • domain assumption The Qiskit simulator faithfully emulates the API interactions of real quantum hardware for the purposes of validating the integration workflow.
    Section 5.4 states real hardware was unavailable, so all end-to-end workflows were tested against a simulator.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Q-AIM: A Unified Portable Workflow for Seamless Integration of Quantum Resources." pith.science (2026). https://pith.science/paper/S3OFDYRX

@misc{pith2026250613436,
  author       = {Pith},
  title        = {Pith review of: Q-AIM: A Unified Portable Workflow for Seamless Integration of Quantum Resources},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/S3OFDYRX}},
  note         = {Machine review of arXiv:2506.13436}
}
read the original abstract

Quantum computing (QC) holds the potential to solve classically intractable problems. Although there has been significant progress towards the availability of quantum hardware, a software infrastructure to integrate them is still missing. We present Q-AIM (Quantum Access Infrastructure Management) to fill this gap. Q-AIM is a software framework unifying the access and management for quantum hardware in a vendor-independent and open-source fashion. Utilizing a dockerized micro-service architecture, we show Q-AIM's lightweight, portable, and customizable nature, capable of running on different hosting paradigms ranging from small personal computing devices to cloud servers and dedicated server infrastructure. Q-AIM exposes a single entry point into the host's infrastructure, providing secure and easy interaction with quantum computers on different levels of abstraction. With a minimal memory footprint, the container is optimized for deployment on even the smallest server instances, reducing costs and instantiation overhead while ensuring seamless scalability to accommodate increasing demands. Q-AIM intends to equip research groups and facilities purchasing and hosting their own quantum hardware with a tool simplifying the process from procurement to operation and removing non-research related technical redundancies.

Figures

Figures reproduced from arXiv: 2506.13436 by the authors.

Figure 1
Figure 1. Instruction abstraction levels in quantum computing. From high-level circuit design (highest [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Overview of the quantum computation workflow. The larger, red box (right) indicates classical [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Microservice-based architecture of Q-AIM. It facilitates secure client interactions via HTTPS and [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Representation of the first authentication process for an approved user attempting to run code on [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Q-AIM Web User Interface. Users can provide code and runtime parameters in different formats, [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Grafana-based Monitoring Dashboard visualizing memory and CPU usage, as well as network traffic [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 43 canonical work pages

  1. [1]

    Quantum cryptography,

    N. Gisin, G. Ribordy, W. Tittel, and H. Zbinden, “Quantum cryptography,”Rev. Mod. Phys., vol. 74, pp. 145–195, Mar 2002. [Online]. Available: https://link.aps.org/doi/10.1103/RevModPhys.74.145

    doi:10.1103/revmodphys.74.145 2002

  2. [2]

    Advances in quantum cryptography,

    S. Pirandola, U. L. Andersen, L. Banchi, M. Berta, D. Bunandar, R. Colbeck, D. Englund, T. Gehring, C. Lupo, C. Ottaviani, J. L. Pereira, M. Razavi, J. S. Shaari, M. Tomamichel, V. C. Usenko, G. Vallone, P. Villoresi, and P. Wallden, “Advances in quantum cryptography,” 15 Adv. Opt. Photon., vol. 12, no. 4, pp. 1012–1236, Dec 2020. [Online]. Available: htt...

    work page 2020

  3. [3]

    Quantum algorithms for quantum chemistry and quantum materials science,

    B. Bauer, S. Bravyi, M. Motta, and G. K.-L. Chan, “Quantum algorithms for quantum chemistry and quantum materials science,”Chemical Reviews, vol. 120, no. 22, p. 12685–12717, Oct 2020

    work page 2020

  4. [4]

    Industry quantum computing applications,

    Quantum Technology and Application Consortium – QUTAC, Bayerstadler, Andreas, Becquin, Guillaume, Binder, Julia, Botter, Thierry, Ehm, Hans, Ehmer, Thomas, Erdmann, Marvin, Gaus, Norbert, Harbach, Philipp, Hess, Maximilian, Klepsch, Johannes, Leib, Martin, Luber, Sebastian, Luckow, Andre, Mansky, Maximilian, Mauerer, Wolfgang, Neukart, Florian, Niedermeie...

    2021

  5. [5]

    Build utility-scale quantum applications with the updated open plan and ibm quantum credits,

    M. Facchini and S. Thoß, “Build utility-scale quantum applications with the updated open plan and ibm quantum credits,” 2023, accessed: 2024-11-27. [Online]. Available: https: //www.ibm.com/quantum/blog/utility-scale-quantum-credits

    work page 2023

  6. [6]

    Expanding access to quantum today for a better tomorrow,

    K. Kissell and N. DeSantis, “Expanding access to quantum today for a better tomorrow,” 2021, accessed: 2024-11-27. [Online]. Available: https://cloud.google.com/blog/products/compute/ ionq-quantum-computer-available-through-google-cloud?hl=en

    work page 2021

  7. [7]

    Amazon braket pricing,

    A. W. S. I. or its affiliates, “Amazon braket pricing,” 2024, accessed: 2024-11-27. [Online]. Available: https://aws.amazon.com/braket/pricing/

    work page 2024

  8. [8]

    Docker: Open platform for developing, shipping, and running applications,

    D. Inc., “Docker: Open platform for developing, shipping, and running applications,” https://www. docker.com, 2025, accessed: 2025-02-07

    work page 2025

Show all 50 references
  1. [9]

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

    R. Wille, R. Van Meter, and Y. Naveh, “Ibm’s qiskit tool chain: Working with and developing for real quantum computers,” in2019 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2019, pp. 1234–1240

    2019

  2. [10]

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

    V. Omole, A. Tyagi, C. Carey, A. Hanus, A. Hancock, A. Garcia, and J. Shedenhelm, “Cirq: A python framework for creating, editing, and invoking quantum circuits,”0 0, 2020

    2020

  3. [11]

    Quantum software as a service through a quantum api gateway,

    J. Garcia-Alonso, J. Rojo, D. Valencia, E. Moguel, J. Berrocal, and J. M. Murillo, “Quantum software as a service through a quantum api gateway,”IEEE Internet Computing, vol. 26, no. 1, pp. 34–41, 2022

    2022

  4. [12]

    Review of intermediate representations for quantum computing,

    F. J. Cardama, J. Vázquez-Pérez, C. Piñeiro, J. C. Pichel, T. F. Pena, and A. Gómez, “Review of intermediate representations for quantum computing,”The Journal of Supercomputing, vol. 81, no. 2, Jan 2025

    2025

  5. [13]

    Distributed quantum computing: A survey,

    M. Caleffi, M. Amoretti, D. Ferrari, J. Illiano, A. Manzalini, and A. S. Cacciapuoti, “Distributed quantum computing: A survey,”Computer Networks, vol. 254, p. 110672, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1389128624005048

    2024

  6. [14]

    Berkeley quantum synthesis toolkit (bqskit) v1,

    E. Younis, C. C. Iancu, W. Lavrijsen, M. Davis, E. Smith, and USDOE, “Berkeley quantum synthesis toolkit (bqskit) v1,” 04 2021. [Online]. Available: https://www.osti.gov/biblio/1785933

    2021

  7. [15]

    Automating the comparison of quantum compilers for quantum circuits,

    M. Salm, J. Barzen, F. Leymann, B. Weder, and K. Wild, “Automating the comparison of quantum compilers for quantum circuits,” inService-Oriented Computing, J. Barzen, Ed. Cham: Springer International Publishing, 2021, pp. 64–80

    2021

  8. [16]

    Open quantum assembly language,

    A. W. Cross, L. S. Bishop, J. A. Smolin, and J. M. Gambetta, “Open quantum assembly language,” 2017

    2017

  9. [17]

    Openqasm 3: A broader and deeper quantum assembly language,

    A. Cross, A. Javadi-Abhari, T. Alexander, N. De Beaudrap, L. S. Bishop, S. Heidel, C. A. Ryan, P. Sivarajah, J. Smolin, J. M. Gambetta, and B. R. Johnson, “Openqasm 3: A broader and deeper quantum assembly language,”ACM Transactions on Quantum Computing, vol. 3, no. 3, sep 202...

    2022 doi

  10. [18]

    Accelerating hpc with quantum com- puting: It is a software challenge too,

    M. Schulz, M. Ruefenacht, D. Kranzlmüller, and L. B. Schulz, “Accelerating hpc with quantum com- puting: It is a software challenge too,”Computing in Science & Engineering, vol. 24, no. 4, pp. 60–64, 2022

    2022

  11. [19]

    Bringing quantum acceleration to supercomputers,

    M. Ruefenacht, B. G. Taketani, P. Lähteenmäki, V. Bergholm, D. Kranzlmüller, L. Schulz, and M. Schulz, “Bringing quantum acceleration to supercomputers,”IQM/LRZ Technical Report, https://www. quantu m. lrz. de/fileadmin/QIC/Downloads/IQM HPC-QC-Integration-White paper. pdf, 2022

    2022

  12. [20]

    Quantum com- puters for high-performance computing,

    T. S. Humble, A. McCaskey, D. I. Lyakh, M. Gowrishankar, A. Frisch, and T. Monz, “Quantum com- puters for high-performance computing,”IEEE Micro, vol. 41, no. 5, pp. 15–23, 2021

    2021

  13. [21]

    Toward a quantum-science gateway: A hybrid reference architecture facilitating quantum computing capabilities for cloud utilization,

    A. C. Marosi, A. Farkas, T. Máray, and R. Lovas, “Toward a quantum-science gateway: A hybrid reference architecture facilitating quantum computing capabilities for cloud utilization,”IEEE Access, vol. 11, pp. 143913–143924, 2023

    2023

  14. [22]

    Cloud quantum computing concept and development: A systematic literature review,

    H. Soeparno and A. S. Perbangsa, “Cloud quantum computing concept and development: A systematic literature review,”Procedia Computer Science, vol. 179, pp. 944–954, 2021, 5th International Conference on Computer Science and Computational Intelligence 2020. [Online]. Available:...

    2021

  15. [23]

    Quantum cloud computing: Trends and challenges,

    M. Golec, E. S. Hatay, M. Golec, M. Uyar, M. Golec, and S. S. Gill, “Quantum cloud computing: Trends and challenges,”Journal of Economy and Technology, vol. 2, pp. 190–199, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S2949948824000271

    2024

  16. [24]

    Technolog- ical diversity of quantum computing providers: a comparative study and a proposal for api gateway integration,

    J. Alvarado-Valiente, J. Romero-Álvarez, E. Moguel, J. García-Alonso, and J. M. Murillo, “Technolog- ical diversity of quantum computing providers: a comparative study and a proposal for api gateway integration,”Software Quality Journal, vol. 32, pp. 53–73, 2024

    2024

  17. [25]

    Quantum computing with qiskit,

    A. Javadi-Abhari, M. Treinish, K. Krsulich, C. J. Wood, J. Lishman, J. Gacon, S. Martiel, P. D. Nation, L. S. Bishop, A. W. Cross, B. R. Johnson, and J. M. Gambetta, “Quantum computing with qiskit,” 2024. [Online]. Available: https://arxiv.org/abs/2405.08810

    2024 arXiv

  18. [26]

    Quantum service-oriented computing: current landscape and challenges,

    E. Moguel, J. Rojo, and D. e. a. Valencia, “Quantum service-oriented computing: current landscape and challenges,”Software Quality Journal, vol. 30, pp. 983–1002, 2022

    2022

  19. [27]

    Qfaas: A serverless function-as-a-service framework for quantum computing,

    H. T. Nguyen, M. Usman, and R. Buyya, “Qfaas: A serverless function-as-a-service framework for quantum computing,”Future Generation Computer Systems, vol. 154, pp. 281–300, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167739X24000189

    2024

  20. [28]

    A serverless cloud integration for quantum computing,

    M. Grossi, L. Crippa, A. Aita, G. Bartoli, V. Sammarco, E. Picca, N. Said, F. Tramonto, and F. Mattei, “A serverless cloud integration for quantum computing,” 2021. [Online]. Available: https://arxiv.org/abs/2107.02007

    2021 arXiv

  21. [29]

    Integrating quantum computing resources into scientific hpc ecosystems,

    T. Beck, A. Baroni, R. Bennink, G. Buchs, E. A. C. Pérez, M. Eisenbach, R. F. da Silva, M. G. Meena, K. Gottiparthi, P. Groszkowski, T. S. Humble, R. Landfield, K. Maheshwari, S. Oral, M. A. Sandoval, A. Shehata, I.-S. Suh, and C. Zimmer, “Integrating quantum computing resourc...

    2024

  22. [30]

    Docker: lightweight linux containers for consistent development and deployment,

    D. Merkel, “Docker: lightweight linux containers for consistent development and deployment,”Linux journal, vol. 2014, no. 239, p. 2, 2014

    2014

  23. [31]

    hpcng/singularity: Singularity 3.7. 1,

    G. M. Kurtzer, M. Bauer, I. Kaneshiro, D. Trudgian, D. Godlove, Y. Cote, C. E. Arango Gutierrez, G. Vallee, A. Hughes, J. Cooket al., “hpcng/singularity: Singularity 3.7. 1,”Zenodo, 2021

    2021

  24. [32]

    Containers for computational reproducibility,

    D. Moreau, K. Wiebels, and C. Boettiger, “Containers for computational reproducibility,”Nature Re- views Methods Primers, vol. 3, no. 1, p. 50, 2023. 17

    2023

  25. [33]

    Rfc 4511: Lightweight directory access protocol (ldap): The protocol,

    J. Sermersheim, “Rfc 4511: Lightweight directory access protocol (ldap): The protocol,” 2006

    2006

  26. [34]

    Official postgresql docker image,

    P. Community, “Official postgresql docker image,” 2025, accessed: 2025-01-29. [Online]. Available: https://hub.docker.com/_/postgres

    2025

  27. [35]

    Keycloak docker image,

    K. Community, “Keycloak docker image,” 2025, accessed: 2025-01-29. [Online]. Available: https://hub.docker.com/r/keycloak/keycloak

    2025

  28. [36]

    Fastapi,

    S. Ramírez, “Fastapi,” 2018, accessed: 2025-01-28. [Online]. Available: https://github.com/fastapi/ fastapi

    2018

  29. [37]

    Angular - the modern web framework,

    A. Team, “Angular - the modern web framework,” 2025, accessed: 2025-01-29. [Online]. Available: https://angular.io/

    2025

  30. [38]

    Cantelon, M

    M. Cantelon, M. Harter, T. Holowaychuk, and N. Rajlich,Node.js in Action. Manning Greenwich, 2014

    2014

  31. [39]

    Nginx: The high-performance web server and reverse proxy,

    W. Reese, “Nginx: The high-performance web server and reverse proxy,”Linux Journal, vol. 2008, no. 173, p. 2, 2008

    2008

  32. [40]

    cadvisor docker image,

    Google, “cadvisor docker image,” 2025, accessed: 2025-01-29. [Online]. Available: https: //hub.docker.com/r/google/cadvisor

    2025

  33. [41]

    Design and implementation of a quantum circuit preparation algorithm,

    C. Gaberle, “Design and implementation of a quantum circuit preparation algorithm,” 2023, unpublished thesis, Goethe University Frankfurt

    2023

  34. [42]

    Qasmparserlibrary,

    ——, “Qasmparserlibrary,” 2023, accessed: 2025-01-28. [Online]. Available: https://github.com/ msqc-goethe/QasmParserLibrary

    2023

  35. [43]

    Improved variational quantum eigensolver via quasidynamical evolution,

    M. S. Jattana, F. Jin, H. De Raedt, and K. Michielsen, “Improved variational quantum eigensolver via quasidynamical evolution,”Phys. Rev. Appl., vol. 19, p. 024047, Feb 2023. [Online]. Available: https://link.aps.org/doi/10.1103/PhysRevApplied.19.024047

    2023 doi

  36. [44]

    A variational eigenvalue solver on a quantum processor,

    A. Peruzzo, J. McClean, P. Shadbolt, M.-H. Yung, X.-Q. Zhou, P. J. Love, A. Aspuru-Guzik, and J. L. O’Brien, “A variational eigenvalue solver on a quantum processor,”Nature Communications, vol. 5, p. 4213, 2014

    2014

  37. [45]

    Assessment of the variational quantum eigensolver: Application to the heisenberg model,

    M. S. Jattana, F. Jin, H. De Raedt, and K. Michielsen, “Assessment of the variational quantum eigensolver: Application to the heisenberg model,”Frontiers in Physics, vol. 10, 2022. [Online]. Available: https://www.frontiersin.org/journals/physics/articles/10.3389/fphy.2022.907160

    2022

  38. [46]

    Qiskit aer QasmSimulator backend,

    Qiskit Development Team, “Qiskit aer QasmSimulator backend,” https://qiskit.github.io/qiskit-aer/ stubs/qiskit_aer.QasmSimulator.html, 2025, accessed: 2025-02-10

    2025

  39. [47]

    Google cloud compute vm instance pricing,

    G. Cloud, “Google cloud compute vm instance pricing,” 2025, accessed: 2025-01-29. [Online]. Available: https://cloud.google.com/compute/vm-instance-pricing

    2025

  40. [48]

    General error mitigation for quantum circuits,

    M. S. Jattana, F. Jin, H. De Raedt, and K. Michielsen, “General error mitigation for quantum circuits,”Quantum Information Processing, vol. 19, no. 11, p. 414, 2020. [Online]. Available: https://doi.org/10.1007/s11128-020-02913-0

    2020 doi

  41. [49]

    Scalablegeneral error mitigation for quantum circuits,

    P.Döbler, J.Pflieger, F.Jin, H.D.Raedt, K.Michielsen, T.Lippert, andM.S.Jattana, “Scalablegeneral error mitigation for quantum circuits,” 2024. [Online]. Available: https://arxiv.org/abs/2411.07916

    2024 arXiv

  42. [50]

    Quantum annealer accelerates the variational quantum eigensolver in a triple- hybrid algorithm,

    M. S. Jattana, “Quantum annealer accelerates the variational quantum eigensolver in a triple- hybrid algorithm,”Physica Scripta, vol. 99, no. 9, p. 095117, aug 2024. [Online]. Available: https://dx.doi.org/10.1088/1402-4896/ad6aea 18

    2024 doi

Pith tools

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