Five Major Use Cases for a Classical Quantum Simulator

  1. Simulate simply because a real quantum computer is not yet available. Or that available real quantum computers are insufficient to meet your computing requirements, such as number of qubits, qubit fidelity, and connectivity.
  2. Simulating an ideal quantum computer, with no noise and no errors. Primarily for research, experimentation, and education. And for testing and debugging for logic errors.
  3. Determining what the results of a quantum circuit should be — without any of the noise of a real quantum computer.
  4. Simulating an actual, real quantum computer, matching its noise and error rate. Replicate the behavior of the real machine as closely as possible.
  5. Simulating a proposed quantum computer, matching its expected noise and error rate. Evaluate proposed work before it is done — simulate before you build.
  6. Simulating proposed enhancements to an existing quantum computer, matching its expected noise and error rate. Evaluate proposed work before it is done — simulate before you build.
  7. Debugging a quantum circuit, such as examining all details of quantum state which are not observable on a real quantum computer. For those who are not perfect and are unable to write bug-free algorithms and circuits from the start.
  8. Analysis of execution of a quantum circuit. There is far too much which cannot be easily predicted.
  9. Benchmarking a real quantum computer, comparing actual results with simulated results. Such as for IBM’s Quantum Volume metric.
  10. Repeated runs with different noise and error rates to determine what noise and error rate must be achieved to achieve a desired success rate for achieving expected results. What advances in hardware must be achieved to run a particular quantum circuit?
  11. And more.
  1. Perfect simulation. No noise and no errors. Good for research and testing and debugging of logic errors.
  2. Theoretical ideal real simulation. Not quite perfect since there are theoretical limits from quantum mechanics.
  3. Match an existing real quantum computer. Very closely match the error and limit profile for a particular real quantum computer — so simulation results closely match the real machine.
  4. Match a proposed real quantum computer. Tune noise and error profile for proposed enhancements to evaluate how effective they will be — simulate before you build.
  5. Near-perfect qubits. Evaluate algorithms based on varying levels (nines) of qubit fidelity.
  1. Most users should be focused on accurate simulators rather than current real quantum computers.
  2. Is quantum simulation the same as quantum simulator?
  3. The future of classical quantum simulators even if not the present.
  4. Why use a classical quantum simulator?
  5. Overarching goal: Focus on where the “puck” will be in 2–4 years rather than current hardware which will be hopelessly obsolete by then.
  6. Quantum algorithms and quantum circuits are rough synonyms.
  7. Target quantum computer.
  8. Profile for a target quantum computer.
  9. Personas, use cases, and access patterns.
  10. The five major use cases.
  11. Access patterns.
  12. Personas for simulation of quantum circuits.
  13. Users.
  14. Major use case #1: Perfect simulation.
  15. Major use case #2: Theoretical ideal real simulation.
  16. Major use case #3: Match an existing real quantum computer.
  17. Major use case #4: Match a proposed real quantum computer.
  18. Major use case #5: Near-perfect qubits.
  19. Determining what the results of a quantum circuit should be — without any of the noise of a real quantum computer.
  20. Quantum error correction (QEC).
  21. Would a separate use case be needed for quantum error correction?
  22. Will quantum error correction really be perfect?
  23. Should debugging be a major use case?
  24. Generally, the use cases revolve around criteria for configuring noise and error rates.
  25. Simulate before you build.
  26. Why simulate if real hardware is available?
  27. Noise models.
  28. Per-qubit noise and error model.
  29. Noise models analogous to classical device drivers.
  30. Most users should not create, edit, look at, or even be aware of the details of noise models.
  31. High-level control of noise models.
  32. Selecting nines of qubit fidelity for noise models.
  33. Viewing effective nines of qubit fidelity.
  34. Inventory of known quantum computers.
  35. Parameters and properties for use cases and access patterns.
  36. Precision in simulation.
  37. Precision in unitary matrices.
  38. Granularity of phase and probability amplitude.
  39. Limitations of simulation of quantum circuits.
  40. Simulation details.
  41. Debugging features.
  42. Use of perfect simulation to test for and debug logic errors.
  43. Rerun a quantum circuit with the exact same noise and errors to test a bug fix.
  44. Checking of unitary matrix entries.
  45. Need for blob storage for quantum states.
  46. What to do about shot counts for large simulations.
  47. Resources required for simulation of deep quantum circuits.
  48. Is there a practical limit to the depth of quantum circuits?
  49. Will simulation of Shor’s factoring algorithm be practical?
  50. Alternative simulation modes.
  51. Pulse control simulation.
  52. Major caveat: Simulation is limited to roughly 50 qubits.
  53. Need for scalable algorithms.
  54. Need for automated algorithm analysis tools.
  55. Need to push for simulation of 45 to 55 qubits.
  56. Would simulation of 60 to 65 qubits be useful if it could be achieved?
  57. Potential to estimate Quantum Volume without the need to run on a real quantum computer
  58. Simulation is an evolving, moving target, subject to change — this is simply an initial snapshot.
  59. Summary and conclusions.

