iQuantum: A toolkit for modeling and simulation of quantum computing environments

Quantum computing resources are predominantly accessible through cloud services, with a potential future shift to edge networks. This paradigm and the increasing global interest in quantum computing have amplified the need for efficient, adaptable resource management strategies and service models for quantum systems. However, many limitations in the quantum resources' quantity, quality, availability, and cost pose significant challenges for conducting research in practical environments. To address these challenges, we proposed iQuantum, a holistic and lightweight discrete‐event simulation toolkit uniquely tailored to model hybrid quantum computing environments. We also present a detailed system model for prototyping and problem formulation in quantum resource management. Through rigorous empirical validation and evaluations using large‐scale quantum workload datasets, we demonstrate the flexibility and applicability of our toolkit in various use cases. iQuantum provides a versatile environment for designing and evaluating quantum resource management policies such as quantum task scheduling, backend selection, hybrid task offloading, and orchestration in the quantum cloud‐edge continuum. Our work endeavors to create substantial contributions to quantum computing modeling and simulation, empowering the creation of future resource management strategies and quantum computing's broader applications.


INTRODUCTION
5][6] The emergence of the cloud-based quantum computing 7,8 and quantum computing-as-a-service (QCaaS) 9 models has enabled access to F I G U R E 1 Overview of hybrid quantum computing paradigm envisions the seamless integration of quantum and classical computation resources across different cloud and emerging edge layers, with edge resources being geographically closer to end-users (data sources), albeit with computational limitations compared to their cloud counterparts.
quantum computation resources without a massive upfront investment in quantum hardware, leading to tremendous progress in quantum software and algorithm fronts. 10Major cloud providers, such as Microsoft Azure, 11 AWS, 12 and IBM, 13 now offer cloud-based access to their quantum computing services.Moreover, quantum computation resources are predicted to be extended to the edge network 14,15 when quantum hardware becomes popular in the future, envisioning the emergence of the hybrid paradigm of quantum cloud-edge continuum, 16 whose main components are illustrated in Figure 1.
The future quantum computing paradigm is anticipated to incorporate heterogeneous quantum and classical computing entities situated in different layers, including the cloud and the fog/edge layer.The main differences between cloud-based resources and edge-based resources include the computation capacity, mobility, and geographical distance to the data source or users. 17Each layer comprises different computation resources and intermediary components, such as gateways and brokers for resource management and orchestration.If edge computation resources are insufficient for executing incoming tasks, these tasks can be migrated or offloaded to the upper cloud layer with more powerful capacity. 18,19It is important to highlight that this is the vision for the future expansion of quantum computing, whereas most available quantum resources are only accessible through the cloud due to the limitation in quantity, quality, and cost of current quantum hardware. 20s the demand for quantum computing services continues to rise rapidly, it triggers the inevitable requirement for efficient system design and resource management strategies to maximize the benefits of available quantum resources. 21owever, there are several challenges to designing and evaluating system and resource orchestration policies in practical environments. 22First, access to physical quantum computers is limited and costly.Although vendors such as IBM Quantum offer free access to several quantum computers to the public, these devices are on a small scale, comprising only a few qubits.In addition, completing a cloud-based quantum task can take anywhere from seconds to hours because of the fair-share policy that is in place for sharing limited resources among a large number of users worldwide. 21This means that some tasks may have to wait for others to finish before they can be executed in a real quantum computer.On the other hand, the pricing model for commercial quantum computing services is still expensive.This is because of the limitations and operating costs associated with the current quantum hardware available.For example, the IBM Quantum Pay-As-You-Go plan charges up to 1.6 USD for every second of quantum execution (as of August 2023).Furthermore, it's important to note that quantum hardware is still in the Noisy Intermediate-Scale Quantum (NISQ) era, 20 which implies the limitation in the quality and quantity of qubits inside the quantum chips.These challenges hinder large-scale evaluation and experimental validation of resource management strategies.As a result, it's crucial to have a simulation framework that can model hybrid quantum computing environments to aid in the design and evaluation of resource orchestration policies.
Over the last decade, simulation toolkits such as CloudSim 23 have gained popularity for modeling cloud environments and supporting resource management research.Moreover, several simulators have been proposed for hybrid cloud-edge and fog/edge environments, including EdgeCloudSim, 24 FogNetSim, 25 iFogSim, 26 EdgeSimPy. 27These simulation toolkits play a significant role in the development of enormous resource management policies for cloud and edge computing environments.However, as far as we know, none of the existing cloud-edge simulators supports the modeling of quantum computing systems and workloads.Meanwhile, existing quantum simulators mainly focus on emulating quantum physical operations of quantum computers, and do not offer comprehensive support for modeling quantum cloud-edge computing environments.As these quantum simulators use classical resources to mimic the actual quantum execution, they can quickly reach the limitation of classical hardware and can usually support up to tens to hundreds of qubits. 28Besides, several quantum simulators focus on quantum communications, which support modeling quantum network protocols. 29,30While quantum networks represent a promising direction for the future of quantum computing, 31 it is important to highlight that quantum systems can still utilize classical drivers and networks to handle user requests and facilitate cooperation between quantum and classical computation.Ultimately, the lack of a modeling and simulation framework for quantum computing environments poses significant challenges for research in quantum system design and resource management, impeding researchers from effectively testing their system designs or task scheduling algorithms for hybrid quantum computing systems.Furthermore, it also complicates reproducing experimental results or comparing the performance of different algorithms or applications since no standard simulator is available.
To tackle these challenges, we propose iQuantum, a versatile and lightweight simulation framework designed to model quantum computing environments to facilitate quantum software and system research, focusing on resource management and orchestration.The main approach of our toolkit is simplifying and modeling the environments with resources that are quantum systems with key metrics such as number of qubits, quantum volume, quantum processor speed, 32 native gate sets, and qubit topology.Similarly, we extract the features of quantum circuits to model as workload entities in the environments.Then, we employ the discrete-event simulation method, which is a popular simulation technique for operations research. 33We leverage the core engine and classical components of the latest version of CloudSim 23 to extend and adapt to the quantum computing environment, expanding from the cloud layer to edge layers with various potential use cases.Our toolkit can pave the way for the development of a quantum environment modeling and simulation, which empowers researchers to prototype, design, and evaluate their system design and policies in a simulated quantum computing environment, eliminating the need for costly access to practical quantum resources.Moreover, it enhances research and experimentation in quantum software and systems, enabling result comparison and experiment replication for more robust and impactful investigations aligned with the latest advances in quantum computing.
Our earlier study 14 introduced the initial ideas and proof-of-concept design for the creation of iQuantum, mainly focusing on cloud-based quantum environments.In this paper, we thoroughly extend the architecture design, system model, and implementation of iQuantum along with extensive empirical evaluation to demonstrate the effectiveness of iQuantum for modeling and simulation of quantum computing environments in the cloud-edge continuum.The major contributions of our extended study are as follows: 1. We present a comprehensive system model for quantum computing environments using key metrics and features of available quantum computers and quantum task execution.Besides, we also propose various models and simulation logic for different use cases in hybrid quantum resource management and orchestration.These models serve as theoretical references for prototyping and problem formulation in system design and resource management for hybrid quantum computing.2. We design the architecture of iQuantum based on the discrete-event simulation approach of CloudSim and extensively extend the entire implementation of iQuantum to enhance the flexibility and support all proposed resource management use cases, including task scheduling, backend selection, hybrid task orchestration, and task offloading between edge and cloud layer.3. We validate and evaluate iQuantum in different scenarios using trustworthy datasets, including IBM Quantum 13 calibration data for quantum systems and the MQT Bench dataset 34 for the workload.Our findings demonstrate that iQuantum is a versatile and efficient tool that holds great potential to support the development and evaluation of policies related to various resource management issues.4. We discuss the lesson learned throughout the development of the iQuantum simulator, which can bring valuable insights for developing and extending quantum computing environment modeling and simulation frameworks in the future.
Besides, as an open-source toolkit, iQuantum is designed to enhance and collaborate with other tools in the quantum software ecosystem, specifically in the areas of quantum environment modeling and simulation.This area is inevitably essential for the advancement of quantum resource management policies, along with the rapid maturation of quantum hardware and software.
The rest of this paper is structured as follows: Section 2 reviews related work and identifies gaps in the literature.Section 3 outlines the system model for the quantum computing environment.Section 4 proposes the architecture design and implementation of iQuantum.Section 5 presents different models for various use cases of iQuantum in resource management and orchestration problems.Section 6 shows an explanatory example, sample workflow operation of iQuantum, and performance evaluations from various scenarios and workload datasets.Section 7 discusses the lessons learned from developing iQuantum.Finally, Section 8 concludes the study and suggests future directions.In the classical computing domain, modeling and simulation tools such as CloudSim 23 have become popular for their capability to facilitate the development and evaluation of resource management policies.

