Investigate continuous-action/exact-piecewise-linear reformulation of the DP to eliminate discretization interpolation error

[johanzander]

Summary

Tracked follow-up from #275 (DP holds charge for a known-worse future price
on extended horizons) and the design doc
docs/superpowers/specs/2026-07-12-dp-continuous-path-reconstruction-fix-design.md
(Option C there). Not being implemented as part of the #275 fix — this is a
larger algorithm redesign, filed here so the idea isn't lost.

The problem it would solve

The DP's backward induction (core/bess/dp_battery_algorithm.py) only
computes its value function V[t, i] at a fixed grid of SOE points
(SOE_STEP_KWH = 0.1) and searches a fixed grid of power actions
(POWER_STEP_KW = 0.2). The real battery's actual SOE almost never lands
exactly on a grid point, so reconstructing the actual schedule (Step 2 of
optimize_battery_schedule) has to interpolate V at off-grid states.
V has genuine kinks (slope discontinuities) wherever the optimal action
changes character — e.g. crossing BATTERY_EXPORT_THRESHOLD_KWH's
self-throttling cutoff, or a price threshold where exporting stops being
worth it — and linear interpolation across a kink gives a wrong answer.
That's the confirmed root cause of #275, and a smaller, previously-shipped
version of the same mechanism (2026-07-06 guardrail-removal doc).

Two options already tried (grid-snap vs. interpolated recompute) each win
in a different regime (single-day vs. multi-day horizons) — see #275 and the
2026-07-12 design doc for the empirical evidence. Neither eliminates the
error; they just move it around.

What this issue proposes investigating

Remove the fixed grid as the source of the mismatch entirely, via one or
both of:

1. Solve for the optimal power level analytically instead of grid search.
   For a fixed price/state, one-period reward is mostly piecewise-linear in
   the charge/discharge power, so the true per-period optimum could be
   computed directly (root-finding / closed-form) at the actual continuous
   SOE, instead of testing ~150 discrete power values.
2. Track V as an exact piecewise-linear function of SOE, not a sampled
   grid. Classical LP-sensitivity result: for linear dynamics and
   piecewise-linear reward, the true value function at each time step is
   itself exactly piecewise-linear, with a small number of real breakpoints
   — not the artificial ones introduced by uniform 0.1 kWh sampling.
   Tracking those breakpoints exactly would make "interpolation" exact
   rather than approximate, since there'd be no hidden kink to interpolate
   across.

Why this is deferred, not part of #275's fix

• Real algorithm redesign, not a patch — touches _run_dynamic_programming's
  core loop and _compute_reward's structure.
• Needs proof that the reward function is piecewise-linear/concave enough
  for either approach to work cleanly; BATTERY_EXPORT_THRESHOLD_KWH
  (dp_battery_algorithm.py:344) is itself a hard discontinuity worth
  checking against this assumption.
• No existing prototype — 2026-07-06 already flagged this direction as out
  of scope for that PR, for the same reasons.
• Interacts with perf: vectorize DP backward-induction hot loop in dp_battery_algorithm.py #236 (DP hot-loop perf) either way, depending on which
  approach is chosen.

References

• DP holds charge for a known-worse tomorrow price instead of a known-better today price (real 2-day horizon branch) #275 — reported symptom and root cause
• docs/superpowers/specs/2026-07-12-dp-continuous-path-reconstruction-fix-design.md — full options analysis (A: grid-snap, B: finer discretization, C: this issue)
• docs/superpowers/specs/2026-07-06-dp-bellman-guardrail-removal-design.md — where the grid-snap-vs-interpolation mechanism was first identified and partially mitigated
• perf: vectorize DP backward-induction hot loop in dp_battery_algorithm.py #236 — DP hot-loop perf, relevant to feasibility of either approach here

[johanzander]

Update: Approach 2 likely not needed — see #275

While scoping Approach 2 (tracked as #285), a direct grid-resolution sweep against #275's own "Worse" reproduction scenario found that held charge stays flat (~3.9-4.1 kWh) across a 20x finer SOE_STEP_KWH (0.05 → 0.0025) — i.e. even a near-exact value function doesn't change the behavior. Combined with a deeper trace showing the reported "export at a worse known price" doesn't actually hold up (the overnight reserve drains to floor before solar arrives; the later export is fresh next-day solar, not carried-over charge), this means the premise both Approach 1 (#282) and Approach 2 were built on — that #275's symptom is a discretization/interpolation artifact — appears to be wrong.

Full evidence: #275 (comment)

Recommendation: pause Approach 2 (#285) pending #275's resolution/re-diagnosis. #282 (Approach 1) remains merged as an independent hardware-safety/accuracy improvement, not as a fix for this issue's original symptom.

[johanzander]

Correction: the follow-up investigation's premise was wrong, but the original fix (b13) was real

My earlier comment on this issue overstated things by suggesting #275's symptom might be a misdiagnosis from the start. Corrected picture, see #275 (comment) for full detail:

• The real defect DP holds charge for a known-worse tomorrow price instead of a known-better today price (real 2-day horizon branch) #275 reported (excess held charge from SOE-grid-interpolation error in Step 2) was genuinely fixed by Option B (v9.9.0b13, PR fix: refine DP SOE grid resolution to reduce interpolation error (#275, Option B) #279) — 27% reduction, verified.
• This issue's two follow-up approaches (Approach 1 = Replace DP per-period grid search with closed-form breakpoint enumeration (Approach 1 of #276) #282, Approach 2 = Exact piecewise-linear value-function propagation for the DP backward induction (Approach 2 of #276) #285) were built on the assumption that more of that same discretization error remained to eliminate. Direct testing (20x finer grid resolution, exact hardware-aware search, Bellman-optimality checks, and realized-cost financial comparison against the "hold less" alternative) shows that assumption is wrong — the post-b13 residual is not discretization error, it's the financially optimal amount.

Recommendation: close this issue. #282 remains merged as an independent, real hardware-safety/accuracy fix (unrelated to this issue's original symptom). #285 (Approach 2) is being closed as not needed.

[johanzander]

Closing — the follow-up approaches this issue scoped (Approach 1/#282, Approach 2/#285) were built on an assumption (more discretization error remaining after #279) that direct investigation disproved. See #275 and PR #286 for the full findings.