SeQUeNCe.DQC: Full-stack Simulation of Distributed Quantum Computing

SeQUeNCe.DQC: Full-stack Simulation of Distributed Quantum Computing Sanjay Suresh∗ , Caitao Zhan† , Joaquin Chung† , Rajkumar Kettimuthu† University of Wisconsin-Madison, † Argonne National Laboratory (USA) ssuresh27@wisc.edu, czhan@anl.gov, chungmiranda@anl.gov, kettimuthu@anl.gov

arXiv:2610.39476v1 [cs.NI] 29 Oct 2026

∗

Abstract—Distributed quantum computing (DQC) connects multiple quantum processing units to overcome the scale limits of monolithic hardware. We introduce SeQUeNCe.DQC, a new top-level module within the SeQUeNCe package that compiles monolithic circuits into topology-aware execution plans and coordinates their execution using SeQUeNCe’s existing quantumnetwork modules and protocols. We validate SeQUeNCe.DQC by reproducing a two-node trapped-ion Grover experiment in simulation and comparing success probabilities with the reported 71% benchmark. We then evaluate how compiler strategy, topology, and memory capacity jointly govern distributed circuit execution time and success rate. In these experiments, our hybrid compilers successfully identified mixed T ELE G ATE/T ELE DATA execution plans that outperformed pure gate-teleportation strategies. By capturing the physical overhead of distributed quantum primitives, SeQUeNCe.DQC provides a rigorous platform for codesigning DQC software and hardware architectures.

I. I NTRODUCTION By interconnecting multiple quantum processors, distributed quantum computing (DQC) [1], [2] offers a promising path beyond the scale limits of monolithic hardware toward applications such as quantum chemistry [3], blind quantum computing [4], large-integer factorization [5], and distributed unstructured search [6]. Realizing DQC systems, however, remains exceptionally challenging: it requires quantum processors capable of distributing high-fidelity entanglement at practical rates [7] over reliable quantum network channels and protocols [8]–[11]. Because building and testing physical testbeds are costly and difficult [6], software simulation serves as a vital approach for designing, evaluating, and optimizing DQC architectures, algorithms, and protocols. Motivated by this need, numerous efforts to simulate DQC have emerged [12]–[20]. Interlin-q [12] and SENDQ [13] operate primarily at the circuit level using simplified network abstractions without considering noise. More recent works incorporate hardware noise and focus on job scheduling [14], dynamic circuits [15], or HPC-oriented emulation [16]. SimDisQ [17] and Q-DICE [18] further consider interand intra-QPU topologies, while SwitchQNet [19] provides network-aware compilation and communication scheduling for switch-based quantum data centers. The dqc simulator [20], built on NetSquid, places greater emphasis on quantumnetwork simulation. This material is based upon work supported by the U.S. Department of Energy Office of Science National Quantum Information Science Research Centers as part of the Q-NEXT Center.

A central challenge is understanding how compilation choices and quantum network behavior jointly determine DQC execution time and success probability. A plan with fewer remote operations may still incur long waits for probabilistic entanglement generation, additional swaps, or contention for communication memories. During these waits, stored qubits decohere. Researchers therefore need to evaluate execution time and success probability jointly across compilation, control, and network protocols. We address this need by extending SeQUeNCe, the opensource R&D 100 Award-winning discrete-event quantum network simulator [21], with SeQUeNCe.DQC. The module integrates network-aware compilation and controller–worker execution with SeQUeNCe’s photon transmission, heralding, entanglement swapping, and memory models. This integration lets researchers test whether abstract compiler cost reductions translate into gains under simulated network dynamics. This is particularly important for compiler development: reducing a heuristic communication cost does not establish an application-level benefit unless entanglement generation, classical signaling, memory availability, and noise are evaluated together during execution. Unlike an abstract Bell-pair operation, protocol-level simulation exposes the repeated attempts and classical signaling needed to establish remote entanglement. This distinction matters when comparing compilation strategies that place different demands on network paths and communication memories. A central goal of this work is to provide the community with an easy-to-use open-source tool that advances DQC research by enabling researchers to realistically evaluate compilers, network protocols, and hardware architectures within a unified discrete-event simulation framework. Our contributions are: 1) Design and implementation of SeQUeNCe.DQC1 for full-stack DQC simulation in SeQUeNCe (§II). 2) Validation of SeQUeNCe.DQC by reproducing the results of a distributed Grover search experiment and comparing our simulated success probabilities with the reported 71% success rate [6] (§III). 3) Simulation study on the impact of compiler-network interactions (compiler choice, network topology, and quantum memory) on the performance of DQC using SeQUeNCe.DQC in SeQUeNCe (§IV). 1 https://github.com/ssuresh27-byte/SeQUeNCe.DQC