Most users should be focused on accurate simulators rather than current real quantum computers

Is quantum simulation the same as quantum simulator?

The future of classical quantum simulators even if not the present

Why use a classical quantum simulator?

  1. Simulate quantum circuit execution when no real quantum computer hardware is yet available.
  2. Simulate quantum circuit execution when no real quantum computer hardware is available with sufficient resources — not enough qubits, qubit coherence time is too short for required circuit depth, qubit fidelity is too low, or qubit connectivity is insufficient.
  3. Test a quantum algorithm on an imaginary, hypothetical ideal quantum computer as part of a research project.
  4. Simulate an existing real quantum computer as accurately as possible.
  5. Simulate a proposed change to an existing quantum computer.
  6. Simulate a proposed new quantum computer.
  7. Evaluate what changes to existing quantum computers would be needed to enable particular algorithms to return more acceptable results.
  8. Debug a quantum algorithm (quantum circuit.)
  9. Single-step through a quantum circuit.
  10. Examine the full quantum state of result qubits just before they are measured for actual results.
  11. Simulate a quantum circuit when measuring Quantum Volume for a real quantum computer.
  12. Develop baseline test results for comparison against results from a real machine.
  13. Develop, test, and evaluate a noise model to be used for future simulator runs.

Overarching goal: Focus on where the “puck” will be in 2–4 years rather than current hardware which will be hopelessly obsolete by then

Quantum algorithms and quantum circuits are rough synonyms

Target quantum computer

  1. An actual, real quantum computer.
  2. A hypothetical or proposed quantum computer.
  3. An ideal quantum computer.

Profile for a target quantum computer

  1. Vendor name. Full name.
  2. Vendor handle. Short name for the vendor.
  3. Vendor quantum computer family name or other identifier.
  4. Vendor model number or other identification.
  5. Serial number for a particular instance of some model of quantum computer.
  6. Number of qubits.
  7. Noise model.
  8. Actual or expected overall qubit fidelity. Can include nines of qubit fidelity, qubit coherence time, gate error rate, and measurement error rate.
  9. Fidelity for individual qubits, when that level of detail is available.
  10. Qubit connectivity. Which qubits may participate in a two-qubit quantum logic gate.
  11. Precision of unitary matrix entries supported.
  12. Granularity of phase supported.
  13. Granularity of probability amplitudes supported.
  14. Coherence time and a sense of maximum circuit depth. Be able to report to the user if their quantum circuit exceeds the maximum circuit depth. Maybe two thresholds, one to issue a warning diagnostic, and another to abort the simulation. Otherwise, users may struggle to figure out exactly while their circuit results are so unexpected.

Personas, use cases, and access patterns

  1. Personas. Who is using it? What is their role or function in the organization? Also known as an archetype.
  2. Use cases. What goals or purposes are they trying to achieve?
  3. Access patterns. What specific tasks are they performing in order to work towards and achieve those goals?

