Framework for realistic experimental backends

[Matt-RFI]

What should we add?

There are different versions of Backend objects that exist in Qiskit Terra, such as FakeBackend which inherits from BackendV2. Additionally, there are other simulator-based backends like the QASM simulator and the statevector simulator. Ultimately, the results from these simulators are not as practical and true-to-hardware as the results from existing IBM Quantum backends. A potential solution to this problem is to create a realistic experimental backend generator that takes information from IBM Quantum backends, samples from this data, and replicates the backend’s performance. The information of the backend will be stored in a BackendSpec object that the user can utilize to generate new backends. The following is a more detailed look at this potential solution:

There are two ways a user can construct a BackendSpec object:

1. The user inputs an existing backend
2. The user constructs a backend with custom specifications

In both cases the BackendSpec class creates/samples from the information inputted by the user, and the class also contains modifier functions which can change certain parts of a backend spec, including the number of qubits, coupling map, and error rates. The class then samples from these values and feeds them into the RealisticBackend class, which returns a BackendV2 object. Some example code from the API is shown below:

parent_backend = provider.get_backend('example backend')
backend_spec = BackendSpec(parent_backend)

backend_spec.set_qubit_property(0, 'T1', 0.73)
backend_spec.set_qubit_property(1, 'error_rate', 0.43)

new_backend = backend_spec.normal_distribution()
qc = QuantumCircuit(18)
qc.h(0)
qc.measure_all()
job = execute(qc, backend=new_backend, shots=4000)

[jakelishman]

The backends in qiskit.providers.fake_provider literally use calibration data from their equivalent qiskit-ibm-provider backends, although we admittedly don't really update that once we've made it once.

What you describe is, I think, both the domain of Qiskit Aer, but also already implemented there. You can use NoiseModel.from_backend to get the object with up-to-date calibrations from whatever backend you like, then execute on AerSimulator (which is all the fake backends do anyway), using that noise model.

Fwiw, execute is not a preferred way to run a circuit on a backend - it's a fast-path only. You get access to the full range of options by doing

from qiskit import transpile
qc = ...
backend = ...
transpiled = transpile(qc, backend, <transpile options>)
job = backend.run(transpiled, <backend-specific run options>)

[Matt-RFI]

To make some corrections and clarifications regarding this proposal, the purpose of the BackendSpec is to provide a framework for generating highly customized backends that can be used for testing on the transpiler. This is especially useful for Qiskit Terra as it allows for testing the transpiler on backend configurations that don’t exist at the moment. For example, the framework would allow for testing the transpiler on new hardware architectures (IBM or non-IBM) with different coupling schemes, qubit types, and qubit specific basis gates. Another case would be testing noise aware transpilation. BackendSpec would also address most problems discussed in the following issue: https://github.com/Qiskit/qiskit-terra/issues/9553. Specifically, the framework would allow fake backend construction in favor of IBM-derived fake backends. For example, if a user wants to generate a version of an existing backend with more qubits and lower error rates they can use the framework to do this efficiently. Additionally, a BackendSpec can be built with unique data from the user and generate new backends based on these custom specifications. I should also note that BackendSpec could potentially be used by the qiskit-ibm-provider package, or other vendor provider packages, to generate vendor specific backends. Overall, the addition of BackendSpec would make it easier to remove the need to maintain IBM specific fake backends while also providing a vendor agnostic tool for generating and testing a diverse set of backends.

[Matt-RFI]

didn't mean to close the issue.

[jakelishman]

In that case, I think that much of what you're describing is called Target in Qiskit, as it's the fundamental component that describes the properties of a backend. There's documentation on that page about how to construct one, and you can pass one to transpile using the target keyword argument, instead of passing a full backend.

[jakelishman]

Fwiw, all the extra helper methods that you might want to have to investigate the properties of various error distributions and whatnot would, I think, be a bit more suited to a separate package to provide them; they sound quite specific to one particular type of research. You could make that, if you like and it'd help your work, and you can contribute it to the Qiskit ecosystem.