`bounds:` has no `where:`, so a mixed fleet merges its fixed and free capacities into a data-prep column

[FBumann]

Prompt: Maybe we should transfer all of them from lpspec to mathspec and close them in lpspec? Lets go through one by one.

Note

The following content was generated by AI. Moved from fluxopt/lpspec#1220, which holds the evidence — probes, corpus audits and the ports behind it — and is closed against this issue.

What can be improved?

The language half of the upstream issue; the port that exercises the
equal-bounds pin on a real mixed fleet stays there.

declarations.md offers the
equal-bounds pin as the answer to a quantity that is a decision in one model
and data in another: bind lower and upper to the same value where it is
fixed, and one equation serves both.

Within one model it does not reach the ordinary case, because bounds: has
no where:. A fleet where some entities have a fixed capacity and the rest are
free needs a merged column — the fixed value where fixed, the maximum or
inf where free — built in data prep. A fact the model file already states,
"this entity's capacity is given", leaves the file and reappears as a column
nothing declares the meaning of. That is the same tax as pushing a regime mask
into data, one layer down: at the bounds rather than at the constraint.

Everything needed is already declared — the mask is p_nom_set being present,
which the language says elsewhere. This is ergonomics, not new power:
today's answer works and produces the same LP.

Also worth checking here

The pin's fitness for the case the docs advertise it for is unverified — no
model in examples/ uses it for a mixed fleet, and the upstream port mirrors
PyPSA's two-name split instead. So declarations.md's sentence reads as
covering a case nothing exercises.

Related: #261, a different restriction on the same field.

Version

v0.0.0-alpha.42

[FBumann]

Prompt: "Can it be in dataprep?"

Note

The following content was generated by AI.

A second instance of this tax, on a live rung — and this one costs a worse LP, not just a
column nothing declares.

examples/pypsa.yaml states a committable unit's status as an unbounded integer and caps it
with a row:

Generator_status:
  foreach: [snapshot, generator]
  where: Generator_committable
  domain: integer
  bounds: { lower: 0 }          # no upper — Generator_status_p_fixed_upper is the cap

PyPSA writes both: the plain case is a binary column (upper=1 on the column) and the
<= 1 row. That redundancy is not sloppiness — a binary column is strictly better for a MIP
solver than an unbounded integer with a cap row, since branching and presolve exploit
binaries. The file cannot follow, because the cap it would put on the column varies by regime
and bounds: takes no where::

regime	the cap PyPSA puts on the column
committable, not modular	1
committable, fixed modular	the module count (3 for p_nom=90, p_nom_mod=30)
committable, extendable modular	none — status <= n_mod is a row, the cap being a decision

Verified against pypsa 1.3.0: for a fixed modular unit the status column is an integer with
upper=inf and the row carries rhs=3.0, so the row is load-bearing there; for a plain
committable unit the column is binary with upper=1 and the row is implied.

The data-prep answer works, which is what makes it a tax

Exactly as this issue describes — a merged column, inf where another row caps it instead.
It is not hypothetical: it builds, solves and agrees on both lanes, and survives the LP
writer.

The probe

cap is 1 for the plain build, 3 for the fixed modular one, +inf where a row caps it:

relational objective: 11.0   x = [3.0, 1.0, 7.0]
eager objective:      11.0
  x upper bounds    : [ 1.  3. inf]

and through the LP writer:

bounds
0.0 <= x0 <= 1.0
0.0 <= x1 <= 3.0
0.0 <= x2 <= +infinity

So the pin's fitness question above has an answer for this shape: the merged column does
produce the same LP. What it costs is that +inf means "no cap here" — a regime encoded
as a magic value, in a column whose declared meaning says nothing about regimes, and visible
only in the consumer's data prep rather than in the file.

What where: on bounds would buy here

bounds:
  lower: 0
  upper: { value: 1,                           where: "not (Generator_p_nom_mod > 0)" }
  upper: { value: Generator_modules_installed, where: "Generator_p_nom_mod > 0 and not Generator_p_nom_extendable" }

No magic value, and the file states the cap where the reader looks for it. It would also close
four of the differences the downstream ladder records against PyPSA — the three
the cap is a row here, where PyPSA bounds the variable at 1 as well entries on
Generator-{status,start_up,shut_down}, and the Generator-status-p-fixed-upper dual that
follows from them, a binding cap's price being free to sit on the bound or on the row.

Note cases: (#168) does not reach this: a bound takes a declared parameter, and a named
expression — cased or not — is refused there (bounds.upper: 'cap' is not a declared parameter).