The five major use cases

  1. Perfect simulation. Ideal, perfect, or even naive simulation. Noise-free and error-free. No limits and maximum precision. Great for research in ideal algorithms, but does not reflect any real machine. The baseline, starting point for all other use cases. Also useful for verifying results of a real machine, such as Quantum Volume metric calculation and cross-entropy benchmarking. Also useful for testing and debugging for logic errors.
  2. Theoretical ideal real simulation. Not quite perfect since there are theoretical limits from quantum mechanics. There’s no clarity as to the precise limits at this time. It’s possible that theoretical limits may vary for different qubit technologies, such as trapped ions and superconducting transmon qubits.
  3. Match an existing real quantum computer. Very closely match the noise, error, and limit profile for a particular real quantum computer — so simulation results closely match the real machine, and given a relatively small number of real machines, could run a very large number of simulations on more plentiful classical machines. Great for evaluating algorithms intended to run on a particular real quantum computer. Should include a per-qubit noise profile since that’s how problematic current, real machines really are.
  4. Match a proposed real quantum computer. Tune noise and error profile for proposed enhancements to evaluate how effective they will be — exactly match proposed evolution for new machines — simulate before you build. This may be a relatively minor adaptation of an existing real quantum computer, significant improvements to an existing real quantum computer, or it may be for some entirely new and possibly radically distinct quantum computer.
  5. Near-perfect qubits. Configure a theoretical ideal real simulation for the number of nines of qubit fidelity. Great for evaluating perfect algorithms for varying levels of qubit fidelity. Based on theoretical ideal real simulation, configured for nines of qubit fidelity.

Access patterns

  1. Normal circuit execution. The normal, typical usage, to simply execute the circuit and retrieve the results of measured qubits.
  2. Debugging. Logging all intermediate results and quantum states for later examination. Single-step to examine quantum state at each step of the algorithm. Range of classical debugging techniques, but applied to quantum circuits. Useful for all of the main use cases.
  3. Audit trail. Capture all quantum state transitions. For external analysis. For larger circuits, it might be desirable or even necessary to specify a subset of qubits and a subset of gates to reduce the volume of state transitions captured. Blob storage may be necessary to accommodate the sheer volume of quantum states.
  4. Rerun a quantum circuit with the exact same noise and errors to test a bug fix. Some circuit failures may be due to logic bugs that only show up for particular combinations of noise and errors.
  5. Shot count. Circuit repetitions to develop the expected value of the probabilistic result using statistical aggregation of the results from the repeated executions of the circuit.
  6. Snapshot and restart. For very large simulations, periodically capture (snapshot) enough of all quantum state so that the simulation can later be restarted right where it left off.
  7. Assertions and unit testing. Check quantum state and probabilities at various steps in the circuit during execution, and just before final result measurement as well.
  8. Find maximum error rate. Specify desired results and run an algorithm repeatedly with varying error rates to find the minimum number of nines of qubit fidelity needed to get correct results a designated percentage of the time. Gives an idea of how practical an algorithm is. Or, what qubit fidelity must be achieved to enable various applications. Or, given a roadmap, at what stage various applications will be enabled. Useful for evaluating ideal algorithms or proposed changes to a real machine.
  9. Report error rate trend. Run an algorithm n times with increments of qubit fidelity and report percentage of correct results for each run. Used to evaluate the tradeoffs between error rate and correctness of results. Achieving more correct results might be too difficult or time-consuming to achieve. Useful for evaluating ideal algorithms or proposed changes to a real machine.
  10. Calibrate shot count. Experiment with a quantum circuit to find how the shot count for circuit repetitions needs to be calibrated based on various noise levels and error rates to achieve a desired success rate for results of the quantum computation.
  11. Checking of unitary matrix entries. Such as fine-grained rotation angles which may not make sense for particular hardware.
  12. Count quantum states. Gather and return counts of quantum states during circuit execution, including counts of the total quantum state transitions, total unique quantum states, and maximum simultaneous quantum states, as well as a distribution of quantum states, and histogram of quantum states over time. That can be expensive and voluminous, so allow qubits and time intervals to be selected to dramatically reduce resource requirements.

