Epic: Revamp Verify section about documentation

[kevinsung]

Here is my proposed plan for the Verify section:

• Rewrite Introduction (#86)
• Merge IBM Quantum simulators and Noisy simulators into a single page on IBM Quantum simulators and move to the end of the section
• Add page on noiseless and noisy simulation with Qiskit Aer
• Add page on noiseless and noisy (extended) stabilizer circuit simulation (#108)

In the end, the Verify section will have the following structure:

• Introduction
• Exact simulation with Qiskit primitives
• Exact and noisy simulation with Qiskit Aer primitives
• Build custom noise models
• Efficient (extended) stabilizer circuit simulation with Qiskit Aer
• IBM Quantum Simulators

[javabster]

@kevinsung i think this plan generally looks good to me, my only concern is that these pages might get quite long, so I'd recommend breaking them up and putting them under subheadings. We actually used to have the noisy simulation and ibm quantum simulators combined in one page as you suggest, but we split them to make it more readable.

So I'd recommend a page structure like this:

• Intro
• Qiskit Aer simulation
  • noiseless
  • custom noise models
  • extended stabilizer
• primitives simulation
  • noiseless
  • noisy (can you use noise models with primitives? Im not actually sure)
• IBM Quantum cloud-based simulation
  • available simulators
  • using the simulators

In addition, I'd be interested to hear any suggestions for expanding this section beyond just simulation, are there other "verification" steps that a user might want to take before running on real hardware that we might want to highlight here?

[blakejohnson]

noisy (can you use noise models with primitives? Im not actually sure)

Yes, but to model the effect of various error mitigation techniques, you have to use the cloud simulators which we plan to sunset early in 2024. So, you can only locally simulate a primitive query without error mitigation.

It would be good to teach users to reason about the likelihood of success of a given circuit. i.e. maybe get them to extract the width and depth of their circuit, or extract the total number of cx gates. Even getting them to think about $p_{cx}^n$ where $p_{cx}$ is the average CX gate fidelity and $n$ is the number of gates would already be a start.

Eventually I would like to release tooling that counts layers in circuits in the same way we do within IBM's primitives, and then we can connect number of layers to the LEQ metric which will soon appear in the system cards.

[kevinsung]

Thanks for the comments. I'll split the pages if they get too large.

It would be good to teach users to reason about the likelihood of success of a given circuit. i.e. maybe get them to extract the width and depth of their circuit, or extract the total number of cx gates. Even getting them to think about
where is the average CX gate fidelity and is the number of gates would already be a start.

Great suggestion, I'll incorporate it.

[javabster]

final page structure:

• intro #86
• exact simulation with qiskit primitives
• noisy simulation with qiskit aer (including likelihood of success analysis) #291
• custom noise models with qiskit aer
• extended stabiliser simulation with qiskit aer #108
• IBM Quantum cloud-based simulation
  • available simulators
  • using the simulators

[kevinsung]

I decided not to include extended stabilizer simulation with the normal stabilizer simulation: #322.

The extended stabilizer simulation is different enough that it warrants its own page if we want to write one. There is already a good existing article though: https://qiskit.org/ecosystem/aer/tutorials/6_extended_stabilizer_tutorial.html. It uses backend.run but can be easily updated to use the Sampler primitive (but not the Estimator primitive because the simulator does not support expectation values).