Enabling Dynamic Resource Scaling in Quantum Circuit Simulations

arXiv:2610.39824v1 [cs.DC] 29 Oct 2026

Enabling Dynamic Resource Scaling in Quantum Circuit Simulations 1st Íñigo Aréjula-Aı́sa

2nd Sergio Iserte

3rd Petter Sandås

Barcelona Supercomputing Center (BSC) 0009-0006-7354-0915

Barcelona Supercomputing Center (BSC) 0000-0003-3654-7924

Barcelona Supercomputing Center (BSC) 0009-0009-2028-7719

3th Ricard. S. Raigada-Garcı́a

4th Oliver Brown

5th James Richings

Universitat Politècnica de Catalunya (UPC) Barcelona, Spain 0009-0009-2028-7719

Edinburgh Parallel Computing Centre (EPCC) Edinburgh, UK email address or ORCID

Edinburgh Parallel Computing Centre (EPCC) Edinburgh, UK email address or ORCID

8th Antonio J. Peña Barcelona Supercomputing Center (BSC) Barcelona, Spain 0000-0002-3575-4617

Abstract—Studies of quantum algorithms often simulate sequences of circuits whose number of qubits changes from one circuit to the next, such as instances of increasing size of the same problem. Since each additional qubit doubles the statevector, every circuit needs a different number of nodes, which a fixed allocation on a shared High-Performance Computing (HPC) system cannot provide: a job sized for the largest circuit leaves most of its nodes idle, and one job per circuit adds scheduler interactions and queue waits. We make the QuEST state-vector simulator malleable with the Dynamic Management of Resources (DMR) framework, so that a single job resizes between circuits. Because no state-vector exists between circuits, reconfigurations require no data redistribution and no changes to the simulation kernels, and a checkpoint holding the index of the next circuit is enough to resume. A right-sizing policy derives the number of nodes from the number of qubits, and the circuit_executor API hides reconfigurations from the user. We evaluate the reconfiguration overhead on MareNostrum 5 and show that a single job can run a batch of circuits of different sizes, adapting its allocation to each of them with negligible overhead. Index Terms—HPC-QC, Dynamic Resource Management, Quantum Circuit Simulation, MPI Malleability, State-vector

I. I NTRODUCTION Quantum computing (QC) is expected to speed up certain problems in chemistry, materials science, and optimization [1]. However, current and near-term quantum processors are limited by noise, small qubit counts, and shallow circuit depths, a regime known as Noisy Intermediate-Scale Quantum (NISQ) [2]. Until fault-tolerant hardware becomes available, quantum circuit simulators allow researchers to design, benchmark, and refine quantum algorithms on classical computers. Simulations

show how algorithms scale, how robust they are to noise, and how the constraints of real hardware affect them. Results from independent simulators are also cross-checked to validate complex circuits [3]. These studies often require many simulations, for instance to sweep parameters or noise models, and the cost of each simulation grows exponentially with the number of qubits. Simulators therefore rely on multithreading, distributed memory, and GPU acceleration, and run on platforms ranging from laptops to supercomputers. QuEST (Quantum Exact Simulation Toolkit) [4] is an opensource simulator of this kind. It simulates both state-vectors and density matrices, and thus both ideal and noisy circuits. It combines OpenMP multithreading, GPU acceleration with CUDA, and distribution with the Message Passing Interface (MPI), which allows it to simulate large circuits on supercomputers. Moreover, the size of the simulated circuits often changes and later circuits can depend on the results of earlier ones. A common pattern is to optimize the parameters of a variational algorithm on small instances and reuse them on larger ones. For instance, the scaling of the Quantum Approximate Optimization Algorithm (QAOA) [5] on the low autocorrelation binary sequences (LABS) problem has been studied with exact state-vector simulations of 24 to 40 qubits on up to 1,024 GPUs per simulation, using a single set of parameters obtained by optimizing on small instances and rescaled to every problem size [6]. Similarly, QAOA parameters optimized on small graphs can be transferred to much larger ones [7]. Since each additional qubit doubles the size of the state-vector, the resources needed by a distributed simulation change with every

circuit in the sequence. Static allocations on shared HighPerformance Computing (HPC) systems fit such sequences poorly: a job sized for the largest circuit keeps most of its nodes idle while the smaller circuits run, whereas one job per circuit multiplies the interactions with the scheduler and exposes every circuit to its own queue wait. This becomes worse when the system operates under restrictions, for instance by limiting the number of nodes per user or allowing only one running job at a time, since these jobs then cannot run concurrently and their queue waits add up one after another. Malleability, the ability of applications to adjust their resources at runtime, addresses this mismatch by allowing a simulation to expand or shrink its footprint as the sequence progresses. Malleable jobs can improve system utilization and reduce wait times [8]; a malleable job waits in the queue once, at submission, and although later expansions still depend on the availability of free nodes, shrinkages return idle nodes to the system. However, QuEST, like other distributed simulators, runs on an allocation fixed at launch. To close this gap, we integrate QuEST with the Dynamic Management of Resources (DMR) framework [9], which allows MPI applications to expand and shrink at runtime in coordination with the resource manager. We present a case study in which a single QuEST job runs a sequence of circuits of different sizes and adapts its number of nodes to each of them. We measure the reconfiguration overhead and discuss the usability benefits of this approach. The contributions of this paper are: (i) the design and implementation of a malleable version of QuEST that reconfigures at circuit boundaries, using the checkpoint-restart mode of DMR; (ii) a right-sizing policy that maps the number of qubits of each circuit to a number of nodes; (iii) the circuit_executor API, which hides reconfigurations from the user; and (iv) an evaluation of the reconfiguration overhead on MareNostrum 5. The rest of the paper is organized as follows. Section II provides background on QuEST and DMR. Section III reviews related work on malleability, distributed quantum simulation, and resource management for HPC-QC integration. Section IV describes the design of the integration, Section V evaluates it, Section VI discusses our findings and their limitations, and Section VII concludes the paper. II. BACKGROUND This section provides background on the two main components of our study: QuEST, a high-performance quantum circuit simulator, and DMR, a framework for enabling malleability in MPI applications. A. QuEST QuEST [4] is an open-source C/C++ library for the exact simulation of quantum circuits on state-vectors and density matrices. A state-vector of n qubits holds 2n complex amplitudes, 16 bytes each in double precision, and a density matrix of n qubits is stored as a vector of 22n amplitudes. QuEST provides different back-end algorithms [10], and combines OpenMP multithreading, GPU acceleration, and memory distribution with MPI.

gate on qn−1 process 0 2n−2 amplitudes

process 1 2n−2 amplitudes

process 2 2n−2 amplitudes

process 3 2n−2 amplitudes

buffer

buffer

buffer

buffer

local qubits q0 , . . . , qn−3 ; qn−2 , qn−1 select the process Fig. 1. Distribution of an n-qubit state-vector over P = 4 MPI processes in QuEST (k = 2). Each process stores a block of 2n−2 amplitudes and an equally sized communication buffer. Gates on local qubits need no communication; a gate on global qubit qn−1 pairs processes 0 ↔ 2 and 1 ↔ 3, which exchange amplitudes through their buffers via MPI.

In distributed mode, the 2n amplitudes are split evenly among P = 2k MPI processes, each holding a contiguous block of 2n−k amplitudes (Fig. 1). Hence, P must be a power of two and cannot exceed 2n , since every process must hold at least one amplitude. Gates acting only on the n − k low-order qubits are local and need no MPI communication, whereas the k high-order qubits index the process that holds an amplitude, so a gate on one of them pairs processes that exchange amplitudes. For this exchange, each process allocates a communication buffer of the same size as its block, which doubles the memory per process. B. DMR The Dynamic Management of Resources (DMR) framework1 is a middleware layer that enables process malleability [11] and runtime resource management for MPI applications in HPC environments. DMR acts as an orchestration layer connecting scientific applications, the MPI runtime (e.g., Open MPI/PRRTE (PMIx Reference Runtime Environment) [12]–[14]), performance monitoring tools (e.g., TALP [15]), and the underlying Resource Management System (RMS), e.g., Slurm [16]. Its primary goal is to allow running jobs to dynamically acquire, release, or reconfigure compute resources at runtime, enabling applications to transparently expand or shrink their resource footprint, thereby improving system utilization and responsiveness. Internally, DMR implements a state-driven architecture exposed to developers through a core API [17]: dmr_init: Initializes the dynamic environment, establishes communication with the RMS, and sets up internal data structures. • dmr_check: Called at synchronization points to indicate readiness for resizing; it evaluates policies and system feedback to determine whether reconfiguration is needed. • dmr_reconfigure: Performs the selected reconfiguration and coordinates with the MPI runtime to spawn or terminate processes as required. •

1 Pronounced “dimmer.”

dmr_finalize: Cleans up the management layer and releases allocated resources. A key advancement is the introduction of a non-invasive methodology tailored for production HPC clusters. While earlier approaches relied on customized or invasive scheduler modifications (e.g., Slurm4DMR) in controlled environments [9], the new DMR@Jobs feature enables malleable applications to interact directly with standard, unmodified RMS deployments through user-level API calls [18]. This approach orchestrates MPI processes across multiple independent jobs to achieve expansion and shrinkage without requiring administrative privileges. DMR also provides a unified programming model that supports both in-memory data redistribution via MPI and checkpoint-restart (C/R) mechanisms, adapting to diverse scientific codes and existing application-level checkpointing logic. The framework supports sophisticated reconfiguration strategies which allow applications to continue executing while resource requests are pending, so DMR hides resource acquisition latency in heavily contended production systems. This makes it a robust solution for bridging the gap between experimental malleability prototypes and operational supercomputing environments. •

III. R ELATED W ORK This section reviews work on malleability in HPC, on distributed state-vector simulation, and on resource management for HPC-QC integration, and positions our contribution with respect to them. a) Malleability in HPC: Feitelson and Rudolph classify parallel jobs by when and by whom their resources are decided [19]. Rigid and moldable jobs keep the resources assigned at launch, evolving jobs request changes initiated by the application, and malleable jobs adapt to changes decided by the system. Following common usage in MPI research, we use malleability for any job that changes its resources at runtime, whether the change is triggered by the application or by the RMS. Malleability can raise system throughput and resource utilization and shorten waiting times, yet it remains rare in production systems [20]. It requires support from the RMS, the MPI runtime, and the application, which must redistribute its data among a changing set of processes. At the runtime level, MPI provides dynamic process management to spawn processes. Malleability has traditionally been evaluated under dynamic workloads of scientific applications [21] and replayed production conditions [8]. In this work, we apply malleability to an MPI distributed quantum simulator and reconfigure it between circuits, where no state-vector must be redistributed. b) Distributed state-vector simulation: Since a statevector of n qubits holds 2n amplitudes, large circuits require distributing the state over many nodes. JUQCS [22], IntelQS [23], QuEST [4], SV-Sim [24], mpiQulacs [25], Qiskit Aer [26], and cuStateVec [27] partition the state-vector among processes or GPUs and exchange amplitudes for gates on non-local qubits; Jamadagni et al. benchmark many of these

packages on an HPC cluster [3]. For QuEST, Adamski et al. show that node type and CPU frequency trade runtime against energy and the compute units charged to the user [28], which illustrates that the best allocation depends on the circuit. All these simulators run on an allocation fixed at launch. Intel-QS can divide its allocation into groups that simulate a pool of related circuits in parallel [23], which also targets batches of circuits, but the partition holds for the whole execution. To the best of our knowledge, no distributed simulator adapts its allocation to the size of each circuit at runtime. c) Resource management for HPC-QC integration: The integration of quantum processors and simulators into HPC environments has motivated new programming tools [29] and resource-management strategies. Rocco et al. use malleability and workflows to release classical resources while computation is offloaded to a quantum processor and to reclaim them afterwards [30], and Cipollini et al. compare strategies to share a quantum processor among hybrid applications [31]. Closed-loop electronic-structure calculations already couple a quantum processor with a full supercomputer [32], and circuitcutting workflows split a circuit into many smaller subcircuits that are orchestrated on HPC resources [33], [34]. These works manage the classical resources around quantum stages. In contrast, we make the simulation stage itself malleable, so that it can be resized like any other classical stage of such workflows. d) Our position: This work lies at the intersection of the three lines above. It applies the malleability support of DMR to a distributed quantum simulator, which, to the best of our knowledge, has not been done before. The partitioning of QuEST remains unchanged; only the allocation it runs on changes between circuits. Resizes are driven by the application itself: the number of qubits of each circuit determines the allocation, and circuit boundaries provide reconfiguration points where no distributed state must be redistributed. The resulting malleable simulator can serve as a resizable stage in the HPC-QC workflows discussed above. IV. M ETHODOLOGY This section describes how we have designed and implemented the integration of DMR2 with QuEST3 to enable MPI malleability in quantum circuit simulations. We describe where and how reconfigurations take place (Section IV-A), the policy that decides the size of the job (Section IV-B), and the programming interface exposed to users (Section IV-C). In this regard, we aim to: (i) adapt the number of nodes of a single job to each of its circuits, (ii) leave the simulation kernels of QuEST untouched, confining the changes to register creation, and (iii) hide the reconfiguration logic from the user. A. Reconfiguration at Circuit Boundaries QuEST is designed with modularity in mind: its distributedmemory parallelism is provided by a separate MPI module that can be enabled or disabled at compile time. Following 2 https://zenodo.org/records/17831722 3 https://quest.qtechtheory.org

the same approach, we add a malleability module on top of the distributed-memory layer that interfaces with DMR, so that the core simulation logic is not modified. The central design decision is to reconfigure only between circuits, never during their execution. Each circuit allocates its quantum register, applies its gates, and destroys the register. At a circuit boundary there is therefore no distributed state-vector alive, and the only state that must survive a reconfiguration is the progress of the batch and the results of completed circuits, which each circuit writes to persistent storage and subsequent circuits can read as their input. This has two consequences: 1) No state-vector redistribution is needed, which would otherwise involve handling up to 2n amplitudes of data. Instead, the execution is relaunched on an expansion or a shrinkage; DMR respawns the MPI processes and the QuEST simulation restarts from the beginning of its entry point. 2) The checkpoint only contains the index of the next circuit to run. On restart, circuits before this index are skipped and execution resumes at the correct position. In QuEST, the most straightforward malleability point, i.e., the reconfiguration point where the MPI ranks are synchronized, is the creation of the quantum register. createQureg and its variants invoke the malleability module before allocating the register, which is the earliest moment at which the size of the circuit, n, is known and the previous register has already been released. If a resize is performed, the application restarts, skips the completed circuits, and re-enters the current one; this time the register creation finds the correct number of nodes and proceeds. After a resize, the only repeated work is the part of the current circuit that precedes the creation of its register. Any action with side effects in this part, such as writing output or seeding a random number generator, is executed again after the restart. Therefore, circuits must create their register before producing any output, and all the registers of a circuit must have the same size, since every register creation is a reconfiguration point. Because gates are always applied on a stable allocation, malleability cannot interfere with the simulation itself. Fig. 2 summarizes this execution flow. B. Automatic Node Right-Sizing At each reconfiguration point, a DMR reconfiguration policy designed for QuEST computes the target number of nodes for a register of n qubits as

N ∗ (n) = min max 2 n−L , 1 , Nmax , (1) where L is the number of local qubits per node, so that each node holds 2L amplitudes of the state-vector, and Nmax is the maximum number of nodes the job is allowed to hold. Registers with n ≤ L fit in a single node, and each additional qubit beyond L doubles the number of nodes until Nmax is reached. Since we run one MPI process per node, in the notation of Section II-A the policy sets k = n − L, so that each process keeps n − k = L local qubits, unless the

Job start / restart from main Read checkpoint i, skip circuits before i Circuit i: createQureg(ni ), compute N ∗ (ni ) (Eq. (1))

next circuit

N = N ∗ (ni )?

no

DMR reconfiguration

yes Apply gates, destroyQureg Write checkpoint i+1 last circuit Batch completed

Fig. 2. Execution flow of a malleable batch. Reconfigurations only take place at register creation, when no state-vector is alive; after a resize, the job restarts and resumes from the checkpointed circuit index.

