Merge pull request #394 from unitaryfund/qrack_blog_correction

Refer to cuStateVec simulator as 'cusvaer'

src/content/blog/qrack_report.md

@@ -29,9 +29,9 @@ For "ideal" (vs. "approximate") simulation benchmarks, the report focuses on com
 
 ![](/images/qrack_qft_performance.png)
 
-It is worth remembering, as regards any trade-off for this very modest performance advantage of cuQuantum Qiskit Aer in a relatively specific case, that the PyQrack wheels for most operating systems transfer from PyPi in about 4 to 5 MB and have no dependencies at all (besides `packaging`, technically made part of Python language standard by PEP); cuQuantum-based Qiskit Aer is only available packaged with cuQuantum-based "qsimcirq" in an "appliance" Docker container with GBs of dependencies.
+It is worth remembering, as regards any trade-off for this very modest performance advantage of (cuStateVec-based) "cusvaer" in a relatively specific case, that the PyQrack wheels for most operating systems transfer from PyPi in about 4 to 5 MB and have no dependencies at all (besides `packaging`, technically made part of Python language standard by PEP); cusvaer is currently only available packaged in the cuQuantum Appliance (Docker container) with GBs of dependencies.
 
-We show that **Qrack can simulate a quantum circuit with 54 qubits on a single GPU** with fidelities close to the state-of-the-art of quantum supremacy experiments. As reported in the article, while an attainable average fidelity of about ~4% on 7 depth layers of a 54-qubit "nearest-neighbor" coupler circuit might be modest, this is with less than 80 GB of total memory footprint, on a single GPU. Employing a virtualization framework to connect nodes, it should already be possible to scale Qrack to an arbitrarily high number of GPUs, increasing this fidelity figure as a function of available (GPU) memory. We are eager to explore such true "HPC" regimes. It is worth noting how far the Qrack capabilities have gone, as the project started as an unfunded hobbyist project. We do not take for granted that any user has ready access and financial resources to run on 64 GPUs for over a dozen hours, for example, potentially costing tens or hundreds of thousands of US dollars, but this is exactly why the Qrack developers have focused their efforts for years on hardware available to virtually any "consumer," including first-class support for integrated graphics accelerators and CPU-only systems as low-cost alternatives to GPUs.
+We show that **Qrack can simulate a quantum circuit with 54 qubits on a single GPU** with fidelities close to the state-of-the-art of quantum supremacy experiments. As reported in the article, while an attainable average fidelity of about ~4% on 7 depth layers of a 54-qubit "nearest-neighbor" coupler circuit might be modest, this is with less than 80 GB of total memory footprint, on a single GPU. Employing a virtualization framework to connect nodes, it should already be possible to scale Qrack to an arbitrarily high number of GPUs, increasing this fidelity figure as a function of available (GPU) memory. We are eager to explore such true "HPC" regimes. It is worth noting how far the Qrack capabilities have come, as the project started as an unfunded hobbyist project. We do not take for granted that any user has ready access and financial resources to run on 64 GPUs for over a dozen hours, for example, potentially costing tens or hundreds of thousands of US dollars, but this is exactly why the Qrack developers have focused their efforts for years on hardware available to virtually any "consumer," including first-class support for integrated graphics accelerators and CPU-only systems as low-cost alternatives to GPUs.
 
 At a high level, Qrack can make many of the same kinds of general performance claims as conventional tensor network approaches: for special cases of low-entanglement or "near-Clifford" simulation, it can often support hundreds or thousands of qubits in a single quantum circuit. Since Qrack robustly supports interoperability with major conventional tensor network software, it's also incredibly easy to combine techniques in Qrack with use of those more popular back ends. However, we think many users would be surprised at how much equivalent functionality, compared to tensor networks, is already covered by Qrack, whether through relatively "novel" simulation techniques. You can learn more about Qrack's simulation methods in the [recent report](https://arxiv.org/abs/2304.14969), to appear in the Proceedings of IEEE QCE 2023.