RepeatedReverseSimulatedAnnealing¶
Repeated Reverse Simulated Annealing finds the solution to a problem using an annealing process. Initially, random states are chosen in the solution landscape. Afterwards, as the temperature decreases, states are chosen that are more energetically favorable. At the end of the complete annealing process, the resulting states make up the solution.
Note
This solver is only available for commercial and academic licenses.
Compatible Backends¶
The RepeatedReverseSimulatedAnnealing algorithm supports the following backends:
By default, RepeatedReverseSimulatedAnnealing uses the DWave backend.
Initialization¶
The following section outlines the default configurations of RepeatedReverseSimulatedAnnealing. You can also specify other compatible backends for the algorithm. When backend=None is specified, the default backend will be initialized automatically. In this case, if the backend requires a token, it will be taken from the environment variables.
from luna_quantum.solve.parameters.algorithms import RepeatedReverseSimulatedAnnealing
algorithm = RepeatedReverseSimulatedAnnealing(
backend=None,
num_reads=None,
num_sweeps=1000,
beta_range=None,
beta_schedule_type='geometric',
initial_states_generator='random',
num_sweeps_per_beta=1,
seed=None,
beta_schedule=None,
initial_states=None,
randomize_order=False,
proposal_acceptance_criteria='Metropolis',
num_reads_per_iter=None,
timeout=5.0,
max_iter=10,
target=None
)
Parameter Details
For a complete overview of available parameters and their usage, see the RepeatedReverseSimulatedAnnealing API Reference.
Usage¶
from luna_quantum import LunaSolve
LunaSolve.authenticate("<YOUR_LUNA_API_KEY>")
# Define your model and algorithm
model = ...
algorithm = ...
solve_job = algorithm.run(model, name="my-solve-job")
API Reference¶
Bases: SimulatedAnnealingParams, LunaAlgorithm[DWave]
Parameters for the Repeated Reverse Simulated Annealing solver.
This algorithm applies principles similar to quantum reverse annealing but in a classical context. It starts from specified states, partially "reverses" the annealing by increasing temperature to explore nearby states, then re-anneals to find improved solutions. This process repeats for multiple iterations, refining solutions progressively.
The approach is particularly effective for problems with complex energy landscapes where standard simulated annealing might get trapped in local optima.
Attributes:
| Name | Type | Description |
|---|---|---|
num_reads_per_iter |
list[int] | None
|
Number of reads (independent runs) to perform in each iteration. Uses num_reads_per_iter[i] in iteration i, and num_reads_per_iter[-1] once the list is exhausted. If None, uses the num_reads value inherited from SimulatedAnnealingParams. This allows dynamic control of sampling intensity across iterations, typically starting with broader exploration and focusing on refinement in later iterations. Minimum list length: 1. Default is None. |
initial_states |
Any | None
|
Starting states for the first iteration. Each state defines values for all problem variables and serves as a starting point for the reverse annealing process. If fewer states than reads are provided, additional states are generated according to the initial_states_generator setting inherited from SimulatedAnnealingParams. Providing good initial states (e.g., from classical heuristics) can significantly improve solution quality. Default is None, which generates random initial states. |
timeout |
float
|
Maximum runtime in seconds before termination, regardless of other stopping criteria. Provides a hard time limit for time-constrained applications. Default is 5.0 seconds, which is suitable for small to medium-sized problems. For larger or more complex problems, consider increasing this value. |
max_iter |
int
|
Maximum number of reverse annealing iterations to perform. Each iteration involves: starting from the best states found so far, raising temperature to explore nearby configurations, then gradually cooling to refine solutions. More iterations generally improve solution quality but increase runtime. Default is 10, providing a good balance for most problems. |
target |
Any | None
|
Target energy value that triggers early termination if reached. Allows the algorithm to stop when a solution of sufficient quality is found, even before reaching max_iter or timeout. Default is None, which means the algorithm will run until other stopping criteria are met. |
num_sweeps_per_beta |
int
|
Number of sweeps to perform at each temperature before cooling. More sweeps per temperature allow better exploration at each temperature level. Default is 1, which works well for many problems. |
seed |
Optional[int]
|
Random seed for reproducible results. Using the same seed with identical parameters produces identical results. Default is None (random seed). |
beta_schedule |
Sequence[float] | None
|
Explicit sequence of beta (inverse temperature) values to use. Provides complete control over the cooling schedule. Format must be compatible with numpy.array. Default is None, which generates a schedule based on beta_range and beta_schedule_type. |
initial_states |
Optional[Any]
|
One or more starting states, each defining values for all problem variables. This allows the algorithm to start from promising regions rather than random points. Default is None (random starting states). |
randomize_order |
bool
|
When True, variables are updated in random order during each sweep. When False, variables are updated sequentially. Random updates preserve symmetry of the model but are slightly slower. Default is False for efficiency. |
proposal_acceptance_criteria |
Literal['Gibbs', 'Metropolis']
|
Method for accepting or rejecting proposed moves: - "Gibbs": Samples directly from conditional probability distribution - "Metropolis": Uses Metropolis-Hastings rule (accept if improving, otherwise accept with probability based on energy difference and temperature) Default is "Metropolis", which is typically faster and works well for most problems. |
num_reads |
Union[int, None]
|
Number of independent runs of the algorithm, each producing one solution sample. Multiple reads with different random starting points increase the chance of finding the global optimum. Default is None, which matches the number of initial states (or just one read if no initial states are provided). |
num_sweeps |
Union[int, None]
|
Number of iterations/sweeps per run, where each sweep updates all variables once. More sweeps allow more thorough exploration but increase runtime. Default is 1,000, suitable for small to medium problems. |
beta_range |
Union[List[float], Tuple[float, float], None]
|
The inverse temperature (β=1/T) schedule endpoints, specified as [start, end]. A wider range allows more exploration. Default is calculated based on the problem's energy scale to ensure appropriate acceptance probabilities. |
beta_schedule_type |
Literal['linear', 'geometric']
|
How beta values change between endpoints: - "linear": Equal steps (β₁, β₂, ...) - smoother transitions - "geometric": Multiplicative steps (β₁, r·β₁, r²·β₁, ...) - spends more time at lower temperatures for fine-tuning Default is "geometric", which often performs better for optimization problems. |
initial_states_generator |
Literal['none', 'tile', 'random']
|
How to handle cases with fewer initial states than num_reads: - "none": Raises error if insufficient initial states - "tile": Reuses provided states by cycling through them - "random": Generates additional random states as needed Default is "random", which maximizes exploration. |
backend
class-attribute
instance-attribute
¶
beta_range
class-attribute
instance-attribute
¶
beta_schedule_type
class-attribute
instance-attribute
¶
initial_states_generator
class-attribute
instance-attribute
¶
model_config
class-attribute
instance-attribute
¶
num_reads_per_iter
class-attribute
instance-attribute
¶
proposal_acceptance_criteria
class-attribute
instance-attribute
¶
get_compatible_backends
classmethod
¶
get_compatible_backends() -> tuple[type[DWave], ...]
Check at runtime if the used backend is compatible with the solver.
Returns:
| Type | Description |
|---|---|
tuple[type[IBackend], ...]
|
True if the backend is compatible with the solver, False otherwise. |
get_default_backend
classmethod
¶
get_default_backend() -> DWave
Return the default backend implementation.
This property must be implemented by subclasses to provide the default backend instance to use when no specific backend is specified.
Returns:
| Type | Description |
|---|---|
IBackend
|
An instance of a class implementing the IBackend interface that serves as the default backend. |
run ¶
run(
model: Model | str,
name: str | None = None,
backend: BACKEND_TYPE | None = None,
client: LunaSolve | str | None = None,
*args: Any,
**kwargs: Any,
) -> SolveJob
Run the configured solver.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
model
|
Model or str
|
The model to be optimized or solved. It could be an Model instance or a string identifier representing the model id. |
required |
name
|
str | None
|
If provided, the name of the job. Defaults to None. |
None
|
backend
|
BACKEND_TYPE | None
|
Backend to use for the solver. If not provided, the default backend is used. |
None
|
client
|
LunaSolve or str
|
The client interface used to interact with the backend services. If not provided, a default client will be used. |
None
|
*args
|
Any
|
Additional arguments that will be passed to the solver or client. |
()
|
**kwargs
|
Any
|
Additional keyword parameters for configuration or customization. |
{}
|
Returns:
| Type | Description |
|---|---|
SolveJob
|
The job object containing the information about the solve process. |