Personas for simulation of quantum circuits

  1. Algorithm researchers. Interest in hypothetical or theoretical algorithms on hypothetical or theoretical quantum computers rather than on simply current real quantum computers. Need to debug and analyze the performance of algorithms.
  2. Quantum hardware engineers. Designing and developing quantum computer hardware itself, the quantum processing unit (QPU). Evaluate predictions for how a proposed or new quantum computer should perform. Configure the simulator to match the noise levels and error rates of the prospective quantum computer. And, test and evaluate their new hardware as it is built — does it perform up to their expectations.
  3. Quantum software engineers. Designing and developing the operating software for quantum computer software. Need to test the full quantum computer system, hardware combined with operating software. Not applications per se, but need algorithm and application test cases to validate correct operation of the system. Simulate the real quantum computer to get results to compare against the actual hardware. Assure that the operating software is properly preparing quantum circuits from requests over the network connections and properly executing them on the hardware.
  4. Users with limited access to current real quantum computers. The machine may be too new to permit wider access or the demand may be so high that access is severely limited.
  5. Algorithm designers. Need to debug new algorithms (quantum circuits), even if they will technically run on existing quantum computers, but intermediate quantum states cannot be observed. Need to run a very wide range of tests, more than existing real current quantum computers can handle.
  6. Prospective users of algorithms. Experiment with algorithms to see how well they work and perform. Experient with noise levels and error rates.
  7. Application developers. Need to be able to test quantum algorithms at a fast pace, greater than access to real hardware will permit.
  8. Quality assurance testers. Test algorithms and applications on a very wide range of variability in noise levels and error rates since testing on a single real quantum computer or even a number of real quantum computers may not cover the full range of variability.
  9. Application usage testers. Test the full application before deployment. Especially if real quantum computers are not available or not available in sufficient volume. And to capture a greater range of the variability of real quantum computer hardware.
  10. IT planners. Need to plan for both quantum and classical hardware system requirements.
  11. IT staff. Need to deploy, configure, test, and maintain quantum and classical hardware systems.
  12. Technical management. Need to understand the capabilities of the hardware that their team is using. Need to understand hardware and service budgeting requirements.
  13. Research management. More specialized than non-research technical management. Focused more on the science than the engineering or products. Need to understand hardware and service budgeting requirements.
  14. Executive management. Need to understand the budget and impact of the computer hardware needed by their organization, and the need for research.
  15. Technical journalists. Understand what the technology does, its purpose, its limits.
  16. General journalists. A more general understanding of the need for simulation of real quantum computers.
  17. Students. A wide range of levels, some overlapping with the other personas, especially if involved with research or internships.
  18. Casual users. Interested in learning about quantum computers, informally.

Users

Major use case #1: Perfect simulation

  1. It’s great for research in ideal algorithms. Theoreticians contemplating the ideal.
  2. It’s the baseline or starting point or foundation for all other use cases.
  3. It’s useful for verifying results of a real machine, such as for Quantum Volume metric calculation and cross-entropy benchmarking.
  4. It’s also useful for testing and debugging for logic errors. To avoid being distracted or sent on wild goose chases by noise.

Major use case #2: Theoretical ideal real simulation

Major use case #3: Match an existing real quantum computer

  1. Debugging. Intermediate and even final quantum states are not observable on a real quantum computer. A classical quantum simulator can capture and record all quantum states.
  2. Rapid turnaround for a large number of executions. For massive testing of small quantum circuits, the network latency to run a quantum circuit could easily be much greater than the time the simulator could simulate the circuit. Plentiful commodity classical computers could permit a very large number of parallel simulations.
  3. Limited access to the actual, real quantum computer system. For new machines and for machines in very high demand, the waiting time could greatly exceed the simulation time.
  4. Faster access and more precise control of execution. Classical code can simulate exactly when it wants and exactly as it wants, not having to deal with all of the vagaries of remote execution in the cloud.
  5. Precise evaluation of intermediate states. As part of validation of the quality of the actual, real quantum computer, as well as precise validation of the execution of quantum algorithms. Similar to debugging, but used differently — debugging may be more interactive and visual, while validation is likely to be automated.

Major use case #4: Match a proposed real quantum computer

  1. A relatively minor adaptation of an existing real quantum computer.
  2. Significant improvements to an existing real quantum computer.
  3. An entirely new quantum computer. Possibly radically distinct from existing quantum computers.

Major use case #5: Near-perfect qubits

  1. Two nines. Roughly current state of the art.
  2. 2.5 nines. A more precise reference to the current state of the art. Corresponds to 99.5% reliability or a 0.5% error rate (0.005 in decimal form.)
  3. Three nines. A little better than the best we have today. May or may not be suitable for quantum error correction.
  4. Four nines. A stretch from where we are today. Probably enough for initial quantum error correction.
  5. Five nines. Possibly a limit for current quantum hardware technologies. Probably needed for efficient quantum error correction.
  6. Six nines. Near-perfect qubit fidelity.
  7. Nine nines. Even closer to perfect.
  8. Twelve nines. Possibly beyond what we can expect to achieve.
  9. Fifteen nines. Almost certainly beyond what we can expect to achieve. But still useful for algorithm research to test the limits of quantum computing.

