# QPU Solvers¶

These solvers submit problems to and return results from the D-Wave QPU. This section lists the properties of these solvers, lists the parameters they accept with a problem submission, and describes the answer format.

For a quick reference listing all parameters and how they interact with each other, see the QPU Solver Parameters Matrix section.

## Properties¶

This section describes the properties of QPU solvers, in alphabetical order.

### anneal_offset_ranges¶

Array of ranges of valid anneal offset values, in normalized offset units, for each qubit. The negative values represent the largest number of normalized offset units by which a qubit’s anneal path may be delayed. The positive values represent the largest number of normalized offset units by which a qubit’s anneal path may be advanced.

Check these ranges before using the anneal_offsets parameter.

### anneal_offset_step¶

Quantization step size of anneal offset values in normalized units.

### anneal_offset_step_phi0¶

Quantization step size in physical units (annealing flux-bias units): \(\Phi_0\).

### annealing_time_range¶

Range of time, in microseconds, possible for one anneal (read). The lower limit in this range is the fastest quench possible for this solver. When adjusting the anneal schedule, using either the annealing_time or anneal_schedule parameter, ensure that you do not exceed the limits in this range.

### category¶

Type of solver; for example, `qpu`

.

### chip_id¶

Name of the solver.

### couplers¶

Couplers in the working graph. A coupler contains two elements [*q1*, *q2*], where both *q1* and *q2* appear in the
list of working qubits, in the range [0, *num_qubits* - 1] and in ascending order (i.e., *q1* < *q2*). These are the
couplers that can be programmed with nonzero \(J\) values; for example, `[[0, 4], [1, 4], [2, 4], ...]`

### default_annealing_time¶

Default time, in microseconds, for one anneal (read). You can change the annealing time for a given problem by using the annealing_time or anneal_schedule parameters, but do not exceed the upper limit given by the annealing_time_range property.

### default_programming_thermalization¶

Default time, in microseconds, that the system waits after programming the QPU for it to
return to base temperature. This value contributes to the total *qpu_programming_time*, which
is returned by SAPI with the problem solutions.

You can change this value using the programming_thermalization parameter, but be aware that values lower than the default accelerate solving at the expense of solution quality.

### default_readout_thermalization¶

Default time, in microseconds, that the system waits after each state is read from the QPU for it
to cool back to base temperature. This value contributes to the *qpu_delay_time_per_sample* field,
which is returned by SAPI with the problem solutions.

### extended_j_range¶

Extended range of values possible for the coupling strengths (quadratic coefficients), \(J\), for this solver. Strong negative couplings may be necessary for some embeddings; however, such chains may require additional calibration through the flux_biases parameter to compensate for biases introduced by strong negative couplings. See also per_qubit_coupling_range.

Note

Flux-bias offsets and extended \(J\) ranges cannot be used with autoscaling or spin-reversal transforms.

### h_gain_schedule_range¶

Range of the time-dependent gain applied to qubit biases for this solver. When setting this gain, using the h_gain_schedule parameter, ensure that you do not exceed the limits in this range.

### h_range¶

Range of values possible for the qubit biases (linear coefficients), \(h\), for this solver.

The auto_scale parameter, which rescales \(h\) and \(J\) values in the problem to use as much of the range of \(h\) (h_range) and the range of \(J\) (j_range) as possible, enables you to submit problems with values outside these ranges and have the system automatically scale them to fit.

### j_range¶

Range of values possible for the coupling strengths (quadratic coefficients), \(J\), for this solver.

The auto_scale parameter, which rescales \(h\) and \(J\) values in the problem to use as much of the range of \(h\) (h_range) and the range of \(J\) (j_range) as possible, enables you to submit problems with values outside these ranges and have the system automatically scale them to fit.

See also extended_j_range.

### max_anneal_schedule_points¶

Maximum number of points permitted in a PWL waveform submitted to change the default anneal schedule. Check this value before defining a new schedule with the anneal_schedule parameter.

For reverse annealing, the maximum number of points allowed is one more than the number given in the max_anneal_schedule_points property.

### max_h_gain_schedule_points¶

Maximum number of points permitted in a PWL waveform submitted to set a time-dependent gain on linear coefficients (qubit biases, see the h parameter) in the Hamiltonian. Check this value before using the h_gain_schedule parameter.

### num_qubits¶

Total number of qubits, both working and nonworking, in the QPU; for example, `2048`

.

### num_reads_range¶

Range of values possible for the number of reads that you can request for a problem; for example, `[1, 1000]`

.

### parameters¶

List of the parameters supported for the solver.

### per_qubit_coupling_range¶

Coupling range permitted per qubit for this solver. Check this property when using an extended \(J\) range to strongly couple qubits in a chain. Strong negative couplings may be necessary for some embeddings; however, chains may require additional calibration through the flux_biases parameter to compensate for biases introduced by strong negative couplings. See also extended_j_range.

Note

Flux-bias offsets and extended \(J\) ranges cannot be used with autoscaling or spin-reversal transforms.

### problem_run_duration_range¶

Range of time, in microseconds, that a submitted problem is allowed to run.

The run-duration for a given problem, which is compared with this range, is calculated according to the following formula:

where \(P_1\), \(P_2\), \(P_3\), and \(P_4\) are the values specified for the annealing_time (or anneal_schedule), readout_thermalization, num_reads (samples), and programming_thermalization parameters, respectively.

Note

This is not the actual QPU access time of a given problem as that includes
programming time and readout time.
For more information, see *Solver Computation Time*.

### programming_thermalization_range¶

Range of time, in microseconds, possible for the system to wait after programming the QPU for it to cool back to base temperature
This value contributes to the total *qpu_programming_time*, which is returned by SAPI with the problem solutions.

You can change this value using the programming_thermalization parameter, but be aware that values lower than the default accelerate solving at the expense of solution quality. The default value for a solver is given in the default_programming_thermalization property.

### qubits¶

Indices of the working qubits in the working graph.
For example, `[0, 1, 2, 3, ...]`

Note

In a D-Wave QPU, the set of qubits and couplers that are available for computation is
known as the *working graph*. The yield of a working graph is typically less than the total
number of qubits and couplers that are fabricated and physically present in the QPU.

### quota_conversion_rate¶

Rate at which user or project quota is consumed for the solver. Time is deducted from your quota according to:

If your quota_conversion_rate is `1`

, for example, then the rate of quota consumption is straightforward:
1 second used on a solver deducts 1 second from your quota.

Different solver types may consume quota at different rates.

### readout_thermalization_range¶

Range of time, in microseconds, possible for the system to wait after each state is read from
the QPU for it to cool back to base temperature. This value contributes to the
*qpu_delay_time_per_sample* field, which is returned by SAPI with the problem solutions.

### supported_problem_types¶

Indicates what problem types are supported for the solver. QPU and QPU-like solvers support the following energy-minimization problem types:

`qubo`

—Quadratic unconstrained binary optimization (QUBO) problems; use \(0/1\)-valued variables.`ising`

—Ising model problems; use \(-1/1\)-valued variables.

### tags¶

May hold attributes about a solver that you can use to have a client program choose one solver over another.

For example, the following attribute identifies a solver as lower-noise:

```
"tags": ["lower_noise"]
```

### topology¶

Indicates the topology `type`

(`chimera`

or `pegasus`

) and `shape`

of the QPU graph. For example, the
following topology is a C16 Chimera graph, meaning that the QPU has 16 x 16 blocks of Chimera unit cells,
and each unit cell has K4,4 connectivity:

```
{"type": "chimera", "shape": [16, 16, 4]}
```

### vfyc¶

Flag indicating whether this solver is a VFYC solver.

## Parameters¶

This section describes the parameters accepted by QPU solvers, in alphabetical order. See QPU Solver Parameters Matrix for a summary.

### anneal_offsets¶

Provides offsets to annealing paths, per qubit.

When using the Ocean tools, supply the values as a list or a tuple.

### anneal_schedule¶

Introduces variations to the global anneal schedule. For a reverse anneal, use the anneal_schedule parameter with the initial_state and reinitialize_state parameters.

An anneal schedule variation is defined by a series of pairs of floating-point numbers identifying points in the schedule at which to change slope. The first element in the pair is time \(t\) in microseconds; the second, normalized persistent current \(s\) in the range [0,1]. The resulting schedule is the piecewise-linear curve that connects the provided points.

The following rules apply to the set of anneal schedule points provided:

Time \(t\) must increase for all points in the schedule.

For forward annealing, the first point must be \((0, 0)\).

For reverse annealing, the anneal fraction \(s\) must start and end at \(s = 1\).

In the final point, anneal fraction \(s\) must equal 1 and time \(t\) must not exceed the maximum value in the

*annealing_time_range*property.- The number of points must be \(\geq 2\).The upper bound is system-dependent; check the
*max_anneal_schedule_points*property. For reverse annealing, the maximum number of points allowed is one*more*than the number given by this property. Additional rules that govern maximum slope vary by product; check the QPU properties document for your system.

The max_anneal_schedule_points property shows the maximum number of points permitted in an anneal schedule, and default_annealing_time shows the annealing time range for the solver.

When using the Ocean tools,
provide the schedule as a list or tuple of two-element lists or tuples; for example: `[[0.0, 0.0], [10.0, 0.3], [20.0, 1.0]]`

Note

The annealing_time and anneal_schedule parameters are mutually exclusive.

Note

Spin-reversal transforms are incompatible with reverse annealing.

### annealing_time¶

Sets the duration (in microseconds) of quantum annealing time, per read. This value populates
the *qpu_anneal_time_per_sample* field returned in the *timing* structure.

Must be a positive integer falling within the range given by the annealing_time_range solver property.

Note

The annealing_time and anneal_schedule parameters are mutually exclusive.

### answer_mode¶

Indicates how to return answers from the solver; one of:

`histogram`

(default)—Answers returned as a histogram sorted in order of increasing energies. Duplicate answers are merged and include a*num_occurrences*field.`raw`

—Answers returned individually in the order they were read from the solver. Use this setting if the returned time sequences are an important part of the solution data.

See also the Answer Format section below.

### auto_scale¶

Indicates whether \(h\) and \(J\) values are rescaled:

`true`

—\(h\) and \(J\) values in the problem are rescaled to use as much of the range of \(h\) (h_range) and the range of \(J\) (j_range) as possible. When enabled, \(h\) and \(J\) values need not lie within the solver’s range of \(h\) and \(J\), but must still be finite.`false`

—\(h\) and \(J\) values in the problem are used as is. If the \(h\) and \(J\) values are outside the range of the solver, problem submission fails.

For problems that use the regular \(J\) range of a solver, this parameter is enabled by default. For problems that use the extended \(J\) range, it is disabled (and cannot be enabled while the extended range is in use). See also j_range and extended_j_range.

Note

Flux-bias offsets and extended \(J\) ranges cannot be used with autoscaling or spin-reversal transforms.

Auto-scaling works as follows. Each QPU has an allowed range of values for the biases and strengths of qubits and couplers. Unless you explicitly disable auto-scaling, the values defined in your problem are adjusted to fit the entire available range, by dividing them by a positive (non-zero) factor defined as:

The example below uses Ocean software to check a QPU’s range of \(h\) and \(J\) before submitting a two-variable Ising problem to a QPU. In this example, DWaveSampler implicitly sets auto_scale to True, so the \(h\) and \(J\) values are automatically rescaled by \(\frac{-3.6}{-2}=1.8\).

```
>>> from dwave.system import DWaveSampler, EmbeddingComposite
>>> sampler = EmbeddingComposite(DWaveSampler(solver={'qpu': True}))
...
>>> sampler.sampler.child.properties['j_range']
[-1.0, 1.0]
>>> sampler.sampler.child.properties['h_range']
[-2.0, 2.0]
...
>>> h = {'a': -3.6, 'b': 2.3}
>>> J = {('a', 'b'): 1.5}
>>> sampleset = sampler.sample_ising(h, J)
```

Problems specified in QUBO form are always converted to Ising for the submitted QMIs. When using auto-scaling, the converted problem’s \(h\) and \(J\) values are rescaled as described above. Note that bias values in the converted form, which have a dependency on the number of quadratic interactions in the QUBO, can be larger than the maximum bias of the original form. For example, the four-variable QUBO below, which has a maximum bias value of 2,

when converted to an Ising model, has a bias with a value greater than 2.0, \(h_1=2.375\), as shown below:

```
>>> import dimod
>>> Q = {(1, 1): 2, (2, 2): 1.5, (3, 3): -0.5, (4, 4): -1.0,
... (1, 2): 2, (1, 3): 1.5, (1, 4): 2}
>>> dimod.qubo_to_ising(Q)
({1: 2.375, 2: 1.25, 3: 0.125, 4: 0.0},
{(1, 2): 0.5, (1, 3): 0.375, (1, 4): 0.5},
2.375)
```

Ocean software’s samplers often have a *chain strength* parameter: because the QPU’s
qubits are sparsely connected, problem variables might be represented by more than
one physical qubit (a “chain” of qubits), strongly coupled so as to return the same
value. Typically, chains are generated by minor-embedding tools such as Ocean’s
*minorminer*. Setting a value for chain strength determines the values set for the
couplers used in forming these chains. When using auto-scaling, the \(J\) values
of chain couplers are scaled together with the given or converted \(J\) values.
Similarly, if you disable auto-scaling, any chain strength you specify must result in
coupling values within the allowed range for the QPU.

### beta¶

Provides a value for the Boltzmann distribution parameter. Used when sampling postprocessing is enabled on D-Wave 2000Q and earlier systems.

Note

As in statistical mechanics, \(\beta\) represents inverse temperature: \(1/(k_B T)\), where \(T\)
is the thermodynamic temperature in kelvin and \(k_B\) is Boltzmann’s constant. In the D-Wave software,
postprocessing refines the returned solutions to target a Boltzmann distribution characterized by \(\beta\), which
is represented by a floating point number without units. When choosing a value for \(\beta\), be aware that lower
values result in samples less constrained to the lowest energy states. For more information on \(\beta\) and how it
is used in the sampling postprocessing algorithm, see *Postprocessing Methods on D-Wave Systems*.

### chains¶

Defines which qubits represent the same logical variable. Used only when postprocessing is enabled on D-Wave 2000Q and earlier systems. Ensures that all qubits in the same chain have the same value within each sample.

Provide the indices of the qubits that are in a chain. Qubits in a chain must be connected, and no qubit may appear more than once.

When using the Ocean tools, provide the qubit
indices as a list of lists.
The inner lists are the indices of the qubits in the same chain; for
example, `[4, 12, 20, 28, 36, 44]`

.
An example with two parallel horizontal 4-qubit chains
is `[[4, 12, 20, 28], [5, 13, 21, 29]]`

.

### flux_biases¶

List of flux-bias offset values with which to calibrate a chain. Often required when using the extended \(J\) range to create a strongly coupled chain for certain embeddings. See also the extended_j_range and per_qubit_coupling_range properties.

Provide an array of flux-bias offset values, in normalized offset units[1], for all qubits, working or not. Use 0 for no offset.
Before using this parameter, query the solver properties to determine whether *extended_J_range* and *per_qubit_coupling_range* properties exist.

When using the Ocean tools, supply the values as a list or a tuple.

Note

[1] | Flux-biases applied to the qubit body are in units of \(\Phi_0\). |

### flux_drift_compensation¶

Boolean flag indicating whether the D-Wave system compensates for flux drift.
The procedure it follows to do so is described in detail in Appendix A
of *Postprocessing Methods on D-Wave Systems*.

`flux_drift_compensation=true`

(default)—Compensate for flux drift.`flux_drift_compensation=false`

—Do not compensate for flux drift. If you disable this parameter, you may want to apply flux-bias offsets manually; see flux_biases.

### h_gain_schedule¶

Sets a time-dependent gain for linear coefficients (qubit biases, see the h parameter) in the Hamiltonian. This parameter enables you to specify the \(g(t)\) function in,

where \({\hat\sigma_{x,z}^{(i)}}\) are Pauli matrices operating on a qubit \(q_i\) and \(h_i\) and \(J_{i,j}\) are the qubit biases and coupling strengths.

This time-dependent gain, \(g(t)\), is specified, similarly to the anneal_schedule parameter, by a series of pairs of floating-point numbers identifying points in the schedule at which to change the gain applied to h. The first element in the pair is time, \(t\) in microseconds; the second, the unitless \(g\) in the range h_gain_schedule_range. The resulting time-dependent gain is the piecewise-linear curve that connects the provided points over the same range of times as the anneal_schedule.

The following rules apply to the set of gain points provided:

Time \(t\), in microseconds, must increase for all points in the schedule.

The first point of time must be zero, \(t=0.0\).

The last point of time must match the last time in the anneal_schedule.

- The number of points must be \(\geq 2\).The upper bound is system-dependent; check the max_anneal_schedule_points property.
Additional rules that govern maximum slope (i.e., how quickly \(g(t)\) can change) vary by product; check the QPU properties document for your system.

The range of gain values permitted is a property of the solver; check the h_gain_schedule_range for your solver.

The max_anneal_schedule_points property shows the maximum number of points permitted in an anneal schedule, max_h_gain_schedule_points the maximum number of gain changes allowed, and h_gain_schedule_range shows the minimum and maximum supported gain values for the solver.

When left unspecified, \(g(t)\) defaults to 1, which can be explicitly coded as

```
h_gain_schedule=[[0,1],[t_final,1]]
```

where t_final is the requested annealing time.

When using the Ocean tools,
provide the schedule as a list or tuple of two-element lists or tuples; for example: `[[0.0, 0.0], [10.0, 0.25], [20.0, 0.4]]`

### initial_state¶

When using the reverse annealing feature, you must supply the initial state to which the system is set. When you include this parameter with the anneal_schedule parameter, this indicates that the requested anneal schedule change is also a reverse anneal.

The initial_state parameter specifies the initial classical state of all qubits.
Provide (*qubit*, *state*) pairs, where *qubit* is the qubit index, *i*, and *state* is:

- -1 or 1—Ising problems, active qubits
- 0 or 1—QUBO problems, active qubits
- 3—Unused or inactive qubits

When using the Ocean tools, provide the dense set of (*qubit*, *state*) pairs as a list or tuple.

You have the option to reassert this state for each anneal, although this impacts timing; see also reinitialize_state.

Note

Spin-reversal transforms are incompatible with reverse annealing.

### max_answers¶

Specifies the maximum number of answers returned from the solver:

- If answer_mode is
`histogram`

—Total number of distinct answers. - If answer_mode is
`raw`

—Limits the returned values to the first max_answers of num_reads samples. In this mode, max_answers should never be more than num_reads.

Must be an integer > 0; default is num_reads.

### num_reads¶

Indicates the number of states (output solutions) to read[2] from the solver. Must be a positive integer; default is `1`

.

[2] | Terms synonymous to reads are anneals and samples. |

### num_spin_reversal_transforms¶

Specifies the number of spin-reversal transforms[3] to perform.

[3] | Also known as gauge transformations. |

Applying a spin-reversal transform can improve results by reducing the impact of analog errors that may exist on the QPU. This technique works as follows: Given an \(n\)-variable Ising problem, we can select a random \(g\in\{\pm1\}^n\) and transform the problem via \(h_i\mapsto h_ig_i\) and \(J_{ij}\mapsto J_{ij}g_ig_j\). A spin-reversal transform does not alter the mathematical nature of the Ising problem. Solutions \(s\) of the original problem and \(s^\prime\) of the transformed problem are related by \(s^\prime_i=s_ig_i\) and have identical energies. However, the sample statistics can be affected by the spin-reversal transform because the QPU is a physical object with asymmetries.

Spin-reversal transforms work correctly with postprocessing and chains. Majority voting happens on the original problem state, not on the transformed state.

Be aware that each transform reprograms the QPU; therefore, using more than 1 transform will increase the amount of time required to solve the problem.
For more information about timing, see *Solver Computation Time*.

Note

Flux-bias offsets and extended \(J\) ranges cannot be used with autoscaling or spin-reversal transforms. Furthermore, spin-reversal transforms are incompatible with reverse annealing.

### postprocess¶

Postprocessing optimization and sampling algorithms provide local improvements with minimal overhead to solutions obtained from the quantum processing unit (QPU).

