# Using Leap’s Hybrid Solvers¶

Introduces Leap‘s quantum-classical hybrid solvers and provides references to usage information.

Note

## Leap’s Hybrid Solvers¶

Leap’s quantum-classical hybrid solvers are intended to solve arbitrary application problems formulated as quadratic models1.

1

Problems submitted directly to quantum computers are in the binary quadratic model (BQM) format, unconstrained with binary-valued variables and structured for the topology of the quantum processing unit (QPU). Hybrid solvers may accept arbitrarily structured quadratic models (QM), constrained or unconstrained, with real, integer, and binary variables.

These solvers, which implement state-of-the-art classical algorithms together with intelligent allocation of the quantum computer to parts of the problem where it benefits most, are designed to accommodate even very large problems. Leap’s hybrid solvers enable you to benefit from D-Wave’s deep investment in researching, developing, optimizing, and maintaining hybrid algorithms.

The generally available hybrid solvers depend on your Leap™ account. Check your Leap dashboard to see which hybrid solvers are available to you.

Generally-available hybrid solvers currently supported in Leap include:

• Hybrid BQM solver (e.g., hybrid_binary_quadratic_model_version2)

Binary quadratic models (BQM) typically represent problems of decisions that could either be true (or yes) or false (no); for example, should an antenna transmit, or did a network node fail?

These solvers accept arbitrarily structured, unconstrained problems formulated as BQMs, with any constraints typically represented through penalty models.

• Hybrid CQM solver (e.g., hybrid_constrained_quadratic_model_version1)

Constrained quadratic models (CQM) typically represent problems that might include real, integer and/or binary variables and one or more constraints.

These solvers accept arbitrarily structured problems formulated as CQMs, with any constraints represented natively.

• Hybrid DQM solver (e.g., hybrid_discrete_quadratic_model_version1)

Discrete quadratic models (DQM) typically represent problems with several distinct options; for example, which shift should employee X work, or should the state on a map be colored red, blue, green, or yellow?

These solvers accept arbitrarily structured, unconstrained problems formulated as DQMs, with any constraints typically represented through penalty models.

### High-Throughput (“Bulk”) Solvers¶

In addition to the generally available (GA) versions of Leap’s hybrid solvers, some accounts may have access to versions of these solvers optimized for high throughput. These (sometimes called “bulk solvers”) can performantly process the submission of multiple problem in rapid succession, and may accept problems of larger size than their GA counterparts.

However, to handle high throughput, these solvers first instantiate the needed compute resources, which adds latency. The cost of this latency tends to be small compared to the overall solution time for multiple, large problems.

• Use GA solvers for single submissions of problems that do not exceed size limitations.

• Use high-throughput solvers when submitting multiple problems in a fast sequence or problems that exceed size limitations for the GA solvers.

The following example demonstrates the selection of a high-throughput CQM solver for use by an application that submits a sequence of problems and a standard BQM solver the user is experimenting with interactively.

>>> from dwave.system import LeapHybridBQMSampler, LeapHybridCQMSampler
...
>>> # Select a standard BQM solver
>>> bqm_solver_selection = LeapHybridBQMSampler.default_solver
>>> bqm_solver_selection.update(name__regex=".*(?<!bulk)$") >>> sampler_bqm = LeapHybridBQMSampler(solver=bqm_solver_selection) ... >>> # Select a high-throughput CQM solver >>> cqm_solver_selection = LeapHybridCQMSampler.default_solver >>> cqm_solver_selection.update(name__regex=".*bulk$")
>>> sampler_cqm = LeapHybridCQMSampler(solver=cqm_solver_selection)


For this user’s account selected2 solvers might be the following ones:

>>> sampler_cqm.solver.name
>>> sampler_bqm.solver.name

2

Solvers have default selection criteria; for example, hybrid BQM solvers might be required to support the BQM problem type and prioritize the latest available version. The code above adds a requirement to find or not find a match to “bulk” at the end of the solver’s name. For the user’s account of this example, the updated selection criteria might look like this:

>>> bqm_solver_selection
{'supported_problem_types__contains': 'bqm',
'order_by': '-properties.version',
'name__regex': '.*(?<!bulk)\$'}


Contact D-Wave at sales@dwavesys.com if your application requires scale or performance that exceeds the currently advertised capabilities of Leap’s generally available hybrid solvers.

## Solver Properties and Parameters¶

The Solver Properties and Parameters Reference guide details limitations on problem size, the range of time allowed for solving problems, etc and input arguments that enable you to configure execution.

## Solver Timing¶

The table below lists the timing information returned from Leap‘s quantum-classical hybrid solvers. Ocean users access to this information is from the info field in the dimod SampleSet class, as in the example below.

>>> import dimod
>>> from dwave.system import LeapHybridSampler
...
>>> sampler = LeapHybridSampler(solver={'category': 'hybrid'})
>>> bqm = dimod.generators.ran_r(1, 300)
>>> sampleset = sampler.sample(bqm)
>>> sampleset.info
{'qpu_access_time': 41990, 'charge_time': 2991424, 'run_time': 2991424}

Table 3 Timing Information from Leap’s Hybrid Solvers

Field

Meaning

run_time

Time, in microseconds, the hybrid solver spent working on the problem.

charge_time

Time, in microseconds, charged to the account. 3

qpu_access_time

QPU time, in microseconds, used by the hybrid solver. 4

3

charge_time and run_time may differ due to the time granularity of the solver. For example, if a hybrid solver has a time granularity of 0.5 sec and your submission specifies 4.7 sec, run_time might be 5 sec and charge_time 4.5 sec.

4

qpu_access_time might be zero for submissions with short run_time. Because the QPU is a shared, remote resource, the first set of samples from the QPU might not be received before a short explicitly-specified or default time_limit is reached. In such cases, the hybrid solver respects the time limitation and returns without the QPU having a chance to contribute to the solution. On the large, complex problems for which hybrid solvers are intended, this is unlikely to occur.

## Solver Usage Charges¶

D-Wave charges you for time that solvers run your problems, with rates depending on QPU usage. You can see the rate at which your account’s quota is consumed for a particular solver in the solver’s quota_conversion_rate property.

You can see the time you are charged for in the responses returned for your submitted problems. The relevant field in the response is 'charge_time'. The example in the Solver Timing section shows 'charge_time': 2991424 in the returned response, meaning almost 3 seconds are being charged.

For high-throughput solvers, as noted in the High-Throughput (“Bulk”) Solvers section above, instantiating the needed compute resources introduces a delay before problems are processed. The charge_time does not include this delay.

## Examples¶

Use a hybrid solver as you would any Ocean sampler. For example, given a 1000-variable problem formulated as a quadratic unconstrained binary optimization (QUBO) model, $Q$, you can submit it for solution to a hybrid BQM solver as follows:

from dwave.system import LeapHybridSampler

# Select a solver
sampler = LeapHybridSampler()

# Submit for solution