API Reference

Superfluous Load Avoidance Release (SLAR) policy.

Implements the SLAR algorithm from Land & Gaalman (1998) extended with a starvation-avoidance sub-trigger. On every job-completion event at a server, _consider_release evaluates three branches (in order):

1. Idle prevention (paper rule): if the server queue is empty, release the most urgent PSP candidate (lowest PST) to prevent the server from idling.
2. Urgent insertion (paper rule): if no queued job is urgent (negative PST) but the PSP holds an urgent candidate, release the urgent candidate with the shortest processing time to minimise disruption to the queue. Skipped if an urgent job is already in the queue — the priority rule will dispatch it next.
3. Drain safety net (extension): if exactly one job remains in the queue, schedule a postponed release of the most urgent PSP candidate so the queue is replenished before it drains. Mutually exclusive with (2): if (2) fires, (3) does not, to avoid superfluous load.

Construction is active: the instance self-registers with shopfloor.on_processing_end and psp.on_arrival(starvation_avoidance), and (if a router is provided) sets router.priority_policies to the PST dispatching rule. This makes it impossible to forget the priority wiring that the algorithm depends on.

slar = Slar(
    shopfloor=shop_floor, psp=psp, router=router,
    allowance_factor=3.0,
)

Bases: Slar

SLAR augmented with a workload-norm limit on urgent insertion.

Identical to Slar except for the urgent-insertion branch:

• Classic SLAR releases the urgent PSP candidate (negative PST) with the shortest processing time, unconditionally.
• SLAR-Limit iterates urgent PSP candidates in ascending SPT order and releases the first whose corrected workload contribution PT / (i + 1) keeps every server in its routing at or below its configured norm. If no urgent candidate fits, the drain safety-net branch may still fire — same as in Slar.

The idle-prevention and drain-safety-net branches, the PST priority rule, and the postponed-release mechanism are inherited unchanged.

Requires CorrectedWIPStrategy on the shopfloor — the corrected contribution formula PT / (i + 1) only makes sense under that strategy. The strategy and the norm coverage are checked eagerly at construction.

from simulatte.policies.slar_limit import SlarLimit
from simulatte.shopfloor import CorrectedWIPStrategy

shop_floor.set_wip_strategy(CorrectedWIPStrategy())
slar_limit = SlarLimit(
    shopfloor=shop_floor, psp=psp, router=router,
    wl_norm={s: 5.0 for s in servers},
    allowance_factor=3.0,
)

Workload-based release policy using corrected WIP and planned release dates.

LUMS-COR controls job releases by: 1. Sorting PSP jobs by planned release date (earliest first) 2. Releasing a job only if adding it keeps each server's corrected WIP at or below its workload norm

The starvation release complements periodic releases by immediately releasing jobs when servers become idle or nearly idle.

Requires CorrectedWIPStrategy on the shopfloor, which accounts for downstream workload when computing WIP at each server.

from simulatte.policies.triggers import periodic_trigger, on_completion_trigger

lumscor = LumsCor(wl_norm={server: 10.0}, allowance_factor=2)
shopfloor.set_wip_strategy(CorrectedWIPStrategy())
psp = PreShopPool(env=env, shopfloor=shopfloor)
env.process(periodic_trigger(psp, 1.0, lumscor.periodic_release))
env.process(on_completion_trigger(shopfloor, psp, lumscor.starvation_release))

Non-hierarchical DRACO release/dispatch policy.

Design note: DRACO is a class (not a dispatching-rule factory) because it holds shop-coupled state (the WIP target, per-pair loop targets, the embedded Focus, and the one-shot force flags) and exposes both a priority_policy and a decide_next_job (on_processing_end) callback.

Trigger: shopfloor.on_processing_end — the same mechanism SLAR uses. On every job exit from any server k, decide_next_job runs (with k passed directly by the callback) and selects the next job to be processed at k from Q_k ∪ P_k.

Active construction (like Slar.__init__): the instance self-wires every hook it depends on — it sets router.priority_policies to its priority_policy, registers decide_next_job on shopfloor.on_processing_end, and (when a psp is given) registers starvation_avoidance on psp.on_arrival. So build_draco_system stays a single Draco(...) line and a user wiring DRACO by hand cannot forget any of the three.

Strict paper semantics — "the winner is the next processed": DRACO scores Q_k ∪ P_k once per completion and the winner must be the next job processed at k. But priority_policy re-derives queue-side scores live on every sort_queue — and for multi-op jobs the queue-side context can shift between the decision and the dispatch (see Decision instant below) — so the order sort_queue produces is not guaranteed to match DRACO's decision. To make the decision authoritative, DRACO sets a _forced_at_server flag for the winner — whether it came from Q_k or P_k — and priority_policy returns -inf for that job at that server while the flag is set, guaranteeing queue[0] = winner across every sort_queue re-evaluation. A PSP winner additionally gets released onto the shop floor; a queue winner is already in Q_k and only needs the pin. The flag is cleared at the START of the next decide_next_job call for the same server (not on first read), so repeated _trigger_put sorts cannot wipe it out. (Correctness assumes a single freed slot per completion, i.e. capacity == 1, as in build_draco_system and the paper.)

