Skip to content

perf: skip charge/discharge lock binaries for one-directional batteries#89

Open
andig wants to merge 1 commit into
model/tight-big-mfrom
model/skip-vacuous-zcd
Open

perf: skip charge/discharge lock binaries for one-directional batteries#89
andig wants to merge 1 commit into
model/tight-big-mfrom
model/skip-vacuous-zcd

Conversation

@andig

@andig andig commented Jul 15, 2026

Copy link
Copy Markdown
Member

Full-suite benchmark (bundled CBC, single-thread, app-faithful build, median of 3)

Measured against #88 (this PR's base):

case #88 nodes/iters/wall this PR nodes/iters/wall
013 0 / 12 / 0.05s 0 / 5 / 0.05s
017 0 / 98 / 0.06s 0 / 87 / 0.06s
020 18 / 1442 / 0.62s 18 / 1806 / 0.56s
021 10 / 220 / 0.38s 52 / 798 / 1.24s
others unchanged unchanged
TOTAL 1.70s 2.50s

⚠ Honest tradeoff: the binary removal is a pure model-size win (−154 binaries on 020) and slightly helps 013/017/020, but 021 regresses 5× (10→52 nodes) — with the vacuous rows gone, CBC's dive heuristics land elsewhere on 021's alternate-optima plateau and the suite total goes net-negative on this machine. The removal is structurally sound (optimum unchanged); whether smaller models or this machine's search-path luck matters more is a maintainer call. Happy to close if the wall-clock regression outweighs the size win.

@andig

andig commented Jul 15, 2026

Copy link
Copy Markdown
Member Author

@ekkea found this during model optimization when porting CBC to Go.

A battery with d_max=0 (or c_max=0) cannot have simultaneous charge and
discharge, so its z_cd lock pair is vacuous — yet it contributed one
binary and two rows per time step (154 binaries on case 020, a quarter
of the model's integer variables). Follow the existing z_c pattern:
create z_cd only when the battery can do both, None otherwise.

Case 013's expected objective_value moves again for the same reason as
in the big-M change underneath: the constraints removed are vacuous, so
the optimum is unchanged (side-by-side full-objective check agrees to
all printed digits), but the penalty-free decomposition is not unique
across the optimal plateau and the solution lands elsewhere on it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant