We are delighted to present a new experience for exploring space-time tradeoffs recently added to the Azure Quantum Resource Estimator. Available both as Azure Quantum Development Kit (VS Code extension) and a Python package, it adds a new dimension to estimates.

The post Exploring space-time tradeoffs with Azure Quantum Resource Estimator appeared first on Q# Blog.

]]>We are delighted to present a new experience for exploring space-time tradeoffs recently added to the Azure Quantum Resource Estimator. Available both as Azure Quantum Development Kit (VS Code extension) and a Python package, it adds a new dimension to estimates.

Resource estimation doesn’t just yield a single group of numbers (one per objective), but rather multiple points representing tradeoffs between objectives, such as qubit number and runtime. Our recent update of the Azure Quantum Resource Estimator adds methods for finding such tradeoffs for a given quantum algorithm and a given quantum computing stack. We also provide a visual experience to navigate alternatives with an interactive chart and supplementary reports and diagrams:

This chart illustrates tradeoffs between qubit numbers and runtimes required for running the same algorithm across multiple projected quantum computers. See estimation-frontier-widgets.ipynb for steps to learn how to generate this diagram.

More specifically, we have considered the simulation of the dynamics of a quantum magnet, the so-called Ising model on a square 10×10 lattice. This is the simplest model for ferromagnetism in a quantum system, and the algorithm simulates its evolution over time. At this system size the problem cannot be simulated on classic computers in reasonable time and solutions with computers would be highly desired.

The diagram above and the table

show that this algorithm requires 230 logical qubits with low error rates. Such logical qubits don’t exist yet, and it will require hundreds of noisy physical qubits per each logical. So, the total number of high error rate physical qubits requiring for the simulation ranges from 33,000 to 261,340.

You also can notice on the chart that increasing the number of utilized physical qubits by 10-35 times reduces the runtime 120-250 times. A thoughtful analysis of tradeoffs for entire algorithms and for subroutines can save a lot of runtime if extra qubit resources are available.

Compromises between the number of physical qubits and the runtime in quantum computations are like ones between space and time utilization in classic computing. As we have done above, for a given algorithm, one can start estimates by computing the minimal number of physical qubits required for its execution on a given quantum stack, and then deduce the corresponding runtime. If more physical qubits are available, one can accelerate the runtime by parallelizing execution of the algorithm or its subroutines.

One can build multiple estimates by allowing more and more physical qubits and improving the runtime. We can consider efficient estimates, such that in each pair of estimates, one would be better than the other with respect to runtime, and the other would be better with respect to the number of physical qubits. The set of such estimates forms the so-called Pareto frontier which is represented by monotonous decreasing plots on the space-time diagram.

Just as in classical programs, there are many opportunities for space-time tradeoffs in the choice of quantum algorithms and their implementation. Here we want to discuss another, quantum-specific opportunity. Rotation gates that rotate logical qubits by arbitrary angles require so-called magic states which are generated in a process known as Magic State Distillation happening in a set of qubits called the “magic state factories”. Many quantum stacks use the T gate as the only magic gate, and corresponding states and factories become T-states and T-factories, and we use those names in the Resource Estimator.

T-state generation subroutines are executed in parallel with the main algorithm. Let us start with a single T-factory. For some algorithms, it could produce enough T-states corresponding for the algorithm consumption. For other algorithms requiring more T-states, the algorithm execution will be slowed down, waiting for the next T-state to be produced. Note that idling of an algorithm is not free in the quantum world because errors in quantum states will occur while waiting. Longer runtimes might thus require a higher error correction code distance and with it more physical qubits and longer runtimes than might naively be estimated.

If an algorithm waits for new T-states and there are more qubits available, we can add additional T-factories to produce more T-states. This saves runtime at the cost of more physical qubits. Having enough physical qubits available, we can increase the number of T-factories until they produce enough T-states for algorithm consumption without idling. This will give the shortest runtime of the algorithm. For example, the algorithm considered above could efficiently use up to 172-251 T-factories depending on the computing stack. This involves spending from 92.29% to 98.40% of its resources for T-states distillation.

As shown in estimation-frontier-widgets.ipynb, to estimate resources required to run a Q# program, one has to run

result=qsharp.estimate(entry_expression, params)

where the “entry_expression” refers to the entry point of the program and params could cover multiple quantum stack configurations and estimation parameters as well.

When “estimateType”: “frontier” is set, the estimator searches for the whole frontier of estimates, otherwise, it looks for the shortest runtime solution only.

Executing the

EstimatesOverview(result)