Fig. 1. Modular architecture of SeQUeNCe.DQC. Light-gray boxes represent existing SeQUeNCe modules; blue boxes highlight new modules added to enable full-stack DQC simulation.

II. D ESIGN AND I MPLEMENTATION SeQUeNCe.DQC is a SeQUeNCe top-level module that extends SeQUeNCe from a quantum network simulator into a full-stack DQC simulator. It compiles a monolithic circuit onto a target topology and executes it over SeQUeNCe’s discrete event-driven simulator (Figure 1). In this section, we introduce the SeQUeNCe.DQC design and implementation. A. Runtime Interface and Simulation Configuration Users interact with SeQUeNCe.DQC through a single highlevel API entry point, runtime.run (see the top left of Figure 2). Given a target circuit, network topology, and compiler, run() automatically constructs the whole network topology DQCNetTopo, instantiates worker processes, compiles the circuit, executes the discrete-event simulation timeline, and returns measurement outcomes across single or multi-shot runs. The circuit is generated by the function CircuitBuilder.build()→Circuit which accepts OpenQASM, Qiskit, or QuTiP circuits. Two simulation backends are supported: • Density-matrix backend: Evaluates exact quantum states under completely positive and trace-preserving (CPTP) noise channels represented by Kraus operators. This backend has a high computational cost and is used for reproducing experimental results in simulations in §III. • Ket-vector backend: Optimized for speed and higher qubit counts, modeling gate errors and pure dephasing derived from T1 /T2 through per-shot random-Pauli trajectories, with T1 relaxation approximated by stochastic resets. This backend drives the majority of our scaling evaluations in §IV. Hardware error parameters—including single- and two-qubit gate infidelities, measurement errors, and T1 /T2 coherence times—are specified per DQC Node, allowing for fine-grained modeling of heterogeneous hardware platforms under either backend formalism.

Fig. 2. SeQUeNCe.DQC execution workflow. The compiler produces a CompiledProgram; the controller tracks qubit locations and dispatches operations to per-node WorkerPrograms.

B. Circuit Partitioning and Remote Operation Planning A compiler takes a quantum circuit and network topology as input and produces a CompiledProgram that the controller further executes (Figure 2). We assume that each QPU contains fully connected, equivalent qubits. Thus, no intra-QPU mapping optimization or routing is required, and compilation focuses on circuit partitioning across QPUs and remote operation planning. The compiler makes two core decisions: circuit partitioning, which assigns logical qubits to DQCNode instances subject to memory-capacity constraints, and remote operation planning, which determines whether inter-node gates use T ELE G ATE or qubit relocations via T ELE DATA. The compiled program contains the initial qubit-tonode assignment and an operation dependency directed acyclic graph (DAG) comprising local gates, T ELE G ATE instructions, and T ELE DATA instructions. SeQUeNCe.DQC supports multiple compilation strategies. Built-in options include a quadratic assignment problem (qap) compiler that minimizes hop-weighted communication distance and a random partitioning baseline. Both retain fixed qubit-to-node assignments and implement all inter-node gates using T ELE G ATE. A time-sliced compiler based on FGP [22] introduces T ELE DATA moves when qubit relocation is advantageous, producing hybrid T ELE G ATE/T ELE DATA execution plans. The CompiledProgram provides a common interface that makes SeQUeNCe.DQC a compiler-agnostic simulation platform: any compiler that produces a compatible CompiledProgram can use the same simulation runtime. External and custom compilers can therefore be evaluated using simulated physical network behavior, complementing their abstract cost estimates. §IV demonstrates this capability. C. Controller - Worker Interaction Controller. The Controller is a classical node that connects to each DQCNode via classical channels. It maintains a central QubitRegistry that tracks the dynamic mapping between logical circuit qubits and physical memory addresses