RELATED WORK
In the rapidly evolving era of the Internet of Things (IoT), 35 paradigms such as edge and fog computing are gaining prominence. 36,37Although CloudSim, the predecessor of iQuantum, facilitates various simulation models for cloud computing-based use cases, it cannot be directly used for modeling edge/fog environments.As a result, new simulation toolkits are proposed to adapt to these kinds of computing paradigms.Mahmud et al. 26 proposed iFogSim2, which extends the first version of iFogSim 38 to support mobility, clustering, and microservices management policies in fog and edge computing.Similarly, Souza et al. 27 propose EdgeSimPy, which employs an agent-based modeling technique to represent each entity in the edge environment as an agent that has its own behavior, decision-making capabilities, and interactions with other agents and the environment.Additionally, IoT applications in emerging domains like blockchain IoT (B-IoT) 39 and medical applications 40 present a new frontier.Blockchain IoT integration offers enhanced security and efficiency in IoT scenarios.This integration is particularly significant in applications where blockchain's decentralized and immutable nature can strengthen data integrity and trust in distributed IoT networks.Simulators such as ChainFL 41 and xFogSim, 42 can be adapted to simulate such scenarios, providing valuable insights into the resource management challenges and opportunities inherent in B-IoT systems.Conversely, the key characteristic of the modeling toolkit is capturing the behaviors of the actual entities and modeling them as an object or agents, then simulating the actual interactions among different entities through events.However, there is no existing cloud/edge simulator support modeling quantum computing resources and workloads.
In terms of quantum computing simulation, it is important to highlight that there are numerous quantum simulators, but they are mostly focused on simulating the physical quantum operation, which mimics the real quantum systems and can be categorized as "emulation".However, none of the existing quantum simulation toolkits support modeling the environments and resource management problems, which can be categorized as "simulation", similar to other modeling toolkits in the classical realm. 23ndustry-standard quantum simulators, such as IBM's quantum simulator integrated with Qiskit 46 and Google's quantum simulator employed with Cirq, 47 are renowned for their robustness in simulating quantum circuit operations.However, iQuantum distinguishes itself from these simulators in several key aspects.First, while IBM and Google's simulators primarily concentrate on the physical aspects of quantum computation, iQuantum mainly focuses on modeling quantum computing environments, facilitating research in resource management problems.This approach is similar to other well-known simulators in the classical domain, such as CloudSim, 23 iFogSim, 26 and EdgeSimPy. 27Second, iQuantum is designed as a lightweight, discrete-event simulation framework, making it more accessible and easier to model and simulate the large-scale environment with heterogeneous quantum (and classical) instances.This contrasts with the more resource-intensive nature of several industry simulators, which may require more computational overhead 22 when employed to design and evaluate resource management algorithms.Additionally, iQuantum is designed with an interoperability approach, enabling it to leverage the modeling of circuit and quantum computation features extracted from these established simulators.Indeed, we can extract attributes of quantum circuits from benchmark datasets (such as MQT Bench 34 ) using Qiskit and use IBM's benchmark data on quantum volume and circuit layer operation per second (CLOPS) 32 of quantum systems to model quantum computing environments in iQuantum (see Section 7).
Apart from the built-in quantum simulators of common quantum SDKs such as Qiskit, Cirq, Braket, and Q#, several works have proposed simulation frameworks for quantum operation and communications.Regarding quantum networks, Diadamo et al. 29 proposed QuNetSim as a framework for simulating different quantum network protocols, such as quantum key distribution and quantum routing.As QuNetSim relies on other qubit simulators (such as SimulaQron, 48 ProjectQ, 49 and QuTiP 50 ), its main objective is to develop quantum network protocol simulation rather than distributed quantum system modeling.Similarly, NetSquid 30 is a discrete-event network simulator for simulating quantum network protocols and systems.Although quantum communications is certainly an important prospect of the future implication of quantum technology, it is still in its infancy and requires more research effort to develop standard protocols and methods.In practice, current quantum computing services can still leverage the classical driver counterpart and network communication for quantum execution.Therefore, our focus in iQuantum is to reflect the current nature of the quantum computing environment in consensus with classical resources.
Besides, several simulators for quantum operation have been proposed recently.Jones et al. proposed QuEST 43 to support simulating the behavior of quantum systems with high performance.Similarly, Bian et al. 44 proposed PAS as a lightweight quantum simulator, and the authors argued that PAS outperforms QuEST in terms of quantum operation simulation.QXTools 45 is another Julia-based toolkit for simulating large-scale quantum circuits using the tensor network approach, which can be executed on a distributed computation cluster.However, as the main focus of these simulators is quantum operation, modeling and simulation toolkits for quantum systems and workloads are needed to facilitate the design of resource management policies.
In terms of modeling and simulation tools for quantum computing environments, especially for facilitating the design and evaluation of quantum resource management policies, iQuantum can be considered as one of the first-of-its-kind toolkits.As iQuantum is built on top of CloudSim, 23 which is one of the most widely-used simulators over the last decade for cloud computing environments, our toolkit can leverage the capabilities of CloudSim to expand its support to classical resource modeling in the cloud and extend to the edge network.Eventually, iQuantum serves as the unified toolkit for supporting the hybrid quantum-classical computing paradigm in the edge-cloud continuum, which enhances the seamlessly and simplicity of employing different frameworks and paves a new way for research in system design and resource management for various scenarios, such as quantum computing and hybrid quantum-classical computing environments.Although simulators can have their limitations compared to practical environments (such as the QFaaS framework 22 for practical quantum environments), by capturing the timing and interactions of events, modeling and simulation toolkits provide valuable insights into the performance resource utilization and scalability of the overall systems.
iQuantum also offers other advantages that distinguish it from existing toolkits.For instance, it provides support for external datasets, accommodating both OpenQASM files for quantum tasks and quantum computer calibration data for quantum systems.Our toolkit also facilitates data importing and exporting in a common CSV format, enabling further investigation and analysis.The modular architecture of iQuantum allows for easy extension and customization to support various use cases.Furthermore, iQuantum can be seamlessly integrated with common quantum SDKs like Qiskit, 46 enabling workload feature extraction and dataset generation.For users seeking more advanced resource management techniques, iQuantum's compatibility with Python-Java brokers, such as Py4J, * allows for straightforward integration of machine learning-based policies.Ultimately, these features collectively position iQuantum as a powerful and flexible toolkit for modeling and simulation in hybrid quantum computing environments.

