Solver System
The DispatchAtlas solver system — a capability-typed registry of constructive baselines, dispatching rules, metaheuristics, exact backends, and NDSO variants with declared metadata.
dispatchatlas.solve owns solver metadata, selection, schedule construction,
repair, performance safeguards, baseline families, optional adapters, and the
NDSO family.
The package imports dispatchatlas.core only. Benchmark smoke integration tests
live in tests/solve/ so the runtime package does not depend on concrete
benchmark generators.
Runnable example: examples/compare_solvers.py schedules a solver cohort in parallel and anchors it with a proven exact optimum.
Registry
SolverRegistry stores stateless solver factories with rich metadata:
- capability tags such as
capacity-aware,precedence-aware,repair,local-search, andndso - supported objectives such as
makespan,energy, andcost - declared constraints expressed through capability tags
- default stop criteria
- deterministic or seeded stochastic replay behavior
- solution encoding (
permutation,mapping,assignment, ornative) - optional dependency declarations and commercial-backend disclosure
- evidence-tier visibility for staged exports
- a canonical citation, or an explicit citation-not-applicable rationale
Every named solver family carries a citation that fails closed: a family with a canonical seminal origin that omits its reference cannot be constructed, and a family with no single canonical origin records the reason rather than fabricating one.
from dispatchatlas.solve import SolverCapability, default_solver_registry
registry = default_solver_registry()
metaheuristics = registry.select(
required_capabilities=(SolverCapability.METAHEURISTIC,),
objective="makespan",
)Registry Catalog
Every solver in the registry, in one sortable, searchable table. The table and
its totals are generated from default_solver_registry(), so the counts below
are countable from the rows themselves. A capability-coverage chart above the
table summarizes how many registry solvers advertise each declared capability.
Generated from the solver registry: 87 solvers across 6 groups — constructive (5), dispatching (14), exact (7), learning (11), metaheuristic (47), ndso (3).
Showing 87 of 87 solvers.
| Supported objectives | Notes | ||
|---|---|---|---|
adpso | metaheuristic | makespan, energy, cost | Inspect
|
age-moea-ii | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
ant-colony | metaheuristic | makespan, energy, cost | Inspect
|
apparent-tardiness-cost | dispatching | makespan, lateness, energy, cost | Inspect
|
arithmetic-optimization | metaheuristic | makespan, energy, cost | Inspect
|
artificial-bee-colony | metaheuristic | makespan, energy, cost | Inspect
|
artificial-fish-swarm | metaheuristic | makespan, energy, cost | Inspect
|
beam-search | constructive | makespan, energy, cost | Inspect
|
branch-and-bound | exact | makespan, energy, cost | Inspect
|
ccgp | metaheuristic | makespan, energy, cost | Inspect
|
clpso | metaheuristic | makespan, energy, cost | Inspect
|
cma-es | metaheuristic | makespan, energy, cost | Inspect
|
cpop | dispatching | makespan, energy, cost | Inspect
|
critical-path-tabu | metaheuristic | makespan, energy, cost | Inspect
|
cuckoo-search | metaheuristic | makespan, energy, cost | Inspect
|
d-clpso | metaheuristic | makespan, energy, cost | Inspect
|
d-depso | metaheuristic | makespan, energy, cost | Inspect
|
d-lshade | metaheuristic | makespan, energy, cost | Inspect
|
dan-dual-attention | learning | makespan, energy, cost | Inspect
|
decima-dag-rl | learning | makespan, energy, cost | Inspect
|
decision-diagram-sequencing | exact | makespan, energy, cost | Inspect
|
differential-evolution | metaheuristic | makespan, energy, cost | Inspect
|
earliest-deadline | dispatching | makespan, energy, cost | Inspect
|
earliest-finish-time | dispatching | makespan, energy, cost | Inspect
|
earliest-start | dispatching | makespan, energy, cost | Inspect
|
epso | metaheuristic | makespan, energy, cost | Inspect
|
exhaustive-enumeration | exact | makespan, energy, cost | Inspect
|
firefly-algorithm | metaheuristic | makespan, energy, cost | Inspect
|
fjsp-hgnn-drl | learning | makespan, energy, cost | Inspect
|
genetic-algorithm | metaheuristic | makespan, energy, cost | Inspect
|
grasshopper-optimization | metaheuristic | makespan, energy, cost | Inspect
|
gravitational-search | metaheuristic | makespan, energy, cost | Inspect
|
greedy-completion | dispatching | makespan, energy, cost | Inspect
|
grey-wolf-optimizer | metaheuristic | makespan, energy, cost | Inspect
|
guided-local-search | metaheuristic | makespan, energy, cost | Inspect
|
gurobi-exact | exact | makespan, energy, cost | Inspect
|
harris-hawks-optimization | metaheuristic | makespan, energy, cost | Inspect
|
heft | dispatching | makespan, energy, cost | Inspect
|
ibea | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
iterated-greedy-rs | metaheuristic | makespan, energy, cost | Inspect
|
jaya-algorithm | metaheuristic | makespan, energy, cost | Inspect
|
l2d-disjunctive-gnn | learning | makespan, energy, cost | Inspect
|
l2s-improvement | learning | makespan, energy, cost | Inspect
|
learned-priority-policy | learning | makespan, energy, cost | Inspect
|
logic-based-benders-decomposition | exact | makespan, energy, cost | Inspect
|
longest-processing-time | dispatching | makespan, energy, cost | Inspect
|
lshade | metaheuristic | makespan, energy, cost | Inspect
|
marine-predators | metaheuristic | makespan, energy, cost | Inspect
|
matheuristic-restricted-neighbourhood | metaheuristic | makespan | Inspect
|
max-min | dispatching | makespan, energy, cost | Inspect
|
min-min | dispatching | makespan, energy, cost | Inspect
|
minimum-slack | dispatching | makespan, energy, cost | Inspect
|
moead | metaheuristic | makespan, lateness, fairness, energy, cost | Inspect
|
monte-carlo-tree-search | metaheuristic | makespan, energy, cost | Inspect
|
moth-flame-optimization | metaheuristic | makespan, energy, cost | Inspect
|
ndso-core | ndso | makespan, energy, cost | Inspect
|
ndso-fast | ndso | makespan, energy, cost | Inspect
|
ndso-summit | ndso | makespan, energy, cost | Inspect
|
neh | constructive | makespan, energy, cost | Inspect
|
nsga2 | metaheuristic | makespan, lateness, fairness, energy, cost | Inspect
|
nsga3 | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
ortools-cp-sat | exact | makespan, energy, cost | Inspect
|
particle-swarm | metaheuristic | makespan, energy, cost | Inspect
|
peft | dispatching | makespan, energy, cost | Inspect
|
pulp-milp | exact | makespan, energy, cost | Inspect
|
residual-scheduling | learning | makespan, energy, cost | Inspect
|
rl-dispatching | learning | makespan, energy, cost | Inspect
|
rollout | constructive | makespan, energy, cost | Inspect
|
rvea | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
salp-swarm | metaheuristic | makespan, energy, cost | Inspect
|
sarsa-dispatching | learning | makespan, energy, cost | Inspect
|
scatter-search | metaheuristic | makespan, energy, cost | Inspect
|
selection-hyper-heuristic | metaheuristic | makespan, energy, cost | Inspect
|
serial-sgs-justification | constructive | makespan, energy, cost | Inspect
|
shifting-bottleneck | constructive | makespan, energy, cost | Inspect
|
shortest-processing-time | dispatching | makespan, energy, cost | Inspect
|
simulated-annealing | metaheuristic | makespan, energy, cost | Inspect
|
sine-cosine-algorithm | metaheuristic | makespan, energy, cost | Inspect
|
slim-self-labeling | learning | makespan, energy, cost | Inspect
|
sms-emoa | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
spea2 | metaheuristic | makespan, lateness, fairness, energy, cost, carbon | Inspect
|
squeaky-wheel | metaheuristic | makespan, energy, cost | Inspect
|
sufferage | dispatching | makespan, energy, cost | Inspect
|
surrogate-assisted-gp-hh | learning | makespan, energy, cost | Inspect
|
tabu-mrcpsp-mode-search | metaheuristic | makespan, energy, cost | Inspect
|
teaching-learning-optimization | metaheuristic | makespan, energy, cost | Inspect
|
whale-optimization | metaheuristic | makespan, energy, cost | Inspect
|
All objective support is declared registry metadata, not a performance claim. The solver recommender ranks these solvers by declared fit.
Solver Applicability
Which solvers apply to which benchmark family, read from the applicability matrix. Every cell is declared applicability, never a performance claim: verified cells cite a named public campaign, citation, or test, and approximate cells are derived from declared solver capabilities and benchmark-family traits. The table below is generated from the public applicability bundle, so its status totals are countable from the rows themselves.
Generated from the applicability matrix: 69 benchmark families by 87 public solvers. 10 verified · 5835 approximate · 158 not applicable.
Cell status is declared applicability, never a performance claim. Verified cells cite a named public campaign artifact, citation source, or test; approximate cells are derived from declared solver capabilities and benchmark-family traits and are labeled as such.
Showing 6003 of 6003 cells.
| Basis | |||
|---|---|---|---|
accelerator-coschedulingdistributed-computing | adpso | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the random-key-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | age-moea-ii | Approximate | family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | ant-colony | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | apparent-tardiness-cost | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | arithmetic-optimization | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | artificial-bee-colony | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | artificial-fish-swarm | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | beam-search | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | branch-and-bound | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | ccgp | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | clpso | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the random-key-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | cma-es | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | cpop | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | critical-path-tabu | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | cuckoo-search | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | d-clpso | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the spv-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | d-depso | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | d-lshade | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the rounding-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | dan-dual-attention | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | decima-dag-rl | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | decision-diagram-sequencing | Not applicable | native exact search caps at 12 tasks; family instances carry 96; optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | differential-evolution | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | earliest-deadline | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | earliest-finish-time | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | earliest-start | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | epso | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the random-key-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | exhaustive-enumeration | Not applicable | native exact search caps at 8 tasks; family instances carry 96; optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | firefly-algorithm | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | fjsp-hgnn-drl | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | genetic-algorithm | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | grasshopper-optimization | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | gravitational-search | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | greedy-completion | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | grey-wolf-optimizer | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | guided-local-search | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | gurobi-exact | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | harris-hawks-optimization | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | heft | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | ibea | Approximate | family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | iterated-greedy-rs | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | jaya-algorithm | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | l2d-disjunctive-gnn | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | l2s-improvement | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | learned-priority-policy | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | logic-based-benders-decomposition | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | longest-processing-time | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
accelerator-coschedulingdistributed-computing | lshade | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; searches a continuous space decoded via the random-key-adapter with topological repair. |
accelerator-coschedulingdistributed-computing | marine-predators | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling. |
accelerator-coschedulingdistributed-computing | matheuristic-restricted-neighbourhood | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity; produces a static schedule for a family with dynamic arrivals/rescheduling; no repair or dispatching mechanism for the family's declared uncertainty. |
accelerator-coschedulingdistributed-computing | max-min | Approximate | optimizes one objective axis of a multi-objective family; family declares constraint features with no capability-tag counterpart: affinity. |
Cell status is declared applicability, never a performance claim. Verified cells cite a named public campaign, citation, or test; approximate cells are derived from declared solver capabilities and benchmark-family traits. The solver recommender scores solvers against this matrix by scheduling family.
Dispatching Baselines
The bundled deterministic baselines are constructive list-scheduling solvers. Each controls task order; the serial constructor honors every task's declared resource demands and assigns each task to its earliest-available demanded resource. Each family names its canonical seminal reference.
| Solver | Priority basis | Canonical reference |
|---|---|---|
earliest-start | topological input order | not applicable (identity baseline) |
shortest-processing-time | shortest task duration first | Smith (1956) |
longest-processing-time | longest task duration first | Graham (1969) |
earliest-deadline | earliest deadline first (deadline-aware) | Jackson (1955) |
earliest-finish-time | earliest reachable finish first | Topcuoglu et al. (2002) |
minimum-slack | smallest schedule slack first | Conway, Maxwell & Miller (1967) |
greedy-completion | earliest state-aware completion first | Graham (1966) |
apparent-tardiness-cost | highest apparent-tardiness-cost index first (deadline-aware) | Vepsalainen & Morton (1987) |
Retired Dispatching Families
Resource-mapping families are recorded explicitly rather than silently folded into a generic kind. They control resource assignment, not task order, and the demand-respecting serial constructor exposes no free mapping decision under the current core problem model:
- Resource mapping (
olb,met,mct,round-robin,load-balanced): the constructor assigns each task to its declared resource, so these heuristics have no realizable degree of freedom; execution-time-aware mapping is owned by the objectives and constraints work, not this foundation. - Type tags absent (
type-aware,domain-aware): require task-type and resource-type tags that the current core problem model does not carry.
retired_dispatching_families() returns the full ledger with per-family
rationale and citation.
Rank-Based List Schedulers
Three heterogeneity-aware list schedulers share a two-phase shape: a static prioritization phase ranks every task over the precedence DAG from mean execution times and communication costs, and a processor-selection phase binds each task in priority order through the serial constructor's earliest-finish rule. Per-resource execution times come from a moldable task's declared execution modes, and a rigid task degenerates to the documented homogeneous specialization.
| Solver | Priority basis | Canonical reference |
|---|---|---|
heft | upward rank | Topcuoglu, Hariri & Wu (2002) |
cpop | combined upward-plus-downward rank, critical-path tasks first | Topcuoglu, Hariri & Wu (2002) |
peft | optimistic-cost-table rank | Arabnejad & Barbosa (2014) |
Ready-Set Mapping Rules
Three batch mapping rules score every precedence-ready task by its earliest
completion over its candidate bindings, then map one task per step. The
published rules map a batch of independent tasks; here the batch is the
precedence-ready set, so the rules extend to dependent workloads and reduce to
the published behavior on independent-task instances. These families left the
retired ledger for first-class registration once moldable TaskSpec.modes made
their per-machine expected-completion matrix representable.
| Solver | Priority basis | Canonical reference |
|---|---|---|
min-min | smallest best completion next | Ibarra & Kim (1977); Braun et al. (2001) |
max-min | largest best completion next | Ibarra & Kim (1977); Braun et al. (2001) |
sufferage | largest second-best-minus-best completion gap next | Maheswaran et al. (1999) |
Iterated-Greedy, Tabu, and RCPSP Baselines
Three published single-solution methods search the precedence-safe task-order
space, each projecting its canonical mechanism onto the shared order-run seam.
serial-sgs-justification is the platform's first resource-constrained
project-scheduling (RCPSP) solver.
| Solver | Mechanism | Canonical reference |
|---|---|---|
iterated-greedy-rs | NEH seed with a destruction-reconstruction loop and fixed-temperature acceptance | Ruiz & Stutzle (2007) |
critical-path-tabu | advanced tabu search over critical-path block moves | Nowicki & Smutnicki (2005) |
serial-sgs-justification | serial schedule-generation-scheme decode with double right-then-left justification | Valls, Ballestin & Quintanilla (2005) |
Metaheuristic Baselines
Representative seeded metaheuristic baselines share the same feasibility, repair, scoring, and local-search operators, each with its canonical reference: genetic algorithm (Holland 1975), simulated annealing (Kirkpatrick et al. 1983), ant colony (Dorigo, Maniezzo & Colorni 1996), particle swarm (Kennedy & Eberhart 1995), and differential evolution (Storn & Price 1997).
Encoded Adapter Solvers
Comprehensive learning particle swarm optimization and success-history adaptive differential evolution search a continuous, real-valued vector with one component per task. Each core is generic over a continuous objective, so its convergence behavior is validated directly on a continuous benchmark, and is bound to the scheduling problem through an encoding adapter that decodes a vector into a precedence-feasible task order.
| Solver | Inspiration | Adaptation | Encoding |
|---|---|---|---|
clpso | Comprehensive learning particle swarm (Liang et al. 2006) | Continuous swarm decoded to a precedence order | random-key |
d-clpso | Comprehensive learning particle swarm (Liang et al. 2006) | Discrete adapter over the smallest-position-value decode | spv |
lshade | Success-history adaptive DE with linear population reduction (Tanabe & Fukunaga 2014) | Continuous differential evolution decoded to a precedence order | random-key |
d-lshade | Success-history adaptive DE with linear population reduction (Tanabe & Fukunaga 2014) | Discrete adapter over integer-rank rounding | rounding |
CLPSO learns each dimension from a comprehensive-learning exemplar rather than a single global best, so the swarm's best fitness improves monotonically on a unimodal basin. L-SHADE adapts crossover and scale-factor memories from its success history and shrinks the population linearly to a minimum of four individuals. Both report a convergence trajectory, and a convergence-correctness test fails when the observed trajectory contradicts the published reference behavior, separate from seed-reproducibility checks.
These solvers are continuous optimizers adapted to a discrete domain through an encoding bridge; they are not exact reimplementations of any prior code, and no performance claim is made before the comparative campaigns run.
Encoding Adapters
Each named continuous-to-discrete encoding is a distinct adapter with an explicit repair policy, so no encoding is silently folded into a generic decoder. Every adapter repairs its decoded order into a precedence-feasible order and records whether repair fired.
| Adapter | Transfer | Decode rule | Citation status |
|---|---|---|---|
random-key | identity | sort by clamped key | canonical (Bean 1994) |
spv | identity | smallest position value | canonical (Tasgetiren et al. 2007) |
rounding | identity | integer rank slots | not-applicable |
sigmoid | S-shaped sigmoid | weighted probabilistic draw | canonical (Kennedy & Eberhart 1997) |
v-shaped | V-shaped magnitude | weighted probabilistic draw | canonical (Mirjalili & Lewis 2013) |
tanh | shifted hyperbolic tangent | weighted probabilistic draw | canonical (Mirjalili & Lewis 2013) |
The deterministic decodes (random-key, spv, rounding) ignore the random
source; the transfer-function decodes consume a seeded source and replay under a
fixed seed. The rounding adapter records citation-not-applicable because
nearest-integer rank rounding is a generic discretization with no single
canonical seminal origin.
Diversified Competitor Set
The diversified competitor set broadens the comparison beyond the representative baselines with a small handful of recent, strong peers, each a named solver with its full-text reference projected onto the order-only decision space, rather than a bulky roster of classical baselines. A peer stays on the public field only when it clears a venue-strength bar: published within the post-2020 currency window in an indexed, peer-reviewed venue, with the venue tier recorded so a reader weights it on evidence rather than on prestige.
| Solver | Mechanism | Venue | Citation |
|---|---|---|---|
epso | Workload-biased-initialization swarm with path gathering | Electronics (MDPI), 2023 — indexed | Anbarkhan & Rakrouki (2023) |
adpso | Swarm search with success-adaptive descending inertia | Sensors (MDPI), 2022 — indexed | Nabi et al. (2022) |
ccgp | Cooperative coevolution of priority-rule trees | Computers & Operations Research (Elsevier), 2024 — top-tier OR | Zaki et al. (2024) |
Each peer carries strengths, caveats, and a runnable-baseline evidence class in its metadata so the recommender can explain why a solver fits a context. A broader set of classical baselines — integer-key, biased-random-key, and estimation-of-distribution genetic algorithms, and large-neighborhood, iterated greedy, tabu, variable-neighborhood, and memetic searches — stays registered for internal comparison but is kept off the public field, since the representative heuristics already carry their mechanism signal. No performance claim is made before the comparative campaigns run.
Currency Anchor
The competitor and related-work set is positioned against current-decade work through a post-2020 currency anchor: Karimi-Mamaghan, Mohammadi, Pasdeloup, and Meyer (2023, learning to select operators via Q-learning integrated into iterated greedy for the permutation flowshop, European Journal of Operational Research 304(3):1296-1330, doi:10.1016/j.ejor.2022.03.054) and the 2024 IEEE Transactions on Evolutionary Computation indicator-driven collaborative multi-objective evolutionary algorithm for distributed flowshop group scheduling (doi:10.1109/TEVC.2023.3339558).
Multi-Objective Competitors
Two Pareto competitors evolve a population of precedence-safe task orders on a
multi-objective vector, distinct from the many-objective nsga3 surface.
nsga2 is the dominance-based competitor — fast nondominated sorting with
crowding-distance tie-breaking — and moead is the decomposition-based
counterweight, splitting the problem into scalar Tchebycheff subproblems along a
structured simplex weight grid and replacing incumbents across each subproblem's
nearest-weight neighborhood.
| Solver | Mechanism | Canonical reference |
|---|---|---|
nsga2 | dominance-based Pareto: fast nondominated sorting, crowding distance | Deb et al. (2002) |
moead | decomposition-based Pareto: Tchebycheff scalarization over a simplex weight grid | Zhang & Li (2007) |
Many-Objective Competitor
nsga3 is the named many-objective competitor (Deb & Jain 2014,
doi:10.1109/TEVC.2013.2281535), distinct from the bi-objective competitor
surface. It maintains a population over precedence-safe task orders, evaluates
each order on a multi-objective vector (makespan, lateness, and load fairness),
and survives each generation by a reference-point niching selection over
Das & Dennis structured reference points on the unit simplex. The
reference-point design, the association of solutions to their nearest reference
direction, and the niche-count selection are the algorithmic signature; the
solver declares the many-objective capability alongside multi-objective so a
campaign can select it explicitly.
Capability Matching
SolverRegistry.select matches solvers by capability, constraint, and objective. Capability and constraint requirements are both expressed as
capability tags and matched as a conjunction: a many-objective campaign that also
needs deadline awareness passes
required_capabilities=(SolverCapability.MANY_OBJECTIVE,) and
required_constraints=(SolverCapability.DEADLINE_AWARE,), and the registry
returns only solvers that declare both. An objective filter further restricts
the result to solvers that declare support for that named objective.
NDSO Family
The NDSO family is the registry's native-encoding solver family: it searches
directly over feasible schedules. Every schedule it produces is feasible by
construction (a validity-by-design constructor builds a precedence-respecting
order at each step), so the family carries the native encoding and never runs
an encode/decode step or a repair pass. The family composes a small set of named
mechanisms:
- Confidence Matrix — a sparse store of learned trust per (position, task) cell, updated as better schedules reinforce their cells.
- Confidence-Weighted Voting — synthesizes the elite schedule by voting across the population weighted by the Confidence Matrix; the fast variant uses an unweighted majority vote instead.
- Quantity-and-Quality schedules — the Quantity schedule sets how much a candidate changes; the Quality schedule sets which guidance source it learns from.
- Three-source guidance — a candidate learns from the synthesized elite (exploitation), a peer (diversity), or a vanished-knowledge source (radical exploration).
- Unified adaptive coefficient — one non-linear schedule shifts the family from exploration to exploitation and drives both the sensitivity and the learning focus; the fast variant pins it to a fixed value.
| Variant | Composition |
|---|---|
ndso-core | Confidence-Weighted Voting, adaptive coefficient, three-source guidance |
ndso-fast | majority-vote synthesis, fixed coefficient, single guidance source |
ndso-summit | Inter-group council coordinating several groups with over-arching synthesis |
Inter-Group Council
The ndso-summit variant is the quality composition: it runs several groups in
parallel and coordinates them through one council. Each swarm composes the core
mechanisms over its own population; the inter-group council keeps those groups
working as one search rather than several isolated runs and synthesizes their
results into a single over-arching elite — the schedule the whole summit stands
behind. The council is what distinguishes the variant at a glance: ndso-core
and ndso-fast each search with one population, while ndso-summit is the
composition built for coordinated multi-swarm search.
The council's coordination behavior and per-swarm diagnostics are configurable, and every schedule it produces remains feasible by construction.
Ablation Map
The ablation map enumerates one isolating configuration per named mechanism so downstream analysis can attribute each mechanism's contribution. The intra-swarm entries disable one switch each: the eight core switches — the Confidence Matrix, Confidence-Weighted Voting, the Quantity schedule, the Quality schedule, the multi-source guidance structure, the peer source, the vanished-knowledge source, and the adaptive coefficient — plus the speed-tier anytime-convergence-control switch. These switches are isolated with one dependency: Confidence-Weighted Voting reads the Confidence Matrix, so the matrix-disabling entry also removes that weighting. The coordination entries each disable one council parameter — the Intra- versus inter-group coordination and the over-arching synthesis. Each entry declares the run-count floor at which the analysis layer samples its comparison and names the statistical tests that layer applies (a paired nonparametric significance test, a Friedman average-rank post-hoc with a Holm multiple-comparison correction, and a Cliff's-delta effect size). The sampled comparison is materialized by the downstream experiment engine; the in-process runner proves every isolation is feasible.
A staged export filter governs which mechanisms a report scope may expose: the base scope exposes the foundational mechanisms only, and a fail-closed gate raises rather than leaking a faster or higher-quality mechanism under a base scope, so the foundational and fast scopes cannot expose the council-only mechanisms. Convergence diagnostics — population diversity, Confidence-Matrix entropy, exploration ratio, resource load, timing, and the improvement trace — are optional and add no overhead when disabled, and the council exports a JSON manifest the analysis layer ingests without importing any solver type.
Exact Adapters
Exact adapters take one of two shapes. Optional-backend adapters declare an
optional dependency and check its import root at runtime; if the backend is
absent they raise MissingOptionalDependencyError with the extra name,
purpose, commercial flag, and licensing note instead of importing a heavyweight
dependency during package import. Native-bounded adapters carry no third-party
dependency and solve small instances exactly by their own bounded search —
enumerating precedence-feasible orders in one case, decision-diagram branch and
bound in the other — raising UnsupportedCapabilityError when the instance
exceeds the supported task count.
| Solver | Method | Backend | Extra | Commercial |
|---|---|---|---|---|
ortools-cp-sat | CP-SAT | ortools | exact | no |
pulp-milp | MILP / MIP | pulp | exact | no |
branch-and-bound | branch-and-bound / cut | ortools | exact | no |
logic-based-benders-decomposition | logic-based Benders decomposition | pulp | exact | no |
exhaustive-enumeration | exhaustive enumeration | native (no backend) | — | no |
decision-diagram-sequencing | decision-diagram branch and bound | native (no backend) | — | no |
gurobi-exact | MILP / MIP | gurobipy | exact-commercial | yes |
The public exact handful is the representative open set — CP-SAT, MILP,
branch-and-bound, and logic-based Benders decomposition — plus the two native
bounded solvers and the genuinely invoking Gurobi wrapper. The commercial
Gurobi wrapper stays behind the exact-commercial
extra, is never bundled, and carries an explicit licensing note; an academic
license is available. A broader pool of optional backends stays registered for
internal use.
Selection And Learning Layer
The selection layer ranks solvers for a problem without ever claiming a globally
best solver. It consumes a SelectionFeatures record — difficulty,
heterogeneity, objective_conflict, uncertainty, dynamism, and
solver_sensitivity — and public solver metadata, and returns ranked
SolverRecommendation rows. Each recommendation carries a RecommendationSource
(metadata or learned-model), a ConfidenceLabel, and explicit limitation
notes, so a metadata recommendation is never mistaken for a learned one.
FEATURE_ORIGIN traces every feature to the benchmark characterization metric it
reads; the consumer maps dispatchatlas.bench characterization metrics into the
feature contract, so dispatchatlas.solve still imports dispatchatlas.core
only. Two selectors ship: RuleBasedSelector ranks from declared capabilities
and characterization alone (a metadata recommendation), and SupervisedSelector
ranks from a labeled corpus by a deterministic distance-weighted
nearest-neighbor model (a learned-model recommendation).
The supervised selector reports held-out generalization, never training fit. The
cross-validation protocol partitions a labeled corpus so that no instance, no
benchmark family, and no characterization record appears in both the training and
the test partition (partition_by_families, leave_one_family_out,
leakage_report), trains on the remaining families, and scores the held-out
family (held_out_generalization, cross_validate). Its confidence rises above
metadata-only solely when a leakage-free held-out evaluation supports it.
learning_interface_catalog() registers seven named learning and hybrid
interfaces — supervised algorithm selection, surrogate-assisted search,
reinforcement-learning hooks, hyper-heuristics, policy-guided repair, learned
initialization, and a benchmark-only baseline. Each declares a
LearningEvidencePolicy (training data, leakage controls, reproducibility,
evidence class, evidence-tier eligibility). Two are implemented here; the other five are
registered deferred interfaces whose realization is gated on the comparative
campaigns that produce training data. Heavy estimator backends stay behind the
optional learning extra and are probed by import root, never imported during
package import; absence raises MissingOptionalDependencyError while the
deterministic fallback remains available.
Performance Safeguards
Batch scoring is explicit through BatchScoringProfile. The current kernel uses
a standard-library fallback and records that fallback in diagnostics. This keeps
the API ready for vectorized or accelerated kernels while preserving a tested,
portable path.