Skip to content

Weight unit commitment startups by days each season represents - #387

Open
SutubraResearch wants to merge 1 commit into
TemoaProject:unstablefrom
SutubraResearch:fix/uc-startup-day-weight
Open

SutubraResearch wants to merge 1 commit into
TemoaProject:unstablefrom
SutubraResearch:fix/uc-startup-day-weight

Conversation

@SutubraResearch

@SutubraResearch SutubraResearch commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #386.

What changed

  • New days_in_season(model, s) = segment_fraction_per_season[s] * days_per_period in temoa/extensions/unit_commitment/components/startup.py.
  • uc_startup_cost_rptv, uc_startup_emissions_rpe and uc_startup_input_rpsdc multiply starts by it. That covers the objective, limit_emission_constraint, commodity_balance_constraint and annual_commodity_balance_constraint.
  • Output polling (poll_startup_input_results, poll_emission_results, and the emission cost in poll_startup_cost_results) does the same, so output_flow_in, output_emission and output_cost match the model.
  • Docs: the startup cost formula in unit_commitment.rst and append_startup_costs; matching lines for startup emissions and inputs; a note that output_unit_commitment describes one day of each season.

The test

tests/test_unit_commitment_starts.py solves an 8-day period two ways: as two seasons of 2 and 6 days, and as 8 one-day seasons. Both must give 10 MW started, startup cost 30, CO2 50, startup fuel 70 and fuel supply 190; the output costs must sum to the objective, and the two objectives must be equal. Before the fix the multi-day case fails (startup cost 9; objective 784.35 against 1390.48); the one-day case passes before and after. The full suite passes (296); mypy and ruff are clean.

What doesn't change

  • One-day-per-season models: the factor is 1. The test_week objective, starts and startup cost, emissions and inputs are unchanged in all three time-sequencing modes, checked with HiGHS and Gurobi.
  • Within-day constraints: integer domains, started ≤ offline, the transition, min up time and the ramp startup allowance. They compare starts with other quantities on one day.
  • output_unit_commitment.start_cap stays per represented day, alongside online_cap and stop_cap; multiply it by the season's days for a total.

One assumption to note

In consecutive_days mode with multi-day seasons, a start between the last hour of one season and the first hour of the next is also multiplied by the season's days. That treats each day of the season as repeated, the same assumption ordinary flows already make.

Summary by CodeRabbit

  • Bug Fixes
    • Startup costs, emissions, and fuel inputs now account for all days represented by each season, keeping totals consistent across multi-day and one-day season configurations.
    • Clarified that reported start and stop capacities are per day and must be scaled to calculate season totals.
  • Tests
    • Added coverage confirming consistent startup totals and costs across different season representations.

@coderabbitai

coderabbitai Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Configuration used: Repository: TemoaProject/temoa/.coderabbit.yaml
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 1834c7cf-0b9d-4b00-bd87-fb5edff27bf2
📥 Commits

Reviewing files that changed from the base of the PR and between d5148db and 8adf18c.

📒 Files selected for processing: 7
  • docs/source/extensions/unit_commitment.rst
  • temoa/extensions/unit_commitment/components/startup.py
  • temoa/extensions/unit_commitment/core/data_puller.py
  • tests/conftest.py
  • tests/test_unit_commitment_starts.py
  • tests/testing_configs/config_uc_starts.toml
  • tests/testing_data/uc_starts.sql

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

Walkthrough

Startup costs, emissions, and inputs now include the number of days represented by each season. Tests compare these values and the objective for equivalent multi-day and one-day season representations.

Changes

Startup accounting

Layer / File(s) Summary
Apply season-day weighting
temoa/extensions/unit_commitment/components/startup.py, temoa/extensions/unit_commitment/core/data_puller.py, docs/source/extensions/unit_commitment.rst
Startup cost, emissions, and input calculations now multiply starts by segment_fraction_per_season[s] * days_per_period. The documentation describes this weighting and clarifies that start_cap and stop_cap are per-day values.
Validate equivalent season representations
tests/testing_data/uc_starts.sql, tests/testing_configs/config_uc_starts.toml, tests/conftest.py, tests/test_unit_commitment_starts.py
A test fixture compares an eight-day period represented by two multi-day seasons with the same days represented by eight one-day seasons. Tests check startup totals, output values, and matching objectives.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: idelder

Fixed issue severity:

Merge Risk: ⚪ Minimal · up to 8adf1

No actionable merge-blocking risk is identified; the change is ready for normal merge checks.

Pre-merge checks: Passed 5
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely describes the main change: weighting unit commitment startups by the number of days each season represents.
Linked Issues check Passed Issue #386 requires season-day weighting wherever starts contribute to cost, emissions, or inputs. startup.py defines days_in_season as segment_fraction_per_season[s] * days_per_period and appli…
Out of Scope Changes check Passed The added documentation, test fixture, configuration, and tests all support issue #386 by describing or checking season-day startup accounting. The change summary identifies no unrelated implementatio…
Docstring Coverage Passed Docstring coverage is 93.33% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 15 functions across 4 files. (3 skipped: 3 …
Full details: Linked Issues check

Explanation

Issue #386 requires season-day weighting wherever starts contribute to cost, emissions, or inputs. startup.py defines days_in_season as segment_fraction_per_season[s] * days_per_period and applies it to direct startup costs, startup emissions, and startup inputs. These expressions feed the objective, emission limit, and commodity balances. data_puller.py applies the same factor to startup input, emission, and startup-cost output polling. The new tests compare two multi-day seasons with eight one-day seasons and check startup totals, output totals, fuel supply, and objective equality. The within-day commitment variables remain unweighted.

Full details: Out of Scope Changes check

Explanation

The added documentation, test fixture, configuration, and tests all support issue #386 by describing or checking season-day startup accounting. The change summary identifies no unrelated implementation changes.

Full details: Docstring Coverage

Explanation

Docstring coverage is 93.33% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 15 functions across 4 files. (3 skipped: 3 unsupported.)

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codecov

codecov Bot commented Oct 16, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

This branch has not been deployed

No deployments
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.

2 participants