SYSTEM MODEL FOR QUANTUM ENVIRONMENTS
This section outlines the system model of key entities in the quantum computing environments, including quantum processing units (QPUs), quantum nodes, and quantum tasks.Figure 2 illustrates these entities and main attributes, which are described in detail below.

3.1
QPUs and quantum computation nodes

Quantum processing units
The computational unit of a physical quantum system (or quantum node-QNode) is a quantum chip (or quantum processing unit-QPU).
A QPU q i of QNode  can be defined as follows: where: 1. q w is the number of qubits (or width), which implies the scale of the QPU.The more number of qubits, the more quantum information a QPU can process.2. q v is the quantum volume (QV) of the QPU, which indicates the quality of qubits and the QPU's capability to execute a quantum circuit precisely.Cross et al. 51 proposed the measurement of QV as follows: where d and m are the depth and width of the largest square circuit that can be faithfully executed.The higher the value of QV, the higher the possibility of getting a precise execution result.

F I G U R E 2
Overview of the system model and key attributes of entities in quantum computing environments.
3. q s is the number of circuit layers that can be processed per second (CLOPS), 32 which indicates the speed of the QPU for processing quantum circuits.CLOPS can be empirically measured by where M = 100, K = 10, S = 100, D = log 2 q v , which stands for the number of evaluated templates, number of parameter updates, number of shots, and number of QV layers, respectively.The higher the CLOPS, the faster the QPU can operate.4. q g indicates a list of all supported single-qubit and multiple-qubit quantum gates of the QPU.For example, most available IBM Quantum chips from 5 to 65 qubits support five native gate sets, including CNOT, ID, RZ, SX, and X gate, where their most recent 127-qubit and 433-qubit chips (Eagle r3 and Osprey r1) replace the support of CNOT gate with ECR gate. 5. q t represents the qubit topology (or connectivity) of all qubits in the QPU, which can be modeled by a graph q t = (, ), where  = {v i |1 ≤ i ≤ ||}, || = q w depicts the number of qubits and v i denotes the i-th qubit;  = {c i,j |v i , v j ∈ , i ≠ j} denotes the connection of two qubits, where c i,j denotes the connection between qubit v i and qubit v j .6. q e represents a list of all error rates of the QPU, which can be defined as q e = ( v ,  g ), where denotes the list of all qubit error, and e v i depicts the readout assignment error of i-th qubit;  g = {e g k |1 ≤ k ≤ |q g |} denotes the list of all quantum gate errors and e g k depicts the readout assignment error of k-th quantum gate.The errors of the two-qubit gate (CNOT and ECR gate) contain all errors between each pair of two qubits in the QPU.The error rates model can be useful in assisting the development of solutions for more complex resource management problems that take into account the quality of qubits and the quantum volume.However, it is important to note that supporting the evaluation of the quantum errors impacts on quantum execution results is not within the scope of our study and can be considered for future extension.
Besides, other calibration metrics of each qubit can be modeled to reflect the comprehensive properties of a QPU, such as T1 time, T2 time, frequency, and anharmonicity.It is worth noting that although we support modeling all of these features in the implementation of iQuantum, the complex resource management policies considering all error rates and all calibration data of each qubit in the QPU are out of scope in this study, which inspire the further contribution of other practitioner and researchers in the field of quantum computing systems and quantum error mitigation.

Quantum nodes
A quantum computation node (QNode ) can be modeled as follows: where n is the number of QPUs and  s is the local task scheduling of the quantum node.Presently, most available quantum computer from well-known vendors such as IBM Quantum, Rigetti, and IonQ only has single-chip quantum nodes.However, the proposal for multi-chip quantum nodes such as IBM Quantum System Two † are expected to be released in the near future.According to the current situation and potential development of quantum hardware, iQuantum supports both single-QPU (n = 1) and multi-QPU (n ≥ 1) QNode models.Besides, users can design the scheduling policy  s to determine the execution model of multiple incoming quantum tasks inside the quantum node.More details and examples of scheduling policies can be found in Section 5.1.

3.2
Quantum datacenters and brokers

Quantum datacenters
A cluster or centralized hub of multiple quantum nodes at the same location can be defined as a quantum datacenter (  ) as follows: where || is the number of QNodes,  is the cost model of using quantum computation resources, and  is the location of the quantum datacenter.Different quantum cloud providers have different cost models for using their quantum computing services.For example, IBM Quantum offers a Pay-As-You-Go plan through IBM Cloud with a fixed price of using 27-to 127-qubit quantum computers at 1.6 USD per second of quantum runtime, ‡ whereas Amazon Braket 12 calculates the total cost  i of executing i-th quantum task  i at quantum computer q by  i =  t q +  s i ×  s q , where  t q is the cost per task,  s q is cost per shots † IBM Quantum System Two ‡ https://www.ibm.com/quantum/access-plans. of quantum node q, and  s i is the number of shots that quantum task  i need to be executed.Additionally, different quantum computers offered by Amazon Braket have different per-task and per-shot prices.Therefore, users can customize the pricing strategy to have an appropriate model if they consider the cost of execution in the resource management problem.
The location  of a quantum datacenter refers to either the cloud layer or edge layer, where the quantum datacenter is hosted.Besides, it also indicates the linked quantum broker, which interacts with the quantum data center for selecting and scheduling quantum tasks.

Quantum brokers
The intermediary component in conjunction with a quantum datacenter to manage incoming quantum tasks and coordinates with the datacenter to determine the appropriate backend for task execution can be defined as a quantum broker (QBroker)   as follows: where   is the linked quantum datacenter, Γ is a list of all incoming quantum tasks, and  b is the backend selection policy to determine which available quantum node is suitable to place each incoming quantum task.

Quantum tasks
A quantum task (QTask)  is a fundamental unit of a quantum computation.Conceptually, a quantum application can include one or more quantum circuits that are being sent to be executed in a quantum node. 14We model each single circuit as a QTask to simplify the simulation process, making it more tractable to model and analyze quantum computing environments, especially those involving complex scheduling and resource allocation scenarios.A complex quantum application that involves more than one quantum circuit can be modeled as multiple QTasks.The key features of a quantum task  i can be modeled as follows: where: 1.  a is the arrival time of the quantum task.2.  g is a list of all quantum gate sets used in the quantum circuit, which can contain different single-and multiple-qubit quantum gates.3.  w is the quantum circuit width, which is measured by the number of qubits that need to be used.4.  d is the number of circuit layers, which can be assumed to be directly related to the depth of the circuit.5.  s is the number of shots (i.e., execution repetition) that circuit need to be executed.6.  t is the connectivity of all qubits in the circuit.
Besides, a quantum task can be associated with other metrics related to Quality-of-Service (QoS), such as the acceptable error threshold for executing a quantum task.Quantum circuit features such as quantum gates, circuit width, circuit depth, and qubit connectivity extracted from SDKs such as Qiskit can be mapped to QTask automatically.For example, we extracted features of quantum circuits in QASM format from the MQT Bench dataset 34 and mapped them to corresponding QTasks to represent the workload needed to be processed within the quantum computing environment (see Section 7).
A task placement configuration for task  i ∈ Γ can be represented as  i = { i , q k } ∈ Σ, where q k ∈  and 1 ≤ k ≤ || denotes the index of the quantum computation node.More details about quantum task scheduling and use cases for quantum resource management strategies are discussed in Section 5.