command visualizes all the estimates found in result (frontier and individual as well) with the space-time diagram and the summary table.

Selecting rows on the summary table or point on the space-time diagram generates the space diagram and the detailed report:

“EstimatesOverview” supports optional parameters for custom color schemes on the space-time diagram and custom series name for the summary table.

More tips and tricks for the “EstimatesOverview” and for supplementary visualization elements are available at estimation-frontier-widgets.ipynb.

Estimating resources for quantum algorithm executions goes beyond providing a single pair of numbers — the runtime and the number of physical qubits. It requires constructing and analyzing the entire frontier of tradeoffs between those objectives. The Azure Quantum Resource Estimator allows you to build and explore those tradeoff frontiers and more accurately evaluate your requirements. With this new data, you can determine if you need to improve your algorithm, develop new error correction codes, or explore alternate qubit technologies.

The Azure Quantum team is committed to continuous improvements in the Resource Estimator. This tool supports both our internal teams and external researchers in the pursuit of designing quantum computers.

Our primary focus is on enhancing the precision of estimates and offering expanded estimation capabilities.

We eagerly welcome your feedback on the specific custom options you require for estimating your quantum computer resources. Your insights will play a vital role in refining our tool, making it even more effective for the entire quantum community.

- Visit our technical documentation for more information on Resource Estimation, including detailed steps to get you started.
- Try the sample used for writing the blog post.
- Run the Resource Estimator at Azure Quantum Development Kit (VS Code extension). You can try an online version https://aka.ms/qre-demo as well. To estimate a Q# program press CTRL+SHIFT+P and look for “Q# Calculate Resource Estimates” in the drop down menu.

- Dive deeper into our research on Resource Estimation at arXiv.org.

The post Exploring space-time tradeoffs with Azure Quantum Resource Estimator appeared first on Q# Blog.

]]>Introduction

There are numerous architectural decisions to consider when building quantum computers, which have the potential to address real-world computational challenges like quantum chemistry and quantum cryptography. Researchers worldwide are engaged in developing various aspects of quantum computer architecture. Microsoft Azure Quantum Resource Estimator plays a pivotal role in assessing how different combinations of design choices might impact the performance of upcoming quantum computers.

The post Modeling quantum architecture with Azure Quantum Resource Estimator appeared first on Q# Blog.

]]>There are numerous architectural decisions to consider when building quantum computers, which have the potential to address real-world computational challenges like quantum chemistry and quantum cryptography. Researchers worldwide are engaged in developing various aspects of quantum computer architecture. Microsoft Azure Quantum Resource Estimator plays a pivotal role in assessing how different combinations of design choices might impact the performance of upcoming quantum computers.

Azure Quantum Resource Estimator was designed to assist researchers in estimating computational time and the requisite number of qubits based on diverse assumptions regarding hardware quality and error correction strategies. We have used a more powerful version of the Resource Estimator for many years as an internal tool for analyzing architectural decisions in our own quantum program. We have incorporated new options to offer similar capabilities to the Azure Quantum users.

Continuing our commitment to enhancing the tool’s capabilities, we have recently introduced several new features. These updates include the ability to customize error budget distributions and implement custom distillation units.

In this article, we provide an overview of fundamental concepts related to the architecture of quantum computers, exploring their influence on the necessary resources and the capabilities offered by Microsoft Azure Quantum Resource Estimator to model these intricate structures.

One can represent quantum computing stack as follows:

