Adaptive migration: stabilize evolution by adapting mutation/selection based on progress

[kotama7]

Title: Adaptive island migration: per-island parameter tuning + optional bandit policy selection

Summary:
This PR adds an optional adaptive migration module that tunes island-migration behavior during evolution runs. When enabled, Shinka can adjust (per island):

• migration_rate
• migration_interval
• island_elitism (treated as a float ratio internally)
  The adaptation can be driven by success, diversity, and/or a bandit policy selector, and it writes a run log to migration_adaptation.csv in the run’s results_dir.

Motivation:
Fixed, global migration hyperparameters are often suboptimal across islands and across phases of a run. This change makes migration responsive to observed outcomes, improving robustness without changing default behavior for existing configurations (adaptation is opt-in).

Key Changes:

1. New config surface (opt-in)

• Introduces an optional db_config.migration_adaptation block (MigrationAdaptationConfig) and related sub-config dataclasses
• Adds a sample Hydra config: configs/database/island_adaptive.yaml
• Updates documentation: configuration guide now describes migration_adaptation and points to docs/migration_adaptation.md

2. Runtime controller + logging

• Adds MigrationAdaptationController that:

  • registers per-island params with the island manager
  • optionally registers a policy provider (bandit)
  • logs adaptation state each generation to migration_adaptation.csv

3. Island migration now supports per-island params + policies

• Migration strategy can consume:

  • a per-island parameter provider (rate/interval/elitism)
  • a per-island policy provider (donor/payload/size)

4. Runner integration (no behavior change unless enabled)

• EvolutionRunner instantiates the controller only when db_config.migration_adaptation.enabled == true

Backward Compatibility:

• Default behavior remains unchanged when migration_adaptation is omitted / null / disabled.

How to Test:

1. Install (example using uv):
   uv venv --python 3.11
   source .venv/bin/activate
   uv pip install -e ".[dev]"

2. Run an example with adaptive migration enabled via the provided database preset:
   shinka_launch variant=circle_packing_example database=island_adaptive evo_config.num_generations=12

3. Confirm outputs:

• migration_adaptation.csv exists under the run output directory (results_dir)
• Logs show migration events and the run completes successfully

Expected result:
The run completes normally, and migration_adaptation.csv contains per-generation rows per island with migration_rate, migration_interval, island_elitism, and optional bandit policy fields.

Notes / Design Details:

• island_elitism is normalized to a float ratio internally (e.g., a boolean true maps to a small default ratio); adaptation updates clamp changes with bounds and per-step change limits.

Checklist:

• Code builds and runs locally
• Lint/style checks pass (if applicable)
• Verified baseline parity when migration_adaptation is disabled
• Added/updated docs + sample config

[RobertTLange]

Hi there! Thank you for putting in the work. Do you have any results indicating that this type of adaptation is helping performance? Is there any related work?

[kotama7]

Top: Baseline execution using the shinka_launch variant=circle_packing_example configuration.

Bottom: Execution with adaptive migration enabled. All other settings are identical to the baseline, except for the island configuration.

Hi Robert — thanks a lot for taking a look.

Preliminary results (Circle Packing example)

I ran a quick sanity check on circle_packing_example comparing the default (fixed) migration setup vs. database=island_adaptive (this PR), keeping the rest of the run configuration the same.

Best fitness (end of run): adaptive improved by ~0.7% (Δ ≈ +0.0185 in the reported score in my run).

Efficiency: adaptive reached the baseline’s best score in ~4.6× less wall-clock time (time-to-target).

The run also produces migration_adaptation.csv, which makes it easy to inspect per-island migration_rate / migration_interval / island_elitism trajectories and the (optional) bandit-selected policy per generation.

Related work

Conceptually, this PR is closest to prior work on parameter control in evolutionary algorithms and adaptive/dynamic island models, plus bandit-based operator/policy selection:

Karafotias et al., Parameter Control in Evolutionary Algorithms: Trends and Challenges, IEEE TEVC 2015 (survey of parameter control).
ACM Digital Library

Srinivasa et al., A Dynamic Migration Model for Self-adaptive Genetic Algorithms, 2005 (dynamic/self-adaptive migration).
SpringerLink

Candan et al., A Dynamic Island Model for Adaptive Operator Selection, GECCO 2012 (dynamic island model framing + adaptive selection).
ACM Digital Library

Fialho et al., Analyzing bandit-based adaptive operator selection mechanisms, AMAI 2010 (MAB/UCB-style adaptive operator selection).
SpringerLink

Lissovoi et al., GECCO 2016 (work discussing adaptive migration intervals/topology effects in island models).
ACM Digital Library

If you prefer, I can add these citations (with brief “how it relates” notes) directly into docs/migration_adaptation.md to better motivate the design.

Thanks again — happy to run a more systematic ablation (success-only vs diversity-only vs bandit, and with/without step-clamp) if that would help the PR decision.