Architecture and main components
We developed iQuantum using the discrete-event simulation approach, leveraging the core components of the CloudSim toolkit. 23The initial design of iQuantum, which aimed to demonstrate the possibility of modeling quantum computing environments, was previously proposed in Reference 14.To support a hybrid quantum-classical environment and expand to modeling the potential use cases, we propose an improved layered design for the iQuantum toolkit, as shown in Figure 3.
We have significantly enhanced the original design through extensive refactoring and adding new features to enhance the simulation process for both quantum and hybrid quantum-classical environments.iQuantum is designed with a modular architecture that comprises five main layers: core simulation, physical, logical, middleware, and resource management.All elements in these layers are implemented to demonstrate the functionality and usefulness of our toolkit in modeling, simulating, and evaluating resource management strategies for hybrid quantum-classical computing in the cloud-edge continuum.Additionally, various utility toolkits have been developed to aid in the simulation process.
The following subsections describe the key components of each layer in the iQuantum framework.

Core simulation layer
The Core Simulation layer in iQuantum is built on the discrete event management framework in CloudSim, 23 which is one of the most widely used simulation toolkits for classical cloud computing environments.The discrete event simulation technique is highly suitable for simulating and modeling dynamic events and their interactions over time in complex computation systems such as cloud-edge environments.This technique is commonly used in many other simulation toolkits, including iFogSim2, 26 ns-3, 52 and OMNET++. 53We enhanced the core simulation framework of CloudSim to incorporate quantum features and improve clarity in the context of hybrid quantum-classical computing in cloud-edge environments.In iQuantum, the whole system is represented as a set of entities that interact with each other through events.After starting the simulation, the core simulation components initialize all entities based on the provided scenario and register all computation resources with the central Resource Information Service (RIS).The simulation moves forward by scheduling and processing all defined events in chronological order.Each event alters the state of the system and can possibly schedule new events for the future.The simulation continues until it reaches a predetermined termination condition, such as a specified time duration or a certain number of tasks.

Physical layer
The Physical Layer encompasses various components, including QDatacenter, CDatacenter, QNode, and CNode, which collectively enable the simulation of a hybrid quantum-classical computing environment.Processing Units in iQuantum comprise both (Classical) Central Processing Units (CPUs) and Quantum Processing Units (QPUs).CPUs handle classical computations and support the quantum task compilation and coordination of hybrid tasks in the system.Each CPU entity (formerly Pe in CloudSim) is modeled by Million Instructions Per Second (MIPS). 23PUs (or quantum chips) are responsible for executing quantum tasks.We leverage common metrics and properties of gate-based quantum devices to model a QPU in iQuantum, including the number of qubits (scale), Quantum Volume (QV-quality), Circuit Layer Operations Per Second (CLOPS-speed), qubit connectivity topology, supported quantum gates, qubit, and quantum gate error rates (see Figure 2).To simplify the terminologies, we used "node" to refer to the physical computation devices, where QNodes represent the quantum computer (or quantum system) and CNodes represent the classical server or host (formerly in CloudSim).Each node can contain one or more processing units, enabling parallel execution of tasks.In the classical domain, a CNode can be modeled with other capacities such as RAM and storage.As similar techniques for quantum computing have not yet been invented or are in the early stages of development, we only consider adding QPUs for QNodes in iQuantum at this stage.However, these metrics can be modeled in the future as the technology advances.Besides, it is important to note that current quantum computers mostly support a single quantum chip (QPU).However, a multi-QPU quantum computer is expected to be invented soon with planned roadmaps by major hardware vendors such as IBM.In addition to computing capacity, each node can be associated with different resource management policies and pricing models.For QNodes, users can model different cost models, as different quantum providers offer different pricing models.For instance, IBM Quantum offers a cost per second of the quantum execution model, while Amazon Braket offers a cost-per-execution and shots (iterations) model.
The datacenters in iQuantum, namely QDatacenter and CDatacenter, serve as the infrastructure for resource coordination.In general, a data center can be seen as a collection (or cluster) of multiple computing nodes (QNodes or CNodes), which can be coordinated to perform a common task.Each datacenter entity is associated with a corresponding class to model a list of all belonging computation nodes and other necessary characteristics.

Logical layer
The Logical Layer in iQuantum consists of abstractions that represent the classical virtualized resources and computation tasks on the system.These abstractions are designed to provide a simplified and standardized interface for both classical and quantum counterparts.The classical part is mainly inherited from CloudSim entities, which includes resource and application abstractions such as Virtual Machines (VMs), containers, and classical tasks (CTasks).VMs are virtualized computing resources allocated within a CNode, while containers represent containerized computing resources allocated within a VM.They offer an isolated and flexible environment for deploying and running classical applications.Additionally, CTasks represent a classical task (formerly Cloudlet in CloudSim) that can be scheduled and executed on classical resources.The quantum part includes the model of quantum task (QTask) as the virtualization technique for quantum counterpart is not yet invented.A QTask represents a computation task that needs to be executed on the quantum computing resources.It encapsulates the quantum algorithm or quantum circuit, along with any necessary parameters and configurations, such as the number of qubits, number of circuit layers, quantum gates, and other execution constraints.By utilizing the QTask abstraction, users can simulate the execution of quantum algorithms and evaluate their performance in conjunction with the classical infrastructure.

Gateway layer
The gateway layer comprises intermediary components, including gateways and brokers, which facilitate communication and task orchestration between cloud and edge computation components.In iQuantum, a gateway (cloud or edge gateway) is a communication interface between data center brokers and the layer below.It receives incoming tasks, classifies them, and dispatches them to the appropriate broker for further scheduling.The brokers, namely QCloudBroker, QEdge-Broker, CCloudBroker, and CEdgeBroker, then perform the task scheduling based on the resource management policies in the system.

Resource management layer
This layer enables users to prototype and evaluate various management policies, including task scheduling, migration, orchestration, and resource provisioning.
1. Task scheduling (or task placement): An efficient placement technique must be designed to optimize resource utilization, especially for limited and expensive resources such as quantum computing devices.It is also possible to consider other objectives, such as minimizing execution time or optimizing the precision of quantum execution results by scheduling tasks to quantum nodes with higher quantum volume.2. Task offloading: Due to the dynamic nature of the cloud-edge environments, an adaptive task migration technique must be designed to migrate tasks to other computation nodes or offload tasks from the edge layer to the cloud layer when the edge resources are unavailable or insufficient to execute tasks.3. Resource provisioning: iQuantum can prototype different resource allocation strategies, such as container or virtual machine provisioning and multi-processing unit (CPUs and QPUs) allocation to computation nodes (CNodes and QNodes).It is important to note that resource provisioning policies are mainly for classical resources, as quantum resource virtualization or partitioning is not yet mature.However, it can be extended in future releases to adapt to the current nature of quantum technology.

