piecewise_lp¶

A piecewise-linear cost curve stated as the lines its segments lie on — piecewise with one line changed, and the only method that declares no auxiliary variable at all.

The problem¶

The weight methods all say one thing: put the operating point somewhere on the curve, and read the cost off beside it. Saying it costs one weight per breakpoint per row, plus a convexity row to make the weights a combination.

A convex curve needs none of that, because it is the upper envelope of its own segment lines:

So cost \(\ge\) every one of those lines says cost \(\ge f(p)\), and a minimising objective pushes it down onto the curve. That takes one row per segment, no weights and no convexity row, so the model declares no variable beyond its own two.

The saving is a trade. Against method: convex on 20 generators × 48 snapshots × 6 breakpoints:

method: lp drops three quarters of the columns and a third of the nonzeros, and carries more than twice the rows.

The model¶

description: >-
  The same least-cost dispatch as `piecewise.yaml`, with each generator's cost
  curve stated as the lines its segments lie on rather than interpolated
  between its breakpoints. The curve is convex and the objective pushes the
  cost down, so a cost above every segment line settles on the curve — which
  needs no interpolation weights, and so declares no auxiliary variable at all.

dimensions:
  snapshot:
    description: dispatch periods
    dtype: int
  generator:
    description: dispatchable units
    dtype: str
  bp:
    description: breakpoints of the cost curve
    dtype: int

parameters:
  p_max:
    description: maximum dispatch
    dims: [generator]
  load:
    description: demand to be met
    dims: [snapshot]
  bp_x:
    description: breakpoint dispatch levels, one curve per generator
    dims: [generator, bp]
  bp_y:
    description: cost at each breakpoint, one curve per generator
    dims: [generator, bp]

variables:
  p:
    description: dispatched power
    dims: [snapshot, generator]
    bounds:
      lower: 0
      upper: p_max
  op_cost:
    description: operating cost, held above every segment of the generator's curve
    dims: [snapshot, generator]
    bounds:
      lower: 0

piecewise:
  cost_curve:
    description: >-
      cost bounded below by the curve — the `>=` is what says which side of the
      lines the cost sits on, and the curvature has to match it: lines that
      envelope a convex curve would cut a concave one, and the solve comes back
      optimal either way
    over: bp
    links:
      - [p, bp_x]
      - [op_cost, bp_y, ">="]
    method: lp

constraints:
  balance:
    dims: [snapshot]
    expression: sum(p, over=generator) == load

objective:
  sense: minimize
  description: total operating cost, taken off the curves rather than from a marginal rate
  expression: sum(op_cost)

What it exercises¶

The >= on the second link is the whole declaration. It says which side of the lines the cost sits on, and the curvature has to match it. Lines that envelope a convex curve cut a concave one, and the solve comes back optimal either way, with an answer below the curve it was told to price. So >= requires a convex curve and <= a concave one, checked against the breakpoint values once they are bound. That check is stricter than the mixed-curvature guard of method: convex, which a wholly concave curve passes.

A segment line does not stop where its segment does, so two more rows pin the operating point inside the curve's own range: p >= min(bp_x) and p <= max(bp_x), at the first and last breakpoint. Without them the formulation extrapolates along the end segments, where the weight methods cannot go.

Everything above is emitted as ordinary constraints before the plan exists. There is no plan node for a curve and no engine case, so both lanes receive identical affine rows and the LP file agrees with them.

This model and piecewise are the same instance. Both reach 3850.0 and the same shadow prices on balance, so two formulations of one curve agree on the dual as well as the primal.

Compare sos, the other one-line variant, which moves the restriction outward to the solver where this one removes the need for it.

examples/piecewise_lp.yaml · back to all models