Chapter 9. Local search

9.1. Overview

Local Search starts from an initial solution and evolves that single solution into a mostly better and better solution. It uses a single search path of solutions, not a search tree. At each solution in this path it evaluates a number of moves on the solution and applies the most suitable move to take the step to the next solution. It does that for a high number of iterations until it's terminated (usually because its time has run out).

Local Search acts a lot like a human planner: it uses a single search path and moves facts around to find a good feasible solution. Therefore it's pretty natural to implement.

Local Search often needs to start from an initialized solution, therefore it's often required to configure a construction heuristic solver phase before it.

9.2. Local Search concepts

9.2.1. Taking steps

A step is the winning Move. The local search solver tries every move on the current solution and picks the best accepted move as the step:

Figure 9.1. Decide the next step at step 0 (4 queens example)

Because the move B0 to B3 has the highest score (-3), it is picked as the next step. If multiple moves have the same highest score, one is picked randomly, in this case B0 to B3. Note that C0 to C3 (not shown) could also have been picked because it also has the score -3.

The step is applied on the solution. From that new solution, the local search solver tries every move again, to decide the next step after that. It continually does this in a loop, and we get something like this:

Figure 9.2. All steps (4 queens example)

Notice that the local search solver doesn't use a search tree, but a search path. The search path is highlighted by the green arrows. At each step it tries all possible moves, but unless it's the step, it doesn't investigate that solution further. This is one of the reasons why local search is very scalable.

As you can see, Local Search solves the 4 queens problem by starting with the starting solution and make the following steps sequentially:

B0 to B3
D0 to B2
A0 to B1

If we turn on debug logging for the category org.optaplanner, then those steps are shown into the log:

INFO  Solving started: time spend (0), score (-6), new best score (-6), random seed (0).
DEBUG     Step index (0), time spend (20), score (-3), new best score (-3), accepted/selected move count (12/12) for picked step (col1@row0 => row3).
DEBUG     Step index (1), time spend (31), score (-1), new best score (-1), accepted/selected move count (12/12) for picked step (col0@row0 => row1).
DEBUG     Step index (2), time spend (40), score (0), new best score (0), accepted/selected move count (12/12) for picked step (col3@row0 => row2).
INFO  Phase (0) localSearch ended: step total (3), time spend (41), best score (0).
INFO  Solving ended: time spend (41), best score (0), average calculate count per second (1780).

Notice that the logging uses the toString() method of the Move implementation: col1@row0 => row3.

A naive Local Search configuration solves the 4 queens problem in 3 steps, by evaluating only 37 possible solutions (3 steps with 12 moves each + 1 starting solution), which is only fraction of all 256 possible solutions. It solves 16 queens in 31 steps, by evaluating only 7441 out of 18446744073709551616 possible solutions. Note: with construction heuristics it's even a lot more efficient.

9.2.2. Deciding the next step

The local search solver decides the next step with the aid of 3 configurable components:

A MoveSelector which selects the possible moves of the current solution. See the chapter move and neighborhood selection.
An Acceptor which filters out unacceptable moves.
A Forager which gathers accepted moves and picks the next step from them.

The solver phase configuration looks like this:


  <localSearch>

    <unionMoveSelector>

      ...

    </unionMoveSelector>

    <acceptor>

      ...

    </acceptor>

    <forager>

      ...

    </forager>

  </localSearch>

In the example below, the MoveSelector generated the moves shown with the blue lines, the Acceptor accepted all of them and the Forager picked the move B0 to B3.

Turn on trace logging to show the decision making in the log:

INFO  Solver started: time spend (0), score (-6), new best score (-6), random seed (0).
TRACE         Move index (0) not doable, ignoring move (col0@row0 => row0).
TRACE         Move index (1), score (-4), accepted (true) for move (col0@row0 => row1).
TRACE         Move index (2), score (-4), accepted (true) for move (col0@row0 => row2).
TRACE         Move index (3), score (-4), accepted (true) for move (col0@row0 => row3).
...
TRACE         Move index (6), score (-3), accepted (true) for move (col1@row0 => row3).
...
TRACE         Move index (9), score (-3), accepted (true) for move (col2@row0 => row3).
...
TRACE         Move index (12), score (-4), accepted (true) for move (col3@row0 => row3).
DEBUG     Step index (0), time spend (6), score (-3), new best score (-3), accepted/selected move count (12/12) for picked step (col1@row0 => row3).
...

Because the last solution can degrade (for example in Tabu Search), the Solver remembers the best solution it has encountered through the entire search path. Each time the current solution is better than the last best solution, the current solution is cloned and referenced as the new best solution.

Important

With a low acceptedCountLimit it is recommended to avoid using selectionOrder SHUFFLED because the shuffling generates a random number for every element in the selector, taking up a lot of time, but only a few elements are actually selected.

9.2.4.2. Pick early type

A forager can pick a move early during a step, ignoring subsequent selected moves. There are 3 pick early types:

NEVER: A move is never picked early: all accepted moves are evaluated that the selection allows. This is the default.
```
    <forager>

      <pickEarlyType>NEVER</pickEarlyType>

    </forager>
```
FIRST_BEST_SCORE_IMPROVING: Pick the first accepted move that improves the best score. If none improve the best score, it behaves exactly like the pickEarlyType NEVER.
```
    <forager>

      <pickEarlyType>FIRST_BEST_SCORE_IMPROVING</pickEarlyType>

    </forager>
```
FIRST_LAST_STEP_SCORE_IMPROVING: Pick the first accepted move that improves the last step score. If none improve the last step score, it behaves exactly like the pickEarlyType NEVER.
```
    <forager>

      <pickEarlyType>FIRST_LAST_STEP_SCORE_IMPROVING</pickEarlyType>

    </forager>
```

9.3. Hill Climbing (Simple Local Search)

9.3.1. Algorithm description

Hill Climbing tries all selected moves and then takes the best move, which is the move which leads to the solution with the highest score. That best move is called the step move. From that new solution, it again tries all selected moves and takes the best move and continues like that iteratively. If multiple selected moves tie for the best move, one of them is randomly chosen as the best move.

Notice that one a queen has moved, it can be moved again later. This is a good thing, because in an NP-complete problem it's impossible to predict what will be the optimal final value for a planning variable.

9.3.2. Getting stuck in local optima

Hill Climbing always takes improving moves. This may seem like a good thing, but it's not: Hill Climbing can easily get stuck in a local optimum. This happens when it reaches a solution for which all the moves deteriorate the score. Even if it picks one of those moves, the next step might go back to the original solution and which case chasing it's own tail:

Improvements upon Hill Climbing (such as Tabu Search, Simulated Annealing and Late Acceptance) address the problem of being stuck in local optima. Therefore, it's recommend to never use Hill Climbing, unless you're absolutely sure there are no local optima in your planning problem.

9.3.3. Configuration

Configure this SolverPhase:


  <localSearch>

    ...

    <acceptor>

      <acceptorType>HILL_CLIMBING</acceptorType>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

9.4. Tabu Search

9.4.1. Algorithm description

Tabu Search works like Hill Climbing, but it maintains a tabu list to avoid getting stuck in local optima. The tabu list holds recently used objects that are taboo to use for now. Moves that involve an object in the tabu list, are not accepted. The tabu list objects can be anything related to the move, such as the planning entity, planning value, move, solution, ... Here's an example with entity tabu for 4 queens, so the queens are put in the tabu list:

Scientific paper: Tabu Search - Part 1 and Part 2 by Fred Glover (1989 - 1990)

9.4.2. Configuration

When Tabu Search takes steps it creates one or more tabu's. For a number of steps, it does not accept a move if that move breaks tabu. That number of steps is the tabu size.


  <localSearch>

    ...

    <acceptor>

      <entityTabuSize>7</entityTabuSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1000</acceptedCountLimit>

    </forager>

  </localSearch>

Important

A Tabu Search acceptor should be combined with a high acceptedCountLimit, such as 1000.

OptaPlanner implements several tabu types:

Solution tabu makes recently visited solutions tabu. It does not accept a move that leads to one of those solutions. If you can spare the memory, don't be cheap on the tabu size.
```
    <acceptor>

      <solutionTabuSize>1000</solutionTabuSize>

    </acceptor>
```

Move tabu makes recent steps tabu. It does not accept a move equal to one of those steps.


    <acceptor>

      <moveTabuSize>7</moveTabuSize>

    </acceptor>

Undo move tabu makes the undo move of recent steps tabu.


    <acceptor>

      <undoMoveTabuSize>7</undoMoveTabuSize>

    </acceptor>

Planning entity tabu makes the planning entities of recent steps tabu. For example, for N queens it makes the recently moved queens tabu. It's recommended to start with this tabu type.
```
    <acceptor>

      <entityTabuSize>7</entityTabuSize>

    </acceptor>
```
To avoid hard coding the tabu size, configure a tabu ratio, relative to the number of entities, for example 2%:
```
    <acceptor>

      <entityTabuRatio>0.02</entityTabuRatio>

    </acceptor>
```
Planning value tabu makes the planning values of recent steps tabu. For example, for N queens it makes the recently moved to rows tabu.
```
    <acceptor>

      <valueTabuSize>7</valueTabuSize>

    </acceptor>
```

You can even combine tabu types:


    <acceptor>

      <entityTabuSize>7</entityTabuSize>

      <valueTabuSize>3</valueTabuSize>

    </acceptor>

If you pick a too small tabu size, your solver can still get stuck in a local optimum. On the other hand, with the exception of solution tabu, if you pick a too large tabu size, your solver can get stuck by bouncing of the walls. Use the Benchmarker to fine tweak your configuration.

9.5. Simulated Annealing

