Annealing Temperature Schedule¶
Schedule — instantiates Adaptive Mutation Rate Management
Follows a predetermined cooling curve: variation starts hot enough to accept disruptive, even worsening moves, then cools by the clock toward stability — shifting exploration into exploitation on a fixed schedule rather than in response to feedback.
Borrowed straight from metallurgy, Annealing Temperature Schedule governs variation with a single falling parameter — a temperature — set entirely by how far the run has progressed. When the temperature is high, the process readily accepts big, disruptive moves, including ones that make things temporarily worse, so it can climb out of local traps. As the temperature cools along a fixed curve, the process grows choosier, accepting only improvements, until it freezes into a settled state. Its defining move is that the schedule is open-loop and predetermined: the cooling curve is written before the run starts and followed by the clock, not steered by any live reading of how the search is doing. Explore-early, exploit-late is baked into time itself.
Example¶
A logistics team needs to sequence 800 delivery stops into an efficient route, and greedy nearest-neighbor keeps locking into obviously bad loops. They reach for simulated annealing. The solver proposes random swaps of stops; a temperature parameter sets how willing it is to accept a swap that lengthens the route. It starts hot — early on it will accept a swap that adds ten kilometers, letting the tour scramble out of a bad basin — and cools geometrically, multiplying the temperature by 0.95 after each batch of swaps. By the final batches the temperature is near zero and the solver accepts only swaps that shorten the route, polishing the tour to a local optimum.
Nothing about the run reads the route's current length to decide the temperature; the cooling curve was fixed in advance. The team's real work was choosing that curve — hot enough at the start to escape traps, slow enough to cool that good structure survives — because on a badly-set schedule the same solver either freezes into the first mediocre loop or never settles at all.[1]
How it works¶
- Set the starting temperature. High enough that most moves, including worsening ones, are accepted early — this is the exploration reservoir.
- Pick the cooling law. A geometric decay, a logarithmic schedule, or a staged step-down that lowers temperature as a function of iteration count alone.
- Tie acceptance to temperature. A worsening move of size Δ is accepted with a probability that shrinks as the temperature falls (the Metropolis rule), so disruption is common when hot and rare when cold.
- Run the clock down. Cool through the schedule to a freezing point; the run's explore-to-exploit shift is entirely the temperature's descent.
Tuning parameters¶
- Initial temperature — how disruptive variation is at the start. Too low and the search freezes early into a local optimum; too high and it wanders uselessly at first.
- Cooling rate — how fast the temperature falls. Fast cooling is cheap but risks premature convergence; slow cooling explores thoroughly but costs iterations.
- Cooling law — geometric, logarithmic, or staged. The shape decides how much of the budget is spent hot versus cold.
- Dwell length — how many moves are attempted at each temperature level before the next drop. Longer dwell lets each regime equilibrate.
- Final temperature — where the schedule stops. A hard freeze locks in; a warm floor keeps a trickle of exploration alive.
When it helps, and when it misleads¶
Its strength is that it needs no feedback machinery: a fixed cooling curve provably drifts a search from exploration to exploitation, is trivial to reason about, and cannot be destabilized by a noisy progress signal because it never reads one. On problems whose difficulty profile is roughly known in advance, a well-set schedule is hard to beat for its simplicity.
Its failure mode is the flip side of that simplicity: the schedule is blind to the actual landscape. Cool too fast for the problem and it converges prematurely into a poor optimum; cool too slow and it burns the budget wandering. The classic misuse is transplanting one project's schedule onto a different problem, where the same curve either freezes early or never settles — because the schedule cannot notice that it has mismatched the terrain. The discipline is to tune the curve to the specific problem (often by trial runs), and, where a run is clearly stuck or clearly done, to reheat or stop rather than mechanically riding the clock down.
How it implements the components¶
Annealing Temperature Schedule realizes the predetermined-plan side of the archetype — the components that fix how variation should change over a run:
mutation_rate_schedule— the cooling curve is the rate schedule: temperature over iteration count sets how much disruptive variation is admitted at every point.phase_plan— the hot-to-cold descent is an explicit phase plan, moving the run through an exploratory phase into an exploitative one on a fixed timetable.
It does not read live search_state_observability or close an evaluation_feedback_loop — that's the Adaptive Learning-Rate or Noise Schedule; the one-sentence difference is that annealing follows a curve fixed before the run, while the adaptive schedule computes the rate from the search's live state.
Related¶
- Instantiates: Adaptive Mutation Rate Management — this schedule is the archetype's open-loop way of drifting a run from exploration to exploitation.
- Sibling mechanisms: Adaptive Learning-Rate or Noise Schedule · Mutation Budget Cap · Plateau-Triggered Rate Boost · Protected Elite Set · Random Restart Pulse · Rollback Checkpoint · Sandboxed Mutation Test
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: During search the mechanism applies a predetermined time-dependent cooling law that changes the probability of accepting worsening moves and thereby shifts execution from exploration to exploitation, so it is runtime control.
Nearest alternative: Representation, Specification & Plan — The cooling curve can be documented as a schedule, but its operative role is to govern live move acceptance during execution.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Simulated-annealing algorithms made a predetermined cooling curve into an explicit open-loop control of computational exploration.
Related originating lineages:
- Chemistry & Materials Science — Metallurgy is the source of the annealing process analogy.
- Mathematics — Probability and asymptotic convergence justify schedules.
- Operations Research — Combinatorial optimization supplied extensive schedule design and application.
- Physics — The Metropolis criterion and statistical-mechanical temperature are mathematically formative.
Review resolution: The explicit cooling curve is an established simulated-annealing algorithmic device. Metallurgy, probability, operations research, and statistical mechanics materially formed it; despite cross-disciplinary origins, its direct reach is specialized.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Simulated annealing (Kirkpatrick, Gelatt, and Vecchi, 1983) named the method by analogy with annealing in metallurgy, where a metal is heated and cooled slowly so its atoms settle into a low-energy crystal. Accepting occasional worsening moves with a temperature-dependent probability is the Metropolis criterion that makes the escape-from-local-optima behavior work. withdrawn registry ↩