[ArttuTupala]

Started by @ArttuTupala's observation that a multi-output indirect unit (e.g. a CHP) was limited by its fuel-input bound in dispatch-only solves but not in investment solves. Root-causing that uncovered a set of related capacity, min-load and reserve issues. They are fixed here together, plus a few things found along the way.

Capacity of indirect (multi-output) units

• New maxOutputSum constraint: unit capacity (existing + invested − retired) caps the sum of outputs, as the docs define it. Previously this was enforced only by accident, through the fuel-input bound, and only in dispatch-only solves.
• The fuel-input limit is no longer the capacity constraint. It is derived from the conversion equation, so it never binds artificially.
  • Units that can't invest or retire in the solve get a per-element variable bound (needs polar-high ≥ 3.8.0), which removes rows (coal_chp: 528 → 480 rows).
  • Units that can invest or retire keep a constraint row with a corrected investment multiplier.
• capacity_max_coeff and availability now apply to invested capacity in every capacity-style constraint (maxFlow, reverse flow, ramps, maxOutputSum). Before, they scaled only existing capacity: an output with coefficient 0.2 on a unit investing 900 MW could deliver 900 MW. This also fixes reverse flow on newly built connections and ramping of newly built units.
• Coefficient meanings clarified:
  • capacity_max_coeff = 0 means a zero cap.
  • conversion_flow_coeff = 0 means an uncapped edge (the hydro pass-through pattern).

Input shares (schema change)

• On unit__inputNode, capacity_max_coeff / capacity_min_coeff are renamed to input_share_max / input_share_min.
  • input_share_max (default 1): the largest share of the unit's full-load input this input may supply. A poorer heating value is handled by conversion_flow_coeff.
  • input_share_min (default 0): while the unit runs, this input supplies at least this share of the unit's input.
  • Invalid shares are errors: outside [0, 1], minimum shares summing above 1, or min > max.
• unit__outputNode keeps capacity_max_coeff. Its capacity_min_coeff becomes an optional extra per-output floor (default 0).

Minimum load and reserves

• Min load applies once per unit, on the sum of outputs. It used to apply on every arc, which forced every input of a multi-input unit to be used: a two-input CHP had to burn its expensive gas (objective 330M instead of 21M), a high-efficiency unit never ran, and an extraction CHP in pure-heat mode made unwanted electricity.
• Downward reserve can't take a unit below its minimum load.
• Reserve shortfall (vq_reserve) keeps its 0–1 scaling, but its multiplier is now the largest possible requirement of the group. Before, dynamic and n-1 groups without a reservation could fall short by at most 1 MW, and that 1 MW was free.
• penalty_reserve defaults to 5000 again. The default was lost in the v56 cleanup, which left reserve requirements without an authored penalty effectively optional.

Other bug fixes

• Part-load efficiency: indirect min_load_efficiency units were missing the section term, so their input, cost and CO2 were about 31 % too low at full load.
• Constant delay: a constant delay value silently stopped the unit. Rolling solves with any delayed unit crashed.
• Delayed inputs: input_share_max was not enforced on delayed inputs with conversion_flow_coeff > 1.
• Connection delay: delay on a connection silently changed the connection (it lost its losses, and a regular connection became one-way). Connection delay is not implemented, so it is now ignored with a warning.
• No-limit investment: invest_retire_no_limit was not recognised as "no limit", so the unit could not invest.
• Rolling roll loader: roll sub-solves ignored output capacity_max_coeff and uncapped edges.
• polars 2.0 warm-start fix: also released separately as 4.0.5 (release: 4.0.5 — polars 2.0 rolling warm-start fix #347); merged from main here.

Housekeeping

• Dependency caps: polars>=1.40,<3, pandas>=2.2.3,<4, spinedb-api>=0.36.5,<0.37, highspy>=1.14.0,<1.15 (allows patch releases).
• Weekly canary workflow (.github/workflows/canary.yml): installs the newest versions with the caps lifted, runs the tests, and keeps a "canary: dependency drift" issue updated.
• No more flextool.sol / glpsol warning: the GLPK-era solution file is no longer written. Old project highs.opt lines are ignored.

Schema / migration

• One self-contained, idempotent step: v70. It contains:
  • the input_share_* rename;
  • deletion of the old input-side min values, which no engine since v3.32 applied;
  • deletion, with a printed list, of out-of-range or v36-leftover output capacity_min_coeff values;
  • new defaults;
  • description fixes;
  • the penalty_reserve default.
• Generated files were rebuilt with the documented commands, and all verify commands pass.
• This PR merges before the stochastics branch, which will then renumber its own steps after v70.

Results

• Changed goldens: coal_chp_extraction (electricity can now reach its 800 MW cap; before it was stuck at 470) and test_a_lot (one hour differs at an identical objective). All other scenarios are unchanged.
• Tests: new tests cover every fix above. CI is green on Linux, macOS and Windows.

Follow-ups (not in this PR)

Listed in docs/dev/unit_floors_and_reserves.md:

• upward reserve from offline online-capable units; a design for activation and start-up times is in progress;
• consumer reserve headroom;
• a downward-reserve rule for connections;
• the reserve-balance slope factor;
• connection delay;
• the dynamic / n-1 reserve activation bug;
• n-1 as one constraint per failing unit.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Cai1ke9MzbEMpY1jfScB6q

[ArttuTupala]

It seems that the discrepancy on what the capacity of unit with multiple inputs means is in the tests as well.
Therefore it should be decided which of the two it means, and align all to this.

"Currently the documentation claims that the capacity limits the sum of outflows.
However, currently it applies to the outflows separately. Not sure which one is the intended one"
#341

[jkiviluo]

working on this - more complicated than it seemed at first.