anchor.diff:  [[customSolverPhase]]
   == Custom Solver Phase
   
  -Between phases or before the first phase, you might want to run a custom optmization algorithm to initialize the `Solution`
  -or to take some low hanging fruit to get a better score quickly.
  -Yet you'll still want to reuse the score calculation.
  -For example, to implement a custom Construction Heuristic without implementing an entire ``Phase``.
  -
  -[NOTE]
  -====
  -Most of the time, a custom solver phase is not worth the hassle.
  +Run a custom optmization algorithm etween phases or before the first phase to initialize the `Solution`, or to get a better score quickly.
  +You will still want to reuse the score calculation.
  +For example, to implement a custom Construction Heuristic without implementing an entire `Phase`.
  +
  +[NOTE]
  +====
  +Most of the time, a custom solver phase is not worth the development time investment.
   The supported <<constructionHeuristics,Constructions Heuristics>> are configurable (use the <<benchmarker,Benchmarker>> to tweak them),
   `Termination` aware and support partially initialized solutions too.
   ====
   
  -The `CustomPhaseCommand` interface looks like this:
  +The `CustomPhaseCommand` interface appears as follows:
   
   [source,java,options="nowrap"]
   ----
  
positive.code:   </termination>
  ----
  
  This example ensures it doesn't just terminate after finding a feasible solution, but also completes any obvious improvements on that solution before terminating.
  
  
  [[asynchronousTermination]]
  === Asynchronous Termination from Another Thread
  
  Sometimes you'll want to terminate a Solver early from another thread, for example because a user action or a server restart.
  This cannot be configured by a `Termination` as it's impossible to predict when and if it will occur.
  Therefore the `Solver` interface has these 2 thread-safe methods:
  
  [source,java,options="nowrap"]
  ----
  
negative.code: This search space size calculation includes infeasible solutions (if they can be represented by the model), because:
  
  * The optimal solution might be infeasible.
  * There are many types of hard constraints that cannot be incorporated in the formula practically. For example, in Cloud Balancing, try incorporating the CPU capacity constraint in the formula.
  
  Even in cases where adding some of the hard constraints in the formula is practical (for example, Course Scheduling), the resulting search space is still huge.
  ====
  
  An algorithm that checks every possible solution (even with pruning, such as in <<branchAndBound,Branch And Bound>>) can easily run for billions of years on a single real-life planning problem.
  The aim is to find the best solution in the available timeframe.
  Planning competitions (such as the International Timetabling Competition) show that Local Search variations
  (<<tabuSearch,Tabu Search>>, <<simulatedAnnealing,Simulated Annealing>>, <<lateAcceptance,Late Acceptance>>, ...)
  usually perform best for real-world problems given real-world time limitations.
  