Determining what the results of a quantum circuit should be — without any of the noise of a real quantum computer

Quantum error correction (QEC)

Would a separate use case be needed for quantum error correction?

Will quantum error correction really be perfect?

Should debugging be a major use case?

Generally, the use cases revolve around criteria for configuring noise and error rates

Simulate before you build

  1. Simulate a completely new quantum computer. Not based on a current quantum computer.
  2. Simulate incremental (or even radical) enhancements to an existing quantum computer.

Why simulate if real hardware is available?

  1. Test algorithms which cannot be run on existing real quantum computers, primarily due to low qubit fidelity of current hardware.
  2. Testing algorithms and applications for qubit fidelities and gate error rates that are different from current real quantum computers.
  3. Debugging — not possible on real quantum computers. Is your algorithm failing due to bugs in your logic or limitations of the hardware?
  4. Other forms of analysis, as enumerated in the access pattern section, beyond simply capturing results of full circuit execution.
  5. To capture the results for simple quantum circuit execution instantly for testing purposes without any of the latency, delay, or unavailability associated with queuing up to use the scarce number of real quantum computers available today and for the indefinite future.
  6. For smaller simulations, can run many simulators on a very large distributed cluster to achieve many more runs than may be possible with shared cloud access to very limited real quantum computers.

Noise models

Per-qubit noise and error model

Noise models analogous to classical device drivers

Most users should not create, edit, look at, or even be aware of the details of noise models

High-level control of noise models

Selecting nines of qubit fidelity for noise models

Viewing effective nines of qubit fidelity

Inventory of known quantum computers

Parameters and properties for use cases and access patterns

Precision in simulation

  1. Precision of entries in unitary matrices. For execution of quantum logic gates.
  2. Precision of quantum probability amplitudes. For the quantum state of qubits during simulation.
  3. Precision of phase. A subset of the quantum state of qubits. For the quantum state of qubits during simulation.
  4. Precision of readout of quantum probability amplitudes. For the quantum state of qubits during simulation as displayed or returned for debugging and analysis of qubit state.
  5. Precision of readout of phase. A subset of the quantum state of qubits. For the quantum state of qubits during simulation as displayed or returned for debugging and analysis of qubit state.
  1. A perfect simulation should have the maximum possible precision.
  2. A theoretical real ideal simulation should have a precision which closely matches the theoretical ideal, as defined by quantum mechanics.
  3. A simulation of a real machine should match the effective precision of the actual hardware, firmware, and software.
  4. A near-perfect simulation should use a precision which matches the best estimate of a real machine which would achieve the nines of qubit fidelity selected for the simulation.

Precision in unitary matrices

Granularity of phase and probability amplitude

Limitations of simulation of quantum circuits

  1. It is believed that simulation of circuits using more than about 50 qubits will not be practical since the number of potential quantum states grows exponentially as the number of qubits grows, so 50 qubits would imply 2⁵⁰ quantum states — roughly one quadrillion states.
  2. Performance of simulation of larger circuits can be problematic, both in time and the amount of storage required.
  3. At present 40 qubits may be the current practical limit for simulation — and maybe less.
  4. Finely tuning noise models to accurately model real machines is the ideal, the goal, but accuracy is not guaranteed and could potentially be problematic.

Simulation details

Debugging features

  1. The full richness of debugging on classical computers. Not all classical debugging features will be relevant to quantum computing, but certainly a nontrivial fraction.
  2. A full set of quantum-specific debugging features. Taking into account the nature of quantum state with complex probability amplitudes which can span any number of qubits when qubits become entangled — so-called product states.

Use of perfect simulation to test for and debug logic errors

  1. To facilitate debugging.
  2. To facilitate analysis of intermediate quantum state.
  3. For more controlled execution.
  4. For more rapid execution (at least for smaller circuits.)

Rerun a quantum circuit with the exact same noise and errors to test a bug fix

Checking of unitary matrix entries

Need for blob storage for quantum states