Scientists all around the world are collaborating on refining individual stack components and integrating them cohesively. The multitude of decisions made at each stack layer, coupled with diverse quantum algorithms, results in a vast array of possible combinations that warrant evaluation and comparison. Microsoft Azure Quantum Resource Estimator helps to assess and compare those combinations efficiently. You can submit your quantum program (such as in Q# or Qiskit) or Quantum Intermediate Representation (QIR) while specifying particular characteristics of a proposed quantum computing stack:

- Microarchitecture of magic state distillation and physical qubit parameters
- Quantum error correction
- Error budget allowed for the program

And the Resource Estimator will calculate rQOPS of the architecture and, qubits and time required for the application given this combination.

In the current landscape of 2023, a significant challenge lies in the pursuit of rapidly responsive, stable, and scalable physical qubits to enable impactful applications in chemistry and materials science (read more at Communications of the ACM, 2023). Researchers are exploring a range of design possibilities, including instruction sets as well as diverse anticipated levels of speed and fidelity for these qubits.

In the process of resource estimation, a higher degree of specificity becomes necessary, encompassing various times for distinct actions involving qubits. Our recent updates here involve:

- Providing separate `process` and `readout` error rates for qubit measurements;
- Adding an idling error rate to the model;
- Separating `Clifford` and `readout` error rates in magic state distillation formulas.

Azure Quantum Resource Estimator supports:

- predefined qubit types with characteristics expected or targeted,
- and custom qubit types where users could provide specific times and error rates.

Here is an example of specifying a custom qubit type:

`from azure.quantum import Workspace from azure.quantum.target.microsoft import MicrosoftEstimator from azure.quantum.target.microsoft.target import MeasurementErrorRate #Enter your Azure Quantum workspace details here workspace = Workspace( resource_id="", location="" ) estimator = MicrosoftEstimator(workspace) params = estimator.make_params() params.qubit_params.name = "qubit_maj_ns_e6" params.qubit_params.instruction_set = "Majorana" params.qubit_params.one_qubit_measurement_time ="150 ns" params.qubit_params.two_qubit_joint_measurement_time = "200 ns" params.qubit_params.t_gate_time = "100 ns" params.qubit_params.one_qubit_measurement_error_rate = MeasurementErrorRate(process=1e-6, readout=2e-6) params.qubit_params.two_qubit_joint_measurement_error_rate = 1e-6`

# test quantum program from qiskit import QuantumCircuit circ = QuantumCircuit(3) circ.crx(0.2, 0, 1) circ.ccx(0, 1, 2) job = estimator.submit(circ) job.wait_until_completed() result = job.get_results() print(result)

We use a simple Qiskit circuit for this blog post for short. To learn how to run resource estimator for Q# algorithms, go to the Create the quantum algorithm section at the resource estimator documentation.

You can learn more about this at the Physical qubit parameters section of documentation.

Error correction in classical computing involves creating duplicates or checksums of data and periodically verifying these duplicates. In quantum computing, error correction is more complex due to the impossibility of copying information (see No-cloning theorem).

However, the basic principles are similar to classical error correction: achieving greater accuracy in computations requires extra resources (additional qubits and time). Analogous to classical computing, the extent of extra information can be quantified using a code distance (see Hamming distance). Opting for a higher code distance necessitates more resources but leads to enhanced computation fidelity.

We use the following exponential model for error rate suppression:

Here, *p* – is the physical qubit error rate (computed from various physical error rates above), *P* – is the (output) logical error rate provided by an error correction scheme, *d* – is the code distance, and *a* and *p* – are coefficients specific for the scheme, called crossing prefactor and error correction threshold correspondingly. As you can see, if *p < p**, then *P* increases when *d* increases.

As mentioned above, resources involved would also grow with increasing of *d*. Here are examples for the Floquet scheme (arxiv.org:2202.11829):

```
logicalCycleTime=3 * oneQubitMeasurementTime * d,
physcialQubitsPerLogicalQubit=4 * d^2 + 8 * (d -1).
```

Microsoft Azure Quantum Resource Estimator supports two predefined schemes of error correction: surface and Floquet, as well as custom error correction schemes.

The surface scheme is based on the premise that physical qubits form a lattice on a surface. In this arrangement, we have two types of qubits: data qubits, which play a role in primary algorithm computations, and measurement qubits, which serve as supplementary components. These qubits are organized in a checkerboard pattern, where each data qubit is surrounded by four measurement qubits, and vice versa. Boundary qubits are conceptually linked to qubits on the opposite side, creating a toroidal structure. Stabilization measurements are performed on corresponding qubits along different axes with a specific geometric pattern. This scheme exhibits versatility, as it can be applied to both gate-based qubits and Majorana qubits.

Conversely, the Floquet scheme places more stringent demands on the geometric arrangement of qubits but offers significant advantages in terms of time and space efficiency (as detailed in arxiv.org: 2202.11829). Qubits must be arranged in a grid with three neighbors each, and it should be possible to color the plaquettes with just three colors. Honeycomb is an example of such structure. Subsequently, stabilization measurements are executed periodically with a period of three, involving joint measurements between one qubit and one of its three neighbors at a time. This geometric structure aligns well with Majorana qubits and can bring substantial benefits when applied to them.

If using Microsoft Quantum Development Kit, one can submit the following job with different error correction schemes:

`from azure.quantum import Workspace from azure.quantum.target.microsoft import MicrosoftEstimator, ErrorBudgetPartition # Enter your Azure Quantum workspace details here workspace = Workspace( resource_id="", location="" ) estimator = MicrosoftEstimator(workspace) params = estimator.make_params() params.qec_scheme.error_correction_threshold = 0.01 params.qec_scheme.crossing_prefactor = 0.07 params.qec_scheme.logical_cycle_time = "3 * oneQubitMeasurementTime * codeDistance" params.qec_scheme.physical_qubits_per_logical_qubit = "4 * codeDistance * codeDistance + 8 * (codeDistance - 1)"`

# there are two predefined schemes: floquet_code and surface_code # the floquet_code can be applied for models with Majorana instruction set # the surface code can be applied to both: Majorana and gate-based instruction sets. # you can just specify the name of a predefined scheme #params.name = "surface_code" # test quantum program from qiskit import QuantumCircuit circ = QuantumCircuit(3) circ.crx(0.2, 0, 1) circ.ccx(0, 1, 2) job = estimator.submit(circ) job.wait_until_completed() result = job.get_results() print(result)

See more at the Quantum error correction schemes section of the Resource Estimator documentation.

To harness the benefits of quantum computing over classical counterparts, it is essential to devise quantum gates that cannot be effectively simulated on traditional non-quantum hardware. These operations can be envisioned as rotations of the Bloch sphere, executed at arbitrary angles. In this context, classical non-quantum hardware is proficient at executing rotations limited to angles of 90 degrees. This particular set of operations can be encapsulated by the concept of Clifford gates.

By combining a set of Clifford gates with additional non-Clifford gates, it is possible to create a universal set of quantum gates. This means that any quantum gate can be efficiently approximated to the desired precision using a predefined sequence of operations from this set. This approximation process is commonly referred to as rotation synthesis.

Various quantum computer architectures might incorporate distinct non-Clifford gates within the rotation synthesis. These particular gates are often termed “magic gates,” and their associated states are labeled as “magic states.” A notable challenge in quantum computing stems from its inherent inability to duplicate data. Consequently, generating these magic states once and employing them indefinitely is unfeasible. Instead, each usage demands the creation of fresh instances of these magic states. This intricate procedure of generating magic states with a specified level of precision is known as magic state distillation.

One of popular choices for the magic state is the T-gate defined as follows:

In Azure Quantum Resource Estimator, we assume that the T-state is used as the magic state.

Algorithms designed for T-state distillation play a crucial role in enhancing qubit accuracy. These algorithms utilize multiple input qubits with low accuracy to generate an output qubit with higher accuracy. This process can encompass multiple rounds of distillation, progressively refining qubit quality until the desired standard is attained. Each round employs a specific algorithm known as a distillation unit.

For each distillation unit, one should specify how it improves the qubit quality and what resources it will consume for the runtime: qubits involved, and time spent. Those characteristics depend on the code distance used for the distillation, physical quality of qubits and accuracy provided originally or by the previous round of distillation.

It’s important to note that distinct sequences of distillations can yield greater efficiency for different qubit qualities (output error rates). In other words, depending on the initial error rate of an input qubit, specific sequences of distillation may be more adept at achieving the required error rate while utilizing fewer resources.

Here are examples of distillation units described in Assessing requirements to scale to practical quantum advantage:

Distillation unit |
# input Ts |
# output Ts |
acceptance probability |
# qubits |
time |
output error rate |

15-to-1 space-eff. physical |
15 |
1 |
1−15p |
12 |
46t |
35p |

15-to-1 space-eff. logical |
15 |
1 |
1−15P |
20n(d) |
13τ(d) |
35P |

15-to-1 RM prep. physical |
15 |
1 |
1−15p |
31 |
23t |
35p |

15-to-1 RM prep. logical |
15 |
1 |
1−15P |
31n(d) |
13τ(d) |
35P |

When we are estimating the performance of a particular quantum algorithm on a specific quantum computer (which has a certain qubit quality and operation speed), we might need different target output error rates. Considering two distillation units (15-to-1 space-efficiency and 15-to-1 RM preparation) and various code distances for each round, there could potentially be thousands of combinations to evaluate.

Various research groups are actively working on developing distillation algorithms, and their approaches might differ from the ones described earlier. For instance, some algorithms could generate multiple output T-states, potentially reducing costs by sharing resources or enabling parallelization. With dozens of distillation algorithms in consideration, an intriguing opportunity arises to compare them against each other, encompassing diverse physical qubit attributes and algorithm variations. This comparative analysis could provide valuable insights into their relative effectiveness.

Microsoft Quantum invites researchers to assess the resources needed for their unique distillation approaches. Presently, we offer support for two established distillation units named `15-1 RM` and `15-1 space-efficient`, in addition to the flexibility to define custom distillation unit specifications.

Here is an example of calling the Resource Estimator with custom distillation unit specifications:

```
from azure.quantum import Workspace
from azure.quantum.target.microsoft import MicrosoftEstimator
from azure.quantum.target.microsoft.target import DistillationUnitSpecification, ProtocolSpecificDistillationUnitSpecification
# Enter your Azure Quantum workspace details here
workspace = Workspace(
resource_id="",
location=""
)
estimator = MicrosoftEstimator(workspace)
params = estimator.make_params()
specification1 = DistillationUnitSpecification()
specification1.display_name = "28-2"
specification1.num_input_ts = 2
specification1.num_output_ts = 28
specification1.output_error_rate_formula = "35.0 * inputErrorRate ^ 3 + 7.1 * cliffordErrorRate"
specification1.failure_probability_formula = "15.0 * inputErrorRate + 356.0 * cliffordErrorRate"
physical_qubit_specification = ProtocolSpecificDistillationUnitSpecification()
physical_qubit_specification.num_unit_qubits = 12
physical_qubit_specification.duration_in_qubit_cycle_time = 65
specification1.physical_qubit_specification = physical_qubit_specification
logical_qubit_specification = ProtocolSpecificDistillationUnitSpecification()
logical_qubit_specification.num_unit_qubits = 20
logical_qubit_specification.duration_in_qubit_cycle_time = 37
specification1.logical_qubit_specification = physical_qubit_specification
specification2 = DistillationUnitSpecification()
specification2.name = "15-1 RM"
specification3 = DistillationUnitSpecification()
specification3.name = "15-1 space-efficient"
params.distillation_unit_specifications =[specification1, specification2, specification3]
# test quantum program
from qiskit import QuantumCircuit
circ = QuantumCircuit(3)
circ.crx(0.2, 0, 1)
circ.ccx(0, 1, 2)
job = estimator.submit(circ)
job.wait_until_completed()
result = job.get_results()
print(result)
```

For further information, please refer to the Distillation Units section in the Resource Estimator documentation.

Quantum algorithms inherently embrace a probabilistic aspect, and the execution process is susceptible to errors. Typically, an algorithm can be run multiple times to reveal its probabilistic behavior and mitigate errors. When sending an algorithm for quantum computer execution, it’s crucial to determine how many runs are required to achieve a desired confidence level. Consequently, a probability of error in the final computations is defined, termed the error budget. Seeking a higher probability of success can involve employing the error correction methods elucidated earlier. However, it is important to note that this pursuit of higher success probability comes at an elevated cost, involving more qubits and a longer runtime.

We could categorize errors into three categories by occurrence:

- During distilling magic states
- During performing rotations
- While executing the algorithm

As an initial approximation, we might distribute the error budget evenly among these three sources. Yet, certain algorithms could demand varying amounts of rotations or magic states. Hence, there could be a preference to readjust the error budget to align with the intricacies of the algorithm in question.

If using Microsoft Quantum Development Kit, one can submit the following job with different error budget options:

```
from azure.quantum import Workspace
from azure.quantum.target.microsoft import MicrosoftEstimator, ErrorBudgetPartition
# Enter your Azure Quantum workspace details here
workspace = Workspace(
resource_id="",
location=""
)
estimator = MicrosoftEstimator(workspace)
params = estimator.make_params()
```

# make an estimate with specific error budget
# for each of the three error sources:
params.error_budget = ErrorBudgetPartition(logical=0.001, t_states=0.002, rotations=0.003)

# for uniformly distributed error budgets,
# # you can specify just the total as single number:
# params.error_budget = 0.001
# test quantum program
from qiskit import QuantumCircuit
circ = QuantumCircuit(3)
circ.crx(0.2, 0, 1)
circ.ccx(0, 1, 2)
job = estimator.submit(circ)
job.wait_until_comps()
print(result)leted()
result = job.get_result

Read more about error budgets in the documentation.

The Azure Quantum team is dedicated to ongoing enhancements of the Resource Estimator. This valuable tool serves both our internal teams and external researchers in the endeavor to design quantum computers. Expanding the scope of modeling capabilities remains a key priority for us. We eagerly welcome your feedback on the specific custom options you require for estimating your quantum computer resources. Your insights will greatly contribute to refining our tool and making it even more effective for the quantum community.

There are many ways to learn more:

- Visit our technical documentation for more information on Resource Estimation, including detailed steps to get you started.
- Login to the Azure Portal, visit your Azure Quantum workspace, and try an advanced sample on topics such as factoring and quantum chemistry.
- Dive deeper into our research on Resource Estimation at arXiv.org.

The post Modeling quantum architecture with Azure Quantum Resource Estimator appeared first on Q# Blog.

]]>