Implementation of quantum components
The overview of the main class diagram for the quantum entities in iQuantum is shown in Figure 4.The core classes for discrete-event simulation are adapted from the latest version of CloudSim to support the seamless integration of iQuantum with classical component modeling.
1. iQuantum class is the core entity, which triggers the initialization of all entities, runs a clock tick during the simulation to record all events, manages the simulation, and triggers all entities to shut down at the end of the simulation.2. SimEntity and SimEvent: Each core entity in the quantum environment, such as quantum data centers and brokers, is an extension of the SimEntity class, which can generate events for interaction with other entities.Each simulation event is associated with a unique ID (defined in iQuantumTags) and is represented using SimEvent class, which includes properties such as two entities, timestamps, and all exchanging information in the event.3. ResourceInformationService (RIS): This class handles the resource registration of QDatacenter entities when they are initialized.4. Gateway is the abstract class that represents the intermediary component that receives all incoming tasks from users or below the layer, then classifies and dispatches to corresponding brokers for further scheduling.Two implementations of this class, CloudGateway and Edgegateway, represent the gateway of cloud and edge layers, respectively.5. QBroker class models a quantum broker that interacts with the Gateway and QDatacenter to schedule incoming QTask to a suitable QNode in the QDatacenter.Two extended classes, namely QCloudBroker and QEdgeBroker, handle the brokering job at the cloud layer and edge layer accordingly.6. QDatacenter is the generalized class model of the datacenter (or a cluster) of multiple quantum nodes located in the same areas.There are two specific classes that extend this class for modeling a cloud-based quantum datacenter (QCloudDatacenter) and an edge-based quantum node cluster (QEdgeDatacenter).A list of all associated QNode and other configurations of QDatacenter are defined in QDatacenterCharacteristics class.The connectivity of qubits in a QTask can also be modeled using the QubitTopology class.9. QTaskScheduler is an abstract class to model the scheduling policy to distribute resources of each QNode among multiple incoming QTasks.We implemented the QTaskSchedulerSpaceShared by default for QNode, which is described in detail in Section 5.1.
In the context of our simulation framework, it is important to outline the scope of iQuantum regarding quantum physical operation.iQuantum's design does not include the direct simulation of quantum physical phenomena such as superposition and entanglement.This decision aligns with our framework's objective to provide a high-level simulation environment primarily concerned with the operational aspects of quantum computing environments.However, iQuantum is capable of modeling quantum circuit features from external quantum SDKs such as Qiskit.For instance, quantum circuit features can be obtained from these SDKs and subsequently incorporated into iQuantum's simulations to represent a QTask.This integration allows iQuantum to model the outcome and performance implications of quantum computations based on the empirical benchmark data, albeit at an abstract level.In this way, iQuantum can simulate the broader operational environment of quantum computing, such as the scheduling of quantum tasks into an appropriate quantum system to optimize resource management.

Quantum nodes and workload datasets
Initially, simulation scenarios in iQuantum can be defined manually, 14 similar to CloudSim. 23This approach allows users to customize the definition and attributes of all entities in the system.However, this task can be trivial for explanatory or small experiments but impractical for large-scale experiments with a vast number of heterogeneous devices and tasks.
To improve the flexibility of dataset processing in iQuantum, we support quick prototyping by using external datasets.Datasets in iQuantum are expected to be formatted as a CSV file, which is commonly used in machine learning and software domains.
1.Quantum nodes: iQuantum supports the use of a calibration datasheet format, adopted from IBM Quantum, 13 to model all attributes of a QNode, including detailed qubit topologies and error rates.2. Quantum tasks: The quantum workload dataset in iQuantum can be generated by extracting all features from the OpenQASM file to a CSV file.You can import this dataset directly into iQuantum to automatically generate QTasks for evaluating resource management policies.We derived several sets of quantum workload datasets for iQuantum based on QASM files from the MQT Bench. 34

USE CASES OF IQUANTUM FOR QUANTUM RESOURCE MANAGEMENT SIMULATION
In this section, we demonstrate the usefulness and effectiveness of iQuantum in modeling quantum computing resource management problems, such as quantum task scheduling and hybrid quantum-classical task orchestration in the cloud-edge continuum.In order to make our explanation accessible to a wide range of readers, we explain how iQuantum can be used with general resource management policies and discuss the possibility of tackling more complex problems.It is important to note that creating new resource management policies is not within the scope of this paper.

Quantum task scheduling
Effective task scheduling (or task placement) is a crucial aspect of distributed system research, which also applies to the quantum computing domain.The goal is to enhance the management of computational resources by optimizing resource utilization, reducing the overall time taken to complete tasks, and minimizing the cost of resource usage.The overall simulation logic of QTask scheduling problems in iQuantum is described in Algorithm 1.We divide the quantum task scheduling process into two main stages: quantum node selection (or backend selection) and task allocation at QNode.After initializing the environment and the simulation clock, all tasks are submitted to the closest gateway (Cloud Gateway or Edge Gateway).Then, the gateway classifies and dispatches quantum and classical tasks to their corresponding brokers.For quantum tasks, the key steps of each stage in the scheduling process are as follows:

Backend selection
QBroker communicates with the quantum data center to gather information about the current environment, combining with all features of the incoming tasks to determine which QNode is the most appropriate backend for executing each QTask.This procedure comprises two main steps: 1. Pre-selection: First, QBroker performs this process to select all potential QNodes   , which satisfies the strict requirements of executing tasks to reduce the overhead for the backend selection.Several prerequisites to place a QTask  i to a potential QNode q j ∈   are considered, including: a.The qubit number of a potential QNode (q w j ) must be equal to or higher than the required qubit number (or circuit width) of QTask ( w i ), denoted as q w j ≥  w i .At this stage, we assume that a quantum circuit cannot be split and executed on different QNodes.It is important to acknowledge that techniques such as circuit cutting, 54 are in the early stages of development and can be considered in the future.b.All quantum gates used in QTask ( g i ) need to be supported by the gate sets of the QNode (q g T ), denoted as  g i ⊆ q g j .Otherwise, the transpiler can be used to convert unsupported gates 55 to the native gate set of QNode.c.It is possible to find a mapping ( ij ) of the QTask's qubit connectivity ( t i ) and the qubit topology of the QNode (q t j ).iQuantum also allows users to model and evaluate their qubit mapping strategy or use the default backtracking-based qubit mapping policy.Other constraints, such as cost, quantum volume, and quality of services (QoS), can also be considered.If all prerequisites are satisfied, the QNode will be added to the potential QNodes   for the backend selection.2. Selection: QBroker can then apply the backend selection policy ( b ) to select the most suitable QNode from the pre-selected list in the previous step.This policy is driven by different objectives and constraints defined by users.