across the network. At initialization, a Compiler produces a CompiledProgram that sets up this registry. The controller then drives execution using one of two built-in control policies: a lock-step barrier policy that broadcasts each circuit layer, waits for all acknowledgement (ACK) messages, and advances; or an adaptive policy that dispatches individual operations as soon as their preceding dependencies resolve. Because the controller tracks physical memory address mappings, it resolves logical target qubits to concrete physical locations prior to instruction dispatch. Whenever a T ELE DATA operation completes, its ACK message updates the controller’s registry with the qubit’s new location. Modeling classical transmission channels explicitly ensures that control-plane latencies and broadcast overheads are faithfully captured during simulation. DQC Node. Each DQCNode serves as a worker that executes quantum operations dispatched by the controller. It combines a QPU with quantum repeater functionality, following the server-centric architecture described in [23]. Each node has two distinct quantum memory resources: data memories for computation and communication memories for inter-node entanglement. Communication qubits are allocated dynamically for entanglement-generation attempts to produce heralded Bell pairs and are recycled upon protocol completion. A dedicated Bell-state-measurement node is placed in the middle of each link connecting adjacent DQCNode instances. Each DQCNode houses a local WorkerProgram that executes instructions dispatched by the central controller. The controller issues operations already resolved to concrete physical memory addresses on the target node. The WorkerProgram executes local gates directly, or reserves network qubits to execute a nonlocal protocol. It returns an ACK upon operation completion; for nonlocal gates, this ACK is deferred until the underlying entanglement and gate protocols finish. D. Two Teleportation Primitives Nonlocal operations are delegated to SeQUeNCe’s teleportation suite via a single teleportation application instance per node, exposing two primary primitives: • T ELE G ATE (gate teleportation) executes a remote twoqubit gate (cx or cz) while leaving both data qubits on their respective home nodes. • T ELE DATA (state teleportation) physically relocates a data qubit to another node. This primitive supports two modes: moving a qubit into an empty memory slot, or performing an inter-node swap when target slots are occupied (requiring two concurrent T ELE DATA operations). Because parallel links enable simultaneous entanglement generation, swap operations complete in roughly the same duration as single-qubit relocations. These primitives represent a compilation trade-off: incurring a single T ELE DATA relocation upfront can convert subsequent inter-node operations into fast local gates, reducing total T EL E G ATE overhead (§IV). Both primitives run atop SeQUeNCe’s resource-management layer, meaning each required Bell pair may demand multiple probabilistic attempts, and multi-hop link interactions are enabled by entanglement swapping.

TABLE I I MPLEMENTED ERROR BUDGET (A/B = A LICE /B OB = CONTROL / TARGET ) [6, TABLE 1].

Error source

A

B

Raw entanglement 3.11% Mixed-species gate 2.4% 2.0% QC decoherence (T2 ) 1.9% 1.8% QX ↔ QC transfer 0.76% 0.52% Mid-circuit meas. 0.091% 0.122% In-CZ rotations 0.016% 0.015% Local gate (H/X) Readout

1×10−4 5.0×10−3

Noise channel

Applied

2-qubit depol. 1-qubit depol. 1-qubit deph. (Z) 1-qubit depol. 1-qubit flip (X) 1-qubit depol.

each CZ each CZ each CZ each CZ each CZ each CZ

1-qubit depol. bit-flip

every local final meas.

III. R EPRODUCING A D ISTRIBUTED G ROVER E XPERIMENT To validate SeQUeNCe.DQC against experimental results, we reproduce the two-node distributed Grover search experiment of Main et al. [6] in simulation and compare success probabilities. In their setup, two photonically interconnected trapped-ion modules execute Grover’s algorithm using teleported controlled-Z gates. Their reported benchmark is a 71% average success probability across the four two-qubit marked states, achieved via a teleported-CZ average gate fidelity of 86.2% and a remote Bell-pair fidelity of 96.89%. A. Setup and noise model We construct the two-qubit Grover circuit and assign its two data qubits to separate modules connected by a single photonic channel. The CZ gates in the oracle and diffusion circuits are the only nonlocal operations, each implemented using T ELE G ATE. We run the full SeQUeNCe.DQC stack under the density-matrix backend, injecting calibrated error channels from the experiment and estimating success over 2000 shots per marked state. We evaluate two noise configurations: 1) Noiseless control: Isolates compilation and readout artifacts from hardware noise. 2) Detailed model: Implements the experiment’s full persource error budget (Table I) [6, Table 1]. The six per-CZ noise sources act on the data qubits after each teleported CZ gate once communication qubits are traced out. Additionally, we apply local single-qubit gate errors (1×10−4 ) after every local H/X gate and readout errors (5.0 × 10−3 ) at final readout. B. Results Figure 3 compares per-marked-state success probabilities for the two noise configurations with the experimental average. The noiseless baseline achieves a 100% success rate across all four states, confirming that the teleported-CZ execution and readout routines function correctly end-to-end. When noise channels are enabled, the simulated success probabilities approach the experimental benchmark: evaluated over 2000 shots per state, the full detailed model achieves 73.8% (perstate: |00⟩73.4%, |01⟩73.5%, |10⟩73.8%, |11⟩74.4%). The per-

