Movement planner: should it ever decline a combination when startup is too slow for a spike? #1

New Issue

vps1_gitea_admin · 2026-05-15T14:15:24Z

vps1_gitea_admin commented

2026-05-15 14:15:24 +00:00

Context

As part of the timing-aware movement-planner design (rendezvous-on-demand-at-current-pressure, see conversation 2026-05-15 with Rene), an open question was flagged for future consideration.

The question

When the optimizer picks bestCombination and the planner sees that delivering it requires starting a machine whose startingS + warmingupS + accelTime is large (e.g. several minutes), should the MGC:

(current behaviour, and the chosen behaviour for the first cut): always commit to the optimal combination and schedule it as best it can — the demand simply lands a bit late, header pressure absorbs the transient safely; or
decline and fall back to a worse-but-faster combination (e.g. push existing-online pumps harder, accept lower efficiency for a faster rendezvous)?

Why we deferred it

The first-cut planner targets correctness of the rendezvous math under the current optimizer's pick. Layering a "speed vs efficiency" trade-off on top of that is a second optimization problem and risks coupling the planner to the optimizer's internals.
The safe-undershoot property of the rendezvous-at-current-pressure objective (pressure-rise self-corrects flow downward, never upward) means a slow rendezvous is not unsafe — just slower.
Real wastewater demand transients are slow enough (minutes-scale) that startup-bound rendezvous is acceptable for most operating points.

When to revisit

If a customer / process owner says "we need rendezvous in N seconds for demand spikes of magnitude X" and the slowest available combination exceeds N, this becomes load-bearing.
If we ever add fast-acting actuators (VFD-driven valves, accumulators) into the same MGC group as slow-start pumps, the asymmetry might justify a speed-priority mode alongside the existing optimalControl / priorityControl modes.

Design conversation: 2026-05-15 with Rene
First-cut planner modules already landed (uncommitted): src/movement/machineProfile.js, src/movement/moveTrajectory.js, src/state/stateManager.js (added stateEnteredAt + getRemainingTransitionS() in generalFunctions)
Next-up modules: src/movement/movementScheduler.js, src/movement/movementExecutor.js

Tags

future-consideration, planner, optimizer-coupling

## Context As part of the timing-aware movement-planner design (rendezvous-on-demand-at-current-pressure, see conversation 2026-05-15 with Rene), an open question was flagged for future consideration. ## The question When the optimizer picks `bestCombination` and the planner sees that delivering it requires starting a machine whose `startingS + warmingupS + accelTime` is large (e.g. several minutes), should the MGC: - (current behaviour, and the chosen behaviour for the first cut): **always commit** to the optimal combination and schedule it as best it can — the demand simply lands a bit late, header pressure absorbs the transient safely; **or** - **decline and fall back** to a worse-but-faster combination (e.g. push existing-online pumps harder, accept lower efficiency for a faster rendezvous)? ## Why we deferred it - The first-cut planner targets correctness of the rendezvous math under the current optimizer's pick. Layering a "speed vs efficiency" trade-off on top of that is a second optimization problem and risks coupling the planner to the optimizer's internals. - The safe-undershoot property of the rendezvous-at-current-pressure objective (pressure-rise self-corrects flow downward, never upward) means a slow rendezvous is not unsafe — just slower. - Real wastewater demand transients are slow enough (minutes-scale) that startup-bound rendezvous is acceptable for most operating points. ## When to revisit - If a customer / process owner says "we need rendezvous in N seconds for demand spikes of magnitude X" and the slowest available combination exceeds N, this becomes load-bearing. - If we ever add fast-acting actuators (VFD-driven valves, accumulators) into the same MGC group as slow-start pumps, the asymmetry might justify a speed-priority mode alongside the existing `optimalControl` / `priorityControl` modes. ## Related work - Design conversation: 2026-05-15 with Rene - First-cut planner modules already landed (uncommitted): `src/movement/machineProfile.js`, `src/movement/moveTrajectory.js`, `src/state/stateManager.js` (added `stateEnteredAt` + `getRemainingTransitionS()` in generalFunctions) - Next-up modules: `src/movement/movementScheduler.js`, `src/movement/movementExecutor.js` ## Tags future-consideration, planner, optimizer-coupling

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RnD/machineGroupControl#1