Task allocation
After the backend selection procedure, QDatacenter will place each QTask to the selected QNode for execution.All arrived tasks are place in the queue at QNode and will be executed based on the QNode's task allocation policy.Different strategies for task allocation can be designed to schedule multiple incoming quantum tasks in the appropriate order to minimize the execution time or achieve other resource utilization objectives.
For the classical computing domain, there are two main policies for allocating multiple tasks for execution in classical computation resources, including the Space-shared and Time-shared policies. 23Examples of comparable strategies for quantum tasks are illustrated in Figure 5.We assume there is a 7-qubit QNode and 5 QTasks (arrived in order from q1 to q5) in the waiting queue.The width and height of each QTask represent its number of qubits and number of circuit layers, respectively.1.In space-shared policy, quantum resources (qubits) are allocated exclusively to each task for the entire duration of its execution without any time-sharing.The remaining tasks must wait for available resources if other tasks occupy current resources.2. In the time-shared policy, the available resources can be divided into time slots and allocated to tasks or users in a round-robin fashion.Each task is assigned resources for a fixed time interval, after which the resources are reassigned to the next task in the queue.
It is important to highlight that the time-share approach is impractical for quantum task execution at the moment.It is mainly because a quantum task cannot be suspended and then resume its previous quantum state to continue executing in the future due to the no-cloning theorem of quantum computing.Therefore, the space-shared policy is suggested to be used as default in iQuantum for task allocation at QNode.In the future, we anticipate that multiple quantum tasks can be parallel executed in different areas of the qubit topology in a quantum computer.However, it is challenging to realize this approach in the current NISQ era 20 as it can be affected by noise and complicated qubit reset control.

Hybrid quantum task orchestration
Quantum computing is predicted to enhance classical computing rather than replace it entirely.It can handle tasks that are best suited to its distinctive features.In this way, a hybrid quantum-classical computing system can be a potential paradigm to maximize the capabilities of both quantum and classical systems during the NISQ era. 56This approach utilizes the advantages of classical computing for tasks such as data pre-processing and post-processing while assigning more computationally demanding tasks to quantum resources.iQuantum leverages the classical entities in CloudSim to support modeling classical resources and its local resource management policies within the classical data center.Additionally, user can design their policy for orchestrating quantum and classical tasks from the Gateway to the appropriate broker.The hybrid task orchestration logic is depicted in Algorithm 2. It is important to note that different resource provisioning can be applied to classical servers (CNodes) to allocate logical resource units such as virtual machines (VMs) and containers.However, the equivalent technique is not yet available for quantum resources as QTasks are executed directly in quantum nodes.
After the environment setup, all tasks can be submitted directly to the closest Edge gateway.Then, Edge Gateway classifies and dispatches each task to Quantum Edge Broker (QEBroker) or Classical Edge Broker (CEBroker) for the scheduling process.Users can design different scheduling policies for classical and quantum tasks to achieve their objectives.For quantum tasks, the complete scheduling process can be done as described in Algorithm 1 (Section 5.1).For classical tasks, more discussion about task scheduling and resource management policies can be found in Reference 23.
Additionally, the task offloading and migration problems can be modeled in iQuantum in case the computation resources at the Edge layer are insufficient for executing the incoming tasks.For example, a quantum node at the Edge layer does not have enough qubits for executing quantum tasks as edge nodes have limited capacity compared to the cloud nodes.In this case, the corresponding broker will offload these failed tasks from the edge to the cloud gateway.Accordingly, a similar orchestration process can be performed at the cloud layer to distribute all arrived tasks to the most suitable computation node.
An example of hybrid task orchestration in the cloud-edge continuum is illustrated in Figure 6.We assume four hybrid services (or applications) that need to be executed.Each service (or application) can contain multiple quantum and classical tasks that require different computation resources.Services 1 and 4 contain only classical tasks or quantum tasks, in which the smaller task can be sent to executed using edge resources, and the larger one can be offloaded to the cloud.Services 2 and 3 contain both quantum and classical tasks, which can be sent to their most appropriate computation node for execution.If the resource at the edge layer is sufficient for the incoming task, it can be used to place the task to reduce the communication latency and overhead for the cloud.More complex scenarios can be modeled within our toolkit.When iQuantum is used with CloudSim/iFogSim, one can model and simulate a hybrid quantum-classical computing environment and evaluate new hybrid task orchestration algorithms.

EXAMPLE OF SIMULATION WORKFLOW
Figure 7 depicts an overview of the simulation workflow in iQuantum, which consists of four main stages.First, the user needs to define the scenario manually or automatically using the dataset generator and importer.Then, when the simulation is initialized, it will first set up the environment with all pre-defined entities.Next, it executes all resource management policies, such as provisioning, scheduling, migration, and orchestration of all quantum and classical tasks.Finally, when the simulation stop condition is met, the simulation will be terminated, and the outcome will be generated in CSV format for further analysis.
To demonstrate the main steps of setting up a simulation in iQuantum, we present an explanatory example as Figure 8.This example is mainly derived from our earlier proposal 14 with improvement in the declaration.A quantum datacenter with a single 7-qubit QNode follows the configuration of ibmq_oslo node from IBM Quantum (QV 32, CLOPS 2,600).This QNode receives two quantum tasks, QTask 1 and QTask 2, with 4 qubits and 3 qubits, respectively.Both QTasks employed 3 basic gates (CX, RZ, X), which are fully supported by the quantum node.QTask 1 comprises 100 circuit layers and will execute 4000 shots, while the metrics for QTask 2 are 50 layers and 1000 shots.
Step 2. Create a list of QNode instances.Users can model manually similar to Reference 14, or automatically by using the predefined QNode and adding to qNodeList as follows (Code 1): Step 3: Create a QCloudDatacenter.qNodeList and other information, such as cost of execution in the quantum datacenter are modeled in a QDatacenterCharacteristics object (Code 2).
Step 5: Submit all quantum tasks to CloudGateway and start the simulation.Once all the simulation tasks are complete, stop the simulation and print out the final outcome (Code 5).The simulator shows all events (with timestamps) happening during the simulation period (Code 6).The simulation results show that two quantum tasks are submitted to the QNode at timestamp t = 0.01 s (minimum interval between two different events).The execution times of QTask 1 and QTask 2 in the QNode are 153.85 and 19.23 s, respectively.According to the Space-shared scheduling policy, QTask 2 can only be executed after QTask 1 finishes its execution.The total execution time of all quantum tasks is 173.08 s.As noted above, these results are the same as when we manually calculated using Equation (8).More large-scale simulation scenarios and evaluation of iQuantum are discussed in the following section.

VERIFICATION AND PERFORMANCE EVALUATION
In this section, we conduct a comprehensive verification and evaluation of iQuantum in different scenarios by using a well-known benchmarking quantum workload dataset to verify the accuracy of the conceptual model's implementation and its performance with the proposed use cases discussed in Section 5.The primary findings of the empirical experiments are discussed in this section.

iQuantum simulation verification
Simulation is a cost-effective and less complex alternative to empirical experimentation for understanding real-world systems. 58However, due to the high complexity of real-world systems, simulators often employ assumptions and abstractions, which can introduce certain inaccuracies while simplifying the model.Therefore, a key aspect of simulation studies is ensuring that these models maintain acceptable accuracy levels, considering their assumptions and abstractions.This involves two critical processes: validation, which assesses if the conceptual model is a true representation of the real world, and verification, which ensures the correct implementation of the model. 27or the system model validation, the conceptual model and metrics in quantum are devised based on well-known studies on quantum benchmarking 32,51,59,60 without further modification.Besides, the validation and verification of classical components had been studied in CloudSim. 23Thus, the quantum system model validation and classical system models are out of the scope of this study.The rest of this section demonstrates a verification to ensure the correctness of iQuantum implementation for quantum-based features before conducting a large-scale evaluation, following the verification approach of other modeling and simulation studies, such as References 27,58.

