The post Festivus: Azure Quantum Feats of Strength appeared first on Q# Blog.
]]>How about you – what is your favorite thing about Azure Quantum?
Wim van Dam
The post Festivus: Azure Quantum Feats of Strength appeared first on Q# Blog.
]]>The post Developing and using Azure Quantum assignments for quantum computing courses appeared first on Q# Blog.
]]>This course was definitely my favorite of the two courses I designed material for. Introduction to Quantum Science and Technology covers quantum physics in relation to quantum computing and communication protocols. Interestingly, it does not cover quantum algorithms or quantum programming! Considering that our end goal was to create Azure Quantum-based assignments, this posed a unique set of design constraints. Namely, we needed to leverage Q# and the Microsoft Azure platform WITHOUT requiring students to write a single line of code.
The solution we came up with was to create Q# interactive workbooks. The basic structure of these workbooks was as follows. Students would typically start by reading a write-up that provided context and related back to the material they were learning in class. Next, they would be presented with Q# code implementing an example or protocol. Then they would submit this code to Azure Quantum simulators or hardware and view visualizations of the program output. The last step for the student was to answer questions tying the code they are running to concepts in the course. This structure ended up working out very well. I think an example will do a great job illustrating our design philosophy.
In class, students learn about the physical realization of quantum gates on different architectures. For assignment 1 we wanted to relate this to the way we reason about these gates in an abstract manner.
Next, we dive into an application of these ideas with an example Q# program which demonstrates how this abstract model allows us to reason about quantum computation.
Lastly, the students have to answer some questions which tie things together.
It is really exciting to know that these materials have already been used at Purdue. The first session of this course using these materials is wrapping up right now. Fortunately, this has also allowed me to gather some data on student reception of the materials. So I’ll let the students speak as to whether we did a good job.
And my favorite response
I really enjoyed the assignments. Thinking about noise in quantum systems in such a straightforward way was great. I also like to relate the technology hardware to the algorithm itself, although quantum programming layer of abstraction is useful to learn about first! Being able to dial in to a real quantum machine was quite awesome.
So in short, I am happy to say that the reception has been positive. It is great to know that people are enjoying something I helped to build.
I also had a blast writing the assignments for Applied Quantum Computing III: Algorithm and Software. This course corresponds to the last 5 weeks of a 15-week course at Purdue. The first 10 weeks are an introduction to quantum mechanics and quantum computing physics. Then for the last part of the course, students get a crash course in quantum algorithms and quantum programming. This made the task of designing these assignments a bit easier since we had the freedom to ask students to write code. We settled on a typical programming assignment structure where students were asked to implement different quantum algorithms using Q# and then run them on Azure Quantum simulators and/or hardware. The list of topics covered includes Simon’s algorithm, Bernstein-Vazirani algorithm, Grover’s algorithm, and Quantum Approximate Optimization Algorithm (QAOA).
Unlike the previous course, these assignments have yet to be used. So it remains to be seen how students will react to these quantum programming assignments. Maybe I am biased but I think they will enjoy learning about quantum programming using the powerful tools provided by Microsoft QDK and Microsoft Azure. I am certainly looking forward to seeing the feedback once the assignments are implemented in this coming Spring semester.
The post Developing and using Azure Quantum assignments for quantum computing courses appeared first on Q# Blog.
]]>The post λ-Q#: Understanding and Evolving the Q# Programming Language appeared first on Q# Blog.
]]>Fast-forwarding by two or so years, I was interning at Microsoft Quantum on an unrelated project. Q# was still at the back of my mind, so while there, I tried to understand the history and pain points of the language by talking with the designers. This led me to propose a longer-term project for defining formal semantics for Q# and solving some of the problems I learned about. This project is far from complete, but I wanted to share some progress with you.
What does it mean to formally define a language, and why do we want to do it? While many programming languages come with informal specifications, they are written in natural languages (like English), often leaving subtle technical concepts for interpretation (leading to the infamous undefined behavior). A formal specification uses mathematical notation to avoid ambiguity in the meaning of the language and hence aids in understanding and allows precise implementation. This makes it easier to evaluate how new features may interact with existing ones, helping with the evolution of the language.
At a high level, a formal specification consists of the following:
Designing a new language with a formal specification is much easier than endowing an existing language with one. The design decisions aimed at user convenience can typically be at odds with the needs of a researcher studying the language. Since Q# already exists, we borrowed the methodology pioneered in the specification of the Standard ML programming language:^{[2]}
λ_{Q#} is a simply typed λ-calculus extended with commands encapsulating actions on the quantum state. In λ_{Q#}, we may encode any Q# program as a pure functional term, analogous to how a language like Haskell treats side effects (we also borrow the do notation from Haskell). The Algol programming language pioneered the idea of safely combining pure functional programming with side-effectful imperative programming.^{[3]}
Quantum teleportation in λ_{Q#} syntax
The syntax, the type system, and the safety properties of λ_{Q#} (enforcing the no-cloning theorem and safe qubit memory management; that the Q# compiler currently does not enforce) have been discussed in various presentations.^{[4]} I take this opportunity to instead emphasize how the dynamic semantics of the language is defined in an accessible manner using a small set of program equations.
In the following equations, the terms on the left of the turnstile (⊢) show the types of variables used in the equations. qref⟨q⟩ represents the type of qubit; × represents the product type; ≡ is the symbol for equivalence; ⟨⟩ represents unit; and D(U, V) = U ⊕ V represents a block diagonal matrix corresponding to controlled unitaries.
λ_{Q#} program equations relating unitary gates and measurement (A and B) and those relating allocation with unitaries and measurement (D and E)
Equation (A) says that applying the quantum X gate to a qubit and then measuring it is the same as negating the measurement result. Equation (B) explains the action of a block diagonal matrix D(U, V) as quantum control: Applying the diagonal matrix and then measuring the control qubit is equivalent to measuring the control qubit and branching on the result to decide whether to apply U or V.
Equation (D) states that measuring a new qubit always results in 0 (false in our language). Equation (E) says that using a new qubit as control is the same as controlling by 0.
These four are the most interesting equations; I omit the other seven administrative equations. This presentation of semantics is known as algebraic or equational semantics. The key idea is to capture the entire behavior of a language using a complete set of equations. For quantum computation, this fully complete set (that we adapt for λ_{Q#}) was first introduced by Sam Staton in a 2015 paper. The beauty of this presentation style is two-fold: it is both broadly accessible as almost everyone is familiar with equations from school-level mathematics, and it is concise while still being formal.
I hope this post helps you understand our approach to formally specifying Q# using program equations. For full details, see our paper Q# as a Quantum Algorithmic Language (arXiv:2206.03532) presented at the Quantum Physics and Logic conference earlier this year. In the paper, my coauthors (Kesha Hietala, Sarah Marshall, Robert Rand) and I argue that λ_{Q#} represents the core of Q# as an Algol-like quantum language. It safely combines pure (classical) and effectful (quantum) computation while obeying a strict stack discipline for (qubit) memory management. We also provide translation rules from Q# to λ_{Q#}.
λ_{Q#} is an idealized version of Q# aimed at providing it a formal language definition, placing the language on a solid mathematical foundation, and enabling further evolution of its design and type system. I am currently working on preventing aliasing in Q# arrays and coverage of remaining features in λ_{Q#}; look out for my upcoming dissertation!
The post λ-Q#: Understanding and Evolving the Q# Programming Language appeared first on Q# Blog.
]]>The post Signing up for Azure Quantum from scratch appeared first on Q# Blog.
]]>Because of its global importance, signing up for Azure is maybe a bit more complicated than you are used to. To help you get started, I will use this post to walk you through the signing up process. At the end of this tutorial, you will be ready to explore our gallery notebooks, write your own, and use the hardware and simulators of our partners. To get there as a first-time user, you have to take the following steps, which are explained below:
Before you get started, you could check the availability of the Azure Quantum providers IonQ, Quantinuum, and Rigetti in your country, which you can do at the Global availability of Azure Quantum providers page.
Heads up: getting a quantum workspace is free, but you will need to provide a credit or debit card number to set up a subscription.
You need a general Azure account to get access to Azure Quantum. To set up this account, go to
A note for students and educators in the US: If you have an .edu email address, then you might want to use that to set up your account as that gets you a free student subscription. But to keep things simple and as general as possible, I will assume here that you are not using a .edu address.
Once you have created an account, things should look like this:
Before you can get a quantum resource, you must create a subscription as part of your account. Select the blue “Start” button under “Start with an Azure free trial”. If this is your first Azure account, then you are eligible for the free subscription. You should now be at the site
which should look like this:
Select the “Start free” button and wait a few seconds. Now enter “profile” data. As part of this process, use “Text me” or “Call me” to get a verification code. Select “I agree to the customer agreement and privacy agreement”. Select “Next” and wait a few seconds. Now, since Azure provides paid services, you have to provide a credit card number. But, as it states: “you won’t be charged unless you move to pay-as-you-go pricing”. Enter this data, select “Sign up”, and wait a moment.
At this point you have a subscription and your portal site https://portal.azure.com/ should look like this:
Your Quantum Workspace will be considered a resource, hence: select “+ Create a resource”, search for “Azure Quantum”, and when found, select “Create”.
When you get to the Create Quantum Workspace site, you want to select “Quick create”:
You’re almost there: give your workspace a proper name and enter your Region. Check Azure geographies page to see how the various regions are defined.
Hit the Create button at the bottom of the page and keep in mind that the deployment of the workspace takes about 5 minutes to complete. Once done, you can “Go to resource”. You can claim success if your portal looks like this:
Congratulations, you are now ready to explore the many resources available on Azure Quantum, such as:
.
To get going with the gallery notebooks you first have to copy them to My notebooks so that you can view, execute, and edit them to your heart’s content.
Enjoy and Happy Holidays!
The post Signing up for Azure Quantum from scratch appeared first on Q# Blog.
]]>The post Teaching Quantum Computing with Q# and Azure Quantum at Northeastern University appeared first on Q# Blog.
]]>This fall I taught an “Introduction to Quantum Computing” course at Northeastern University. It was my second time teaching this course at NEU, after the first run in spring 2020. As always, it was a unique experience that taught me a lot – though, hopefully, it taught my students more! – so I decided to share the highlights of my experience with you.
In this course, I introduce quantum computing to graduate students at the College of Engineering at Northeastern University who pursue a non-physics major. This allowed me to teach the contents through the lens of software engineering rather than physics, spending only a bit of time on an overview of physical implementations of quantum devices and instead spend more time on the algorithm implementation and quantum software stack. In fact, my approach was based on the one our team took when teaching at University of Washington back in 2019: introduce the basic concepts of quantum computing and simple algorithms, focusing on using them for solving problems and implementing and evaluating algorithms. Same as back then, I used Q# and Microsoft Quantum Development Kit as the software tools for the course, adding Azure Quantum for running programs on cloud simulators and hardware.
The three-month course consisted of two parts:
Let’s take a closer look at the three different kinds of assignments that the course offered: solving programming problems, debugging code, and running code on Azure Quantum.
This type of assignment requires the students to apply the theoretical concepts and algorithms they have learned to solve simple programming problems. To give you some examples,
Same as in the exercises in the Quantum Katas, each problem describes the task and provides the signature of a Q# operation that matches the description of the given problem. The student has to implement the operation that solves the task and turn in their code. The grading is done automatically using a testing harness – Q# code that runs the solutions on a set of tests using quantum simulators and checks that their results match the expected ones.
We’ve used similar assignments in the past courses as well, but this time I took them one step further. In the past we didn’t share the testing harnesses with the students, since they often included solutions to the problems (see “Inside the Quantum Katas” blog series for examples of testing code that relies on reference solutions), and you don’t really want to include the solution as part of the graded assignment! This meant that the instructors and teaching assistants could use the testing harness to automate the grading process, but the students had to come up with other ways to test their work. This could be challenging at times, especially in the first weeks when the students were exposed to a lot of completely new concepts at once.
For this course, I took the feedback from the past courses to heart and modified the projects to conceal the testing code while allowing the students to execute it. This allowed me to share it with my students without revealing the solutions, and my students – to test their code themselves and to figure out which tasks they needed to focus on.
Debugging assignments offer the students a quantum program that has a number of bugs of different kinds and ask them to identify and fix them. They aim to improve the students’ familiarity with the software tools they use and with the algorithms covered in the course. I used them during the weeks that covered well-studied algorithms such as BB84 quantum key distribution protocol or Grover’s search, when the students are already familiar with the basics of quantum programming and can focus on the logic behind the program.
Tracking down different types of errors emphasize different aspects of writing and running quantum programs:
The final type of assignment encourages the students to explore the behavior of quantum programs on the cloud simulators and quantum devices available via Azure Quantum using the free Azure Quantum credits. The tasks were mostly introductory, teaching the students to run Q# programs on cloud targets and to interpret the results rather than diving deep into the hardware.
This semester was the first time I introduced Azure Quantum-based assignments. I’m looking forward to improving them and including new tools, such as the recently released Azure Quantum resource estimation tool, in the course!
Check out Azure Quantum for Educators page to see examples of materials developed for the course.
The post Teaching Quantum Computing with Q# and Azure Quantum at Northeastern University appeared first on Q# Blog.
]]>The post Automate Resource Estimation with QIR appeared first on Q# Blog.
]]>In these samples, e.g., Estimation with Q# input, you can generate resource estimations like the following that are computed from a quantum program that multiplies two quantum registers (click on the titles to unfold more tables with details on the estimates):
Physical qubits | 8160 |
Number of physical qubits
This value represents the total number of physical qubits, which is the sum of 4200 physical qubits to implement the algorithm logic, and 3960 physical qubits to execute the T factories that are responsible to produce the T states that are consumed by the algorithm. |
Runtime | 6ms 80us |
Total runtime
This is a runtime estimate (in nanosecond precision) for the execution time of the algorithm. In general, the execution time corresponds to the duration of one logical cycle (10us) multiplied by the 608 logical cycles to run the algorithm. If however the duration of a single T factory (here: 82us 500ns) is larger than the algorithm runtime, we extend the number of logical cycles artificially in order to exceed the runtime of a single T factory. |
Logical algorithmic qubits | 84 |
Number of logical qubits for the algorithm after layout
Laying out the logical qubits in the presence of nearest-neighbor constraints requires additional logical qubits. In particular, to layout the ${Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}=33$ logical qubits in the input algorithm, we require in total $2\cdot {Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}+\lceil \sqrt{8\cdot {Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}}\rceil +1=84$ logical qubits. |
Algorithmic depth | 608 |
Number of logical cycles for the algorithm
To execute the algorithm using Parallel Synthesis Sequential Pauli Computation (PSSPC), operations are scheduled in terms of multi-qubit Pauli measurements, for which assume an execution time of one logical cycle. Based on the input algorithm, we require one multi-qubit measurement for the 8 single-qubit measurements, the 0 arbitrary single-qubit rotations, and the 0 T gates, three multi-qubit measurements for each of the 192 CCZ and 8 CCiX gates in the input program, as well as No rotations in algorithm multi-qubit measurements for each of the 0 non-Clifford layers in which there is at least one single-qubit rotation with an arbitrary angle rotation. |
Logical depth | 608 |
Number of logical cycles performed
This number is usually equal to the logical depth of the algorithm, which is 608. However, in the case in which a single T factory is slower than the execution time of the algorithm, we adjust the logical cycle depth to exceed the T factory’s execution time. |
Number of T states | 800 |
Number of T states consumed by the algorithm
To execute the algorithm, we require one T state for each of the 0 T gates, four T states for each of the 192 CCZ and 8 CCiX gates, as well as No rotations in algorithm for each of the 0 single-qubit rotation gates with arbitrary angle rotation. |
Number of T factories | 11 |
Number of T factories capable of producing the demanded 800 T states during the algorithm’s runtime
The total number of T factories 11 that are executed in parallel is computed as $\lceil {\displaystyle \frac{800\phantom{\rule{thickmathspace}{0ex}}\text{T states}\cdot 82us500ns\phantom{\rule{thickmathspace}{0ex}}\text{T factory duration}}{1\phantom{\rule{thickmathspace}{0ex}}\text{T states per T factory}\cdot 6ms80us\phantom{\rule{thickmathspace}{0ex}}\text{algorithm runtime}}}\rceil $ |
Number of T factory invocations | 73 |
Number of times all T factories are invoked
In order to prepare the 800 T states, the 11 copies of the T factory are repeatedly invoked 73 times. |
Physical algorithmic qubits | 4200 |
Number of physical qubits for the algorithm after layout
The 4200 are the product of the 84 logical qubits after layout and the 50 physical qubits that encode a single logical qubit. |
Physical T factory qubits | 3960 |
Number of physical qubits for the T factories
Each T factory requires 360 physical qubits and we run 11 in parallel, therefore we need $3960=360\cdot 11$ qubits. |
Required logical qubit error rate | 9.79e-9 |
The minimum logical qubit error rate required to run the algorithm within the error budget
The minimum logical qubit error rate is obtained by dividing the logical error probability 5.00e-4 by the product of 84 logical qubits and the total cycle count 608. |
Required logical T state error rate | 6.25e-7 |
The minimum T state error rate required for distilled T states
The minimum T state error rate is obtained by dividing the T distillation error probability 5.00e-4 by the total number of T states 800. |
Number of T states per rotation | No rotations in algorithm |
Number of T states to implement a rotation with an arbitrary angle
The number of T states to implement a rotation with an arbitrary angle is $\lceil 0.53{\mathrm{log}}_{2}(0/0)+5.3\rceil $ [arXiv:2203.10064]. For simplicity, we use this formula for all single-qubit arbitrary angle rotations, and do not distinguish between best, worst, and average cases. |
QEC scheme | surface_code |
Name of QEC scheme
You can load pre-defined QEC schemes by using the name |
Code distance | 5 |
Required code distance for error correction
The code distance is the smallest odd integer greater or equal to $\frac{2\mathrm{log}(0.08/0.000000009790100250626566)}{\mathrm{log}(0.0015/0.000001)}}-1$ |
Physical qubits | 50 |
Number of physical qubits per logical qubit
The number of physical qubits per logical qubit are evaluated using the formula 2 * codeDistance * codeDistance that can be user-specified. |
Logical cycle time | 10us |
Duration of a logical cycle in nanoseconds
The runtime of one logical cycle in nanoseconds is evaluated using the formula 20 * oneQubitMeasurementTime * codeDistance that can be user-specified. |
Logical qubit error rate | 2.37e-11 |
Logical qubit error rate
The logical qubit error rate is computed as $0.08\cdot {\left({\displaystyle \frac{0.000001}{0.0015}}\right)}^{\frac{5+1}{2}}$ |
Crossing prefactor | 0.08 |
Crossing prefactor used in QEC scheme
The crossing prefactor is usually extracted numerically from simulations when fitting an exponential curve to model the relationship between logical and physical error rate. |
Error correction threshold | 0.0015 |
Error correction threshold used in QEC scheme
The error correction threshold is the physical error rate below which the error rate of the logical qubit is less than the error rate of the physical qubit that constitute it. This value is usually extracted numerically from simulations of the logical error rate. |
Logical cycle time formula | 20 * oneQubitMeasurementTime * codeDistance |
QEC scheme formula used to compute logical cycle time
This is the formula that is used to compute the logical cycle time 10us. |
Physical qubits formula | 2 * codeDistance * codeDistance |
QEC scheme formula used to compute number of physical qubits per logical qubit
This is the formula that is used to compute the number of physical qubits per logical qubits 50. |
Physical qubits | 360 |
Number of physical qubits for a single T factory
This corresponds to the maximum number of physical qubits over all rounds of T distillation units in a T factory. A round of distillation contains of multiple copies of distillation units to achieve the required success probability of producing a T state with the expected logical T state error rate. |
Runtime | 82us 500ns |
Runtime of a single T factory
The runtime of a single T factory is the accumulated runtime of executing each round in a T factory. |
Number of output T states per run | 1 |
Number of output T states produced in a single run of T factory
The T factory takes as input 345 noisy physical T states with an error rate of 0.01 and produces 1 T states with an error rate of 2.52e-7. |
Number of input T states per run | 345 |
Number of physical input T states consumed in a single run of a T factory
This value includes the physical input T states of all copies of the distillation unit in the first round. |
Distillation rounds | 2 |
The number of distillation rounds
This is the number of distillation rounds. In each round one or multiple copies of some distillation unit is executed. |
Distillation units per round | 23, 1 |
The number of units in each round of distillation
This is the number of copies for the distillation units per round. |
Distillation units | 15-to-1 space efficient physical, 15-to-1 space efficient logical |
The types of distillation units
These are the types of distillation units that are executed in each round. The units can be either physical or logical, depending on what type of qubit they are operating. Space-efficient units require fewer qubits for the cost of longer runtime compared to Reed-Muller preparation units. |
Distillation code distances | 1, 3 |
The code distance in each round of distillation
This is the code distance used for the units in each round. If the code distance is 1, then the distillation unit operates on physical qubits instead of error-corrected logical qubits. |
Number of physical qubits per round | 276, 360 |
The number of physical qubits used in each round of distillation
The maximum number of physical qubits over all rounds is the number of physical qubits for the T factory, since qubits are reused by different rounds. |
Runtime per round | 4us 500ns, 78us |
The runtime of each distillation round
The runtime of the T factory is the sum of the runtimes in all rounds. |
Logical T state error rate | 2.52e-7 |
Logical T state error rate
This is the logical T state error rate achieved by the T factory which is equal or smaller than the required error rate 6.25e-7. |
Logical qubits (pre-layout) | 33 |
Number of logical qubits in the input quantum program
We determine 84 from this number by assuming to align them in a 2D grid. Auxiliary qubits are added to allow for sufficient space to execute multi-qubit Pauli measurements on all or a subset of the logical qubits. |
T gates | 0 |
Number of T gates in the input quantum program
This includes all T gates and adjoint T gates, but not T gates used to implement rotation gates with arbitrary angle, CCZ gates, or CCiX gates. |
Rotation gates | 0 |
Number of rotation gates in the input quantum program
This is the number of all rotation gates. If an angle corresponds to a Pauli, Clifford, or T gate, it is not accounted for in this number. |
Rotation depth | 0 |
Depth of rotation gates in the input quantum program
This is the number of all non-Clifford layers that include at least one single-qubit rotation gate with an arbitrary angle. |
CCZ gates | 192 |
Number of CCZ-gates in the input quantum program
This is the number of CCZ gates. |
CCiX gates | 8 |
Number of CCiX-gates in the input quantum program
This is the number of CCiX gates, which applies $-iX$ controlled on two control qubits [1212.5069]. |
Measurement operations | 8 |
Number of single qubit measurements in the input quantum program
This is the number of single qubit measurements in Pauli basis that are used in the input program. Note that all measurements are counted, however, the measurement result is is determined randomly (with a fixed seed) to be 0 or 1 with a probability of 50%. |
Total error budget | 1.00e-3 |
Total error budget for the algorithm
The total error budget sets the overall allowed error for the algorithm, i.e., the number of times it is allowed to fail. Its value must be between 0 and 1 and the default value is 0.001, which corresponds to 0.1%, and means that the algorithm is allowed to fail once in 1000 executions. This parameter is highly application specific. For example, if one is running Shor’s algorithm for factoring integers, a large value for the error budget may be tolerated as one can check that the output are indeed the prime factors of the input. On the other hand, a much smaller error budget may be needed for an algorithm solving a problem with a solution which cannot be efficiently verified. This budget $\u03f5={\u03f5}_{\mathrm{log}}+{\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}+{\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$ is uniformly distributed and applies to errors ${\u03f5}_{\mathrm{log}}$ to implement logical qubits, an error budget ${\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}$ to produce T states through distillation, and an error budget ${\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$ to synthesize rotation gates with arbitrary angles. Note that for distillation and rotation synthesis, the respective error budgets ${\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}$ and ${\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$ are uniformly distributed among all T states and all rotation gates, respectively. If there are no rotation gates in the input algorithm, the error budget is uniformly distributed to logical errors and T state errors. |
Logical error probability | 5.00e-4 |
Probability of at least one logical error
This is one third of the total error budget 1.00e-3 if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise. |
T distillation error probability | 5.00e-4 |
Probability of at least one faulty T distillation
This is one third of the total error budget 1.00e-3 if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise. |
Rotation synthesis error probability | 0.00e0 |
Probability of at least one failed rotation synthesis
This is one third of the total error budget 1.00e-3. |
Qubit name | qubit_maj_ns_e6 |
Some descriptive name for the qubit model
You can load pre-defined qubit parameters by using the names |
Instruction set | Majorana |
Underlying qubit technology (gate-based or Majorana)
When modeling the physical qubit abstractions, we distinguish between two different physical instruction sets that are used to operate the qubits. The physical instruction set can be either gate-based or Majorana. A gate-based instruction set provides single-qubit measurement, single-qubit gates (incl. T gates), and two-qubit gates. A Majorana instruction set provides a physical T gate, single-qubit measurement and two-qubit joint measurement operations. |
Single-qubit measurement time | 100 ns |
Operation time for single-qubit measurement (t_meas) in ns
This is the operation time in nanoseconds to perform a single-qubit measurement in the Pauli basis. |
Two-qubit measurement time | 100 ns |
Operation time for two-qubit measurement in ns
This is the operation time in nanoseconds to perform a non-destructive two-qubit joint Pauli measurement. |
T gate time | 100 ns |
Operation time for a T gate
This is the operation time in nanoseconds to execute a T gate. |
Single-qubit measurement error rate | 1E-06 |
Error rate for single-qubit measurement
This is the probability in which a single-qubit measurement in the Pauli basis may fail. |
Two-qubit measurement error rate | 1E-06 |
Error rate for two-qubit measurement
This is the probability in which a non-destructive two-qubit joint Pauli measurement may fail. |
T gate error rate | 0.01 |
Error rate to prepare single-qubit T state or apply a T gate (p_T)
This is the probability in which executing a single T gate may fail. |
More details on the following lists of assumptions can be found in the paper Accessing requirements for scaling quantum computers and their applications.
Uniform independent physical noise. We assume that the noise on physical qubits and physical qubit operations is the standard circuit noise model. In particular we assume error events at different space-time locations are independent and that error rates are uniform across the system in time and space.
Efficient classical computation. We assume that classical overhead (compilation, control, feedback, readout, decoding, etc.) does not dominate the overall cost of implementing the full quantum algorithm.
Extraction circuits for planar quantum ISA. We assume that stabilizer extraction circuits with similar depth and error correction performance to those for standard surface and Hastings-Haah code patches can be constructed to implement all operations of the planar quantum ISA (instruction set architecture).
Uniform independent logical noise. We assume that the error rate of a logical operation is approximately equal to its space-time volume (the number of tiles multiplied by the number of logical time steps) multiplied by the error rate of a logical qubit in a standard one-tile patch in one logical time step.
Negligible Clifford costs for synthesis. We assume that the space overhead for synthesis and space and time overhead for transport of magic states within magic state factories and to synthesis qubits are all negligible.
Smooth magic state consumption rate. We assume that the rate of T state consumption throughout the compiled algorithm is almost constant, or can be made almost constant without significantly increasing the number of logical time steps for the algorithm.
«We have found the Resource Estimator simple to use despite the complexity of fault-tolerant computing schemes. In this tool, resource estimates are neatly laid-out at a glance, and hardware parameters and model assumptions can be easily tweaked. This kind of tool represents exactly what will be needed for designing large-scale algorithms and computations that are more resource-efficient, which is a major focus of our work.», notes Jing Hao CHAI, Fault-tolerant Quantum Computing Scientist at Entropica Labs.
To use the Resource Estimator in your day-to-day quantum computing work, and especially to automate multiple resource estimation jobs, it may be more convenient to integrate it directly into your existing toolchains or workflows. In this blog post, we will we use the Azure Quantum Python library to write a Python tool that returns resource estimates in JSON format given as input a QIR program. The complete source code is available in this Gist.
With the tool it will be possible to generate physical resource estimates as simple as:
python estimate.py quantum_program.qir > resources.json
Let’s start by declaring some program arguments:
import argparse, os
parser = argparse.ArgumentParser(
prog="estimate",
description="Estimate physical resources using Azure Quantum")
parser.add_argument("filename", help="Quantum program (.ll, .qir, .bc)")
parser.add_argument("-r", "--resource-id",
default=os.environ.get("AZURE_QUANTUM_RESOURCE_ID"),
help="Resource ID of Azure Quantum workspace (must be set, unless set via \
environment variable AZURE_QUANTUM_RESOURCE_ID)")
parser.add_argument("-l", "--location",
default=os.environ.get("AZURE_QUANTUM_LOCATION)"),
help="Location of Azure Quantum workspace (must be set, unless set via \
environment AZURE_QUANTUM_LOCATION")
parser.add_argument("-p", "--job-params", help="JSON file with job parameters")
args = parser.parse_args()
The Python tool takes a QIR program as input, which can be either in human-readable LLVM code (.ll
and .qir
extension) or directly in bitcode (.bc
extension). The tool also requires information on how to connect with your Azure Quantum workspace, which can be either passed as program arguments or using environment variables. An Azure Quantum workspace allows us to access the resource estimator target and submit resource estimation jobs. If you do not have an Azure account, you can set one up for free here. If you do not have an Azure Quantum workspace, create one here. You will find the resource id and the location in the Overview page of your Azure Quantum workspace.
Next, we are connecting to our Azure Quantum workspace:
from azure.quantum import Workspace
workspace = Workspace(resource_id=args.resource_id, location=args.location)
The QIR program can be generated from other quantum programming languages like Q# (more details on generating QIR from Q#) and Qiskit (more details on generating QIR from Qiskit). If the QIR is provided in human-readable LLVM code, we first need to translate it to LLVM bitcode via the PyQIR library:
from pyqir.generator import ir_to_bitcode
ext = os.path.splitext(args.filename)[1].lower()
if ext in ['.qir', '.ll']:
with open(args.filename, 'r') as f:
bitcode = ir_to_bitcode(f.read())
elif ext == '.bc':
with open(args.filename, 'rb') as f:
bitcode = f.read()
In addition to the quantum program, one can pass job parameters that model the assumed fault-tolerant quantum computer. If no job parameters are specified, a default model is assumed. You can find more information on the job parameters in the Azure Quantum documentation. Job parameters can be provided through an optional JSON file such as the following:
{
"qubitParams": {"name": "qubit_maj_ns_e6"},
"qecScheme": {"name": "floquet_code"},
"errorBudget": 0.005
}
We read such a file using Python’s json
library:
import json
input_params = {}
if args.job_params:
with open(args.job_params, 'r') as f:
input_params = json.load(f)
Now that we have access to the Azure Quantum workspace, the QIR program, and the job parameters, we are ready to create and submit a resource estimation job:
from azure.quantum import Job
job = Job.from_input_data(
workspace=workspace,
name="Estimation job",
target="microsoft.estimator",
input_data=bitcode,
provider_id="microsoft-qc",
input_data_format="qir.v1",
output_data_format="microsoft.resource-estimates.v1",
input_params=input_params
)
job.wait_until_completed()
Now all what is left to do is to extract the results from the job and print them in JSON format:
result = job.get_results()
print(json.dumps(result, indent=4))
The resulting output looks as follows:
{
// ...
"physicalCounts": {
"breakdown": {
"algorithmicLogicalDepth": 3479912,
"algorithmicLogicalQubits": 217,
"cliffordErrorRate": 0.001,
"logicalDepth": 3479912,
"numTfactories": 18,
"numTfactoryRuns": 242135,
"numTsPerRotation": 15,
"numTstates": 4358430,
"physicalQubitsForAlgorithm": 191394,
"physicalQubitsForTfactories": 599760,
"requiredLogicalQubitErrorRate": 4.4141872274122407e-13,
"requiredLogicalTstateErrorRate": 7.648013925503755e-11
},
"physicalQubits": 791154,
"runtime": 29231260800
},
// ...
}
Here are some ideas on what to try next:
The post Automate Resource Estimation with QIR appeared first on Q# Blog.
]]>