allocation is capped at one node or at Nmax . We set L = 26, the threshold that QuEST v4 itself uses to decide whether createQureg distributes a register: it does so only if each node keeps at least 226 amplitudes. If the current node count N equals N ∗ (n), execution continues normally. If N < N ∗ (n), the policy requests an expansion before running the circuit; if N > N ∗ (n), it requests a shrinkage, and the released nodes are returned to the RMS, where they become available to other jobs. Hence, N ∗ (n) is the largest allocation over which QuEST still distributes an n-qubit register; on a larger one, createQureg would not distribute it and the additional nodes would do no useful work. The policy is evaluated synchronously: the executor waits for the outcome of the reconfiguration before running the circuit, instead of overlapping the wait with computation. The outcome is a request rather than a command, since DMR evaluates it against the state of the system; if it is not granted, the executor waits and retries the request until it is. C. Programming Interface Using the mechanism above directly would require the user to guard each circuit against re-execution after a restart and to manage the DMR environment explicitly. To hide these details, we introduce the circuit_executor, which manages the execution of a batch of circuits. Users register each circuit as a function, and the executor runs them in order, maintains the checkpoint, and wraps the initialization and finalization of DMR. A circuit is a plain C function with no arguments and no return value (void (*)(void)) that creates its register, applies its gates, reports its results, and destroys the register, so that it is self-contained and can be re-executed from the start after a restart. Listing 1 shows a batch of three circuits of different sizes. Compared with a non-malleable QuEST program, the changes



Listing 1. Running a set of circuits with the circuit_executor API.

are limited to wrapping each circuit in a function, registering it, and calling the executor. Because the whole batch is known before execution starts, the executor runs circuits in registration order; no reordering is performed. V. E VALUATION We first measure the cost of a reconfiguration in isolation (Section V-A) and then run a batch of circuits with the circuit_executor (Section V-B). All the experiments are executed on MareNostrum 5 (MN5), a pre-exascale system integrated into the EuroHPC-JU infrastructure4 . Specifically, jobs are submitted to its generalpurpose partition (GPP)5 , which comprises 6,192 Intel Sapphire Rapids-based nodes, each equipped with two Intel Xeon Platinum 8480+ processors (56 cores at 2 GHz, 112 cores total) and 256 GB of DDR5 memory, interconnected by a 100 Gbit/s ConnectX-7 NDR200 InfiniBand network. The core software stack relies on Open MPI 5.1.0a1, PRRTE 5.0.0a1, OpenPMIX 7.0.0a1, DLB 3.5.0, and DMR 2.0.2. QuEST v4.2.06 , extended with the malleability module designed in this work, is built in Release mode in double precision, with distribution (MPI) and multithreading (OpenMP) enabled. Each node runs a single MPI process with 112 OpenMP threads, and nodes are allocated exclusively. To avoid the waiting times of the production queue and make the experiments easier to reproduce, they run under Slurm4DMR, a malleability-enabled, user-level instance of Slurm deployed inside a regular MN5 job. A. Malleability Overhead Before running a batch of circuits, we measure the cost of a reconfiguration in isolation. A minimal QuEST application performs every transition between the power-of-two node counts from 1 to 64. For each pair (a, b), a separate job is launched on a nodes and expands or shrinks to b nodes. Each transition is repeated three times, and Fig. 3 reports the mean overhead. 4 https://bsc.es/marenostrum/marenostrum-5 5 https://www.bsc.es/supportkc/docs/MareNostrum5/overview/#marenostr um-5-gpp-general-purpose-partition 6 https://github.com/QuEST-Kit/QuEST

1 1

2

to (nodes) 8 16

32

64

1.23 1.24 1.40 1.53 1.69 2.02

2 0.34



4

1.28 1.40 1.50 1.66 1.97

4 0.36 0.44

2.00 1.75 1.50

1.41 1.53 1.67 1.98

1.25

1.45 1.68 1.97

1.00

1.69 1.95

0.75

1.95

0.50

8 0.37 0.45 0.49 16 0.41 0.49 0.52 0.53

32 0.48 0.55 0.59 0.60 0.62 64 0.56 0.64 0.67 0.68 0.71 0.78

overhead (s)



1 initQuESTEnv(); 2 circuit_executor_init(argc, argv); 3 4 circuit_executor_add(circuit_32q); 5 circuit_executor_add(circuit_16q); 6 circuit_executor_add(circuit_8q); 7 8 circuit_executor_run(); 9 10 circuit_executor_destroy(); 11 finalizeQuESTEnv();

from (nodes)



0.25 0.00

Fig. 3. Reconfiguration overhead on MN5 (mean of three repetitions). Rows give the source and columns the target number of nodes: expansions lie above the diagonal and shrinkages below it.

The measured time covers the whole transition: DMR evaluates the action (expand, shrink, or none); in an expansion, the new nodes are acquired from Slurm and added to the PRRTE distributed virtual machine, whereas in a shrinkage the released nodes are returned to Slurm (and asynchronously removed from PRRTE); the processes are respawned on the target nodes; and the MPI, DMR, and QuEST environments are initialized in the new processes. The respawn uses MPI_Comm_spawn, whose cost depends on the number of created processes [35]. No quantum register is allocated during this interval, since a circuit creates its register only after the reconfiguration completes. Expansions take between 1.23 and 2.02 s, and their cost is set by the target size: about 1.25 s to reach 2 or 4 nodes, 1.45 s to 8 or 16, 1.7 s to 32, and 2.0 s to reach 64 nodes. Shrinkages take between 0.34 and 0.78 s and grow slowly with both sizes: shrinking to one node takes from 0.34 s (from two nodes) to 0.56 s (from 64), and shrinking from 64 nodes takes from 0.56 s (to one node) to 0.78 s (to 32). The gap between both directions comes from the steps that only expansions perform synchronously. Before spawning processes, an expansion must obtain the new nodes from Slurm and extend the PRRTE distributed virtual machine to them, whereas a shrinkage removes nodes as a background operation because they do not participate in the spawning. B. Batch Execution We run a batch of circuits with the circuit_executor API. Since reconfigurations take place only between circuits, every circuit runs entirely on a fixed allocation: from the moment its register is created, through the application of its gates, until its result is read, the circuit executes exactly as it would in a non-malleable run. Malleability only determines the number of nodes on which each circuit starts.