Scenario description
We use the quantum cloud-edge infrastructure as depicted in Figure 9 to comprehend the proposed use cases along with the correctness verification of iQuantum's implementation.Detailed attributes of heterogeneous QNodes, which are adopted from IBM Quantum, 13 are depicted in Table 2.The edge layer consists of a cluster of five quantum nodes, modeled according to information of different 27-qubit IBM Quantum Systems, including ibm_hanoi, ibm_auckland, ibm_cairo, ibmq_mumbai, and ibmq_kolkata.The cloud layer has a datacenter of 6 QNodes, following the 127-qubit topology of the ibm_washington system with different metrics for QV and CLOPS to demonstrate the heterogeneity of the quantum cloud environment.
To facilitate the verification, we use four QTasks that represent different quantum applications extracted from the MQT Bench dataset, 34 in which the circuit attributes are shown in Table 3.All QTasks are initially submitted to the edge gateway for processing.Following the proposed system model and use cases (Section 5), QTask  2 (55 qubits) is expected to be offloaded to the quantum cloud layer while the remaining QTasks can be executed at the quantum edge layers.The offloading time between two layers is set to 0.01 s.We also assume that  3 and  4 are to be scheduled to the same QNode (QE1) to verify the correctness of the proposed space-share task allocation within a QNode of iQuantum.

Verification discussion
The dynamics of all events that occurred in the simulation of our verification are illustrated in Figure 10 and Table 4, following the similar verification approach of the EdgeSimPy simulator study. 27 scheduled at the quantum edge layer for execution.However, as all QNodes at the edge layer can only process QTasks up to 27 qubits, QTask  2 (55 qubits) needs to be offloaded to the cloud with more powerful QNodes for processing.Besides,  1 and  3 start the processing at QE5 and QE1, respectively, while  4 need to wait at QE1 to be executed after  3 completion (following the Space-shared scheduling).At time step T 2 = 0.02 s,  2 arrived at the cloud layer and is scheduled to QNode QC1 for execution for 8.72 s, then finished at time step T 3 = 8.74 s.After the completion of  3 for 14.74 s,  4 starts its execution at QNode QE1 at time step T 4 = 14.75 s.The remaining QTasks,  1 , and  4 , continue their execution and finish at time step T 5 = 16.32 s and T 6 = 39.8 s, respectively.It is obvious that all discrete events that occurred during the verification are correct and meet the initial expectation with the given input.

Performance evaluation
To validate the effectiveness of iQuantum with the proposed use cases (discussed in Section 5), we further evaluate its performance and correctness of the implementation in different large-scale scenarios.

Environment setup
For the quantum cloud-edge system, we set up a similar infrastructure as the previous verification setting (see Figure 9 and Table 2) to further investigate the quantum cloud-edge architecture with large-scale scenarios and use cases.For modeling large-scale quantum task workloads, we used MQT Bench 34 and extracted features of quantum circuits for 28 different quantum algorithms into four sets as shown in Table 5.The original quantum circuits are mapped to IBM Quantum systems (27 qubits and 127 qubits).To simplify the circuit layer extraction, we assume that the number of circuit layers is equivalent to the circuit depth of each QTask.We employed the Lottery-based 61 Backend Selection algorithm for the quantum node selection and the Space-shared policy for QNode scheduling.In the backend selection policy, we use quantum volume (QV) and CLOPS with the same weight (0.5) to determine the number of tickets for each QNode (i.e., a QNode has a higher QV and CLOPS will have a higher chance to be selected).All workload data of each set are sent to the edge gateway for the orchestration.The experiments are conducted on a Ubuntu 22.04 virtual machine hosted by Melbourne Research Cloud with an 8-vCore CPU and 32 GB of RAM.Each evaluation is repeated 1000 times, with the results discussed in the following part.are truncated for simplicity as there are no new events after T 3 .

Discussion
Figure 11 illustrates the peak memory (RAM) usage and average simulation time (wall-lock time) of all scenarios on different workload datasets measured by using time command in Ubuntu.As iQuantum is an event-based simulation toolkit, its resource usage is relatively low without simulating the quantum operation.For Sets 1 and 2 cases, all tasks are executed at the quantum edge layer as all quantum edge nodes have sufficient qubits for the execution.Each simulation only takes around 0.5 to 1 s and requires from 117.8 MB (Set1) to 241.6 MB (Set2) of RAM for processing.As all tasks in Set 3 and the majority of tasks in Set 4 (5569 tasks) require 127 qubits, they are offloaded from the edge layer to the cloud layer for execution during the simulation.The qubit mapping for 127-qubit tasks requires more memory, peaks at 910.95 MB of RAM, and takes about 8 s to process 7000 QTasks in the hybrid scenario (Set 4).Nevertheless, the average simulation time and resource consumption of iQuantum are lightweight to model and evaluate different resource management policies for quantum computing environments.Figure 12 illustrates the heatmap distribution of all QTask execution on different QNodes.As we employed the lottery-based backend selection policy, which prioritizes the selection of QNode with a higher quantum volume and CLOPS, this heatmap reinforces the correctness of our implementation.In order to use quantum resources more effectively, it is important to develop an advanced resource management strategy.Users can use iQuantum to design and evaluate more advanced backend selection and task scheduling to optimize the resource management strategy.
Additionally, to draw insight into the simulation results to highlight the necessity of the iQuantum toolkit, we illustrate the average results of all QTasks completion time in Figure 13.QTasks completion time indicates the time elapsed for all QNodes to finish executing all QTasks, where different QNodes can execute different tasks at the same time.We also measure the sum of the total execution time from all quantum nodes in each scenario.As the space-shared scheduling policy limits a QNode can execute only one task at a time, and each QTask in our test has a large number of circuit layers, the total completion time, as well as the sum of QPU times, are quite considerable, especially for completing Sets 3 and 4. It requires around 1 h of execution in practical environments for completing all incoming tasks where the actual QPU times are 4.2 h (Set 3) up to 7 h (Set 4).If we consider the cost model of quantum computing providers, such as IBM Quantum, which charges each second of quantum execution at $1.6, the total cost for each set in the actual environment is enormous.Therefore, a simulated environment for the design and evaluation of quantum resource management policies is crucial.Since implementing quantum computing in practical settings can be costly, iQuantum offers a simplified  toolkit for modeling, designing, and assessing resource management policies without incurring massive waiting time or expenses.