TABLE III D ISTRIBUTED G ROVER SCALING VS . PROBLEM SIZE (n). WALL TIME IS MEASURED FOR A SINGLE CIRCUIT EXECUTION .

Fig. 3. Two-node distributed Grover validation. Per-marked-state success probability for the noiseless baseline (100%) and the full detailed error model (73.8% avg). The dashed line represents the measured 71% average from Main et al. [6].

state success probabilities span only ∼ 1%, showing similar observed performance across the four marked states. Findings. Relative to the noiseless baseline, modeled noise reduces success probability by approximately 26.2%. The detailed model yields a success probability 2.8% above the experimental average from [6]. This difference may partly reflect an underestimate of the experimental gate errors: Main et al. [6] report that the measured teleported-CZ error exceeds the component error-budget prediction and attribute this discrepancy to calibration drift. IV. E VALUATION ON C OMPILER , N ETWORK & M EMORY Following validation against the two-node Grover experiment, we use SeQUeNCe.DQC to study how compiler strategy, network topology, and memory-capacity distribution affect execution time and success probability for larger Grover circuits. Throughout this section, Grover’s success probability is estimated from 1,000 distributed circuit executions per configuration. We first evaluate simulator scaling and noise sensitivity, then compare architectural choices using the ket-vector backend at z = 0.95 (Table IV). Table II summarizes the experimental configurations. For an n-qubit Grover search, the circuit builder uses n − 2 ancilla qubits to decompose multicontrolled operations, giving 2n − 2 circuit qubits in total, all stored in data memories, excluding communication qubits. In Table II, Data and Comm denote the numbers of data and communication qubits per node. Throughout this section, links are 5 km long, light propagates through fiber at 2 × 108 m/s, and memory and detector efficiencies are both 0.9. Local gates are assumed to take 1µs (typical for neutral atoms). TABLE II E XPERIMENTAL CONFIGURATIONS . Evaluation Target

n

Topology

Scaling Limits (Table III) Noise Sensitivity (Fig. 4) Compilers (Fig. 5) Topology (Fig. 6a) Capacity (Fig. 6b)

2–10 6 4 6 7

Star (2n − 2 nodes) 2-node star 2-node link Star / Grid / Caveman 4-node line

Data

Comm

1 5 3 1 Varied (12 total)

8–34 8 8 8 8

n

Nodes

Qubits

Iter.

T ELE G ATE

Local gates

Exec. time (ms)

Wall time (s)

2 3 4 5 6 7 8 9 10

2 4 6 8 10 12 14 16 18

2 4 6 8 10 12 14 16 18

1 2 3 4 6 8 12 17 25

2 52 150 296 588 976 1752 2890 4850

14 107 280 533 1038 1703 3032 4973 8310

10.8 70.2 207.4 423.3 887.4 1467.7 2630.4 4382.5 7424.7

0.0 0.1 0.4 1.1 3.5 13.2 71.5 1249.3 4236.3

TABLE IV C OORDINATED HARDWARE QUALITY PARAMETER z (T1 =100 S FIXED ). z

F1q

F2q

Fm

0.00 0.25 0.50 0.65 0.80 0.90 0.95 1.00

0.99900 0.99925 0.99950 0.99965 0.99980 0.99990 0.99995 1.00000

0.99910 0.99933 0.99955 0.99969 0.99982 0.99991 0.99996 1.00000

0.99600 0.99700 0.99800 0.99860 0.99920 0.99960 0.99980 1.00000

Fphys

T2 (s)

0.96500 2.00 0.97375 2.67 0.98250 4.01 0.98775 5.73 0.99300 10.03 0.99650 20.07 0.99825 40.14 1.00000 199.99