Each circuit applies the Quantum Fourier Transform (QFT) to an n-qubit register. The register is allocated with createQureg, initialized to |0⟩⊗n with initZeroState, and transformed by a sequence of Hadamard gates and controlled phase shifts (applyHadamard and apply TwoQubitPhaseShift). An n-qubit QFT applies n Hadamard gates and n(n − 1)/2 controlled phase shifts, and each gate updates every amplitude of the local block. Finally, the probability of the basis state |0 · · · 0⟩ is computed with calcProbOfBasisState. The batch consists of seven circuits of 28, 30, 24, 36, 31, 32, and 34 qubits, executed in this order. With L = 26 and Nmax = 64, Eq. (1) assigns them 4, 16, 1, 64, 32, 64, and 64 nodes, respectively (see the first and second columns of Table I). Keeping 226 amplitudes per node, the 34- and 36-qubit circuits would need 256 and 1,024 nodes; they are therefore capped at Nmax , and each node holds 228 and 230 amplitudes, respectively. We chose this order to alternate register sizes, so that consecutive circuits require different allocations and a single run includes both expansions and shrinkages, while the last circuit covers the case in which no reconfiguration is needed. Users do not need to size the job for its circuits: the job can be submitted requesting a single node, and the executor then adapts its resources. Before the first circuit (28 qubits), the executor expands the job to 4 nodes. It then expands to 16 nodes for the 30-qubit circuit, shrinks to a single node for the 24-qubit circuit, expands to 64 nodes for the 36qubit circuit, shrinks to 32 nodes for the 31-qubit circuit, and expands back to 64 nodes for the 32-qubit circuit. The 34-qubit circuit runs on the same 64 nodes without reconfiguring, since DMR is only invoked when the right-sizing policy selects a different number of nodes. The batch therefore performs six reconfigurations, four expansions and two shrinkages, which are listed as transitions in the fourth column of Table I. Submitting the job directly on 4 nodes would avoid the first expansion, but requires the user to know the size of the first circuit and the right-sizing policy in advance. Without malleability, this workload would run either as a static 64-node job, with up to 63 idle nodes during the smaller circuits, or as seven independent jobs, each with its own queue wait. With the circuit_executor, the entire batch is handled within a single job that dynamically adjusts its footprint, reducing the total number of scheduler interactions and the associated queue wait time of each job. Notice that when expanding in the malleable scenario, the requests are also affected by the queue wait time, although these requests are smaller, since only the missing nodes are requested. The third column of Table I presents the execution time of the circuits, which is driven by the number of amplitudes per node (computational load) and the number of involved global qubits (internode communication). In particular, in direct qubit-node relationships where the number of amplitudes is proportional to the number of nodes, i.e., the node count scales with the state-vector (e.g., 28-4, 30-16, 31-32, 32-64), the execution time increases with the number of nodes from

41.3 to 52.6 s. Outside this direct relationship (e.g., 24-1, 3464, 36-64) the time is ruled by the number of amplitudes per node. On the capped 64-node allocation, each additional pair of qubits quadruples the work per node and the execution time (52.6, 235.1, and 1044.1 s for 32, 34, and 36 qubits). Regarding reconfigurations, the fifth column of Table I reports the overhead times measured as in the previous section: from the decision until execution resumes. The full overheads grow with the target allocation (1.41, 1.64, 2.14, and 2.02 s for the four expansions) and are within 4–14% of those measured in isolation in Fig. 3. TABLE I C IRCUIT EXECUTION TIMES AND TRANSITION RECONFIGURATION OVERHEADS FOR THE EVALUATED SEVEN - CIRCUIT BATCH . E ACH TRANSITION TAKES PLACE AFTER THE CIRCUIT IN THE SAME ROW; THE FIRST ROW IS THE INITIAL SINGLE - NODE ALLOCATION . Qubits

Nodes

Execution Time (s)

Transition

Reconfiguration Time (s)

– 28 30 24 36 31 32 34

1 4 16 1 64 32 64 64

– 41.331 47.050 7.944 1044.113 49.345 52.593 235.057

1→4 4 → 16 16 → 1 1 → 64 64 → 32 32 → 64 – –

1.41 1.64 0.44 2.14 0.81 2.02 – –

VI. D ISCUSSION In this section, we discuss the implications of our findings from the evaluation of the integration of QuEST with DMR. We analyze the benefits and limitations of using malleability for quantum circuit simulations on HPC systems, and we explore potential future directions for research in this area. The current right-sizing policy keeps a fixed number of local qubits per node, so the allocation grows with the size of the state-vector regardless of the circuit. However, the optimal allocation from a performance standpoint depends on the circuit itself, since communication overhead grows with the number of global qubits and can outweigh the benefit of additional parallelism, especially for circuits with a low computational load. Incorporating performance models or online profiling into the right-sizing decision would allow the simulator to pick a better trade-off between parallelism and communication cost [36]. The execution model of the circuit_executor also leaves room for improvement. Currently, circuits run sequentially: the next circuit starts only when the previous one has finished. A natural extension is to allow concurrent execution. For example, if a 32-node circuit is running and three 16-node circuits are waiting in the queue, the executor could request 16 additional nodes in advance. Once the 32-node circuit finishes and those nodes are freed, the three smaller circuits could start simultaneously using all 48 nodes at once, instead of running one after another. This would improve resource utilization and reduce the total time to complete a workload.

Variational algorithms alternate circuit evaluations with a classical optimizer that chooses the parameters of each evaluation from the results of the previous ones [37]. Within one problem instance, all evaluations use the same number of qubits, so the loop triggers no resize. Resizes appear when instances of increasing size are chained, as in the QAOA studies that transfer parameters from smaller to larger instances [6], [7], and then the optimizer state must survive each restart. The current executor already supports this case: since a circuit is a user-defined function, it can read its results from the register, run the optimizer update, and persist the new parameters before it returns, so that the checkpoint written after the circuit also covers this classical step. A natural extension is to let users register such state with the executor, which would then save it in the checkpoint next to the index of the next circuit and restore it transparently after a restart. More generally, malleability currently applies to the circuits of the batch, not to the whole application: the code outside the executor runs again after every restart, so it should be limited to setting up the environment. Making complete hybrid workflows malleable, including their classical stages, is left for future work. A further step is a persistent, adaptive simulation service. Instead of one job per workflow, a long-running service could hold a pool of nodes and run circuits as they arrive, resizing the pool for each of them. Circuits would then avoid the queue wait and the startup of a new job; only expansions of the pool would wait for the scheduler to grant nodes. CUNQA [38] already deploys simulators as a service on HPC systems, where users submit circuits to a pool of virtual quantum processing units (vQPUs), but the resources and layout of these vQPUs are fixed when the service is deployed. Combined with DMR, such a service could change at each reconfiguration not only its number of nodes, but also how they are grouped into vQPUs and how each vQPU is configured, since every restart rebuilds the processes from scratch. The virtual hardware would then match the circuits being submitted. VII. C ONCLUSION This paper has presented a malleable version of the QuEST simulator for sequences of circuits whose number of qubits changes from one circuit to the next. Built on the DMR framework, a single job adapts its number of nodes to each circuit, instead of holding the allocation of the largest circuit for the whole sequence or submitting one job per circuit. The design reconfigures only between circuits, when no state-vector is alive. As a result, no amplitudes are redistributed, the simulation kernels of QuEST remain unchanged, and a checkpoint holding the index of the next circuit is enough to resume after a resize. A right-sizing policy maps the number of qubits of each circuit to a power-of-two number of nodes, and the circuit_executor API hides the reconfigurations: users wrap and register their circuits, and can submit the job on a single node without sizing it in advance. On MareNostrum 5, reconfigurations between 1 and 64 nodes measured in isolation take 0.34 to 0.78 s for shrinkages

and 1.23 to 2.02 s for expansions, which must also acquire the new nodes and extend the PRRTE distributed virtual machine before spawning processes. Future work includes right-sizing policies based on performance models that balance parallelism against communication, concurrent execution of circuits within the executor, checkpoints that also store user-defined state such as optimizer parameters, and a persistent malleable simulation service for HPC-QC workflows. ACKNOWLEDGMENT BSC researchers have been financially supported by the Ministry of Economic Affairs and Digital Transformation of the Spanish Government through the QUANTUM ENIA project call - Quantum Spain project, and by the Ministerio para la Transformación Digital y de la función pública, within the framework of the Plan de Recuperación Transformación y Resiliencia, and by the European Union — NextGenerationEU and the framework of the Digital Spain 2026 Agenda. Antonio J. Peña was partially supported by the Ramón y Cajal fellowship RYC2020-030054-I funded by MCIN/ AEI/10.13039/501100011033 and by “ESF Investing in your future”. The views and opinions expressed are solely those of the authors and do not necessarily reflect those of the European Union. Neither the European Union nor the European Commission can be held responsible for them. Language polishing was performed using an AI language model, with subsequent thorough review and editing by the authors. The authors take full responsibility for the final manuscript content. R EFERENCES [1] A. Montanaro, “Quantum algorithms: an overview,” npj Quantum Information, vol. 2, p. 15023, 2016. [2] J. Preskill, “Quantum computing in the NISQ era and beyond,” Quantum, vol. 2, p. 79, Aug. 2018. [3] A. Jamadagni Gangapuram, A. M. Läuchli, and C. Hempel, “Benchmarking quantum computer simulation software packages: State vector simulators,” SciPost Physics Core, vol. 7, p. 075, 2024. [4] T. Jones, A. Brown, I. Bush, and S. C. Benjamin, “QuEST and high performance simulation of quantum computers,” Scientific Reports, vol. 9, no. 1, p. 10736, Jul. 2019. [Online]. Available: https://doi.org/10.1038/s41598-019-47174-9 [5] E. Farhi, J. Goldstone, and S. Gutmann, “A quantum approximate optimization algorithm,” arXiv:1411.4028, 2014. [6] R. Shaydulin, C. Li, S. Chakrabarti, M. DeCross, D. Herman, N. Kumar, J. Larson, D. Lykov, P. Minssen, Y. Sun, Y. Alexeev, J. M. Dreiling, J. P. Gaebler, T. M. Gatterman, J. A. Gerber, K. Gilmore, D. Gresh, N. Hewitt, C. V. Horst, S. Hu, J. Johansen, M. Matheny, T. Mengle, M. Mills, S. A. Moses, B. Neyenhuis, P. Siegfried, R. Yalovetzky, and M. Pistoia, “Evidence of scaling advantage for the quantum approximate optimization algorithm on a classically intractable problem,” Science Advances, vol. 10, no. 22, p. eadm6761, 2024. [7] A. Galda, E. Gupta, J. Falla, X. Liu, D. Lykov, Y. Alexeev, and I. Safro, “Similarity-based parameter transferability in the quantum approximate optimization algorithm,” Frontiers in Quantum Science and Technology, vol. 2, p. 1200975, 2023. [8] S. Iserte, M. Madon, G. Da Costa, J.-M. Pierson, and A. J. Peña, “MPI malleability validation under replayed real-world HPC conditions,” Future Generation Computer Systems, p. 108305, Dec. 2025. [Online]. Available: https://doi.org/10.1016/j.future.2025.108305

