![[1]](https://git
8. Y. Y. Boykov and M.-P. Jolly, “Interactive graph cuts for optimal boundary \& region segmentation of objects in N-D images,” in Proceedings Eighth IEEE International Conference on Computer Vision. ICCV 2001, Vancouver, BC, Canada: IEEE Comput. Soc, 2001, pp. 105–112. doi: 10.1109/ICCV.2001.937505. Available: [http://ieeexplore.ieee.org/document/937505](http://ieeexplore.ieee.org/document/937505). [Accessed: Aug. 14, 2024]
9. F. Barahona, M. Grötschel, M. Jünger, and G. Reinelt, “An Application of Combinatorial Optimization to Statistical Physics and Circuit Layout Design,” Operations Research, vol. 36, no. 3, pp. 493–513, Jun. 1988, doi: 10.1287/opre.36.3.493. Available: [https://pubsonline.informs.org/doi/10.1287/opre.36.3](https://pubsonline.informs.org/doi/10.1287/opre.36.3).493. [Accessed: Aug. 14, 2024]
-
-## Give feedback!
-
-Feedback is greatly appreciated! You can send feedback directly to [fiqci-feedback@postit.csc.fi](mailto:fiqci-feedback@postit.csc.fi).
diff --git a/content/_publications/2024-08-29-Topology.md b/content/_publications/2024-08-29-Topology.md
index c7e8c7a47ec0..c4828d7a1750 100644
--- a/content/_publications/2024-08-29-Topology.md
+++ b/content/_publications/2024-08-29-Topology.md
@@ -10,11 +10,10 @@ layout: post
tags:
- Helmi
- Quantum
-type: 'Blog'
filters:
Skill level: Beginner # Beginner, Advanced
Type: Blog # Blog, Instructions, News
- Theme: Technical # Technical, Algorithm, Programming, Hybrid QC+HPC computing
+ Theme: Technical # Technical, Algorithm, Programming, HPC+QC+AI
---
*As quantum computing continues to advance, the architecture of quantum processing units (QPUs) is becoming increasingly critical to the performance of quantum circuits, the backbone of all quantum algorithms. A key factor influencing the design of these circuits is qubit connectivity—how qubits are arranged and interact within a QPU. Different quantum platforms exhibit unique connectivity patterns that directly impact how quantum circuits are implemented and optimized.*
diff --git a/content/_publications/2025-03-04-Q50-Call-1_2025.md b/content/_publications/2025-03-04-Q50-Call-1_2025.md
new file mode 100644
index 000000000000..330980379bec
--- /dev/null
+++ b/content/_publications/2025-03-04-Q50-Call-1_2025.md
@@ -0,0 +1,109 @@
+---
+title: 'Open Call 1/2025 for Academic Projects for the VTT Q50 Quantum Computer'
+date: 2025-03-04
+collection: publications
+header:
+ teaser: /assets/images/about-icon.jpg
+published: true
+layout: post
+tags:
+ - Q50
+filters:
+ Skill level: Beginner # Beginner, Advanced
+ Type: News # Blog, Instructions, News
+ Theme: Technical # Technical, Algorithm, Programming, HPC+QC+AI
+---
+
+## Note: This Call is now closed (1 Apr 2025). A new Call will be announced in due time.
+
+*The first Call for access to the VTT Q50 quantum computer is now open for users from Finnish higher-education institutions and research institutes.
+This marks a significant boost for the Finnish Quantum-Computing Infrastructure FiQCI, maintained and developed by VTT, CSC, and Aalto University.
+VTT Q50, the Finnish quantum computer operated by VTT is accessible through the LUMI supercomputer environment, provided by CSC.*
+
+Through this Call, accepted projects will get access to a true hybrid high-performance computing / quantum computing (HPC+QC) environment,
+with a quantum computing resource that exceeds the capacity of full emulation on supercomputers.
+
+This opens exciting avenues in both software development and end-user applications.
+For a software development perspective, this setup enables the development of, for example, quantum-classical hybrid algorithms,
+error mitigation techniques, and quantum compilers that optimise circuit execution based on real hardware features.
+
+For end-users, applications such as quantum-enhanced optimisation, simulation of molecular systems and materials science,
+and machine learning acceleration through hybrid quantum-classical AI models becomes possible.
+
+The LUMI HPC backbone ensures that computationally demanding pre- and post-processing tasks can be seamlessly incorporated.
+Thus, quantum computing becomes a practical enhancement to supercomputing, and vice versa.
+The update to the FiQCI infrastructure creates a unique environment across classical, quantum, and hybrid HPC+QC software solutions.
+
+With the addition of the VTT Q50 quantum computer to FiQCI, also parallel quantum computing directly within a supercomputer
+environment can be explored.
+
+## Timeline of Call
+
+ - **4 Mar 2025** Call opens
+ - **1 Apr 2025** Call closes
+ - **15 Apr 2025** (tentative) Outcome communicated
+
+## How to apply
+
+Access to the VTT Q50 machine is organised through regular Calls, of which this is the first one. Calls will be announced four times per year.
+
+**The deadline for Call 1/2025 is 1 April 2025**. Proposals will be evaluated within FiQCI as soon as possible after the deadline.
+The results will be communicated to all applicants after decision. The expected duration of the projects is one year.
+
+Proposal will be evaluated based on scientific merit, feasibility, and computational resource justification.
+
+The application form is available here: [Application form for FiQCI / VTT Q50 Academic Project 1/2025](https://link.webropolsurveys.com/S/EC707D2388673638)
+
+**Please fill in all the applicable fields** in the application form, including abstract, key scientific/societal/technological contribution,
+justification for the importance, and references.
+
+### Requested computing time
+
+**Carefully estimate the total need of computational resources required for your project!**
+
+As a guideline, execution of a single circuit, using 10.000 shots consumes roughly 10 QPU-seconds.
+Initialisation time for each circuit, included in this estimate, is roughly 4 seconds.
+The execution time will naturally depend on the exact circuit being executed.
+
+We have set up a **resource estimator** to aid in estimating the QPU resources required:
+[FiQCI QPU resource estimator](https://fiqci.fi/resource-estimator/)
+
+The amount of resources applied for should be justified in the application.
+We acknowledge that this will be a rather approximate exercise, when practical experience on using the system is still scarce.
+Note that the total available QPU time available per Call is 20-60 QPU-hours, and we expect to grant resources to several projects.
+
+The following example resource application serves as a guideline;
+both smaller and larger resources can be granted based on the application.
+In addition to QPU resources, it is mandatory to apply also for classical resources in at least one category (CPU or GPU).
+Also storage resources are required. For example, 10.000 TiBh corresponds to storing on average roughly 1 Terabyte of data for a year.
+
+**Resource allocation example:**
+ - VTT Q50 QPU hours: 2
+ - LUMI CPU-core hours (in thousands of CPUh): 4
+ - LUMI GPU-core hours (in thousands of GPUh): 0
+ - LUMI Storage TiB hours (in thousands of TiBh): 10
+
+## Terms of Use
+
+Accepted Projects must accept the Terms of Use for both the LUMI supercomputing environment and the VTT Q50 system.
+Full Terms of Use will be communicated to the Principal Investigators before start of the projects.
+
+The main restrictions are:
+ - Only academic research purposes are eligible
+ - Use is restricted to users affiliated with a Finnish University, University of Applied Sciences, a state-owned research institute, or the National Archives of Finland
+ - No commercial purposes are allowed
+ - No sensitive or specific category data can be handled
+ - Access is allowed only from within Finland
+
+## Acknowledgement
+
+When publishing the results that utilise VTT Q50, users have to acknowledge the use of VTT Quantum and FiQCI, preferably in the format:
+ - ){kind=link}
+
+
+
+
+
+### Hardware Specifications for a single node
+
+This table shows the hardware resources available [3] on a single compute node in the LUMI *standard-g* partition.
+
+| # of Qubits | +Memory requirements | +
|---|---|
| 32 | 64 GB |
| 33 | 128 GB |
| 34 | 256 GB |
| 36 | 1024 GB |
| 38 | 4 TB |
| 40 | 16 TB |
| 42 | 64 TB |
| 44 | 256 TB |
+
+
+
+
+
+
+
+## Surpassing simulation limits of a single node
+
+To overcome the memory limitations imposed by large qubit counts requires utilizing the *distributed* memory spaces across many nodes by leveraging MPI (Message Passing Interface). MPI is a portable message-passing standard designed to function on parallel computing architectures, and allows for utilizing both the CPUs/GPUs and their distributed memory across many compute nodes.
+
+## Parallelizing a simulation across multiple nodes
+
+Using MPI we can aggregate the system memory of many nodes for our simulation. Below is a table that shows the memory requirements of storing the state-vector information of our quantum state as well as the amount of useable system memory distributed across the number of nodes that we use for simulation of *n* qubits.
+
+| LUMI single GPU accelerated node | +Specifications | +
|---|---|
| LUMI Partition | standard-g |
| Model of node | HPE Cray EX |
| CPU Model | AMD EPYC Trento |
| # of CPU sockets | 1 |
| # of CPU cores | 64 |
| GPU Model | AMD Instinct MI250X GPU |
| AMD Rocm version | 6.1.2 |
| # of GPUs (GCDs) | 8 |
| Amount of memory per GPU | 64 GB |
| Amount of Useable system memory | 480 GB |
| Network | +HPE Cray Slingshot-11 200 Gbps NIC using Dragonfly topology | +
+
+
+
+
+
+
+
+## Using GPUs to accelerate Quantum simulations
+
+Now that system memory requirements needed for simply storing the state-vector information of our qubits have been worked out, we can pivot to speeding up our simulation execution times using GPU acceleration and cache blocking techniques. Let's first shed some light on why GPU accelerated hardware speeds up the simulations.
+
+The type of calculations used in state-vector simulations of quantum circuits makes GPUs a natural choice for acceleration due to several key factors:
+
+1. **Linear Algebra Operations**
+ State-vector simulations rely heavily on linear algebra operations like matrix multiplications and vector additions. These operations are inherently parallel, meaning they can be divided into smaller tasks that can be executed simultaneously. GPUs are designed for this type of parallel processing, making them more efficient as an accelerator for these computations.
+
+2. **Massive Parallelism**
+ GPUs have a large number of cores (thousands of threads), which allows them to handle many operations at the same time. Since the workload of state-vector quantum circuit simulation is massively parallel, using GPUs is a good choice for accelerating such tasks.
+
+3. **High Memory Bandwidth**
+ Simulations of quantum states can involve large datasets, which can put a strain on memory access. GPUs typically have high-bandwidth memory (such as HBM2e), which allows for faster data retrieval and minimizes delays caused by memory bottlenecks, especially as the number of qubits increases.
+
+4. **Efficient Floating-Point Operations**
+ Quantum simulations often require high-precision floating-point calculations, such as those involving complex numbers. GPUs are capable of efficiently performing both single and double-precision floating-point operations, which are needed for the precision required in these simulations.
+
+5. **Support for Optimized Libraries**
+ GPUs are supported by libraries that are specifically optimized for accelerating tasks like matrix operations and Fourier transforms, which are common in quantum simulation domain. These libraries are tailored to GPU architecture, improving the performance of these operations.
+
+6. **Scalability Across HPC Nodes**
+ As quantum simulations grow in complexity with more qubits, they often need to be distributed across multiple computing nodes. GPUs are well-suited for this kind of parallel computation across many nodes, allowing simulations to scale to larger systems than what would be feasible with a single machine.
+
+7. **Energy Efficiency and Cost-Effectiveness**
+ Compared to CPU-based systems, GPUs are generally more energy-efficient for the kind of parallel processing needed in large-scale simulations. This can reduce the operational cost for running simulations of large quantum circuits.
+
+## Using Cache blocking with GPUs to accelerate Quantum Simulations
+To speed up simulations, we employed a technique called cache blocking, in which parts of quantum circuit (chunks) are simulated parallel in distributed memory spaces (caches). An important factor to condsider when using cache blocking is the data transfer between caches. When chunks that are far apart in memory need to interact, data has to be transferred over the network between those memory locations. This data transfer (or "data exchange") between compute nodes is relatively slow and becomes a bottleneck when utilizing large amount of resources.
+
+By strategically rerouting quantum operations using simulated noiseless SWAP gates, frequently interacting qubits are grouped together in memory on a single node; thereby reducing the need for slow data transfers between different distributed memory spaces spread out across the nodes of the supercomputer. This optimization technique draws inspiration from classical cache blocking methods and is implemented within Qiskit Aer to improve its performance, especially when dealing with large, complex quantum circuits. Also, by utilizing additional memory spaces for buffering, the data exchange between chunks can be decreased, making the simulation more efficient. [4] [5].
+
+## Example connectivity graphs showing network traffic between LUMI-G nodes
+In the LUMI-G partition, nodes are connected to each other by switches. Each node has 4 network connections, and single switch can have maximum of 16 nodes connected.
+In image below, the compute nodes are marked as purple dots and slingshot switches as orange dots.
+The gray lines show network connectivity (1 hop) between a compute node and a switch.
+The green lines show the network connectivity between switches (1 hop).
+The maximum hops that any network traffic can take between nodes on the LUMI-G slingshot network are 3.
+
+The example graphs below demonstrate the minimum possible data exchange paths for 2 different simulations that may take place between 16 nodes (38 qubits) and 32 nodes (39 qubits) over the Cray/HPE Slingshot network. This demonstrates the utility of trying to use the local memory space of a nodes before accessing distributed memory spaces.
+Localized computations take place within the nodes before having to transfer data across the network, a requirement for data exhange between caches. For example, when using 16 nodes connected by single switch, any data exhange between nodes goes through a maximum of 2 hops.
+
+| n # of Qubits | +Memory requirements | +Number of nodes | +Available system memory | +
|---|---|---|---|
| 34 | 256 GB | 1 | 480 GB |
| 35 | 512 GB | 2 | 960 GB |
| 36 | 2048 GB | 4 | 1920 GB |
| 38 | 4 TB | 16 | 7.5 TB |
| 40 | 16 TB | 64 | 30 TB |
| 42 | 64 TB | 256 | 120 TB |
| 44 | 256 TB | 1024 | 480 TB |
+
+
+## "Necessity is the mother of invention" - Building a container for scaling simulations
+
+When our users inquired about running multinode simulations with Qiskit, we took the task of building a Qiskit Aer singularity container with support for the AMD ROCm GPUs using Native HPE Cray MPI as suggested by the LUMI documentation.
+
+[Qiskit documentation on CSC](https://docs.csc.fi/apps/qiskit/)
+
+Multiple container build iterations took place before arriving at the latest version of qiskit/qiskit-aer. The biggest performance improvements in the qiskit-aer container comes from the usage of the same Native HPE Cray MPI software that is built on the node.
+
+
+ 
+
+
+ Figure 1. Network traffic - 16 nodes
+
+ 
+
+
+ Figure 2. Network traffic - 32 nodes
+
+ 
+
+
+
+## In order to build a performant container, some tradeoffs were made.
+
+### Pros:
+- The container exhibits a drastic performance gain.
+- New containers are easy to maintain as each container in the build process manages different aspects of the software stack.
+
+### Cons:
+- Lack of portability.
+- Built specifically for LUMI nodes that use HPE Cray MPI.
+- Increased complexity in curating container build scripts and definitions specific to LUMI.
+- A new container must be rebuilt after a major system update on LUMI.
+
+These drawbacks are easily outweighed by the substantial performance increase in the simulations -- a drastic (8x) speedup, as seen in the test outputs below.
+
+**Example Simulation using a container built using ABI Compliant MPICH**
+
+
+```
+Singularity Container : /
+ +
+
+ Figure 4: A layered Singularity container approach similar to nested dolls, where each container is built using the previous one as a bootstrap image. The base container serves as the foundation, with additional software installed at each stage, culminating in the final specialized qiskit-aer container.
+
+
+
+
+
+
+
+
+
+
+**GPU Statistics for a 32 Qubit Simulation on a single LUMI-G node**
+
+notice the GPU VRAM usage (38%), and not all GPUs are at a constant 100% utilization
+
+```sh
+> srun --interactive --pty --jobid=| Qubits | +Blocking Qubits | +Allocated Nodes | +Allocated GPUs | +Tasks Per Node | +Circuit Execution Time (Depth 10) - Seconds | +Circuit Execution Time (Depth 30) - Seconds | +
|---|---|---|---|---|---|---|
| 25 | 0 | 1 | 8 | 1 | 2.147 | 2.349 |
| 26 | 0 | 1 | 8 | 1 | 2.193 | 2.598 |
| 27 | 0 | 1 | 8 | 1 | 2.436 | 3.156 |
| 28 | 0 | 1 | 8 | 1 | 2.854 | 4.329 |
| 29 | 0 | 1 | 8 | 1 | 3.463 | 6.577 |
| 30 | 29 | 1 | 8 | 1 | 4.352 | 7.656 |
| 31 | 29 | 1 | 8 | 1 | 5.890 | 10.536 |
| 32 | 29 | 1 | 8 | 1 | 9.183 | 19.993 |
| 33 | 29 | 1 | 8 | 1 | 15.656 | 37.115 |
| 34 | 29 | 1 | 8 | 1 | 32.371 | 71.462 |
+ 
+
+
+
+---
+
+### **2. Strong Scaling Analysis**
+
+**Objective**:
+Evaluate how simulation time decreases as the number of compute nodes increases for a fixed number of qubits (34). The analysis explores six different node allocations (1, 2, 4, 8, 16, 32 nodes) across four circuit depths (10, 30, 100, 300), highlighting the impact of parallelization on execution time.
+
+---
+
+**Algorithm & Justification**:
+
+* **Methodology**:
+ The experiment was conducted with a fixed qubit count of 34, progressively increasing the allocated compute nodes from 1 to 32 while keeping 8 GPUs per node. Each node was assigned 8 tasks, leading to a total of 256 MPI ranks at the highest allocation level. Execution times were recorded for circuit depths 10, 30, 100, and 300 to assess scaling behavior across shallow and deep circuits.
+
+* **Justification**:
+ Quantum circuit simulations can be accelerated by increasing computational resources, enabling faster feedback for quantum algorithm designers. This study quantifies the efficiency of distributing workloads across more nodes, balancing speedup versus resource use. However, excessive resource allocation can lead to diminishing returns or even execution failures due to exceeding parallelization limits.
+
+---
+
+**Results & Discussion**:
+
+* **Performance Trends**:
+ Increasing the number of nodes reduces execution time, particularly for deeper circuits. For this specific example, the largest speedup is observed between 1 and 8 nodes. Although the simulation execution time does scales well up to 32 nodes, the performance improvements begin to diminish beyond 8 nodes.
+
+* **Efficiency Losses**:
+ While increasing resources enhances performance, efficiency losses emerge at higher allocations due to:
+
+ * **Communication Overhead**:
+ MPI-based communication increases as more nodes are used, contributing to diminishing returns at 16+ nodes.
+
+ * **Synchronization Delays**:
+ Larger task distributions require more frequent synchronization, particularly for deep circuits, impacting performance gains.
+
+ * **Load Balancing Challenges**:
+ At higher node counts, work imbalance can arise, as certain tasks may complete before others, leading to idle resources.
+
+ * **Parallelization Limits**:
+ The maximum effective MPI ranks that can be used for a given qubit count is constrained by the simulation’s computational structure. Over-allocation of nodes can result in execution failures, as seen when exceeding the optimal distribution.
+
+* **Scaling Efficiency**:
+ Strong scaling tests for quantum volume circuit with 34 qubits run very efficiently up to 16 nodes, with diminishing efficiency beyond 32 nodes. While increasing node allocations can accelerate simulations, optimal resource allocation depends on circuit depth and computational workload. Generally, doubling the number of nodes does not always halve the execution time.
+
+---
+
+**Calculating Max Nodes for our tests**
+
+Before running the tests, some awareness about the test parameteres that can and can not be used is needed, based on some initial assumptions and quick math. To obtain an estimate of the maximum number of nodes for error-free execution of a job, the formula below provides some guidance.
+
+$$
+\begin{aligned}
+\text{mem[statevec]} &\quad = \quad \text{precision} \times 2^n
+\\
+\text{mem[cache]} &\quad = \quad \text{precision} \times 2^{c}
+\\
+\end{aligned}
+$$
+
+, where n is number of qubits and c is the number of cache blocking qubits
+
+$$
+\begin{aligned}
+\text{Max MPI Ranks} &\quad = \quad \frac{\text{mem[statevec]}}{\text{mem[cache]}} \\
+
+ %&\quad = \quad \frac{\text{precision} \times 2^n}{\text{precision} \times 2^{c}} \\
+ &\quad = \quad 2^{n - c} \\
+\\
+\text{Max Nodes} &\quad = \quad \frac{\text{Max MPI Ranks}}{\text{Tasks Per Node}}
+\end{aligned}
+$$
+
+
+Using the above formulas to calculate *Max Nodes* with respect to our chosen value for *n* qubits and *c* cache-blocking qubits we can compare the results of the formula to the error message
+
+*Example Error*
+
+
+```
+mpi_test_34_qubits_29_blocking_8_GPU_8_task_8_node_depth_10.e9525960
+
+Simulation failed and returned the following error message:
+ERROR: [Experiment 0] cache blocking : blocking_qubits is too large to parallelize with 64 processes
+Simulation failed and returned the following error message:
+```
+
+*Using the Following allocation resources*
+
+```
+mpi_test_34_qubits_29_blocking_8_GPU_8_task_8_node_depth_10.o9525960
+
+Singularity Container : /appl/local/quantum/qiskit/qiskit_1.3.2_csc.sif
+Simulation Method : statevector
+# of Qubits : 34
+# of Blocking Qubits : 29
+Circuit Depth : 10
+SLURM JOB NAME : mpi_test_34_qubits_29_blocking_8_GPU_8_task_8_nodes_depth_10
+SLURM JOB ID : 9525960
+NODES : 8
+NODE LIST : nid[005322-005323,005356-005357,005423,007447-007449]
+Tasks Per Node : 8
+CPUS PER TASK : 7
+GPUS PER NODE : 8
+GPU LIST : 0,1,2,3,4,5,6,7
+```
+
+**Step 1: Express Max MPI Ranks in terms of Max Nodes:**
+*Calculation of Max Nodes for given number of total qubits and cache-blocking qubits. We use parameters from the above error message*
+
+$$
+\begin{aligned}
+n &\quad = \quad \text{34} \\
+c &\quad = \quad \text{29} \\
+\\
+\text{Max MPI ranks} &\quad = \quad 2^{n - c} \\
+%\\
+%\text{Max MPI Ranks} &\quad = \quad 2^{5} \\
+&\quad = \quad 32 \\
+\\
+\text{Max Nodes} &\quad = \quad \frac{\text{Max MPI Ranks}}{\text{Tasks Per Node}} \\
+ %&\quad = \quad \frac{\text{32}}{\text{8}} \\
+ &\quad = \quad \text{4} \\ \\
+\end{aligned}
+$$
+
+The above experiment failed due to the amount of allocated nodes (*Max Nodes*) being 8 (64 parallel processes) rather than 4 (32 parallel processes). There were not enough MPI ranks (distributed processess) to spread out across the amount of nodes that were requested in the resource allocation. The 64 processes are double the amount of *Max MPI Ranks* (32) that would be spawned based on the size of the cache-blocking qubits used for a simulation of *n* qubits. Now if we work backwards knowing that we want to run an experiment on 8 nodes, we can calculate the size of *c* cache-blocking qubits in with respect to the number of *n* qubits and Tasks Per Node as can be observed in the example below. Notice that if we decrease the cache-blocking qubits from 29 to 28 we are able to generate enough parallel processes (64) to be distributed across 8 nodes:
+
+**Step 2: Solve for cache-blocking qubits:**
+*Calculation for suitable number of cache-blocking qubits for given number of nodes and qubits*
+
+$$
+\begin{aligned}
+\\
+n &\quad = \quad \text{34} \\
+\text{Max Nodes} &\quad = \quad \text{8} \\
+\text{Tasks per Node} &\quad = \quad \text{8} \\
+\\
+\text{Max MPI Ranks} &\quad = \quad (\text{Max Nodes} \times \\
+ &\quad\quad\quad\text{Tasks Per Node}) \\
+ &\quad = \quad \text{64} \\
+\\ \\
+\text{Max MPI Ranks} &\quad = \quad 2^{n-c} \\ \\
+\Rightarrow c &\quad = \quad n - \log_2(\text{Max MPI} \\
+ &\quad\quad\quad\quad\quad\quad\quad \text{Ranks}) \\
+&\quad = \quad 34 - \log_2 (\text{64}) \\
+&\quad = \quad 28
+\end{aligned}
+$$
+
+Equipped with the tools needed to estimate the resource needs before submitting jobs, we proceed with the Strong Scaling tests.
+
+**Quantum Volume - Strong Scaling execution time results table**
+
+
+ +
+
+ Figure 3: Chart displaying the execution time of a range of qubits for Quantum Volume depth 10 and depth 30 that were run on a single LUMI standard-g node.
+
+
+
+
+
+
+
+
+
+
+**Quantum Volume - Strong Scaling execution time results - chart**
+
+| # of Qubits | +Blocking Qubits | +Allocated Nodes | +Allocated GPUs | +Tasks Per Node | +Total Tasks (MPI Ranks) | +Circuit Execution Time (Depth 10) - seconds | +Circuit Execution Time (Depth 30) - seconds | +Circuit Execution Time (Depth 100) - seconds | +Circuit Execution Time (Depth 300) - seconds | +
|---|---|---|---|---|---|---|---|---|---|
| 34 | 26 | 1 | 8 | 8 | 8 | 17.704 | 53.813 | 157.277 | 451.620 |
| 34 | 26 | 2 | 8 | 8 | 16 | 14.196 | 40.388 | 118.691 | 338.842 |
| 34 | 26 | 4 | 8 | 8 | 32 | 9.117 | 23.768 | 73.050 | 200.675 |
| 34 | 26 | 8 | 8 | 8 | 64 | 5.721 | 13.236 | 41.134 | 113.088 |
| 34 | 26 | 16 | 8 | 8 | 128 | 3.536 | 7.980 | 22.074 | 59.613 |
| 34 | 26 | 32 | 8 | 8 | 256 | 2.645 | 5.232 | 13.063 | 35.655 |
+ 
+
+
+ Figure 4: Chart displaying the execution time of Quantum Volume depth 10, 30, 100, and 300 on a range of nodes.
+
+
+
+
+**Quantum Volume - Weak Scaling execution time result tables**
+
+
+ 
+
+
+ Figure 6. Network traffic - 32 nodes
+
+ 
+
+
+ Figure 7. Network traffic - 64 nodes
+
+ 
+
+
+ Figure 8. Network traffic - 128 nodes
+ | Qubits | +Blocking Qubits | +Number of Nodes | +Tasks Per Node | +Total Tasks (MPI Ranks) | +Minimum Memory Requirements (GB) | +Total Usable Memory Across Nodes (GB) | +Circuit Execution Time (Depth 10) - seconds | +Circuit Execution Time (Depth 30) - seconds | +
|---|---|---|---|---|---|---|---|---|
| 34 | 29 | 1 | 8 | 8 | 256 GB | 480 GB | 17.723 | 47.683 |
| 35 | 29 | 2 | 8 | 16 | 512 GB | 960 GB | 28.355 | 63.231 |
| 36 | 29 | 4 | 8 | 32 | 1024 GB | 1920 GB | 31.728 | 88.154 |
| 37 | 29 | 8 | 8 | 64 | 2 TB | 4 TB | 32.785 | 94.958 |
| 38 | 29 | 16 | 8 | 128 | 4 TB | 8 TB | 39.217 | 106.818 |
| 39 | 29 | 32 | 8 | 256 | 8 TB | 15 TB | 46.092 | 120.872 |
| 40 | 29 | 64 | 8 | 512 | 16 TB | 31 TB | 48.920 | 170.657 |
| 41 | 29 | 128 | 8 | 1024 | 32 TB | 61 TB | 63.667 | 185.674 |
| 42 | 29 | 256 | 8 | 2048 | 64 TB | 123 TB | 97.119 | 259.823 |
| 43 | 29 | 512 | 8 | 4096 | 128 TB | 246 TB | 135.397 | 420.243 |
| 44 | 29 | 1024 | 8 | 8192 | 256 TB | 492 TB | 286.414 | 649.876 |
+ 
+
+
+ Figure 9: Chart displaying the execution time of Quantum Volume simulations using recommended node allocations for qubit ranges of 34-44.
+
+
-
+
-
+
Qiskit Aer Statevector Simulator: Backend Options - precision https://qiskit.github.io/qiskit-aer/
+
+ -
+
Qiskit Aer Statevector Simulator: Backend Options https://qiskit.github.io/qiskit-aer/stubs/qiskit_aer.StatevectorSimulator.html#qiskit_aer.StatevectorSimulator
+
+ -
+
LUMI’s full system architecture revealed https://lumi-supercomputer.eu/lumis-full-system-architecture-revealed/
+
+ -
+
Running with multiple-GPUs and/or multiple nodes https://qiskit.github.io/qiskit-aer/howtos/running_gpu.html
+
+ -
+
Cache Blocking Technique to Large Scale Quantum Computing Simulation on Supercomputers https://arxiv.org/pdf/2102.02957
+
+ -
+
Quantum Computer Simulations at Warp Speed: Assessing the Impact of GPU Acceleration https://arxiv.org/abs/2307.14860
+
+ -
+
mpiQulacs: A Distributed Quantum Computer Simulator for A64FX-based Cluster Systems https://arxiv.org/pdf/2203.16044
+
+
-
- {props.title.length >= 89 ? props.title.slice(0, 90) + "..." : props.title}
+
+
+ {props.title.length >= 89 ? props.title.slice(0, 90) + "..." : props.title}
+
- { type } | {props.date} + {type} | {props.date}
-
+
- { SITE.publications.slice(-5).reverse().map(blog =>