LESSON LEARNED AND DISCUSSION
Through the development and empirical evaluation of different use cases of iQuantum, we identify several insights that can be useful for research in quantum resource management and developing modeling and simulation toolkits for quantum computing environments.Performing experiments in practical environments for quantum computing is difficult and time-consuming, mainly due to the limited and costly quantum resources.The use of modeling tools like iQuantum is critical to accelerate research in system design and resource management.Furthermore, iQuantum can be used for educational purposes to help practitioners better understand the quantum system operation and performance.
In order to keep up with the latest advancements in quantum hardware and software, the modeling and simulation toolkit must be easily expandable and support new metrics.Quantum computing is constantly evolving, with new standards and metrics emerging during its development.Recently, metrics like quantum volume and CLOPS have gained popularity, and more may be added in the future.The simulator should be able to support modeling new metrics to reflect the comprehensive environment for testing more advanced resource management strategies.iQuantum allows users to customize and add more features as needed to fulfill their requirements.Users can advance resource management to adapt to current NISQ devices with more comprehensive aspects, such as error rates and connectivity of qubits in QNode.A quantum node in iQuantum can be modeled with detailed information on error rates in each qubit and their connections, which can serve these studies.Besides, different features of quantum circuits can be extracted from QASM files or using other quantum SDKs such as Qiskit 46 and Cirq 47 to the customized format in iQuantum.
Currently, the vision of quantum computing at the edge layer 15,16 is just a theoretical concept, but it may become a reality in the near future as quantum devices become more popular.Nevertheless, our paper also illustrated a simple hybrid model of quantum cloud-edge computing, where resources for quantum computing at the edge are more limited compared to cloud-based quantum computers.Future research should consider various aspects of this hybrid model, such as user mobility, service migration, and network communication.Additionally, we suggest expanding iQuantum to include further aspects and features, such as energy consumption management, network communication, and parallel processing of quantum tasks in multi-QPU quantum computers.It is worth noting that quantum nodes do not currently use virtualization or containerization techniques, unlike classical computing.Instead, they directly execute quantum tasks with the support of classical drivers for circuit compilation and transpilation.As a result, there is no equivalent conceptual model for virtual machines (VMs) or containers in the quantum computing field at present.Besides, quantum datacenters can contain nodes that are either homogeneous or heterogeneous, depending on their physical properties and underlying technology.While quantum cloud providers offer access to their quantum simulators, these resources are only useful for testing during the NISQ era and not for long-term production phases.Consequently, we do not take these simulators into account for modeling purposes.
It is also important to mention that iQuantum also supports the model of different error rates of quantum nodes, which helps to understand quantum errors in a simulated environment and design more complex resource management strategies.However, the scope of our study does not include a comprehensive benchmarking analysis of the impact on different error rates.Users can consider these error rates and holistic quality metrics of a quantum system, such as quantum volume, 51,60 when designing task scheduling or resource management policies.Quantum error modeling and analysis, which delves into the specific impacts of varying error rates on quantum computation, represents a significant and complex undertaking that is actively developed in the domain of quantum hardware benchmarking, 59,62 and quantum error correction. 63n the current landscape of quantum computing, the development of large-scale quantum systems, exemplified by endeavors such as the IBM System Two with more than 1000 qubit quantum chips, 64 represents a significant step forward.Future work with iQuantum will focus on extending its capabilities to model and simulate such large-scale quantum systems.This undertaking will involve enhancing the framework's scalability and computational efficiency to represent and manage the complexities inherent in systems of this magnitude.
It would be beneficial to explore an improved method for measuring the number of circuit layers in quantum tasks.In our evaluation, we assumed that the circuit depth extracted from the original QASM files represented the circuit layers.However, it is important to note that circuit depth is only an approximate metric, and we recommend using a more precise method to extract the number of circuit layers in quantum tasks to adapt to the measurement of the CLOPS metric for quantum nodes.In the study on CLOPS metric benchmarking, a circuit layer was defined as one layer of permutation among qubits and one layer of pair-wise random SU(4) 2-qubit unitary gates.However, this circuit was designed specifically for CLOPS benchmarking, and a technique for estimating the number of circuit layers in a general circuit is still necessary.It is important to note that our work primarily pertains to the features of the circuit dataset used for the simulation, and the circuit layer measurement technique does not impact the core simulation logic of iQuantum.We emphasize the need for a standardized and large-scale quantum workload dataset to investigate further the development of advanced quantum resource management policies in the future.For example, the depth-1 circuit per second 32 metric, which is linearly scaling to CLOPS, can be considered in the future.

CONCLUSIONS AND FUTURE WORK
Our paper introduces iQuantum, a lightweight and versatile toolkit for modeling and simulation of hybrid quantum computing environments.This toolkit focuses on creating and evaluating quantum resource management policies within the cloud-edge continuum.We have extensively developed iQuantum from an initial case proposal to a holistic toolkit that is flexible and adaptable for various use cases in quantum systems research.In addition to the iQuantum toolkit, we also propose a comprehensive system model for quantum computing environments, which serves as a baseline model for quantum entities in the hybrid cloud-edge paradigm.We demonstrate various use cases for iQuantum, including facilitating the design and evaluation of different scenarios in resource orchestration problems such as task scheduling, backend selection, and hybrid task orchestration.Moreover, we also validate and evaluate the performance to highlight the effectiveness of iQuantum using reliable datasets from MQT Bench 34 and IBM Quantum.The targeted users of iQuantum will be students, educators, researchers, and practitioners who want to comprehensively evaluate resourced management algorithms in simulated environments.Such proven algorithms can then be deployed in real quantum computing environments.
Our future work in iQuantum involves ensuring that we can adapt to new advances and standards in quantum hardware and software design.We aim to support the model of large-scale quantum chips with more than 1000 qubits and extend our modeling to analyze the impact of various quantum error rates.We are also considering extending iQuantum's capabilities to model the characteristics of various quantum hardware and quantum networks.We will also consider the modeling of forthcoming techniques, such as circuit-cutting, to allow the allocation of tasks to multiple quantum resources in the future.

F I G U R E 4
Overview of class diagram for quantum components.7.QNode class represents the gate-based quantum computer, which is used for executing QTask.Each QNode can consist of one or more QPU, cost of execution, and a QTask scheduling policy.Each QPU can be modeled in QPU class.Each QPU class represents different metrics, such as the number of qubits, quantum volume, CLOPS, list of all supported gates, and qubit topology.In the QubitTopologyExtended class, we model the connectivity of all qubits along with the error rates of each qubit and quantum gate.Users can also import calibration data from vendors, such as IBM Quantum, to quickly model the quantum nodes.8. QTask class represents all features of a gate-based quantum task (or quantum circuit).Users can extract the circuit features of a quantum task (from a QASM file or CSV dataset) and import them into iQuantum automatically.

5
Example of two allocation strategies for five different quantum tasks (sequenced as q1 to q5) within a seven-qubit quantum node.(A) The Space Shared policy dedicates separate quantum resources to each task.(B) Time Shared policy allocates tasks in even time slots using a round-robin approach, resulting in pausing and resuming of tasks q3 and q4, rendering it impractical for quantum computing.

F I G U R E 6
An example of hybrid task orchestration in the Cloud-Edge continuum.Four services incorporate different quantum and classical tasks, varying in execution time and resource requirements.Each task can be executed on edge computing resources or offloaded to the cloud if edge resources are insufficient for execution.

F I G U R E 9
Overview of the infrastructure considered in iQuantum's verification and performance evaluation.

10
Dynamics of each time step involved in the verification process of iQuantum.The cloud layer in time steps T 4 , T 5 , and T 6

F
I G U R E 11 Average RAM usage (bar chart) and total simulation time (line chart) of iQuantum on four workload datasets (varying from 300 to 7000 QTasks) over 1000 iterations.F I G U R E 12 Distribution of the average number of QTasks execution per QNode in all scenarios.QC, quantum nodes at the cloud layer; QE, quantum nodes at the edge layer.

F
I G U R E 13 Total QTasks completion time (wall-lock time) and cumulative QPU times of all QNodes in minutes required for each workload set's completion.These figures are average values of 1000 iterations.
TA B L E 5 1097024x, 2024, 6, Downloaded from https://onlinelibrary.wiley.com/doi/10.1002/spe.3331by National Health And Medical Research Council, Wiley Online Library on [07/05/2024].See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions)on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License