Timing — why this is correct without any shopfloor.py changes: decide_next_job is wired via shopfloor.on_processing_end, so it runs synchronously inside shopfloor.main the moment the with server.request() block exits. By then server.release(req) has already removed the request from users (so count drops to 0) and scheduled a Release event (NORMAL), but that event has not yet been dequeued and no SimPy process-based listener has resumed. If DRACO releases a PSP winner via psp.shopfloor.add, the new process's Initialize event is URGENT (simpy/events.py) and therefore runs before the pending Release event; inside the new process, server.request calls _trigger_put synchronously, finds users empty, and grants the slot immediately. The Release event then fires with nothing to dispatch. Net result: the PSP winner has the server. For a queue winner there is no new process; that same Release event's _trigger_put calls sort_queue, which sees the forced -inf and pins the winner at queue[0] before granting the slot. Either way the callback fires before any event is dequeued, so correctness rests on event priority — URGENT Initialize before NORMAL Release for a PSP winner, and the live -inf for a queue winner — never on same-priority event-id ordering.

Decision instant: the callback fires before the just-finished job re-enters its next server's queue, so a multi-op triggering job is not part of the shop scan at decision time. Because DRACO force-pins the winner, dispatch follows the decision verbatim — there is no later sort_queue re-derivation to disagree with — so the R, A and D terms are all evaluated consistently at this single instant. (Whether the in-transit order should be counted at the decision instant is a literature-faithfulness question, of the same flavour as the build_context note on the O set; the consistency of decision and dispatch does not depend on the answer.)

Cold start / bootstrapping: DRACO's decision is triggered only on job completions. In an idle or lightly loaded shop, no completion fires, so an arriving job would sit in the PSP indefinitely. build_draco_system therefore also wires psp.on_arrival(starvation_avoidance): when a new arrival's first server is completely idle, the job is released immediately, bypassing the R/A/D scoring. This is a liveness provision, not a DRACO decision — in steady state, completion-triggered decisions dominate. (Faithfulness of this provision to Kasper et al. 2023 has not been verified against the primary source.)

Downstream auto-grant (no decision on routing-in): decide_next_job fires only on completion at a server. When a released job routes into an idle downstream server B while a P_B pool candidate waits, SimPy grants B to the arriving job immediately and DRACO never weighs pulling the pool candidate — a decision moment in the paper's sense passes without R/A/D scoring. Rare at the paper's ~90% utilization; not corrected here, noted for faithfulness (review §6.F).

Parameters:

FOCUS dispatching rule — weighted combination of five impact mechanisms.

The class is stateless beyond its weights. Computations are organised so each mechanism (pi, omega, psi, gamma, beta) is exposed independently for testability and for use as a building block by higher-level policies (DRACO).

All five mechanisms return values in [0, 1] with 1 indicating a "relevant" impact and 0 an "irrelevant" one. The aggregated score is the weighted average of the five pieces and also lies in [0, 1].

Design note: unlike the stateless dispatching-rule factories (e.g. planned_slack_time), FOCUS is a class because it exposes each mechanism as an independently testable method and a shared per-decision build_context consumed by higher-level policies (DRACO). A bare (job, server) -> float closure cannot expose these. Use FocusPriorityRule to adapt a Focus to the priority_policy contract.

Parameters:

w1 → SPT            → pi    → π   (FOCUS Eq-12 w1)
w2 → starvation     → omega → ξ   (FOCUS Eq-12 w3)
w3 → slack timing   → psi   → τ   (FOCUS Eq-12 w4)
w4 → pacing         → gamma → δ   (FOCUS Eq-12 w5)
w5 → WIP balancing  → beta  → β   (FOCUS Eq-12 w2)

FOCUS-π : (0.0,  0.25, 0.25, 0.25, 0.25)
FOCUS-β : (0.25, 0.25, 0.25, 0.25, 0.0 )   # the default
FOCUS-ξ : (0.25, 0.0,  0.25, 0.25, 0.25)
FOCUS-τ : (0.25, 0.25, 0.0,  0.25, 0.25)
FOCUS-δ : (0.25, 0.25, 0.25, 0.0,  0.25)

Example (inside DRACO — one ctx, many candidates): >>> focus = Focus(weights=(0.2, 0.2, 0.2, 0.2, 0.2)) >>> ctx = focus.build_context(shopfloor, env.now, psp=psp) >>> for candidate in candidates: ... d_score = focus.score(candidate, server_k, ctx, env.now)

Snapshot of shop-wide aggregates at a single decision instant.

Built once per decision via Focus.build_context and reused across all candidates being scored at that instant. Computing this object is O(|O| · |J|) (the |J| factor comes from the beta entropy pass; without beta the cost is O(|O|)).

Attributes:

Adapter exposing Focus as a simulatte priority_policy.

Wraps a Focus and a ShopFloor into a (job, server) -> float callable suitable for simulatte.router.Router.priority_policies. The returned value is the negated FOCUS score because simulatte's simpy.resources.resource.PriorityResource sorts ascending (lower key = served first).

Parameters: