# 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 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.

### 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.

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:

$$Duration = ((P_1 + P_2) * P_3) + P_4$$

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:

$\frac{num\_seconds}{quota\_conversion\_rate}$

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.

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.

Provide an array of anneal offset values, in normalized offset units, for all qubits, working or not. Use 0 for no offset. Negative values produce a negative offset (qubits are annealed after the standard annealing trajectory); positive values produce a positive offset (qubits are annealed before the standard trajectory). Before using this parameter, query the solver properties to see whether the anneal_offset_ranges property exists and, if so, to obtain the permitted offset values 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.

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.

### 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:

$\max \left\{ \max \left( \frac{\max (h)}{\max (h\_range)}, 0 \right), \max \left( \frac{\min (h)}{\min(h\_range)}, 0 \right), \max \left( \frac{\max(J)}{\max(J\_range)}, 0 \right), \max \left( \frac{\min(J)}{\min(J\_range)}, 0 \right) \right\}$

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,

$\begin{split}\begin{bmatrix} 2 & 2 & 1.5 & 2 \\ 0 & 1.5 & 0 & 0 \\ 0 & 0 & -0.5 & 0 \\ 0 & 0 & 0 & -1.0 \end{bmatrix}\end{split}$

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

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

 [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,

$${\cal H}_{ising} = - \frac{A({s})}{2} \left(\sum_i {\hat\sigma_{x}^{(i)}}\right) + \frac{B({s})}{2} \left(g(t) \sum_{i} h_i {\hat\sigma_{z}^{(i)}} + \sum_{i>j} J_{i,j} {\hat\sigma_{z}^{(i)}} {\hat\sigma_{z}^{(j)}}\right)$$

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.

Specifies the maximum number of answers returned from the solver:

Must be an integer > 0; default is 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.
Use this parameter to specify how many spin-reversal transforms to perform on the problem. Valid values range from 0 (do not transform the problem; the default value) to a value equal to but no larger than the num-reads specified. If you specify a nonzero value, the system divides the number of reads by the number of spin-reversal transforms to determine how many reads to take for each transform. For example, if the number of reads is 10 and the number of transforms is 2, then 5 reads use the first transform and 5 use the second.

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

For problems that use online VFYC solvers, postprocessing always runs. By default, sampling postprocessing runs using a default $\beta$ value of $10$.

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:

$$s = q2 - 1.$$

To convert the coefficients from QUBO to Ising:

$$J_{i,j} = \frac{1}{4} \rm \textbf{Q}_{i,j},$$ $$h_i = \frac{1}{2} \textbf{Q}_{i,i} + \frac{1}{4} \sum_{i < j} \textbf{Q}_{i,j},$$

or from Ising to QUBO:

$$\textbf{Q}_{i,j} = 4J_{i,j}$$ $$\textbf{Q}_{i,i} = 2h_i - \frac{1}{2} \sum_{i < j} \textbf{Q}_{i,j}.$$

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

$$\frac{1}{2} \sum_i \textbf{Q}_{i,i} + \frac{1}{4} \sum_{i < j} \textbf{Q}_{i,j}.$$

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.

• 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.