A. Simulator Scaling and Noise Sensitivity Scaling constraints. To examine the computational cost of full-state simulation, we evaluate distributed Grover on a (2n − 2)-node star network (sweeping n from 2 to 10 data qubits) where every two-qubit gate requires an inter-node T ELE G ATE. The hub node in the star network is provisioned with max(8, 4n−6) communication qubits to accommodate increasing telegate concurrency as circuit width grows. As shown in Table III, simulated Grover search circuit execution time increases from 10.8 ms to 7.4 s (∼ 690×), while simulator host wall-clock time grows exponentially. The largest evaluated circuit contains ten search qubits and eight ancillas and requires approximately 71 minutes of wall-clock time on an Apple M3 Pro chip, illustrating the computational cost of full-state discrete-event DQC simulation. Cross-layer noise sensitivity. To examine noise sensitivity, we use a coordinated hardware quality parameter z ∈ [0, 1] proposed in [24] that concurrently scales device-level gate fidelities, measurement errors, Bell-pair fidelity (Fphys ), and dephasing times (T2 ) (Table IV). Sweeping z on an n = 6 (10-qubit) two-node star illustrates how lower-level errors compound across teleported gates (Figure 4). We select z = 0.95 as an illustrative nonideal operating point for subsequent architectural comparisons. At this setting, the baseline success probability is 74.9%, allowing architectural effects to be examined in the presence of hardware noise. B. Compiler choice Setup. Two nodes are joined by a single physical link, each with a data-memory capacity of three. The workload is optimal-iteration (three-iteration) distributed 4-qubit Grover (six qubits total, including the two ancillas of the

Fig. 4. Distributed Grover (n=6) success probability versus hardware quality z (Table IV), linking physical device noise directly to algorithmic outcome.

CX-decomposed oracle), with marked state |1111⟩. Using four compilers, we compile the workload eight ways: the random and qap partition baselines, our FGP time-sliced compiler at three operating points, and one external compiler to demonstrate framework flexibility. Because SeQUeNCe .DQC is compiler-agnostic, its run function accepts any object implementing compile(circuit, topology, seed)→CompiledProgram. Users can supply custom circuit partitioning and remote operation planning strategies or external tool outputs, which share the same simulation runtime. We demonstrate this capability with Amaro [25], a compiler generator synthesizing qubit mapping-and-routing compilers from high-level device specifications. Our specification (dqc_hybrid.qmrl) models each QPU as an internal clique. Inter-node interactions use either an in-place T ELE G ATE at link_cost or a T ELE DATA relocation at teleport_cost. Amaro generates a solver that minimizes the specified cost of circuit partitioning and remote operation planning. An AmaroCompiler adapter converts the circuit to OpenQASM and the network to an architecture graph, then translates the solver’s per-step qubit assignments into a CompiledProgram. This allows compiler outputs to be compared using simulated execution time and success probability, alongside their abstract costs. We evaluate T ELE G ATE:T ELE DATA cost ratios of 1:2, 2:2, and 3:2 (Figure 5). These ratios specify the relative costs assigned to one T ELE G ATE operation and one T ELE DATA move in the compiler’s objective, rather than their simulated execution times. Findings. The random baseline scatters qubits and requires 87 T ELE G ATEs on average (107 ms), whereas qap reduces this to 48 T ELE G ATEs (54.6 ms). At default operating points, both FGP and Amaro adopt pure-T ELE G ATE strategies on Grover’s uniform interaction pattern. When incentivized, however, both leverage the T ELE G ATE/T ELE DATA trade-off: lowering FGP’s relocation margin yields a hybrid plan with 6 T ELE G ATEs and 24 T ELE DATA moves (31.4 ms)—the fastest plan evaluated, achieving a 42% runtime reduction over qap. Lowering the margin even further results in a pure-T ELE DATA schedule (104 moves; 99.9 ms). Increasing Amaro’s assigned T ELE G ATE cost relative to T ELE DATA produces a hybrid plan (5 T ELE G ATEs and 42 T ELE DATA moves; 42.1 ms). At a cost ratio of 3:2, Amaro produces a pure-T ELE DATA schedule with 56 moves, taking 56.9 ms—slightly longer than the pure-

Fig. 5. Execution time and Grover’s success probability of eight compilations of the same 2-node Grover (n=4). Bars annotate success at z=0.95.

