# QPU-Like Solvers¶

This section describes the “QPU-like” solvers, including virtual full-yield chip (VFYC) solvers, optimizing emulators, and sampling emulators. These solvers have similar properties and accept similar parameters as the QPU solvers. Differences are described below.

Note

Not all accounts have access to these solvers.

## VFYC Solvers¶

A VFYC solver emulates a fully connected QPU working graph based on an idealized abstraction
of the system. Through this solver, variables corresponding to a Chimera-structured
or Pegasus-structured graph that are not representable on a
specific working graph are determined via hybrid use of the QPU and the integrated postprocessing system, which effectively
fills in any missing qubits and couplers that may affect the QPU. For more information on the VFYC solver and how it is
integrated with the postprocessing system, see *Postprocessing Methods on D-Wave Systems*.

The properties of a VFYC solver and the parameters it accepts are the same as for the QPU solvers described above, with the following differences:

- For problems that use the VFYC solver, postprocessing always runs. If you do not choose a postprocessing option, sampling postprocessing runs.
- When sampling postprocessing runs, the default \(\beta\) value is \(10\).

## Optimizing and Sampling Emulators¶

Software solvers are useful for prototyping optimization or sampling algorithms that make multiple calls to the hardware. Optimizing emulator solvers solve the same type of optimization problems as the QPU, but using a classical software algorithm. Sampling emulator solvers mimic the probabilistic nature of the QPU to draw samples that can be used to train a probabilistic model.

These solvers have names ending with the following strings:

`-sw_optimize`

`-sw_sample`

### Optimizing Emulators¶

This class of solvers is entirely deterministic, so the semantics of some
parameters are different. The number of solutions returned is always the
lesser of *max_answers* and *num_reads* \(\times\)
*num_programming_cycles*. The solutions returned are the lowest-energy states,
sorted in increasing-energy order.

These solvers accept the following parameters, described above:

The acceptable range and the default value of each field are given in the table below.

Field | Range | Default value |
---|---|---|

answer_mode | `histogram` or `raw` |
`histogram` |

max_answers | > 0 | num_reads |

num_reads | > 0 | 1 |

When *answer_mode* is `histogram`

, the *num_occurrences* field contains all
ones, except possibly for the lowest-energy solution. That first entry is
set so that the sum of all entries is *num_reads* \(\times\)
*num_programming_cycles*.

Note

The *num_programming_cycles* parameter is deprecated and will be removed
in a future release. Plan code updates accordingly.

### Sampling Emulators¶

This class of solvers mimic the probabilistic nature of the QPU, drawing samples from a Boltzmann distribution; that is, state s is sampled with probability proportional to:

where \(\beta\) is some parameter and \(E(s)\) is the energy of state \(s\).

These solvers accept the following parameters, described above:

In addition to this list, the sampling emulators accept an additional parameter: *random-seed*.
This parameter provides a random number generator seed. If provided, the solver solves the same problem with the same
parameters each read thereby producing the same results every time. If no value is provided, a time-based seed is selected,
and solutions will vary.

The acceptable range and the default value of each field are given in the following table.

Field | Range | Default value |
---|---|---|

answer_mode | `histogram` or `raw` |
`histogram` |

beta | Any finite value | 3.0 |

max_answers | > 0 | num_reads |

num_reads | > 0 | 1 |

random_seed | >= 0 | Randomly set |