feat: fixed (no-load / commitment) cost per operation mode#2327
Open
Flix6x wants to merge 1 commit into
Open
Conversation
Based on #2278 (operation-mode power bands). Operation modes constrain a device's power to signed bands but carry no fixed cost. Real unit-commitment has a no-load / commitment cost incurred only while a unit is on (e.g. a cogeneration unit's full-speed-no-load fuel burn). Without it, an LP/MILP that can idle a unit under-represents the cost of staying on at low output. Adds an optional per-mode `fixed-cost` (per timestep, in the flex-context currency), incurred whenever that mode's binary is active: - schema: OperationModeSchema.fixed-cost, parsed to a currency Quantity; - objective: sum over (d,b,j) of device_band[d,b,j] * fixed_cost[d,b], threaded through device_scheduler as device_band_fixed_costs, mirroring the power bands; - tests: a generator idles when marginal benefit < fixed cost, and the objective includes the fixed cost exactly when on (hand-computed); - docs: changelog + metadata field. Min-up / min-down time is out of scope (follow-up). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016MLCUiSdXDqDBmg8GbYp1B
Documentation build overview
48 files changed ·
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on #2278 (operation-mode power bands).
The gap
Operation modes (#2113 / #2278) constrain a device's power to a set of signed bands, but carry no fixed cost. Real unit-commitment has a no-load / commitment cost incurred only while a unit is on — e.g. a cogeneration unit's full-speed-no-load fuel burn, or a fixed per-timestep running cost. Without it, an LP/MILP that can idle a unit still under-represents the cost of keeping it running at low output, so the schedule and objective diverge from the true unit-commitment optimum by the no-load term.
What this adds
An optional
fixed-costper operation mode, incurred at every time step during which that mode's binary is active.operation-modesentry may carry"fixed-cost": "1200 EUR"(per time step, in the flex-context currency). Absent ⇒ 0, so existing behaviour is unchanged. Kept in its native currency and converted to the flex-context's shared currency by the scheduler.Σ_{d,b,j} device_band[d,b,j] · fixed_cost[d,b]to the cost expression, threaded throughdevice_schedulervia a newdevice_band_fixed_costsargument, mirroring how the power bands themselves are threaded.StorageScheduler(device_constraints[d].attrs) todevice_scheduler, alongside the existingoperation_modeshandling.fixed-cost— asserts the unit idles when its marginal benefit is below the fixed cost, and that the objective includes the fixed cost exactly when on (hand-computed on a 2-step instance).Min-up / min-down time is intentionally out of scope (follow-up).
🤖 Generated with Claude Code