T ELE G ATE plan’s 54.6 ms. Success rate generally decreases with increased number of T ELE G ATE and T ELE DATA operations, because more network operations result in extra entanglement overhead. The random and FGP all-move strategies produced success rates of 78.6% and 73.2%, respectively, whereas the FGP low-margin compiler produced the highest success rate of 89.3%. C. Network Topology Setup. We evaluate the FGP compiler across three 10-node networks with distinct edge structures: a star (one hub, nine spokes), a grid (2×5 mesh), and a caveman graph (two 5cliques joined by a single bridge). Because each node has a capacity of 1 (holding 10 total qubits for an n = 6 distributed Grover circuit), every two-qubit gate is inherently an internode T ELE G ATE. We measure success under z = 0.95 noise. Findings. FGP produces 588 T ELE G ATE operations and no T ELE DATA moves on all three topologies (Figure 6a). With one data-memory slot per node, relocation cannot make gates local. Instead, performance is governed by the hop distance of T ELE G ATE operations. Single-hop T ELE G ATEs require one heralded Bell pair, whereas two-hop T ELE G ATEs require two pairs connected by an entanglement swap, adding latency and error overhead. The star topology routes spoke-to-spoke gates through the hub, resulting in 396 two-hop T ELE G ATEs; the grid has 192, and the caveman has only 48 because interactions concentrate inside cliques. Total Bell-pair consumption drops from 984 (star) to 780 (grid) to 636 (caveman). Execution times are 887.4 ms, 818.1 ms, and 733.6 ms for star, grid, and caveman, respectively. Caveman has the lowest Bell-pair requirement and the highest observed success probability (27.1%). The grid follows (21.2%), while the star— despite the identical T ELE G ATE count—has the lowest success (15.0%): its 396 two-hop T ELE G ATEs each consume two heralded pairs across the 5 km links, so it accumulates the most entanglement noise and idle dephasing. D. Memory-Capacity Distribution Setup. We evaluate a fixed four-node line network (m0 –m1 – m2 –m3 ) with a constant total data capacity of twelve slots. We

compilation algorithms that jointly optimize remote gates and qubit relocation while accounting for network topology and communication costs. Our experiments also show that DQC performance depends on communication paths and memory distribution, even when the number of remote gates or total memory capacity is fixed. Future work will extend SeQUeNCe.DQC to switch-centric quantum data center networks [23]. Our wide-area simulations suggest that small-area quantum data centers may better support DQC by reducing communication overhead. We will also study scheduling and resource contention when multiple distributed circuit requests overlap. Finally, we will extend SeQUeNCe.DQC beyond its current assumptions of full intra-QPU connectivity and uncorrected noise, incorporating realistic internal topologies and fault-tolerance models. Fig. 6. Same FGP compiler; the network drives execution time and success probability. (a) Three 10-node topologies at capacity 1: identical T ELE G ATE count (588), yet the star’s hub serializes traffic and runs ∼ 20% slower. (b) Fixed four-node line, fixed total memory (12 slots): concentrating capacity co-locates interacting qubits.

vary slot allocation across nodes: balanced ([3, 3, 3, 3]), midconcentrated ([6, 3, 2, 1]), and highly skewed ([9, 1, 1, 1]). The workload is n = 7 optimal-iteration distributed Grover (12 total qubits: 7 data + 5 ancillas), completely filling available data memory. We employ FGP with a reduced relocation margin to enable hybrid T ELE G ATE and T ELE DATA execution. Findings. Reallocating memory capacity across nodes significantly alters execution time and success probability (Fig. 6b). Under the selected FGP policy, the balanced layout ([3, 3, 3, 3]) produces 369 network operations (17 T ELE G ATEs and 352 T ELE DATA moves). This high network operation count yields the longest runtime (410.7 ms) and lowest success probability (27.0%) under z = 0.95 noise. In contrast, concentrating memory capacity creates a hub co-locating frequently interacting qubits. The mid-concentrated layout reduces total network operations to 275 (143 T ELE G ATEs + 132 moves), lowering runtime to 262.0 ms and raising success probability to 49.7%. The highly skewed layout ([9, 1, 1, 1]) achieves the best performance, dropping operations to 145 (17 T ELE G ATEs + 128 moves), reducing execution time to 165.5 ms, and achieving a 52.6% success rate. In these evaluations, topology changes communication paths, whereas memory allocation changes the mix and number of remote operations. V. C ONCLUSION AND F UTURE W ORK We presented SeQUeNCe.DQC, extending the open-source SeQUeNCe simulator with circuit compilation and execution control integrated with heralded entanglement protocols for full-stack DQC evaluation. We validated the framework by reproducing a two-node trapped-ion Grover experiment in simulation, obtaining 73.8% success under the detailed noise model versus the measured 71%. Hybrid T ELE G ATE/T ELE DATA plannings with selective qubit relocation outperform both gate teleportation only and aggressive state movement in the evaluated workload. This finding motivates further research into