What to do about shot counts for large simulations

  1. To compensate for the noisiness and errors of current NISQ hardware.
  2. To accommodate the inherent probabilistic nature of quantum computing.

Resources required for simulation of deep quantum circuits

Is there a practical limit to the depth of quantum circuits?

  1. Physical limits of real quantum computers. Such as coherence time. There may also be limits for the capacity of the storage used by software or classical hardware which is preparing the quantum logic gates of a quantum circuit for execution.
  2. Resource limits for classical quantum simulators. Limits of capacity of storage for intermediate quantum states, as well as human patience for how long a simulation might take in wall clock time.
  1. Dozens of gates. It’s got to be more than that. But, that could be the limit for some or many current simulators, at least for circuits with more than a handful of qubits.
  2. Hundreds of gates. Hopefully at least that, but the practical limit could be in that range.
  3. Thousands of gates. That could well be well beyond the range of many simulators.
  4. Millions of gates. No reasonable expectation that this would be possible.

Will simulation of Shor’s factoring algorithm be practical?

Alternative simulation modes

  1. Full wavefunction simulator. This is a full simulation. Normal simulation. The common, default case.
  2. Hybrid Schrödinger-Feynman simulator. From Google. Built for parallel execution on a cluster of machines. It produces amplitudes for user- specified output bitstrings. “It simulates separate disjoint sets of qubit using a full wave vector simulator, and then uses Feynman paths to sum over gates that span the sets.
  3. Clifford. From IBM. Up to 5,000 qubits.
  4. Matrix Product State. From IBM. Up to 100 qubits.
  5. Extended Clifford. From IBM. Up to 63 qubits.
  6. General, context-aware. From IBM. Up to 32 qubits.
  7. Schrodinger wavefunction. From IBM. Up to 32 qubits.
  8. Pulse control simulation. From IBM. Aer PulseSimulator.

Pulse control simulation

Major caveat: Simulation is limited to roughly 50 qubits

  1. Google is claiming 40 qubits as their simulation upper bound, or even only 38 qubits using their cloud computing engine.
    https://github.com/quantumlib/qsim
  2. Intel is claiming 42 qubits as their upper bound.
    https://arxiv.org/abs/2001.10554
  3. IBM is advertising 32 qubits as their upper bound for full simulation.
    https://www.ibm.com/quantum-computing/simulator/
  4. AtoS Quantum Learning Machine is advertising simulation up to 41 qubits.
    https://atos.net/en/solutions/quantum-learning-machine

Need for scalable algorithms

Need for automated algorithm analysis tools

Need to push for simulation of 45 to 55 qubits

Would simulation of 60 to 65 qubits be useful if it could be achieved?

Potential to estimate Quantum Volume without the need to run on a real quantum computer

Simulation is an evolving, moving target, subject to change — this is simply an initial snapshot

Summary and conclusions

  1. Simulation needs to closely match noise and error profiles of both existing real quantum computers and proposed quantum computers.
  2. Need to support debugging of quantum algorithms. Especially as they become more complex and not so easy to simulate in your own head. And debugging cannot be performed on a real quantum computer since intermediate quantum states are not observable.
  3. Need to fully observe all details of quantum state during quantum circuit execution. Including measured qubits just before they are measured.
  4. Need to support full testing of quantum algorithms.
  5. Need to support analysis of quantum circuit execution which is not possible when executing the circuit on a real quantum computer.
  6. Need to focus on where the “puck” will be in 2–4 years rather than rely on current hardware which will be hopelessly obsolete by then if not much sooner.
  7. Need to focus algorithm designers on hardware of the future rather than be distracted by current hardware which is incapable of solving real, production-scale practical problems or delivering significant quantum advantage anyway.
  8. Significant further research is needed to push the envelope for maximizing performance and minimizing resources needed to simulate quantum circuits since 38–50 qubits (or even less) is approximately the limit for simulation today.
  9. Simulation is an evolving, moving target, subject to change — this is simply an initial snapshot.

--

--

--

Freelance Consultant

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jack Krupansky

Jack Krupansky

Freelance Consultant

More from Medium

What I Learned From Fire Opal…

Podcast with Tom Marshall, Bloomberg

Quantum Key Distribution

Quantum Key Distribution Protocols