Ocean software provides postprocessing tools, and you can optionally run postprocessing online on D-Wave 2000Q and earlier systems.

Defines what type of postprocessing the system runs online on raw solutions:

- “” (empty string)—No postprocessing (default). Note that if this option is selected for the VFYC solver, sampling postprocessing runs.
`sampling`

—Runs a short Markov-chain Monte Carlo (MCMC) algorithm with single bit-flips starting from each sample. The target probability distribution is a Boltzmann distribution at inverse temperature \(\beta\).`optimization`

—Performs a local search on each sample, stopping at a local minimum.

Note

When postprocessing is enabled, qubits in the same chain, defined by the chains
parameter, are first set to the same value by majority vote. Postprocessing is performed
on the logical problem but qubit-level answers are returned. For more information
about postprocessing, see *Postprocessing Methods on D-Wave Systems*.

Note

Ocean software provides postprocessing tools; use these for Advantage systems.

### programming_thermalization¶

Gives the time (in microseconds) to wait after programming the QPU for it to cool back to base temperature
(i.e., post-programming thermalization time). Lower values accelerate solving at the expense of solution quality.
Must be an integer. This value contributes to the total *qpu_programming_time*, which is returned by SAPI with the problem solutions.

The default value for a solver is given in the default_programming_thermalization property; the range of possible values is given in the programming_thermalization_range property.

#### Problem Conversion¶

Conversion between QUBO and Ising problem formulations is as follows:

To convert the coefficients from QUBO to Ising:

or from Ising to QUBO:

For example, this two-qubit problem in QUBO format,

```
Q = (0,5): -10,
```

is as follows in Ising format:

```
h = [-2.5, 0, 0, 0, 0, -2.5], J = {(0, 5): -2.5}.
```

The energies for the corresponding solutions have the constant difference of

### readout_thermalization¶

Gives the time (in microseconds) to wait after each state is read from the QPU for it to cool back to base temperature
(i.e., post-readout thermalization time). This value contributes to the *qpu_delay_time_per_sample* field,
which is returned with the problem solutions. Must be an integer.

### reduce_intersample_correlation¶

Reduces sample-to-sample correlations caused by the spin-bath polarization effect[4] by adding a delay between reads.

[4] | See the Technical Description of the D-Wave Quantum Processing Unit for more information on this effect. |

Boolean flag indicating whether the system adds a delay.

`reduce_intersample_correlation=true`

—Adds delay.`reduce_intersample_correlation=false`

(default)—Does not add delay.

Important

Enabling this parameter drastically increases problem run times. To avoid exceeding the maximum
problem run time configured for your system, limit the number of reads when using this feature.
For more information on timing, see *Solver Computation Time*.

### reinitialize_state¶

When using the reverse annealing feature, you must supply the initial state to which the system is set; see the initial_state parameter. If multiple reads are requested in a single call to the Solver API, you have two options for the starting state of the system. These are controlled by the reinitialize_state Boolean parameter:

`reinitialize_state=true`

(default)—Reinitialize to the specified initial state for every anneal-readout cycle. Each anneal begins from the state given in the initial_state parameter. The amount of time required to reinitialize varies by system; typical D-Wave 2000Q systems require between 100 and 600 microseconds for this operation.`reinitialize_state=false`

—Initialize only at the beginning, before the first anneal cycle. Each anneal (after the first) is initialized from the final state of the qubits after the previous cycle. Be aware that even if this parameter is disabled, reverse annealing adds a small amount of time (\(\approx 10 \ \mu s\)) for each read.

See also anneal_schedule.

## Answer Format¶

The format of answers returned by QPU solvers depends on the setting of the *answer_mode* parameter:

- If
`raw`

—The answer contains two fields,*solutions*and*energies*. The*solutions*field is a list of lists; the inner lists all have length num_qubits and entries from \({-1, +1}\) for Ising problems or \({0, 1}\) for QUBO problems. Values of \(3\) denote used or inactive qubits. The*energies*field contains the energy of each corresponding solution. - If
`histogram`

—The answer still contains the*solutions*and*energies*fields, but in this case the solutions are unique and sorted in increasing-energy order. An additional field,*num_occurrences*, indicates how many times each solution appeared.