Backend configuration


The configuration of a backend contains the necessary information to run circuits on the target backend. This includes details on the physical (real system) or logical (simulator) setup of the backend, as well as configurable properties such as the maximum number of circuits that can be executed in a single job. The backend setup, along with the configuration details of control electronics (if any), can be used to assign a version number to a backend.

Backend configuration values

Here we describe a subset of backend configuration values available on IBM Quantum Experience, or from Qiskit.

  • name - The unique name assigned to a specific quantum system or simulator. Backends hosted on IBM®Cloud have names that begin with ibmq_*. All quantum systems are given a city name, e.g., ibmq_johannesburg. This name does not indicate where the actual quantum system is hosted. These are actually named after IBM locations around the world.

  • version - The version number of a backend in the form major.minor.revision. See backend versioning for details on how this number is assigned.

  • n_qubits - The number of qubits in a backend. For real quantum systems, this is the number of physical qubits in the device. For simulators, this number need not be uniquely defined, and instead can depend on the simulation method and/or the amount of memory available.

  • basis_gates - A list of gates that can be natively executed on a backend.

  • coupling_map - A nested list of integer values that indicate those pairs of qubits that support two-qubit gate operations between them. This is also called the device topology or connectivity. Simulators support all-to-all connectivity and will return None for this value. The coupling map is best viewed visually, with qubits represented as circles, and the supported two-qubit gate operations displayed as lines connecting the qubits.

  • max_experiments - The maximum number of quantum circuits that you can submit at one time.

  • max_shots - The maximum number of shots you can execute a single circuit on a backend. The number of shots taken determines the precision of the output probability distribution over repeated executions.


    Distance (in terms of Hellinger distance) for a Bell state run on the IBM Quantum Boeblingen system from the theoretical answer as a function of the number of shots taken. For each value of the shots, the experiment is repeated 100 times.

  • online_date - The date on which the backend first became available on IBM Quantum Experience.

  • local - A flag indicating whether the backend is local to the user or remote.

  • simulator - A flag indicating if the backend is a classical simulator. simulator == False indicates a real quantum system.

  • open_pulse - A flag that determines whether a backend supports pulse inputs.

  • memory - Indicates that the backend supports returning raw counts data.

  • conditional - A flag that indicates that the backend supports execution of quantum gates that are conditioned on the value(s) of a classical register(s).

View backend configuration on IBM Quantum Experience

View backend configuration values in IBM Quantum Experience by selecting a system from the dashboard:


View backend configuration in Qiskit

In Qiskit, obtain the backend configuration information via:

from qiskit import IBMQ


provider = IBMQ.get_provider(group='open', project='main')
backend = provider.get_backend('ibmq_vigo')
<qiskit.providers.models.backendconfiguration.QasmBackendConfiguration at 0x7f112a6c69d0>

or graphically using:

import qiskit.providers.ibmq.jupyter

provider = IBMQ.get_provider(group='open', project='main')
backend = provider.get_backend('ibmq_vigo')

Back to the User Account and Services table of contents