Système de solveurs
dispatchatlas.solve possède les métadonnées de solveurs, la sélection, la construction
d'ordonnancements, la réparation, les garde-fous de performance, les familles de référence,
les adaptateurs optionnels, et la famille NDSO.
Le paquet importe dispatchatlas.core uniquement. Les tests d'intégration de test de
benchmarks vivent dans tests/solve/ afin que le paquet d'exécution ne dépende pas de
générateurs de benchmarks concrets.
Exemple exécutable : examples/compare_solvers.py ordonnance une cohorte de solveurs en parallèle et l'ancre avec un optimum exact prouvé.
Registre
SolverRegistry stocke des fabriques de solveurs sans état avec des métadonnées riches :
- des étiquettes de capacité comme
capacity-aware,precedence-aware,repair,local-search, etndso - des objectifs pris-en-charge comme
makespan,energy, etcost - des contraintes déclarées exprimées via des étiquettes de capacité
- des critères d'arrêt par défaut
- un comportement de rejeu déterministe ou stochastique-ensemencé
- un encodage de solution (
permutation,mapping,assignment, ounative) - des déclarations de dépendance optionnelle et la divulgation de backend commercial
- une visibilité de niveau-de-preuve pour les exports par étapes
- une citation canonique, ou une justification explicite de citation-non-applicable
Chaque famille de solveur nommée porte une citation qui échoue en position fermée : une famille avec une origine séminale canonique qui omet sa référence ne peut être construite, et une famille sans origine canonique unique enregistre la raison plutôt que d'en fabriquer une.
from dispatchatlas.solve import SolverCapability, default_solver_registry
registry = default_solver_registry()
metaheuristics = registry.select(
required_capabilities=(SolverCapability.METAHEURISTIC,),
objective="makespan",
)Catalogue du registre
Chaque solveur du registre, dans une seule table triable et cherchable. La table et ses
totaux sont générés à partir de default_solver_registry(), de sorte que les comptes
ci-dessous sont dénombrables depuis les lignes elles-mêmes. Un graphique de
couverture-des-capacités au-dessus de la table résume combien de solveurs du registre
déclarent chaque capacité déclarée.
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.
Applicabilité des solveurs
Quels solveurs s'appliquent à quelle famille de référence, lu depuis la matrice d'applicabilité. Chaque cellule est une applicabilité déclarée, jamais une affirmation de performance : les cellules vérifiées citent une campagne publique, une citation ou un test nommé, et les cellules approximatives sont dérivées des capacités déclarées du solveur et des traits de la famille de référence. Le tableau ci-dessous est généré à partir du paquet public d'applicabilité, de sorte que ses totaux de statut sont dénombrables à partir des lignes elles-mêmes.
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.
Lignes-de-base d'ordonnancement
Les lignes-de-base déterministes empaquetées sont des solveurs constructifs d'ordonnancement-par-listes. Chacun contrôle l'ordre des tâches ; le constructeur série honore les demandes de ressources déclarées de chaque tâche et affecte chaque tâche à sa ressource demandée disponible-au-plus-tôt. Chaque famille nomme sa référence séminale canonique.
| Solveur | Base de priorité | Référence canonique |
|---|---|---|
earliest-start | ordre topologique d'entrée | non applicable (ligne-de-base identité) |
shortest-processing-time | tâche de durée la plus courte d'abord | Smith (1956) |
longest-processing-time | tâche de durée la plus longue d'abord | Graham (1969) |
earliest-deadline | deadline le plus tôt d'abord (conscient-du-deadline) | Jackson (1955) |
earliest-finish-time | fin atteignable la plus tôt d'abord | Topcuoglu et al. (2002) |
minimum-slack | plus petite marge d'ordonnancement d'abord | Conway, Maxwell & Miller (1967) |
greedy-completion | achèvement conscient-de-l'état le plus tôt d'abord | Graham (1966) |
apparent-tardiness-cost | indice de coût-de-retard-apparent le plus élevé d'abord (conscient-du-deadline) | Vepsalainen & Morton (1987) |
Familles d'ordonnancement retirées
Les familles de mapping-de-ressources sont enregistrées explicitement plutôt que repliées silencieusement dans un type générique. Elles contrôlent l'affectation des ressources, non l'ordre des tâches, et le constructeur série respectueux-des-demandes n'expose aucune décision de mapping libre sous le modèle de problème cœur actuel :
- Mapping de ressources (
olb,met,mct,round-robin,load-balanced) : le constructeur affecte chaque tâche à sa ressource déclarée, de sorte que ces heuristiques n'ont aucun degré de liberté réalisable ; le mapping conscient-du-temps-d'exécution est la propriété du travail sur les objectifs et contraintes, non de cette fondation. - Étiquettes de type absentes (
type-aware,domain-aware) : requièrent des étiquettes de type-de-tâche et type-de-ressource que le modèle de problème cœur actuel ne porte pas.
retired_dispatching_families() renvoie le grand-livre complet avec justification et
citation par-famille.
Ordonnanceurs par listes basés sur le rang
Trois ordonnanceurs par listes conscients-de-l'hétérogénéité partagent une forme à deux phases : une phase de priorisation statique classe chaque tâche sur le DAG de précédence à partir des temps d'exécution moyens et des coûts de communication, et une phase de sélection-de-processeur lie chaque tâche dans l'ordre de priorité via la règle de fin-la-plus-tôt du constructeur série. Les temps d'exécution par-ressource proviennent des modes d'exécution déclarés d'une tâche moldable, et une tâche rigide dégénère en la spécialisation homogène documentée.
| Solveur | Base de priorité | Référence canonique |
|---|---|---|
heft | rang ascendant | Topcuoglu, Hariri & Wu (2002) |
cpop | rang ascendant-plus-descendant combiné, tâches du chemin-critique d'abord | Topcuoglu, Hariri & Wu (2002) |
peft | rang de table-de-coût-optimiste | Arabnejad & Barbosa (2014) |
Règles de mapping de l'ensemble-prêt
Trois règles de mapping par lots notent chaque tâche prête-en-précédence par son achèvement
le plus tôt sur ses liaisons candidates, puis mappent une tâche par étape. Les règles publiées
mappent un lot de tâches indépendantes ; ici le lot est l'ensemble des tâches
prêtes-en-précédence, de sorte que les règles s'étendent aux charges de travail dépendantes et
se réduisent au comportement publié sur les instances à tâches-indépendantes. Ces familles ont
quitté le grand-livre des retirées pour un enregistrement de premier-rang une fois que les
TaskSpec.modes moldables ont rendu représentable leur matrice d'achèvement-attendu
par-machine.
| Solveur | Base de priorité | Référence canonique |
|---|---|---|
min-min | plus petit meilleur achèvement d'abord | Ibarra & Kim (1977); Braun et al. (2001) |
max-min | plus grand meilleur achèvement d'abord | Ibarra & Kim (1977); Braun et al. (2001) |
sufferage | plus grand écart d'achèvement deuxième-meilleur-moins-meilleur d'abord | Maheswaran et al. (1999) |
Lignes-de-base iterated-greedy, tabu, et RCPSP
Trois méthodes publiées à solution-unique cherchent l'espace des ordres-de-tâches
sûrs-en-précédence, chacune projetant son mécanisme canonique sur la couture ordre-exécution
partagée. serial-sgs-justification est le premier solveur d'ordonnancement-de-projet
sous-contrainte-de-ressources (RCPSP) de la plateforme.
| Solveur | Mécanisme | Référence canonique |
|---|---|---|
iterated-greedy-rs | amorce NEH avec une boucle de destruction-reconstruction et acceptation à température-fixe | Ruiz & Stutzle (2007) |
critical-path-tabu | recherche tabou avancée sur les mouvements de blocs du chemin-critique | Nowicki & Smutnicki (2005) |
serial-sgs-justification | décodage par schéma-de-génération-d'ordonnancement série avec double justification droite-puis-gauche | Valls, Ballestin & Quintanilla (2005) |
Lignes-de-base métaheuristiques
Les lignes-de-base métaheuristiques ensemencées représentatives partagent les mêmes opérateurs de faisabilité, réparation, notation, et recherche-locale, chacune avec sa référence canonique : genetic algorithm (Holland 1975), simulated annealing (Kirkpatrick et al. 1983), ant colony (Dorigo, Maniezzo & Colorni 1996), particle swarm (Kennedy & Eberhart 1995), et differential evolution (Storn & Price 1997).
Solveurs adaptateurs encodés
La comprehensive learning particle swarm optimization et la success-history adaptive differential evolution cherchent un vecteur continu à valeurs-réelles avec une composante par tâche. Chaque cœur est générique sur un objectif continu, de sorte que son comportement de convergence est validé directement sur un benchmark continu, et est lié au problème d'ordonnancement via un adaptateur d'encodage qui décode un vecteur en un ordre de tâches faisable-en-précédence.
| Solveur | Inspiration | Adaptation | Encodage |
|---|---|---|---|
clpso | Comprehensive learning particle swarm (Liang et al. 2006) | Essaim continu décodé en un ordre de précédence | random-key |
d-clpso | Comprehensive learning particle swarm (Liang et al. 2006) | Adaptateur discret sur le décodage smallest-position-value | spv |
lshade | Success-history adaptive DE avec réduction linéaire de population (Tanabe & Fukunaga 2014) | Differential evolution continue décodée en un ordre de précédence | random-key |
d-lshade | Success-history adaptive DE avec réduction linéaire de population (Tanabe & Fukunaga 2014) | Adaptateur discret sur l'arrondi de rang-entier | rounding |
CLPSO apprend chaque dimension à partir d'un exemplaire de comprehensive-learning plutôt que d'un unique meilleur-global, de sorte que la meilleure aptitude de l'essaim s'améliore monotonement sur un bassin unimodal. L-SHADE adapte les mémoires de croisement et de facteur-d'échelle depuis son historique de succès et réduit la population linéairement jusqu'à un minimum de quatre individus. Les deux rapportent une trajectoire de convergence, et un test de convergence-correcte échoue lorsque la trajectoire observée contredit le comportement de référence publié, séparé des vérifications de reproductibilité-de-graine.
Ces solveurs sont des optimiseurs continus adaptés à un domaine discret via un pont d'encodage ; ce ne sont pas des réimplémentations exactes d'un quelconque code antérieur, et aucune affirmation de performance n'est faite avant que les campagnes comparatives ne s'exécutent.
Adaptateurs d'encodage
Chaque encodage continu-à-discret nommé est un adaptateur distinct avec une politique de réparation explicite, de sorte qu'aucun encodage n'est replié silencieusement dans un décodeur générique. Chaque adaptateur répare son ordre décodé en un ordre faisable-en-précédence et enregistre si la réparation s'est déclenchée.
| Adaptateur | Transfert | Règle de décodage | Statut de citation |
|---|---|---|---|
random-key | identité | trier par clé bornée | canonique (Bean 1994) |
spv | identité | smallest position value | canonique (Tasgetiren et al. 2007) |
rounding | identité | créneaux de rang-entier | non-applicable |
sigmoid | sigmoïde en-S | tirage probabiliste pondéré | canonique (Kennedy & Eberhart 1997) |
v-shaped | magnitude en-V | tirage probabiliste pondéré | canonique (Mirjalili & Lewis 2013) |
tanh | tangente hyperbolique décalée | tirage probabiliste pondéré | canonique (Mirjalili & Lewis 2013) |
Les décodages déterministes (random-key, spv, rounding) ignorent la source aléatoire ;
les décodages de fonction-de-transfert consomment une source ensemencée et se rejouent sous
une graine fixe. L'adaptateur rounding enregistre citation-non-applicable car l'arrondi de
rang à-l'entier-le-plus-proche est une discrétisation générique sans origine séminale
canonique unique.
Ensemble diversifié de concurrents
L'ensemble diversifié de concurrents élargit la comparaison au-delà des lignes-de-base représentatives avec une petite poignée de pairs récents et forts, chacun un solveur nommé avec sa référence texte-intégral projetée sur l'espace de décision ordre-uniquement, plutôt qu'une liste volumineuse de lignes-de-base classiques. Un pair ne reste sur le terrain public que lorsqu'il franchit une barre de force-de-lieu : publié dans la fenêtre de validité post-2020 dans un lieu indexé et évalué-par-les-pairs, avec le niveau du lieu enregistré pour qu'un lecteur le pondère sur la preuve plutôt que sur le prestige.
| Solveur | Mécanisme | Lieu | Citation |
|---|---|---|---|
epso | Essaim à initialisation-biaisée-par-charge avec rassemblement de chemins | Electronics (MDPI), 2023 — indexé | Anbarkhan & Rakrouki (2023) |
adpso | Recherche par essaim à inertie descendante adaptative-au-succès | Sensors (MDPI), 2022 — indexé | Nabi et al. (2022) |
ccgp | Coévolution coopérative d'arbres de règles-de-priorité | Computers & Operations Research (Elsevier), 2024 — OR de premier-rang | Zaki et al. (2024) |
Chaque pair porte des forces, des mises-en-garde, et une classe de preuve de ligne-de-base-exécutable dans ses métadonnées afin que le recommandeur puisse expliquer pourquoi un solveur convient à un contexte. Un ensemble plus large de lignes-de-base classiques — genetic algorithms à clé-entière, biased-random-key, et estimation-of-distribution, et recherches large-neighborhood, iterated greedy, tabu, variable-neighborhood, et memetic — reste enregistré pour comparaison interne mais est tenu hors du terrain public, puisque les heuristiques représentatives portent déjà leur signal de mécanisme. Aucune affirmation de performance n'est faite avant que les campagnes comparatives ne s'exécutent.
Ancre de validité
L'ensemble de concurrents et de travaux-connexes est positionné contre les travaux de la décennie-actuelle via une ancre de validité post-2020 : Karimi-Mamaghan, Mohammadi, Pasdeloup, et Meyer (2023, apprendre à sélectionner des opérateurs via Q-learning intégré dans iterated greedy pour le permutation flowshop, European Journal of Operational Research 304(3):1296-1330, doi:10.1016/j.ejor.2022.03.054) et l'algorithme évolutionnaire multi-objectif collaboratif guidé-par-indicateur de 2024 IEEE Transactions on Evolutionary Computation pour l'ordonnancement de groupes de distributed flowshop (doi:10.1109/TEVC.2023.3339558).
Concurrents multi-objectifs
Deux concurrents Pareto font évoluer une population d'ordres de tâches sûrs-en-précédence sur
un vecteur multi-objectif, distincts de la surface de nombreux-objectifs nsga3. nsga2 est
le concurrent basé-sur-la-dominance — tri rapide des non-dominés avec départage par
distance-de-foule — et moead est le contrepoids basé-sur-la-décomposition, scindant le
problème en sous-problèmes scalaires de Tchebycheff le long d'une grille de poids simplexe
structurée et remplaçant les titulaires à travers le voisinage de poids-le-plus-proche de
chaque sous-problème.
| Solveur | Mécanisme | Référence canonique |
|---|---|---|
nsga2 | Pareto basé-sur-la-dominance : tri rapide des non-dominés, distance de foule | Deb et al. (2002) |
moead | Pareto basé-sur-la-décomposition : scalarisation de Tchebycheff sur une grille de poids simplexe | Zhang & Li (2007) |
Concurrent de nombreux-objectifs
nsga3 est le concurrent de nombreux-objectifs nommé (Deb & Jain 2014,
doi:10.1109/TEVC.2013.2281535), distinct de la surface de concurrent bi-objectif. Il maintient
une population sur des ordres de tâches sûrs-en-précédence, évalue chaque ordre sur un vecteur
multi-objectif (makespan, retard, et équité de charge), et survit à chaque génération par une
sélection par nichage de points-de-référence sur des points-de-référence structurés de Das &
Dennis sur le simplexe unitaire. La conception des points-de-référence, l'association des
solutions à leur direction de référence la plus proche, et la sélection par
comptage-de-niche sont la signature algorithmique ; le solveur déclare la capacité
many-objective aux côtés de multi-objective afin qu'une campagne puisse le sélectionner
explicitement.
Appariement de capacités
SolverRegistry.select apparie les solveurs par capacité, contrainte, et objectif. Les
exigences de capacité et de contrainte sont toutes deux exprimées comme des étiquettes de
capacité et appariées comme une conjonction : une campagne de nombreux-objectifs qui a aussi
besoin de conscience-de-deadline passe required_capabilities=(SolverCapability.MANY_OBJECTIVE,)
et required_constraints=(SolverCapability.DEADLINE_AWARE,), et le registre renvoie
uniquement les solveurs qui déclarent les deux. Un filtre objective restreint en outre le
résultat aux solveurs qui déclarent le support de cet objectif nommé.
Famille NDSO
La famille NDSO est la famille de solveurs à encodage-natif du registre : elle cherche
directement sur des ordonnancements faisables. Chaque ordonnancement qu'elle produit est
faisable par construction (un constructeur valide-par-conception construit un ordre
respectueux-de-précédence à chaque étape), de sorte que la famille porte l'encodage native
et n'exécute jamais une étape d'encodage/décodage ni une passe de réparation. La famille
compose un petit ensemble de mécanismes nommés :
- Confidence Matrix — un magasin clairsemé de confiance apprise par cellule (position, tâche), mis à jour à mesure que de meilleurs ordonnancements renforcent leurs cellules.
- Confidence-Weighted Voting — synthétise l'ordonnancement élite en votant à travers la population pondérée par la Confidence Matrix ; la variante rapide utilise un vote de majorité non-pondéré à la place.
- Ordonnancements Quantity-and-Quality — l'ordonnancement Quantity fixe combien un candidat change ; l'ordonnancement Quality fixe de quelle source de guidage il apprend.
- Guidage à trois-sources — un candidat apprend de l'élite synthétisé (exploitation), d'un pair (diversité), ou d'une source de connaissance-évanouie (exploration radicale).
- Coefficient adaptatif unifié — un ordonnancement non-linéaire fait glisser la famille de l'exploration vers l'exploitation et pilote à la fois la sensibilité et le foyer d'apprentissage ; la variante rapide le fixe à une valeur fixe.
| Variante | Composition |
|---|---|
ndso-core | Confidence-Weighted Voting, coefficient adaptatif, guidage à trois-sources |
ndso-fast | synthèse par vote-de-majorité, coefficient fixe, source de guidage unique |
ndso-summit | Conseil Inter-Essaim coordonnant plusieurs essaims avec synthèse surplombante |
Conseil Inter-Essaim
La variante ndso-summit est la composition de qualité : elle exécute plusieurs essaims en
parallèle et les coordonne via un seul conseil. Chaque essaim compose les mécanismes cœur sur
sa propre population ; le conseil Inter-Essaim maintient ces essaims travaillant comme une
seule recherche plutôt que plusieurs exécutions isolées et synthétise leurs résultats en un
unique élite surplombant — l'ordonnancement que tout le sommet soutient. Le conseil est ce
qui distingue la variante au premier coup d'œil : ndso-core et ndso-fast cherchent chacun
avec une population, tandis que ndso-summit est la composition construite pour la recherche
multi-essaim coordonnée.
Le comportement de coordination du conseil et les diagnostics par-essaim sont configurables, et chaque ordonnancement qu'il produit reste faisable par construction.
Carte d'ablation
La carte d'ablation énumère une configuration isolante par mécanisme nommé afin que l'analyse en aval puisse attribuer la contribution de chaque mécanisme. Les entrées intra-essaim désactivent chacune un interrupteur cœur — la Confidence Matrix, la Confidence-Weighted Voting, l'ordonnancement Quantity, l'ordonnancement Quality, la structure de guidage multi-source, la source pair, la source de connaissance-évanouie, et le coefficient adaptatif. Les entrées de coordination désactivent chacune un paramètre du conseil — la coordination Intra- versus Inter-Essaim et la synthèse surplombante. Chaque entrée déclare le plancher de comptage-d'exécutions auquel la couche d'analyse échantillonne sa comparaison et nomme les tests statistiques que cette couche applique (un test de significativité non-paramétrique apparié, un post-hoc de rang-moyen de Friedman avec une correction de comparaison-multiple de Holm, et une taille-d'effet Cliff's-delta). La comparaison échantillonnée est matérialisée par le moteur d'expériences en aval ; l'exécuteur en-processus prouve que chaque isolation est faisable.
Un filtre d'export par-étapes gouverne quels mécanismes une portée de rapport peut exposer : la portée de base expose uniquement les mécanismes fondationnels, et un gate fail-closed lève plutôt que de fuiter un mécanisme plus-rapide ou de plus-haute-qualité sous une portée de base, de sorte que les portées fondationnelle et rapide ne peuvent exposer les mécanismes réservés-au-conseil. Les diagnostics de convergence — diversité de population, entropie de la Confidence-Matrix, ratio d'exploration, charge de ressources, chronométrage, et la trace d'amélioration — sont optionnels et n'ajoutent aucune surcharge quand ils sont désactivés, et le conseil exporte un manifeste JSON que la couche d'analyse ingère sans importer aucun type de solveur.
Adaptateurs exacts
Les adaptateurs exacts prennent l'une de deux formes. Les adaptateurs de backend-optionnel
déclarent une dépendance optionnelle et vérifient sa racine d'importation à l'exécution ; si
le backend est absent ils lèvent MissingOptionalDependencyError avec le nom de l'extra, le
but, le drapeau commercial, et la note de licence plutôt que d'importer une dépendance lourde
durant l'importation du paquet. Les adaptateurs natifs-bornés ne portent aucune dépendance
tierce et résolvent exactement les petites instances par leur propre recherche bornée — en
énumérant des ordres faisables-en-précédence dans un cas, branch-and-bound par
diagramme-de-décision dans l'autre —, levant UnsupportedCapabilityError lorsque l'instance
dépasse le compte de tâches pris-en-charge.
| Solveur | Méthode | Backend | Extra | Commercial |
|---|---|---|---|---|
ortools-cp-sat | CP-SAT | ortools | exact | non |
pulp-milp | MILP / MIP | pulp | exact | non |
branch-and-bound | branch-and-bound / cut | ortools | exact | non |
logic-based-benders-decomposition | décomposition de Benders basée-sur-la-logique | pulp | exact | non |
exhaustive-enumeration | énumération exhaustive | natif (sans backend) | — | non |
decision-diagram-sequencing | branch-and-bound par diagramme-de-décision | natif (sans backend) | — | non |
gurobi-exact | MILP / MIP | gurobipy | exact-commercial | oui |
La poignée exacte publique est l'ensemble ouvert représentatif — CP-SAT, MILP,
branch-and-bound, et décomposition de Benders basée-sur-la-logique — plus les deux solveurs
natifs bornés et le wrapper Gurobi authentiquement invoquant.
Le wrapper commercial Gurobi reste derrière l'extra exact-commercial, n'est jamais empaqueté,
et porte une note de licence explicite ; une licence académique est disponible. Un pool plus
large de backends optionnels reste enregistré pour usage interne.
Couche de sélection et d'apprentissage
La couche de sélection classe les solveurs pour un problème sans jamais affirmer un solveur
globalement meilleur. Elle consomme un enregistrement SelectionFeatures — difficulty,
heterogeneity, objective_conflict, uncertainty, dynamism, et solver_sensitivity —
et les métadonnées publiques de solveur, et renvoie des lignes SolverRecommendation
classées. Chaque recommandation porte un RecommendationSource (metadata ou
learned-model), un ConfidenceLabel, et des notes de limitation explicites, de sorte
qu'une recommandation de métadonnées n'est jamais confondue avec une apprise.
FEATURE_ORIGIN trace chaque caractéristique jusqu'à la métrique de caractérisation de
benchmark qu'elle lit ; le consommateur mappe les métriques de caractérisation de
dispatchatlas.bench dans le contrat de caractéristiques, de sorte que dispatchatlas.solve
importe toujours dispatchatlas.core uniquement. Deux sélecteurs sont livrés :
RuleBasedSelector classe depuis les capacités déclarées et la caractérisation seule (une
recommandation de métadonnées), et SupervisedSelector classe depuis un corpus étiqueté par
un modèle déterministe de plus-proche-voisin pondéré-par-distance (une recommandation de
modèle-appris).
Le sélecteur supervisé rapporte la généralisation hors-échantillon, jamais l'ajustement
d'entraînement. Le protocole de validation-croisée partitionne un corpus étiqueté de sorte
qu'aucune instance, aucune famille de benchmark, et aucun enregistrement de caractérisation
n'apparaisse dans les deux partitions d'entraînement et de test (partition_by_families,
leave_one_family_out, leakage_report), s'entraîne sur les familles restantes, et note la
famille retenue (held_out_generalization, cross_validate). Sa confiance s'élève au-dessus
de métadonnées-seules uniquement lorsqu'une évaluation retenue exempte-de-fuite la soutient.
learning_interface_catalog() enregistre sept interfaces d'apprentissage et hybrides nommées
— sélection d'algorithme supervisée, recherche assistée-par-substitut, hooks
d'apprentissage-par-renforcement, hyper-heuristiques, réparation guidée-par-politique,
initialisation apprise, et une ligne-de-base benchmark-uniquement. Chacune déclare une
LearningEvidencePolicy (données d'entraînement, contrôles de fuite, reproductibilité,
classe de preuve, éligibilité de niveau-de-preuve). Deux sont implémentées ici ; les cinq
autres sont des interfaces différées enregistrées dont la réalisation est conditionnée aux
campagnes comparatives qui produisent des données d'entraînement. Les backends d'estimateur
lourds restent derrière l'extra optionnel learning et sont sondés par racine d'importation,
jamais importés durant l'importation du paquet ; l'absence lève
MissingOptionalDependencyError tandis que le repli déterministe reste disponible.
Garde-fous de performance
La notation par lots est explicite via BatchScoringProfile. Le kernel actuel utilise un
repli de bibliothèque-standard et enregistre ce repli dans les diagnostics. Cela maintient
l'API prête pour des kernels vectorisés ou accélérés tout en préservant un chemin testé et
portable.