R EFERENCES [1] M. Caleffi et al., “Distributed quantum computing: A survey,” Computer Networks, vol. 254, 2024. [2] D. Barral et al., “Review of distributed quantum computing: From single qpu to high performance quantum computing,” Com. Sci. Rev., 2025. [3] S. DiAdamo et al., “Distributed quantum computing and network control for accelerated vqe,” IEEE TQE, vol. 2, p. 1–21, 2021. [4] Y.-C. Wei et al., “Universal distributed blind quantum computing with solid-state qubits,” Science, vol. 388, no. 6746, pp. 509–513, 2025. [5] H. Jacinto et al., “Network requirements for distributed quantum computation,” Phys. Rev. Res., vol. 8, p. 013205, 2026. [6] D. Main et al., “Distributed quantum computing across an optical network link,” Nature, vol. 638, no. 8050, pp. 383–388, 2025. [7] A. J. Menssen et al., “Strategic plan for neutral atom quantum computation.” [8] C. Cabrillo et al., “Creation of entangled states of distant atoms by interference,” Physical Review A, vol. 59, 1999. [9] S. D. Barrett et al., “Efficient high-fidelity quantum computation using matter qubits and linear optics,” Physical Review A, vol. 71, 2005. [10] C. Zhan et al., “Design and simulation of the adaptive continuous entanglement generation protocol,” in QCNC, 2025. [11] J. Chung et al., “InterQnet: A heterogeneous full-stack approach to codesigning scalable quantum networks,” IEEE TQE, 2026. [12] R. Parekh et al., “Quantum Algorithms and Simulation for Parallel and Distributed Quantum Computing,” in IEEE/ACM QCS, 2021. [13] T. Häner et al., “Distributed quantum computing with qmpi,” in ACM SC, 2021. [14] D. Ferrari et al., “A design framework for the simulation of distributed quantum computing,” in HPQCI, 2024. [15] S. Muralidharan, “The simulation of distributed quantum algorithms,” The Journal of Supercomputing, vol. 81, 2025. [16] J. Vázquez-Pérez et al., “Cunqa: a distributed quantum computing emulator for hpc,” 2025. [17] S. Zhang et al., “An end-to-end distributed quantum circuit simulator,” 2025. [18] M. Silver et al., “Q-DICE: Quantum distributed interconnect compiler and emulator,” 2026. [19] H. Zhang et al., “SwitchQNet: Optimizing distributed quantum computing for quantum data centers with switch networks,” in ISCA, 2025. [20] K. Campbell, “dqc simulator: an easy-to-use distributed quantum computing simulator,” 2026. [21] X. Wu et al., “SeQUeNCe: a customizable discrete-event simulator of quantum networks,” Quantum Science and Technology, vol. 6, 2021. [22] J. M. Baker et al., “Time-sliced quantum circuit partitioning for modular architectures,” in ACM Inter. Conf. on Computing Frontiers (CF), 2020. [23] S. Pouryousef et al., “Benchmarking quantum data center architectures: A performance and scalability perspective,” in IEEE QCE, 2026. [24] S. Patange et al., “Realistic simulation of quantum repeater with encoding and classical error correction,” in IEEE QCE, 2026. [25] A. Molavi et al., “Generating compilers for qubit mapping and routing,” ACM on Programming Languages, 2026.

Related documents

• SeQUeNCe.DQC: Full-stack Simulation of Distributed Quantum Computing#1490871
• Democratizing Atomistic Simulation Workflows for the AI Era with the Quantum Accelerator#1118896
• A Modular, Topology-Aware Software Stack for Entanglement-Based Distributed Quantum Computing#1109698
• dqc_simulator: an easy-to-use distributed quantum computing simulator#1233822
• SemQBench: Benchmarking Decomposition-Aware Runtime Policies for Quantum-HPC Search#1387175