[9] S. Iserte, I. Martı́n-Álvarez, K. Rojek, J. I. Aliaga, M. Castillo, and A. J. Peña, “Towards the democratization and standardization of dynamic resources with MPI spawning,” in Parallel Processing and Applied Mathematics, 2025, pp. 287–300. [10] T. Jones, B. Koczor, and S. C. Benjamin, “Distributed simulation of statevectors and density matrices,” arXiv:2311.01512, 2023. [Online]. Available: https://arxiv.org/abs/2311.01512 [11] D. G. Feitelson, “Packing schemes for gang scheduling,” in Job Scheduling Strategies for Parallel Processing, 1996, pp. 89–110. [Online]. Available: https://doi.org/10.1007/BFb0022289 [12] E. Gabriel, G. E. Fagg, G. Bosilca, T. Angskun, J. J. Dongarra, J. M. Squyres, V. Sahay, P. Kambadur, B. Barrett, A. Lumsdaine, R. H. Castain, D. J. Daniel, R. L. Graham, and T. S. Woodall, “Open MPI: Goals, concept, and design of a next generation MPI implementation,” in Recent Advances in Parallel Virtual Machine and Message Passing Interface, 2004, pp. 97–104. [Online]. Available: https://doi.org/10.1007/978-3-540-30218-6 19 [13] “PRRTE: The PMIx reference RunTime environment,” https://github.c om/openpmix/prrte, accessed: Oct. 2026. [14] R. H. Castain, J. Hursey, A. Bouteiller, and D. Solt, “PMIx: Process management for exascale environments,” Parallel Computing, vol. 79, pp. 9–29, 2018. [15] V. Lopez, G. Ramirez Miranda, and M. Garcia-Gasulla, “TALP: A lightweight tool to unveil parallel efficiency of large-scale executions,” in Proceedings of the 2021 on Performance EngineeRing, Modelling, Analysis, and VisualizatiOn STrategy, ser. PERMAVOST ’21, 2021, p. 3–10. [Online]. Available: https://doi.org/10.1145/3452412.3462753 [16] A. B. Yoo, M. A. Jette, and M. Grondona, “SLURM: Simple linux utility for resource management,” in Job Scheduling Strategies for Parallel Processing, 2003, pp. 44–60. [Online]. Available: https://doi.org/10.1007/10968987 3 [17] S. Iserte, R. Mayo, E. S. Quintana-Ortı́, and A. J. Peña, “DMRlib: Easy-coding and efficient resource management for job malleability,” IEEE Transactions on Computers, vol. 70, pp. 1443–1457, Sep. 2020. [Online]. Available: https://doi.org/10.1109/TC.2020.3022933 [18] P. Sandås, S. Iserte, G. Houzeaux, and A. J. Peña, “Dynamic resource management in production HPC clusters,” arXiv:2606.13266, 2026. [Online]. Available: https://arxiv.org/abs/2606.13266 [19] D. G. Feitelson and L. Rudolph, “Toward convergence in job schedulers for parallel supercomputers,” in Job Scheduling Strategies for Parallel Processing, ser. Lecture Notes in Computer Science, vol. 1162. Springer, 1996, pp. 1–26. [20] A. Tarraf, M. Schreiber, A. Cascajo, J.-B. Besnard, M.-A. Vef, D. Huber, S. Happ, A. Brinkmann, D. E. Singh, H.-C. Hoppe, A. Miranda, A. J. Peña, R. Machado, M. Garcı́a-Gasulla, M. Schulz, P. Carpenter, S. Pickartz, T. Rotaru, S. Iserte, V. Lopez, J. Ejarque, H. Sirwani, C. D. Carothers, J. Carretero, and F. Wolf, “Malleability in modern HPC systems: Current experiences, challenges, and future opportunities,” IEEE Transactions on Parallel and Distributed Systems, vol. 35, no. 9, pp. 1551–1564, 2024. [21] S. Iserte, I. Martı́n-Álvarez, K. Rojek, J. I. Aliaga, M. Castillo, W. Folwarska, and A. J. Peña, “Resource optimization with MPI process malleability for dynamic workloads in HPC clusters,” Future Generation Computer Systems, p. 107949, 2025. [Online]. Available: https://doi.org/10.1016/j.future.2025.107949 [22] H. De Raedt, F. Jin, D. Willsch, M. Willsch, N. Yoshioka, N. Ito, S. Yuan et al., “Massively parallel quantum computer simulator, eleven years later,” Computer Physics Communications, vol. 237, pp. 47–61, 2019. [23] G. G. Guerreschi, J. Hogaboam, F. Baruffa, and N. P. D. Sawaya, “Intel quantum simulator: a cloud-ready high-performance simulator of quantum circuits,” Quantum Science and Technology, vol. 5, no. 3, p. 034007, 2020. [24] A. Li, B. Fang, C. Granade, G. Prawiroatmodjo, B. Heim, M. Roetteler, and S. Krishnamoorthy, “SV-Sim: Scalable PGAS-based state vector simulation of quantum circuits,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC ’21), 2021. [25] S. Imamura et al., “mpiQulacs: A distributed quantum computer simulator for A64FX-based cluster systems,” arXiv:2203.16044, 2022. [Online]. Available: https://arxiv.org/abs/2203.16044 [26] J. Doi and H. Horii, “Cache blocking technique to large scale quantum computing simulation on supercomputers,” in 2020 IEEE International Conference on Quantum Computing and Engineering (QCE), 2020, pp. 212–222.