9.5.1. Algorithm description

Simulated Annealing evaluates only a few moves per step, so it steps quickly. In the classic implementation, the first accepted move is the winning step. A move is accepted if it doesn't decrease the score or - in case it does decrease the score - if passes a random check. The chance that a decreasing move passes the random check decreases relative to the size of the score decrement and the time the phase has been running (which is represented as the temperature).

9.5.2. Configuration

Simulated Annealing does not always pick the move with the highest score, neither does it evaluate many moves per step. At least at first. Instead, it gives non improving moves also a chance to be picked, depending on its score and the time gradient of the Termination. In the end, it gradually turns into Hill Climbing, only accepting improving moves.

Start with a simulatedAnnealingStartingTemperature set to the maximum score delta a single move can cause. Use the Benchmarker to tweak the value.


  <localSearch>

    ...

    <acceptor>

      <simulatedAnnealingStartingTemperature>2hard/100soft</simulatedAnnealingStartingTemperature>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

Simulated Annealing should use a low acceptedCountLimit. The classic algorithm uses an acceptedCountLimit of 1, but often 4 performs better.

You can even combine it with a tabu acceptor at the same time. That gives Simulated Annealing salted with a bit of Tabu. Use a lower tabu size than in a pure Tabu Search configuration.


  <localSearch>

    ...

    <acceptor>

      <simulatedAnnealingStartingTemperature>2hard/100soft</simulatedAnnealingStartingTemperature>

      <entityTabuSize>5</entityTabuSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

9.6. Late Acceptance

9.6.1. Algorithm description

Late Acceptance (also known as Late Acceptance Hill Climbing) also evaluates only a few moves per step. A move is accepted if does not decrease the score, or if it leads to a score that is at least the late score (which is the winning score of a fixed number of steps ago).

Scientific paper: The Late Acceptance Hill-Climbing Heuristic by Edmund K. Burke, Yuri Bykov (2012)

9.6.2. Configuration

Late Acceptance accepts any move that has a score which is higher than the best score of a number of steps ago. That number of steps is the lateAcceptanceSize.


  <localSearch>

    ...

    <acceptor>

      <lateAcceptanceSize>400</lateAcceptanceSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

You can even combine it with a tabu acceptor at the same time. That gives Late Acceptance salted with a bit of Tabu. Use a lower tabu size than in a pure Tabu Search configuration.


  <localSearch>

    ...

    <acceptor>

      <lateAcceptanceSize>400</lateAcceptanceSize>

      <entityTabuSize>5</entityTabuSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

Late Acceptance should use a low acceptedCountLimit.


  <localSearch>

    ...

    <acceptor>

      <stepCountingHillClimbingSize>400</stepCountingHillClimbingSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1</acceptedCountLimit>

    </forager>

  </localSearch>

You can even combine it with a tabu acceptor at the same time, similar as shown in the Late Acceptance section.

Step Counting Hill Climbing should use a low acceptedCountLimit.

9.8. Late Simulated Annealing (experimental)

9.8.1. Algorithm description

Late Simulated Annealing combines the best characteristics of Simulated Annealing and Late Acceptance. A move is accepted if does not decrease the score, or if it leads to a score that is at least the late score, or - failing those criteria - if it passes a random check. The chance that a decreasing move passes the random check decreases relative to the size of the score decrement and the late score.

Warning

Currently, the Late Simulated Annealing prototype is consistently inferior to Late Acceptance.

9.8.2. Configuration

Late Simulated Annealing accepts any move that has a score which is higher than the best score of a number of steps ago and has a chance to accept any move below that score too. That number of steps is the lateSimulatedAnnealingSize.


  <localSearch>

    ...

    <acceptor>

      <lateSimulatedAnnealingSize>100</lateSimulatedAnnealingSize>

    </acceptor>

    <forager>

      <acceptedCountLimit>1000</acceptedCountLimit>

    </forager>

  </localSearch>

9.9. Using a custom Termination, MoveSelector, EntitySelector, ValueSelector or Acceptor

You can plug in a custom Termination, MoveSelector, EntitySelector, ValueSelector or Acceptor by extending the abstract class and also the related *Config class.

For example, to use a custom MoveSelector, extend the AbstractMoveSelector class, extend the MoveSelectorConfig class and configure it in the solver configuration.

Note

It's not possible to inject a Termination, ... instance directly (to avoid extending a Config class too) because:

A SolverFactory can build multiple Solver instances, which each require a distinct Termination, ... instance.
A solver configuration needs to be serializable to and from XML. This makes benchmarking with PlannerBenchmark particularly easy because you can configure different Solver variants in XML.
A Config class is often easier and clearer to configure. For example: TerminationConfig translates maximumMinutesSpend and maximumSecondsSpend into maximumTimeMillisSpend.

If you build a better implementation that's not domain specific, consider contributing it back as a pull request on github: we'll optimize it and take it along in future refactors.