[27] H. Bayraktar et al., “cuQuantum SDK: A high-performance library for accelerating quantum science,” in 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), 2023, pp. 1050–1061. [28] J. Adamski, J. P. Richings, and O. T. Brown, “Energy efficiency of quantum statevector simulation at scale,” in Proceedings of the SC ’23 Workshops of the International Conference on High Performance Computing, Network, Storage, and Analysis, 2023. [29] A. Elsharkawy, X.-T. M. To, P. Seitz, Y. Chen, Y. Stade, M. Geiger, Q. Huang, X. Guo, M. A. Ansari, C. B. Mendl, D. Kranzlmüller, and M. Schulz, “Integration of quantum accelerators with high performance computing—a review of quantum programming tools,” ACM Transactions on Quantum Computing, vol. 6, no. 3, Jul. 2025. [Online]. Available: https://doi.org/10.1145/3743149 [30] R. Rocco, S. Rizzo, M. Barbieri, G. Bettonte, E. Boella, F. Ganz, S. Iserte, A. J. Peña, P. Sandås, A. Scionti, O. Terzo, C. Vercellino, G. Vitali, P. Viviani, J. Frassineti, S. Marzella, D. Ottaviani, I. Colonnelli, and D. Gregori, “Dynamic solutions for hybrid Quantum-HPC resource allocation,” in 2025 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 02, Aug. 2025, pp. 34–40. [Online]. Available: https://doi.org/10.1109/QCE65121.2025.10289 [31] M. Cipollini, S. Rizzo, S. Iserte, P. Viviani, G. Vitali, M. Barbieri, G. Bettonte, E. Boella, F. Ganz, R. Rocco, O. Spina, A. J. Peña, P. Sandås, I. Colonnelli, A. Scionti, C. Vercellino, E. Dri, J. Frassineti, S. Marzella, A. Muratori, D. Ottaviani, O. Terzo, B. Montrucchio, and D. Gregori, “Three ways to share a QPU: Scheduling strategies for hybrid quantum-hpc applications,” 2026. [Online]. Available: https://arxiv.org/abs/2604.14955 [32] T. Shirakawa, J. Robledo-Moreno, T. Itoko, V. Tripathi, K. Ueda, Y. Kawashima, L. Broers, W. Kirby, H. Pathak, H. Paik, M. Tsuji, Y. Kodama, M. Sato, C. Evangelinos, S. Seelam, R. Walkup, S. Yunoki, M. Motta, P. Jurcevic, H. Horii, and A. Mezzacapo, “Closed-loop calculations of electronic structure on a quantum processor and a classical supercomputer at full scale,” 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2511.00224 [33] M. Tejedor, B. Casas, J. Conejero, A. Cervera-Lierta, and R. M. Badia, “Orchestrating quantum-hpc workflows with distributed quantum circuit cutting,” in Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2025, p. 1898–1906. [Online]. Available: https://doi.org/10.1145/3731599.3767547 [34] R. S. Garcı́a-Raigada, J. Jorba, and S. Iserte, “Wave-based dispatch for circuit cutting in hybrid hpc–quantum systems,” 2026. [Online]. Available: https://doi.org/10.48550/arXiv.2604.15279 [35] I. Martı́n-Álvarez, J. I. Aliaga, M. Castillo, S. Iserte, and R. Mayo, “Dynamic spawning of MPI processes applied to malleability,” The International Journal of High Performance Computing Applications, vol. 38, no. 2, pp. 69–93, 2024. [Online]. Available: https: //doi.org/10.1177/10943420231176527 [36] Íñigo Aréjula-Aı́sa, S. Iserte, P. Sandås, R. S. Raigada-Garcı́a, and A. J. Peña, “Communication-aware qubit placement and automatic node-count allocation for distributed state-vector simulation,” 2026. [Online]. Available: https://arxiv.org/abs/2610.09659 [37] M. Cerezo, A. Arrasmith, R. Babbush, S. C. Benjamin, S. Endo, K. Fujii, J. R. McClean, K. Mitarai, X. Yuan, L. Cincio, and P. J. Coles, “Variational quantum algorithms,” Nature Reviews Physics, vol. 3, pp. 625–644, 2021. [38] J. Vázquez-Pérez, D. Expósito-Patiño, M. Losada, Á. Carballido, A. Gómez, and T. F. Pena, “CUNQA: a distributed quantum computing emulator for HPC,” arXiv:2511.05209, 2025. [Online]. Available: https://arxiv.org/abs/2511.05209

Related documents

• Enabling Dynamic Resource Scaling in Quantum Circuit Simulations#1491219
• Tensor Network Simulation of Dynamic Circuits#1062406
• Branch-Aware Quantum Constant Propagation for Dynamic Quantum Circuits#1123108
• Scalable Benchmarking Framework for Dynamic Quantum Circuits#1123062
• QuWARP: A Workload-Aware Reuse Planner for simulating Quantum Circuits#1049401